RAG : comment ça marche, et quand ça ne suffit pas | Rakam AI

Nouveau : la roadmap IA sur 12 mois d'un éditeur de logiciel, phase par phase. Lire l'article

RAG

Le RAG, et les cinq endroits où il casse en production

La génération augmentée par la recherche est devenue la brique par défaut de tout projet IA d'entreprise. Elle est aussi la plus mal calibrée : un prototype se monte en trois jours, une version qui tient en production demande de traiter cinq problèmes que le prototype cache.

Ce que le RAG résout vraiment

Un modèle de langage ne connaît pas votre entreprise. Il ne connaît pas vos références produit, vos procédures internes, l’historique du dossier que votre utilisateur a ouvert. La génération augmentée par la recherche, ou RAG, traite exactement ce manque : au moment de la question, on va chercher les éléments pertinents dans vos données, on les place dans le contexte du modèle, et on lui demande de répondre à partir de ces éléments plutôt qu’à partir de ce qu’il a mémorisé.

L’intérêt n’est pas seulement la justesse. C’est la traçabilité : une réponse construite à partir de segments identifiés peut citer ses sources, donc être vérifiée. Une réponse mémorisée par le modèle ne peut pas.

Le pipeline, étape par étape

  1. L’ingestion. Vos documents entrent : PDF, pages de documentation, tickets de support, enregistrements de base. Chacun est nettoyé et normalisé.
  2. Le découpage. Chaque document est coupé en segments. C’est l’étape la plus sous-estimée du pipeline, et nous y revenons plus bas.
  3. La vectorisation. Chaque segment est transformé en vecteur par un modèle d’embedding, puis stocké avec ses métadonnées : source, date, droits d’accès.
  4. La recherche. À la question, on récupère les segments les plus proches. Une recherche sérieuse combine la similarité vectorielle et la recherche par mots-clés, parce que les deux échouent sur des cas différents.
  5. Le reclassement. Les segments récupérés sont réordonnés par un modèle plus fin, qui juge la pertinence réelle plutôt que la proximité vectorielle.
  6. La génération. Le modèle rédige la réponse à partir des segments retenus, en citant lesquels.

Les cinq endroits où ça casse

1. Le découpage ne respecte pas la structure du document

C’est la cause numéro un des réponses incomplètes. Couper tous les 500 caractères sépare un titre de tableau de ses lignes, une condition de son exception, un article de son alinéa. Le segment récupéré est alors syntaxiquement propre et sémantiquement inutilisable.

Ce qui marche : découper selon la structure, par section, par article, par entrée de tableau, et conserver dans chaque segment le chemin hiérarchique qui le situe. Un segment doit être compréhensible seul, sans le reste du document.

2. La recherche est purement vectorielle

La similarité vectorielle est excellente sur le sens et mauvaise sur les identifiants. Un utilisateur qui cherche la référence XRP-4021 ou le nom d’un client n’obtient rien de fiable d’une recherche vectorielle seule, parce que ces chaînes n’ont pas de voisinage sémantique.

Une recherche hybride, vectorielle plus lexicale, avec fusion des deux classements, corrige ce trou pour un coût d’ingénierie faible. C’est presque toujours le premier réglage qui fait gagner le plus.

3. Il n’y a pas de jeu d’évaluation

Sans jeu d’évaluation, toute modification du pipeline est un pari. On change le modèle d’embedding, la réponse d’une démonstration s’améliore, et personne ne sait ce qui s’est dégradé ailleurs.

Un jeu d’évaluation utile n’a pas besoin d’être grand : cinquante à deux cents questions réelles, avec la réponse attendue et le document qui la contient. Les questions doivent venir de vos utilisateurs, pas d’une session de rédaction interne, les vraies questions sont mal formulées, ambiguës, et c’est précisément ce qu’il faut mesurer.

C’est pour cette raison que nous construisons l’évaluation avant d’écrire du code de production. On mesure ce que veut dire réussir, pour pouvoir le prouver ensuite.

4. Les droits d’accès sont appliqués après la recherche

Erreur de conception fréquente et grave. Si le filtrage par droits se fait sur la réponse plutôt que sur les segments récupérés, le modèle a déjà lu des documents que l’utilisateur n’a pas le droit de voir, et il peut en restituer le contenu par paraphrase.

