Tensoria
FR EN
Parler de votre projet
Parlez-nous de votre projet : 07 82 80 51 40
Mise en production : évaluer, fiabiliser, déployer

Audit RAG et agents IA : évaluer, corriger, mettre en production

Expert RAG, LLM et NLP pour PME et ETI

Un audit RAG commence par mesurer votre système sur un jeu de questions réelles, avant toute correction. On isole ensuite la cause des mauvaises réponses ou des coûts qui dérivent, on corrige un point à la fois et on vérifie le gain sur la même baseline. Tensoria, agence IA basée à Toulouse, audite, corrige et met en production des RAG et des agents IA pour les PME et ETI.

Présenter votre système Recevoir un devis
RAG Agents IA LLM et NLP AWS, cloud français ou on-premise Sur devis

Deux points de départ

Corriger un système qui déçoit, ou le mettre en production

Cette expertise commence quand le cas d'usage est choisi et qu'un RAG, un agent ou un prototype existe déjà. La suite dépend de ce qui vous amène.

01

Audit puis correction

Votre RAG ou votre agent répond mal, ou coûte trop

  • Réponses imprécises. Incomplètes, appuyées sur de mauvaises sources, ou inventées.
  • Agent instable. Il boucle, choisit le mauvais outil ou ne termine pas certains parcours.
  • Coût ou latence qui dérivent. La facture API grimpe plus vite que l'usage, les utilisateurs attendent.
  • Sorties structurées fragiles. Le JSON, l'extraction ou la classification ne respectent pas toujours le format.
  • Aucune mesure. La qualité repose sur quelques démonstrations, personne ne sait si la dernière modification a amélioré ou dégradé le système.
Voir comment on évalue et on corrige →
02

Mise en production

Vous voulez le mettre en production proprement

  • Un prototype qui marche en démo. Il reste l'évaluation, les erreurs, les intégrations et le suivi.
  • Un hébergement à choisir. AWS ou Azure en région Europe, cloud français, serveurs internes ou déploiement souverain.
  • Des sources qui bougent. Documents ajoutés, modifiés ou retirés chaque semaine, droits d'accès à respecter.
  • Des données sensibles. Le modèle, l'index et les journaux doivent rester dans un périmètre défini.
  • Une équipe qui devra l'exploiter. Code, infrastructure et documentation doivent lui revenir.
Voir comment on déploie et on maintient →

Évaluer

Évaluation RAG : une baseline avant toute correction

Évaluer un RAG, c'est rejouer un jeu de questions de référence et noter séparément la recherche documentaire et la réponse. Sans cette mesure de départ, changer de modèle, augmenter le nombre de passages ou réécrire le prompt reste une intuition.

Les questions viennent de vos journaux, de vos tickets ou des premiers testeurs, jamais d'une réunion. Un jeu de 30 à 50 questions réelles suffit pour démarrer, 100 à 150 pour suivre les régressions dans la durée.

Un modèle juge accélère la notation, à condition de le calibrer sur un échantillon noté à la main. Des outils open source comme Ragas automatisent une partie des métriques. La méthode complète est détaillée dans notre article sur la baseline d'évaluation RAG.

Ce qu'on mesure La question posée Exemples de métriques
Recherche (retrieval) Le bon passage est-il retrouvé ? Part des questions dont le passage attendu figure dans les k premiers résultats, rang du premier bon passage
Génération La réponse est-elle juste et fidèle aux sources ? Exactitude contre la réponse de référence, fidélité aux passages cités, abstention correcte quand l'information n'existe pas
Agent La tâche est-elle menée au bout ? Taux de réussite métier, nombre d'étapes, appels d'outils en échec
Exploitation À quel prix et en combien de temps ? Coût par question ou par tâche, latence médiane et au 95e centile

Séparer avant de corriger

Si le bon passage n'est pas retrouvé, aucun prompt ne sauvera la réponse. Si le passage est là et que la réponse est fausse, le problème est en aval. Cette séparation évite de corriger le mauvais étage. Le diagnostic pas à pas est dans mon RAG répond à côté.

