0e02fdbd59
- Created 27 new people-pages for all TODO-marked persons - Replaced all TODO: people-page markers with wiki-links in institutions - Cross-referenced back to institutions from each people-page - 0 TODO markers remaining New people-pages: shayne-coplan, jim-zemlin, wang-changhu, yang-bingyang, demis-hassabis, clement-delangue, thomas-kurian, fei-fei-li, christopher-manning, sam-altman, ilya-sutskever, moritz-kaminski, elon-musk, nicolas-burtey, elizabeth-stark, olaoluwa-osuntokun, jan-leike, oren-etzioni, ali-farhadi, jaime-sevilla, max-tegmark, daniela-rus, jared-kaplan, alex-atallah, andrew-moore, tuomas-sandholm, mitchell-baker
50 lines
No EOL
2.6 KiB
Markdown
50 lines
No EOL
2.6 KiB
Markdown
---
|
|
created: 2026-06-05
|
|
updated: 2026-06-16
|
|
sources:
|
|
- blog/2026-06-16_okf-google-cloud-open-knowledge-format.md
|
|
tags: [concept, karpathy, wiki, okf]
|
|
---
|
|
|
|
# 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
|
|
1. **Raw Sources** — immutable, LLM liest nur
|
|
2. **Wiki** — LLM-generated Markdown, verlinkt und strukturiert
|
|
3. **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
|
|
- [[../../architecture/memory-system.md]] — Schicht 1/2/3 als komplementäres Memory-System
|
|
- [[../../architecture/byterover-knowledge-mining.md]] — historischer Vorläufer, der an Container-Ephemeralität scheiterte
|
|
- [[llm-behavior-persistence.md]] — wie LLMs selbst persistente Verhaltensweisen aufbauen
|
|
- [[../policy/open-knowledge-format-okf.md]] — **OKF v0.1 (Google Cloud, 2026-06-12) formalisiert genau dieses Pattern als offenen Standard. Unser Wiki ist strukturell bereits konform** |