RAG : L'IA optimise la récupération d'informations

RAG : L'IA optimise la récupération d'informations

Modèles de Langage de Grande Taille

La détection d'ancrage pour RAG : détecteurs parallèles, puis un appel LLM à la fin.

L'intelligence documentaire d'entreprise [Vol.1 #7B] – La récupération consiste à filtrer sur des tables structurées : mots-clés d'abord, table des matières ensuite, embeddings en dernier.

La récupération dans un système RAG d'entreprise consiste à filtrer sur deux tables structurées (line_df et toc_df), et chaque candidat porte une ancre (où se trouve la correspondance) plus un contexte (ce qui est développé pour la génération). Ce modèle mental est le sujet de l'article 7A (récupération comme filtrage). Cet article se concentre sur la façon dont les ancres sont produites : un pipeline en trois étapes qui exécute la détection de mots-clés et les embeddings en parallèle, agrège les résultats en une unité structurelle, et se termine par un seul appel LLM qui classe les candidats avec des raisons.

L'utilisateur tape « Comment l'attention est-elle calculée ? » sur le document Transformer. Six pages candidates correspondent à l'attention. La bonne mentionne softmax, query, key, d_k ensemble, et se trouve dans la section que la table des matières appelle « Attention par produit scalaire ». Deux récupérateurs — mots-clés et embeddings — identifient tous deux l'ensemble des candidats. Aucun d'eux ne peut à lui seul dire quelle page répond réellement à la question. Une troisième étape doit lire les candidats côte à côte, avec la section dans laquelle chacun se trouve, et choisir le bon avec une raison que l'auditeur pourra lire des mois plus tard.

Le pipeline en trois étapes qui suit repose sur trois principes :

• Les mots-clés sont toujours actifs. La détection de mots-clés est gratuite. Il n'y a aucun scénario où vous ne voudriez pas de son signal. Elle fonctionne sur line_df et toc_df dès la première milliseconde.

• Les embeddings fonctionnent en parallèle et sont optionnels. Lorsque des incohérences de vocabulaire sont attendues ou que la question est conceptuelle, les embeddings capturent ce que les mots-clés manquent. Avec des indices pré-calculés, le coût au moment de la requête est de quelques microsecondes. On peut les ignorer lorsque le signal des mots-clés est déjà clair.

• Un appel LLM à la fin. Pas d'étape de « raisonnement TOC » LLM en milieu de pipeline. L'arbitre à la phase 3 voit la TOC, les résultats des mots-clés, les résultats des embeddings, et l'attachement structurel de chaque candidat, en un seul appel. Il effectue le raisonnement sur la TOC implicitement dans le cadre du classement.

Cet article examine les détecteurs sur chaque table (Section 2 sur toc_df, Section 3 sur line_df), puis les combinaisons entre les deux tables (Section 4). L'appel de l'arbitre lui-même, l'arbre de décision, et la sortie JSON se trouvent dans l'article 7C (l'arbitre LLM et la sortie JSON de récupération).

Tout au long de cet article, nous travaillons sur un seul document, Attention Is All You Need (Vaswani et al. 2017, 15 pages ; licence de distribution non exclusive arXiv, déclarée sur la page d'abstract arXiv). Il contient une TOC native propre dans le plan PDF (22 entrées, 3 niveaux de profondeur), et le contenu est un territoire familier pour tout ingénieur touchant au RAG : encodeur, décodeur, attention, requêtes, clés, valeurs. Cela maintient l'accent sur les méthodes de récupération plutôt que sur l'analyse d'un corpus spécifique à un domaine. Cet article suppose également que le document contient sa propre TOC ; la récupération d'une TOC à partir de texte brut est laissée à un travail ultérieur.

Le pipeline de détection d'ancrage

La détection d'ancrage se déroule en trois étapes. La première étape exécute la détection de mots-clés et la similarité des embeddings en parallèle sur line_df et toc_df. La deuxième étape agrège les résultats en une unité structurelle (section via toc_df si disponible, sinon page ou morceau). La troisième étape transmet les unités agrégées à un seul appel LLM qui les classe et rédige son raisonnement pour chaque choix.

La détection de mots-clés est la base toujours active. Elle correspond aux lignes dont le texte contient les mots-clés de la question, avec des boosts de co-occurrence lorsque plusieurs mots-clés se trouvent dans la même ligne ou page. Peu coûteux, déterministe, et auditable. Il n'y a aucune raison de ne pas l'exécuter : cela ne coûte rien, et lorsqu'elle fonctionne bien, elle fournit un signal fort au LLM à la phase 3.

Les embeddings fonctionnent en parallèle comme un second signal optionnel. Utile lorsque des incohérences de vocabulaire sont attendues (la question dit « prime », le document dit « montant annuel »), ou lorsque la question est conceptuelle plutôt que lexicale. Si vous avez pré-calculé les embeddings, le coût marginal est de quelques microsecondes au moment de la requête. Sinon, vous pouvez complètement ignorer les embeddings sur les questions où le signal des mots-clés est déjà clair.

Le LLM à la fin voit tout : résultats des mots-clés, résultats des embeddings, l'unité structurelle à laquelle chaque candidat appartient. Il classe les unités une fois, avec des raisons. Deux conséquences de conception de placer le LLM à la fin plutôt qu'en milieu de pipeline :

• Le LLM effectue le raisonnement sur la TOC implicitement. Si on demande « que se passe-t-il si nous sortons tôt ? » par rapport à un document dont la TOC contient « Terminaison » et « Pénalités » (et pas de section « Sortie »), le LLM choisit les deux au moment du classement. Il n'y a pas d'étape LLM de « raisonnement TOC » séparée plus tôt dans le pipeline ; l'arbitre effectue ce travail dans le cadre de son appel unique.

• Le LLM résout les correspondances subtiles de titres. Si la question porte sur « la prime » mais que la section pertinente est intitulée « Résumé du contrat », aucun mot-clé ne correspondra au titre. Le LLM, étant donné les résultats des mots-clés dans les lignes du corps + l'attachement structurel à cette section, la choisira néanmoins.

Filtrage sur toc_df

Deux détecteurs fonctionnent sur la TOC : correspondance de mots-clés (toujours, gratuite) et correspondance d'embeddings (optionnelle, parallèle). Les deux sont des scores purs, sans LLM à ce stade. Le travail cognitif (choisir les bonnes sections à partir d'une question comme « que se passe-t-il si nous sortons tôt ? » lorsque la section pertinente est intitulée « Terminaison ») se fait plus tard, dans l'appel de l'arbitre. L'arbitre voit la TOC et les résultats des mots-clés / embeddings dans un seul appel LLM.

Nous montrons ci-dessous une fonction reason_on_toc autonome comme une parenthèse pédagogique : elle isole ce que fait l'arbitre en interne lorsqu'il raisonne sur la TOC. En production, vous pouvez soit l'exécuter comme un appel séparé (coût LLM supplémentaire, utile pour le débogage), soit l'incorporer dans l'arbitre (un appel LLM total, la préférence par défaut).

Ce sur quoi l'arbitre raisonne

Le toc_df est suffisamment petit pour être transmis dans son intégralité à un LLM. L'arbitre (développé dans l'article 7C, l'arbitre LLM) exploite cela : il lit toute la TOC et raisonne sur les sections qui répondent à la question. La fonction reason_on_toc autonome ci-dessous isole la même logique en tant qu'appel séparé, utile lorsque vous souhaitez inspecter ou déboguer l'étape de raisonnement sur la TOC par elle-même.

Pourquoi cela est important. Le LLM comprend la sémantique, mais plus important encore, il comprend les implications. « Que se passe-t-il si nous sortons tôt ? » ne partage pas de vocabulaire avec « Terminaison », mais le LLM identifie que sortir d'un contrat signifie ce que la terminaison implique. « Comment l'assureur gère-t-il une inondation ? » ne partage pas de vocabulaire avec « Procédure de réclamation », mais le LLM identifie que gérer les dommages est le processus de réclamation. « Y a-t-il des frais pour modifier la couverture ? » peut correspondre à la fois à « Modification de la couverture » et à « Barème des frais », et le LLM choisit les deux, avec un raisonnement qui explique pourquoi. Un cas subtil en production : une question sur « la prime » atterrit sur une section intitulée « Résumé du contrat ». Aucun mot-clé ne correspond, mais le LLM, étant donné les lignes du corps qui mentionnent les montants de prime attachés à cette section, la choisira néanmoins.

Un modèle d'embedding capture « sortir tôt ≈ terminaison » par la similarité, mais il ne peut pas capturer « sortir tôt implique des pénalités ». C'est du raisonnement, pas de la similarité.

Le coût est un appel LLM de niveau intermédiaire (quelques milliers de tokens pour une TOC typique), quelques centaines de millisecondes de latence. Lorsqu'il est intégré dans l'arbitre, cela ne coûte rien de plus : l'arbitre verrait de toute façon la TOC. La méthode est irréalisable sur line_df : transmettre 12 000 lignes de contenu à un LLM et lui demander de « choisir les pertinentes » est trop coûteux, trop lent, trop peu fiable. La petite taille de la TOC est ce qui débloque cette méthode.