Sorties structurées : le format garanti supprime une étape fragile
ArchitectureFiabilitéIntégrationProduction2024-08-0610 min
Analyser du texte pour en extraire un objet est la source d'erreur la plus banale d'une chaîne automatisée. Le format garanti la supprime entièrement.
Le problème que ça résout
Un modèle qui produit du texte libre oblige à analyser ce texte pour en extraire des données, et cette analyse échoue régulièrement de façon imprévisible. La garantie de format supprime cette étape entière.
Le symptôme est connu de toute équipe ayant branché un modèle sur une chaîne automatisée. Le modèle produit un objet correct quatre-vingt-quinze fois sur cent, puis ajoute une phrase d'introduction, oublie une accolade, ou entoure sa réponse de balises de code. Chaque variante casse l'analyse.
La réponse habituelle consistait à empiler des rustines : nettoyer le texte, tenter plusieurs analyses, redemander au modèle en cas d'échec. Ce dispositif fonctionne, coûte des appels supplémentaires, et reste une source d'incidents.
Ce que la garantie couvre, et ce qu'elle ne couvre pas
Le format est garanti ; le contenu ne l'est pas. C'est la distinction essentielle, et elle est fréquemment mal comprise.
Un modèle contraint produira toujours un objet valide, avec les champs demandés et les types demandés. Il ne garantit en rien que la date extraite soit la bonne date, ni que la catégorie choisie soit la bonne catégorie.
La conséquence est qu'on supprime une classe d'erreurs, les erreurs de forme, sans toucher à l'autre, les erreurs de fond. Le jeu de tests reste donc entièrement nécessaire, et il devient même plus lisible : puisque la sortie est structurée, la comparaison avec la réponse attendue devient automatisable champ par champ.
C'est un gain secondaire important. Une chaîne à sortie structurée est beaucoup plus facile à évaluer, ce qui rend praticable le dispositif décrit dans l'évaluation continue.
Comment concevoir un schéma de sortie qui tienne
- Prévoir explicitement l'incertitude. Un champ « confiance » ou une valeur « indéterminé » évite que le modèle invente pour remplir. Voir le refus de répondre est une fonctionnalité.
- Fermer les listes de valeurs. Une catégorie choisie parmi six valeurs possibles est vérifiable ; une catégorie en texte libre ne l'est pas.
- Demander la source. Un champ indiquant le passage d'où vient l'information rend chaque sortie vérifiable sans relecture complète.
- Rester plat. Un schéma profondément imbriqué augmente les erreurs de contenu sans rien apporter à l'exploitation.
Le coût caché d'un schéma trop ambitieux
Demander vingt champs en un seul appel dégrade la qualité de chacun, alors que deux appels de dix champs coûtent à peine plus cher. C'est le réglage que les équipes découvrent après coup.
Le mécanisme tient à l'attention du modèle : plus la sortie demandée est vaste, moins chaque champ reçoit de soin. Un schéma qui demande simultanément une classification, une extraction de dates, un résumé et une évaluation de risque produit les quatre médiocrement.
La règle empirique que j'applique : un appel, une intention. Extraire les données factuelles d'un côté, porter un jugement de l'autre. Cela double le nombre d'appels et améliore sensiblement les deux résultats.
Ce découpage a un second bénéfice : il permet d'envoyer chaque intention au palier de modèle qui lui convient. L'extraction part sur un petit modèle, le jugement sur un grand, ce qui compense largement le coût du second appel, le raisonnement de Claude 3 : choisir le palier.
Le test qui révèle un schéma trop chargé
Retirer la moitié des champs et comparer la qualité des champs restants. Si elle s'améliore nettement, le schéma demandait trop en un seul appel, et le découper coûtera moins que les erreurs qu'il produisait.
Ce que ça change pour l'intégration aux systèmes existants
Une sortie garantie rend un modèle branchable sur un système d'information sans couche de traduction, ce qui déplace le travail d'intégration. C'est le changement structurel de fond.
Jusqu'ici, brancher un modèle sur un progiciel supposait une couche intermédiaire chargée de fiabiliser la sortie : nettoyage, validation, reprise sur erreur. Cette couche représentait souvent la majorité du code.
Elle disparaît en grande partie. Ce qui reste est le travail utile : décider quels champs sont nécessaires, quelles valeurs sont admissibles, que faire en cas de doute. Autrement dit, un travail de spécification métier plutôt qu'un travail de rustine technique.
C'est une bonne nouvelle pour la maintenabilité : une spécification se relit et se modifie, contrairement à une accumulation de correctifs dont personne ne se rappelle la raison.
Ce que ça permet de supprimer dans le code existant
Sur les systèmes que je reprends, la couche de fiabilisation de sortie représente entre un cinquième et un tiers du code, et elle devient largement inutile. C'est un gain de maintenabilité rare.
Ce code a une caractéristique commune : il s'est accumulé par incidents. Une exception un jour, un correctif ; une variante de format le mois suivant, un autre correctif. Au bout d'un an, personne ne sait plus quelles branches sont encore nécessaires, et personne n'ose les retirer.
La migration vers un format garanti offre l'occasion de nettoyer, à condition de le faire explicitement. Sans cette décision, la couche reste en place « au cas où » et continue d'être maintenue sans raison. Voir la dette technique d'un système d'IA.
Questions fréquentes
- Le format garanti supprime-t-il le besoin de tests ?
Non. Le format est garanti, le contenu ne l'est pas : le modèle produira toujours un objet valide, mais rien n'assure que la date extraite soit la bonne. Le jeu de tests reste entièrement nécessaire.
- Combien de champs demander en un appel ?
Le moins possible, et une seule intention à la fois. Un schéma qui demande simultanément une extraction, un résumé et un jugement produit les trois médiocrement ; deux appels séparés valent mieux.
- Comment gérer les cas où le modèle ne sait pas ?
En prévoyant explicitement la valeur « indéterminé » ou un champ de confiance dans le schéma. Sans cette issue, le modèle inventera pour remplir le champ obligatoire.
- Quel bénéfice secondaire attendre ?
L'évaluation devient automatisable champ par champ, ce qui rend le jeu de tests beaucoup moins coûteux à exploiter et donc beaucoup plus susceptible d'être réellement maintenu.