Short answer. RAG and OKF both exist to give an agent knowledge it wasn't trained on — but they put the work in opposite places. RAG indexes your documents and, on every query, retrieves the closest chunks. OKF (Google's Open Knowledge Format) asks you to curate the knowledge into linked Markdown up front, then hands the whole structured bundle to the model so there's almost nothing to retrieve. The decision isn't "which is better" — it's who pays to make the knowledge usable, and when:
- Choose OKF for a small, canonical, high-stakes source of truth you can afford to curate — a policy set, a product catalog, a data dictionary — where a wrong answer is expensive.
- Choose RAG for the large, messy, fast-changing pile you can't curate: emails, tickets, chat logs, a document lake.
- Most real systems want both — an OKF bundle as the trusted, link-traversable core inside a RAG system that mops up everything else.
The one distinction that matters: authoring time vs query time#
A RAG pipeline pays nothing when you write a document. The cost lands at query time, on every single request: embed the question, search the vector store, pull the top-k nearest chunks, and hope the right ones surfaced together. That "hope" is the whole problem. Retrieval is probabilistic — nearest-neighbor search can miss the one passage a multi-hop question needs, and it fails silently, returning a confident answer built on the wrong context. And the chunker that made the index routinely severs a fact from the context that makes it true, so a chunk reads correctly on its own and is wrong inside its document.
OKF inverts the ledger. You pay at authoring time — a human, or an enrichment agent that drafts concepts from a dataset, writes the knowledge as whole concepts and links them together. Then a multi-hop question becomes link traversal — following relationships that are already explicit — instead of a fresh probabilistic guess on every call. The knowledge arrives pre-organized, so there's far less to retrieve and far less to get wrong.
That's the trade in one line: RAG front-loads nothing and pays forever; OKF front-loads the curation and pays almost nothing per query. Which is cheaper depends entirely on how often you'll ask and how much a wrong answer costs.
What OKF actually is (it's smaller than it sounds)#
OKF is not a platform, a runtime, or a database. It's a file format. A bundle is a directory tree of Markdown files, each with a few lines of YAML frontmatter where only a type field is required (title, description, resource, tags and timestamp are optional). Concepts point at each other with ordinary Markdown links. Two reserved files give the bundle a spine: index.md for navigation and log.md for change history.
Google Cloud's data team published v0.1 on June 12, 2026, under the Apache-2.0 license; v0.2 added sourcing and trust signals so a bundle can carry where a fact came from and when it expires. It formalizes the "LLM-wiki" pattern — the idea that the best context for a model is a small, hand-maintained wiki, not a firehose of raw documents. Because it's just files, an OKF bundle lives happily in a git repo, diffs like code, and carries zero model or vendor lock-in — any model can read plain Markdown. That portability is the sharpest contrast with a vector store, which is wired to the embedding model and database you chose.
So which do you build on?#
Run three checks before reaching for OKF:
- Is the knowledge canonical? If it has a real structure worth drawing — a catalog, a rulebook, an ontology — OKF's links pay off. A shapeless pile of chat logs has nothing to structure; that's RAG's job.
- Is a wrong answer expensive? OKF's whole-concept integrity and explicit links buy you fewer out-of-context answers. If you're doing casual Q&A over a wiki, plain RAG is fine.
- Will someone maintain it? This is the one that kills OKF projects. Front-loaded curation becomes curation debt the moment nobody tends the bundle. RAG's "re-embed and move on" wins by neglect.
If you've read our GraphRAG vs vector RAG piece, OKF will feel familiar: it's the same instinct — make relationships explicit instead of forcing a retriever to rediscover them — pushed all the way to the authoring layer. And if you're still deciding whether you even need the heavier machinery, start with agentic RAG vs naive RAG; plenty of systems that reach for a knowledge format really just needed a better retrieval loop over their existing vector store.
The honest verdict: OKF is not the end of RAG, it's the part of RAG you were supposed to do by hand all along and mostly skipped. Structure the knowledge that deserves it; retrieve the rest.
