In 2026, Google introduced the Open Knowledge Format (OKF), an open specification for representing knowledge in a portable, human- and agent-friendly format. At first glance, OKF and RAG may seem like competing approaches. They aren't quite the same thing.

RAG is primarily about retrieving relevant information for an LLM. OKF is about representing and organizing knowledge so that people and AI systems can consume it.

This article breaks down both approaches, explains how they differ, and shows how they can fit together in an AI knowledge pipeline.

What is RAG?

RAG stands for Retrieval-Augmented Generation.

The basic idea is simple: instead of asking an LLM to answer a question using only the information encoded in its parameters, a RAG system first retrieves relevant information from an external knowledge source and supplies that information as context to the model.

A simplified RAG pipeline looks like this:

User Question → Retrieve Relevant Information → Add Context → LLM → Answer

This approach is useful when an application needs to answer questions using information that may not be part of the model's original training data or that changes over time.

The original RAG research paper, published in 2020, described combining a pretrained generator with an external memory accessed through retrieval. Modern RAG systems can use techniques such as embeddings, vector search, keyword search, hybrid retrieval, and reranking depending on the application.

How Does RAG Actually Work?

A RAG system typically has two major phases: retrieval and generation. Before users ask questions, the source knowledge is usually prepared and indexed so that relevant information can be found efficiently. At query time, the system retrieves information related to the user's question, adds that information to the prompt, and sends the augmented prompt to the LLM.

A simplified RAG pipeline looks like this:

1. Prepare the knowledge

The first step is to make the external information searchable. Documents can be split into smaller sections, converted into numerical embeddings, and stored in an index or vector database.

An embedding represents text as a vector—a list of numbers that captures aspects of its semantic meaning. Texts with similar meanings tend to have vectors that are closer together in the embedding space.

For example:

"How long can I request a refund?"
                ↓
          Embedding Model
                ↓
      [0.12, -0.04, 0.83, ...]

2. Retrieve relevant information

When a user asks a question, the question is also converted into an embedding.

The retrieval system then searches for knowledge that is most relevant to that query. Modern RAG systems can use vector/semantic search, keyword search, hybrid search, and reranking depending on the design.

For example:

User:
"What is the refund policy?"

            ↓

        Retriever

            ↓

     refund-policy.md
       support.md

The goal isn't to retrieve everything. It is to retrieve the most useful context for answering the question.

3. Augment the prompt

The retrieved information is then added to the user's original question.

Conceptually:

Original Question
       +
Retrieved Context
       ↓
Augmented Prompt

For example:

Context:
Customers can request a refund within
14 calendar days of the original purchase.

Question:
How long do customers have to request a refund?

The LLM now has relevant external context available while generating its response.

4. Generate the answer

Finally, the augmented prompt is sent to the language model.

        Augmented Prompt
               ↓
              LLM
               ↓
   "Customers can request a refund
     within 14 calendar days."

This is the generation part of Retrieval-Augmented Generation.

The important idea is that the LLM isn't being asked to rely only on what it learned during training. The application supplies relevant information at query time.

A key point: Retrieval quality matters

A RAG system is only as useful as the information it retrieves.

If the retriever finds irrelevant or incomplete context, the LLM can still produce an answer that is grounded in the wrong information. Retrieval quality and knowledge-base curation as critical parts of RAG performance.

So a useful mental model is:

        Good Knowledge
              +
        Good Retrieval
              +
        Good Generation
              ↓
    Better Grounded Response

What Is Google Open Knowledge Format (OKF)?

As AI systems become more capable, having access to data alone is often not enough. AI agents also need context around that data—such as definitions, metadata, business rules, processes, and other curated knowledge.

In June 2026, Google introduced the Open Knowledge Format (OKF), an open specification designed to represent this kind of knowledge in a format that can be read by both humans and AI systems. Google describes OKF as vendor-neutral and intended to make knowledge portable across tools, organizations, and agents.

The specification discussed in this article is OKF v0.2. It deliberately keeps the format simple: a knowledge bundle is primarily a collection of Markdown files with YAML frontmatter. It does not require a particular database, model provider, agent framework, or runtime.

