RAG en production : de 10 000 € à 900 € par mois.

10 000 € par mois de coûts d'inférence pour un pipeline RAG qui traite quelques milliers de requêtes utilisateur. Pas des millions. Quelques milliers. C'est le chiffre qu'on nous a présenté lors du kick-off avec une banque européenne de taille moyenne, début 2024. Leur POC RAG tournait sur GPT-4, l'équipe adorait les résultats, mais le budget explosait avant même d'avoir ouvert le service à l'ensemble des collaborateurs.

Six mois plus tard, même charge, même qualité perçue par les utilisateurs : 900 € par mois. On vous explique comment, sans bullshit, avec les vrais chiffres et les arbitrages qu'on a faits.

Spoiler : ce n'est pas une success story où "on a tout migré sur du self-hosted et c'est magique". C'est une approche hybride, pragmatique, avec des compromis assumés. Exactement ce qu'on fait chez Abbeal : de l'ingénierie logicielle qui tient la route en prod.

Le contexte : un RAG classique qui coûte cher

La banque avait un use case légitime : permettre aux conseillers clientèle d'interroger en langage naturel une base documentaire de plusieurs milliers de documents réglementaires, notes internes, fiches produits. Un RAG classique : embedding des documents, recherche vectorielle, génération de réponse avec contexte.

Stack initiale du POC :

• Embedding : text-embedding-ada-002 d'OpenAI
• Vector store : Pinecone (plan Starter)
• LLM : GPT-4 (8K context)
• Orchestration : LangChain, hébergé sur Cloud Run

Volumétrie : environ 3 000 requêtes par mois en phase pilote (50 utilisateurs early adopters), avec une moyenne de 4 000 tokens par requête (contexte + prompt + réponse). Le tout pour 10 000 € mensuels, dont 85 % en appels GPT-4.

Problème : impossible de scaler à 500 utilisateurs avec ce modèle économique. Budget prévisionnel de 80-100 K€ par an juste pour l'inférence. Le sponsor métier a calé, le projet allait être mis en pause.

Diagnostic : où part l'argent ?

Avant d'optimiser, on a instrumenté. On a ajouté des logs détaillés sur chaque appel API : tokens in/out, latence, coût unitaire. Premier constat en une semaine d'analyse :

• 70 % des requêtes étaient des questions simples, factuelles, qui ne nécessitaient pas GPT-4. Genre "Quel est le taux du Livret A ?" ou "Quelle est la date limite pour le formulaire X ?"
• 20 % des requêtes nécessitaient un raisonnement complexe ou une synthèse multi-documents. Vraiment GPT-4 territory.
• 10 % des requêtes étaient mal formulées ou hors scope, et généraient quand même un appel coûteux.

Deuxième constat : le contexte injecté dans le prompt était souvent surdimensionné. LangChain récupérait par défaut 6-8 chunks de 500 tokens chacun, même quand 2 suffisaient. Résultat : tokens input gonflés artificiellement.

Stratégie #1 : routing intelligent par complexité

On a mis en place un routeur léger qui classe chaque requête en trois catégories : simple, medium, complex. Pas de fine-tuning compliqué, juste un petit modèle de classification basé sur des règles + un classificateur distilbert entraîné sur 500 exemples labellisés manuellement.

• Simple → GPT-3.5-turbo (90 % moins cher que GPT-4)
• Medium → GPT-4-turbo (moitié prix de GPT-4 vanilla, context window plus large)
• Complex → GPT-4 classique, mais on a réduit ce bucket à moins de 15 % des requêtes

Temps de dev : 3 jours pour le classificateur, 2 jours pour le routeur. Gain immédiat : -55 % sur les coûts d'inférence. De 10 000 € à 4 500 € par mois, sans dégradation perçue de la qualité.

Le code du routeur (simplifié)

py
from transformers import pipeline

classifier = pipeline("text-classification", model="./query-complexity-model")

def route_query(query: str) -> str:
    result = classifier(query)[0]
    label = result["label"]
    score = result["score"]
    
    if label == "SIMPLE" and score > 0.8:
        return "gpt-3.5-turbo"
    elif label == "COMPLEX" and score > 0.75:
        return "gpt-4"
    else:
        return "gpt-4-turbo"  # default safe choice

Rien de révolutionnaire. Ça tourne en 20 ms en moyenne, coût négligeable.

Stratégie #2 : optimisation du contexte RAG

Deuxième levier : réduire le nombre de tokens envoyés sans dégrader la pertinence. On a retravaillé la chaîne de retrieval :

1. Reranking : après la recherche vectorielle, on passe les top 10 chunks dans un modèle de reranking (cross-encoder de Sentence Transformers). On ne garde que les 2-3 chunks vraiment pertinents.
2. Compression de contexte : pour les chunks longs, on a ajouté une étape de summarization légère avec bart-large-cnn pour condenser l'info sans perdre le sens.
3. Prompt engineering : on a réécrit les prompts pour être plus directifs, éviter les répétitions de contexte, et demander des réponses plus concises.

