Pit-Share in OME Topic 13 #6697 (Reddit-Post r/WebAfterAI). OKF v0.1 ist die offizielle Spezifikation des Musters, das wir bereits umsetzen. Neue Konzeptseite open-knowledge-format-okf.md mit Frontmatter-Schema, Bundle-Struktur, 3 Workflows, Citations-Konvention, Versioning. Cross-Ref in llm-knowledge-base.md + index/log Updates.
2.6 KiB
2.6 KiB
| created | updated | sources | tags | |||||
|---|---|---|---|---|---|---|---|---|
| 2026-06-05 | 2026-06-16 |
|
|
LLM Knowledge Base (Karpathy Wiki)
Siehe README.md — Das RamaDama Wiki basiert auf diesem Pattern.
Kernprinzip
Statt RAG (wiederverarbeitet Rohdaten bei jeder Query) → LLM baut und pflegt ein persistentes Wiki aus .md-Dateien.
Drei Schichten
- Raw Sources — immutable, LLM liest nur
- Wiki — LLM-generated Markdown, verlinkt und strukturiert
- Schema — AGENTS.md definiert Konventionen und Workflows
Drei Operationen
- Ingest — Rohdaten verarbeiten → Wiki aktualisieren
- Query — Fragen gegen das Wiki beantworten, Antworten zurückschreiben
- Lint — Health Checks, Widersprüche, Lücken
Quellen
- Karpathy Post: https://x.com/karpathy/status/2039805659525644595
- Karpathy Gist: https://gist.github.com/karpathy/442a6bf555914893e9891c11519de94f
Kontext im RamaDama-Setup
Dieses Wiki ist eine direkte Operationalisierung von Karpathys Vorschlag — das RamaDama Knowledge-Base Repo setzt das Pattern produktiv um. Die Idee, dass RAG ineffizient ist (gleiche Dokumente werden bei jeder Query neu vektorisiert und re-ranked), wird hier konsequent zu Ende gedacht: Einmal ingest, dauerhaft referenzierbar.
Vorteile gegenüber RAG
- Konsistenz: Die Antwort hängt nicht vom Embedding-Modell oder Chunker-Parametern ab — was im Wiki steht, ist die Wahrheit
- Latenz: LLM-only Lookups, keine Vektor-DB-Query + Top-K-Rerank nötig
- Editierbarkeit: Wiki-Pages können vom LLM korrigiert, erweitert, refaktoriert werden — RAG-Index nicht trivial editierbar
- Versionskontrolle: Git-Diff zeigt, was sich am Wissen geändert hat
Trade-offs
- Kontextfenster: Pages müssen kompakt genug sein, um ins LLM-Kontextfenster zu passen — daher die 30-Zeilen-Stub-Heuristik als Wachhund
- Schreib-Overhead: LLM muss aktiv kuratieren, nicht nur retrieven
- Inkonsistenz-Risiko: LLM kann beim Schreiben halluzinieren → Lint-Script prüft auf Widersprüche
Verwandte Seiten
- wiki/architecture/memory-system — Schicht 1/2/3 als komplementäres Memory-System
- wiki/architecture/byterover-knowledge-mining — historischer Vorläufer, der an Container-Ephemeralität scheiterte
- wiki/concepts/llm/llm-behavior-persistence — wie LLMs selbst persistente Verhaltensweisen aufbauen
- open-knowledge-format-okf — OKF v0.1 (Google Cloud, 2026-06-12) formalisiert genau dieses Pattern als offenen Standard. Unser Wiki ist strukturell bereits konform