Le filtrage doit être dans la requête de recherche, sur les métadonnées de droits attachées à chaque segment à l’ingestion.

5. Le système répond toujours

Un RAG mal calibré n’a pas de porte de sortie : quelle que soit la question, il produit une réponse. Sur les questions couvertes par vos documents c’est correct. Sur les autres, il fabrique quelque chose de plausible, et cette réponse-là est plus coûteuse que l’absence de réponse, parce que l’utilisateur n’a aucun moyen de la distinguer d’une bonne.

Ce qu’un système utilisable fait à la place : dire qu’il ne sait pas, montrer ce qu’il a trouvé de plus proche, et escalader vers un humain au-delà d’un seuil réglé par usage. Sur les actions à impact fiscal ou juridique, ce seuil descend à zéro : validation humaine systématique.

Quand le RAG ne suffit plus

Le RAG répond à des questions dont la réponse existe quelque part dans un document. Il ne répond pas aux questions dont la réponse doit être calculée, ni à celles qui exigent de suivre une chaîne de relations.

« Quelle est la procédure de retour d’un article défectueux ? » est une question de RAG. « Pourquoi cette facture est-elle bloquée, et qu’est-ce qui la débloquerait ? » n’en est pas une : il faut lire l’état du dossier, remonter à la commande, vérifier la réception, comparer au bon de commande. Aucun paragraphe ne contient cette réponse.

C’est là que la recherche seule s’arrête et que deux autres briques prennent le relais :

  • Le graphe métier, qui décrit les entités, leurs relations et les états dans lesquels un dossier peut se trouver. La question devient un parcours dans le graphe plutôt qu’une recherche de texte. C’est le sujet de nos travaux de recherche sur le Graph-RAG.
  • L’agent, qui appelle des outils : interroger votre API, exécuter une requête, créer une écriture. Un agent IA ne cherche pas seulement, il agit, et c’est un problème de conception différent, avec des enjeux de sécurité différents.

Ce que nous en faisons chez nos clients

Nous déployons ces systèmes sur des logiciels métier existants, via leurs API, sans migration. Le RAG y est une brique parmi quatre : la connaissance métier minée dans le logiciel, la configuration propre au client, les procédures non écrites, et les habitudes de chaque utilisateur. Le détail est sur la page du système.

Le SDK que nous utilisons pour l’ingestion, la recherche et l’évaluation est publié en source ouverte sous le nom rakam_systems.

Questions fréquentes

Ce ne sont pas des alternatives, elles répondent à des problèmes différents. Le RAG résout un problème de connaissance : le modèle ignore vos données, on les lui apporte au moment de la question. Le fine-tuning résout un problème de comportement : le modèle répond dans un format, un ton ou une structure que vous voulez imposer. Un besoin de connaissance à jour se traite en RAG, parce que réentraîner à chaque changement de documentation est intenable. Un besoin de format strict se traite en fine-tuning ou en sortie structurée. Beaucoup de systèmes sérieux font les deux.

Un prototype démontrable se monte en quelques jours. Une version en production, avec évaluation, traçabilité des sources, gestion des mises à jour et surveillance de la qualité, se compte en semaines. L'écart entre les deux n'est pas du code de plus : c'est le jeu d'évaluation, la stratégie de découpage adaptée à vos documents, et la décision sur ce que le système fait quand il ne sait pas.

C'est la question qui décide si un RAG est utilisable. Un système qui répond toujours produit des réponses plausibles et fausses, ce qui coûte plus cher que pas de réponse du tout. Nos systèmes sont configurés pour dire qu'ils ne savent pas, citer ce qu'ils ont trouvé de plus proche, et escalader vers un humain au-delà d'un seuil de confiance réglé par usage.

Pas toujours. En dessous de quelques centaines de milliers de segments, une extension vectorielle sur la base que vous exploitez déjà, PostgreSQL avec pgvector par exemple, suffit largement et vous évite un composant de plus à opérer. Une base dédiée se justifie sur des volumes importants, du filtrage par métadonnées complexe, ou des contraintes de latence serrées.

Cela dépend entièrement de l'architecture, et c'est un choix, pas une fatalité. Nous déployons des systèmes sur votre infrastructure, avec des modèles locaux quand la souveraineté l'exige, y compris en réseau isolé. Quand un modèle distant est utilisé, l'obfuscation des données personnelles se fait avant l'appel.