Open Knowledge Format (OKF): Eine Wissensschicht für produktionsreife RAG-Systeme

Das Open Knowledge Format, kurz OKF, ist im Kern nichts weiter als ein Verzeichnis aus Markdown-Dateien mit YAML-Kopf. Kein Tooling, keine zentrale Instanz, kein SDK. Und trotzdem trifft es einen wunden Punkt fast jedes RAG-Systems.

Denn das eigentliche Problem großer Wissensbestände ist selten das Modell. Es ist der fehlende Kontext darüber, was ein Dokument überhaupt ist, wozu es gehört und worauf es sich bezieht. Genau hier setzt OKF an, und genau hier lohnt sich ein nüchterner Blick, bevor man es zum Allheilmittel erklärt.

Sie erfahren:

• Was OKF ist, und was es ausdrücklich nicht ist
• Wo es in einer RAG-Pipeline sitzt, als Schicht, nicht als Ersatz
• Über welche Mechanismen es Halluzination reduziert
• Welche Grenzen und Risiken Sie von Anfang an einplanen müssen

1. Was ist das Open Knowledge Format?

OKF ist ein bewusst minimales Format, um Wissen abzubilden: die Metadaten, den Kontext und die kuratierte Einordnung rund um Daten und Systeme. Es ist so gebaut, dass Menschen es ohne Werkzeug lesen, Agenten es ohne Spezial-SDK parsen und Organisationen es austauschen können.

Technisch besteht ein Knowledge Bundle aus einem Verzeichnisbaum von Markdown-Dateien. Jede Datei ist ein Concept, eine einzelne Wissenseinheit, eingeleitet von einem YAML-Kopf (Frontmatter) und gefolgt von freiem Markdown-Text.

Pflicht ist genau ein Feld: type. Es benennt die Art des Concepts, etwa BigQuery Table, API Endpoint, Metric oder Playbook. Empfohlen, aber optional, sind:

Dazu kommen drei Konventionen, die das Bundle selbstbeschreibend machen: index.md listet den Inhalt eines Verzeichnisses auf (für schrittweises Erschließen), log.md hält die Änderungshistorie fest, und ganz normale Markdown-Links zwischen Concepts drücken Beziehungen aus.

Die zentrale Designentscheidung: OKF standardisiert nur das absolute Minimum. Alles darüber hinaus bleibt dem Produzenten überlassen.

2. Die entscheidende Abgrenzung: Beschreibung, nicht Inhalt

Hier liegt das häufigste Missverständnis, und der Punkt, an dem viele zu hohe Erwartungen entwickeln.

Ein OKF-Concept beschreibt ein Asset: eine Tabelle, eine API, einen Prozess, eine Kennzahl. Es ist Metadaten und kuratierter Kontext über Dinge. Es ist keine Transformation des Quelldokuments selbst.

Das hat eine unbequeme Konsequenz:

Ein 200-seitiger Vertrag wird nicht dadurch halluzinationsfest, dass eine OKF-Karte daneben liegt, die ihn beschreibt.

Den Vertragsinhalt müssen Sie weiterhin zerlegen (chunken), 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.

Wer das verinnerlicht, stellt die richtige Frage: Nicht "ersetzt OKF mein Retrieval?", sondern "wie macht diese Schicht mein bestehendes Retrieval besser?".

3. Wo OKF in der RAG-Pipeline sitzt

OKF gehört als Anreicherungs- und Routing-Schicht oben drauf, nicht als Ersatz für Ingestion oder Retrieval. Konkret an zwei Stellen:

In der Ingestion-Phase. Die OKF-Karten selbst werden zu hochsignalreichen Chunks: Sie sind kurz, dicht und kuratiert. Zusätzlich reichern ihre Beschreibungen die Chunks der zugrundeliegenden Ressource an, der Titel, der Einzeiler und der Pfad im Bundle werden jedem abgeleiteten Chunk vorangestellt.

In der Retrieval-Phase. type und tags dienen als strukturierte Metadaten-Filter. Die Verzeichnishierarchie samt index.md wird zum Routing-Layer für agentisches Retrieval, erst die Übersicht lesen, dann ins richtige Concept drillen, dann in die Ressource. Und die Cross-Links bilden einen Graphen, über den ein System mehrstufig navigieren kann.

Die Faustregel lautet: navigieren, dann retrieven statt "alles embedden und hoffen".

4. Warum das gegen Halluzination hilft

Der Nutzen ist real, aber indirekt. OKF reduziert Halluzination über vier Mechanismen, die jeder kennt, der eine Pipeline ernsthaft evaluiert hat:

4.1 Besseres Grounding pro Chunk

Die Frontmatter ist faktisch eine handkuratierte Variante von Contextual Retrieval, dem Anreichern von Chunks mit Kontext vor der Indexierung. Sie adressiert direkt den klassischen Failure Mode, dass beim Chunking der übergeordnete Kontext verloren geht.

4.2 Routing statt Raten

index.md und die Hierarchie geben dem System eine Karte. Statt blind über den gesamten Vektorraum zu suchen, kann ein Agent gezielt in den richtigen Bereich navigieren, weniger Streuung, weniger falsch abgerufener Kontext.

4.3 Beziehungen als Multi-Hop-Hilfe

