OpenKB Review: Is a Knowledge Compiler Better Than RAG?

OpenKB is one of the clearest working implementations of the LLM knowledge-compiler idea, but it is not a drop-in replacement for enterprise RAG. It reads source material, writes summaries and concept pages, updates cross-references, then lets an agent query the accumulated wiki. That changes the unit of work from “find chunks for this question” to “maintain a reusable body of knowledge.”

The pattern came from Andrej Karpathy's April 2026 LLM Wiki idea file. The commercial question is no longer whether the idea sounds good. It is whether OpenKB gives a team better verified answers than vector RAG after build cost, information loss, permissions and maintenance enter the picture.

Our verdict after reviewing the project and current research on 11 August 2026: pilot OpenKB for curated, synthesis-heavy knowledge work; keep vector RAG or a hybrid for large, fast-changing or permission-sensitive corpora. This page owns the product-specific “OpenKB review” and “OpenKB vs RAG” intent. Our separate Open Knowledge Format enterprise guide owns the portable format, while the RAG production-readiness checklist owns retrieval, permissions and answer controls.

What is OpenKB?

OpenKB is an open-source Python CLI and web workbench that compiles files and URLs into a persistent, interlinked Markdown wiki. The official OpenKB repository documents PDF, Word, PowerPoint, Excel, HTML, CSV, text, Markdown and URL input. The compilation pass creates or updates source summaries, concepts, entities, an index and a log. Query, chat, visualization, slide and agent-skill generators then consume that wiki.

Short documents are converted with MarkItDown and read as text. For long PDFs, OpenKB relies on PageIndex's vectorless tree-index approach: it builds a table-of-contents-like hierarchy and asks an LLM to navigate relevant sections. “No vector database” therefore does not mean “no retrieval.” It means retrieval uses document structure and reasoning instead of embedding similarity.

How does a knowledge compiler differ from vector RAG?

Vector RAG usually stores chunks and embeddings, retrieves a top-k set for each question, then assembles an answer. OpenKB performs more synthesis during ingestion. A new document can rewrite several concept pages before any user asks a question.

The useful comparison is not “old RAG versus new magic.” OpenKB itself combines a compiled wiki with reasoning-based retrieval. A mature system can also retrieve over the compiled pages, raw sources or both. The architecture is a spectrum: raw chunk retrieval, hierarchical retrieval, compiled summaries, explicit graphs and cached full context can coexist.

Is OpenKB free, and what does it really cost?

The software uses Apache 2.0, so there is no OpenKB licence fee for commercial use. The current PyPI package record listed version 0.4.4, released 10 July 2026, and classified the project as alpha when we checked. That is a maturity signal, not a criticism. It tells procurement to pin versions, test upgrades and budget ownership around a fast-moving dependency.

Total cost has at least six parts:

1. Compilation tokens. Every source can trigger summary, concept, entity and cross-reference work. A single ingest may update many pages.
2. Retrieval and answer tokens. Query cost remains. Vectorless does not mean model-free or zero-token.
3. Document processing. Local parsing covers common inputs; complex OCR and optional PageIndex Cloud introduce another provider and cost path.
4. Human review. Someone must inspect factual compression, contradictions, citations and sensitive output.
5. Enterprise controls. SSO, role-based access, tenant boundaries, audit, secrets, backups and deletion are product work.
6. Evaluation and operations. Golden questions, source-diff regression tests, latency, retries, model changes and incident handling need continued ownership.

The right cost unit is not “price per embedded page.” Measure cost per accepted, source-backed answer or completed research task. Include compilation, query, retries and reviewer minutes. Our AI agent cost-per-action framework gives that denominator.

Does compiled knowledge beat RAG in independent research?

No architecture wins every knowledge task. The most useful recent evidence is a preregistered comparison of vector RAG and an LLM-compiled wiki over 24 papers and 13 questions. The wiki was better at connecting findings across papers and its cited pages more often supported the exact claim. Vector RAG met the preregistered test for single-fact lookup and used far fewer query tokens. A decomposition-based RAG variant recovered most of the wiki's synthesis advantage at lower token cost, but not its claim-level citation advantage.

