Maintenance de l'encyclopedia LLM : dérive, contradictions et révision

Un wiki LLM échoue lorsque les faits anciens restent plausibles, les contradictions deviennent polies et les résumés générés dérivent de leurs sources.

La maintenance est le véritable produit de tout système de connaissances compilées. Créer des pages de wiki est straightforward par rapport à les maintenir dignes de confiance au fil des mois d’ingestion, de modifications, de réécritures et de nouvelles sources.

Cet article couvre le côté opérationnel des systèmes de wiki LLM : détection de dérive, vérification des contradictions, discipline des citations, linting, révision Git et flux de maintenance. Il suppose que vous comprenez déjà le modèle de base décrit dans LLM Wiki - Connaissances compilées que le RAG ne peut pas remplacer : les sources brutes sont compilées en pages Markdown durables que les humains et les agents peuvent interroger ultérieurement. Le point de vue calme mais tranchant est qu’un wiki LLM sans maintenance n’est qu’un cimetière de connaissances mieux présenté.

Ce qui rend la maintenance du wiki LLM différente

Les wikis traditionnels se dégradent parce que les gens arrêtent de les mettre à jour. Les systèmes RAG dérivent parce que le corpus change, les fragments deviennent obsolètes, les métadonnées sont faibles et la récupération continue de trouver des fragments plausibles mais dépassés. La raison plus profonde est que la récupération et la représentation résolvent des problèmes différents : la récupération peut être relancée contre des données fraîches, mais une représentation que vous avez déjà compilée doit être activement maintenue honnête.

Un wiki LLM a un mode de défaillance différent. Il peut paraître propre même lorsqu’il est faux.

Les pages peuvent être bien formatées. Les liens peuvent fonctionner. Les résumés peuvent paraître équilibrés. Mais sous cette surface soignée, le système peut avoir omis des faits critiques, fusionné des concepts incompatibles, cité des résumés au lieu des sources, ou préservé une ancienne décision comme si elle s’appliquait toujours.

C’est pourquoi la maintenance du wiki LLM doit vérifier à la fois la structure et le sens.

L’objectif de la maintenance

L’objectif n’est pas de rendre chaque page parfaite. C’est trop coûteux, et cela conduit généralement à l’abandon des systèmes.

L’objectif est de maintenir le wiki utile, inspectable et récupérable.

Un wiki LLM maintenu doit faciliter la réponse à ces questions :

• Quelles sources étayent cette affirmation ?
• Quand cette page a-t-elle été révisée pour la dernière fois ?
• Ce concept a-t-il changé ?
• Y a-t-il des pages contradictoires ?
• Ce résumé est-il toujours actuel ?
• L’agent a-t-il réécrit plus qu’il ne le devait ?
• Pouvons-nous annuler une mauvaise mise à jour ?
• Un humain peut-il comprendre pourquoi la page dit ce qu’elle dit ?

Si la réponse est non, le problème n’est pas seulement la qualité du contenu. C’est un problème de conception du système.

Une boucle de maintenance simple

Un wiki LLM utile a besoin d’une boucle répétable. La boucle doit être assez simple pour être exécutée fréquemment et assez stricte pour capturer la dérive avant qu’elle ne devienne invisible.

Cette boucle n’est pas glamour. C’est tout le point.

Un système de connaissances devient durable grâce à une maintenance ennuyeuse : préservation des sources, révision explicite, structure prévisible et petites mises à jour sûres. Le même instinct conduit aux notes evergreen : une note ou une page wiki n’accumule de la valeur que si quelqu’un continue de l’affiner au lieu de la laisser se dégrader après la première ébauche.

Types de dérive dans un wiki LLM

La dérive des connaissances n’est pas une seule chose. Différents types de dérive nécessitent des vérifications différentes. Un bon système de maintenance doit les nommer clairement.

Dérive des sources

La dérive des sources se produit lorsque le matériel source sous-jacent change.

Par exemple, un outil publie une nouvelle version, une politique est mise à jour, une API change ou un fournisseur déprécie une ancienne fonctionnalité. L’ancienne page du wiki peut encore être exacte pour la version précédente, mais fausse pour l’utilisation actuelle.

La dérive des sources est dangereuse parce que l’ancienne affirmation peut encore être vraie dans un contexte historique. Le problème n’est pas que l’affirmation est fausse. Le problème est qu’elle ne répond plus à la question actuelle.

