Combien coûte vraiment un système RAG ? Ingestion, stockage, récupération et génération détaillés

Un système RAG coûte de l'argent à quatre moments distincts : quand vous indexez vos documents, quand vous les stockez, quand vous recherchez les passages pertinents et quand le modèle de langage rédige la réponse. Le prix affiché par un fournisseur (par question ou par abonnement) agrège ces quatre postes, souvent sans le détailler. Comprendre chacun permet de négocier, d'optimiser et d'éviter les mauvaises surprises en fin de mois.

Les quatre postes de coût d'un système RAG

Avant de comparer des offres ou de construire son propre pipeline, il faut décomposer la facture. Un système de génération augmentée par récupération traite chaque document une fois à l'ingestion, puis répond à de nombreuses questions ensuite. Les coûts ne sont donc pas répartis de la même façon dans le temps : certains sont ponctuels, d'autres récurrents, d'autres encore proportionnels au volume de questions posées.

• Ingestion et indexation : extraction du texte, découpage en chunks, calcul des embeddings. Coût ponctuel, payé une fois par document (sauf mise à jour).
• Stockage : conserver les vecteurs, l'index de recherche et les documents sources. Coût récurrent, proportionnel au volume de données conservées.
• Récupération : exécuter la requête (recherche hybride, reranking éventuel) pour retrouver les passages pertinents à chaque question. Coût variable, par question.
• Génération : envoyer le contexte récupéré au modèle de langage et produire la réponse. Coût variable, proportionnel au nombre de tokens en entrée et en sortie.

Ingestion et indexation : le coût caché du démarrage

C'est le poste le plus souvent sous-estimé. Extraire proprement le texte d'un PDF scanné, d'un tableau Excel complexe ou d'un contrat Word mal formaté demande du traitement (OCR, nettoyage, structuration). Vient ensuite le découpage en chunks, puis le calcul d'un vecteur (embedding) pour chaque chunk via un modèle dédié. Pour une base de quelques centaines de pages, ce travail reste marginal en euros, mais il grimpe vite si vous ingérez des dizaines de milliers de pages ou si vous ré-indexez régulièrement des documents qui changent souvent (politiques internes, catalogues produits, jurisprudence).

La façon dont vous découpez vos documents a un impact direct sur ce coût et sur la qualité des réponses obtenues ensuite. Des chunks trop petits multiplient le nombre de vecteurs à calculer et à stocker ; trop grands, ils diluent le signal au moment de la recherche. Les stratégies de chunking pour le RAG permettent de trouver le bon compromis entre coût d'indexation et précision des réponses.

Stockage : combien pèsent les vecteurs et l'index

Une fois calculés, les vecteurs doivent être stockés dans une base capable de faire de la recherche par similarité, généralement combinée à un index plein texte pour la recherche par mots-clés. Le volume de stockage dépend de la dimension des vecteurs (souvent entre quelques centaines et quelques milliers de nombres par chunk) et du nombre total de chunks. Le détail du prix d'une base de données vectorielle montre que ce poste reste modeste en valeur absolue pour une PME, mais qu'il peut devenir significatif si vous conservez plusieurs versions d'un même corpus ou si vous multipliez les bases par client.

Le coût par question : récupération + génération

C'est le poste que l'utilisateur final perçoit directement, et celui qui détermine la rentabilité d'un usage à grande échelle. À chaque question, le système doit : transformer la requête en vecteur, chercher les passages les plus pertinents (recherche hybride mots-clés + sémantique), parfois reclasser les résultats avec un reranker, puis envoyer ces passages ainsi que la question au modèle de langage pour générer une réponse. Le coût de génération dépend presque exclusivement du nombre de tokens envoyés en entrée (la question et les passages récupérés) et du nombre de tokens produits en sortie.

C'est ici que se joue l'arbitrage entre qualité et budget. Envoyer tout un document complet dans le prompt plutôt que de faire une recherche ciblée augmente mécaniquement le nombre de tokens facturés, et donc le prix de chaque question. L'article RAG vs contexte long détaille précisément quand il vaut mieux chercher des passages pertinents plutôt que de tout envoyer au modèle : au-delà d'un certain volume de documents, la recherche ciblée devient à la fois moins chère et plus fiable.

