Un développeur porte le remplissage de questionnaires d'ingénierie à 73–86 % de concordance avec l'expert

Un ingénieur doit remplir un questionnaire pour le fournisseur d'un instrument industriel : indiquer la pression, les matériaux, la version climatique et la protection antidéflagrante. Les réponses sont dispersées sur des centaines de pages du cahier des charges. Cela semble être un travail tout trouvé pour un LLM : retrouver le bon passage et reporter la valeur dans le tableau. Dans le projet décrit sur Habr, la première version remplissait correctement environ un tiers des cellules.

En deux mois, l'auteur a porté le système à 73–86 % de concordance avec l'ingénieur, parmi les lignes auxquelles celui-ci avait répondu, sur trois sites. Mais l'analyse des erreurs est ici plus utile que le chiffre final. Le système confondait des paramètres voisins, tentait de deviner les décisions internes du service et comptait comme des questions des lignes qui n'exigeaient aucune réponse de l'ingénieur.

La citation est authentique, la réponse est fausse

La première version fonctionnait de façon classique : pour chaque cellule, la recherche ramenait douze extraits du cahier des charges, le modèle produisait une valeur et une citation. Le code vérifiait que la citation existait réellement. Cela s'est révélé insuffisant.

Un exemple simple : le système écrit « Garantie : 30 ans ». Le chiffre figure bien dans le document, mais il concerne la durée de vie de l'appareil. La véritable garantie, 36 mois, se trouve juste à côté. La vérification de la source passe, et l'ingénieur reçoit une erreur.

L'auteur a confié le remplissage à des règles et à un référentiel, ne laissant au modèle que l'extraction des faits. Là où les règles se déclenchaient, 86–92 % des réponses étaient correctes. Sur l'ensemble des cellules des deux autres sites, le résultat était de 58 %. Les règles transposaient elles aussi les particularités d'un projet à un autre.

Améliorer la recherche ne garantissait pas à lui seul un gain. Après le réentraînement d'un petit modèle, l'article pertinent est passé en première position dans 63 % des lignes contre 52 %, mais le nombre de valeurs correctes n'a pas augmenté. L'étape suivante continuait de prendre le premier extrait dont on pouvait tirer quelque chose. Des conditions supplémentaires ont aidé : vérifier le mot significatif du paramètre et l'unité de mesure de la durée.

Pour une équipe qui construit une recherche sur des documents d'entreprise, c'est une leçon importante : il faut mesurer toute la chaîne jusqu'à la réponse finale. Un meilleur résultat de recherche est inutile si l'étape suivante l'exploite mal.

Une partie du savoir réside dans le service

La vérification par l'ingénieur a révélé un problème plus profond. Parmi les lignes atypiques des quatre premiers sites, l'auteur n'a pas trouvé dans les documents la réponse pour 65–83 % des cas. Lors d'un contrôle manuel de vingt de ces lignes, environ la moitié se sont révélées être des décisions du service : elles passaient depuis des années d'une fiche de spécifications à l'autre.

Le modèle ne pouvait pas extraire ces informations du cahier des charges. Elles n'y figuraient pas. C'est pourquoi les anciennes fiches et les standards du service ont été ajoutés au système. La concordance des réponses sur deux sites est devenue une raison de proposer un analogue avec plus d'assurance qu'un exemple unique. Toutefois, les paramètres propres à un environnement donné exigent de la prudence : la valeur d'un site voisin peut ne pas convenir.

Dans l'interface de travail, chaque réponse comporte un lien vers l'article du document, la citation et la page avec surlignage. En l'absence de fondement, la ligne reste vide et est versée aux questions au client. Les conclusions relatives aux normes sont proposées séparément par le système, avec une explication, pour validation par l'ingénieur.

Un tel produit aide à collecter et à vérifier l'information. Sa valeur pratique dépend notamment de la facilité avec laquelle le spécialiste peut confirmer une valeur, la corriger et enregistrer la décision pour le projet suivant.

Les beaux pourcentages exigent d'être vérifiés

L'auteur a trouvé plusieurs erreurs dans sa propre évaluation. Les cases à cocher des formulaires étaient mal lues. Les réponses du site évalué entraient dans la base via d'anciens standards : le résultat affichait 71 % au lieu des 61 % réels. Une comparaison approximative prenait IP54 pour IP65, alors qu'il s'agit de désignations de protection différentes.

Enfin, plus de la moitié des lignes du formulaire se sont révélées être des exigences, des listes et des signatures. Après leur exclusion, le taux de remplissage est passé de 45 à 81 %. Pas une seule bonne réponse n'a été ajoutée : c'est le dénominateur qui a été corrigé.

Les 73–86 % finaux ont eux aussi leurs limites. Bien que le système n'ait pas vu les réponses des trois sites de validation, l'auteur a ajusté les règles d'après leurs erreurs. Pour deux sites, les tableaux issus de scans ont été reportés à la main dans Excel. C'est un résultat de banc d'essai ; la vérification sur un nouveau site reste à faire.

Conclusion pratique pour le développeur : avant de changer de LLM, il vaut la peine de vérifier la structure du formulaire, les sources de connaissances, la recherche et la méthode d'évaluation. Pour le product manager, la question suivante est de savoir combien de temps l'ingénieur consacre à la vérification et aux corrections. C'est ce qui montrera dans quelle mesure le système aide réellement au travail.