Six leçons apprises lors de la construction de systèmes RAG en production

Depuis quelques années, RAG est devenu une sorte de signal de crédibilité dans le domaine de l’IA. Si une entreprise veut paraître sérieuse aux yeux des investisseurs, des clients ou même de ses propres dirigeants, elle doit désormais disposer d’une histoire de génération augmentée par récupération. Les LLM ont changé le paysage presque du jour au lendemain et ont intégré l’IA générative dans presque toutes les conversations commerciales.

Mais en pratique : Construire un mauvais système RAG est pire que pas de RAG du tout.

J’ai vu ce schéma se répéter encore et encore. Quelque chose est expédié rapidement, la démo semble correcte, la direction est satisfaite. Les vrais utilisateurs commencent alors à poser de vraies questions. Les réponses sont vagues. Parfois faux. Parfois confiant et complètement absurde. C’est généralement la fin. La confiance disparaît rapidement, et une fois que les utilisateurs décident qu’un système n’est pas digne de confiance, ils ne vérifient plus s’il s’est amélioré et ne lui donneront pas une seconde chance. Ils arrêtent simplement de l’utiliser.

Dans ce cas, le véritable échec n’est pas technique mais humain. Les gens toléreront des outils lents et des interfaces encombrantes. Ce qu’ils ne toléreront pas, c’est d’être induits en erreur. Lorsqu’un système vous donne la mauvaise réponse avec confiance, cela semble trompeur. S’en remettre, même après des mois de travail, est extrêmement difficile.

Seules quelques réponses incorrectes suffisent à renvoyer les utilisateurs vers des recherches manuelles. Au moment où le système devient enfin vraiment fiable, le mal est déjà fait et personne ne veut plus l’utiliser.

Dans cet article, je partage six leçons que j’aurais aimé connaître avant de déployer des projets RAG pour les clients.

1. Commencez par un vrai problème commercial

Les décisions importantes du RAG se produisent bien avant que vous écriviez un code.

• Pourquoi vous lancez-vous dans ce projet ? Il faut vraiment identifier le problème à résoudre. Le faire « parce que tout le monde le fait » n’est pas une stratégie.

• Reste ensuite la question du retour sur investissement, celle que tout le monde évite. Combien de temps cela permettra-t-il réellement d’économiser dans les flux de travail concrets, et pas seulement sur la base de mesures abstraites présentées dans des diapositives ?

• Et enfin, le cas d’utilisation. C’est là que la plupart des projets RAG échouent discrètement. « Répondre aux questions internes » n’est pas un cas d’utilisation. Est-ce que cela aide les RH à répondre aux questions politiques sans allers-retours interminables ? Cela donne-t-il aux développeurs un accès instantané et précis à la documentation interne pendant qu’ils codent ? S’agit-il d’un assistant d’intégration à portée limitée pour les 30 premiers jours d’une nouvelle embauche ? Un système RAG solide fait bien une chose.

RAG peut être puissant. Cela peut permettre de gagner du temps, de réduire les frictions et d’améliorer véritablement le fonctionnement des équipes. Mais seulement s’il est traité comme une véritable infrastructure et non comme une expérience de tendance.

La règle est simple : ne suivez pas les tendances. Mettre en œuvre de la valeur.

Si cette valeur ne peut pas être clairement mesurée en termes de gain de temps, d’efficacité ou de réduction des coûts, alors le projet ne devrait probablement pas exister du tout.

2. La préparation des données prendra plus de temps que prévu

De nombreuses équipes précipitent le développement de leur RAG et, pour être honnête, un simple MVP peut être atteint très rapidement si l’on ne se concentre pas sur les performances. Mais RAG n’est pas un prototype rapide ; c’est un énorme projet d’infrastructure. Dès que vous commencerez à stresser votre système avec des données réelles et évolutives en production, les faiblesses de votre pipeline commenceront à faire surface.

Compte tenu de la popularité récente des LLM avec de grandes fenêtres contextuelles, parfois mesurées en millions, certains déclarent que les modèles à contexte long rendent la récupération facultative et que les équipes tentent simplement de contourner l’étape de récupération. Mais d’après ce que j’ai vu, en implémentant cette architecture à plusieurs reprises, les grandes fenêtres contextuelles dans les LLM sont très utiles, mais elles ne remplacent pas une bonne solution RAG. Lorsque vous comparez la complexité, la latence et le coût du passage d’une fenêtre de contexte massive à la récupération uniquement des extraits de code les plus pertinents, un système RAG bien conçu reste nécessaire.

