Lors du déploiement des systèmes RAG en production, la première question est généralement « quel modèle d'embedding, compte tenu du coût des tokens ». Mauvaise question. La bonne question : « si la précision de la récupération chute sous 0,85, quel pourcentage de requêtes utilisateur se transforment en hallucinations ? » La structure des coûts RAG ne ressemble pas à l'inférence batch — une mauvaise récupération crée un gaspillage exponentiel de tokens en aval et une perte de confiance utilisateur. Le choix du modèle d'embedding, la stratégie de chunking et la configuration d'évaluation doivent être abordés dans ce contexte.
Modèle d'embedding : La qualité de l'espace latent avant les métriques coût/token
Lors du choix d'un modèle d'embedding, l'ordre des métriques à examiner est : précision de récupération → dérive sémantique → latence → coût/token. OpenAI text-embedding-3-large (3072 dimensions), Cohere embed-v3 (1024), Voyage AI voyage-2 (1536) — ces chiffres définissent la granularité de l'espace latent. Mais la véritable différence ne réside pas dans les benchmarks, mais dans le comportement sur les requêtes spécifiques au domaine. Sur une plateforme de commerce électronique, la requête « veste en cuir noir taille M » produisait 12% de faux positifs supplémentaires avec text-embedding-3-large, car il encodait « cuir » davantage comme un style que comme une matière. L'option de fine-tuning de domaine de Voyage AI entre alors en jeu — un fine-tune de 2 semaines avec 5000 paires requête-document a augmenté la précision de 18% par rapport à la baseline.
Le calcul des coûts fonctionne ainsi : text-embedding-3-large coûte $0,13 par 1M de tokens, Cohere $0,10. Mais si la précision est faible, un mauvais contexte atteint le LLM — GPT-4o coûte $0,30 par 10K tokens, une récupération incorrecte signifie 3K tokens supplémentaires = $0,09 supplémentaires par requête. À 100K requêtes/mois, cela représente $9K gaspillés. Économiser $30 sur l'embedding pour perdre $9K en aval n'est pas rationnel. La latence suit un schéma similaire : Cohere 45ms, Voyage 62ms — mais la qualité de récupération supérieure de Voyage réduit le besoin de reranking de 40%, ce qui fait passer la latence totale du pipeline de 180ms à 140ms.
Pour le suivi de la dérive sémantique, l'ensemble d'évaluation doit inclure des requêtes temporelles. Exécutez la même requête utilisateur avec 3 mois d'intervalle, comparez les ensembles de documents récupérés. S'il y a une dérive supérieure à 15%, cela signifie que le modèle d'embedding est exposé à une dérive de concept en production — un réentraînement ou un changement de modèle est nécessaire. Sans ce suivi, le choix du modèle d'embedding devient une décision aveugle.
Stratégie de chunking : L'erreur du fixed-size et le compromis d'overlap
L'erreur la plus courante : chunks de 512 tokens de taille fixe + 50 tokens d'overlap. Cette approche naïve ignore les limites sémantiques. Elle divise les en-têtes Markdown, les blocs de code, les tableaux — créant une perte de contexte dans la récupération. Alternative : chunking sémantique — utiliser les embeddings de phrases pour définir les limites dynamiques des chunks basées sur un seuil de similarité sémantique (par exemple, cosinus 0,75). Le SemanticChunker de LangChain le fait, mais crée un surcoût de latence de 30% — si la latence est critique, une approche hybride (splitting de caractères récursif + parsing conscient des en-têtes) est plus pragmatique.
Le compromis d'overlap : 0% d'overlap = perte d'information aux limites des chunks, 50% d'overlap = taille d'index 1,5x + augmentation de la latence de requête de 25%. Le sweet spot varie selon le domaine. Pour la documentation technique, 25% d'overlap (128 tokens @ 512 chunks), pour les données conversationnelles, 10% (50 tokens). Test : créez un sous-ensemble « boundary query » dans l'ensemble d'évaluation — des requêtes dont la réponse se situe entre deux chunks. Comment l'augmentation de l'overlap affecte-t-elle la précision de la récupération sur ces requêtes ? Dans nos tests, 25% d'overlap a augmenté la précision de 0,68 à 0,81 sur les boundary queries. À 50%, elle atteint 0,83, mais le coût de latence de 2% de gain supplémentaires n'est pas justifiable.
Le choix de la taille des chunks n'est pas binaire. Les chunks de 256 tokens permettent une récupération plus granulaire, les chunks de 1024 tokens offrent plus de contexte par chunk. Mais quand la fenêtre de contexte du LLM est remplie, 1024 tokens chunks = 4 chunks = 4K tokens, 256 tokens chunks = 16 chunks = 4K tokens — même contexte, mais le chunking de 256 offre 4x plus d'options sémantiques. Compromis : coût d'embedding 4x, mais diversité de récupération augmente. En production, approche hybride : 256 pour les FAQ/short-form, 768 pour les articles long-form. Cela nécessite un tracking de performance basé sur les logs dans cette architecture d'analyse de données — quelle taille de chunk performe mieux pour quel type de requête ?
Métadonnées de chunks : Injection de champs JSON
Injecter des métadonnées dans chaque chunk est crucial pour le filtrage de la récupération. Des champs comme {category, created_at, author, content_type} permettent le filtrage des métadonnées en plus de la recherche vectorielle. Exemple : la requête « tutoriels Python de 2025 » correspond à la fois sémantiquement et au filtre created_at > 2025-01-01. Cette approche hybride a augmenté la précision de récupération de 22%. Pinecone, Weaviate, Qdrant supportent tous le filtrage des métadonnées, mais la syntaxe de requête diffère — utiliser LlamaIndex comme couche d'abstraction offre de la flexibilité.
Configuration d'évaluation : Les métriques hors ligne ne peuvent pas prédire les hallucinations de production
Pour l'évaluation RAG, les métriques hors ligne incluent : précision de récupération, rappel, MRR (mean reciprocal rank), NDCG. Nécessaires mais insuffisantes. Le vrai problème en production : le contexte récupéré est correct mais le LLM hallucine quand même. Cela nécessite une évaluation end-to-end — chunks récupérés + réponse du LLM + réponse de vérité au sol en comparaison. Le framework Ragas le fait : fidélité, pertinence de la réponse, précision du contexte et autres métriques basées sur LLM-as-judge. Nous utilisons GPT-4o comme juge et exécutons une évaluation batch — 1000 requêtes d'ensemble d'évaluation, complétées en 24 heures.
Composition de l'ensemble d'évaluation : 60% requêtes utilisateur réelles (log de production), 20% cas limites (ambigus délibérément), 20% adversariaux (informations anciennes, docs obsolètes). Les requêtes utilisateur réelles reflètent la distribution de production. Les cas limites testent la gestion de l'incertitude du modèle. L'ensemble adversarial simule une dérive temporelle — une requête 2026 basée sur une doc datée de 2023 doit inclure un avertissement « information non à jour ».
Pour l'évaluation continue, toutes les 2 semaines, 200 nouvelles requêtes d'évaluation sont ajoutées à l'ensemble. Échantillon aléatoire du log de production + curation des cas limites. Nous testons les changements de modèle/chunking/config de récupération sur cet ensemble. Drop de précision > 5% = rollback. Le pipeline d'évaluation s'exécute sur AWS Step Functions — embedding, récupération, inférence du LLM, scoring, alerte Slack. Runtime total 45 minutes, coût $12 par exécution d'évaluation. Pousser les changements RAG en production sans cela est un déploiement aveugle.
Reranking et expansion de requête : Les couches négligées du pipeline de récupération
La recherche vectorielle seule est insuffisante. Après récupération top-K (par ex. K=20), un modèle de reranking (Cohere Rerank, bge-reranker) réordonne par pertinence sémantique, les K=5 finaux vont au LLM — cela augmente la précision de récupération de 30%. Le surcoût de latence du reranking est 80ms, mais comme le contexte incorrect n'atteint pas le LLM, la fiabilité du pipeline augmente. Coût : Cohere Rerank $1/1K requêtes — soit $100 pour 100K requêtes/mois, mais réduit le gaspillage en aval du LLM de $9K à $3K.
Expansion de requête : La requête utilisateur « comment configurer RAG » est simple, mais dans l'espace sémantique, « retrieval-augmented generation implementation » devrait aussi correspondre. L'approche HyDE (hypothetical document embedding) : demandez au LLM « écrivez la réponse idéale à cette requête », embedez la réponse, cherchez avec cet embedding. Cela offre une expansion de requête implicite. En production, nous avons obtenu un gain de précision de 15%, mais une latence +120ms. Compromis : si la latence est critique, l'expansion de requête classique (injection de synonymes) offre un gain similaire en 40ms.
Monitoring de production : La qualité de récupération ne peut pas être optimisée si elle n'est pas observable
Les métriques à monitorer dans un système RAG : latence de récupération p50/p95/p99, taux de hit du cache d'embedding, distribution des scores de pertinence des chunks récupérés, score de fidélité du LLM (calculé avec LLM-as-judge), retours utilisateurs (pouces levés/baissés). Nous poussons ceux-ci vers Datadog comme métriques personnalisées. Si la latence de récupération p95 dépasse 200ms, alerte — car la latence totale utilisateur est limitée à 500ms SLA, si la récupération dépasse 200ms, avec l'inférence du LLM, on viole le SLA.
Score de pertinence des chunks récupérés : Loggez les scores de similarité cosinus des top-5 chunks pour chaque récupération. Un shift de distribution (par ex. score moyen de 0,78 à 0,65) signale une dérive du modèle d'embedding ou un problème de qualité du corpus. Tracer cela dans votre architecture de données first-party offre la possibilité de gérer proactivement la qualité de récupération.
Quand la qualité de récupération est-elle assurée et que l'optimisation des coûts commence ?
Une fois que la qualité de récupération est stabilisée à la cible, alors l'optimisation des coûts : (1) Cache d'embedding — si la même requête revient, servir depuis le cache, TTL 6 heures. Taux de hit 40%, coût d'embedding réduit de 40%. (2) Embeddings quantifiés — int8 au lieu de float32, taille d'index réduite de 75%, perte de précision de récupération 2% — acceptable. (3) Recherche hybride — sparse (BM25) + dense (vectorielle), requêtes sparse 70% moins chères, simples requêtes gérées par sparse seul. Routage par classifieur de requête, 30% requêtes vers sparse, 70% vers vectorielle — coût réduit de 20%.
Ces optimisations de coûts doivent intervenir après la stabilisation de la qualité de récupération. Sinon, une réduction aveugle des coûts augmente le gaspillage en aval du LLM et augmente le coût net. RAG economics : embedding $500/mois, infra de récupération $1200/mois, inférence du LLM $8000/mois. Économiser $100 sur l'embedding en réduisant la qualité de récupération et augmentant le gaspillage du LLM de $2000 n'est pas rationnel. Mais quantifier l'embedding et réduire de $125 tout en augmentant le gaspillage du LLM de $50 après stabilisation à 90% de précision est rationnel.
Les systèmes RAG de production deviennent critiques dans l'automation marketing, le support client, la génération de contenu. Mais tous reposent sur la qualité de la récupération — une mauvaise récupération rend la sortie IA peu fiable. Faire d'abord les bonnes décisions sur le modèle d'embedding, le chunking, l'évaluation et le monitoring, puis optimiser les coûts. L'alternative, c'est tenter d'optimiser sur des fondations inexistantes. Le premiers pas : mesurez la précision de récupération dans votre pipeline RAG actuel — si elle n'existe pas, ajoutez-la. Ensuite, regardez les coûts.