At a high level:

OKF = Knowledge representation

RAG = Knowledge retrieval + generation

That difference is the key to understanding why OKF and RAG are not simply competing technologies.

What Does an OKF Document Look Like?

An OKF concept is represented as a Markdown file with two main parts:

1. YAML frontmatter containing structured metadata

2. Markdown body containing the actual knowledge

The typefield is the only always-required frontmatter field. Fields such as title, description, resource, and tags are recommended but optional.

For example:

---
type: Policy
title: Refund Policy
description: Rules governing customer refunds.
tags: [refund, billing, policy]
---

# Refund Policy

Customers can request a refund within 14 calendar days
of the original purchase.

Approved refunds are generally processed within
5 business days.

This may look like an ordinary Markdown document with a little extra metadata—and that's intentional.

The format is designed to remain human-readable without requiring specialized software, while the structured frontmatter gives agents and other software useful information to work with.

What Is an OKF Knowledge Bundle?

A collection of related OKF concept documents forms a knowledge bundle, which is the unit used to distribute the knowledge.

A simple bundle might look like:

acme-knowledge/
│
├── index.md
├── company.md
├── products.md
├── pricing.md
├── support.md
└── refund-policy.md

Each concept can describe something different:

company.md  → Company information

products.md → Product knowledge

pricing.md  → Pricing definitions
 
support.md  → Support rules

refund-policy.md → Refund policy

OKF also supports links between concepts, allowing relationships within a knowledge bundle to be represented using familiar Markdown links.

Why Does the Metadata Matter?

Consider these two files.

Plain Markdown

# Refund Policy

Customers can request a refund within 14 calendar days
of the original purchase.

OKF

---
type: Policy
title: Refund Policy
description: Rules governing customer refunds.
tags: [refund, billing, policy]
---

# Refund Policy

Customers can request a refund within 14 calendar days
of the original purchase.

The underlying information can be the same.

The OKF version additionally tells a consuming system:

What is this?
→ Policy

What is it called?
→ Refund Policy

What is it about?
→ Customer refunds

How can it be categorized?
→ refund, billing, policy

This makes the knowledge self-describing in a way that a simple block of unstructured text is not.

The OKF specification explicitly notes that the description field can be used for generated indexes, search snippets, and previews, while type can support routing, filtering, and presentation.

OKF Is Intentionally Minimal

One of the more interesting design choices in OKF is what it doesn't try to standardize. The specification does not prescribe:

• a particular database

• a specific vector store

• a serving architecture

• a particular LLM

• a specific agent framework

• a required SDK

Instead, it defines a small set of conventions for representing knowledge and leaves the runtime choices to the systems consuming that knowledge.

That means the same OKF bundle could potentially be consumed by different kinds of systems:

                    OKF Knowledge
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
        Human          Search        AI Agent
          │              │              │
       Markdown     Index/Search     LLM/Tools

The official OKF repository lists static file servers, knowledge-management interfaces, LLMs, search indexes, and graph viewers among possible consumers.

Why Is OKF Interesting for AI Agents?

This becomes especially important when knowledge is continuously created or maintained by agents.

OKF v0.2 introduces first-class mechanisms related to provenance, verification, trust, lifecycle, and attested computation. These additions are intended to help consumers understand where knowledge came from, how it was verified, whether it is current, and—where applicable—how a computation was produced.

This leads to a useful shift in thinking:

Traditional knowledge
        ↓
"Here is some information."


Agent-maintained knowledge
        ↓
"Where did this come from?"
"Was it verified?"
"How current is it?"
"Can I trust this context?"

These questions become increasingly relevant as AI agents move from simply reading knowledge to also creating and updating it.

OKF vs RAG: What’s the Difference?

At this point, the distinction between OKF and RAG should be clearer.

OKF and RAG are not direct alternatives. They operate at different layers of an AI knowledge system.

OKF focuses on how knowledge is represented, organized, described, and exchanged.

RAG focuses on how relevant information is retrieved and provided to a language model when answering a question.

A simple way to think about it is:

OKF → How should knowledge be represented?

