Le développeur RAG : rendre les réponses d'un modèle fiables et sourcées

Pourquoi on ajoute une recherche au modèle

Un modèle de langage contient une connaissance figée à sa date d'entraînement et généraliste. Interrogé sur un document interne, une réglementation récente ou un catalogue de produits, il ne peut pas répondre de façon fiable : il produit une réponse plausible sans fondement. La génération augmentée par recherche corrige ce défaut en insérant, au moment de la requête, des passages pertinents tirés d'une source de confiance. Le modèle ne puise plus dans sa mémoire : il résume, explique ou cite des éléments qu'on lui a fournis. La qualité du résultat dépend alors moins du modèle que de la pertinence de ce qu'on lui donne à lire.

L'autre apport est la traçabilité. Un assistant qui répond en s'appuyant sur des documents identifiables peut citer ses sources, ce qui change la nature de la confiance. On peut vérifier, corriger la base, retirer un document obsolète. Cette possibilité compte pour les usages professionnels, où une réponse fausse engage une décision. Le RAG réduit aussi le besoin de réentraîner un modèle pour lui apprendre des contenus nouveaux, opération coûteuse et rarement justifiée. Actualiser une base documentaire est plus rapide que réentraîner un modèle. C'est cette souplesse qui a rendu l'approche dominante dans les applications d'entreprise.

La chaîne de traitement, de l'ingestion à la réponse

Un système RAG est une succession d'étapes, chacune capable de ruiner la suivante. Les documents sont d'abord collectés et nettoyés, car un texte mal extrait, tableaux disloqués ou en-têtes parasites, pollue tout ce qui suit. On les découpe ensuite en fragments cohérents : trop grands, ils diluent l'information ; trop petits, ils perdent le contexte. Chaque fragment est transformé en vecteur, une représentation numérique qui permet de retrouver les passages proches d'une question. Ces vecteurs sont rangés dans une base spécialisée. À l'interrogation, on retrouve les fragments les plus proches, on les ordonne, puis on les confie au modèle avec la question.

Chaque étape recèle des décisions techniques aux conséquences visibles. Le choix du modèle d'embedding détermine ce que la recherche distingue. La stratégie de découpage décide si la réponse traverse une frontière ou reste dans un fragment. Le réordonnancement des résultats améliore souvent plus la qualité qu'un changement de modèle. Les requêtes elles-mêmes peuvent être reformulées ou décomposées pour mieux atteindre l'information. Enfin, la recherche peut combiner proximité sémantique et correspondance de mots-clés, car aucune méthode ne capte seule tous les cas. Un bon développeur RAG raisonne sur cette chaîne complète, non sur l'étape la plus visible.

Ce qui distingue un RAG fiable d'un prototype

Un prototype répond correctement sur quelques questions préparées ; un système fiable tient la durée. La différence tient à l'évaluation. Il faut constituer un jeu de questions représentatives, avec les réponses attendues et les sources pertinentes, puis mesurer régulièrement si le système les retrouve et les restitue. Sans cette mesure, on corrige à l'aveugle et l'on croit améliorer sans preuve. L'évaluation doit porter séparément sur la recherche des passages et sur la qualité de la réponse, car une bonne réponse peut venir d'une mauvaise source, ce qui est une chance trompeuse. Ce travail, peu spectaculaire, sépare les équipes qui progressent des autres.

La fiabilité dépend aussi de la capacité à dire « je ne sais pas ». Un assistant utile sait s'arrêter quand aucun passage pertinent n'est trouvé, plutôt que d'improviser. Cela suppose de définir des seuils et de tester les cas limites : question hors sujet, information absente, documents contradictoires. Il faut aussi surveiller ce qui se passe en production, car les questions réelles diffèrent de celles imaginées. La qualité se dégrade silencieusement quand les documents changent ou quand les usages se déplacent. Prévoir des indicateurs de suivi et une révision périodique de la base fait partie du métier autant que le code initial.

Le profil attendu et l'évolution du métier

Le développeur RAG maîtrise d'abord le développement logiciel : Python, API, traitement de données, déploiement. Il comprend ensuite les modèles de langage assez finement pour savoir ce qu'ils font mal : ils suivent les instructions mais peuvent ignorer un passage pertinent, se laisser distraire par du contexte inutile, ou inventer quand l'information manque. Il connaît les bibliothèques et les bases vectorielles, mais sait que l'outil compte moins que la conception de la chaîne. Enfin, il parle aux métiers, car la qualité d'une base documentaire se juge à l'usage réel qu'on en fait.

Ce périmètre évolue vite. Les approches se sophistiquent, les modèles s'améliorent, et une part du travail se déplace vers l'orchestration de plusieurs étapes, la combinaison de la recherche avec des outils, la vérification des réponses. On demande de plus en plus de mesurer la qualité, de documenter les choix, et de tenir compte des contraintes réglementaires. Le règlement européen sur l'intelligence artificielle impose, selon les cas, transparence et traçabilité, ce qui concerne directement un système qui cite ses sources. Le métier se rapproche ainsi de l'ingénierie logicielle sérieuse autant que de l'IA.