Skip to Content
BlogKnowledge-Wiki (Karpathy & OKF)

Vom Suchindex zum Wissens-Wiki: Karpathys LLM-Wiki-Muster und Googles OKF im KnowledgeSDK

Martin MöllenbeckKnowledgeSDKCLIAIOKF

Zwei Veröffentlichungen haben uns in kurzer Folge bestätigt, dass wir mit dem KnowledgeSDK auf dem richtigen Weg sind — und uns gezeigt, welcher Baustein noch fehlte. Mit KnowledgeSDK v1.3.0 und CLI v4.14.0 ist er jetzt da: der Wiki-Layer, eine destillierte, LLM-gepflegte Wissensbasis über dem Suchindex.

Der Auslöser: Karpathys „LLM Wiki”

Andrej Karpathy hat in seinem Gist „LLM Wiki”  ein Muster beschrieben, das klassisches RAG auf den Kopf stellt: Statt bei jeder Anfrage Rohdokumente zu durchsuchen und die Antwort immer wieder neu abzuleiten, pflegt ein LLM kontinuierlich eine strukturierte Markdown-Wissensbasis — ein kompoundierendes Artefakt, das mit jeder verarbeiteten Quelle besser wird.

Das Muster kennt drei Schichten und drei Operationen:

SchichtInhalt
Raw SourcesOriginalquellen — unveränderlich, werden nur gelesen
WikiVom LLM destillierte, quervernetzte Markdown-Seiten + index.md (TOC) + log.md (Chronik)
SchemaKonventionen und Workflows, von Menschen definiert
  • Ingest: Neue Quelle → das LLM liest, extrahiert und aktualisiert die betroffenen Wiki-Seiten
  • Query: Fragen gehen gegen das Wiki; gute Antworten fließen als neue Seiten zurück
  • Lint: Regelmäßige Integritätsprüfung — denn Drift (veraltete Inhalte) ist der wichtigste Fehlermodus

Karpathys Kernbeobachtung: Die „Buchhaltung” einer Wissensbasis — Querverweise pflegen, Konsistenz prüfen, Inhaltsverzeichnisse aktuell halten — ermüdet Menschen. LLMs ermüden nicht. Und ein Detail hat uns besonders gefreut: Als lokales Suchwerkzeug empfiehlt der Gist explizit qmd — genau die Engine, auf der unser KnowledgeSDK aufbaut.

Die zweite Bestätigung: Google standardisiert dasselbe Muster

Kurz darauf sind wir auf das Open Knowledge Format (OKF v0.1)  gestoßen — eine Spezifikation von Google Cloud für „human- und agentenfreundliche” Wissensrepräsentation. Der Aufbau: Markdown-Dateien mit YAML-Frontmatter in einem Verzeichnisbaum („Bundle”), reservierte Dateien index.md und log.md, Git als Distributionsweg, permissive Konsumenten.

Das ist — bis in die Dateinamen hinein — Karpathys Muster als formale Spec. Wenn ein einzelner Gist und eine Google-Spezifikation unabhängig voneinander bei derselben Struktur landen, ist das kein Zufall, sondern Konvergenz.

Was wir gebaut haben

Der neue Wiki-Layer setzt das Muster für die ProcessCube® Platform um — mit einer klaren Arbeitsteilung: Das SDK und die CLI machen die deterministische Buchhaltung, ein AI-Agent macht die Destillation. Kein einziger LLM-Call steckt im SDK.

pc knowledge wiki init          # OKF-konformes Wiki anlegen
pc knowledge wiki status        # Ingest-Queue: was wartet auf Destillation?
pc knowledge wiki lint          # Drift-Wache (Exit 1 → CI/Cron)
pc knowledge search "timer" --layer wiki
pc knowledge serve --ui         # Wiki-Browser + JSON-API + MCP-Pflege-Tools

Die Wikis sind OKF-v0.1-konforme Bundles — mit dem Pflichtfeld type, okf_version-Deklaration, Datums-Gruppen-Chronik und Markdown-Links nach OKF-Konvention (zusätzlich zu Obsidian-kompatiblen [[wiki-links]]). Damit sind sie austauschbar: lesbar für Googles Tooling und jeden künftigen OKF-Konsumenten.

Unsere Erweiterung: deterministische Drift-Erkennung

Karpathys Community und die OKF-Autoren sind sich einig, dass Drift der Haupt-Fehlermodus LLM-gepflegter Wissensbasen ist — aber beide lösen das Problem nicht strukturell. Genau hier setzt die ProcessCube-Erweiterung an: Jede Wiki-Seite trägt im Frontmatter ihre Quellen-Provenienz — die Dokument-IDs des Suchindex samt contentHash zum Zeitpunkt der Destillation.

sources:
  - id: "docs:/pfad/timer.md"
    contentHash: "ab12…"   # Stand der Quelle bei Destillation

Ändert sich eine Rohquelle, weicht ihr Hash im Index vom Hash im Frontmatter ab — und wiki status meldet die Quelle als changed, wiki lint die Seite als stale-source, der Wiki-Browser zeigt ein rotes „veraltet”-Badge. Deterministisch, ohne einen einzigen LLM-Call. Der Agent muss nicht raten, was veraltet sein könnte — die Buchhaltung sagt es ihm.

Kurz gesagt: KnowledgeSDK-Wiki = OKF-Bundle + Drift-Erkennung. Das Format gehört der Community, die Verlässlichkeit kommt von uns.

Für Menschen und Agenten gleichermaßen

  • Browsen: pc knowledge serve --ui liefert einen eingebauten Wiki-Browser; der Ordner ist zugleich Obsidian-kompatibel (Backlinks und Graph-Ansicht gratis). Für eigene Apps gibt es die React-Komponente WikiBrowser samt JSON-API.
  • Pflegen: Vier MCP-Tools (knowledge_wiki_get_page, upsert_page, append_log, status) lassen auch remote laufende Agenten das Wiki pflegen — die Workflows liefert pc skill install knowledge.
  • Absichern: Auth in drei Stufen — offen für lokale Entwicklung, fixer API-Key (mit Browser-Login per ?key=), oder ein eigenes Auth-Plugin, über das sich ein kompletter OIDC-Flow gegen die Authority abbilden lässt.

Ausprobieren

Der Wiki-Layer ist in KnowledgeSDK v1.3.0 und CLI v4.14.0 enthalten. Die vollständige Dokumentation:

ÜbersichtTicketpilot-Release-Prozess