Améliorer

Améliorer un RAG : un changement à la fois, mesuré

Chaque correction est comparée à la baseline. Elle n'est gardée que si elle améliore une métrique utile sans trop déplacer le coût, la latence ou le risque. On commence par les causes les plus fréquentes et les moins chères à tester.

Chunking et métadonnées

Découpage qui suit la structure du document, taille des passages, métadonnées de filtrage : date, version, produit, droits d'accès.

Recherche hybride et reranking

La recherche lexicale BM25 retrouve les références, codes et termes exacts que la recherche vectorielle rate. Un reranker réordonne ensuite les meilleurs candidats.

Prompts, citations et abstention

Consignes de réponse, citation des sources, « je ne sais pas » plutôt qu'une réponse inventée, sorties structurées validées par un schéma.

Modèle, NLP et fine-tuning

Comparaison de LLM et de SLM sur vos questions, modèle NLP dédié pour la classification ou l'extraction de données de documents, fine-tuning quand le problème porte sur le format ou le vocabulaire plutôt que sur une connaissance manquante.

Le fine-tuning n'est pas un diagnostic

Un mauvais résultat peut venir du corpus, du découpage, du retrieval, du prompt, du modèle, des outils de l'agent ou de la méthode d'évaluation. On teste le point le plus plausible au lieu de présupposer la solution. Pour trancher entre les trois approches : fine-tuning, RAG ou prompting, quand choisir quoi.

Ce que disent les mesures

Chez Continental, l'ajout de BM25 à la recherche sémantique a fait passer la précision des réponses de 67 % à 89 %. En septembre 2024, Anthropic a mesuré une baisse de 49 % des échecs de récupération en combinant embeddings contextuels et BM25, et de 67 % avec un reranking, sur ses propres jeux de test. Le détail des optimisations : optimiser un RAG.

Fiabiliser

Fiabiliser un agent IA : trajectoire, coût, garde-fous

Un agent IA qui boucle, dérape ou dont la facture API triple a rarement un problème d'intelligence du modèle. Les causes habituelles sont structurelles : pas de condition d'arrêt, contexte renvoyé en entier à chaque tour, permissions trop larges.

Quand tout se cumule, l'ordre est fixe : couper le risque d'action d'abord, plafonner la trajectoire ensuite, optimiser le coût en dernier. Le protocole est dans notre article sur l'agent IA qui boucle ou dérape.

Pour concevoir un agent de zéro plutôt que reprendre l'existant, voir nos agents IA sur mesure.

Trajectoire

Boucles et état

Condition d'arrêt explicite, plafond d'itérations, détection des appels répétés, état propagé correctement entre les tours.

Coût

Budget par tâche

Plafond par exécution, cache de prompt, contexte résumé plutôt que renvoyé, modèle plus petit sur les étapes simples.

Garde-fous

Permissions et validation

Droits minimaux par outil, validation humaine avant toute action irréversible, sorties validées par un schéma, secrets hors de portée de l'agent.

Observabilité

Traces et alertes

Trace de chaque appel au modèle et à chaque outil (Langfuse, LangSmith ou Phoenix), coût et latence par étape, alerte quand une exécution sort de son budget.

Déployer et maintenir

RAG en production : déployer et maintenir

Un RAG en production tient quand ses sources restent synchronisées, que chaque utilisateur ne retrouve que les documents auxquels il a droit, et que la qualité est mesurée après chaque changement. L'hébergement se choisit selon la sensibilité des données, pas par principe.

Cloud public en région Europe

AWS, Azure ou Google Cloud, régions Paris ou Francfort. Mise en place rapide, services managés, contrat RGPD.

Cloud français

Modèle ouvert servi chez un hébergeur français, sans exploiter soi-même le matériel.

Sur vos serveurs

Modèle servi par vLLM ou Ollama, base vectorielle et journaux dans votre réseau, avec les GPU à exploiter.

Souverain

