Retour d’expérience sur un RAG en production après avoir traité plus de 5 millions de documents

• Pendant 8 mois, un projet de RAG (génération augmentée par la recherche) a permis de distinguer les méthodes réellement efficaces de celles qui faisaient perdre du temps
• Au départ, un prototype a été rapidement finalisé avec Langchain et Llamaindex, mais les retours des utilisateurs ont révélé des limites de performance en conditions réelles
• Les principaux facteurs d’amélioration de la recherche documentaire ont été identifiés comme étant la génération de requêtes, le reranking, la stratégie de chunking, l’exploitation des métadonnées et le routage des requêtes
• En pratique, l’équipe a construit un pipeline sur mesure en choisissant de façon flexible base de données vectorielle, embeddings, reranking, LLM, etc.
• Toute cette expérience et ce savoir-faire ont été regroupés et publiés dans le projet open source (agentset-ai/agentset)

---

Aperçu de 8 mois de construction d’un RAG en production

• Retour d’expérience sur la construction et l’exploitation d’un système RAG sur de grands jeux de données, notamment 9 millions de pages (Usul AI) et 4 millions de pages (une entreprise anonyme d’IA juridique)
• Au début, en suivant des tutoriels YouTube, un prototype a été réalisé en quelques jours en passant de Langchain à Llamaindex, mais au moment du déploiement, des problèmes de performances insuffisantes perceptibles uniquement par les utilisateurs sont apparus
• Après plusieurs mois d’ajustements partiels des composants du système, des performances optimales ont été atteintes

Les éléments qui ont réellement contribué à améliorer les performances (par ordre de ROI)

1. Génération de requêtes (Query Generation)

   • La dernière requête de l’utilisateur ne suffit pas à elle seule à contenir tout le contexte, donc le LLM passe en revue la conversation pour générer plusieurs requêtes sémantiques et requêtes par mots-clés
   • Ces requêtes sont traitées en parallèle puis envoyées à un reranker, ce qui permet d’élargir le périmètre de recherche et de compenser les biais de la recherche hybride

2. Reranking

   • L’impact d’un reranking implémentable en environ 5 lignes de code sur les performances est bien plus important qu’on ne l’imagine
   • Sur un grand volume de chunks en entrée (par exemple 50), le plus fort ROI vient du processus consistant à réordonner et sélectionner une partie des meilleurs chunks (par exemple 15)
   • Le reranking seul peut déjà compenser en grande partie les faiblesses d’un pipeline mal conçu

3. Stratégie de chunking (Chunking Strategy)

   • C’est la partie qui a pris le plus de temps pendant tout le développement
   • Il faut comprendre précisément la structure et les motifs des données, effectuer le chunking selon des unités logiques, et vérifier manuellement que le texte ou les phrases ne sont pas coupés au milieu
   • Chaque chunk doit conserver un sens autonome

4. Exploitation des métadonnées en entrée du LLM

   • Au lieu d’envoyer uniquement le texte brut des chunks au LLM, l’ajout de métadonnées (title, author, etc.) améliore fortement le contexte et la qualité des réponses

5. Routage des requêtes (Query Routing)

   • Pour les types de demandes auxquels le RAG ne peut pas répondre (par exemple résumé d’article, demande d’informations sur l’auteur, etc.), un routeur léger a été introduit afin de diriger ces requêtes vers un chemin de traitement API+LLM

Stack utilisée en pratique (Our stack)

• Base de données vectorielle : Azure → Pinecone → Turbopuffer (peu coûteux et avec prise en charge native de la recherche par mots-clés)
• Extraction de documents : méthode personnalisée
• Outil de chunking : Unstructured.io par défaut, pipeline personnalisé pour l’entreprise (Chonkie a aussi bonne réputation)
• Modèle d’embedding : utilisation de text-embedding-large-3 (autres modèles non testés)
• Reranker : None → Cohere 3.5 → Zerank (peu connu, mais réellement excellent)
• LLM : GPT 4.1 → GPT 5 → GPT 4.1 (principalement avec des crédits Azure)

Open source et conclusion

• Tous les enseignements et l’expérience terrain ont abouti au projet open source agentset-ai/agentset
• Le projet est publié sous licence MIT et peut être utilisé librement ; il est aussi possible de poser des questions (coordonnées fournies)

[GN⁺]

Avis Hacker News

