Quand une IA analyse vos données avec RAG, elle invente des résultats qui semblent justes. Pourtant, elle n’a vu que 8 % des informations. Voici comment corriger cette erreur.

Imaginez : vous posez une question simple à votre assistant IA sur vos dépenses mensuelles. RAG (Retrieval-Augmented Generation, un outil qui mélange recherche et Génération de texte) vous répond avec un tableau détaillé, des chiffres précis, une mise en forme professionnelle. Tout a l’air parfait. Sauf que… 92 % de vos données ont disparu. L’IA a simplement additionné les 8 % qu’elle a récupérés et vous a servi un résultat faux, mais tellement bien présenté que vous ne vous en rendez même pas compte.

Cette situation, un ingénieur l’a vécue en testant son propre outil. Il a d’abord cru que son système fonctionnait à merveille. Jusqu’à ce qu’il réalise que les chiffres étaient complètement faux. Pire : plus il donnait de contexte à l’IA, plus elle devenait convaincante… mais pas plus précise.

« Le problème n’est pas que l’IA échoue. C’est qu’elle échoue en silence, avec une confiance trompeuse. »

UNE DÉCOUVERTE QUI A TOUT CHANGÉ

L’ingénieur travaillait sur un système pour EmiTechLogic, une plateforme qui permet aux utilisateurs d’importer leurs fichiers CSV et de poser des questions en langage naturel sur leurs données. L’idée ? Utiliser RAG pour analyser les tableaux. Les premières démonstrations semblaient parfaites : des tableaux clairs, des chiffres qui s’additionnaient, une présentation professionnelle. Il a commencé à faire confiance à son outil.

Puis il a remarqué quelque chose d’étrange. Pour une requête comme « Quel est le total des dépenses par catégorie ? », le système lui retournait une réponse qui semblait exacte. Pourtant, quand il a additionné manuellement les chiffres fournis par l’IA, il a obtenu un résultat bien inférieur à la réalité. Le vrai total des dépenses pour la catégorie « grocery_pos » était de 1 140 033,24 $. L’IA lui en avait retourné seulement une partie.

Il a alors augmenté la taille du contexte de l’IA : 4 000 tokens, puis 16 000, 32 000, 128 000. Chaque fois, la réponse devenait plus longue, plus détaillée, et plus fausse. L’IA ne se contentait plus de manquer des données : elle inventait des résultats qui semblaient crédibles.

COMMENT RAG TRAVAILLE (ET POURQUOI ÇA NE MARCHE PAS)

Pour comprendre l’erreur, il faut voir comment RAG analyse un fichier CSV. Prenons un exemple concret :

2019-01-01 grocery_pos 107.23 F NC Jennifer Banks .

Quand vous demandez « Quel est le total des dépenses par catégorie ? », RAG fait ceci :

  1. Tokenise les mots-clés de la requête : ["total", "spend", "category"]
  2. Compare ces mots à chaque ligne du fichier CSV (100 000 lignes dans ce cas)
  3. Sélectionne les 5, 50, 500 ou 2 000 lignes les plus pertinentes (selon la taille du contexte)
  4. Transforme ces lignes en texte brut et demande à l’IA de faire la somme et le regroupement

Le problème ? L’IA ne fait pas vraiment de calcul. Elle reconnaît des motifs dans le texte qu’on lui donne. Elle repère les nombres, les additionne, et génère une réponse qui ressemble à une analyse sérieuse. Mais elle ne voit qu’une infime partie des données.

« RAG est un outil de recherche, pas une calculatrice. Il trouve des morceaux de texte pertinents, mais il ne peut pas faire de calculs précis sur l’ensemble des données. »

LA PREUVE PAR LES CHIFFRES

Pour mesurer l’ampleur du problème, l’ingénieur a construit un benchmark (un test comparatif) entre deux systèmes :

  1. Un simulateur RAG qui extrait des morceaux de données (5, 50, 500, 2 000 ou 8 000 lignes) et demande à l’IA de faire les calculs
  2. Un moteur sémantique qui analyse l’intégralité des 100 000 lignes et donne le résultat exact

Voici ce que le benchmark a révélé pour la requête « Quel est le total des dépenses par catégorie ? » :

Contexte               Lignes   Couverture    Somme partielle  Erreur détectable ?
tiny   (~325 tokens)     5   0,0050 %         197,73  FACILE
small  (~3K tokens)     50  0,0500 %        2 003,56  MODÉRÉE
medium (~32K tokens)   500  0,5000 %       31 023,21  DIFFICILE
large  (~130K tokens)  2 000 2,0000 %      140 093,16  TRÈS DIFFICILE
xlarge (~520K tokens)  8 000 8,0000 %      569 368,22  PRESQUE IMPOSSIBLE

