La plupart des tutoriels RAG s'arrêtent exactement là où la production commence. Vous divisez vos documents en segments de 512 tokens, vous les passez dans un modèle d'embedding unique et vous appelez une base de données vectorielle avec une simple récupération top-k. Dans une démo, cela semble convaincant. Posez une question au bot sur la politique de congés de votre entreprise et il renvoie un paragraphe cohérent. Tout le monde acquiesce. Malheureusement, les démos mentent.

La production expose chaque raccourci. Les segments de taille fixe coupent les contrats juridiques en plein milieu des clauses d'indemnisation. La documentation d'API se transforme en un bruit de chevauchement qui étouffe le signal dont vous avez réellement besoin. La latence augmente jusqu'à ce que les utilisateurs abandonnent la requête avant que la réponse n'arrive. Nous nous sommes heurtés à ce mur et avons dû tout reconstruire. Notre couche de récupération est passée d'une approche de « recherche sémantique et espoir » à un pipeline mesuré et instrumenté. Le résultat a été un rappel de 95 % et une réduction de 40 % de la latence. Voici ce qui a réellement fonctionné.

Adaptez la stratégie de segmentation au document

Le défaut de 512 tokens persiste parce qu'il est facile, pas parce qu'il est correct. Différents documents véhiculent le sens de différentes manières, et votre stratégie de segmentation doit refléter cela.

Pour les contrats juridiques, utilisez une segmentation récursive qui respecte les limites structurelles. Le langage juridique est imbriqué. Une clause dépend de la section qui la précède, et une coupure fixe au milieu d'une phrase détruit la logique d'une obligation. La segmentation récursive tente d'abord des divisions sur des séparateurs naturels — les paragraphes, puis les phrases — avant d'imposer une limite de tokens. Cela permet de maintenir intactes les clauses d'indemnisation ou de responsabilité.

Pour la documentation d'API, utilisez une segmentation sensible aux fonctions. Les développeurs ne recherchent pas des paragraphes aléatoires ; ils recherchent des points de terminaison (endpoints), des paramètres et des signatures d'erreur. Un segment doit contenir la signature complète de la fonction, sa description et le schéma de retour comme une seule unité logique. Si vous coupez ce bloc en deux, le système de récupération renvoie la moitié du contexte et le modèle de génération hallucine le reste.

Pour les tickets de support, appuyez-vous sur une segmentation sémantique qui suit les échanges. Les fils de discussion de support sont linéaires et répétitifs. Un client répète le problème, un agent demande des logs, le client les joint. Chaque échange est sa propre unité sémantique. Segmenter par échange préserve l'attribution de qui a dit quoi et quand, ce qui est crucial lorsque l'utilisateur demande : « Qu'est-ce que l'agent a suggéré mardi ? »

Pour les wikis internes, essayez la segmentation agentique. Donnez une section à un LLM et demandez-lui de décider où un sujet se termine et où un autre commence. Cela coûte plus cher lors de l'ingestion, mais les wikis sont désordonnés. Les pages contiennent des mises à jour sans rapport provenant de différentes équipes, et une limite définie par un humain aide rarement. Laisser un modèle tracer des frontières basées sur les changements de sujet réduit considérablement le bruit.

L'exécution de plusieurs stratégies dans un seul pipeline nécessite un étiquetage des documents par type lors de l'ingestion. Cette petite discipline de schéma porte immédiatement ses fruits.

Combinez les méthodes de recherche, ne choisissez pas une seule

La recherche vectorielle comprend l'intention, mais elle échoue systématiquement sur les correspondances exactes. Demandez un code d'erreur ERR_CONNECTION_REFUSED ou un SKU spécifique, et les embeddings denses renvoient souvent des résultats conceptuellement similaires mais factuellement erronés. Le BM25, la méthode classique de recherche par mots-clés (sparse retrieval), gère magnifiquement les chaînes exactes mais manque de nuance sémantique. Vous avez besoin des deux.

Utilisez la récupération hybride. Exécutez la recherche vectorielle et le BM25 en parallèle. Ensuite, combinez-les avec le Reciprocal Rank Fusion (RRF). Le RRF récompense les documents sur lesquels les deux méthodes s'accordent pour être pertinents, tout en faisant remonter des candidats solides issus de l'une ou l'autre approche. Les mathématiques sont simples et le résultat est stable : aucune méthode de récupération unique ne domine le classement final.

