RAG : des articles bonus pour des méthodes NLP explicables

Une série dédiée aux aspects complémentaires de RAG détaille ce que l’ingénierie exige au-delà de l’invite LLM. Du traitement des fautes et du bruit OCR aux tableaux PDF et aux mocks, ces bonus formalisent des méthodes rapides, explicables et évaluées par modes d’échec, avec des références publiques et des contrats précis entre briques.

Justifier l’absence de réponse et tester sans tricher

Lorsqu’un système RAG indique « je ne sais pas », une absence de justification est considérée comme presque aussi problématique qu’une réponse incorrecte et confiante, qui est vue comme un bug. Chaque composant du pipeline doit alors fournir à l’utilisateur des preuves concrètes : ce qui a été analysé, le vocabulaire recherché, les pages consultées et les raisons pour lesquelles aucune correspondance n’a été trouvée. Pour les tests, la série insiste sur l’importance de mocks fidèles : simplifier un type de retour par commodité peut masquer un bug de production. Les mocks doivent donc reproduire exactement la structure des objets, même si cela complique la mise en place des tests. Cette exigence de justification et de fidélité s’applique à chacune des quatre briques du pipeline.

Tableaux PDF : éviter l’aplatissement et adopter quatre niveaux

Les tableaux présents dans les PDF sont un point de fragilité pour de nombreux pipelines RAG, qui échouent souvent sans signaler d’erreur. Un arbre de décision linéaire par type de tableau ne suffit pas, car les dimensions des tableaux se croisent. La série recommande une représentation structurée en quatre niveaux, impliquant un choix explicite lors du parsing, une règle de récupération adaptée et un contrat de génération spécifique aux tableaux. Il est déconseillé d’aplatir la grille, afin de préserver la structure d’origine.

Bruit, fautes, OCR : au-delà de la correction orthographique classique

Le texte bruyant regroupe trois sources principales : fautes de frappe de l’utilisateur, erreurs issues d’une transcription rapide et caractères erronés produits par l’OCR. Les méthodes classiques de correction orthographique, comme Levenshtein, BK-tree, Soundex ou SymSpell, ne traitent qu’une seule de ces origines. Les embeddings et les LLM sont utilisés pour absorber les deux autres types de bruit. Ces perturbations affectent à la fois le parsing du corpus, la formulation des questions et la récupération, qui doit être capable de gérer ces variations.

Des bonus avec références publiques, contrats et modes d’échec

Chaque bonus s’appuie sur des sources publiques, parmi lesquelles figurent des publications du NIST, des articles disponibles sur arXiv, des corpus disposant d’une licence ouverte ou encore des scénarios fictifs créés pour la série. Les captures d’écran dépourvues de fichier source sont interdites. Chaque bonus se positionne explicitement par rapport aux quatre briques du pipeline et à leurs contrats typés et traçables, et rapporte les résultats par mode d’échec plutôt que par chiffres agrégés. Les articles écartent toute promesse d’outil miracle, privilégiant du code simple et des tables relationnelles. Les bonus sont conçus pour rester valables indépendamment des articles principaux, comme l’illustrent B01 (corrections) et B04 (tableaux).

Choisir l’échelon utile : du mot-clé aux embeddings, avant l’invite

Interroger directement un LLM est décrit comme lent, coûteux et difficile à expliquer après coup. Six options plus économiques sont présentées : recherche par correspondance exacte, correction d’une lettre, utilisation de mots-clés issus d’un lexique d’expert, ainsi que les embeddings pour traiter le reste du vocabulaire. La majorité des requêtes trouve une solution grâce à l’une de ces approches en quelques millisecondes, chacune étant capable de spécifier la règle employée. Cette gradation de méthodes sert à résoudre des cas concrets tels que la classification d’une requête, le rapprochement d’un texte libre avec une liste de référence, l’extraction de données de tableaux, la gestion du bruit OCR ou l’exécution d’un modèle localement lorsque le corpus ne peut être exporté.

Pourquoi des bonus et quand inverser le pipeline

Un pipeline RAG opérationnel soulève des questions d’ingénierie que la colonne principale ne peut pas traiter sans perdre sa cohérence. Quatre schémas récurrents justifient le recours à des articles bonus, qui évitent la dispersion en fils sociaux ou commentaires de blog et permettent une vue transversale où les briques s’alignent sur une même préoccupation. La forme de bonus la plus fréquente traite de préoccupations pratiques qui traversent plusieurs jonctions entre briques, avec des propositions de discipline adoptables sans réécriture des composants. La série aborde aussi des formes alternatives de pipeline lorsque le corpus n’est pas un ensemble de PDF adversariaux, par exemple sous forme de FAQ : dans ces cas, les compromis s’inversent et l’ensemble du pipeline se reconfigure, sans remettre en cause la forme de base.