Réponse de maintenance :

• Enregistrer les dates des sources
• Enregistrer les dates de dernière révision
• Marquer clairement les pages spécifiques à une version
• Lier les anciennes pages aux pages qui les remplacent
• Éviter de mélanger les anciennes et nouvelles versions sans étiquettes

Dérive conceptuelle

La dérive conceptuelle se produit lorsque la signification d’un terme change avec le temps.

C’est courant dans l’IA et l’architecture logicielle. Des termes comme “agent”, “mémoire”, “RAG”, “flux de travail”, “utilisation d’outils”, “sortie structurée” et “ingénierie contextuelle” peuvent changer de signification rapidement.

Un wiki peut accidentellement préserver plusieurs significations du même terme sans expliquer la différence. Cela crée des pages confuses qui sonnent cohérentes mais combinent des idées incompatibles.

Réponse de maintenance :

• Maintenir des pages de glossaire
• Ajouter des sections “signification dans ce wiki”
• Séparer les concepts surchargés en pages distinctes
• Lier explicitement les significations apparentées
• Éviter de laisser le modèle fusionner silencieusement les termes

Dérive terminologique

La dérive terminologique est plus petite que la dérive conceptuelle mais reste nuisible.

Elle se produit lorsque le wiki utilise plusieurs noms pour la même chose : “Wiki LLM”, “base de connaissances compilées”, “wiki maintenu par IA”, “wiki maintenu par agent” et “base de connaissances Markdown”.

Une certaine variation est acceptable. Trop de variation brise la recherche, les liens et la révision.

Réponse de maintenance :

• Définir des noms de page canoniques
• Conserver les alias dans les métadonnées front matter ou de la page
• Rediriger les pages dupliquées
• Linter pour les titres quasi-dupliqués
• Utiliser un texte d’ancre cohérent dans les liens internes

Dérive décisionnelle

La dérive décisionnelle se produit lorsque une décision passée reste documentée mais ne reflète plus la pratique actuelle.

Par exemple, une page pourrait indiquer que le projet utilise le RAG vectoriel pour toute recherche de documents, tandis que les nouvelles pages décrivent un flux de travail de wiki LLM. Les deux déclarations peuvent être historiquement vraies, mais le wiki doit montrer laquelle est actuelle.

Cela importe pour les notes d’architecture, les processus d’ingénierie, la stratégie de contenu et les outils internes. La même discipline s’applique aux registres de décision dans le développement piloté par l’IA : une page de décision n’est fiable que si les choix dépassés sont marqués comme tels plutôt que d’être écrasés silencieusement.

Réponse de maintenance :

• Marquer les décisions comme proposées, acceptées, dépassées ou rejetées
• Conserver les dates de décision
• Lier les décisions dépassées à leurs remplacements
• Préserver le contexte historique
• Éviter de supprimer les anciennes décisions sans trace

Dérive des citations

La dérive des citations se produit lorsque une page cite une source, mais que l’affirmation ne correspond plus à ce que dit la source.

Cela peut arriver après une réécriture. La citation reste en place, mais la phrase autour change. La page semble toujours sourcée, mais la citation ne soutient plus l’affirmation.

C’est l’un des modes de défaillance les plus sérieux du wiki LLM car il crée une confiance fausse.

Réponse de maintenance :

• Vérifier le soutien des citations au niveau des affirmations
• Éviter de citer uniquement des résumés
• Conserver les sources brutes
• Exiger des citations pour les affirmations importantes
• Signaler les paragraphes avec des sources mais sans soutien direct
• Réviser les changements de citation dans les diffs Git

Dérive structurelle

La dérive structurelle se produit lorsque le wiki perd lentement sa navigabilité.

De nouvelles pages sont créées au lieu de mettre à jour les anciennes. Les pages d’index prennent du retard. Les pages dupliquées apparaissent. Les pages orphelines s’accumulent. Les pages apparentées cessent de se lier les unes aux autres.

Le wiki contient encore des connaissances utiles, mais les trouver et y faire confiance devient plus difficile.

Réponse de maintenance :

• Linter pour les pages orphelines
• Maintenir les pages d’index
• Détecter les sujets dupliqués
• Exiger des backlinks pour les pages canoniques
• Archiver plutôt que disperser
• Garder les rôles des dossiers clairs