• La partie sur la génération de requêtes synthétiques paraît vraiment importante : en pratique, les utilisateurs saisissent souvent leurs requêtes de manière très imprécise. Au début, c’est le LLM qui génère une requête synthétique, mais comme les résultats varient fortement selon la requête produite à chaque fois, une seule invocation du LLM est désormais utilisée pour générer trois variantes de la requête, qui sont ensuite explorées en parallèle, puis combinées en une liste de résultats robuste via reciprocal rank fusion. Pour la recherche, ils utilisent un hybride dense + sparse BM25 ; le dense seul est faible sur la terminologie spécialisée. En y ajoutant un reranker, la plupart des problèmes liés à la recherche semblent être résolus.
  • Il trouve intéressant de recourir à une approche hybride (BM25 + recherche dense) pour compenser la faiblesse des modèles denses sur les termes techniques. Des modèles v3 comme SPLADE, qui équilibrent bien recherche sémantique et lexicale, semblent aussi très performants, mais il se demande toujours si une solution plus simple pourrait suffire.
  • Il insiste sur le fait que ce niveau de génération/optimisation fine des requêtes est au fond le type de problème dont devraient se charger les fournisseurs de solutions RAG comme Amazon, Microsoft ou OpenAI.
  • Même si ces méthodes sont bien les best practices actuelles, il reste l’impression qu’il manque encore quelque chose parmi les stratégies supplémentaires capables de faire franchir un cap aux performances (sélection conditionnelle des modèles d’embedding, combinaisons variées de re-rankers, etc.).
  • Dernier conseil : montrer à l’utilisateur, en même temps que les résultats, comment le LLM a interprété son intention de recherche, afin qu’il puisse vérifier lui-même si la compréhension du modèle est correcte.
• Il se dit perplexe au sujet de l’option self-hosted : d’après la documentation, il faudrait au minimum six comptes de services tiers, ce qui s’éloigne beaucoup de ce qu’il considère comme du vrai self-hosted.
  • Il est expliqué que le code lui-même peut bien être auto-hébergé. Il estime simplement qu’il n’existe pas de définition officielle claire du terme « self-hosted ». Par exemple, si un service self-hosted propose aussi des sauvegardes hors site, cela reste self-hosted tout en étant simplement bien conçu.
  • Ce type de marketing autour du self-hosted peut sembler naturel ; après tout, le modèle économique de l’éditeur repose sur la vente d’une version hébergée, donc il n’a pas d’obligation à proposer un produit self-hosted complètement autonome.
  • Il partage son expérience de travail en environnement réseau très restreint : depuis vingt ans, il travaille dans des réseaux internes totalement isolés, si bien qu’il a peut-être raté beaucoup de vagues technologiques récentes. Il regarde à peine YouTube en dehors de vidéos de réparation automobile et reste assez réservé vis-à-vis des tendances techniques qui supposent une connexion permanente.
  • Il utilise pour sa part la version open source avec une grande satisfaction ; si l’on ne veut aucune dépendance à un service hébergé, il suffit de tout réécrire soi-même en Rust, dit-il de façon pragmatique.
• Les gros rerankers basés sur des LLM (comme Qwen3-reranker) fournissent enfin le niveau de performance qu’on attendait depuis longtemps des cross-encoders, donc il recommande vraiment de les essayer, même si le coût de calcul est élevé. Il ajoute que les métadonnées et les informations tabulaires sont des éléments de base évidents pour un humain, mais comme ils ne sont pas répétés dans les chunks de texte, les injecter dans l’entrée du LLM le rend nettement plus « intelligent ». En revanche, il faut faire attention aux requêtes complexes mal gérées par un simple RAG (par exemple : résumer les 20 documents les plus récents). C’est pourquoi ils ont orienté l’UI vers la recherche, réduit la dimension chat UX, et fait en sorte que l’utilisateur voie lui aussi exactement les informations que le modèle voit réellement.
  • Il est tout à fait d’accord sur le fait qu’il est très difficile d’amener les utilisateurs à comprendre correctement la manière dont un LLM traite le contexte. Il existe peu d’exemples publics qui s’éloignent de la chat UX, et il doute que si de grandes entreprises ont essayé puis abandonné, ce soit vraiment uniquement « faute de résultats ». En pratique, dans les grandes applications grand public, les coûts de contexte et de raisonnement sont des postes majeurs qu’il faut maîtriser, ce qui a probablement desservi les UI explicites sur le contexte. À l’inverse, pour des systèmes RAG internes, la contrainte de coût est moindre, donc l’accent est bien davantage mis sur la qualité des résultats et le gain de temps pour les employés.
  • Les optimisations techniques comptent, mais il aimerait surtout en savoir plus sur l’amélioration réelle de l’efficacité métier chez les clients ; sinon, ce n’est peut-être qu’une mode technologique de plus.