Après la fusion, ajoutez un ré-ordonnanceur (reranker) par cross-encoder. La première étape — recherche vectorielle plus recherche parcimonieuse — est rapide et large. Le cross-encoder évalue ensuite chaque paire requête-document avec une attention complète, ce qui signifie qu'il lit réellement le candidat par rapport à la question originale. Oui, cela ajoute de la latence. Dans notre cas, environ cinquante à cent millisecondes. Mais le gain de précision est suffisamment important pour que le compromis soit évident. Vous ne pouvez pas vous permettre de l'ignorer si vous vous souciez du rappel.

Corrigez la requête avant de corriger l'index

Les utilisateurs n'écrivent pas des requêtes pour votre moteur de recherche. Ils les écrivent pour des humains. « Ça ne marche pas » est une requête de support courante. Une description vague d'une fonctionnalité est une recherche courante dans un wiki interne. Si vous interrogez l'index avec cette entrée brute, vous obtiendrez des résultats de mauvaise qualité.

Transformez la requête avant qu'elle n'atteigne le retriever.

Use query expansion to generate multiple versions of the user’s question. If someone types “server down,” your system should also search for “service unavailable,” “502 error,” and “connection timeout.” Covering these intent variants moved our recall from 78% to 96%. It is a single step, and it costs almost nothing compared to the gain.

Use query decomposition for complex questions. When a user asks something like “How do I migrate from the legacy billing API to the new one and what breaking changes affect enterprise accounts?,” break it into sub-questions. One sub-question targets migration steps. Another targets enterprise-specific breaking changes. Each hits a different part of the index. The downstream language model synthesizes the final answer from well-retrieved chunks rather than guessing across a noisy context window.

Stop Guessing Hyperparameters

Once you have multiple chunking strategies, hybrid retrieval, and query transformation, you face a combinatorial problem. Chunk size, overlap, fusion weights, reranker depth, and expansion count all interact. Tweaking one in isolation breaks another. Grid search across this space is wasteful and slow.

Use Bayesian optimization instead. Treat this like a machine learning tuning job. Define your objective clearly: maximize recall while keeping latency under a ceiling. Build a golden dataset — a few hundred representative questions where you know precisely which chunks should be retrieved. Then let the Bayesian search explore the configuration space efficiently. It builds a probabilistic model of what works and tests the most promising regions next.

Every candidate configuration must pass the golden dataset before it reaches staging. If a new chunk size drops recall or a heavier reranker pushes you past the latency budget, the optimization catches it automatically. This removes opinion from the room. You stop debating whether 256 or 512 tokens is “better” and start reading the results.

The Outcome

The pipeline changes compounded exactly as we hoped.

  • Recall@10 climbed from 78% to 95%.
  • P95 latency dropped from 850 ms to 320 ms.
  • Hallucination rate fell from 12% to 3%.
  • Cost per query dropped by 38%, largely because better retrieval let us use a smaller generation model and fewer prompt tokens.

The latency reduction surprised some people on the team. Adding rerankers and query expansion sounds like it should slow things down. But because retrieval quality improved, the generation model needed less prompting, less speculation, and fewer retries. Good retrieval makes everything downstream cheaper.

Treat Retrieval Like Infrastructure

Retrieval is not a notebook you run once and forget. It is infrastructure, and it should be managed like code. Version your chunking strategies. When the legal team releases a new contract template, test your recursive splitter before it reaches production. Maintain your golden dataset as living documents, not a static CSV from last quarter. Automate your evaluations in CI so that a pull request modifying an embedding model or a fusion weight gets a comment with recall and latency numbers before a human ever reviews it.

Your users will never ask which embedding model you run. They will not care about your chunking heuristic or your reranker architecture. They care if the answer is correct, if it arrives fast, and if they can trust it. Build a pipeline that earns that trust, measure it honestly, and stop treating retrieval like an afterthought.

Source: Optimizing RAG At Scale
Join the discussion: GyaanSetu AI Community