Comment l'IA détecte ses propres erreurs et se corrige en temps réel

L'IA, UNE DERNIÈRE LIGNE DE DÉFENSE CONTRE LES ERREURS

Parfois, une intelligence artificielle renvoie une réponse fausse sans que rien ne semble suspect. C’est le cas des Outils d’OCR (reconnaissance de texte) classiques : ils lisent correctement les mots, mais oublient la structure d’un tableau. Résultat, la réponse semble correcte… jusqu’à ce qu’on vérifie sur le document original. Dans ces situations, l’IA a besoin d’un système pour repérer ses propres erreurs avant que l’utilisateur ne les découvre.

Ce système s’appelle une boucle de rétroaction. Il fonctionne comme un contrôle qualité intégré directement dans le processus de traitement des documents. Au lieu de se fier uniquement aux outils de parsing (analyse de documents) en amont, l’IA utilise ses propres réponses pour détecter les incohérences.

Ce mécanisme est au cœur de la deuxième partie d’une série dédiée à l’intelligence documentaire d’entreprise. Cette série explique comment construire un système de RAG (Retrieval-Augmented Generation, génération augmentée par récupération) à partir de quatre briques : l’analyse de documents, l’analyse des questions, la récupération d’informations et la génération de réponses. La première partie, intitulée « L’ingénierie des boucles avec un parsing adaptatif : commencer bon marché, payer plus cher seulement quand c’est nécessaire », avait présenté la cascade d’escalade et les vérifications déterministes qui repèrent gratuitement les erreurs de parsing. Cette deuxième partie ajoute l’IA comme dernière ligne de défense, avec deux exemples concrets d’escalade automatique.

COMMENCER SIMPLE, ESCALADER QUAND C’EST NÉCESSAIRE

Exécuter le parser le plus lourd sur chaque page d’un document est un gaspillage. À l’inverse, utiliser uniquement le parser le plus simple partout est une erreur. La solution ? Commencer par le parser le moins cher, puis escalader vers un outil plus puissant uniquement quand un signal indique que la première analyse a échoué.

Ce signal doit provenir du pipeline lui-même : une série de vérifications appliquées sur le résultat du parsing, la question posée, et les traces laissées par l’IA lorsqu’elle tente d’utiliser les informations extraites.

La boucle de rétroaction fonctionne ainsi :

• Le système commence par le parser le moins cher (par exemple, PyMuPDF pour les PDF).
• À chaque étape du pipeline, une vérification évalue si le parsing est suffisant pour répondre à la question.
• Si une vérification échoue, le pipeline escalade vers un parser plus avancé (comme Azure Document Intelligence pour les tableaux ou un modèle de vision pour les images).

Cette cascade de vérifications est organisée en plusieurs étapes, chacune moins chère mais aussi moins fiable que la suivante. Chaque étape pose sa propre question : « Le parsing a-t-il produit assez d’informations pour répondre à la question ? »

DEUX CAS CONCRETS D’ESCALADE AUTOMATIQUE

Les deux exemples suivants illustrent comment cette boucle fonctionne en pratique. Ils sont tirés d’un article scientifique réel, le célèbre papier « Attention Is All You Need » de Vaswani et al. (2017), et représentent des situations courantes dans les documents d’entreprise :

Prenons deux questions sur le papier « Attention Is All You Need » :

1. « Quelle est la valeur de h pour le modèle de base dans le tableau des variations de l’architecture Transformer ? »
2. « Quelle est l’architecture du Transformer ? »

La première question cible un tableau (Table 3, page 9), la seconde une image (Figure 1, page 3). Dans les deux cas, le parser bon marché (PyMuPDF) ne parvient pas à extraire correctement les informations nécessaires. C’est là que la boucle de rétroaction entre en jeu.

CAS 1 : EXTRAIRE UNE VALEUR D’UN TABLEAU

La question porte sur la valeur de h dans le tableau des variations de l’architecture Transformer. La bonne réponse est 8, visible dans la cellule de la ligne « base » du tableau. Pourtant, PyMuPDF, qui analyse le PDF ligne par ligne, ne conserve pas la structure du tableau. Il retourne les 13 cellules de la ligne « base » comme 13 lignes séparées, sans lien entre elles.