That study is deliberately small and used LLM judges rather than humans. It does not prove that OpenKB beats a production RAG stack. It does give CTOs a better evaluation model: score synthesis structure, exact claim support and total cost separately. A single “answer quality” average hides the trade-off you need to buy.

A second paper exposes the main failure mode. WiCER evaluated wiki-memory compilation across 6,800 questions. Blind compilation scored far below raw full context and showed a 53% to 60% catastrophic failure rate in the reported setup because it discarded critical facts. An iterative evaluate-and-refine loop recovered much of the lost quality. The lesson is direct: compilation needs diagnostic questions and repair passes, not a one-shot summary prompt.

What does Google OKF change for OpenKB?

Portability is one of the strongest parts of the approach. Google Cloud introduced the Open Knowledge Format v0.1 in June 2026. It standardizes a small interoperability surface around Markdown, YAML frontmatter, links, index files and logs. OpenKB says its wiki pages are OKF-ready.

That matters because a failed pilot can still leave readable, versioned artifacts. A team can inspect them in an editor, move them through Git or feed them to another search and agent system. It does not guarantee semantic correctness, perfect interoperability or continued conformance as the v0.1 format evolves. Validate the generated bundle in CI and keep raw sources separate from compiled pages.

Is OpenKB enterprise-ready?

OpenKB is ready for a controlled developer or research pilot. Its public control surface is not a complete enterprise knowledge platform. The current workbench and REST API make it easier to upload, compile, query, chat, lint and recompile. The documented authentication model remains intentionally local-first.

The official REST API guide says authentication is off by default and can be enabled with one bearer token. It explicitly warns that binding to a non-loopback host without that token leaves every reachable knowledge base open. A single shared token can protect a pilot endpoint. It is not the same as SSO, user identity, role-based access, document-level authorization or tenant isolation.

For sensitive company sources, retrieval-time authorization is the hard boundary. If a user may read one policy but not another, compiling both into the same concept page can leak restricted facts before the query layer even filters anything. Build permission-preserving compilation domains or keep those sources out of the compiler. Our permissions-first RAG architecture explains the same rule for SharePoint, Confluence and Drive.

When should you choose OpenKB, vector RAG or a hybrid?

Do not start with the technology. Start with a labelled question set. If most questions are “What is the current refund limit in policy X?”, retrieval and permissions dominate. If they are “How did our assumptions about market Y change across twelve reports?”, persistent synthesis becomes more valuable. If both matter, run both paths and route by question type.

A ten-day OpenKB pilot plan

1. Choose one owned domain. Use 20 to 50 approved sources with one accountable subject-matter owner. Do not begin with the whole company drive.
2. Preserve the evidence layer. Hash raw sources, record dates and keep compiled pages in a separate directory. Never let the wiki silently replace originals.
3. Create 30 blind questions. Include single facts, multi-source synthesis, contradictions, missing answers, permission traps and recently changed facts.
4. Freeze three baselines. Compare current search or manual work, a simple vector RAG implementation and OpenKB on the same sources and model budget.
5. Score claim support. Review whether each important sentence is supported by the cited source, not only whether the answer sounds complete.
6. Test information loss. Recompile after adding a contradictory or updated source. Check what changed, what vanished and whether the old claim remains reachable.
7. Attack the boundary. Test prompt injection inside a document, unauthorised source mixing, malicious links, huge files, parser failures and a model-provider outage.
8. Price the full loop. Count ingest and query tokens, p50 and p95 latency, retries, review minutes, wrong answers and recovery work.
9. Set a scale gate. Proceed only if verified answer quality or reviewer time improves enough to fund permissions, operations and maintenance.
10. Keep the exit reversible. Export the wiki, schema, evaluation set and source manifest so another system can consume them.

Wavect's AI enablement service can build this comparison on your infrastructure instead of declaring a winner from a demo. The Twinsoft AI case study shows our approach to traceable AI output and reviewer control. For the commercial model, compare AI enablement with generic AI consulting before deciding whether you need implementation or a strategy document.

Research boundary

Status checked 11 August 2026. This is an independent architecture and buyer review based on public project documentation and research, not a sponsored post, a penetration test or a hands-on benchmark of a private corpus. OpenKB, its package, API and roadmap can change quickly. Pin the version and verify current documentation before procurement.