RAG → How should relevant knowledge be retrieved and used?

The official OKF specification describes OKF as a format for representing knowledge, while deliberately leaving storage, serving, and query infrastructure outside the specification.

RAG, on the other hand, is an application architecture in which relevant external information is retrieved and supplied to a generative model as context.

The Core Difference

Imagine that a company has this knowledge:

Refund Policy
Product Information
Pricing
Customer Support Rules
Company Information

With OKF, the focus is on turning that knowledge into a structured, portable collection of concepts:

knowledge/
│
├── index.md
├── company.md
├── products.md
├── pricing.md
├── support.md
└── refund-policy.md

Each concept can contain structured metadata and human-readable content.

With RAG, the focus is different.

A user asks:

"How long do I have to request a refund?"

The RAG system needs to find the most relevant information—perhaps refund-policy.md—and provide that information to the LLM as context.

So:

OKF
Knowledge → Structure → Describe → Organize

RAG
Question → Retrieve → Context → Generate

OKF and RAG Solve Different Problems

A useful way to understand the difference is to look at the questions each technology answers.

The important point is that OKF does not replace the retrieval or generation components of a RAG system. Likewise, RAG does not define a standard format for representing the underlying knowledge corpus.

OKF's specification intentionally avoids prescribing a particular storage, serving, query infrastructure, or runtime.

Think of Them as Different Layers

Instead of thinking:

OKF vs RAG

it can be more useful to think:

        ┌─────────────────────────────────┐
        │          AI APPLICATION         │
        │                                 │
        │          LLM / AI Agent         │
        └────────────────┬────────────────┘
                         │
                         ↓
        ┌─────────────────────────────────┐
        │              RAG                │
        │                                 │
        │ Retrieve relevant knowledge     │
        │ Build context                   │
        │ Generate response               │
        └────────────────┬────────────────┘
                         │
                         ↓
        ┌─────────────────────────────────┐
        │              OKF                │
        │                                 │
        │ Structured knowledge            │
        │ Metadata                        │
        │ Concepts & relationships        │
        │ Provenance / lifecycle signals  │
        └─────────────────────────────────┘

This is where the relationship becomes interesting.

OKF can provide a structured knowledge source that a RAG system can retrieve from.

Can OKF and RAG Work Together?

Yes. This is where the two approaches become complementary rather than competitive.

An OKF knowledge bundle can act as one possible knowledge source for a retrieval system.

For example:

                 OKF Knowledge Bundle
                         │
          ┌──────────────┼──────────────┐
          ↓              ↓              ↓
      company.md     pricing.md   refund-policy.md
          │              │              │
          └──────────────┼──────────────┘
                         ↓
                   RAG Retriever
                         ↓
                  Relevant Context
                         ↓
                  Augmented Prompt
                         ↓
                        LLM
                         ↓
                       Answer

The roles are therefore different:

OKF organizes the knowledge.

RAG retrieves the knowledge.

The LLM generates the response.

This separation can be useful for AI systems because the knowledge representation can remain relatively independent from the model or retrieval implementation.

The official OKF project explicitly describes possible consumers including search indexes, LLM applications, knowledge-management interfaces, static file servers, and graph viewers.

A Simple Real-World Example

Suppose a customer asks:

"How long does an approved refund take to process?"

Our OKF knowledge bundle contains:

refund-policy.md

with information such as:

Approved refunds are generally processed
within 5 business days.

A RAG system can retrieve that concept based on the user's question.

The process becomes:

This is the key relationship between the two technologies.

How OKF and RAG Can Work Together

OKF and RAG are not technologies that have to be chosen over one another.

In fact, they can complement each other very well.

OKF can provide the structured knowledge layer, while RAG can provide the retrieval and generation layer.

A simple architecture looks like this:

OKF Knowledge Bundle
        ↓
Structured Knowledge
        ↓
Indexer / Retriever
        ↓
Relevant Context
        ↓
Augmented Prompt
        ↓
       LLM
        ↓
Grounded Answer

The idea is straightforward:

OKF organizes the knowledge.
RAG retrieves the relevant knowledge.
The LLM uses that context to generate the response.

For example,