Les fichiers de maintenance essentiels

Un wiki LLM ne doit pas reposer sur la mémoire, les vibes ou le prompting répété. Il a besoin de fichiers d’exploitation qui disent aux humains et aux agents comment le maintenir.

Une structure pratique peut ressembler à ceci :

llm-wiki/
  raw/
    sources/
    transcripts/
    documents/
  wiki/
    index.md
    concepts/
    entities/
    projects/
    decisions/
  maintenance/
    review-log.md
    lint-report.md
    stale-pages.md
    contradiction-report.md
  rules/
    AGENTS.md
    schema.md
    style-guide.md
    citation-policy.md
    source-policy.md

Les noms exacts n’ont pas d’importance. Les rôles si.

Le wiki a besoin de stockage de sources, de pages compilées, d’artefacts de révision et de règles qui survivent entre les sessions.

AGENTS.md

AGENTS.md devrait expliquer comment l’agent est autorisé à travailler.

Il devrait répondre à des questions comme :

• L’agent doit-il mettre à jour les pages existantes avant d’en créer de nouvelles ?
• Quand devrait-il demander une révision ?
• Comment devrait-il citer les sources ?
• Peut-il réorganiser les dossiers ?
• Peut-il réécrire les anciennes pages ?
• Que devrait-il faire avec les contradictions ?
• Que ne devrait-il jamais supprimer ?

Une règle utile est :

Privilégier les petites mises à jour étayées par des sources plutôt que les réécritures larges.

Cette seule phrase empêche de mauvaises habitudes de maintenance. Elle dessine également une frontière utile par rapport à la mémoire des agents : la mémoire façonne le comportement d’un agent dans le moment, tandis que le fichier de règles du wiki façonne ce que l’agent est autorisé à changer dans la base de connaissances partagée.

schema.md

schema.md devrait définir la structure de la page.

Par exemple :

# Titre de la page

## Résumé
Résumé court et actuel.

## Affirmations clés
- Affirmation avec référence source.
- Affirmation avec référence source.

## Statut actuel
Actuel, historique, dépassé, brouillon ou incertain.

## Détails
Explication compilée principale.

## Pages apparentées
Liens internes.

## Sources
Références aux sources brutes.

## Notes de révision
Date de dernière révision et réviseur.

Un schéma n’a pas besoin d’être rigide. Mais sans schéma, le wiki devient une pile d’essais incohérents. Le schéma donne à l’agent quelque chose à préserver.

citation-policy.md

La politique de citation devrait dire ce qui nécessite une source. Au minimum, exiger des citations pour :

• Affirmations techniques
• Comparaisons
• Comportement des produits
• Déclarations spécifiques à une version
• Résultats de benchmarks
• Tarifs
• Affirmations juridiques ou de conformité
• Affirmations sur l’état actuel
• Affirmations copiées ou dérivées d’une source

Une bonne politique de citation dit aussi ce qu’il ne faut pas faire. Ne citer pas une page compilée comme si c’était la source originale. Ne pas attacher de citations à des paragraphes qu’elles ne soutiennent pas. Ne pas conserver une citation après avoir réécrit une affirmation sauf si la source la soutient toujours.

La discipline des citations est la différence entre un wiki LLM utile et une confiance décorative.

source-policy.md

La politique des sources devrait définir comment les sources brutes sont stockées.

Par exemple :

• Conserver les fichiers originaux lorsque possible
• Préserver les URLs et les dates d’accès
• Stocker les notes copiées séparément des résumés générés
• Enregistrer le type de source
• Marquer les sources de faible confiance
• Éviter d’écraser le matériel brut
• Conserver les sources dépassées lorsqu’elles expliquent des décisions historiques

Cette politique protège le wiki d’une erreur commune : résumer une source, jeter l’original, puis traiter le résumé comme une preuve.

Ce n’est pas de la gestion des connaissances. C’est une compression avec perte.

Ce qu’un linter de wiki LLM devrait vérifier

Un linter devrait vérifier la structure en premier. Les problèmes structurels sont plus faciles à automatiser et révèlent souvent des problèmes sémantiques plus profonds.

Les vérifications structurelles utiles incluent :

