Comment entraîner un agent LLM d'infrastructure à ne pas mentir

Un agent LLM interne en lecture seule a été construit pour répondre à des questions d'infrastructure telles que « pourquoi le service renvoie-t-il une erreur 502 ? ». Il utilisait Go, sans LangChain, et appelait les modèles DeepSeek-V4-Flash et Qwen3.6-27B-FP8 via une API compatible OpenAI. La première version utilisait une boucle ReAct libre et produisait des réponses formellement correctes mais souvent trompeuses. Par exemple, lorsqu'une erreur 502 était causée par un en-tête de réponse trop volumineux au niveau du proxy, l'agent concluait « aucune erreur au niveau applicatif », manquant ainsi la véritable cause. Cinq classes d'erreurs ont été identifiées : mauvais périmètre, mauvaise sémantique temporelle, mauvaises conclusions négatives, perte de preuves et replanification incontrôlée. La solution a été d'intégrer l'LLM dans un cadre applicatif strict. Les appels d'outils sont régis par un contrat étendu x-agent qui définit les preuves, le type de sortie, la fraîcheur, la sémantique négative et le statut en lecture seule. Le planificateur établit d'abord des objectifs (par exemple, symptom.http_502, route.edge_to_ingress) et une condition d'arrêt : chaque objectif requis doit être résolu ou explicitement indisponible. Un garde de preuves empêche le finaliseur de conclure avant que tous les objectifs ne soient remplis. La sélection des outils est étagée : filtre politique, préfiltre lexical, reclassement par LLM (top 8), puis porte de pertinence des objectifs. Les intentions risquées ont des pré-itinéraires déterministes. Dans l'évaluation finale, 44 scénarios sur 45 ont réussi (29 sur 29 obligatoires), chaque scénario étant exécuté deux fois. Le seul test échoué concernait un format de rapport de capacité optionnel. L'agent reste en lecture seule ; les humains décident des modifications en production.