People often ask whether they should use the Open Knowledge Format (OKF) or RAG. The question contains a hidden assumption that is worth dismantling first: that the two are alternatives. They are not. RAG is a retrieval architecture. OKF is a content format. Comparing them directly is a little like comparing a filing system with the quality of the documents you put in it.
This page sets out what each one is, why they live at different layers, how a curated OKF bundle can make a RAG system noticeably better, and when OKF on its own is enough that you can skip retrieval infrastructure altogether.
What RAG is
Retrieval-Augmented Generation is an architecture. Documents are split into chunks, each chunk is embedded into a vector, and those vectors are stored in a vector database. At query time, the system embeds the user’s question, finds the most similar chunks, and injects them into the prompt so the model answers using retrieved context rather than parametric memory alone.
RAG is a pipeline, not a file format. It does not care whether the documents it ingests are clean or messy, authored or scraped, deduplicated or contradictory. It will faithfully retrieve whatever you indexed, including the noise. That last point matters, and it is where OKF enters the picture.
What OKF is
The Open Knowledge Format is an open specification (v0.1) published by Google Cloud on 12 June 2026. It is a vendor-neutral standard for packaging curated knowledge so that both humans and AI agents can use it.
An OKF bundle is a directory tree of UTF-8 markdown files. Every file carries YAML frontmatter delimited by ---, with a required type field and recommended fields such as title, description, resource, tags, and timestamp. The filenames index.md and log.md are reserved. There is no central registry, no runtime, and no SDK requirement: a bundle is just well-structured markdown under version control. You can read more in what the Open Knowledge Format is.
The key idea is curation. OKF content is authored and maintained by humans in source control. It is structured, typed, deduplicated, and human-readable. That is precisely the opposite of the raw, scraped, often duplicated HTML that frequently ends up inside RAG pipelines.
Different layers of the stack
The cleanest way to hold the distinction is by layer.
RAG is the retrieval and serving layer. It answers “given a question, which pieces of knowledge should reach the model?”
OKF is the content and authoring layer. It answers “how is the knowledge itself written, structured, and maintained?”
Because they answer different questions, they compose rather than compete. A RAG pipeline needs source documents; OKF is a high-quality way to produce them. An OKF bundle needs a way to reach the model when it is too big for context; RAG is one way to do that.
Side-by-side comparison
| Dimension | OKF | RAG |
|---|---|---|
| What it is | A content format for curated knowledge | A retrieval architecture |
| Layer in the stack | Authoring and content layer | Retrieval and serving layer |
| How knowledge is stored | Markdown files with YAML frontmatter, in version control | Chunks embedded as vectors in a vector database |
| Freshness / maintenance | Edited by humans in git; timestamp, log.md | Requires re-chunking and re-embedding on change |
| Human readability | Fully human-readable and editable | Vectors are opaque; source readability depends on inputs |
| Infrastructure required | None beyond markdown and git | Embedding model, vector store, retrieval pipeline |
| Best for | Curated, portable, authored knowledge | Querying large corpora too big for context |
| Limitations | Large bundles still need a retrieval path | Output quality capped by quality of indexed content |
How OKF makes RAG better
RAG output is only as good as what you indexed. If you embed scraped, duplicated, contradictory pages, retrieval will surface scraped, duplicated, contradictory chunks, and the model will dutifully reason over them. This is the single biggest source of disappointing RAG results in practice.
An OKF bundle attacks the problem at the source. Because the content is authored, deduplicated, and structured, the chunks you embed are cleaner and more self-consistent. Typed frontmatter (type, title, tags, timestamp) gives you natural metadata for filtering and for attaching provenance to retrieved passages. The reserved log.md gives you a change history, so you can tell when knowledge was last updated and re-index deliberately rather than guessing.
In short, OKF improves the input to RAG: fewer junk passages retrieved, better metadata to filter on, and a clear audit trail for freshness. You can browse concrete bundles on the examples page to see the structure that makes them good corpus material.
When OKF alone is enough
Not every knowledge problem needs a vector database. Modern context windows are large, and many useful knowledge bases are small. When a bundle, or the relevant slice of it, fits in context, you can load it directly and skip retrieval entirely.
OKF is built for exactly this through progressive disclosure. An agent reads index.md first to understand the shape of the bundle, then descends only into the specific files it needs. That gives you targeted, relevant context without embeddings, similarity search, or a vector store to operate and keep in sync.
The trade-offs are real and worth stating plainly. Loading directly is simpler, cheaper to run, fully transparent, and free of retrieval errors, but it is bounded by the context window and by token cost per call. RAG scales to corpora far larger than any context window, but adds infrastructure, an embedding and re-indexing burden, and the risk of retrieving the wrong chunks. Choose by size: small and focused favours OKF alone; large and sprawling favours RAG.
OKF and RAG together
For most serious systems, the answer is both, used at the layers they belong to.
Author and maintain your knowledge as OKF bundles in version control. Humans edit clean markdown, changes are reviewed and logged, and the corpus stays auditable. Then run an indexing pipeline that chunks and embeds those bundles into your vector store. RAG retrieves at query time from a source that was curated rather than scraped.
This pairing gives you the strengths of each without their weaknesses. You get OKF’s clean, typed, version-controlled authoring and RAG’s ability to scale beyond the context window. When knowledge changes, you edit the bundle, your log.md records it, and you re-index. The vector store is downstream of a source of truth that a human can actually read and correct.
A practical rule of thumb:
- Small, focused knowledge that fits in context: OKF loaded directly, no retrieval needed.
- Large knowledge that exceeds the context window: RAG, with OKF bundles as the curated source corpus you index.
- Knowledge that must stay auditable and maintained either way: author it as OKF first, then decide how it reaches the model.
The framing to keep is simple. OKF is how you write and maintain knowledge. RAG is how you fetch it at scale. They are not rivals; they are neighbours on the stack. For a different comparison at the discovery layer, see OKF versus llms.txt, and find the official specs and reference implementations on the resources page.