Le code suivant montre comment le système commence par PyMuPDF :

linedf = fitzpdftoline_df("data/paper/1706.03762v7.pdf")
pagedf = buildpagedf(linedf)

# line_df.shape ~ (1500, 8)
# colonnes : pagenum, linenum, text, x0, y0, x1, y1, character_count

Le système utilise ensuite une étape de récupération pour identifier les pages pertinentes :

from docintel.retrieval import retrieve_pages

retrievedpagesdf, filteredlinedf = retrieve_pages(
    pagedf, linedf,
    keywords=["Table 3: Variations on the Transformer architecture"],
    top_k=5,
)

Puis, il génère une réponse avec l’IA en utilisant les lignes filtrées :

from docintel.generation import llmanswerwith_evidence
from docintel.generation.qa.schemas import AnswerWithEvidence

pass1: AnswerWithEvidence = llmanswerwith_evidence(
    question=("What is the value of h for the base model "
              "in Table of Variations on the Transformer architecture?"),
    filteredlinedf=fitz_p9,    # Lignes PyMuPDF pour la page 9
)

La réponse obtenue est :

{
  "answer": "8",
  "startpagenum": 9,
  "startlinenum": 25,
  "endpagenum": 9,
  "endlinenum": 25,
  "confidence": 0.99,
  "justification": "In the table listing parameters for different Transformer .",
  "caveats": [],
  "completeanswerfound": true,
  "context_structured": false,
  "llmdiscoveredkeywords": []
}

L’IA a trouvé la bonne réponse (8), mais elle a aussi détecté un problème : context_structured=false. Cela signifie que la structure du tableau n’a pas été correctement préservée. L’IA a dû compter les colonnes pour identifier que la cellule L25 correspondait à h. Ce n’est pas fiable : la prochaine question similaire pourrait échouer.

Le système déclenche alors une escalade vers un parser plus avancé, comme Azure Document Intelligence :

from docintel.parsing.pdf.azurelayout import azurelayoutpdftolinedf

azurep9 = azurelayoutpdftolinedf(
    "data/paper/1706.03762v7.pdf",
    pages=[9],     # seule la page identifiée est analysée
)

# azure_p9.shape ~ (52, 9)
# colonnes : pagenum, linenum, text, x0, y0, x1, y1, charactercount, parsingmethod
# Chaque ligne porte parsingmethod == "azurelayout"

Azure retourne le tableau sous forme de lignes structurées en markdown, une ligne par ligne de tableau. La réponse générée ensuite est :

{
  "answer": "8",
  "startpagenum": 9,
  "startlinenum": 7,
  "endpagenum": 9,
  "endlinenum": 7,
  "confidence": 0.98,
  "justification": "In Table 3 (line 7), the 'base' model lists its hyperpara.",
  "caveats": [],
  "completeanswerfound": true,
  "context_structured": true
}

Cette fois, context_structured=true. L’IA n’a plus besoin de compter les colonnes : la structure du tableau est clairement définie. Le coût ? Un appel supplémentaire à Azure DI (environ 0,003 $ et quatre secondes). Le gain ? La réponse est désormais fiable, et la structure du tableau est enregistrée pour toute question future sur cette page.

VISUALISER LA PREUVE : ANNOTER LE DOCUMENT ORIGINAL

Pour rendre le processus transparent, le système génère une annotation visuelle sur le PDF original. Cela permet à un réviseur de vérifier en une seconde que la cellule citée correspond bien à la réponse de l’IA :

from docintel.rendering.pdf.annotation import (
    passagelinesdffromanswer,
    passagebboxby_page,
    drawpassagerectangles,
)

passagedf = passagelinesdffromanswer(linedf, pass1)
bboxesdf  = passagebboxbypage(passage_df)

drawpassagerectangles(
    pdf_path="data/paper/1706.03762v7.pdf",
    bboxesdf=bboxesdf,
    outpdfpath="output/parsingcomparison/hvalue_annotated.pdf",
)

