Open Knowledge Format

Der Newsletter für technische Entscheider, Business-Strategen und KI-Interessierte.

Heute auf der Setlist: Was eine selbstbeschreibende Wissensschicht für RAG-Systeme wirklich leistet, und wo ihre Grenzen liegen.

🎚️ Soundcheck

In vielen RAG-Projekten taucht dieselbe Hoffnung auf: ein Format oder eine Struktur, die Halluzinationen verschwinden lässt. Aktuell richtet sich diese Hoffnung oft auf eine selbstbeschreibende Wissensschicht über den eigentlichen Dokumenten, wie sie das neue Open Knowledge Format (OKF) beschreibt.

Das Konzept ist stark genug, um es ernst zu nehmen, ein Allheilmittel ist es aber nicht. Diese Ausgabe ordnet ein: was ist OKF, wo sitzt es in der RAG-Pipeline und wo liegt der Nutzen tatsächlich.

🎤 Main Set: Was OKF ist und was es nicht ist

Was OKF im Kern ist

OKF ist eine Spezifikation & dabei bewusst minimal gehalten. Sie kann auch als „Knowledge Bundle“ bezeichnet werden, welches in diesem Fall ein Verzeichnisbaum aus Markdown-Dateien ist. Jede Datei ist ein „Concept“, also eine Wissenseinheit mit einem kleinen YAML-Kopf und freiem Markdown-Text darunter.

Es gibt exakt ein Pflichtfeld in der gesamten Spezifikation: type. Es gibt an, um welche Art von Concept es sich handelt: eine Tabelle, eine API, eine Kennzahl, ein Playbook. Empfohlen, aber optional, sind Felder wie title, description, ein Verweis auf die zugrundeliegende Ressource, tags und ein timestamp. Dazu kommen einige Konventionen, die das Format selbstbeschreibend machen: eine Verzeichnisübersicht, eine Änderungshistorie und normale Markdown-Links, um Beziehungen zwischen Concepts auszudrücken.

Es gibt kein Tooling, kein SDK und keine zentrale Instanz. OKF ist für Mensch und Maschine gleichermaßen lesbar.

Die Abgrenzung, auf die es ankommt

Hier liegt das häufigste Missverständnis. Ein OKF-Concept beschreibt ein Asset. Es ist Kontext über ein Dokument oder System, nicht eine Umwandlung oder (verkürzte) Darstellung des Inhalts selbst.

Daraus folgt: Ein 200-seitiger Vertrag wird nicht halluzinationsfest, nur weil ein Concept darüber liegt, die ihn beschreibt. Den Inhalt muss man weiterhin zerlegen, vektorisieren und retrieven. OKF ist eine kuratierte Wissens- bzw. Katalogschicht, kein Dokumenten- und kein Chunking-Format. Es sitzt eine Ebene über dem Inhalt, nicht an seiner Stelle.

Die richtige Frage ist deshalb nicht „ersetzt das mein Retrieval?“, sondern „wie macht diese Schicht mein bestehendes Retrieval besser?“.

🥁 Track 2: Wo OKF in der Pipeline sitzt und warum es gegen Halluzination hilft

OKF sitzt als Anreicherungs- und Routing-Schicht auf der Retrieval-Schicht & ergänzt diese. Ganz konkret an zwei Stellen.

In der Ingestion-Schicht werden die Concepts selbst zu hochsignalreichen Chunks: kurz, dicht und kuratiert. Zusätzlich reichern ihre Beschreibungen die Chunks der eigentlichen Ressource an. Titel, Einzeiler und Pfad werden jedem abgeleiteten Chunk vorangestellt.

Im Retrieval dienen type und tags als Metadaten-Filter, die Hierarchie wird zum Routing-Layer für agentisches Vorgehen, und die Links bilden einen Graphen, über den ein System mehrstufig navigieren kann. Die Faustregel lautet: erst navigieren, dann retrieven, statt alles zu embedden.

Der Nutzen gegen Halluzination ist dabei eher indirekt. Vier Mechanismen greifen ineinander:

• Besseres Grounding pro Chunk: Die Frontmatter ist faktisch eine handkuratierte Variante von Contextual Retrieval und wirkt genau dort, wo beim Chunking sonst der übergeordnete Kontext verloren geht.
• Routing statt Raten: Übersicht und Hierarchie geben dem System eine Karte (Concept). Es navigiert gezielt in den richtigen Bereich, statt blind über den gesamten Vektorraum zu suchen.
• Beziehungen für Multi-Hop: Die Links sind ein menschenlesbarer, versionierbarer Wissensgraph, eine Art GraphRAG-light für Fragen, deren Antwort über mehrere Dokumente verteilt ist.
• Belegpflicht: Die Zitate-Konvention verankert Aussagen an Quellen. Das ist eines der wirksamsten Anti-Halluzinations-Muster.

🎯 Encore: Der eine Gedanke für Entscheider

OKF verfolgt den richtigen Ansatz. Wer große Wissensbestände produktiv nutzbar machen will, braucht eine selbstbeschreibende, versionierbare Schicht über den Rohdaten. Der Wert entsteht aber erst durch die entsprechend notwendige Kuratierung, das Routing und Grounding, und nicht durch das Format an sich.

Das größte Risiko ist dabei nicht die Technik, sondern die anhaltende Pflege der Concepts für die gegebenen Dokumente. Eine Schicht, die Assets beschreibt, läuft ihnen davon, sobald sie sich ändern. Zeitstempel und Änderungslog sind manuelle Hinweise, kein Synchronisationsmechanismus. Veraltete Metadaten erzeugen selbstbewusst falsche Antworten, also potenziell mehr Halluzination, nicht weniger. Eine Wissensschicht ist entsprechend nur so gut wie ihre garantierte Aktualität.

💿 B-Side

Das heutige Anti-Pattern: OKF heute schon als verbindliche Spezifikation festschreiben.

OKF gibt aktuell bewusst nur ein Minimum als verbindliche Spezifikation vor. Das hält es flexibel, bietet aber wenige harte Garantien, auf die sich Werkzeuge verlassen können, die damit arbeiten müssen. Der pragmatische Weg ist, auf das Muster der Spezifikation als solche zu setzen statt auf die Spezifikation selbst: Markdown plus Frontmatter in Git ist stabil und plattform-agnostisch. Wer sich jetzt auf OKF als verbindliche Spezifikation festlegt, riskiert, später Breaking Changes nachziehen zu müssen.

---

Das war Rag'n'Roll #003. Nächste Ausgabe: quantitative Evaluation von RAG-Systemen.

P.S.: Wer RAG von Grund auf verstehen will: In unserem dreitägigen RAG-Workshop konzipieren, implementieren und evaluieren die Teilnehmer eine produktionsreife Pipeline selbst, von Chunking über Contextual Retrieval bis zur quantitativen Evaluation. Mehr auf quikk.de

Weiterleiten erwünscht🤘