• Liens internes brisés
• Pages orphelines
• Titres dupliqués
• Sections de source manquantes
• Dates de révision manquantes
• Pages sans backlinks
• Sections vides ou de remplissage
• Pages très longues sans structure de section
• Pages sans liens entrants depuis un index
• Conventions de nommage incohérentes
• Front matter invalide
• Pages “actuelles” obsolètes dépassant un seuil de révision

Ces vérifications ne prouvent pas que la connaissance est vraie. Elles prouvent que le wiki est encore maintenable. C’est un point de départ nécessaire.

Vérifications sémantiques

Les vérifications sémantiques sont plus difficiles mais plus précieuses.

Les vérifications sémantiques utiles incluent :

• Affirmations sans soutien direct de la source
• Deux pages faisant des affirmations incompatibles
• Anciennes décisions présentées comme actuelles
• Concepts dupliqués avec des noms différents
• Une page de concept mélangeant plusieurs significations
• Résumés omettant des contraintes connues
• Affirmations “meilleur” ou “recommandé” sans critères
• Affirmations spécifiques à une version sans étiquettes de version
• Pages qui contredisent des sources plus récentes

Ces vérifications ne devraient pas réécrire automatiquement le wiki. Elles devraient généralement produire un rapport pour révision.

Le modèle plus sûr est :

Détecter automatiquement.
Expliquer clairement.
Mettre à jour délibérément.
Réviser les changements risqués.

Détection des contradictions

La détection des contradictions n’est pas simplement demander à un LLM si deux pages se contredisent.

Cela peut aider, mais c’est trop vague. Une meilleure approche est de comparer les affirmations.

Un flux de travail de contradiction peut ressembler à ceci :

Cela fonctionne mieux parce que de nombreuses contradictions apparentes ne sont pas de vraies contradictions.

Une page peut décrire la version 1.0 et une autre la version 2.0. Une page peut décrire l’usage personnel et une autre l’usage entreprise. Une page peut décrire l’objectif de conception et une autre la réalité de l’implémentation.

Le rapport de contradiction devrait inclure :

• Affirmations contradictoires
• Pages impliquées
• Références des sources
• Contexte de date ou de version
• Explication probable
• Résolution suggérée
• Si une révision humaine est requise

Ne laissez pas l’agent résoudre silencieusement les contradictions en mélangeant les deux affirmations dans un compromis vague. Cela crée un non-sens fluide.

Comment résoudre les contradictions

Il y a plusieurs façons valides de résoudre une contradiction.

• Si une affirmation est dépassée, marquez-la comme telle et liez-la à la page plus récente.
• Si les deux affirmations sont vraies dans des contextes différents, séparez clairement le contexte.
• Si les sources sont en désaccord, préservez le désaccord et expliquez-le.
• Si la page du wiki a inventé ou généralisé excessivement une affirmation, supprimez-la ou resserrez-la.
• Si la contradiction reflète une décision réelle non résolue, créez ou mettez à jour une page de décision.

L’objectif n’est pas de supprimer toute tension. Une certaine tension est utile. Un bon wiki montre où la connaissance est établie et où elle reste incertaine.

Révision des pages obsolètes

Toute page compilée devrait avoir un statut de révision.

Un bloc de métadonnées simple peut suffire :

status: current
last_reviewed: 10-07-2026
review_after: 10-10-2026
source_confidence: medium

Pour les sujets à évolution rapide, utilisez des fenêtres de révision courtes. Pour les concepts stables, utilisez des fenêtres plus longues.

L’intervalle est moins important que l’habitude. Une page sans date de révision est une page qui finira par mentir silencieusement.

Mises à jour conscientes des sources

Quand une nouvelle source arrive, l’agent ne devrait pas simplement écrire une nouvelle page de résumé.

Il devrait demander :

• Cela met-il à jour un concept existant ?
• Cela dépasse-t-il une source précédente ?
• Cela contredit-il une page existante ?
• Cela ajoute-t-il une nouvelle entité ou un terme ?
• Cela change-t-il une recommandation ?
• Cela nécessite-t-il une mise à jour de l’index ?
• Cela affecte-t-il les pages de décision ?

Un bon flux d’ingestion met à jour le wiki comme un graphe, pas comme une pile de résumés isolés.

