Les équipes qui font passer la génération augmentée par récupération (RAG) d'une démo à un service de production doivent prendre une série de décisions qui séparent un assistant utile d'un assistant bruyant. Cinq choix de conception — le découpage (chunking), le modèle d'embedding, le magasin de vecteurs (vector store), la recherche hybride et l'évaluation — contrôlent la précision, le rappel et la latence que les utilisateurs réels expérimentent.

Pourquoi le passage du prototype à la production est crucial

La plupart des tutoriels permettent de faire fonctionner un pipeline RAG en quelques dizaines de lignes de code, puis s'arrêtent avant d'atteindre la rigueur d'ingénierie nécessaire pour le trafic réel.

1. Stratégie de découpage (chunking) – le premier filtre de qualité

La taille des chunks est primordiale. Des chunks trop volumineux noient le signal sous du texte non pertinent ; des chunks trop petits suppriment le contexte environnant dont le modèle a besoin pour générer des réponses cohérentes. Le découpage par taille fixe ignore la structure naturelle du contenu source.

Règle d'or pratique

  • Découpez selon des limites logiques : en-têtes dans les documents, sauts de paragraphe dans les articles, définitions de fonctions dans le code.
  • Gardez des chunks suffisamment petits pour une récupération précise, tout en conservant la section parente plus large pour l'étape de génération de l'LLM. Ce modèle « parent-enfant » permet au récupérateur de faire remonter un extrait précis tandis que le générateur dispose d'assez de contexte pour rester factuel.

2. Modèles d'embedding – comment la similarité est jugée

Le modèle d'embedding transforme le texte en vecteurs que le moteur de recherche de similarité compare. Un modèle polyvalent performant tel que text-embedding-3-large d'OpenAI offre une base solide pour la plupart des domaines. Si le corpus appartient à un domaine hautement spécialisé — avis juridiques, dossiers médicaux, spécifications techniques — testez un modèle spécifique au domaine, mais seulement après avoir mesuré une amélioration tangible sur vos propres données.

Quand changer

  • Ne changez que si vous constatez un gain mesurable dans les scores de pertinence qui comptent pour votre application (par exemple, une meilleure précision du contexte).

3. Base de données vectorielle – passer à l'échelle du stockage

Choisissez un vector store qui s'adapte à votre infrastructure existante et au nombre de vecteurs attendu.

  • pgvector s'exécute à l'intérieur de PostgreSQL et gère confortablement jusqu'à environ un million de vecteurs. C'est idéal pour les équipes utilisant déjà une base de données relationnelle et ayant besoin d'une solution à faible maintenance.
  • Qdrant excelle dans la plage de 1 M à 100 M, offrant un débit plus élevé et une latence plus faible pour des corpus plus importants.
  • Pinecone fournit un service cloud entièrement managé, éliminant la charge opérationnelle de l'auto-hébergement.

4. Recherche hybride et reranking – équilibrer sens et exactitude

La recherche vectorielle pure excelle dans la similarité sémantique, mais peut manquer les correspondances exactes par mots-clés que les utilisateurs attendent. La recherche hybride superpose un index de mots-clés BM25 traditionnel à l'index vectoriel, puis fusionne les deux listes de résultats. Le Reciprocal Rank Fusion (RRF) attribue à chaque candidat un score basé sur son rang dans les deux listes et les combine, en favorisant les éléments qui apparaissent haut dans l'une ou l'autre.

Le reranking ajoute un dernier filtre de précision. Après la récupération hybride, soumettez les N meilleurs candidats (généralement 50) à un cross-encoder — un modèle qui évalue conjointement une paire requête-document. Les scores du cross-encoder remplacent les chiffres de similarité originaux, vous permettant de choisir le chunk le plus pertinent avant de le transmettre à l'LLM. Cette étape supplémentaire produit souvent un bond notable de la qualité des réponses, en particulier pour les corpus longs ou bruités.

5. Évaluation et abstention – mesurer ce qui compte

Vous ne pouvez pas améliorer un système que vous ne mesurez pas. Le framework RAGAS propose quatre métriques qui, ensemble, capturent la santé d'un pipeline RAG :

  • Context Precision – proportion des chunks récupérés qui contiennent réellement la réponse.
  • Context Recall – part de tous les chunks pertinents qui ont été récupérés.
  • Faithfulness – degré auquel la réponse générée reste dans le contexte récupéré, évitant ainsi les hallucinations.
  • Answer Relevance – mesure dans laquelle la réponse finale satisfait la requête originale.

Suivez ces métriques sur un ensemble de tests glissant qui reflète le trafic de production.

Une dernière protection, souvent négligée, est l'abstention. Au lieu de forcer le modèle à répondre avec un faible niveau de confiance, définissez un seuil sur le score de faithfulness ou de relevance qui déclenche une réponse « Je ne sais pas ». Les utilisateurs préfèrent un aveu clair d'incertitude à une réponse confiante mais erronée, et ce mécanisme de repli réduit les coûts de support en aval.

Considérez chacun de ces cinq domaines comme un point de décision plutôt que comme une configuration « on configure et on oublie », et vous pourrez faire passer le RAG d'une démo tape-à-l'œil à un service de production fiable. Le résultat : un système qui répond rapidement, reste sur le sujet et sait quand se taire.