Quand aucune donnée ne doit sortir d'un périmètre européen maîtrisé. Voir notre offre d'IA souveraine.

Synchronisation des sources

Ingestion incrémentale depuis SharePoint, la GED ou un serveur de fichiers. Un document modifié est réindexé, un document retiré sort de l'index, les droits d'accès de la source sont repris dans la recherche.

Évaluation continue

Le jeu de référence est rejoué à chaque changement de modèle, de prompt ou de corpus. Les questions sans réponse et les retours négatifs alimentent le jeu suivant.

Observabilité

Journal des questions, des passages retrouvés et des réponses, coût et latence, charge GPU quand le modèle est auto-hébergé.

Passation

Code et infrastructure dans vos dépôts et vos comptes, déploiement reproductible, documentation d'exploitation. Votre équipe peut reprendre la main, ou nous confier le maintien.

Pour construire un assistant documentaire de zéro, voir notre assistant IA interne RAG. Pour les fondamentaux, le guide du RAG en entreprise.

Méthode et livrables

Audit, correction, mise en production : ce que vous recevez

Trois formats qui s'enchaînent ou se prennent séparément. Chacun est sur devis, avec une durée et des livrables écrits avant le démarrage.

01

Format court, sur devis

Audit technique

Cadrage, baseline, analyse des causes, restitution.

  • Reproduction des échecs signalés
  • Jeu de questions ou de scénarios de référence
  • Baseline chiffrée : qualité, coût, latence
  • Taxonomie des erreurs avec exemples reproductibles
  • Revue d'architecture, sécurité et permissions
  • Roadmap priorisée, effort et critère d'acceptation par action
02

Blocs de cinq ou dix jours

Sprint de correction

Itérations bornées sur les corrections retenues, avec ou sans votre équipe.

  • Corrections livrées dans votre dépôt
  • Rapport avant et après sur la même baseline
  • Comparaison de modèles, de réglages de recherche ou de prompts
  • Jeu d'évaluation réutilisable pour la non-régression
03

Sur devis selon l'hébergement

Mise en production et maintien

Déploiement sur l'infrastructure retenue, puis suivi ou passation.

  • Déploiement reproductible, configuration versionnée
  • Synchronisation des sources et droits d'accès
  • Traces, tableaux de suivi et alertes
  • Documentation d'exploitation et passation

Accès et confidentialité

Un accès direct à la production n'est pas obligatoire. L'analyse peut s'appuyer sur un environnement isolé, des exports de configuration et des traces anonymisées. Le périmètre d'accès est défini avant le démarrage.

Qui intervient

L'audit est mené par Anas Rabhi, ingénieur IA et data scientist, fondateur de Tensoria, qui conçoit des systèmes RAG, agents et NLP en production depuis plus de six ans.

Cas clients

Des systèmes mesurés en conditions réelles

Des RAG et des briques IA que nous avons construits ou améliorés avec la même méthode : une mesure de départ, un changement, une nouvelle mesure.

Continental

Assistant RAG industriel

De 67 % de réponses correctes avec la recherche sémantique seule à 89 % avec la recherche hybride BM25, sur 15 000 documents, pour plus de 2 000 utilisateurs en usine.

Voir le cas client →

Éditeur de logiciel médical

RAG de support intégré au produit

Documentation et vidéos transcrites dans Qdrant hébergé en Europe, recherche hybride BM25 fusionnée par Reciprocal Rank Fusion, LLM hébergés en Europe sur AWS. Résultat : 50 % de tickets support en moins.

Voir le cas client →

Reezet

Sorties structurées et mémoire conversationnelle

Une brique IA produit avec schémas Pydantic, abstention, recommandations vectorielles et boucle d'évaluation qualitative.

Voir le cas client →

Commencer par vous-même

Les premières vérifications, sans nous

Une partie des symptômes se diagnostique en interne. Ces guides détaillent la méthode que nous appliquons, pour savoir où vous en êtes avant même de nous parler.

Qualité des réponses

Améliorer un RAG, dans quel ordre

