Hector 0e02fdbd59 feat: people-pages for all TODO institutions markers

- 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

2026-06-25 21:44:25 +02:00

2.6 KiB

Raw Blame History

created

updated

sources

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

2.6 KiB Raw Blame History