Aller au contenu

Nettoyage du bruit token

Billet #245 : Nettoyage du bruit token avant implémentation du LLM Wiki
Type : Gouvernance / Automatisation / Qualité
Composants concernés : scripts/rotate_logs.py, .github/workflows/rotate-logs.yml, .github/agents/copilot-instructions.md, tests/test_copilot_scope_rule.py, docs/reports/coverage.xml, docs/reports/report.xml, docs/reports/report.jsonl, docs/reports/quality_score.json, docs/tests/index.md, docs/fr/tests/index.md

1. Contexte et stratégie

Préoccupé depuis quelque temps par ma consommation de tokens sur ce projet, je cherchais une solution pour optimiser mes échanges avec les agents GitHub Copilot. J'avais d'abord envisagé de construire un RAG (Retrieval-Augmented Generation), mais cette idée a été abandonnée au profit du LLM Wiki, jugé plus simple et plus adapté à un projet personnel.

L'objectif du LLM Wiki est de créer une base de connaissance Markdown structurée que l'IA lit en premier, de façon ciblée, avant d'explorer toute autre source de documentation. Le résultat attendu : une orientation plus rapide, des réponses plus précises, et une meilleure capitalisation sur les décisions techniques passées.

Cependant, avant de construire ce LLM Wiki, je devais d'abord réduire le bruit documentaire qui gonfle la consommation de tokens.

Pourquoi ce prérequis était stratégique :

  • un LLM Wiki n'apporte de valeur que si la base lue par l'IA est propre et priorisée;
  • sans nettoyage, l'IA consomme des tokens sur des artefacts de run, des fichiers temporaires et des logs opérationnels au lieu de se concentrer sur la connaissance métier;
  • ce bruit augmente le coût, la latence et le risque de réponses moins pertinentes;
  • en nettoyant d'abord, je crée un socle gouverné et stable qui rend ensuite l'implantation du LLM Wiki plus fiable, plus rapide et plus économique.

2. Solution implémentée

Le chantier a été exécuté en phases, conformément à la spec 005-ai-token-noise-cleanup.

  • définition et clarification complètes de la spec (rotation automatique tous les 180 jours, archivage .gz, suppression définitive des archives après 180 jours, validation automatisée de la règle de scope IA);
  • implémentation d'un script dédié scripts/rotate_logs.py pour :
    • conserver uniquement les entrées actives des 180 derniers jours,
    • archiver les entrées expirées en .gz dans logs/archives/ avec date dans le nom,
    • purger automatiquement les archives trop anciennes;
  • création du workflow GitHub Actions .github/workflows/rotate-logs.yml :
    • planification semestrielle,
    • déclenchement manuel (workflow_dispatch),
    • mode simulation (dry_run) et paramètre de rétention;
  • formalisation de la règle de scope IA dans .github/agents/copilot-instructions.md. Concrètement, cette règle indique à l'IA ce qu'elle doit lire en priorité et ce qu'elle doit ignorer : priorité aux sources de connaissance projet écrites en anglais (puisque la documentation est bilingue), exclusion explicite des artefacts générés, fichiers temporaires et logs opérationnels;
  • ajout d'un test de non-régression tests/test_copilot_scope_rule.py pour verrouiller la présence de cette règle;
  • suppression des fichiers temporaires validés comme non utiles (tmp_*, pytest_result*.txt, gate_result.txt, requirements.txt.tmp).

3. Validation et résultats

Validation d'exécution (recalcul complet):

  • Pytest: 123 tests passés, 1 avertissement, 0 échec;
  • rapports régénérés:
    • docs/reports/report.xml (JUnit XML),
    • docs/reports/report.jsonl (journal détaillé),
    • docs/reports/coverage.xml (couverture code).

Validation de la couverture :

  • couverture du code applicatif (code_source_simule/*) : 67.58% (494/731 lignes couvertes);
  • score qualité mis à jour (docs/reports/quality_score.json):
    • couverture: 67.58,
    • pytest: 100.0,
    • e2e: 100.0,
    • score global: 83.79 (arrondi 84).

Validation de gouvernance:

  • la règle de scope IA est désormais testée automatiquement;
  • le flux de rotation/purge des logs est industrialisé;
  • la spec 005-ai-token-noise-cleanup est passée au statut Implemented.

4. Impact business

Ce nettoyage améliore directement la rentabilité future du LLM Wiki:

  • moins de tokens gaspillés sur des fichiers sans valeur;
  • meilleur signal documentaire pour l'IA;
  • réponses plus ciblées et plus cohérentes;
  • base de connaissances plus maintenable dans la durée.

En synthèse, ce travail transforme le dépôt en fondation prête pour la phase LLM Wiki, avec un meilleur contrôle coût/qualité dès le départ.

5. Limites et points de vigilance

  • le scénario SC-005 (session IA de test post-implémentation) reste une validation comportementale à exécuter explicitement après votre revue;
  • le dossier logs/ est localement ignoré par Git, ce qui est cohérent avec sa nature opérationnelle. La discipline attendue est la suivante : laisser le workflow planifié s'exécuter à échéance, lancer manuellement le workflow après un incident ou un run exceptionnellement volumineux, puis vérifier le résumé d'exécution pour confirmer que la rotation et la purge ont bien été appliquées.

6. Leçons apprises

Voici un bilan de la consommation de tokens au cours de la présente session de travail :

  • Consommation totale estimée : 19 602 640 tokens sur 212 requêtes LLM;
  • Répartition entrée/sortie : 19 471 947 tokens d'entrée (~99.33%) vs 130 693 tokens de sortie (~0.67%);
  • Postes principaux :
    • session principale : 19 395 379 tokens (~98.94% du total),
    • sous-agent AI coach : 206 952 tokens (~1.06%),
    • génération de titre UI : 309 tokens (~0.00%, négligeable);

  • Modèles les plus consommateurs :

    • gpt-5.3-codex : 12 411 325 tokens (~63.31%),
    • claude-sonnet-4.6 : 7 191 315 tokens (~36.69%).

  • Éléments ayant le plus consommé les tokens pendant cette session :

    • les requêtes avec contexte cumulé très volumineux (113 requêtes >= 80 000 tokens d'entrée);
    • la réinjection de grands blocs de contexte et de sorties outils au fil des itérations, notamment après read_file (88 appels) et run_in_terminal (61 appels);
    • l'inclusion de pièces jointes longues (12 requêtes), qui reste secondaire mais contribue à l'augmentation du contexte.

  • Conclusion opérationnelle :

    • la session a atteint son objectif métier, mais le coût token reste majoritairement piloté par la taille du contexte d'entrée;
    • le levier le plus direct pour la prochaine session est de réduire la taille des extraits injectés et de clôturer chaque étape avec un résumé court au lieu d'accumuler des sorties brutes.