imagine an AI assistant connected to a company's OKF knowledge bundle.

The bundle might contain:

acme-knowledge/
├── company.md
├── products.md
├── pricing.md
├── support.md
└── refund-policy.md

A customer asks:

"How long does an approved refund take to process?"

The RAG system searches the available knowledge and identifies refund-policy.md as the most relevant document.

It then retrieves the relevant information:

"Approved refunds are generally processed within 5 business days."

That information is added to the prompt as context and passed to the LLM.

The LLM can then generate a grounded response such as:

"Approved refunds are generally processed within 5 business days."

This separation of responsibilities is useful because the knowledge representation and the AI application are not tightly coupled.

The knowledge can remain organized in a portable format, while different applications can use the same knowledge through their own retrieval, search, agent, or AI pipelines.

The relationship can be summarized as:

OKF → Represents knowledge

RAG → Retrieves relevant knowledge

LLM → Generates the response

The important point is that OKF does not replace RAG, and RAG does not replace OKF.

They solve different problems at different layers of an AI knowledge system.

Practical Experiment: Plain Markdown vs OKF

To understand the difference between knowledge representation and retrieval in practice, I built a small local experiment using the same knowledge base in two different formats.

The goal was simple:

Does structuring the same knowledge as OKF change how a RAG system retrieves information?

Instead of comparing different models or different retrieval systems, I kept the RAG pipeline as consistent as possible and changed only the knowledge representation.

Experiment Setup

I created a fictional knowledge base for a company called Acme AI Solutions. The knowledge base contains information about:

• Company details

• Products

• Pricing

• Customer support

• Refund policies

I created two versions of the same knowledge:

knowledge/
│
├── okf/
│   ├── company.md
│   ├── index.md
│   ├── pricing.md
│   ├── products.md
│   ├── refund-policy.md
│   └── support.md
│
└── plain/
    ├── company.md
    ├── index.md
    ├── pricing.md
    ├── products.md
    ├── refund-policy.md
    └── support.md

The plain version contains ordinary Markdown files.

The OKF version uses Markdown together with YAML frontmatter to provide structured metadata.

For example, an OKF document can look like this:

---
type: Policy
title: Refund Policy
description: Rules governing customer refunds.
tags: [refund, billing, policy]
---

# Refund Policy

Customers can request a refund within 14 calendar days
of the original purchase.

Approved refunds are generally processed within
5 business days.

The actual knowledge is essentially the same. The important difference is that the OKF version explicitly describes the document using metadata such as its type, title, description, and tags.

The RAG Pipeline

For the experiment, I used a local RAG pipeline with:

• Python 3.11

• Ollama

• EmbeddingGemma for embeddings

• Qwen3 4B for answer generation

• Markdown files as the knowledge source

The pipeline follows this basic flow:

        Knowledge Files
               ↓
        Document Loading
               ↓
          Embeddings
               ↓
       Similarity Search
               ↓
       Relevant Documents
               ↓
              LLM
               ↓
             Answer

I ran the same queries against both the plain Markdown and OKF knowledge bases.

This makes the experiment useful for observing whether the structured representation affects retrieval behavior.

Example Query

One of the questions I tested was:

"How long do customers have to request a refund?"

For the plain Markdown knowledge base, the most relevant result was:

refund-policy.md
Similarity: 0.6258

For the OKF knowledge base:

refund-policy.md
Similarity: 0.6539

In both cases, the system correctly identified refund-policy.md as the most relevant document.

The generated answer was:

"Customers can request a refund within 14 calendar days."

The OKF representation produced a slightly higher similarity score in this particular example.

However, one example alone is not enough to conclude that OKF always produces better retrieval.

Retrieval Evaluation

To make the comparison more meaningful, I evaluated both knowledge bases using a set of test questions. The evaluation contained 14 questions:

• 12 questions had answers available in the knowledge base.

• 2 questions intentionally asked for information that was not present.

The results were:

Both approaches successfully retrieved the relevant documents for all 12 answerable questions.

For the two questions where the information did not exist in the knowledge base, the system correctly indicated that there was not enough information rather than inventing an answer.