Résultat : tokens moyens par requête passés de 4 000 à 2 200. Gain supplémentaire : -45 % sur les coûts restants. On est à 2 500 € par mois environ.

Stratégie #3 : caching agressif et embeddings self-hosted

On avait encore deux leviers à activer :

Cache sémantique

On a mis en place un cache sémantique : si une nouvelle requête est suffisamment proche d'une requête déjà traitée (cosine similarity > 0.92 sur les embeddings), on sert la réponse en cache. Avec Redis + RediSearch pour l'indexation vectorielle.

Hit rate après un mois : 18 %. Ça paraît faible, mais sur 3 000 requêtes, ça fait 540 appels LLM économisés. Environ 300 € de gain mensuel, pour un Redis qui coûte 50 € par mois.

Embeddings self-hosted

On a remplacé text-embedding-ada-002 (OpenAI) par bge-large-en-v1.5, un modèle open source qu'on a déployé sur une VM GPU (T4) chez Google Cloud. Coût de la VM : 150 € par mois. Économie sur les appels embeddings : environ 400 € par mois.

Net gain : 250 € par mois, plus l'indépendance vis-à-vis d'OpenAI pour cette brique.

Stratégie #4 : fine-tuning d'un petit modèle pour les FAQ

Dernière optimisation, la plus technique : on a identifié un cluster de ~200 questions récurrentes (type FAQ interne) qui revenaient sans cesse. Au lieu de passer par le pipeline RAG complet, on a fine-tuné un Mistral-7B sur ces 200 Q&A + 1 000 exemples synthétiques générés avec GPT-4.

On sert ce modèle via une VM CPU (pas besoin de GPU pour l'inférence avec quantization Q4_K_M). Latence : 800 ms en moyenne. Coût marginal : quasi nul, la VM tourne déjà pour d'autres services.

Le routeur détecte si la requête match une FAQ (via un index Elasticsearch simple), et si oui, bascule sur le Mistral fine-tuné. Couvre environ 12 % des requêtes. Économie supplémentaire : 400 € par mois.

Bilan chiffré : de 10 000 € à 900 €

Récap des gains cumulés :

• Routing intelligent : -5 500 €
• Optimisation contexte RAG : -2 000 €
• Cache sémantique : -300 €
• Embeddings self-hosted : -250 €
• Fine-tuning FAQ : -400 €
• Coûts infra additionnels (VM, Redis) : +350 €

Total : 900 € par mois, soit 91 % de réduction. Temps de développement total : environ 6 semaines/homme, étalées sur 4 mois (on a itéré prudemment, avec A/B tests à chaque étape).

Ce qu'on a appris (et ce qu'on ferait différemment)

Quelques retours d'expérience concrets :

• Instrumentez avant d'optimiser. On a perdu 2 semaines à optimiser les mauvais trucs avant d'avoir les vrais chiffres.
• Le routing intelligent est le levier #1. Si vous ne faites qu'une chose, faites ça. ROI immédiat, risque faible.
• Ne sous-estimez pas le reranking. C'est un game changer pour la précision du RAG, et ça coûte rien.
• Self-hosting : à faire uniquement si vous avez déjà les compétences MLOps en interne. Sinon, le coût caché (maintenance, monitoring, debugging) bouffe vite les gains.
• Fine-tuning : rentable seulement si vous avez un cluster de requêtes vraiment récurrentes et bien identifiées. Sinon, c'est du temps perdu.

Si c'était à refaire, on aurait démarré par le routing + reranking dès le POC. Ça aurait évité le coup de stress budgétaire à mi-projet.

Conclusion : hybride > dogme

On voit passer beaucoup de discours "tout open source self-hosted" ou à l'inverse "tout SaaS managed". La réalité, c'est que l'approche hybride est souvent la plus pragmatique : APIs managées pour les use cases complexes, self-hosted pour les briques commoditisées, fine-tuning ciblé pour les patterns récurrents.

Ce projet RAG est maintenant en prod chez notre client depuis 4 mois, avec 500+ utilisateurs actifs, et le budget infra reste sous les 1 200 € par mois. L'équipe interne a repris la main sur la maintenance courante, et on intervenons en support ponctuel pour les évolutions.

Si vous avez un projet RAG qui explose votre budget, ou si vous êtes en phase POC et que vous voulez éviter ce piège, on a rodé cette approche sur 4-5 projets similaires. Chez Abbeal, on ne vend pas de la presta au mètre : on vient résoudre des problèmes concrets, on transfert les compétences, et on se casse quand c'est fini. Parlons-en.