Ingosstrakh apprend à une LLM multimodale à douter : les erreurs dans les documents détectées via les logprobs

L'équipe des technologies avancées du Centre de développement de l'intelligence artificielle de SPAO Ingosstrakh a publié sur Habr une analyse de la façon de détecter les erreurs dans les réponses d'une LLM multimodale qui extrait des données structurées de documents entrants directement, sans passer par l'OCR. L'outil retenu ne nécessite pas de modèle évaluateur distinct : il s'agit des logprobs, les logarithmes des probabilités des tokens, que le modèle produit de toute façon à la génération. La question est très concrète : parmi des milliers de documents traités, lesquels envoyer à un opérateur humain, et lesquels laisser passer automatiquement ?

Un JSON valide, mais sans garantie

La tâche relève de l'Intelligent Document Processing (IDP). En entrée, un scan ou une photo de document ; en sortie, un JSON avec des champs : nom complet, numéro de passeport, dates, montants. Le modèle multimodal lit lui-même l'image, sans reconnaissance de texte intermédiaire.

Ce schéma a un défaut gênant. Une erreur sur un chiffre du passeport ou sur une lettre du nom de famille ne casse pas le format de la réponse. La structure est correcte, le parseur est satisfait, et des données erronées partent vers le système suivant sous l'apparence de données fiables. Les clients l'ont vite remarqué et ont demandé un confidence score : une estimation permettant d'écarter les résultats suspects.

Dans les pipelines OCR classiques comme CRNN, Surya, EasyOCR ou Tesseract, une telle estimation est généralement disponible au niveau du caractère, du mot ou de la ligne. Les auteurs précisent qu'elle ne garantit pas l'exactitude et peut nécessiter une calibration, mais qu'elle sert de signal de départ pour la sélection. Le système LLM d'Ingosstrakh ne disposait pas d'un tel signal.

D'où vient le signal

À chaque étape, le modèle choisit le token suivant en tenant compte de l'image, de l'instruction et du texte déjà généré. On peut obtenir le logprob du token choisi. Plus la valeur est basse, moins la suite était attendue par le modèle lui-même.

Une réserve importante de l'article : les logprobs ne répondent pas à la question « le champ a-t-il été reconnu correctement ? ». Ils indiquent seulement avec quelle assurance le modèle a suivi sa propre trajectoire. Un modèle peut se tromper avec assurance, et une réponse correcte peut recevoir une faible probabilité à cause d'un format rare ou d'un mauvais scan. L'équipe n'utilise donc pas les probabilités brutes directement : elle en construit une estimation du risque et la confronte aux erreurs réelles sur les données de l'entreprise.

Ce que l'on sait à partir de l'introduction publiée :

• tâche : extraction de données structurées à partir de documents entrants (IDP) ;
• architecture : LLM multimodale sans étape d'OCR distincte ;
• demande métier : un confidence score pour router les documents vers la vérification manuelle ;
• source du signal : les logprobs des tokens choisis ;
• validation : sur des données réelles ; les métriques de qualité précises figurent dans l'article complet.

L'introduction ne contient aucun résultat chiffré. Il est donc trop tôt pour juger de la capacité de l'estimation du risque à séparer les réponses erronées des réponses correctes.

Comment appliquer cette approche

Ce qui suit relève de mes conclusions tirées de l'énoncé du problème, et non d'un résumé des résultats des auteurs.

Premièrement : il vaut mieux évaluer les champs que le document entier. La confiance moyenne sur une réponse dilue facilement un seul token douteux dans un numéro de passeport. Il est donc logique de regarder le minimum, ou une autre agrégation, sur les tokens du champ concerné.

Deuxièmement : le seuil de vérification doit être ajusté au coût de l'erreur. Pour le nom complet et les pièces d'identité, il doit être plus strict que pour les champs facultatifs.

Troisièmement : sans échantillon annoté, le signal est inutile. Pour savoir si les faibles probabilités sont corrélées aux erreurs réelles, il faut des réponses de référence et une mesure de la part d'erreurs détectées par rapport à la charge des opérateurs. La calibration que les auteurs mentionnent à propos de l'OCR sera nécessaire ici aussi.

Quatrièmement : il faut revérifier la logique lors d'un changement de modèle ou de version du prompt. La distribution des probabilités diffère d'un modèle à l'autre, et un seuil réglé pour l'un peut se comporter autrement sur un autre.

Pour les équipes qui construisent des pipelines LLM de traitement de documents, la conclusion principale est simple : le confidence score s'obtient presque gratuitement, mais ce n'est qu'après validation sur ses propres données qu'il passe du statut de simple nombre à celui d'outil de routage opérationnel.