Mais qu’est-ce qui définit un « bon » système de récupération ? Vos données et leur qualité, bien sûr. Le principe classique « Garbage In, Garbage Out » s’applique ici tout autant que dans l’apprentissage automatique traditionnel. Si vos données sources ne sont pas méticuleusement préparées, l’ensemble de votre système connaîtra des difficultés. Peu importe le LLM que vous utilisez ; la qualité de votre récupération est l’élément le plus critique.

Trop souvent, les équipes envoient des données brutes directement dans leur base de données vectorielle (VectorDB). Cela devient rapidement un bac à sable où le seul mécanisme de récupération est une application basée sur la similarité cosinus. Même s’il réussit vos tests internes rapides, il échouera presque certainement sous la pression du monde réel.

Dans les systèmes RAG matures, la préparation des données dispose de son propre pipeline avec des tests et des étapes de versioning. Cela signifie nettoyer et prétraiter votre corpus d’entrée. Aucune fragmentation intelligente ou architecture sophistiquée ne peut corriger des données fondamentalement mauvaises.

3. Un chunking efficace consiste à garder les idées intactes

Lorsque nous parlons de préparation de données, nous ne parlons pas seulement de données propres ; nous parlons d’un contexte significatif. Cela nous amène au découpage.

Le découpage consiste à décomposer un document source, peut-être un PDF ou un document interne, en morceaux plus petits avant de l’encoder sous forme vectorielle et de le stocker dans une base de données.

Pourquoi Un découpage est-il nécessaire ? Les LLM ont un nombre limité de jetons, et même les « LLM à contexte long » deviennent coûteux et souffrent de distraction avec trop de bruit. L’essence du chunking est de sélectionner l’information la plus pertinente qui répondra à la question de l’utilisateur et de transmettre uniquement cette information au LLM.

La plupart des équipes de développement divisent les documents en utilisant des techniques simples : limites de jetons, nombre de caractères ou paragraphes approximatifs. Ces méthodes sont très rapides, mais c’est généralement à ce moment-là que la récupération commence à se dégrader.

Lorsque nous fragmentons un texte sans règles intelligentes, il devient des fragments plutôt que des concepts entiers. Le résultat est des pièces qui se séparent lentement et deviennent peu fiables. Copier une stratégie de segmentation naïve à partir de l’architecture publiée par une autre entreprise, sans comprendre votre propre structure de données, est dangereux.

Les meilleurs systèmes RAG que j’ai vus intègrent le Semantic Chunking.

En pratique, le Semantic Chunking consiste à diviser le texte en morceaux significatifs, et pas seulement en tailles aléatoires. L’idée est de garder chaque pièce concentrée sur une pensée complète. L’objectif est de s’assurer que chaque morceau représente une seule idée complète.

• Comment l’implémenter : Vous pouvez implémenter cela en utilisant des techniques telles que : Fractionnement récursif : briser le texte en fonction de délimiteurs structurels (par exemple, sections, en-têtes, puis paragraphes, puis phrases).
• Transformateurs de phrases : cela utilise un modèle léger et compact pour identifier toutes les transitions importantes en fonction de règles sémantiques afin de segmenter le texte à ces points.

Pour mettre en œuvre des techniques plus robustes, vous pouvez consulter des bibliothèques open source telles que les différents modules de segmentation de texte de LangChain (notamment leurs modules récursifs avancés) et des articles de recherche sur la segmentation thématique.

4. Vos données deviendront obsolètes

La liste des problèmes ne s’arrête pas là une fois lancé. Que se passe-t-il lorsque vos données sources évoluent ? Les intégrations obsolètes tuent lentement les systèmes RAG au fil du temps.

C’est ce qui se produit lorsque les connaissances sous-jacentes à votre corpus documentaire changent (nouvelles politiques, faits mis à jour, documentation restructurée) mais que les vecteurs de votre base de données ne sont jamais mis à jour.

Si vos intégrations sont faibles, votre modèle hallucinera essentiellement à partir d’un enregistrement historique plutôt que de faits actuels.

Pourquoi la mise à jour d’un VectorDB est-elle techniquement difficile ? Les bases de données vectorielles sont très différentes des bases de données SQL traditionnelles. Chaque fois que vous mettez à jour un seul document, vous ne modifiez pas simplement quelques champs, mais vous devrez peut-être restructurer l’ensemble du document, générer de nouveaux grands vecteurs, puis remplacer ou supprimer entièrement les anciens. Il s’agit d’une opération gourmande en calculs, très chronophage, et qui peut facilement conduire à une situation de temps d’arrêt ou d’incohérences si elle n’est pas traitée avec soin. Les équipes ignorent souvent cela car l’effort d’ingénierie n’est pas trivial.