• Il partage un billet récapitulatif écrit il y a un an et demi sur le traitement RAG de millions de pages, en particulier de documentation technique : https://jakobs.dev/learnings-ingesting-millions-pages-rag-azure/
  • Il avait lui aussi construit l’an dernier un système RAG pour la recherche technique, et a l’impression qu’encore aujourd’hui beaucoup d’éléments restent quasiment identiques.
• Du point de vue de quelqu’un qui veut construire ou adopter ce type de système RAG, il se demande si une architecture pratique consisterait à envoyer les documents via API dans des dossiers Google Workspace puis à les rechercher avec l’API Google AI Search, en les séparant par dossiers différents selon les utilisateurs ; il se demande aussi si quelque chose de similaire pourrait être réalisé sur Azure.
• Il se demande comment gérer le versioning des embeddings : comment faire lorsqu’il faut mettre à jour les données, exposer une version spécifique ou filtrer par date ? Il envisage aussi d’ajouter une version de contexte au début de chaque chunk.
  • Il suffit de stocker le texte source et les métadonnées (y compris les informations de version) dans le vector store. Il cite par exemple turbopuffer, dont le filtrage par attributs est pratique, avec ce lien vers la documentation.
  • Il estime que cette question en elle-même est particulièrement utile et importante.
• Il trouve étrange la succession des versions de LLM utilisées — GPT 4.1 → GPT 5 → retour à GPT 4.1 — ainsi que le décalage avec les versions d’autres composants de la stack (par ex. text-embedding-large-3).
  • Réponse de l’OP : ils ont essayé GPT-5 dès sa sortie, mais sur des entrées avec beaucoup de contexte (jusqu’à 100k tokens), il faisait moins bien que GPT-4.1, d’où le retour à 4.1. Plus précisément : a) il suivait moins bien les instructions et respectait mal le system prompt ; b) ses réponses devenaient trop verbeuses, au détriment marqué de l’UX ; c) la limite de fenêtre de contexte à 125k tokens provoquait des erreurs sur les très gros inputs. Ces problèmes se voyaient particulièrement en « RAG » quand beaucoup de chunks étaient fournis ; pour des tâches plus générales, GPT-5 peut malgré tout être meilleur.
• Sans être un défenseur d’AWS, il affirme que S3 Vectors est actuellement l’état de l’art dans ce domaine. Avec Bedrock Knowledge Base branché dessus, Discovery/Rebalance devient aussi très simple, ce qui en ferait la solution la plus simple du marché ; une fois la version finale lancée, cela pourrait écraser la plupart des concurrents.
  • Il corrige en plaisantant : ce n’est pas « schlep » mais « shill » qu’il fallait dire.
  • Il se demande pourquoi S3 Vectors serait SOTA ; après tout, n’est-ce pas « juste » un vector store ?
• Un RAG fondé sur les embeddings n’est pas forcément la meilleure approche en pratique ; c’est utile pour une tâche unique ou une démo, mais dans le réel, il atteint souvent ses limites.
  • Ce n’est pas forcément vrai, selon d’autres retours d’expérience. Le produit Query Assistant de Honeycomb, sur lequel il a travaillé, reposait lui aussi sur des requêtes de données dès 2023 ; comme cette fonctionnalité avait un objectif simple et clair, cela lui paraît au contraire représenter une direction idéale pour les produits à base de LLM. Le mieux est de le combiner avec des traitements non-LLM.
  • Le RAG continue d’être réinterprété de différentes manières et pour de nombreux usages : ils l’ont intégré comme un outil au sein d’une recherche agentique, tout en le mélangeant avec de la recherche sur sources en temps réel ou l’approche classique par chunks. Avec les grandes fenêtres de contexte qui arrivent, il deviendra bientôt possible d’injecter un document entier dans une seule requête.
  • Il demande quelle alternative serait recommandée exactement : parle-t-on de la manière de générer les requêtes ?
  • Dans le cas de ChatGPT aussi, le RAG est efficace pour récupérer des informations récentes ; cette utilité très concrète explique pourquoi tous les grands fournisseurs le proposent aujourd’hui.
  • Il demande clairement par rapport à quoi la comparaison est faite.
• Puisqu’il a été dit que la sélection des chunks demandait beaucoup de temps et d’efforts, il aimerait entendre plus en détail les stratégies concrètes qui ont été utilisées.