Le résultat est un PDF annoté où la cellule contenant la valeur 8 est mise en évidence. Même si l’escalade a eu lieu, la trace de l’analyse initiale (PyMuPDF) est conservée, garantissant une traçabilité complète.

LE RÔLE DU MODÈLE D’IA DANS LA DÉTECTION DES ERREURS

Pour comprendre comment la qualité du parser interagit avec la force du modèle d’IA, les développeurs ont testé la même question avec trois modèles (GPT-4o-mini, GPT-4o et GPT-4.1) et les deux parsers (PyMuPDF et Azure DI). Les résultats montrent deux tendances clés :

En revanche, le flag context_structured varie de manière utile :

• GPT-4o-mini et GPT-4o acceptent les lignes plates de PyMuPDF sans signaler de problème.
• GPT-4.1, plus puissant, signale le risque structurel même s’il a trouvé la bonne réponse.

Cela signifie qu’un modèle plus avancé est un meilleur rapporteur des risques de parsing en amont. Cependant, la solution la plus durable reste d’améliorer le parser lui-même, car cela supprime le risque structurel une fois pour toutes. Dans un pipeline de production, combiner les deux approches (amélioration du parser et du modèle) permet de couvrir les faiblesses de chacun.

CAS 2 : EXTRAIRE UNE ARCHITECTURE D’UNE IMAGE

La deuxième question porte sur l’architecture du Transformer : « Quelle est l’architecture du Transformer ? ». La réponse est principalement portée par la Figure 1 (page 3), un schéma montrant l’architecture encodeur-décodeur.

Avec PyMuPDF, la page 3 est récupérée, mais la figure est représentée par une ligne de type type='image' avec un texte placeholder. Le contenu réel de l’image est absent. Le système génère une réponse partielle avec une mise en garde :

{
  "answer": "The Transformer uses a stack of 6 encoder layers and 6 decoder l.",
  "startpagenum": 3,
  "startlinenum": 12,
  "endpagenum": 3,
  "endlinenum": 14,
  "confidence": 0.55,
  "caveats": [
    "Figure 1 is referenced in the prose but its content is absent fr."
  ],
  "completeanswerfound": false,
  "context_structured": true
}

Le système détecte que la figure est référencée mais vide. Il consulte alors la table des images et voit que parsingmethod='notparsed'. Il escalade donc vers un modèle de vision (ici, GPT-4o) pour extraire le contenu de l’image :

newlines = visionextract(
    "data/paper/1706.03762v7.pdf",
    pages=[3],
    image_ids=[1],
)

# newlines.parsingmethod == "vision_gpt4o"
# La ligne imagedf.imageid=1 passe de parsingmethod='notparsed' à 'vision_gpt4o'

Le modèle de vision retourne une description structurée de l’architecture : un encodage d’entrée, six couches identiques dans l’encodeur (chaque couche contient un mécanisme d’auto-attention multi-têtes avec connexions résiduelles et normalisation), puis un décodeur miroir avec une auto-attention masquée et une attention croisée vers la sortie de l’encodeur, suivi d’une couche linéaire et d’un softmax pour le vocabulaire.

Cette description est ajoutée au line_df comme de nouvelles lignes de texte avec parsingmethod='visiongpt4o'. La génération finale produit alors une réponse complète et fiable.

LA CASCADE DE VÉRIFICATIONS : UNE SUITE LOGIQUE DE CONTRÔLES

Le système repose sur une cascade de vérifications, chacune plus fiable mais aussi plus coûteuse que la précédente. Voici comment cela fonctionne :

1. Vérification 1 : Parsing déterministe (Article 6). Repère les erreurs évidentes avant même la génération de la réponse.
2. Vérification 2 : Empreinte de l’IA (Article 7). Analyse la question et le résultat du parsing pour détecter les incohérences.
3. Vérification 3 : Auto-évaluation de l’IA (Check 7). L’IA évalue elle-même si sa réponse est complète et fiable.
4. Vérification 4 : Vérification de groundedness (Check 8). Un autre modèle ou un système de NLI (Natural Language Inference) vérifie que la réponse est bien ancrée dans les données sources.

