Trois contrôles avant de croire une extraction

Le rendez-vous qui part dans la mauvaise ville

Votre document indique : « Le siège est à Paris. La réunion aura lieu à Lyon. » Vous demandez la ville de réunion. Le système répond avec un objet contenant Paris. Rien ne plante, l’application affiche une carte et la démonstration paraît réussie. Pourtant, elle vous envoie au mauvais endroit.

Cette erreur est intéressante parce qu’elle traverse deux contrôles habituels. Le JSON est lisible et la valeur est bien une chaîne de caractères. Le problème est ailleurs : la ville choisie n’a pas le rôle demandé.

Écrire le contrat avant le prompt

Fixez le champ attendu, son type et la conduite à tenir si l’information manque. Ici, le champ est meeting_city ; il contient un texte ou null. Aucun autre champ n’est accepté. null signifie que la ville de réunion est absente, pas que le modèle hésite ou que la ville manque dans une liste autorisée.

Construisez ensuite une référence par document. Si deux annotateurs ne peuvent pas se mettre d’accord sur la bonne ville, le problème n’est pas encore assez défini pour être évalué proprement.

Mesurer trois réussites distinctes

1. Syntaxe : le parseur accepte-t-il la sortie ?
2. Schéma : les champs et leurs types sont-ils conformes ?
3. Fidélité : la réponse correspond-elle à l’information et au rôle demandés ?

Rapportez chaque taux sur un dénominateur explicite. « 90 % de réponses exactes parmi les sorties valides » ne signifie pas « 90 % des documents traités correctement ». Les sorties invalides ne doivent pas disparaître silencieusement du bilan global.

Un petit jeu de test utile

Préparez quatre familles : une seule ville, plusieurs villes avec des rôles différents, aucune ville de réunion, une ville hors du catalogue habituel. Variez également l’ordre des phrases. Gardez des documents nouveaux pour le test final après vos corrections.

Le décodage contraint peut réduire certaines erreurs de format. Il ne remplace ni ces références ni les cas difficiles. Les expériences du tome 2 illustrent cette séparation dans un protocole précis ; leurs chiffres ne constituent pas une performance générale de tous les LLM.

Suivre un document du début à la fin

Reprenons notre document en nous plaçant du côté du lecteur qui doit vérifier le résultat. Nous cherchons une relation : quelle ville est associée à la réunion ? Le mot « Paris » satisfait le critère « être une ville présente dans le texte », mais ce critère est trop faible. La phrase qui le contient parle du siège. La seconde phrase relie explicitement la réunion à Lyon. La référence doit donc provenir de cette relation, et non de la première ville rencontrée.

Cette distinction explique pourquoi une extraction n’est pas toujours une simple recherche de mots. Reconnaître une entité, lui attribuer un rôle et la restituer dans le bon champ sont trois opérations conceptuellement différentes. Même si un même modèle les réalise en une seule génération, nous gagnons à les séparer pour analyser ses erreurs.

Imaginons maintenant trois sorties : un texte libre disant « Lyon », un objet avec meeting_city égal à Paris, puis un objet avec meeting_city égal à Lyon. La première réponse contient la bonne information, mais ne respecte pas l’interface imposée à l’application. La deuxième respecte l’interface, mais transmet la mauvaise information. Seule la troisième satisfait les deux exigences. Le succès opérationnel exige à la fois un contenu juste et une représentation exploitable.

Passer du résultat global au diagnostic

Supposons, dans un autre exemple construit, que vous évaluiez cent documents. Dix sorties sont illisibles, vingt sont lisibles mais ne respectent pas le schéma, et cinquante des soixante-dix sorties conformes contiennent la bonne ville. La réussite de bout en bout est de 50 sur 100. La fidélité parmi les sorties conformes est de 50 sur 70, soit environ 71,4 %. Ces deux nombres sont utiles, mais répondent à des questions différentes. Le premier décrit ce que reçoit l’utilisateur ; le second aide à isoler les erreurs de sens après les erreurs de format.

Une amélioration du format peut ainsi augmenter le nombre de sorties exploitables sans améliorer leur exactitude. À l’inverse, une meilleure compréhension peut rester invisible dans l’application si les sorties ne sont pas lisibles. Choisissez la prochaine correction à partir de la catégorie d’erreurs dominante, puis recommencez la mesure sur des documents réservés.

Une règle simple pour les cas difficiles

Si un document mentionne deux réunions dans deux villes, notre contrat à une seule valeur devient insuffisant. Il faut alors préciser quelle réunion nous cherchons, autoriser plusieurs valeurs ou signaler l’ambiguïté. Demander au modèle d’être « plus précis » ne répare pas une question mal définie. L’excellence d’une extraction commence par une tâche que l’on peut expliquer et vérifier sans le modèle.

Exercice et correction

« Le siège est à Lyon. La réunion sera à Marseille. » Une réponse null est-elle correcte parce que Marseille n’appartient pas à votre liste ? Non. L’information est présente. Il faut prévoir un état distinct pour les valeurs hors catalogue, ou autoriser leur extraction, plutôt que confondre présence et absence.

Ouvrir l’expérience interactive