C’est pourquoi une seule source peut toucher de nombreuses pages. C’est normal. Le défi de maintenance est de rendre ces mises à jour petites, révisables et traçables.

Révision avec les diffs Git

Git est l’un des meilleurs outils de maintenance pour un wiki LLM.

Non pas parce que Git est à la mode, mais parce que la connaissance générée a besoin d’un historique de changement révisable. Un diff Git montre ce que l’agent a changé, supprimé, déplacé ou reformulé.

Utilisez Git pour réviser :

• Nouvelles pages
• Sections supprimées
• Affirmations changées
• Citations changées
• Pages renommées
• Mises à jour de l’index
• Changements de liens
• Changements de statut
• Réécritures larges

L’habitude de révision la plus importante est d’inspecter les suppressions. Les LLMs suppriment souvent des détails tout en rendant le prose plus propre.

Un prose propre n’est pas toujours une meilleure connaissance.

Stratégie de commit sûre

Évitez les commits géants comme :

Mise à jour du wiki

Utilisez des commits qui expliquent l’opération :

ingest: ajouter des notes de source pour la sortie d'embedding Qwen
maint: marquer l'ancienne comparaison de magasin vectoriel comme dépassée
lint: réparer les liens internes brisés dans les pages RAG
review: mettre à jour les citations de la page Wiki LLM
refactor: séparer le concept de mémoire agent de la mémoire à long terme

Cela donne aux humains et aux agents futurs un historique utile.

Les messages de commit font partie du système de connaissances. Ils expliquent pourquoi le wiki a changé.

Niveaux de révision

Toutes les pages n’ont pas besoin du même niveau de révision. Utilisez une révision basée sur le risque.

Changements à faible risque :

• Corrections de liens brisés
• Nettoyage du formatage
• Ajout de backlinks
• Ajout d’entrées d’index
• Correction de fautes de frappe
• Ajout d’alias

Changements à risque moyen :

• Ajout de résumés de source
• Création de nouvelles pages de concept
• Mise à jour des recommandations
• Fusion de pages dupliquées
• Changement de statut de page

Changements à haut risque :

• Suppression d’affirmations
• Réécriture de pages canoniques
• Changement des registres de décision
• Mise à jour des affirmations de sécurité, juridiques, tarifaires ou de benchmark
• Résolution de contradictions
• Marquage du contenu comme actuel ou dépassé

Les changements à haut risque devraient obtenir une révision humaine. Cela peut être vous, un mainteneur ou un propriétaire de domaine.

L’agent peut préparer le changement, mais il ne devrait pas toujours être l’autorité finale.

Un tableau de bord de maintenance

Un tableau de bord de maintenance simple peut vivre en Markdown.

Exemple :

# Tableau de bord de maintenance du Wiki LLM

## Nécessite une révision
- wiki/concepts/agent-memory.md - révision en retard
- wiki/projects/search-index.md - affirmations contradictoires trouvées

## Pages obsolètes
- wiki/tools/ollama.md - dernière révision il y a 120 jours
- wiki/concepts/rag.md - sujet à évolution rapide, révision due

## Liens brisés
- wiki/index.md -> wiki/concepts/old-page.md

## Pages orphelines
- wiki/entities/vendor-x.md

## Rapports de contradiction
- reports/contradictions/2026-07-10-agent-memory.md

## Ingestions récentes
- raw/sources/2026-07-09-new-paper.md

Ce n’est pas un panneau d’administration fancy. C’est une surface de travail.

Pour de nombreux systèmes solo ou petite équipe, un tableau de bord Markdown est suffisant.

Métriques pour un wiki LLM en bonne santé

Vous pouvez suivre la santé du wiki sans sur-ingénierie.

Les métriques utiles incluent :

• Nombre de pages
• Pages sans sources
• Pages sans dates de révision
• Pages dépassant la date de révision
• Liens internes brisés
• Pages orphelines
• Titres ou alias dupliqués
• Rapports de contradiction ouverts
• Rapports de contradiction résolus
• Âge moyen des pages par cluster
• Sources brutes non encore ingérées
• Pages modifiées sans révision humaine
• Pages canoniques modifiées au cours des 30 derniers jours

Ces métriques ne sont pas des chiffres vaniteux. Ils vous disent si le système devient plus facile ou plus difficile à faire confiance.

