Retrieval Augmented Generation, or RAG, and the Open Knowledge Format, or OKF, solve two different problems. RAG is a technique. It lets an AI model search outside documents and pull relevant pieces into its answer. OKF is a format. It is a standard way to write down and organize knowledge so any AI system can read it. You do not have to choose only one. Most real systems will end up using both.
This guide explains each one in plain terms, then walks through how they show up inside three ecosystems people actually build on, Anthropic's Claude, OpenAI's models, and the open source RAG tools like LangChain and LlamaIndex.
What RAG actually is
Retrieval Augmented Generation is a pattern, not a product. A model gets a question. Before it answers, a search step runs. That search step looks through your documents, finds the most relevant pieces, and adds them to the prompt. The model then answers using both its own training and the fresh material it was just handed.
The search step usually works through embeddings. An embedding is a list of numbers that captures the meaning of a piece of text. Documents get cut into chunks, each chunk gets turned into an embedding, and those embeddings get stored in a vector database. At query time, the question also gets turned into an embedding, and the system finds the stored chunks whose embeddings are closest in meaning.
RAG became popular because it is cheaper and faster than retraining a model on new data. It also lets an answer point back to a real source, which matters for trust and for catching mistakes.
RAG has known weak spots. Chunking can cut a sentence away from the context that explained it. A search step can return the wrong chunk, or an outdated one, if the index has not been refreshed. Keeping thousands of embeddings in sync with fast-changing source data is real ongoing work, not a one-time setup task.
What OKF actually is
Google Cloud announced the Open Knowledge Format on June 12, 2026. OKF is an open specification for writing down knowledge in a shape that any AI agent can read, without a proprietary database, SDK, or vendor account.
An OKF bundle is a folder of plain markdown files. Each file starts with a short block of YAML frontmatter, a small structured header, followed by normal markdown text. The specification requires exactly one field in that header, called type. Everything else, like a title, a description, or tags, is optional and left to whoever is writing the bundle.
Here is what one file looks like, based on Google Cloud's own example.
1--- 2type: BigQuery Table 3title: Orders 4description: One row per completed customer order. 5resource: https://console.cloud.google.com/bigquery?p=acme&d=sales&t=orders 6tags: [sales, revenue] 7timestamp: 2026-05-28T14:30:00Z 8--- 9# Schema10| Column | Type | Description |11|--------|------|-------------|12| order_id | STRING | Globally unique order identifier. |13| customer_id | STRING | FK to customers. |1415# Joins16Joined with customers on customer_id.Files link to each other with ordinary markdown links, the same way a wiki page links to another wiki page. That web of links forms a graph, which is richer than a plain folder structure. Google's team has pointed to a line from AI researcher Andrej Karpathy as part of the thinking behind this, the idea that keeping a personal wiki up to date is exactly the kind of bookkeeping task an LLM is good at, even when a human would find it tedious.
OKF is version 0.1 today. Google Cloud calls it a starting point, not a finished standard. The spec, a reference agent that drafts OKF files from BigQuery data, a visualizer, and sample bundles are public on GitHub under the Knowledge Catalog project.
The real difference between RAG and OKF
Here is the distinction that most headlines skip past. RAG is a retrieval technique. It answers the question, how does a model find the right piece of text at the right moment. OKF is a packaging format. It answers a different question, what shape should that text be in, so it stays accurate, linkable, and readable by more than one system.
Google Cloud has said directly that OKF is not a replacement for RAG. Most real setups will use OKF to organize and clean up the source knowledge, then still run a RAG pipeline, or another retrieval method, on top of that OKF bundle to actually serve answers at scale. OKF suits knowledge that is curated and relatively stable, things like a table schema, a runbook, or an internal policy. RAG still wins for searching large, messy, unstructured collections, like years of support tickets or a stack of PDFs.
Think of it this way. RAG is the search engine. OKF is the well organized library that search engine is searching through. A better organized library does not remove the need for a search engine once that library gets large. It just means the search engine has cleaner material to work with.
RAG and OKF in the Anthropic ecosystem
How Claude does RAG today
Anthropic's own engineering team has published a technique called contextual retrieval. Standard RAG chunks a document and embeds each chunk on its own, which strips away surrounding context. Contextual retrieval fixes that by using Claude to write a short summary for each chunk before it gets embedded, so the chunk still carries the information that explains what it is about. Anthropic combines this with a traditional keyword search method called BM25, and with a reranking step, and reports that the combination cuts retrieval failures by up to 67 percent compared to plain embedding search.
Anthropic also points out a case where RAG is not needed at all. For a knowledge base under about 200,000 tokens, Claude's large context window and prompt caching feature let you paste the entire knowledge base into the prompt directly. Prompt caching keeps that content ready between calls at a lower cost, so there is no retrieval step to build or maintain for smaller knowledge sets.
Where OKF fits next to Claude Skills and MCP
Anthropic already ships a markdown based system that looks close in spirit to OKF, called Agent Skills. A skill is a folder with a file named SKILL.md at its root. That file has YAML frontmatter with a name and a description, followed by markdown instructions, plus optional scripts and reference files. Claude loads a skill only when the task calls for it, instead of holding every skill in context all the time.
Anthropic's Model Context Protocol, or MCP, is the separate piece that lets Claude connect to outside tools and data sources at runtime. An OKF bundle is a natural thing to expose through an MCP connector, since both are built around plain files and both avoid a proprietary storage layer. As of this writing, Anthropic has not announced first-class OKF support, so pairing the two today means writing that connector yourself, or waiting for a community integration.
RAG and OKF in the OpenAI ecosystem
File search and vector stores as OpenAI's RAG layer
OpenAI's Assistants API is being retired, with a shutdown date of August 26, 2026, after the Responses API reached the same feature set. The Responses API now carries File Search, OpenAI's built in RAG tool. You upload files into a vector store, OpenAI parses and chunks them, generates embeddings, and stores everything for you. At query time, File Search runs both vector search and keyword search together and hands the model the matching passages. File Search accepts a range of formats, including PDF, DOCX, and plain markdown, and supports metadata filtering so you can scope a search to a subset of files.
This is a fully managed RAG pipeline. You do not choose a chunking strategy or an embedding model by hand, and pricing is based on storage plus the number of search calls.
What OKF would add on top
Because File Search already accepts markdown files, an OKF bundle can be uploaded into an OpenAI vector store today without any special adapter, since a .md file with YAML frontmatter is still just a markdown file to that system. What OpenAI's stack does not give you is the format's real benefit, portability. Files uploaded into an OpenAI vector store are indexed and stored inside OpenAI's infrastructure. An OKF bundle kept in a plain git repository stays readable, linkable, and reusable by any other tool, including a different vendor's RAG pipeline, without re-exporting anything. Feeding OKF bundles into OpenAI's File Search is a reasonable way to get OpenAI's managed retrieval on top of vendor neutral source files, but the neutrality lives in the bundle, not in OpenAI's index.
RAG and OKF in the open source ecosystem
LangChain, LlamaIndex, and the RAG framework field
The open source RAG landscape is large and active heading into 2026. LangChain remains the biggest and most general framework, with the widest set of integrations for models, embeddings, and vector stores, and is popular for building full agent applications, not just retrieval. LlamaIndex is more focused, built specifically around indexing and querying private data. RAGFlow and Haystack are two more actively used options, each with a large open source following. None of these frameworks define a shared, standard file format for the knowledge they index. Each project tends to bring its own loaders, its own chunking defaults, and its own document objects.
OKF as a shared format across open source tools
This is exactly the gap OKF targets. A LangChain pipeline, a LlamaIndex pipeline, and a completely different tool can all point at the same OKF bundle and load it with their own existing markdown loaders, since OKF adds nothing beyond markdown and YAML frontmatter on top of the file. Because an OKF bundle is just files in a folder, it fits naturally into a git repository, which means it gets version history, pull request review, and diffing for free, the same way source code does. A team using LlamaIndex for retrieval today could adopt OKF purely as the way source documents are organized, without changing their retrieval framework at all, since OKF sits underneath the framework rather than replacing it.
Because OKF is brand new, most open source RAG frameworks have no dedicated OKF loader yet. Treat it, for now, as a well organized markdown source you point your existing loader at, not as a framework feature you can turn on with a flag.
When to use RAG, OKF, or both
Use RAG alone when your knowledge is large, unstructured, and changes constantly, like a support ticket archive or a growing collection of PDFs, and no one is going to hand curate it into a clean format.
Use OKF alone, without a full RAG pipeline, when your knowledge base is small enough to fit in a model's context window, and you mainly need it well organized and version controlled rather than searched at scale.
Use both together for the common middle case, a knowledge base that is curated and structured, like table schemas, runbooks, or internal policies, but too large or too fast changing to paste into every prompt. Store the source material as an OKF bundle for portability and version control, then run a RAG pipeline, whether that is Anthropic's contextual retrieval, OpenAI's File Search, or an open source framework, on top of that bundle to actually serve answers.
Common mistakes to avoid
Do not treat OKF as a search engine. It has no query layer of its own, so an OKF bundle by itself will not answer a question, it only organizes the material that a separate retrieval step will search.
Do not assume every ecosystem already supports OKF out of the box. As of this writing, only Google Cloud has shipped first-class tooling. Claude, OpenAI, and most open source frameworks can consume OKF files as plain markdown, but none of them have announced dedicated OKF integrations yet.
Do not skip contextual chunking when you build RAG on top of curated documents. A well organized OKF bundle still loses meaning if a chunking step slices a table away from the heading that explains it, so pair a good source format with a chunking approach that keeps context intact.
Do not treat OKF version 0.1 as a stable, unchanging standard. Google Cloud has called it explicitly a starting point, so expect the spec to keep evolving.
Frequently asked questions
Is OKF a replacement for RAG?
No. Google Cloud has stated directly that OKF is not a replacement for RAG. It is a format for organizing the knowledge that a RAG pipeline, or another method, later retrieves.
Who created OKF?
Google Cloud announced OKF on June 12, 2026, through its Data Analytics and BigQuery engineering team. The specification, reference tools, and sample bundles are public on GitHub.
Does Claude or OpenAI support OKF natively?
Not as of this writing. Both can read an OKF bundle as plain markdown files, since neither format requires special tooling to parse, but neither vendor has announced dedicated OKF support.
Can I use OKF with LangChain or LlamaIndex today?
Yes, through each framework's existing markdown and YAML loaders. There is no dedicated OKF loader yet, since the specification is only a few months old.
