OpenKB Review: Ist ein Knowledge Compiler besser als RAG?

OpenKB ist eine der klarsten funktionierenden Umsetzungen der Idee eines LLM Knowledge Compilers, aber kein Drop-in-Ersatz für Enterprise RAG. Das Tool liest Quellen, schreibt Zusammenfassungen und Konzeptseiten, aktualisiert Querverweise und lässt anschließend einen Agenten das gewachsene Wiki abfragen. Die Arbeitseinheit verschiebt sich von „Finde Chunks für diese Frage“ zu „Pflege einen wiederverwendbaren Wissensbestand“.

Das Muster stammt aus Andrej Karpathys LLM-Wiki-Ideendatei vom April 2026. Die kommerzielle Frage ist nicht mehr, ob die Idee gut klingt. Entscheidend ist, ob OpenKB nach Build-Kosten, Informationsverlust, Berechtigungen und Wartung bessere verifizierte Antworten liefert als Vector RAG.

Unser Urteil nach Prüfung des Projekts und aktueller Forschung am 11. August 2026: Teste OpenKB für kuratierte, syntheseintensive Wissensarbeit; behalte Vector RAG oder einen hybriden Ansatz für große, schnell veränderliche oder berechtigungssensible Korpora. Diese Seite besitzt die produktspezifische Suchintention „OpenKB Review“ und „OpenKB vs. RAG“. Unser separater Enterprise Guide zum Open Knowledge Format besitzt das portable Format. Die RAG-Production-Readiness-Checkliste besitzt Retrieval, Berechtigungen und Antwortkontrollen.

Was ist OpenKB?

OpenKB ist eine Open-Source-Python-CLI mit Web Workbench, die Dateien und URLs in ein dauerhaftes, querverlinktes Markdown-Wiki kompiliert. Das offizielle OpenKB-Repository dokumentiert PDF, Word, PowerPoint, Excel, HTML, CSV, Text, Markdown und URLs als Eingaben. Der Kompilierungslauf erstellt oder aktualisiert Quellenzusammenfassungen, Konzepte, Entitäten, Index und Log. Generatoren für Query, Chat, Visualisierung, Slides und Agent Skills lesen anschließend dieses Wiki.

Kurze Dokumente werden mit MarkItDown konvertiert und als Text gelesen. Für lange PDFs nutzt OpenKB den vektorlosen Tree-Index-Ansatz von PageIndex: Ein Inhaltsverzeichnis ähnlicher Baum entsteht, und ein LLM navigiert zu relevanten Abschnitten. „Keine Vektordatenbank“ bedeutet daher nicht „kein Retrieval“. Die Suche nutzt Dokumentstruktur und Reasoning statt Embedding-Ähnlichkeit.

Wie unterscheidet sich ein Knowledge Compiler von Vector RAG?

Vector RAG speichert meist Chunks und Embeddings, holt pro Frage ein Top-k-Set und baut daraus eine Antwort. OpenKB verlagert mehr Synthese in den Ingest. Ein neues Dokument kann mehrere Konzeptseiten verändern, bevor jemand eine Frage stellt.

Der nützliche Vergleich lautet nicht „altes RAG gegen neue Magie“. OpenKB kombiniert selbst ein kompiliertes Wiki mit reasoning-basiertem Retrieval. Ein reifes System kann auch über kompilierte Seiten, Rohquellen oder beides suchen. Die Architektur ist ein Spektrum: Raw-Chunk-Retrieval, hierarchische Suche, kompilierte Zusammenfassungen, explizite Graphen und gecachter Vollkontext können nebeneinander bestehen.

Ist OpenKB kostenlos, und was kostet es wirklich?

Die Software steht unter Apache 2.0. Für kommerzielle Nutzung fällt daher keine OpenKB-Lizenzgebühr an. Der aktuelle PyPI-Paketeintrag nannte bei unserer Prüfung Version 0.4.4 vom 10. Juli 2026 und klassifizierte das Projekt als Alpha. Das ist ein Reifesignal, keine Abwertung. Procurement sollte Versionen pinnen, Upgrades testen und Ownership für eine schnell bewegte Dependency budgetieren.

Die Gesamtkosten haben mindestens sechs Teile:

1. Kompilierungs-Token. Jede Quelle kann Arbeit für Summary, Konzepte, Entitäten und Querverweise auslösen. Ein Ingest kann viele Seiten ändern.
2. Retrieval- und Antwort-Token. Query-Kosten bleiben. Vektorlos bedeutet weder modellfrei noch tokenfrei.
3. Dokumentenverarbeitung. Lokales Parsing deckt übliche Inputs ab; komplexes OCR und optional PageIndex Cloud schaffen einen weiteren Provider- und Kostenpfad.
4. Menschliche Prüfung. Jemand muss Faktenkompression, Widersprüche, Zitate und sensible Ausgaben prüfen.
5. Enterprise-Kontrollen. SSO, Rollen, Tenant-Grenzen, Audit, Secrets, Backups und Löschung sind Produktarbeit.
6. Evaluation und Betrieb. Golden Questions, Source-Diff-Regression, Latenz, Retries, Modellwechsel und Incidents brauchen dauerhaft Ownership.

Die richtige Kosteneinheit ist nicht „Preis pro eingebetteter Seite“. Miss Kosten pro akzeptierter, quellenbelegter Antwort oder abgeschlossener Recherche. Beziehe Kompilierung, Query, Retries und Review-Minuten ein. Unser Cost-per-Action-Modell für KI-Agenten liefert dafür den Nenner.

Schlägt kompiliertes Wissen RAG in unabhängiger Forschung?

Keine Architektur gewinnt jede Wissensaufgabe. Die nützlichste aktuelle Evidenz ist ein preregistrierter Vergleich von Vector RAG und einem LLM-kompilierten Wiki mit 24 Papers und 13 Fragen. Das Wiki verband Ergebnisse über mehrere Papers besser, und seine zitierten Seiten stützten häufiger die konkrete Aussage. Vector RAG bestand den preregistrierten Test für Einzelfakten und verbrauchte deutlich weniger Query-Token. Eine RAG-Variante mit Query-Zerlegung holte den Großteil des Synthesevorteils bei geringerem Token-Verbrauch auf, aber nicht den Vorteil bei Claim-Level-Zitaten.

Die Studie ist bewusst klein und nutzt LLM-Judges statt Menschen. Sie beweist nicht, dass OpenKB einen Production-RAG-Stack schlägt. Sie gibt CTOs aber ein besseres Evaluationsmodell: Bewerte Synthesestruktur, exakten Claim-Support und Gesamtkosten separat. Ein einzelner Durchschnitt für „Antwortqualität“ versteckt den Trade-off.

Ein zweites Paper zeigt den wichtigsten Failure Mode. WiCER evaluierte Wiki-Memory-Kompilierung über 6.800 Fragen. Blinde Kompilierung lag deutlich unter Raw Full Context und zeigte im berichteten Setup 53% bis 60% katastrophale Fehler, weil kritische Fakten verloren gingen. Eine iterative Evaluate-and-Refine-Schleife holte einen großen Teil der Qualität zurück. Die Konsequenz ist direkt: Kompilierung braucht diagnostische Fragen und Reparaturdurchläufe, keinen One-shot-Summary-Prompt.

Was ändert Google OKF für OpenKB?

Portabilität ist eine der stärksten Seiten des Ansatzes. Google Cloud stellte im Juni 2026 das Open Knowledge Format v0.1 vor. Es standardisiert eine kleine Interoperabilitätsfläche rund um Markdown, YAML-Frontmatter, Links, Indexdateien und Logs. OpenKB bezeichnet seine Wiki-Seiten als OKF-ready.

Das ist wichtig, weil auch ein gescheiterter Pilot lesbare, versionierte Artefakte hinterlassen kann. Ein Team kann sie in einem Editor prüfen, über Git bewegen oder an ein anderes Search- und Agentensystem geben. Es garantiert weder semantische Korrektheit noch perfekte Interoperabilität oder dauerhafte Konformität, wenn sich v0.1 weiterentwickelt. Validiere das Bundle in CI und halte Rohquellen von kompilierten Seiten getrennt.

Ist OpenKB enterprise-ready?

OpenKB ist bereit für einen kontrollierten Entwickler- oder Research-Pilot. Die öffentliche Kontrollfläche ist keine vollständige Enterprise-Wissensplattform. Workbench und REST API erleichtern Upload, Kompilierung, Query, Chat, Lint und Rekompilierung. Das dokumentierte Auth-Modell bleibt bewusst local-first.