Les bugs d'abord, puis la lecture des documents, le découpage et la recherche. Et pourquoi un gain de trois points ne justifie pas toujours un assistant plus lent.

Projet RAG

Les erreurs qui font échouer un RAG

Attentes irréalistes, données mal préparées, absence d'indicateurs : les causes d'échec vues le plus souvent.

Trajectoires et coûts

Mon agent boucle ou dérape

Les trois familles de dérapage, ce qu'il faut instrumenter pour chacune et dans quel ordre les traiter.

Mesure

Mesurer la performance de votre RAG

La première question que nous posons en mission, ce que montre la première mesure, et ce qu'il faut demander à votre équipe ou à votre prestataire.

Reprise

Reprendre un projet livré par un autre

Sécuriser les accès, inventorier l'existant, puis trancher entre réparer et réécrire.

Passage à l'échelle

Du prototype à la production

L'écart réel entre une démo qui passe et un système sur lequel l'entreprise peut s'appuyer.

Priorités encore ouvertes

Audit IA opérationnel

Comparer plusieurs opportunités, leur faisabilité et leur ROI avant de développer.

Faire monter l'équipe

Formation RAG avancée

Réutiliser les constats de l'audit dans un parcours technique de quatre jours.

Faire monter l'équipe

Formation Agents IA avancée

Travailler résilience, permissions, évaluation et observabilité.

Questions fréquentes sur l'audit RAG et agents IA

Un audit RAG mesure un système de recherche documentaire augmentée par IA sur un jeu de questions réelles, isole la cause des mauvaises réponses (données, découpage, recherche, génération) et priorise les corrections avec un critère de réussite pour chacune. Il porte sur un système qui existe déjà, en prototype ou en production.
L'audit IA opérationnel compare des opportunités et leur ROI avant de développer. L'audit RAG et agents IA analyse un système déjà conçu ou déployé pour identifier les causes d'erreur, les risques et les corrections prioritaires.
Non. Un prototype peut être audité, à condition de pouvoir reproduire le problème et d'accéder à des exemples représentatifs, au code ou à une documentation technique suffisante.
Non. L'audit peut être mené sur un environnement isolé, des configurations exportées, des jeux de tests et des traces anonymisées. Pour commencer, il faut des exemples d'échecs et de réussites, l'architecture connue, les métriques disponibles et les contraintes d'hébergement ou de confidentialité. Les accès sont définis avant le démarrage.
Un premier jeu de 30 à 50 questions réelles, couvrant les principales catégories de demandes, suffit à révéler les problèmes structurels et à comparer deux versions du système. Pour suivre les régressions dans la durée, 100 à 150 questions annotées donnent une base plus solide.
Rarement en premier. La cause peut venir des données, du découpage, du retrieval, du prompt, du modèle, des outils de l'agent ou de l'absence d'évaluation. Le fine-tuning n'est testé que lorsqu'il répond à une hypothèse mesurable, après les corrections moins coûteuses.
Oui. On commence par sécuriser les accès et inventorier le code, les données et l'infrastructure, puis la baseline indique s'il vaut mieux corriger l'existant ou réécrire une partie du système.
Il est établi sur devis, après un premier échange gratuit qui vérifie les symptômes, les données disponibles et le périmètre. Le devis précise la durée, les livrables et les accès nécessaires. Il dépend surtout du nombre de scénarios à évaluer, du nombre de sources et du fait qu'il s'agisse d'un RAG, d'un agent ou des deux.
Non. Les livrables, le jeu d'évaluation et les recommandations sont utilisables par votre équipe ou par un autre prestataire. Si vous souhaitez un appui, nous pouvons aussi travailler avec votre équipe technique, en sprint au forfait ou en blocs de cinq ou dix jours.

Un problème reproductible se corrige

Présentez votre système, quelques exemples d'échec et la métrique à améliorer. Le premier échange sert à vérifier les symptômes, les données disponibles et le périmètre utile avant tout devis.

Échanger avec un ingénieur IA Recevoir un devis écrit