Un wiki en croissance avec des pages orphelines et des révisions obsolètes en hausse n’accumule pas des connaissances. Il accumule de la dette de maintenance.

Prompts de maintenance

Les prompts de maintenance devraient être étroits. Les prompts larges produisent des réécritures larges.

Prompt de lint structurel

Réviser la structure du wiki.

Vérifier :
- liens internes brisés
- pages orphelines
- titres de page dupliqués ou quasi-dupliqués
- pages manquant des sections de source
- pages manquant la métadonnée last_reviewed
- pages d'index qui ne lient pas aux nouvelles pages

Ne pas réécrire le contenu.
Produire un rapport Markdown avec les constatations et les corrections suggérées.

Prompt de révision des citations

Réviser les citations pour la page sélectionnée.

Pour chaque affirmation importante :
- identifier la source de soutien
- vérifier si la source soutient directement l'affirmation
- signaler les affirmations avec un soutien faible, manquant ou inadapté
- ne pas réécrire la page pour l'instant

Retourner un tableau avec :
affirmation, citation actuelle, niveau de soutien, problème, action suggérée.

Prompt de vérification des contradictions

Vérifier cette page pour les contradictions contre les pages apparentées.

Étapes :
1. Extraire les affirmations principales de la page.
2. Trouver les pages apparentées via liens, backlinks, alias et recherche.
3. Extraire les affirmations potentiellement contradictoires.
4. Classer chaque conflit comme :
   - vraie contradiction
   - différence de version
   - différence de portée
   - différence terminologique
   - incertitude non résolue
5. Recommander une résolution.

Ne pas éditer les fichiers tant que le rapport de contradiction n'est pas révisé.

Prompt de révision des pages obsolètes

Réviser cette page pour l'obsolescence.

Vérifier :
- dates
- affirmations spécifiques à une version
- comportement des outils
- recommandations
- liens vers des pages dépassées
- sources plus récentes que la date de révision de la page
- affirmations marquées comme actuelles sans soutien récent

Retourner :
- conserver actuel
- mise à jour nécessaire
- marquer historique
- marquer dépassé
- diviser en pages versionnées

Prompt de mise à jour sûre

Mettre à jour la page du wiki sélectionnée en utilisant la source fournie.

Règles :
- préserver la structure utile existante
- ne pas supprimer les affirmations sourcées sauf si la source est dépassée
- ajouter des citations pour les nouvelles affirmations
- marquer explicitement l'incertitude
- mettre à jour les pages apparentées uniquement lorsque nécessaire
- ajouter une note de révision expliquant ce qui a changé
- garder le diff petit

Ces prompts ne sont pas magiques. Ce sont des garde-fous. La vraie valeur vient du fait de rendre l’action de maintenance explicite.

Erreurs de maintenance courantes

La première erreur est de laisser l’agent réécrire trop.

Les grandes réécritures semblent productives parce qu’elles rendent les pages plus fluides. Elles rendent aussi plus difficile de voir ce qui a changé et plus facile de perdre des détails précis.

La deuxième erreur est de traiter les résumés générés comme des sources.

Un résumé peut être utile, mais ce n’est pas la preuve. Conserver les sources brutes et les citer lorsque les affirmations importent.

La troisième erreur est de créer de nouvelles pages au lieu de mettre à jour les anciennes.

Cela produit des concepts dupliqués, des recommandations contradictoires et de la confusion dans la recherche. L’agent devrait d’abord chercher, ensuite mettre à jour, et créer de nouvelles pages uniquement lorsque le concept est réellement nouveau.

La quatrième erreur est de supprimer le contexte historique.

Les anciennes décisions, les expériences échouées et les recommandations dépassées peuvent être précieuses. Les marquer clairement au lieu de les effacer.

La cinquième erreur est d’oublier les index.

Une page qui n’est pas liée depuis le bon endroit est à moitié perdue. La maintenance de l’index n’est pas un travail administratif. C’est de l’architecture de navigation.

La sixième erreur est d’utiliser la même politique de révision pour chaque page.

Une page conceptuelle stable et une comparaison d’outils à évolution rapide ne devraient pas avoir le même calendrier de révision.

Archiver, dépasser ou supprimer

La plupart des pages obsolètes ne devraient pas être supprimées immédiatement.

Une page dépassée devrait lier au remplacement.

