OKF vs. Vektordatenbank: zwei Wege, einer KI deine Dokumente zu geben

Zwei Wege, einer KI deine Dokumente zu geben

Das grundlegende Problem ist in beiden Fällen dasselbe: Ein Sprachmodell hat ein begrenztes Kontextfenster. Die meisten Dokumente passen nicht hinein. Man braucht einen Weg, dem Modell zur Anfragezeit genau die richtigen Informationen bereitzustellen. Eine Vektordatenbank und ein OKF-Bundle sind zwei grundlegend verschiedene Antworten auf dieses Problem. Die Wahl zwischen ihnen entscheidet über Hosting-Aufwand, Wartbarkeit und Souveränität.

Wie eine Vektordatenbank funktioniert

Eine Vektordatenbank-Pipeline besteht aus fünf Schritten. Erst werden die Quelldokumente in Chunks zerlegt: überlappende Textsegmente von einigen hundert Token. Dann wird jeder Chunk durch ein Embedding-Modell verarbeitet: Der Text wird in einen dichten numerischen Vektor umgewandelt, eine Liste von Hunderten oder Tausenden von Gleitkommazahlen. Diese Vektoren werden in einer Spezialdatenbank abgelegt: Pinecone, Weaviate, Chroma, Qdrant oder einem selbst betriebenen Milvus. Zur Anfragezeit wird die eingehende Frage auf dieselbe Weise eingebettet und eine Ähnlichkeitssuche durchgeführt: Die top-k Vektoren, die dem Fragevektor am nächsten liegen, werden gefunden. Diese Chunks landen im Prompt, und das Modell antwortet.

Das System funktioniert. Aber der Betrieb hat seinen Preis.

Die Vektoren sind undurchsichtig. Eine Folge von Gleitkommazahlen kodiert die Bedeutung von "höhere Gewalt" auf eine Weise, die kein Mensch (und kein Prüfwerkzeug) direkt lesen kann. Wenn das Retrieval schiefläuft, vergleicht man Ähnlichkeitswerte.

Du betreibst die Datenbank. Ob als verwalteter Cloud-Dienst oder selbst gehosteter Container, es ist ein zustandsbehaftetes System mit Zugangsdaten, Backups, Skalierung und Schema-Migrationen.

Du re-embedest bei jeder Änderung. Ein Dokument aktualisiert? Neu chunken, neu einbetten, in den Index schreiben. Verpasst man einen Zyklus, driftet der Index still vom Original weg, ohne Warnung.

Den Index kann man nicht einfach teilen. Vektoren sind modellspezifisch: Ein anderes Embedding-Modell erzeugt einen anderen Index. Ein Mitarbeiter braucht die Quelldokumente und eine laufende Datenbank, nicht einfach das Wissen.

Wie ein OKF-Bundle funktioniert

Ein OKF-Bundle (im Format, das Google am 12. Juni 2026 als Open Knowledge Format veröffentlicht hat) speichert Wissen als einfache Markdown-Konzeptdateien mit YAML-Frontmatter. Keine Vektoren. Keine Datenbank. Nur ein Verzeichnis von Textdateien, die man in jedem Editor öffnen kann. Das ist die Kernidee hinter "Markdown statt Vektordatenbank".

Zur Anfragezeit durchsucht ein Agent das Bundle per grep: Dateinamen und Überschriften scannen, passende Konzeptdateien lesen, Querverweisen folgen. Der Agent navigiert wie ein Entwickler, der eine Codebasis liest: direkt, mit Datei-I/O, ohne undurchsichtigen Vermittler.

pdf2okf erzeugt OKF-kompatible Bundles. Das Wissen ist menschenlesbar, versionierbar in git, portabel als Zip-Datei und teilbar ohne Datenbank oder Embedding-Modell.

Vergleich auf einen Blick

| Eigenschaft | Vektordatenbank | OKF-Bundle | |---|---|---| | Speicherformat | Undurchsichtige numerische Vektoren | Reines Markdown + Frontmatter | | Menschenlesbar | Nein | Ja, in jedem Editor öffenbar | | Hosting erforderlich | Ja, DB-Prozess oder Managed Service | Nein, ein Verzeichnis mit Dateien | | Re-Embedding bei Änderung | Ja, obligatorischer Pipeline-Schritt | Nein, speichern genügt | | Portabel / teilbar | Modell- und DB-spezifisch | Jeder Agent, jede Maschine | | Versionskontrolle | Extern / manuell | Nativ (git diff funktioniert) | | Vendor-Lock-in | Hoch, gebunden an DB und Embedding-Modell | Keiner, reine Dateien | | Retrieval debuggen | Ähnlichkeitswerte lesen | Datei direkt öffnen und lesen |

Wann eine Vektordatenbank sinnvoll bleibt

Vektordatenbanken rechtfertigen ihre Komplexität bei echter Skalierung: Millionen heterogener, unstrukturierter Dokumente, bei denen das Corpus zu groß ist, um per Dateiname und Überschrift zu navigieren. Ein medizinisches Literaturarchiv, Discovery-Sets mit Hunderttausenden von Verträgen, mehrsprachige Kundensupport-Historien: das sind Fälle, bei denen embedding-basierte Ähnlichkeitssuche ihren Betriebsaufwand rechtfertigt.

Ist das Corpus begrenzt, strukturiert und selbst verwaltet (eine Produktspezifikation, ein Richtlinienhandbuch, eine technische Wissensbasis, eine kuratierte Dokumentensammlung), schlägt Struktur Embeddings. Man braucht keine Heuhaufen-Suche, wenn das Wissen bereits organisiert ist. Auf dieser Ebene navigiert ein Agent, der Konzeptdateien per Überschrift durchsucht, schneller, günstiger und exakter als Kosinus-Ähnlichkeit über einen probabilistischen Index.

Skalierung ist nicht immer eine Tugend. Ein gut strukturiertes Bundle ist ein Merkmal, keine Einschränkung.

Wo pdf2okf passt

pdf2okf wandelt PDFs in OKF-kompatible Bundles um: strukturierte Markdown-Konzeptdateien, die jeder Agent direkt per grep durchsuchen kann, die praktische Alternative zur Vektordatenbank. Keine Vektordatenbank zu betreiben, keine Embedding-Pipeline zu pflegen, kein Index, der bei Quelländerungen neu synchronisiert werden muss. Das Wissen bleibt lesbar, portabel und vollständig unter deiner Kontrolle.

Das ist keine Notlösung. Es ist die richtige Architektur für begrenzte, souveräne Wissensdatenbanken, und dieselbe Entscheidung, die Anthropics eigenes Entwicklertool Claude Code getroffen hat, als es die Vektorsuche zugunsten direkter Dateisuche aufgab.