Quand faut-il réintégrer le corpus ? Il n’y a pas de règle générale ; les tests sont votre seul guide pendant cette phase POC. N’attendez pas un nombre précis de modifications dans vos données ; la meilleure approche consiste à réintégrer automatiquement votre système, par exemple après une version majeure de vos règles internes (si vous construisez un système RH). Vous devez également réintégrer si le domaine lui-même change de manière significative (par exemple, en cas de changement réglementaire majeur).

L’intégration du versioning, ou le suivi des documents associés à quelle exécution pour générer un vecteur, est une bonne pratique. Cet espace a besoin d’idées innovantes ; la migration dans VectorDB est souvent une étape manquée par de nombreuses équipes.

5. Sans évaluation, les échecs n’apparaissent que lorsque les utilisateurs se plaignent

L’évaluation RAG consiste à mesurer les performances réelles de votre application RAG. L’idée est de vérifier si votre assistant de connaissances alimenté par RAG donne des réponses précises, utiles et fondées. Ou, plus simplement : est-ce que cela fonctionne réellement pour votre cas d’utilisation réel ?
L’évaluation d’un système RAG est différente de l’évaluation d’un LLM classique. Votre système doit exécuter des requêtes réelles que vous ne pouvez pas entièrement anticiper. Ce que vous voulez comprendre, c’est si le système extrait les bonnes informations et répond correctement.
Un système RAG est composé de plusieurs composants, depuis la façon dont vous fragmentez et stockez vos documents jusqu’à l’intégration, la récupération, le format d’invite et la version LLM.
Pour cette raison, l’évaluation RAG devrait également être multi-niveaux. Les meilleures évaluations incluent des métriques pour chaque partie du système séparément, ainsi que des métriques commerciales pour évaluer les performances de l’ensemble du système de bout en bout.

Bien que cette évaluation commence généralement pendant le développement, vous en aurez besoin à chaque étape du cycle de vie du produit IA.

Une évaluation rigoureuse transforme RAG d’une preuve de concept en un projet technique mesurable.

6. Les architectures tendances correspondent rarement à votre problème

Les décisions d’architecture sont fréquemment importées à partir d’articles de blog ou de conférences sans jamais se demander si elles correspondent aux exigences spécifiques internes.

Pour ceux qui ne sont pas familiers avec RAG, de nombreuses architectures RAG existent, allant d’un simple système RAG monolithique à des flux de travail agents complexes.

Vous n’avez pas besoin d’un RAG Agentic compliqué pour que votre système fonctionne correctement. En fait, la plupart des problèmes commerciaux sont mieux résolus avec une architecture RAG de base ou RAG en deux étapes. Je sais que les mots « agent » et « agent » sont populaires en ce moment, mais veuillez donner la priorité à la valeur mise en œuvre plutôt qu’aux tendances mises en œuvre.

• RAG monolithique (de base) : Commencez ici. Si les requêtes de vos utilisateurs sont simples et répétitives (« Quelle est la politique de vacances ? »), un simple pipeline RAG qui récupère et génère est tout ce dont vous avez besoin.
• Réécriture de requêtes en deux étapes : Utilisez-le lorsque la saisie de l’utilisateur peut être indirecte ou ambiguë. La première étape LLM réécrit la saisie ambiguë de l’utilisateur dans une requête de recherche plus propre et meilleure pour VectorDB.
• RAG agent : N’envisagez cela que lorsque le cas d’utilisation nécessite un raisonnement complexe, l’exécution d’un flux de travail ou l’utilisation d’un outil (par exemple, « Trouvez la politique, résumez-la, puis rédigez un e-mail aux RH pour demander des éclaircissements »).

Les systèmes RAG constituent une architecture fascinante qui a récemment gagné en popularité. Alors que certains prétendent que « RAG est mort », je pense que ce scepticisme est tout simplement un élément naturel d’une époque où la technologie évolue incroyablement rapidement.

Si votre cas d’utilisation est clair et que vous souhaitez résoudre un problème spécifique impliquant de grands volumes de données documentaires, RAG reste une architecture très efficace. La clé est de rester simple et d’intégrer l’utilisateur dès le début.

N’oubliez pas que la création d’un système RAG est une entreprise complexe qui nécessite un mélange de compétences en apprentissage automatique, en MLOps, en déploiement et en infrastructure. Vous devez absolument vous lancer dans cette aventure avec la participation de tous, des développeurs aux utilisateurs finaux, dès le premier jour.

🤝 Restez connecté

Si vous avez apprécié cet article, n’hésitez pas à me suivre sur LinkedIn pour des informations plus honnêtes sur l’IA, la science des données et les carrières.

👉 LinkedIn : Sabrine Bendimerad

👉 Moyen: https://medium.com/@sabrine.bendimerad1

👉 Instagram: https://tinyurl.com/datailearn