Workflow de gestion de base de connaissances (mode LLM Wiki)
Positionnement et application
Ce Skill est une méthodologie indépendante de la plateforme : transformer des connaissances externes en règles de comportement exploitables par l'agent lors de son exécution (Mémoire / Spécifications / Skill). La base de connaissances n'est pas un classeur, c'est un moteur de croissance pour les capacités de l'agent — chaque connaissance entrante doit être distillée, et le seul critère de valeur est : peut-elle directement modifier la décision comportementale de l'agent dans un scénario spécifique ?
- Si le projet possède déjà son propre fichier de spécifications de base de connaissances (ex.
specifications-projet.md), ce fichier fait autorité ; en cas de conflit, les spécifications du projet prévalent. - Lors de l'application sur différentes plateformes/projets, suivre l'architecture et le flux en trois couches de ce Skill ; les noms de répertoires peuvent être localisés. Le répertoire
examples/de ce dépôt fournit des échantillons minimaux directement exécutables.
Architecture en trois couches
| Couche | Répertoire recommandé | Nature |
|---|---|---|
| Raw Sources | collecte-brute/ (articles/discussions/vidéos) | Lecture seule, immuable après collecte |
| The Wiki | base-de-connaissances/ (répertoire.md, experiences-de-collecte.md, journal-des-opérations.md) | Contenu dérivé maintenu par le LLM |
| The Schema | specifications-projet.md + fichiers-prog/configuration/ | Maintenu conjointement par l'humain et le LLM |
Principe clé : Les fichiers originaux restent toujours dans Raw Sources, ils ne sont pas déplacés vers le Wiki. Après validation, une référence dans le répertoire.md est considérée comme une "entrée en base".
Séparation des rôles (obligatoire)
| Rôle | Entité | Responsabilités | Interdictions |
|---|---|---|---|
| Planificateur | Humain | Définir les objectifs de collecte, le contrat de valeur, orienter l'analyse | Ne pas manipuler directement les fichiers |
| Générateur | LLM | Exécuter la collecte, compléter les métadonnées, rédiger le résumé, maintenir le répertoire et le journal | Interdiction de s'auto-évaluer sur la qualité produite |
| Évaluateur | Outil de validation (ex. scripts/validate.py) | Valider indépendamment le format, l'encodage, les métadonnées, les références croisées | Ne pas participer à la génération |
Règle cardinale : le modèle ne doit pas s'auto-évaluer. L'évaluation de la valeur est enregistrée par le Générateur dans le journal des opérations ; la validation (réussite/échec) est tranchée par l'Évaluateur. En cas de désaccord humain, le jugement humain prévaut. En l'absence d'outil de validation dans le projet, effectuer une vérification manuelle selon les six dimensions de l'audit Lint, mais la conclusion ne peut toujours pas être auto-attribuée par le générateur.
Ingest (Ingestion)
Copier cette liste de suivi pour suivre la progression :
- [ ] 1. Contrat de valeur avant collecte (trois questions)
- [ ] 2. Collecte et complétion des métadonnées
- [ ] 3. Lecture du contenu, extraction des informations clés
- [ ] 4. Jugement de valeur (abandon si non conforme)
- [ ] 5. Mise à jour du répertoire.md (résumé + références croisées)
- [ ] 6. Ajout au journal des opérations
- [ ] 7. Évaluation de la distillation et marquage de l'état de mise en œuvre
- [ ] 8. Commit Git
Étape 1 · Contrat de valeur avant collecte — Avant de commencer, répondre aux trois questions et les enregistrer :
- Quel problème cet article résout-il ? Quelle est sa relation avec les connaissances existantes ? (complément / comparaison / extension)
- Dans quelles conditions est-il considéré comme "utile" ? Au moins une condition doit être remplie : introduire un nouveau concept, offrir une perspective comparative, fournir une référence pratique directe.
- À quelle couche du répertoire.md est-il prévu de l'ajouter ? (Théorie fondamentale / Paradigme d'architecture / Pratique d'ingénierie / Outils et ressources / Actualités de la communauté)
Étape 2 · Collecte et métadonnées — Utiliser le moteur de collecte de la plateforme courante pour obtenir le texte original (voir "Abstraction du moteur de collecte"), le stocker dans le sous-répertoire correspondant de Raw Sources, avec un nom de fichier suivant le modèle {source}_{sujet}_{date}.{ext} (ex. github_karpathy_llm_wiki_20260630.md). Champs obligatoires des métadonnées : URL, Date de collecte, Commande de collecte ; champs recommandés : Par, Site, Publié le , Source originale. Le moteur de collecte ne peut généralement extraire qu'une partie des champs ; les autres doivent être complétés.
Étape 4 · Jugement de valeur (avec abandon) — Évaluer par rapport au contrat de l'étape 1. Si aucune condition de valeur n'est clairement remplie (contenu vide, redondance importante, hors sujet par rapport au positionnement de la base de connaissances), enregistrer explicitement la raison de l'abandon dans le journal des opérations, puis sortir ; ne pas forcer la finalisation du processus d'entrée.
Étape 6 · Format du journal des opérations : ## [date] ingest | titre (append-only).
Étape 7 · Évaluation de la distillation — Cette entrée contient-elle des règles atomiques pouvant directement guider le comportement de l'agent ?
| Marqueur | Signification | Action |
|---|---|---|
| 🟢 Mis en œuvre | Règle atomique exécutable | Extraire et écrire dans la Mémoire/Spécifications/Skill, indiquer le titre de la Mémoire dans l'entrée du répertoire.md |
| 🟡 Partiellement mis en œuvre | Partiellement | Indiquer le contenu mis en œuvre et non mis en œuvre, ainsi que la raison |
| 🔵 Référence d'index | Aucune règle exécutable | Décrire brièvement la raison dans le journal des opérations |
Critère de distillation : La règle doit pouvoir modifier la décision comportementale de l'agent dans un scénario spécifique, et non être une idée abstraite ou une information de référence.
Adaptation de la distillation multiplateforme : Dans Qoder, le produit de la distillation est écrit dans le système de Mémoire (classification : méthodologie → task_experience, pièges → common_pitfalls_experience, décisions architecturales → important_decision_experience, etc.) ; sur d'autres plateformes d'agent, le mapper au mécanisme de mémoire persistante/règles de comportement propre à la plateforme, tout en conservant les mêmes critères de jugement et les trois marqueurs colorés.
Étape 8 : git add -A && git commit -m "ingest: titre".
Query (Interrogation)
- Lire d'abord
base-de-connaissances/repertoire.mdpour localiser la page pertinente - Lire en profondeur le ou les fichiers concernés, synthétiser la réponse
- Les bonnes réponses sont rétrocédées (backfill) sous forme de nouvelle page — faire en sorte que l'exploration elle-même produise des intérêts composés
- Ajouter au journal des opérations :
## [date] query | question - Après création d'une nouvelle page :
git add -A && git commit -m "query: question"
Lint (Audit)
Donner la priorité à l'exécution de l'outil de validation du projet (ce dépôt fournit un exemple sans dépendance : python scripts/validate.py <racine_de_la_base_de_connaissances>) ; la décision de l'outil prime sur le jugement manuel. En l'absence d'outil, vérifier manuellement selon les six dimensions :
- Intégrité des métadonnées — Les champs obligatoires (URL, Date de collecte, Commande de collecte) sont-ils tous présents ?
- Exactitude de l'encodage — Double encodage, BOM, caractères de remplacement (U+FFFD)
- Conformité du format — Markdown doit commencer par un H1, et les métadonnées doivent être séparées du corps par
---; JSON doit avoir un champ_metadata - Conformité du nommage — Respecte-t-il le modèle
{source}_{sujet}_{date}? - Références croisées — Les liens du répertoire.md pointent-ils vers des fichiers réels ? Détection des pages orphelines
- Validation de la source — L'URL appartient-elle à la liste blanche des sources ?
Ajouter au journal des opérations : ## [date] lint | périmètre ; en cas de correction, git commit -m "lint: périmètre".
Décroissance du harnais : Le harnais et le processus sont des mécanismes auxiliaires pour compenser les faiblesses du modèle ; ils doivent diminuer de façon monotone à mesure que le modèle progresse. À chaque Lint, examiner : quelles règles de validation ne sont plus déclenchées ? Quelles étapes le modèle a-t-il déjà internalisées ? Les supprimer.
Abstraction du moteur de collecte (adaptation multiplateforme)
Le flux principal n'est lié à aucun outil de collecte ; le moteur de collecte est choisi en fonction de la disponibilité de la plateforme :
| Environnement de plateforme | Méthode de collecte |
|---|---|
| Windows + navigateur Edge | AutoCLI : autocli read "URL" -f markdown -o "chemin de sortie" ; extrait automatiquement Par/Site/URL ; attention : sous PowerShell, les informations de progression sur stderr peuvent signaler à tort ExitCode=1 ; la sortie contenant "Saved to ..." indique le succès |
| Plateforme d'agent avec capacité de lecture web | Utiliser directement l'outil de lecture web (WebFetch, etc.) pour capturer et convertir en Markdown |
| Sources API publiques | Hacker News, Lobsters, etc. — pas besoin de navigateur, requête API directe |
| Aucun outil réseau | L'utilisateur colle le texte original, le sauvegarde manuellement et enregistre honnêtement Commande de collecte comme "collage manuel" |
Quel que soit le moteur, les exigences de métadonnées, de validation et de distillation après entrée en base sont exactement les mêmes. Le champ Commande de collecte enregistre fidèlement le moteur et la commande réellement utilisés (y compris les changements de niveau de service), afin de garantir la reproductibilité.
Référence rapide des conventions
- Nom de fichier :
{source}_{sujet}_{date}.{ext}, source en minuscules - Journal des opérations : append-only, format
## [date] {ingest|query|lint} | brève description - Message de commit :
{ingest|query|lint}: {brève description}; initialisation :init: ligne de base de la base de connaissances - Les leçons tirées des pièges sont structurées et enregistrées dans
experiences-de-collecte.md, sans être mélangées au journal des opérations