content(wiki): expand stub llm-knowledge-base.md (+20 lines)

This commit is contained in:
Hector 2026-06-16 12:40:15 +02:00
parent 15dcf6428b
commit e4183575ed

View file

@ -1,6 +1,6 @@
---
created: 2026-06-05
updated: 2026-06-05
updated: 2026-06-16
sources: []
tags: [concept, karpathy, wiki]
---
@ -26,3 +26,23 @@ Statt RAG (wiederverarbeitet Rohdaten bei jeder Query) → LLM baut und pflegt e
### 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