Un agent IA qui apprend des corrections, sans réentraînement
Conserver les retours humains, repérer les répétitions et tester les changements proposés avant de les appliquer.
Lorsqu’une personne corrige un brouillon IA, le cabinet obtient une preuve de l’écart entre le résultat produit et le travail attendu. Une boucle de correction conserve cette preuve et s’en sert pour proposer une amélioration, sans réentraîner nécessairement le modèle ni laisser l’agent réécrire seul ses règles.
L’architecture ci-dessous est un modèle de conception. Les seuils et noms de scripts sont illustratifs : ce ne sont ni des résultats clients rapportés ni une promesse d’amélioration après un nombre fixe de semaines.
Le problème d’un système construit puis oublié
Une démonstration reflète les exemples disponibles au moment de sa création. L’utilisation quotidienne révèle d’autres sources, préférences et exceptions. Si l’équipe corrige toujours la même erreur sans conserver sa cause, les personnes finissent par contourner un système qui reste figé.
Il faut observer l’erreur et agir par un changement maîtrisé. Ajouter une règle n’est pas toujours la réponse : il peut être préférable de réparer une source, clarifier le rôle ou donner un meilleur exemple.
Une boucle pour un travail déjà relu
Imaginons un consultant qui accepte, modifie ou rejette des brouillons de prise de contact et des briefs de réunion. Le dispositif peut conserver le type de correction, l’original, la version corrigée, la date et le contexte utile.
Un script illustratif nommé correction_handler.py pourrait écrire ces éléments dans un stockage autorisé. Les catégories pourraient distinguer un mauvais intitulé, une mauvaise société, un ton trop formel, une introduction inutile, une longueur excessive ou un résultat écarté. Ne conservez pas de texte sensible inutile au processus d’amélioration.
Une modification peut être liée à une situation précise. Sa répétition peut révéler un problème récurrent. Dans les deux cas, recueillez les preuves avant d’en faire une préférence permanente.
Examiner les répétitions avant de changer une règle
Un composant de revue programmée, illustrativement rule_graduation.py, peut regrouper les corrections et proposer une explication. Un comptage attire l’attention ; il ne prouve pas que la règle proposée est correcte.
Une proposition pourrait être : « Plusieurs messages de ce type ont été raccourcis. Devons-nous tester une ouverture plus brève ? » Présentez les exemples, exceptions et limites à côté de la proposition. La personne responsable peut accepter, modifier ou refuser.
N’ajoutez pas automatiquement une restriction permanente après un nombre arbitraire de corrections. Cherchez d’abord si un exemple, une définition de rôle, une source corrigée ou une modification réversible traiterait la cause. Testez le changement approuvé avant de le généraliser.
Différence avec la recherche documentaire et le fine-tuning
La recherche documentaire fournit des informations pertinentes. Le fine-tuning modifie les paramètres d’un modèle par entraînement. La boucle de correction ajuste des sources, consignes, exemples ou éléments de configuration avec une revue.
Ces approches peuvent se compléter. Un fait manquant peut demander une meilleure recherche ; un décalage de style répété, un exemple ou une consigne approuvée. Choisissez le changement le plus limité qui traite le problème observé, puis vérifiez-le sur un travail représentatif.
Observer le comportement après correction
Gardez une situation de référence. La correction revient-elle ? La nouvelle consigne crée-t-elle un autre défaut ? La lecture devient-elle plus simple ou les personnes vérifient-elles moins attentivement ?
Suivez acceptations, corrections de fond, raisons de rejet et temps de revue. Un taux d’acceptation supérieur ne prouve pas seul la qualité. Comparez des travaux similaires et examinez des échantillons : l’ajout d’une règle ne constitue pas un résultat métier.
Où ce fonctionnement peut aider
Documents préparatoires, réponses de support, classifications financières et résumés de recherche peuvent produire des signaux de correction. Il faut des sources autorisées, une personne qui relit déjà le travail et une raison légitime de conserver le retour.
Le responsable garde le jugement métier et les actions importantes. La répétition d’une correction n’accorde aucune nouvelle permission.
L’architecture de la boucle
- Capturer : conserver la correction et le contexte nécessaire pour la comprendre. Une petite base ou un fichier approuvé peut suffire à un pilote limité.
- Repérer : regrouper les problèmes récurrents sans perdre les exceptions. Le comptage simple peut aider ; un modèle supplémentaire n’est pas obligatoire.
- Relire : présenter la cause supposée et le changement à une personne responsable. Un refus et son explication sont aussi des preuves utiles.
- Appliquer : versionner un changement approuvé et réversible aux consignes, exemples, sources ou au processus.
- Vérifier : comparer les résultats suivants à la référence et rechercher les effets secondaires avant d’élargir.
Gardez visibles les permissions, informations sensibles et limites de conservation. L’effort dépend du système et des données : il n’existe pas de promesse universelle de réalisation en un après-midi.
Ce qu’il faut examiner pendant l’exploitation
Le seuil de revue doit rendre visibles les répétitions utiles sans submerger le responsable. Les catégories doivent expliquer le problème : « modifié » renseigne moins qu’un motif précis. Conservez les raisons de refus pour éviter de reproposer sans cesse une règle inadaptée.
Repérez également les préférences contextuelles transformées à tort en règles générales. Un consultant peut raccourcir un message en raison du destinataire ou du moment, sans souhaiter tous les messages courts. La boucle doit préserver ce contexte.
Améliorer sans sur-contraindre
Une erreur répétée appelle d’abord une meilleure compréhension du travail. Réparez la source ou expliquez le jugement, rendez les erreurs restantes observables et laissez l’opérateur affiner le processus à partir des résultats.
Une sortie strictement formatée peut justifier une vérification déterministe. La rédaction ou le jugement demandent plutôt de bons exemples, une incertitude visible et une revue. L’approbation humaine des changements maintient cette distinction.
Le premier essai pour votre cabinet
Si vos équipes relisent déjà des brouillons IA, commencez par un petit échantillon autorisé de corrections et de motifs. Choisissez une répétition, proposez une amélioration réversible, nommez le relecteur et testez les prochains cas comparables.
Le diagnostic aide à définir le travail. Le Studio montre comment garder sources, décisions et passage de relais visibles dans un espace partagé.