Facturation à la question ou abonnement : comment choisir

Les fournisseurs de RAG as a service proposent généralement deux modèles de facturation, chacun adapté à un profil d'usage différent.

• Crédits prépayés par question : vous achetez un volume de crédits et chaque question en consomme un nombre variable selon sa complexité. Adapté à un usage irrégulier ou pour tester un cas d'usage avant de s'engager.
• Abonnement avec jauge d'usage : un montant fixe mensuel couvre un volume de questions, avec une jauge pour suivre la consommation. Adapté à un usage régulier et prévisible, car il lisse la facture d'un mois sur l'autre.
• Facturation à l'usage pur : chaque appel API est facturé au tokens consommés, sans forfait. Adapté aux développeurs qui intègrent le RAG dans une application avec un volume variable.

Sur Kopik, les deux logiques coexistent : des crédits prépayés par question pour un usage ponctuel ou pour interroger une base publique du catalogue, et un abonnement à 12 € par mois avec une jauge d'usage pour un usage régulier en chat. Les créateurs de bases publiques fixent eux-mêmes leur prix par question et conservent 70 % des revenus générés, ce qui permet de comparer directement plusieurs bases sur un même sujet avant de choisir celle qui répond le mieux à votre besoin.

Dix leviers concrets pour réduire la facture

1. Nettoyer les documents avant ingestion (supprimer les pages redondantes, les mentions légales répétées, les doublons) pour réduire le volume indexé.
2. Choisir une taille de chunk adaptée au type de document plutôt qu'une valeur par défaut uniforme, voir les stratégies de chunking.
3. Privilégier la recherche hybride à un simple matching sémantique : elle réduit le nombre de passages inutiles envoyés au modèle.
4. Limiter le nombre de passages récupérés par question (souvent 3 à 8 passages suffisent, au-delà le coût grimpe sans gain de qualité).
5. Réserver le reranking aux cas à forte exigence de précision plutôt que l'appliquer systématiquement.
6. Mettre en cache les réponses aux questions fréquentes plutôt que de régénérer à chaque fois.
7. Ré-indexer uniquement les documents modifiés plutôt que l'intégralité de la base à chaque mise à jour.
8. Séparer les bases par thématique plutôt qu'une base unique gigantesque : la recherche est plus rapide et plus pertinente sur un corpus ciblé.
9. Suivre régulièrement la qualité des réponses pour éviter de sur-provisionner (trop de passages, prompts trop longs) par excès de prudence, voir comment évaluer un système RAG.
10. Choisir le bon format de réponse selon l'usage : le mode « passages seuls » coûte moins cher qu'une réponse générée quand l'utilisateur sait lire la source brute.

RAG, fine-tuning ou contexte long : comparer le coût total

Le RAG n'est pas la seule façon de connecter un modèle de langage à des connaissances spécifiques. Le fine-tuning entraîne le modèle sur vos données, avec un coût d'entraînement initial élevé et une maintenance complexe dès que les documents changent. Le contexte long consiste à tout envoyer dans le prompt sans recherche préalable, ce qui fonctionne pour de petits corpus mais devient coûteux et peu fiable au-delà de quelques dizaines de pages. Le comparatif RAG ou fine-tuning détaille les critères de choix selon la fréquence de mise à jour de vos documents et le volume de questions à traiter. Pour les équipes qui ne veulent pas construire et maintenir leur propre pipeline, un panorama des plateformes RAG as a service aide à comparer les modèles de facturation d'un fournisseur à l'autre.

Développeurs : intégrer le RAG sans exploser le budget

Pour une équipe technique, le coût du RAG se pilote aussi au niveau de l'intégration. Passer par une API de base de connaissances plutôt que de construire son propre pipeline d'embeddings et de recherche évite les coûts d'infrastructure (serveurs de calcul, base vectorielle à maintenir, mise à jour des modèles d'embedding). La documentation développeurs de Kopik détaille les clés API et le serveur MCP compatible avec Claude, Cursor ou ChatGPT, utile pour chiffrer précisément le coût par appel avant de l'intégrer dans un produit facturé à vos propres clients.

Foire aux questions