Chaque vérification est conçue pour être moins chère que la suivante, mais aussi plus fiable. Si une vérification échoue, le pipeline escalade vers l’étape suivante. Si toutes les vérifications passent, la réponse est validée et affichée à l’utilisateur.

POURQUOI CETTE MÉTHODE CHANGE LA DONNE

Cette approche résout un problème majeur des systèmes d’IA actuels : les réponses fausses mais convaincantes. Un utilisateur peut facilement croire une réponse qui semble correcte, surtout si l’IA affiche une confiance élevée. Pourtant, cette confiance peut être mal placée si le parsing en amont a échoué.

En intégrant l’IA comme dernière ligne de défense, le système devient auto-correcteur. Il ne se contente pas de détecter les erreurs : il les corrige en temps réel, sans intervention humaine. Cela ouvre la voie à des applications plus fiables dans des domaines critiques, comme la santé, la finance ou le juridique, où une erreur peut avoir des conséquences graves.

De plus, cette méthode optimise les coûts : elle n’utilise les outils les plus puissants (et les plus chers) que lorsque c’est nécessaire. PyMuPDF reste le choix par défaut pour les questions simples, tandis que les parsers avancés ou les modèles de vision ne sont sollicités que pour les cas complexes.

LIMITES ET PERSPECTIVES : UN SYSTÈME EN CONSTANTE AMÉLIORATION

Malgré ses avantages, cette méthode n’est pas parfaite. Le flag context_structured dépend de la capacité du modèle à détecter les risques structurels. Un modèle moins avancé peut ne pas signaler une erreur, même si elle est évidente pour un humain. À l’inverse, un modèle trop prudent peut déclencher des escalades inutiles, augmentant les coûts et les temps de réponse.

Une solution consiste à combiner plusieurs modèles pour la détection des erreurs. Par exemple, utiliser un modèle léger pour une première détection, puis un modèle plus puissant pour confirmer. Une autre piste est d’améliorer les parsers eux-mêmes, pour qu’ils préservent mieux la structure des documents dès l’étape initiale.

À l’avenir, ces systèmes pourraient intégrer des mécanismes d’apprentissage automatique pour affiner leurs propres critères de détection d’erreurs. L’objectif ? Créer une IA qui non seulement se corrige, mais apprend de ses erreurs pour devenir toujours plus fiable.

EN PRATIQUE : COMMENT REPRODUIRE CE SYSTÈME

Pour ceux qui veulent tester cette méthode, le projet propose un notebook exécutable qui parcourt les deux escalades de bout en bout. Vous pouvez parser une page de tableau avec PyMuPDF, puis la re-parser avec Azure, et envoyer une page avec une figure à un modèle de vision. Le notebook montre comment le flag context_structured bascule de False à True, passant d’une réponse fausse à une réponse correcte.

Le code est disponible sur GitHub : doc-intel/notebooks-vol1. Il suffit de suivre les instructions pour reproduire les deux cas d’escalade et comprendre comment le système fonctionne.

CE QUE ÇA CHANGE POUR LES UTILISATEURS D’IA

Cette méthode représente une avancée majeure pour la fiabilité des systèmes d’IA. Elle montre qu’une intelligence artificielle peut non seulement répondre à des questions, mais aussi vérifier ses propres réponses et les corriger si nécessaire. Cela réduit considérablement le risque de propager des informations fausses, un problème récurrent dans les outils d’IA grand public.

Pour les entreprises, cela signifie des systèmes plus robustes pour l’analyse de documents, la recherche d’informations ou l’automatisation des processus. Pour les développeurs, cela ouvre la porte à de nouvelles architectures de pipelines d’IA, plus intelligentes et plus fiables. Et pour les utilisateurs finaux, cela garantit des réponses plus précises et plus dignes de confiance.

À l’ère de l’IA générative, où les réponses fausses mais plausibles sont un fléau, cette approche pourrait bien devenir la norme. Elle rappelle que l’intelligence artificielle ne se limite pas à générer du texte : elle peut aussi apprendre à se surveiller elle-même.