Le vrai total est de 1 140 033,24 $. Avec seulement 8 000 lignes (8 % des données), l’IA a calculé une somme partielle de 569 368,22 $. L’erreur dépasse 50 %, mais la réponse ressemble à un rapport professionnel de 1 500 mots. Sans vérifier manuellement, impossible de détecter l’erreur.

LE PIÈGE DE LA CONFIANCE TROMPEUSE

L’ingénieur a appelé ce phénomène Error Observability Collapse (l’effondrement de la détection des erreurs) : plus le contexte est grand, plus l’IA semble sûre d’elle… mais pas plus précise. Les erreurs deviennent invisibles parce que la présentation est parfaite.

Ce qui est dangereux, c’est que l’IA ne signale jamais son incertitude. Elle retourne une réponse structurée, avec des décimales, des catégories, des totaux… comme si elle avait tout analysé. Pourtant, elle n’a vu qu’une infime partie des données.

« Une mauvaise réponse RAG ressemble à une bonne réponse. Elle est formatée, spécifique, et confiante. Une vraie erreur de calcul, elle, affiche un message d’erreur clair. »

LA SOLUTION : UN ROUTEUR DE REQUÊTES

L’ingénieur a alors construit un système simple pour éviter ce problème. Au lieu d’envoyer toutes les requêtes à RAG, il a créé un QueryRouter (un routeur de requêtes) qui classe les questions avant de les traiter :

  1. Si la requête demande un calcul (somme, moyenne, pourcentage, etc.), il l’envoie à un moteur sémantique qui analyse toutes les données
  2. Si la requête demande une recherche (trouver une transaction, lister des éléments), il l’envoie à RAG

Voici comment ça fonctionne en code :

from query_router import QueryRouter

router = QueryRouter(rows)

result = router.route("Quel est le total des dépenses par catégorie ?")
# result.routed_to     → "COMPUTATION"
# result.answer.answer → [(grocery_pos, 1140033.24), .]
# result.total_latency → ~250ms (classification + exécution)

result = router.route("Trouver les transactions de Jennifer Banks")
# result.routed_to     → "RETRIEVAL"
# result.answer.safe   → True (RAG est adapté)

Le routeur utilise trois niveaux de détection :

  • Tier 1 : mots liés aux calculs (total, somme, moyenne, plus haut, pourcentage, etc.)
  • Tier 2 : comparaisons numériques (supérieur à 500, inférieur à 1 000, etc.)
  • Tier 3 : mots liés à la recherche (trouver, montrer, lister, etc.)

Si aucune correspondance n’est trouvée, le routeur envoie la requête par défaut vers le moteur de calcul. Mieux vaut une erreur visible qu’une fausse certitude.

LES RÉSULTATS DU BENCHMARK APRÈS ROUTAGE

L’ingénieur a testé 9 requêtes différentes avec le routeur : 7 pour les calculs, 2 pour les recherches. Résultat : 9/9 correctes.

Voici les performances pour les requêtes de calcul :

[1] ✓ COMPUTATION   "Quel est le total des dépenses par catégorie ?"
     Tier 1 | matched='total' | confiance=0.97
     #1 grocery_pos      1 140 033,24  (102,57ms | 100 000 lignes | exact)

[2] ✓ COMPUTATION   "Quelle catégorie a le montant moyen le plus élevé ?"
     Tier 1 | matched='highest' | confiance=0.97
                               71,91  (119,47ms | 100 000 lignes | exact)

[3] ✓ COMPUTATION   "Quel est le total dépensé en grocery_pos ?"
     Tier 1 | matched='total' | confiance=0.97
                        1 140 033,24  (49,96ms  | 100 000 lignes | exact)

[4] ✓ COMPUTATION   "Combien de transactions ont été faites par des clientes ?"
     Tier 1 | matched='How many' | confiance=0.97
                           54 641,00  (90,45ms  | 100 000 lignes | exact)

[5] ✓ COMPUTATION   "Quel est le total dépensé pour des montants supérieurs à 500 ?"
     Tier 1 | matched='total' | confiance=0.97
                        1 274 269,60  (91,65ms  | 100 000 lignes | exact)

[6] ✓ COMPUTATION   "Quel État a les dépenses totales les plus basses ?"
     Tier 1 | matched='lowest' | confiance=0.97
     lowest RI               2 125,60  (109,05ms | 100 000 lignes | exact)