Par exemple :

Statut : dépassé
Dépassé par : wiki/concepts/agent-memory-architecture.md
Raison : Cette page utilisait une définition plus ancienne de la mémoire agent avant que le projet ne sépare la mémoire de session, la mémoire utilisateur et les connaissances compilées.

Cela préserve le contexte et réduit la confusion.

La suppression devrait être rare et révisable. Les systèmes de connaissances ont besoin d’élagage, mais un élagage invisible est dangereux.

Les pages canoniques nécessitent une attention particulière

Chaque wiki LLM développe éventuellement des pages canoniques.

Ce sont des pages qui définissent des concepts de base, des choix d’architecture, des flux de travail ou le vocabulaire du projet. Elles sont plus importantes que les notes ordinaires parce que de nombreuses autres pages dépendent d’elles.

Exemples :

• Qu’est-ce que le Wiki LLM
• RAG vs connaissances compilées
• Mémoire agent
• Politique des sources
• Flux de travail de révision
• Architecture du projet
• Glossaire
• Index

Les changements aux pages canoniques devraient nécessiter une révision plus stricte.

Une petite erreur sur une page obscure est locale. Une petite erreur sur une page canonique peut distordre tout le wiki.

À quelle fréquence devez-vous exécuter la maintenance

Pour un wiki LLM actif, exécutez une petite maintenance fréquemment et une maintenance profonde occasionnellement.

Le calendrier devrait correspondre au risque. Un wiki de recherche personnelle peut être plus léger. Un wiki utilisé pour la publication technique, le support client ou les décisions d’ingénierie a besoin de plus de discipline.

Utiliser un wiki LLM pour la publication technique

Pour un blog technique ou un site de documentation, le wiki LLM peut devenir la couche de connaissances derrière la planification des articles.

Il peut suivre :

• Explications canoniques
• Définitions répétées
• Opportunités de liens internes
• Comparaisons obsolètes
• Lacunes des articles
• Clusters de sujets
• Notes de source
• Décisions sur la structure
• Affirmations nécessitant une vérification

C’est utile, mais cela augmente la barre de maintenance.

Si le wiki alimente des articles publiés, alors les pages obsolètes du wiki peuvent devenir du contenu public obsolète. Si le wiki contient des contradictions, ces contradictions peuvent fuir dans les articles. Si les citations sont faibles, les brouillons générés hériteront de cette faiblesse. Les résumés étendus, l’extraction basée sur le schéma et les boucles de révision humaine décrits dans L’IA pour la gestion des connaissances : des flux de travail réels qui tiennent bon sont un bon modèle pour garder ce pipeline éditorial honnête.

Pour les flux de travail de publication, traiter le wiki LLM comme un système éditorial, pas juste un carnet de notes privé. Un jardin numérique rend cela explicite en montrant aux lecteurs quelles pages sont encore en croissance et quelles sont matures, ce qui est exactement le type de signal de statut qu’un wiki LLM bien maintenu devrait également exposer.

La maintenance n’est pas optionnelle

Un wiki LLM est attrayant parce qu’il promet des connaissances composées.

Mais la composition ne fonctionne que si les anciennes connaissances restent utiles. Sinon, le système compose du bruit, pas de l’insight.

Le fardeau de maintenance ne disparaît pas parce qu’un agent est impliqué. Il change de forme.

Les humains ne devraient pas avoir à faire chaque tâche fastidieuse. Les agents peuvent vérifier les liens, trouver les pages obsolètes, comparer les affirmations, rédiger des rapports et proposer des mises à jour. Mais les humains doivent toujours définir la politique, réviser les changements risqués et décider de ce que le wiki est autorisé à signifier.

C’est le véritable échange.

Conclusion

La maintenance du wiki LLM consiste à garder les connaissances compilées honnêtes.

Les pratiques importantes ne sont pas compliquées : préserver les sources, citer les affirmations, maintenir les index à jour, détecter les contradictions, réviser les diffs Git, marquer les pages obsolètes et éviter les réécritures larges non révisées.

Un bon wiki LLM ne prétend pas être magiquement autocorrectif. Il rend la correction plus facile.

C’est la norme à viser : pas une connaissance parfaite, mais une connaissance inspectable qui peut être révisée, réparée et faire confiance au fil du temps.