OpenKB kompiliert Dokumente zu einem Wiki, statt bei jeder Frage neu zu suchen
OpenKB: Open LLM Knowledge Base
Auf einen Blick
- Was ist das?
- OpenKB ist ein CLI-Werkzeug, das Rohdokumente mit einem LLM in eine verlinkte Wiki-Struktur übersetzt und darüber Abfragen, Chats und Agent-Skills erzeugt. Der interessante Teil ist weniger das Wiki als die Abkehr von der Vektordatenbank bei langen PDFs.
- Für wen ist es gedacht?
- Wer viele lange PDFs wiederholt auswerten muss und die Ergebnisse als lesbare Markdown-Dateien behalten will, findet in OpenKB ein passendes Werkzeug. Für kurze, einmalige Fragen an ein paar Textdateien ist der Aufwand einer kompilierten Wissensbasis zu hoch, dort reicht ein einfaches Retrieval.
- Darf ich es kommerziell nutzen?
- Ja. Apache-2.0 ist eine freizügige Lizenz: Sie dürfen darauf aufbauende Software nutzen, verändern und verkaufen, solange Sie die Urheberrechts- und Lizenzhinweise beibehalten.
- Wird es noch gepflegt?
- Ja. Die letzten Commits kamen vor 56 Tagen.
- In welcher Sprache ist es geschrieben?
- Hauptsächlich Python, laut der Sprachstatistik von GitHub.
Die Antworten beruhen auf den GitHub-Daten des Projekts (zuletzt abgeglichen am 15. September 2026) und auf unserer Analyse. Sie sind keine Rechtsberatung.
TIEFGEHENDE OPEN-SOURCE-ANALYSE
Das Problem: Wissen, das bei jeder Abfrage neu entsteht und wieder verschwindet
Traditionelles RAG zerlegt Dokumente in Abschnitte, speichert deren Einbettungen und sucht bei jeder Frage erneut die passenden Fragmente. Das Ergebnis existiert nur für diese eine Antwort. Die README bringt den Kern auf den Punkt: Traditionelles RAG entdecke Wissen bei jeder Abfrage neu, und nichts sammle sich an. Wer dieselbe Dokumentsammlung über Wochen befragt, bezahlt dieselbe Arbeit immer wieder.
OpenKB setzt an einer anderen Stelle an. Es übersetzt die Dokumente einmalig in eine strukturierte Wissensbasis aus Zusammenfassungen, Konzeptseiten, Entitätsseiten und Querverweisen. Diese Wissensbasis liegt als Sammlung von Markdown-Dateien auf der Platte und wird bei neuen Dokumenten fortgeschrieben. Das ist eine andere Kostenkurve: teuer beim Einlesen, günstig bei der wiederholten Nutzung.
Die Zielgruppe ergibt sich daraus. Wer eine private oder teaminterne Sammlung von Papern, Handbüchern oder Spezifikationen über längere Zeit auswertet, profitiert. Wer einmalig eine Frage an drei Textdateien hat, nicht.
Zwei Schichten: Wiki-Fundament und Generatoren
Die Architektur teilt sich laut README in zwei Ebenen. Unten liegt das Wiki-Fundament, das Dokumente kompiliert und aktuell hält. Darauf sitzen Generatoren: query für Einzelfragen, chat für mehrteilige Gespräche mit gespeicherten Sitzungen und die Skill Factory, die aus dem Wiki weitergebbare Agent-Skills destilliert. Dazu kommen visualize für einen interaktiven Wissensgraphen und deck für HTML-Präsentationen.
Entscheidend ist die Richtung des Datenflusses. Die Generatoren lesen aus dem Wiki, nicht aus den Originaldokumenten. Das Wiki ist damit der eigentliche Zustand des Systems. Wer die Wissensbasis löscht, verliert die kompilierte Struktur, nicht nur einen Cache.
Die Wiki-Seiten folgen nach Angaben des Projekts der Google Open Knowledge Format Spezifikation. Das ist ein Format für den Austausch von Wissen, kein internes Serialisierungsdetail. Praktisch heißt das: Die Ausgabe ist nicht an OpenKB gebunden. Die Seiten sind einfache .md-Dateien mit Querverweisen, die sich laut README in Obsidian mit Graphansicht öffnen lassen. Dieses Detail ist wichtiger, als es klingt. Es bedeutet, dass die investierte Kompilierarbeit nicht in einem proprietären Index verschwindet.
Kurze und lange Dokumente laufen durch verschiedene Pfade
Die README dokumentiert eine Aufteilung, die man beim Lesen der Feature-Liste leicht überliest. Kurze Dokumente wandelt markitdown in Markdown um, Bilder werden inline mit pymupdf extrahiert, und das LLM liest den vollen Text. Lange PDFs ab etwa 20 Seiten gehen stattdessen durch PageIndex, das einen Baumindex mit Zusammenfassungen erzeugt. Das LLM liest dann nicht das Dokument, sondern dessen Baum.
Das ist der Kern des vectorless-Ansatzes. Statt Abschnitte über Ähnlichkeitssuche zu finden, navigiert das Modell durch eine hierarchische Struktur und entscheidet begründend, welcher Ast relevant ist. Bei Dokumenten mit klarer Gliederung, also Papern, Verträgen, Handbüchern, ist das plausibel. Bei Textwüsten ohne Überschriften, etwa transkribierten Interviews oder Fließtext ohne Absatzstruktur, fehlt die Hierarchie, an der sich der Baum orientieren könnte. Die README nennt für diesen Fall keine Alternative.
Bemerkenswert ist, dass beide Pfade dasselbe Ausgabeformat liefern: eine Zusammenfassung plus Konzeptseiten. Der Unterschied liegt nur im Weg dorthin. Das hält die nachgelagerten Generatoren einfach, verlagert aber die gesamte Komplexität in die Konvertierung.
Installation und die ersten Befehle
Die Installation erfolgt über pip install openkb. Alternativ nennt die README den direkten Git-Pfad sowie eine editierbare Installation aus dem Quellbaum für die Entwicklung.
Der Ablauf ist linear. Zuerst ein Verzeichnis anlegen und hineinwechseln, dann openkb init ausführen. Das erzeugt die Wissensbasis und fragt nach dem Modell. Dokumente kommen über openkb add dazu, entweder als einzelne Datei, als ganzes Verzeichnis oder als URL. Für eine URL gibt die README das Beispiel einer arXiv-PDF. Anschließend beantwortet openkb query eine Frage, openkb chat startet ein Gespräch.
Die Modellkonfiguration läuft über LiteLLM im Format provider/model, etwa anthropic/claude-sonnet-4-6. OpenAI-Modelle dürfen laut README ohne Präfix angegeben werden. Der Schlüssel gehört in eine .env-Datei unter LLM_API_KEY. Anbieter, die per OAuth-Gerätefluss authentifizieren, etwa chatgpt/* oder github_copilot/*, brauchen keinen Schlüssel. OpenKB überspringt die Warnung über den fehlenden Schlüssel für diese Fälle.
Für die Weboberfläche ist ein Extra nötig: pip install "openkb[web]", danach startet openkb-web den Dienst auf http://127.0.0.1:7566/. Die Authentifizierung ist laut README standardmäßig aus, weil das Werkzeug lokal gedacht ist. Wer den Port nach außen öffnet, muss OPENKB_API_TOKEN setzen.
Was die Konfiguration nicht verrät
Die README verweist für die Konfiguration auf .openkb/config.yaml und nennt als Beispiel nur den Modellschlüssel. Nicht dokumentiert ist in dem vorliegenden Material, welche weiteren Schlüssel diese Datei kennt: Wie wird die Seitengrenze zwischen kurzem und langem Dokument verschoben? Lässt sich der Schwellwert von 20 Seiten ändern? Wie wird festgelegt, welche Entitätsseiten automatisch extrahiert werden? Diese Fragen bleiben offen.
Das ist keine Kleinigkeit. Bei einem Werkzeug, dessen Kosten beim Kompilieren anfallen, ist die Frage, wie viel Text pro Dokument durch das Modell läuft, eine Budgetfrage. Wer viele hundert PDFs einliest, möchte wissen, ob die Kompilierung wiederholbar ist, ob sie bei einem Abbruch fortgesetzt wird und ob ein erneutes openkb add auf dasselbe Dokument die Arbeit verdoppelt. Das Material beantwortet nichts davon.
Wer OpenKB ernsthaft einsetzen will, sollte das vor dem Massenimport klären, nicht danach. Ein Testlauf mit einer Handvoll Dokumente und einer Beobachtung des Tokenverbrauchs beim Anbieter ist hier die naheliegende Vorprüfung.
Die Alternative heißt nicht anderes Wiki, sondern Vektordatenbank
Der naheliegende Vergleich ist nicht ein anderes Wiki-Werkzeug, sondern der klassische RAG-Stack aus Chunking, Embedding-Modell und Vektordatenbank. Der Unterschied liegt nicht in der Qualität der Antwort, sondern im Ort der Arbeit.
Bei einem Vektordatenbank-Stack passiert die Auswahl zur Laufzeit. Jede Frage erzeugt eine Einbettung, die Datenbank liefert die ähnlichsten Abschnitte, das Modell formuliert daraus eine Antwort. Es gibt keinen Zwischenstand, den man lesen könnte. Dafür ist der Einstieg billiger: Dokumente einlesen, einbetten, fertig. Und das Verfahren skaliert auf Sammlungen, in denen Dokumente einander widersprechen, ohne dass jemand die Widersprüche auflösen muss.
OpenKB dreht das um. Die Auswahl passiert beim Kompilieren, das Ergebnis ist inspizierbar. Die README nennt als Vorteil, dass Widersprüche markiert werden. Das ist ein starkes Versprechen, denn es setzt voraus, dass das Modell beim Zusammenführen zweier Dokumente erkennt, dass sie sich widersprechen. Ob das zuverlässig gelingt, lässt sich aus dem Repository-Material nicht beurteilen. Wer darauf angewiesen ist, sollte es mit zwei bewusst widersprüchlichen Dokumenten selbst prüfen.
Der zweite Unterschied ist die Abhängigkeit. Ein Vektordatenbank-Stack bindet an ein Embedding-Modell und eine Datenbank. OpenKB bindet an ein LLM, das die Kompilierung durchführt, und an PageIndex für lange PDFs. Die Abhängigkeit ist damit nicht kleiner, nur anders geschnitten.
Lizenz und Wartungskosten
OpenKB steht unter Apache-2.0. Das erlaubt kommerzielle Nutzung, Veränderung und Weitergabe, sofern die Lizenzbedingungen eingehalten werden. Wer das Werkzeug in ein eigenes Produkt einbettet, sollte die üblichen Pflichten zur Beibehaltung von Copyright- und Lizenzhinweisen beachten. Eine Rechtsberatung ersetzt das nicht.
Zu den Wartungskosten sagt das Material wenig Konkretes. Die Versionshistorie zeigt v0.4.5 vom 20. Juli 2026 und v0.4.4 vom 10. Juli 2026, dazwischen ein Release Candidate. Der Abstand zwischen den Versionen beträgt zehn Tage. Das deutet auf aktive Entwicklung hin, aber auch auf eine frühe Versionsnummer. Ein 0.4.x-Stand bedeutet üblicherweise, dass sich Schnittstellen noch ändern können. Wer auf stabile CLI-Flags angewiesen ist, sollte die Release Notes vor jedem Update lesen.
Ein Punkt, der in die Wartungskosten hineinspielt: Die README erwähnt, dass LiteLLM auf eine als sicher bezeichnete Version festgelegt ist, mit Verweis auf einen Sicherheitshinweis vom März 2026. Eine solche Pinnung schützt, erzeugt aber Pflegeaufwand, weil sie irgendwann gegen neuere Anbieter-SDKs aktualisiert werden muss. Wer OpenKB in einer Umgebung mit festen Abhängigkeiten betreibt, sollte diese Pinnung nicht ohne Prüfung aufheben.
Für wen sich der Aufwand rechnet
OpenKB passt zu Arbeitsabläufen, in denen dieselbe Dokumentensammlung über Monate hinweg befragt wird und in denen das Ergebnis als Text vorliegen soll, den man lesen, versionieren und in einem Editor bearbeiten kann. Der Obsidian-kompatible Markdown-Baum ist hier der eigentliche Nutzen, nicht die Suchfunktion.
Nicht geeignet ist es für einmalige Nachschlagevorgänge, für Sammlungen aus vielen kurzen Notizen ohne Struktur und für Fälle, in denen jede Antwort ausschließlich aus dem Originalwortlaut belegt sein muss. Die Kompilierung erzeugt eine Zwischenschicht, und diese Schicht kann Fehler enthalten, die sich in späteren Antworten fortsetzen.
Wer den Server über das lokale Netz hinaus betreibt, setzt OPENKB_API_TOKEN, bevor der Port geöffnet wird. Wer die Wissensbasis mit hunderten Dokumenten befüllt, macht einen Testlauf mit wenigen Dateien und prüft am Anbieterkonto, was die Kompilierung verbraucht. Und wer die Widerspruchserkennung als Argument für OpenKB anführt, sollte sie zuerst mit zwei Dokumenten prüfen, die sich widersprechen, bevor er sich darauf verlässt.
Redaktionelles Fazit
Wer viele lange PDFs wiederholt auswerten muss und die Ergebnisse als lesbare Markdown-Dateien behalten will, findet in OpenKB ein passendes Werkzeug. Für kurze, einmalige Fragen an ein paar Textdateien ist der Aufwand einer kompilierten Wissensbasis zu hoch, dort reicht ein einfaches Retrieval. Wer den Server über localhost hinaus betreibt, sollte zuerst OPENKB_API_TOKEN setzen, weil die Authentifizierung laut README standardmäßig aus ist. Vor dem produktiven Einsatz ist außerdem zu prüfen, welcher LiteLLM-Anbieter in .openkb/config.yaml hinterlegt ist und ob das gewählte Modell die für die Wiki-Kompilierung nötigen langen Kontexte zuverlässig verarbeitet.
Community-Notizen