Die Cross-Links sind ein (untypisierter) Wissensgraph, menschenlesbar und versionierbar, eine Art GraphRAG-light. Das hilft bei Fragen, deren Antwort über mehrere Dokumente verteilt ist, dem typischen Multi-Hop-Problem.

4.4 Zitate als Attributionszwang

Die Citations-Konvention verankert Aussagen an Quellen. Belegpflicht ist eines der wirksamsten Anti-Halluzinations-Muster überhaupt.

5. Die Grenzen, ehrlich benannt

Wer OKF produktiv einsetzt, muss vier Dinge realistisch einplanen.

Es ersetzt kein Chunking und kein Retrieval. Gegen Halluzination aus fehlendem oder schlecht segmentiertem Inhalt tut OKF nichts. Die Qualität Ihrer Pipeline entscheidet sich weiterhin an Chunking, Reranking und Evaluation.

Es driftet. Das ist der wichtigste Vorbehalt. Eine Schicht, die Assets beschreibt, läuft den Assets davon, sobald sich diese ändern. timestamp und log.md sind manuelle Hinweise, kein Synchronisationsmechanismus. Veraltete Metadaten erzeugen selbstbewusst falsche Antworten, also potenziell mehr Halluzination, nicht weniger. Das ist das klassische Datenkatalog-Problem, und bei einer hand- oder agentengepflegten Schicht ist es sehr real.

Der Interop-Anspruch hat eine Lücke. OKF will Austausch über Organisationsgrenzen hinweg ermöglichen, verzichtet aber bewusst auf eine zentrale Registry für type-Werte. Innerhalb eines Unternehmens ist das unkritisch. Über Organisationsgrenzen hinweg wird Routing und Filtern auf Basis von type dadurch brüchig.

Es bietet wenig Verbindlichkeit. OKF standardisiert bewusst nur ein Minimum, ein einziges Pflichtfeld, der Rest ist Konvention. Das hält das Format flexibel, heißt aber auch: Es gibt kaum harte Garantien, auf die sich Werkzeuge verlassen könnten, und spätere Fassungen dürfen Konventionen verändern.

6. Einordnung: ein Muster, das konvergiert

Wichtig für die strategische Bewertung: OKF ist weniger eine Erfindung als die Spezifikation eines Musters, das aus mehreren Richtungen zusammenwächst, Markdown plus Frontmatter als agentenlesbare Wissensbasis.

Dasselbe Prinzip kennen Sie aus persönlichen Wissenswerkzeugen wie Obsidian, aus "Metadata as Code"-Ansätzen, aus Dokumentationsgeneratoren und aus den SKILL.md-Dateien, mit denen KI-Agenten ihr Vorgehen kapseln. Diese Konvergenz ist real, und sie ist der Grund, warum sich ein Einstieg lohnt.

Die Konsequenz für die Praxis: das Muster adoptieren, nicht die Marke. Die Konvention intern nutzen, ohne eine harte Abhängigkeit auf eine einzelne, minimal gehaltene Spezifikation aufzubauen.

7. Entscheidungsleitlinien für Führungskräfte

Wenn Sie eine Wissensschicht über Ihr RAG-System legen wollen:

1. Setzen Sie auf das Muster, nicht auf die konkrete Spec. Markdown plus Frontmatter in Git ist stabil und plattform-agnostisch, eine spezifische Fassung der Spezifikation ist es nicht.
2. Behandeln Sie die Schicht als Anreicherung, nicht als Ersatz. Sie verbessert Grounding und Routing, sie ist kein Retrieval-Wunder.
3. Planen Sie von Tag eins gegen Drift. Klären Sie, wer oder welcher Prozess die Wissensschicht aktuell hält, und wie Abweichungen vom Quellsystem erkannt werden. Eine Wissensschicht ohne Pflegekonzept wird zur Halluzinationsquelle.
4. Kommunizieren Sie den Nutzen ehrlich. "Besseres Grounding und sauberes Routing" ist ein starkes, belastbares Versprechen. "Keine Halluzinationen mehr" ist es nicht.
5. Messen Sie es. Ob die Schicht etwas bringt, zeigt nur eine quantitative Evaluation gegen eine Baseline ohne sie, nicht das gute Gefühl im Prototyp.

8. Fazit: Die Kuratierung ist der Wert, nicht die Magie

Das Muster hinter OKF ist goldrichtig: Wer große Wissensbestände produktiv nutzbar machen will, braucht eine selbstbeschreibende, versionierbare Schicht über den Rohdaten. OKF gibt diesem Muster einen Namen und ein paar sinnvolle Mindestregeln.

Der Wert entsteht aber durch Kuratierung, Routing und Grounding, nicht durch das Format an sich. Und das größte Risiko ist nicht die Technik, sondern die Pflege:

Eine Wissensschicht ist nur so gut wie ihre Aktualität.

Wer das beherzigt, baut sich genau das, was den Unterschied zwischen einem überzeugenden Demo und einem produktiven System ausmacht: eine KI, die nicht nur Dokumente durchsucht, sondern weiß, womit sie es zu tun hat.

Lieber selbst bauen statt nur lesen? Im 3-tägigen RAG-Workshop konzipieren, implementieren und evaluieren Sie eine produktionsreife RAG-Pipeline selbst, von Chunking und Retrieval über Contextual Retrieval bis zur quantitativen Evaluation. Genau die Bausteine, auf denen eine Wissensschicht wie OKF sinnvoll aufsetzt.