Coûts et ROI du RAG : guide budgétaire

Le RAG est un modèle, pas un produit. Un utilisateur pose une question, le système recherche dans une base de connaissances privée les passages les plus pertinents, et ces passages sont transmis à un grand modèle de langage en tant que contexte. Le modèle répond ensuite en utilisant ce matériel au lieu de se fier uniquement à ce qu’il a appris pendant l’entraînement.

Ce modèle existe parce que les modèles ne connaissent pas votre liste de prix, votre politique de retour ou le brief de campagne de la semaine dernière. Affiner un modèle sur ces données est lent et devient obsolète. La récupération garde les faits en dehors du modèle, donc mettre à jour une réponse signifie mettre à jour un document.

Les blocs de construction courants au moment de la rédaction incluent des modèles d’embedding d’OpenAI, Cohere ou Google, des magasins vectoriels comme Pinecone, Weaviate, Qdrant ou pgvector au sein de PostgreSQL, et des bibliothèques d’orchestration comme LangChain ou LlamaIndex. Des options gérées existent également : la recherche de fichiers d’OpenAI, Google Vertex AI Search et Amazon Bedrock Knowledge Bases regroupent la majeure partie de la pile.

Les équipes budgétisent souvent pour la base de données vectorielle et oublient tout ce qui l’entoure. Une feuille de coûts réaliste comporte cinq lignes, et l’ordre ci-dessous correspond approximativement à l’attention que chacune mérite.

• Jetons de génération : chaque réponse envoie la question plus les passages récupérés à un modèle. Les longues fenêtres de contexte en font le plus grand coût variable.
• Préparation du contenu : nettoyage des PDF, découpage des documents en morceaux, suppression des pages obsolètes et étiquetage des métadonnées. Il s’agit principalement du temps du personnel.
• Embeddings : un coût unique pour intégrer le corpus, puis de petits coûts récurrents pour les documents nouveaux ou modifiés et pour chaque requête entrante.
• Stockage vectoriel et hébergement : modeste pour quelques milliers de documents, plus notable lorsque vous indexez des millions de morceaux ou avez besoin d’une faible latence entre les régions.
• Évaluation et maintenance : ensembles de tests, tableaux de bord de surveillance et quelqu’un qui examine les mauvaises réponses chaque semaine.

Les prix de chacun de ces éléments changent souvent, alors vérifiez les pages des fournisseurs actuels avant de vous engager. Ce qui reste stable, c’est la forme : la génération et la main-d’œuvre dominent, le stockage décide rarement du projet.

Pourquoi la taille des morceaux change la facture

Si chaque morceau récupéré fait 800 jetons et que vous en transmettez cinq, chaque question transporte environ 4 000 jetons de contexte avant que le modèle n’écrive un mot. Réduire de moitié la taille des morceaux ou récupérer trois passages au lieu de cinq réduit directement ce coût. Cela peut également nuire à la précision, c’est pourquoi vous testez les deux paramètres par rapport au même ensemble de questions.

Commencez par le volume, pas par la technologie. Comptez combien de questions le système verra par mois, estimez la taille moyenne du contexte et multipliez par le tarif publié par jeton du modèle. Ajoutez ensuite les coûts fixes.

• Étape 1 : Tirez trois mois de tickets de support, de journaux de chat ou de demandes de vente et comptez les types de questions répétées.
• Étape 2 : Choisissez une portée pilote, par exemple uniquement les expéditions et les retours, et estimez le volume mensuel de requêtes pour cette portée.
• Étape 3 : Évaluez deux modèles, un petit rapide et un plus grand, en utilisant votre longueur de prompt moyenne.
• Étape 4 : Ajoutez la main-d’œuvre de configuration pour le nettoyage du contenu, généralement le plus gros élément ponctuel.
• Étape 5 : Réservez un bloc de maintenance mensuel pour examiner les réponses échouées et actualiser les documents.

Par exemple, un détaillant de meubles en ligne répondant aux questions de livraison et d’assemblage pourrait constater qu’un petit modèle gère bien 90 pour cent des requêtes, le modèle plus grand étant réservé aux escalades. Ce choix de routage compte souvent plus que toute décision de base de données.

Les arguments de ROI s’effondrent lorsque le seul chiffre est “questions répondues”. Un bot peut répondre à des milliers de questions mal. Suivez les résultats qu’une équipe financière reconnaît déjà.

• Taux de déflexion : part des conversations fermées sans agent humain, vérifiée par rapport aux contacts répétés dans les 48 heures.
• Précision des réponses : notée sur un ensemble de tests fixe de questions réelles, réexécutée après chaque changement de contenu ou de modèle.
• Coût par requête résolue : dépenses mensuelles totales de RAG divisées par les conversations correctement résolues.
• Temps économisé pour le personnel : minutes par ticket avant et après, échantillonnées plutôt que devinées.
• Signaux de revenus : pour les assistants de pré-vente, taux de conversion assisté par rapport à un groupe témoin.

Comparez le coût par requête résolue avec votre coût actuel par ticket traité par un humain. Si l’écart est faible, le projet peut toujours en valoir la peine pour la vitesse ou la couverture 24h/24, mais dites-le honnêtement dans le business case.

Trois habitudes font grimper les budgets. La première est d’indexer tout : les anciens decks de campagne, les PDF en double et les pages de brouillon ajoutent du bruit, augmentent les erreurs de récupération et augmentent le stockage. La deuxième est d’utiliser par défaut le plus grand modèle pour chaque question. La troisième est de sauter l’évaluation, de sorte que personne ne remarque qu’un changement de contenu a cassé vingt réponses jusqu’à ce que les clients se plaignent.

La mise en cache aide. De nombreux fournisseurs proposent désormais la mise en cache des prompts ou des tarifs moins chers pour le contexte répété, et les questions fréquemment posées peuvent être servies à partir d’une réponse stockée qui est actualisée selon un calendrier.