Le retrieval augmented generation (RAG) est devenu la réponse standard pour brancher des modèles de langage sur vos documents internes sans tout ré-entraîner. Pourtant, derrière la démo « posez une question sur vos PDF », se cachent des choix d’architecture qui fixent pour des mois votre budget GPU, votre latence utilisateur et la fiabilité des réponses. Cet article décrit comment cadrer ce triangle sans sacrifier l’expérience ni exploser la ligne « cloud IA ».
Pourquoi le RAG n’est pas « brancher un dossier sur ChatGPT »
Un pipeline RAG combine au minimum : ingestion (extraction, nettoyage), segmentation (chunking), vectorisation (embeddings), stockage dans une base vectorielle, puis recherche (retrieval) et enfin appel à un LLM avec le contexte récupéré. Chaque étape ajoute des coûts variables : stockage, requêtes d’embedding, lectures de vecteurs, tokens d’inférence, parfois re-ranking supplémentaire. Si vous ne mesurez que le prix du modèle, vous sous-estimez la moitié de la facture — et vous découvrez tard que « l’IA interne » coûte plus cher que le support humain qu’elle devait remplacer.
Coût : ce qui fait gonfler la facture sans que le métier le voie
Les embeddings se facturent au volume de texte traité et à la fréquence des mises à jour. Une politique de ré-ingestion « à chaque commit » peut multiplier les appels API. Les bases vectorielles facturent stockage, lectures/écritures, et parfois des nœuds dédiés. Les requêtes utilisateur déclenchent : recherche top-k, éventuellement un reranker, puis une génération dont la longueur dépend de votre prompt et de vos garde-fous. Enfin, la rétention des journaux d’audit (prompts, sources) alimente du stockage objet et des pipelines de conformité. Une gouvernance claire sur la fraîcheur des données et la périodicité d’indexation réduit souvent 20 à 40 % des coûts sans perte de valeur métier.
Latence : où perdent les secondes
La latence perçue est une somme : temps de routing, retrieval (I/O disque ou réseau vers la base vectorielle), éventuel rerank, puis TTFT (time to first token) du LLM et streaming. Un chunking trop fin multiplie les candidats et peut augmenter le bruit ; un chunking trop grossier réduit la précision et force des réponses « vagues ». Un top-k élevé gonfle le contexte envoyé au modèle — meilleure couverture, mais plus de tokens et donc plus de latence. Les équipes qui mesurent par segment (ingestion, retrieval, génération) identifient vite si le problème est l’infra ou le modèle — et évitent d’acheter plus de GPU pour masquer un index mal dimensionné.
Qualité : au-delà du score de similarité
La similarité vectorielle n’est pas la vérité métier : deux paragraphes peuvent être « proches » sémantiquement tout en étant contradictoires sur les chiffres. D’où l’intérêt de politiques de citation, de post-filtrage (dates, périmètre produit), et parfois de cross-encoders pour rerank les passages. La qualité des sources prime : OCR bruité, PDF scannés sans texte, ou données dupliquées polluent l’index. Un programme simple de nettoyage et de déduplication améliore souvent davantage les réponses qu’un changement de modèle génératif.
Chunking et métadonnées : le levier le moins glamour, le plus rentable
Fixer la taille des segments, le chevauchement (overlap), et les métadonnées (produit, version, langue, ACL) structure l’espace de recherche et réduit les hallucinations « hors périmètre ». Pour les organisations réglementées, les filtres sur les métadonnées appliquent le contrôle d’accès avant même l’appel au LLM — indispensable dès que des documents sensibles cohabitent dans un même corpus.
Exploitation : SLAs, observabilité et garde-fous
Exposez des métriques : latence p95 par étape, taux d’abstention (refus de répondre faute de sources), couverture des questions fréquentes, coût moyen par requête. Ajoutez des tests de non-régression sur un jeu de questions métier après chaque changement d’embedding ou de topologie d’index. C’est ce qui transforme un prototype RAG en service interne soutenable.
Feuille de route réaliste
Commencez par un périmètre étroit (une base de connaissances, une langue), instrumentez le coût et la latence, puis itérez sur chunking et retrieval avant de changer de famille de modèle. Faites valider par le métier une politique de qualité (quand la machine doit dire « je ne sais pas »). Enfin, anticipez la veille : les fournisseurs d’embeddings et les moteurs vectoriels évoluent vite — ce qui est optimal aujourd’hui peut être dépassé dans douze mois, mais votre cadre de mesure restera le même.
En synthèse
RAG est un produit data autant qu’un widget IA : coût, latence et qualité sont couplés. Des choix simples sur l’ingestion, le chunking, le top-k, et la gouvernance des sources produisent souvent plus de valeur qu’un sur-investissement dans le dernier LLM. Mesurez, coupez le bruit, et alignez la promesse utilisateur sur ce que votre pipeline peut réellement prouver avec des sources vérifiables.
Vous cadreriez une couche RAG interne ou une refonte de recherche documentaire ? Découvrez les services ou écrivez via le formulaire de contact pour en parler dans votre contexte.