What a test with Google's Open Knowledge Format taught us

RAG without a vector database: AI on your own knowledge base

An AI assistant that answers questions from your own documentation — it's the use case almost every organisation thinks of first. The standard technique for it is called RAG: retrieval-augmented generation. With every question, the language model is handed the relevant pieces from your knowledge base and bases its answer on those, instead of on whatever it once read on the internet.

The usual recipe for RAG starts with a vector database. We built a test setup on our own internal knowledge base in Confluence — and deliberately left the vector database out. Instead we followed a young specification from Google: the Open Knowledge Format (OKF). That produced insights worth sharing.

How RAG normally works — and where it pinches

The classic recipe: cut all documents into pieces ("chunks"), compute a mathematical fingerprint for each piece (an embedding), store those in a vector database and, for every question, look for the pieces that resemble it most. That works, but it brings hassle. You need an extra database that has to stay in sync with the source: when a page changes, the embeddings must be redone. The chunking destroys structure — tables and step-by-step guides, often the most valuable part of a knowledge base, survive chunking poorly. And when an answer is off, it's hard to explain why the retrieval step chose these pieces: similarity is a number, not a line of reasoning.

The idea behind OKF: knowledge as plain files

The Open Knowledge Format turns that around. Knowledge is a folder of markdown files: one file per topic, with a small block of metadata at the top — title, summary, labels and a link to the original source. References between topics are ordinary links between files, and index files per level provide the structure: from the overview through a subject area down to the individual page. Documents stay whole; nothing is cut up.

An update is overwriting a file. Version control is git. There is no database to keep in sync, because there is no database.

Our test: Confluence as the source

Our test setup automatically exports Confluence spaces to such an OKF bundle: every page becomes one markdown file with title, summary, labels and a link back to the source page. Search is done with a proven, deterministic text-search technique in which title and labels weigh more than body text, and compound words also match partially — searching for "invoice" also finds the page about the "invoice address". From the best-scoring pages, the linked pages travel along one step as extra context. The language model then formulates the answer and lists the source pages, so you can always click through to the original Confluence page to verify.

A set of automated tests guards the bundle: every file has the required metadata, every internal link points to an existing file and every page keeps a link to its source.

What stood out to us

How far you get without a vector database surprised us. For a knowledge base with clear domain terms — and internal knowledge bases almost always have them — deterministic search finds the right pages reliably. It is also explainable: the same question yields the same documents, and you can see exactly why a page scored. The whole thing can be managed the way we manage software: changes show up as a diff, and the knowledge base simply travels along in version control.

Fair is fair: embeddings can do something text search cannot. Someone who asks in very different words than the documentation uses is sometimes understood better by a vector database. For the knowledge bases we encounter, that rarely outweighs the simplicity — but it remains a case-by-case trade-off, not a dogma.

What this means for your organisation

If your knowledge lives in Confluence, SharePoint or a folder of manuals, an AI assistant on your own documentation is closer than often thought — without heavy extra infrastructure. Importantly: the searching happens within your own environment, only the pages relevant to the question go to the language model as context, and every answer cites its source. No off-the-cuff answers, but verifiable answers from your own knowledge.

Curious what this could mean for your knowledge base? Let us know via the form below, call +31 10 270 75 75 or email hallo@admix.nl. Already working with us? Then support works too.

Contactgegevens

Adres

Get in touch

Postbus

Curious what this means for your site? Leave your details and briefly describe what you're running into, and we'll get back to you. We usually respond within one business day.

 

Prefer direct contact? Feel free to call or email us.

Frequently asked questions about RAG and the Open Knowledge Format

RAG is the technique in which a language model is first handed the relevant pieces from your own documentation with every question, and bases its answer on those. That way the AI answers with your information instead of with whatever the model once read on the internet — and every answer can cite a source.

No. A vector database is the common approach, but not a requirement. Google's Open Knowledge Format shows that a knowledge base can also be a folder of markdown files, searched with deterministic text-search techniques. For knowledge bases with clear domain terms that works reliably and is easier to manage; embeddings remain useful when synonyms and free-form questions weigh heavily.

Yes. Our test setup automatically exports Confluence pages to the Open Knowledge Format, including metadata, labels and internal links. The same approach works for any source that can be read via an API, such as SharePoint or a documentation site.

Searching the knowledge base happens within your own environment. Only the pages relevant to a concrete question go to the language model as context, and every answer references the source page so it remains verifiable.