Domain Knowledge Builder — 领域知识库生成器
Gib mir N Paper + Domainname → daraus wird ein abfragbares A-Level-Domainwissensbasis-Skill. Wissensbasis-Struktur: DAG (5 Knotentypen + 10 Beziehungen) + Mentale Modelle + Query-Protokoll + Ehrlichkeitsgrenzen. Qualitätstor: darwin 2.0 mit 9 Bewertungsdimensionen, ≥B+ (80) gilt als erfolgreich generiert.
Kern-Mentale-Modelle
1. Wissen ≠ Definitionen-Aneinanderreihung
Eine brauchbare Domänenwissensbasis ist nicht das bloße Aneinanderreihen von Definitionen/Theoremen, sondern die Destillation der Linsen, mit denen das Fachgebiet die Welt betrachtet (mentale Modelle), gestützt durch Wissensknoten. Die Frage "Mein Datenfluss ist nicht kommutativ, wie hilft mir CP?" – eine reine Definitionssammlung kann das nicht beantworten, eine von mentalen Modellen getriebene Wissensbasis kann eine Position ableiten. Daher muss der Ingest-Prozess einen Schritt zur Destillation mentaler Modelle enthalten (S5), nicht nur Knotenextraktion.
2. Karpathy-Lebenszyklus × DAG-Struktur
- Karpathy LLM Wiki liefert den "Lebenszyklus": Drei Schichten – raw (unveränderliche Quelle) → wiki (von LLM gepflegt) → SCHEMA (Spezifikation) + Drei Workflows – Ingest/Query/Lint. Die Wissensbasis ist ein wachsender Organismus, kein einmalig extrahierter Schnappschuss.
- DAG liefert die "Struktur": Knoten sind nicht nur kategorisiert, sondern über Beziehungen verbunden –
garantiert/verallgemeinert/widerspricht/hängt_ab_von. Theorem A leitet Theorem B ab, Methode C widerspricht Methode D – diese Beziehungen sind der Kern des Domänenwissens, den ein flaches Verzeichnis nicht abbilden kann. - Fusion: Karpathy verwaltet "wie Wissen wächst" (Lebenszyklus), der DAG verwaltet "wie Wissen verbunden ist" (Struktur).
3. Der Generator muss kontrollierbar sein (D7)
Die Essenz eines meta-skills (im Gegensatz zu einem normalen Skill) ist die Generierung anderer Skills – viele FS-Schreibvorgänge, Subagent-Spawns, Netzwerk. Das muss kontrollierbar sein: Jeder Ingest muss per Checkpoint wiederherstellbar sein, bei nicht bestandenem darwin-Tor muss git revert möglich sein, jeder Knoten muss rückverfolgbar sein (Provenance), und das erneute Ausführen mit denselben Papers muss dieselbe Knoten-ID erzeugen (Determinismus). Sonst ist das Skill nach 6 Monaten nicht mehr wartbar. Diese vier Säulen (Rückrollbarkeit/Prüfbarkeit/Determinismus/Vorabprüfung) sind der Standard für Generator-Skills (darwin-Dimension 9, Subklasse generator).
Wann verwenden / Wann nicht verwenden
Verwenden:
- "Erstelle für einen Experten ein Berater-Skill, das beantworten kann 'Was denkt Experte X zu Y?' + 'Warum (Begründung)'"
- "Verwandle die Papers/Interviews/Blogs eines Experten in einen zwei-motoren-Antrieb aus Mentalem Modell und Wissen"
- "Mach aus diesen wenigen Papers eine abfragbare Wissensbasis"
- "Erstelle eine DAG-Wissensbasis für die Domäne X"
- "Ich habe N PDFs und möchte einen Domänenassistenten, der Positionen ableiten kann"
Routing-Unterscheidung:
- Reine Domänenwissensbasis (keine Expertenperspektive) → DKB-Standardmodus (
examples/conformal-prediction) - Expertenperspektive (mit Expertenurteilen + Begründungen) → Diese Erweiterung (Expert-Advisor-Modus)
Nicht verwenden (an andere Skills weiterleiten):
- "Was ist Split CP?" → Anfrage an existierende CP-Wissensbasis (
examples/conformal-prediction) - "Fasse dieses Buch zusammen" →
book-to-skillfür die direkte Generierung eines Skills aus einem Buch - "Destilliere die Denkweise einer Person (kein Domänenwissen)" →
nuwa-skill
Architektur (5 Schichten)
domain-knowledge-skill/
├── SKILL.md # Diese Datei (meta-skill Einstieg)
├── schema/schema.md # Wissensspezifikation (5 Typen + 10 Beziehungen + D7 Kontrollierbarkeit)
├── pipeline/ # Ingest/Query/Lint Workflows
│ ├── ingest.md # 7-Schritte-Pipeline-Vertrag (S1-S7)
│ ├── query.md # 5-Schritte-DAG-Traversierungsabfrage
│ ├── lint.md # Struktur- + Generator-Compliance-Prüfung
│ ├── run-dag-pipeline.js # Workflow-Orchestrierungsskript
│ └── state/ # D7 Laufzeit
│ ├── init_run.py # UUID + git + run-manifest + preflight
│ └── lint_d7.py # Vier-Säulen-Lint
├── engines/ # Wiederverwendbare Engines
│ ├── book_to_skill/ # virgiliojr94 Extraktions-Engine (technical Modus)
│ ├── darwin-rubric.md # 9-dimensionale Qualitätsbewertung (9. Dimension mit zwei Subklassen)
│ └── nuwa-validation.md # Domänenspezifische dreifache Validierung
├── references/ # Vorlagen (in Planung)
└── examples/
└── conformal-prediction/ # Goldstandard (88 Punkte A-, Lazy Loading)
7-Schritte-Ingest-Pipeline (D3 Phasenweise Aufteilung)
Determinismus (workflow fan-out) Interaktion/Urteil (subagent chain)
───────────────────── ─────────────────────
S1 Extraktion ──┬─▶ S2×N parallel ──┐
└─▶ ... ├─▶ S3 Merge ──▶ S4 Navigation ──▶ S5 Mentale Modelle ──▶ S6 Validierung ──▶ S7 Assembly ──▶ darwin Tor
│ (widerspricht (parallel 3) (dreifache Validierung)(fresh) (<4K) (≥B+)
│ manuelle Bestätigung)
Detaillierter Vertrag in pipeline/ingest.md. Wichtige Einschränkungen:
- S1 muss docling preflight durchführen (Schema §12.4, technical Modus harte Abhängigkeit)
- S2 Knoten-ID folgt
<type>-<source>-<canonical-term>(Schema §10 Determinism) - Bei
widerspricht/garantiert_nicht-Kanten in S3 musscontact_supervisorzur manuellen Bestätigung erfolgen - S5 lädt
engines/nuwa-validation.mdfür die dreifache Validierung - S6/S7 verwenden Fresh-Context-Subagenten (unabhängige Validierung/Bewertung, keine Selbstbewertung)
- Während des gesamten Prozesses wird für jeden Knoten Provenance geschrieben (generated_by_step/run_id/source_span)
Qualitätstor (darwin 2.0, 9 Dimensionen)
engines/darwin-rubric.md laden, Fresh-Context-Subagent bewertet:
| Dimension | Gewicht | Fokus |
|---|---|---|
| ① Strukturelle Vollständigkeit ② Klarheit ③ Inhaltliche Vollständigkeit ④ Handhabbarkeit | 15%×4 | Frontmatter/Workflows/Abdeckung/Ausführbarkeit |
| ⑤ Genauigkeit ⑥ Konsistenz | 10%×2 | Exakte Theorem-Quellen/Keine gebrochenen Referenzen |
| ⑦ Ausführungseffizienz ⑧ Robustheit | 8%/7% | Token-Budget/Ehrlichkeitsgrenzen |
| ⑨ Meta-Skill-Compliance | 5% | Generator-Skill-Subklasse: Vier Säulen |
9. Dimension mit zwei Subklassen (Orakel-Einsicht): query-skill (CP-Typ, schreibgeschützt) vs generator-skill (dieser Skill-Typ, erlaubt kontrolliertes Schreiben, muss aber die Vier Säulen erfüllen: Rückrollbar/Prüfbar/Deterministisch/Vorabprüfung). Dadurch kann der Generator fair das Qualitätstor passieren.
Sperrklinkenmechanismus: darwin <B+ → git revert zur letzten Stufe → Diagnose der schlecht bewerteten Dimension → Reparatur und Neubewertung. Nach 3 aufeinanderfolgenden Runden ohne Verbesserung → Vorschlag für exploratives Rewrite.
Verbleib der 5 Referenzquellen
| Quelle | Verbleib | Art der Wiederverwendung |
|---|---|---|
| Karpathy LLM Wiki | schema/ + pipeline/ | Saubere Vererbung: 3-Schichten-Architektur + Ingest/Query/Lint-Lebenszyklus |
| book-to-skill | engines/book_to_skill/ | Sauberer Vendor: Extraktions-Engine (technical Modus behält Formeln bei) |
| nuwa-skill | engines/nuwa-validation.md | Methodische Destillation: Dreifach-Validierung (ohne expression DNA) |
| darwin-skill | engines/darwin-rubric.md | Doppelquellen-Rekonstruktion: 9 Dimensionen aus validation-report + alte 8-Dimensionen-Referenz |
| dag-executor | Nur philosophische Referenz | Wave-basierte Parallelität + Dateisperren (Implementierung über pi workflow/subagent) |
examples/conformal-prediction (Goldstandard)
Lazy Loading – nimmt nicht am Standard-Skill-Routing teil, wird nur bei expliziter Anforderung aktiviert:
- v1.1.0 / 50 Knoten / 138 Kanten / 0 Brüche / darwin 88 Punkte (A-)
- 3 Quellen (Angelopoulos 2022 / Teneggi 2025 / Min 2026)
- Verwendung: (1) Als Qualitätsbenchmark beim Ingest neuer Domänen; (2) Bei expliziter Abfrage "Konformale Vorhersage" durch den Benutzer laden
Einschränkungen und Ehrlichkeitsgrenzen
Harte Einschränkungen:
- docling ist harte Abhängigkeit im technical Modus (akademische Paper ohne Formeln = wertlos, nicht kompromittierbar)
- SKILL.md body < 4K Tokens (Kompaktierung durch Abschneiden am Ende)
- Alle Knoten-Provenance ist Pflicht (bei neuem Ingest)
- Generierter Skill-Pfad nur relativ zum Skill-Root (gegen Linkbruch)
Nicht möglich:
- Intuition kann nicht destilliert werden – das Framework kann extrahieren, Inspiration nicht
- Nicht das gesamte Domänenumfeld abdecken – nur die vom Benutzer bereitgestellten Quellen
- Keine automatische Beurteilung der Quellenqualität – Garbage in, garbage out (schlechte Papers → schlechte Wissensbasis)
- Kann Expertenurteil nicht ersetzen – Kanten des Typs
widersprichtmüssen manuell bestätigt werden
Bekannte Einschränkungen:
- Version-Drift bei docling kann die Extraktion stillschweigend verschlechtern (kein Test, der dies erfasst)
- Die Extraktion von
canonical-termdurch das LLM ist nicht vollständig deterministisch (bei zweimaliger Extraktion desselben Papers kann der Hash unterschiedlich sein; Lint wird dies melden) - Hohe Extraktionskosten bei großen Papers (>50K Tokens) – empfohlen wird Ingest in Batches
Schnellstart
Benutzer: Erstelle mir eine Wissensbasis für die Domäne diffusionsmodelle, mit den Papers in ~/papers/ddpm.pdf, ~/papers/score-sde.pdf
→ Dieses Skill:
1. Bestätigt Domäne + Quellen + führt docling preflight durch
2. Führt die 7-Schritte-Pipeline aus (pipeline/ingest.md)
3. darwin bewertet, bei ≥B+ wird das generierte Skill nach ~/.pi/agent/skills/diffusion-models/ ausgeliefert
4. Der Benutzer kann das generierte Skill später abfragen
Siehe den vollständigen Vertrag in pipeline/ingest.md.
Dieses meta-skill Version: v0.1 | 5 Quellen-Wiederverwendung + D7 Kontrollierbarkeit + darwin 2.0 Qualitätstor | Goldstandard: examples/conformal-prediction (88/A-)