This is an important observation.

OKF did not magically make the RAG system better.

Instead, the experiment demonstrates something more subtle:

OKF and RAG operate at different layers.

The OKF representation gives the knowledge a consistent structure and additional metadata, while the RAG pipeline is responsible for finding relevant information and providing it to the LLM.

What Did the Experiment Show?

The experiment produced three useful observations.

1. Both formats can work with RAG

A RAG system does not require OKF. Ordinary Markdown documents can also be indexed, embedded, retrieved, and passed to an LLM.

2. Structured knowledge can provide additional context

The OKF version adds explicit metadata around the knowledge.

Instead of having only:

Refund Policy

the system can also see structured information such as:

type: Policy
title: Refund Policy
tags: [refund, billing, policy]

This can become useful for systems that want to filter, classify, navigate, or reason about knowledge beyond simple text similarity.

3. This experiment does not prove OKF improves retrieval

The benchmark was intentionally small and used a synthetic knowledge base.

Both versions achieved a 100% retrieval hit rate, so the experiment does not demonstrate a universal retrieval advantage for OKF.

Instead, it demonstrates the architectural relationship:

OKF → Structured / portable knowledge

RAG → Retrieval + context construction

LLM → Answer generation

That distinction is more important than simply asking which one is "better."

The Bigger Picture

The interesting possibility is to use the two technologies together.

An organization could maintain its knowledge as structured OKF bundles while different AI applications build their own retrieval pipelines on top of that knowledge.

For example:

                 OKF Knowledge
                      │
        ┌─────────────┼─────────────┐
        ↓             ↓             ↓
       RAG          Search       AI Agent
        │             │             │
        ↓             ↓             ↓
       LLM        Knowledge UI  Agent Tools

The knowledge representation remains separate from the application that consumes it.

That separation is one of the most interesting ideas behind combining OKF and RAG.

Experiment takeaway

RAG can work with ordinary Markdown, but OKF provides a structured and portable way to represent the knowledge that RAG and other AI systems can consume.

This is why I see OKF and RAG less as competing technologies and more as different pieces of an AI knowledge architecture.

Conclusion

OKF and RAG solve different problems, but they can work together as complementary parts of an AI knowledge architecture.

OKF focuses on how knowledge is represented. It provides a structured, portable way to organize information using Markdown, metadata, and knowledge relationships.

RAG focuses on how knowledge is retrieved and used. It finds relevant information and provides that context to an LLM so the model can generate a more grounded response.

The practical experiment in this article also showed that OKF does not automatically make a RAG system more accurate. In our small test, both the plain Markdown and OKF knowledge bases achieved the same retrieval hit rate. The value of OKF is therefore not simply "better embeddings" or "better retrieval."

Its value is in providing a consistent and portable representation of knowledge that different systems can consume.

This separation can become especially useful as AI applications evolve from simple chatbots into more capable AI agents. Instead of keeping knowledge tightly coupled to one application, organization, or retrieval system, a structured knowledge layer can potentially be reused across different tools and AI workflows.

So, the question is not:

OKF or RAG?

A better question is:

How can structured knowledge such as OKF become the foundation that RAG, search systems, and AI agents consume?

That is where the combination becomes interesting.

OKF describes the knowledge.
RAG finds the knowledge.
LLMs use that knowledge to generate answers.

And together, they form a more modular approach to building AI systems that can work with external knowledge.

References

1. Google Cloud Platform — Open Knowledge Format (OKF) Specification v0.2
   Official specification covering the OKF structure, metadata, knowledge bundles, versioning, provenance, trust, and lifecycle.
   Read the OKF v0.2 Specification

2. Google Cloud Platform — Open Knowledge Format (OKF)
   Official OKF repository and overview of the vendor-neutral Markdown + YAML approach.
   Open Knowledge Format Repository

3. Google Cloud Blog — OKF v0.2 Adds Trust Signals
   Announcement and explanation of OKF v0.2, including provenance, trust, lifecycle, and attestation.
   Read the Google Cloud article

4. Lewis et al. — Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks
   The original research paper introducing the RAG approach.
   Read the RAG paper