Ce que nous avons appris en construisant des systèmes RAG en production pour des clients d'entreprise

Une démonstration RAG est simple : vectoriser quelques documents, récupérer les meilleures correspondances, les insérer dans un prompt. Le RAG en production est une discipline entièrement différente, et la plupart des problèmes difficiles se situent en dehors du modèle.

La stratégie de découpage compte plus que le choix du modèle. Des documents mal découpés, coupés en plein milieu d'une phrase, sans titres, sans métadonnées, produisent des réponses erronées mais formulées avec assurance, quel que soit le LLM utilisé en aval. Nous consacrons une part disproportionnée du début de chaque collaboration à la structure des documents et aux métadonnées, avant même de toucher au pipeline de récupération.

L'évaluation doit être mise en place avant la mise en production de la fonctionnalité, pas après que les utilisateurs se plaignent. Nous constituons, dès le début de chaque projet, un petit jeu d'évaluation annoté à partir de requêtes réelles, et le relançons à chaque modification du prompt ou de la récupération, afin que les régressions soient détectées avant qu'un client ne les découvre.

La recherche par similarité vectorielle pure échoue sur les requêtes qui dépendent d'un terme exact, d'un code produit ou d'un nom auquel le modèle d'embedding n'accorde pas beaucoup de poids. La recherche hybride, qui combine similarité vectorielle et correspondance par mots-clés/BM25 puis reclasse les résultats fusionnés, surpasse systématiquement chacune des deux approches prise isolément dès que l'ensemble de documents est important ou que les requêtes deviennent spécifiques. Elle coûte plus cher à construire et à ajuster, et cela en vaut la peine pour tout ce qui dépasse une petite base de connaissances homogène.

Le filtrage par métadonnées est ce qui rend la récupération fiable à grande échelle, pas seulement précise. Étiqueter les segments avec la source, la date, le niveau d'accès et le type de document permet de restreindre la récupération avant même que la recherche par similarité ne s'exécute, ce qui importe autant pour la qualité des réponses (ne pas récupérer un document de politique obsolète) que pour le contrôle d'accès (ne pas récupérer un document que cet utilisateur ne devrait pas voir, quelle que soit sa pertinence par rapport à la requête).

Les garde-fous et les signaux de confiance comptent autant que la précision. Un système qui dit « je ne suis pas sûr, voici une personne à contacter » surpasse un système qui répond avec assurance et se trompe, en particulier dans les cas d'usage liés au support et à la conformité, où une mauvaise réponse coûte plus cher qu'une réponse lente.

L'observabilité doit être intégrée dès le premier jour, pas ajoutée quand quelque chose casse. Nous journalisons les segments récupérés avec la réponse générée pour chaque requête en production, pas seulement le résultat final, car lorsqu'une réponse est fausse, la cause se situe presque toujours dans la récupération, et on ne peut pas déboguer ce qu'on n'a pas capturé.

Le coût et la latence sont des décisions produit, pas des considérations d'infrastructure secondaires. Quel modèle traite quelle requête, quand mettre en cache, et quand un modèle plus petit suffit, sont des décisions que nous prenons explicitement, car elles modifient l'économie unitaire de la fonctionnalité.