- Dans l’industrie du logiciel, le concept de « Software Factory » attire fortement l’attention ces derniers temps. Il s’agit d’un nouveau paradigme où des agents IA, capables d’exécuter eux-mêmes plusieurs étapes de travail selon un objectif donné, prennent en charge l’écriture du code source, tandis que les développeurs se concentrent sur la construction et l’amélioration d’un système — autrement dit une « usine » — permettant de produire ce code de manière fiable.
- Dru Knox de Tessl, une entreprise d’outils de développement IA, a nommé cette nouvelle discipline de développement la harness engineering.
- Le harness, comme le harnais que l’on met à un cheval, désigne l’ensemble du framework qui contrôle et fait fonctionner les agents IA, et au cœur de ce framework se trouvent trois boucles (Loop, des cycles répétant la même procédure).
- Ce que couvre la vidéo : ce qu’est une Software Factory et les trois indicateurs qui la définissent / pourquoi Tessl a interdit les sessions de coding conversationnel en interne et ce qui a suivi / les trois couches que sont l’inner, l’outer et la meta loop / pourquoi la harness engineering est difficile / comment la change review et le verifier de Tessl l’implémentent concrètement
- Vidéo : https://www.youtube.com/watch?v=D_cw-k0F1DM&t=236
En appliquant la même structure à la production de connaissances
- Une knowledge factory est un système dans lequel des agents IA rédigent des pages de wiki, tandis que les humains conçoivent et exploitent le « système de rédaction » qui permet de les produire à grande échelle. Les opérateurs n’écrivent pas directement les articles ; ils gèrent les consignes de rédaction et les mécanismes automatisés de vérification.
- L’organisation interne de l’usine s’inspire des cinq rôles d’une rédaction de journal : reporter, chroniqueur, correcteur, desk et rédacteur en chef.
- Le point clé est que ces cinq rôles ne sont pas tous des « IA qui jugent ». Le « correcteur » n’est pas une IA mais du code Python basé sur des règles, et le « rédacteur en chef » est un coordinateur qui répartit le travail. Le seul poste où l’IA prend un jugement d’évaluation indépendant est le desk.
- Concevoir une usine efficace ne consiste pas à augmenter aveuglément le nombre d’agents, mais à définir clairement où placer le domaine du jugement et d’où l’exclure.
Les trois axes de maturité, et la confiance
- La maturité du système se mesure sur trois axes : l’autonomie (finaliser une page sans intervention humaine), l’automatisation (jusqu’où autoriser la publication sans relecture humaine) et la qualité (le niveau des connaissances produites).
- Même si l’autonomie est élevée, si l’opérateur reste inquiet et contrôle intégralement chaque page, le niveau d’automatisation reste faible. L’élément clé qui comble cet écart est précisément la « confiance ».
- On sécurise d’abord l’autonomie, puis on étend les zones d’automatisation à mesure que la confiance s’accumule, tout en maintenant un niveau de qualité constant durant ce processus. Et le mécanisme qui garantit cette confiance, ce sont justement les « boucles ».
1. Inner Loop — auto-vérification en temps réel
- L’inner loop est une procédure de vérification rapide et légère que l’agent exécute fréquemment pendant la rédaction, avant de soumettre un brouillon. Plus cette boucle est sophistiquée, plus l’agent IA corrige lui-même ses erreurs sans intervention humaine, ce qui améliore au final l’autonomie.
- Pendant la rédaction, il ne vérifie que les documents qu’il a lui-même créés à l’aide de l’outil d’inspection Python (
tools/lint.py) ; si la même erreur se répète plus de deux fois, le traitement est immédiatement transmis à l’étape suivante afin de préserver la vitesse d’exécution.
2. Outer Loop — une double barrière juste avant publication
- La 1re barrière est la correction. Du code Python effectue une analyse statique sur 10 domaines — liens, citations, structure documentaire, contradictions de données, etc. — selon des règles déterministes.
- La 2e barrière est le desk. Il réalise une évaluation qualitative du point de vue d’un lecteur tiers selon 6 angles — biais, densité informationnelle, lisibilité, progression de l’argumentation, etc. — et renvoie uniquement une liste d’améliorations à effectuer, sans corriger directement.
- Cela correspond exactement à la structure en deux niveaux verifier (1re barrière) · change review (2e barrière) d’une Software Factory.
- Il y a ici un principe de conception décisif. Au desk, on ne transmet que le manuscrit finalisé et les critères d’évaluation, jamais l’intention de rédaction de l’auteur. Si l’on relit son propre texte dans le même contexte que celui où on l’a écrit, on devient plus indulgent dans son jugement ; l’information est donc délibérément bloquée pour éviter ce biais.
- La vraie différenciation de ce système ne tient pas au nombre d’agents lancés, mais à cette isolation du contexte. En cas de trois rejets pour la même raison, le flux automatique s’arrête et la décision est transmise à un opérateur humain.
3. Meta Loop — mécanisme d’auto-amélioration
- Le principe est le suivant : « ne pas laisser une même erreur se répéter deux fois ; toute erreur détectée doit être promue au rang de règle du système ».
- Si le même défaut continue d’apparaître, une proposition de modification des consignes de rédaction est automatiquement suggérée. Cette proposition passe ensuite par une évaluation comparative en aveugle, où l’on masque lequel des textes a été rédigé avec la règle modifiée, ainsi que par des tests sur de nouveaux cas d’échec jamais utilisés dans la vérification.
- Elle n’est intégrée au système que si les scores s’améliorent réellement, et uniquement après avoir obtenu l’approbation finale d’un opérateur humain.
- Les remarques récurrentes sont promues en hooks Python ou en règles de correction afin d’être ancrées dans le code. On transfère ainsi certaines zones de jugement qualitatif vers le domaine des contrôles par règles, pour permettre au desk de se concentrer en permanence sur les problèmes de plus haut niveau.
4. Reground Loop — une 4e boucle nécessaire uniquement pour la connaissance
- Le code logiciel, une fois buildé et déployé, reste dans un état stable jusqu’à un changement de spécification, mais les actifs de connaissance vieillissent avec le temps, à mesure que l’écart avec les faits du monde réel se creuse.
- Pour résoudre cela, une quatrième boucle a été ajoutée : la loop de reground, qui réinjecte les documents publiés comme entrées dans l’usine de production de connaissances.
- Mise à jour : lorsqu’un changement survient dans la source de données d’origine. Le chroniqueur réanalyse et met à jour les pages vieillissantes identifiées par l’outil d’inspection. (suivi d’actualité)
- Follow-up : lorsqu’une phrase du document mentionne qu’une « vérification ultérieure est nécessaire » ou contient une condition limitée dans le temps. À l’échéance, le desk et l’opérateur procèdent à une nouvelle vérification. (suivi d’enquête)
- Correction : lorsqu’une contradiction d’information est détectée entre nos pages. Le desk relit alors l’ensemble des documents au niveau d’un cluster publié, ce qui permet de repérer des décalages invisibles lorsqu’on examine les pages une par une. (publication corrective)
Human-in-the-Loop
- Les situations exceptionnelles nécessitant une approbation humaine sont définies et gérées au moyen d’une checklist claire, sans dépendre de l’intuition.
- Pour l’instant, le système fonctionne avec une autonomie élevée mais une automatisation volontairement limitée. Les agents rédigent eux-mêmes les pages, mais la publication sur le wiki et les modifications des règles de rédaction exigent encore l’approbation finale d’un humain.
Texte complet : https://alfadur7.github.io/llm-wiki-newsroom/ko/knowledge-factory/
Aucun commentaire pour le moment.