Après quatre mois passés à faire passer un pipeline de génération augmentée par récupération (RAG) d'un notebook Jupyter à un service en production, l'auteur a identifié cinq choix concrets qui ont transformé une simple démo impressionnante en un système sur lequel les utilisateurs peuvent réellement compter. La différence se voit dans les chiffres : un simple changement dans la méthode de découpage du texte a fait passer le taux de réussite de la récupération de 61 % à 83 %, et un modeste jeu d'évaluation de 200 requêtes réelles permet désormais de détecter la plupart des régressions avant qu'elles n'atteignent les clients.

Pourquoi c'est important

Les démos RAG sont impressionnantes : elles extraient un passage et produisent une réponse plausible en quelques secondes. En production, la même approche renvoie souvent des faits obsolètes, des codes d'erreur manqués ou des phrases incorrectes, ce qui érode la confiance des utilisateurs. Le goulot d'étranglement est rarement le modèle de langage ; c'est la manière dont le contenu est ingéré, indexé et servi. Réussir son pipeline peut faire la différence entre un produit qui apporte de la valeur et un produit qui devient un fardeau.

1. Arrêtez d'utiliser des blocs de taille fixe

De nombreux prototypes découpent chaque document en blocs de 512 tokens. Cela fonctionne pour les textes courts, mais cela déchiquette les manuels techniques, les fils de discussion de support et les extraits de code. Les phrases sont coupées, les titres disparaissent et le moteur de recherche ne parvient pas à faire correspondre le contexte attendu par l'utilisateur.

Passez à un découpage sensible à la structure (structure-aware chunking) — en coupant aux titres, aux limites de conversation ou aux blocs de code — pour préserver les unités sémantiques. Dans le système de l'auteur, ce seul changement a fait passer la fraction de requêtes trouvant un passage pertinent de 61 % à 83 %. L'amélioration provient d'un changement de format de données ; le modèle sous-jacent reste le même.

2. Utilisez la recherche hybride

La recherche vectorielle pure (basée sur la similarité des embeddings) excelle pour trouver des passages ayant le même sens, mais elle trébuche sur les identifiants exacts comme les codes d'erreur, les numéros de version ou la terminologie propriétaire. Un utilisateur cherchant un code d'erreur tel que « ERR-XXXX » peut obtenir un paragraphe sémantiquement similaire qui ne contient pas du tout le code.

La recherche hybride combine un index vectoriel dense avec un index BM25 traditionnel (basé sur la fréquence des termes). En pondérant les deux scores, le système récupère des éléments qui sont à la fois sémantiquement proches et qui contiennent les termes exacts saisis par l'utilisateur. Pour la production, la recherche hybride est une exigence de base, pas une option facultative.

3. Gérez les données obsolètes

Des tableaux de prix, des documents de politique ou des notes de mise à jour de firmware périmés détruisent rapidement la crédibilité. Trois étapes pratiques permettent de maintenir l'index à jour :

  • Marquez chaque document avec un numéro de version ou un horodatage.
  • Appliquez un boost de récence lors du scoring pour que les éléments les plus récents soient mieux classés que les anciennes copies.
  • Exécutez une réindexation incrémentielle chaque nuit pour intégrer les changements provenant des systèmes sources.

Ces garde-fous empêchent le système de servir un prix qui était valide le trimestre dernier ou une politique qui a déjà été remplacée.

4. Réordonnez (rerank) plutôt que de mettre à niveau les modèles

La mise à niveau d'un modèle d'embedding n'apporte qu'une légère amélioration de la qualité, tandis que l'ajout d'un réordonnanceur (reranker) de type cross-encoder offre un bond bien plus important pour un coût moindre.

Le flux de production récupère 20 candidats peu coûteux via la recherche hybride, puis les passe par le reranker pour sélectionner les cinq meilleurs. Cette approche en deux étapes offre un gain de qualité bien plus élevé pour une fraction du coût d'une mise à niveau complète du modèle.

5. Construisez un véritable jeu d'évaluation

On ne peut pas améliorer ce que l'on ne mesure pas. L'auteur a assemblé une suite de tests de 200 requêtes d'utilisateurs authentiques, chacune associée à une réponse élaborée par un expert. Chaque modification de code est testée par rapport à cette suite ; toute régression est détectée avant le déploiement.

Lorsqu'un utilisateur signale une mauvaise réponse, ajoutez immédiatement la requête au jeu d'évaluation, transformant ainsi les échecs du monde réel en futurs garde-fous. La journalisation continue de chaque réponse générée alimente la boucle d'évaluation, maintenant le système aligné sur l'usage réel.

Le pipeline de production en pratique

  • Ingestion : Le découpage sensible à la structure préserve les titres, les blocs de code et les tours de conversation.
  • Indexation : Stockage à la fois des embeddings denses et des statistiques de termes BM25.
  • Récupération : La recherche hybride renvoie 20 candidats, équilibrant la similarité sémantique et la correspondance exacte des termes.
  • Réordonnancement (Rerank) : Un cross-encoder réduit la liste aux cinq passages les plus prometteurs.
  • Génération : Le LLM reçoit ces meilleurs morceaux ainsi que leurs métadonnées pour rédiger la réponse finale.
  • Évaluation : Chaque réponse est journalisée ; les échecs sont réinjectés dans le jeu de test de 200 requêtes.

Enjeux et compromis

Un pipeline bien optimisé réduit les hallucinations, améliore la pertinence des réponses et diminue le coût des modèles surdimensionnés. L'avantage réside dans une satisfaction utilisateur accrue et une charge de support réduite. Ignorer ces étapes produit un service fragile qui érode la confiance envers la marque et impose une gestion de crises coûteuse.

À surveiller ensuite

À mesure que les embeddings open-source et les bases de données vectorielles gagnent en maturité, la frontière entre la recherche « dense » et « sparse » s'estompera, mais le principe consistant à combiner la correspondance sémantique et exacte demeure.

À retenir : Dans un système RAG, le modèle de langage est rarement le goulot d'étranglement. Le véritable travail réside dans la manière dont vous découpez, indexez et exposez le contenu sous-jacent. Prendre les bonnes décisions à ce niveau transforme une démo impressionnante en un produit fiable.