Der offizielle REST-API-Guide sagt, dass Authentifizierung standardmäßig aus ist und mit einem einzelnen Bearer Token aktiviert werden kann. Er warnt ausdrücklich, dass ein Binding an einen Non-Loopback-Host ohne Token jede erreichbare Knowledge Base öffentlich lässt. Ein Shared Token kann einen Pilot-Endpunkt schützen. Er ist nicht dasselbe wie SSO, User Identity, rollenbasierter Zugriff, Dokumentberechtigungen oder Tenant-Isolation.

Bei sensiblen Unternehmensquellen ist Autorisierung zur Retrieval-Zeit die harte Grenze. Darf ein User eine Richtlinie lesen, eine andere aber nicht, kann die Kompilierung beider Quellen in dieselbe Konzeptseite eingeschränkte Fakten leaken, bevor die Query-Schicht filtert. Baue permission-erhaltende Kompilierungsdomänen oder halte diese Quellen aus dem Compiler. Unsere Permissions-first-RAG-Architektur erklärt dieselbe Regel für SharePoint, Confluence und Drive.

Wann solltest du OpenKB, Vector RAG oder einen Hybrid wählen?

Starte nicht mit der Technologie, sondern mit einem gelabelten Fragenset. Geht es meist um „Wie hoch ist das aktuelle Refund-Limit in Richtlinie X?“, dominieren Retrieval und Berechtigungen. Geht es um „Wie haben sich unsere Annahmen zu Markt Y über zwölf Reports verändert?“, wird dauerhafte Synthese wertvoller. Wenn beides zählt, betreibe beide Pfade und route nach Fragetyp.

Ein zehntägiger OpenKB-Pilot

1. Wähle eine verantwortete Domäne. Nutze 20 bis 50 freigegebene Quellen und einen accountable Fachexperten. Beginne nicht mit dem gesamten Company Drive.
2. Bewahre die Evidenzschicht. Hash Rohquellen, speichere Datum und halte kompilierte Seiten in einem eigenen Verzeichnis. Das Wiki darf Originals nie still ersetzen.
3. Erstelle 30 Blindfragen. Decke Einzelfakten, Synthese, Widersprüche, fehlende Antworten, Berechtigungsfallen und geänderte Fakten ab.
4. Friere drei Baselines ein. Vergleiche aktuelle Suche oder manuelle Arbeit, simples Vector RAG und OpenKB auf denselben Quellen und im selben Modellbudget.
5. Bewerte Claim-Support. Prüfe, ob jeder wichtige Satz von der zitierten Quelle gestützt wird, nicht nur ob die Antwort vollständig klingt.
6. Teste Informationsverlust. Rekompiliere nach einer widersprechenden oder aktualisierten Quelle. Prüfe, was sich ändert, verschwindet und weiter auffindbar bleibt.
7. Greife die Grenze an. Teste Prompt Injection im Dokument, unberechtigte Quellenmischung, bösartige Links, große Dateien, Parserfehler und Provider-Ausfall.
8. Bepreise den ganzen Loop. Zähle Ingest- und Query-Token, p50 und p95, Retries, Review-Minuten, falsche Antworten und Recovery.
9. Setze ein Scale Gate. Gehe nur weiter, wenn verifizierte Antwortqualität oder Reviewer-Zeit genug steigt, um Controls und Betrieb zu finanzieren.
10. Halte den Exit reversibel. Exportiere Wiki, Schema, Evaluation-Set und Source Manifest für ein Folgesystem.

Wavects AI-Enablement-Service kann diesen Vergleich auf deiner Infrastruktur bauen, statt aus einer Demo einen Gewinner auszurufen. Die Twinsoft-AI-Fallstudie zeigt unseren Ansatz für nachvollziehbare AI-Ausgaben und Reviewer-Kontrolle. Vergleiche für das kommerzielle Modell AI Enablement mit generischem AI Consulting, bevor du zwischen Umsetzung und Strategiepapier wählst.

Research Boundary

Status geprüft am 11. August 2026. Das ist ein unabhängiger Architektur- und Buyer-Review auf Basis öffentlicher Projektdokumentation und Forschung, kein gesponserter Beitrag, Penetrationstest oder Hands-on-Benchmark eines privaten Korpus. OpenKB, Paket, API und Roadmap können sich schnell ändern. Pinne die Version und prüfe aktuelle Dokumentation vor der Beschaffung.