Domain Knowledge Builder — Générateur de bases de connaissances par domaine
Donnez-moi N articles + un nom de domaine → Je produis une compétence de base de connaissances interrogable de qualité A. Structure de la base : DAG (5 types de nœuds + 10 relations) + modèles mentaux + protocole de requête + limites honnêtes. Porte de qualité : notation darwin 2.0 (9 dimensions), score ≥ B+ (80) pour valider la génération.
Modèles mentaux fondamentaux
1. La connaissance n'est pas une accumulation de définitions
Une base de connaissances utile ne se limite pas à recopier des définitions et théorèmes. Elle consiste à distiller la lentille avec laquelle le domaine regarde le monde (modèles mentaux), puis à soutenir ces lentilles avec des nœuds de connaissance. Si on demande : « Mon flux de données est non commutatif, comment CP peut m'aider ? » — une simple accumulation de définitions ne répondra pas ; une base de connaissances pilotée par les modèles mentaux peut inférer une position. C'est pourquoi le processus d'ingestion doit inclure une étape de distillation des modèles mentaux (S5), et pas seulement l'extraction de nœuds.
2. Cycle de vie de Karpathy × structure DAG
- Le cycle de vie de Karpathy LLM Wiki : raw (source immuable) → wiki (maintenu par LLM) → SCHEMA (norme) en trois couches + trois workflows (Ingest/Query/Lint). La base de connaissances est un organisme vivant, pas un instantané unique.
- Le DAG fournit la structure : les relations entre nœuds ne sont pas de simples catégories, ce sont des relations —
guarantees/generalizes/contradicts/depends_on. Le théorème A découle du théorème B, la méthode C contredit la méthode D : ces relations sont au cœur de la connaissance du domaine, un répertoire plat ne peut pas les porter. - Fusion : Karpathy gère « comment la connaissance croît » (cycle de vie), le DAG gère « comment la connaissance se connecte » (structure).
3. Le générateur doit être contrôlable (D7)
Une méta-compétence n'est pas une compétence ordinaire : elle génère d'autres compétences — beaucoup d'écriture FS, lancement de sous-agents, réseau. Cela doit être contrôlable : chaque ingestion peut être reprise via checkpoint, git revert si darwin échoue, chaque nœud est traçable (provenance), la même exécution sur le même article produit les mêmes IDs de nœuds (déterminisme). Sinon, la maintenance devient impossible après 6 mois. Ces quatre piliers (rollback / auditabilité / déterminisme / pré-vérification) sont la norme de conformité pour les compétences génératrices (sous-classe generator de la 9e dimension darwin).
Quand l'utiliser / Quand ne pas l'utiliser
À utiliser :
- « Construire une compétence de consultant capable de répondre à « Que pense l'expert de X ? » + « Pourquoi (preuve) » »
- « Transformer les articles, interviews, blogs d'un expert en un double moteur mental + de connaissances »
- « Convertir ces quelques articles en une base de connaissances interrogable »
- « Construire une base de connaissances DAG pour le domaine X »
- « J'ai N PDF, je veux un assistant de domaine capable d'inférer une position »
Différenciation de routage :
- Base de connaissances pure (sans perspective d'expert) → mode de base DKB (
examples/conformal-prediction) - Perspective d'expert (avec jugement + preuves de l'expert) → cette extension (mode expert-advisor)
Ne pas utiliser (router vers une autre compétence) :
- « Qu'est-ce que le Split CP ? » → interroger la base de connaissances CP existante (
examples/conformal-prediction) - « Résume ce livre » → utiliser book-to-skill pour générer directement une compétence sur un seul livre
- « Distiller la pensée d'une personne (sans connaissance du domaine) » → utiliser nuwa-skill
Architecture (5 couches)
domain-knowledge-skill/
├── SKILL.md # Ce fichier (point d'entrée de la méta-compétence)
├── schema/schema.md # Spécification de la connaissance (5 types + 10 relations + contrôlabilité D7)
├── pipeline/ # Workflows Ingest/Query/Lint
│ ├── ingest.md # Contrat de pipeline en 7 étapes (S1-S7)
│ ├── query.md # Requête en 5 étapes de parcours DAG
│ ├── lint.md # Vérification de structure + conformité Generator
│ ├── run-dag-pipeline.js # Script d'orchestration du workflow
│ └── state/ # Exécution D7
│ ├── init_run.py # UUID + git + run-manifest + preflight
│ └── lint_d7.py # Lint des quatre piliers
├── engines/ # Moteurs réutilisables
│ ├── book_to_skill/ # Moteur d'extraction virgiliojr94 (mode technique)
│ ├── darwin-rubric.md # Notation qualité 9 dimensions (9e dimension : double sous-classe)
│ └── nuwa-validation.md # Triple validation spécifique au domaine
├── references/ # Modèles (en planification)
└── examples/
└── conformal-prediction/ # Référence dorée (88 points, A-, chargement paresseux)
Pipeline d'ingestion en 7 étapes (découpage progressif D3)
Déterministe (fan-out du workflow) Interactif / Jugement (chaîne de sous-agents)
───────────────────── ─────────────────────
S1 Extraction ──┬─▶ S2×N parallèle ──┐
└─▶ ... ├─▶ S3 Fusion ──▶ S4 Navigation ──▶ S5 Modèles mentaux ──▶ S6 Validation ──▶ S7 Assemblage ──▶ Porte darwin
│ (contradictions (parallèle 3) (triple validation) (contexte frais) (<4K) (≥B+)
│ confirmation manuelle)
Voir le contrat détaillé dans pipeline/ingest.md. Contraintes clés :
- S1 doit obligatoirement faire un preflight docling (schema §12.4, dépendance dure en mode technique)
- S2 : IDs de nœuds suivent
<type>-<source>-<canonical-term>(schema §10 Déterminisme) - S3 : Les arêtes
contradicts/does_not_guaranteedoivent déclenchercontact_supervisor(confirmation manuelle) - S5 : Charger
engines/nuwa-validation.mdpour la triple validation - S6/S7 : Utiliser un sous-agent à contexte frais (validation/notation indépendante, pas d'auto-évaluation)
- Chaque étape écrit la provenance du nœud (generated_by_step/run_id/source_span)
Porte de qualité (darwin 2.0, 9 dimensions)
Charger engines/darwin-rubric.md, sous-agent à contexte frais pour la notation :
| Dimension | Poids | Point d'attention |
|---|---|---|
| ① Intégrité structurelle ② Clarté ③ Complétude du contenu ④ Opérationnalité | 15%×4 | frontmatter/workflow/couverture/exécutable |
| ⑤ Exactitude ⑥ Cohérence | 10%×2 | Précision des théorèmes/aucune référence brisée |
| ⑦ Efficacité d'exécution ⑧ Robustesse | 8%/7% | Budget de jetons/limites honnêtes |
| ⑨ Conformité méta-compétence | 5% | Sous-classe generator-skill : quatre piliers |
Double sous-classe de la 9e dimension (aperçu oracle) : query-skill (type CP, lecture seule) vs generator-skill (ce type de compétence, écriture contrôlée autorisée mais doit satisfaire les quatre piliers : rollback / auditabilité / déterminisme / pré-vérification). Cela permet aux générateurs de passer équitablement la porte de qualité.
Mécanisme de cliquet : darwin < B+ → git revert de la dernière étape → diagnostiquer les dimensions faibles → corriger et réévaluer. 3 cycles consécutifs sans amélioration → proposer une réécriture exploratoire.
Devenir des 5 sources de référence
| Source | Destination | Mode de réutilisation |
|---|---|---|
| Karpathy LLM Wiki | schema/ + pipeline/ | Héritage propre : architecture 3 couches + cycle de vie Ingest/Query/Lint |
| book-to-skill | engines/book_to_skill/ | Vendor propre : moteur d'extraction (mode technique conserve les formules) |
| nuwa-skill | engines/nuwa-validation.md | Distillation méthodologique : triple validation (sans l'ADN d'expression) |
| darwin-skill | engines/darwin-rubric.md | Reconstruction à partir de deux sources : 9 dimensions du rapport de validation + comparaison avec l'ancienne version 8 dimensions |
| dag-executor | Référence philosophique uniquement | Parallélisme basé sur les ondes + verrouillage de fichiers (implémentation via pi workflow/subagent) |
examples/conformal-prediction (Référence dorée)
Chargement paresseux — ne participe pas au routage par défaut de la compétence, activé sur demande explicite :
- v1.1.0 / 50 nœuds / 138 arêtes / 0 rupture / darwin 88 points (A-)
- 3 sources (Angelopoulos 2022 / Teneggi 2025 / Min 2026)
- Utilisation : (1) comme référence de qualité lors de l'ingestion d'un nouveau domaine ; (2) charger lorsque l'utilisateur interroge explicitement « prédiction conforme »
Contraintes et limites honnêtes
Contraintes dures :
- docling est une dépendance dure pour le mode technique (articles académiques sans formules = sans valeur, ne peut pas être sacrifié)
- Corps de SKILL.md < 4K tokens (la compaction tronque depuis la fin)
- Tous les nœuds doivent avoir une provenance (nouvelle ingestion)
- Les chemins de compétence générée utilisent uniquement des chemins relatifs à la racine de la compétence (prévient les liens brisés)
Impossibilités :
- Ne peut pas distiller l'intuition — le cadre extrait, l'inspiration ne peut pas être extraite
- Ne peut pas couvrir tous les articles du domaine — ne couvre que les sources fournies par l'utilisateur
- Ne peut pas juger automatiquement la qualité des sources — garbage in garbage out (articles de faible qualité → base de connaissances de faible qualité)
- Ne peut pas remplacer le jugement d'un expert — les arêtes
contradictsdoivent être confirmées manuellement
Limites connues :
- Les variations de version de docling peuvent silencieusement dégrader l'extraction (aucun test pour les capturer)
- L'extraction LLM des termes canoniques n'est pas entièrement déterministe (deux extractions du même article peuvent donner des hash différents, Lint le signalera)
- Coût élevé d'extraction pour les grands articles (>50K tokens) (suggérer une ingestion par lots)
Prise en main rapide
Utilisateur : Construis-moi une base de connaissances pour le domaine diffusion-models, articles dans ~/papers/ddpm.pdf, ~/papers/score-sde.pdf
→ Cette compétence :
1. Confirme le domaine + sources + preflight docling
2. Exécute le pipeline en 7 étapes (pipeline/ingest.md)
3. Note via darwin, si ≥B+ alors livre la compétence générée dans ~/.pi/agent/skills/diffusion-models/
4. L'utilisateur peut ensuite interroger la compétence générée
Voir pipeline/ingest.md pour le contrat complet.
Cette méta-compétence version : v0.1 | Réutilisation de 5 sources + contrôlabilité D7 + porte de qualité darwin 2.0 | Référence dorée : examples/conformal-prediction (88/A-)