[7] ✓ COMPUTATION   "Quel pourcentage de transactions sont frauduleuses ?"
     Tier 1 | matched='percentage' | confiance=0.97
                              0,9900%  (87,35ms  | 100 000 lignes | exact)

[8] ✓ RETRIEVAL     "Trouver les transactions de Jennifer Banks"
     Tier 3 | matched='Find' | confiance=0.85
     RAG est adapté — pas de calcul nécessaire

[9] ✓ RETRIEVAL     "Montrer un exemple de transaction du Texas"
     Tier 3 | matched='Show me' | confiance=0.85
     RAG est adapté — pas de calcul nécessaire

Le routeur a une précision de 100 %. Toutes les requêtes de calcul sont envoyées au moteur sémantique, qui retourne des résultats exacts en moins de 200 ms. Les requêtes de recherche restent gérées par RAG, qui fonctionne parfaitement pour ce type de tâche.

POURQUOI CETTE SOLUTION EST SI SIMPLE (ET SI EFFICACE)

L’ingénieur a testé une solution encore plus basique au début : un moteur sémantique qui analyse directement les données sans passer par RAG. Le principe est simple :

  1. Parser la requête en opérations mathématiques (ex: « total des dépenses par catégorie » → SUM(amt) GROUP BY category)
  2. Scanner l’intégralité du fichier CSV une seule fois
  3. Retourner le résultat exact

Résultat : les requêtes sont résolues en moins de 200 ms, même avec 100 000 lignes. Aucune intelligence artificielle n’est nécessaire pour faire des calculs. Le problème vient du fait qu’on demande à RAG de faire ce qu’il ne sait pas faire.

Le routeur de requêtes n’est qu’une couche de classification qui coûte presque rien : quelques microsecondes pour analyser une requête. Le moteur sémantique ajoute moins de 200 ms de latence. En échange, vous obtenez des résultats déterministes (exacts à chaque fois) pour toutes les requêtes de calcul.

LES LIMITES (ET CE QU’IL RESTE À FAIRE)

Cette solution a des limites :

  • Elle ne fonctionne que sur des fichiers CSV simples. Les bases de données avec plusieurs tables et des jointures ne sont pas supportées
  • Le routeur utilise des expressions régulières, ce qui peut être limité pour des requêtes très complexes
  • Le simulateur RAG ne teste pas de vraies API d’IA (comme GPT-4o ou Claude 3.5), donc les résultats peuvent varier légèrement

Mais ces limites sont volontaires : l’ingénieur a voulu d’abord créer un système qui fonctionne end-to-end (de bout en bout), avant de complexifier. Parfois, la solution la plus simple est la meilleure.

COMMENT TESTER LE SYSTÈME SOI-MÊME

Pour reproduire les tests, il suffit de suivre ces étapes :

  1. Cloner le dépôt GitHub :
    git clone https://github.com/Emmimal/context-window-engine/
  2. Se déplacer dans le dossier :
    cd context-window-engine
  3. Lancer la démo :
    python demo.py

Le projet inclut deux suites de tests :

  • 87 tests pour le moteur sémantique (analyse des données)
  • 72 tests pour le routeur (classification des requêtes)

Pour exécuter les tests :

python -m unittest test_engine -v  # 87 tests
python -m unittest test_router -v  # 72 tests

Tous les tests passent sur Python 3.9+ sans dépendance externe.

CE QU’IL FAUT RETENIR

RAG est un outil puissant pour la recherche et la récupération d’informations. Mais il n’est pas conçu pour faire des calculs. Quand vous lui demandez de faire une somme, une moyenne ou un pourcentage, il invente des résultats qui semblent justes… mais qui sont faux.

La solution ? Un routeur de requêtes qui sépare les requêtes de calcul (envoyées à un moteur sémantique) des requêtes de recherche (gérées par RAG). Résultat : des réponses exactes, une confiance retrouvée, et surtout… plus de surprises.

« RAG n’est pas cassé. On lui demande juste de faire ce qu’il ne sait pas faire. La vraie erreur, c’est de ne pas le savoir. »

Si vous utilisez RAG pour analyser vos données, vérifiez toujours les résultats. Ou mieux : utilisez un routeur de requêtes pour éviter les erreurs avant qu’elles n’arrivent.

Sources :
  • Towards Data Science

L'indépendance de CLODCO est votre garantie.

Pour que l'actualité de l'IA reste sans filtre et sans concession, votre soutien est indispensable. Votre contribution est le seul moteur de notre liberté éditoriale.

Soutenir CLODCO