AutoRAG en entreprise: mesurer qualité, coût et gouvernance
Red Hat propose de traiter l’optimisation d’un RAG comme une discipline mesurable plutôt que comme une suite de réglages intuitifs. Pour les organisations belges et françaises, l’intérêt réside autant dans les preuves produites que dans la technologie: qualité de récupération, fidélité des réponses, coût, droits d’accès et dérive documentaire doivent être suivis ensemble.
1. Une architecture en trois pipelines
Dans sa publication du 22 septembre, Red Hat distingue l’indexation, la récupération en temps réel et la maintenance continue. L’indexation transforme les documents, conserve leur structure, les découpe et produit les embeddings. La récupération combine recherche hybride, reranking, contrôle d’accès, construction du prompt et génération. La maintenance traite mises à jour, suppressions, demandes d’effacement, réindexation et dérive du corpus.
Cette séparation répond à un problème fréquent: élargir aveuglément les morceaux récupérés ou le contexte peut augmenter latence, mémoire GPU et coût sans améliorer la réponse. AutoRAG, proposé dans OpenShift AI 3.5, automatise l’essai de combinaisons de parsing, découpage, embeddings, recherche, reranking et modèles afin de comparer qualité, coût et latence.
2. Ce que cela change pour une entreprise belge ou française
Une PME ou une ETI peut remplacer les validations informelles par un jeu de questions représentatives, des réponses attendues et des seuils avant mise en production. Une grande entreprise ou une administration peut imposer le même protocole aux différents métiers et fournisseurs, puis conserver les configurations, scores et décisions comme éléments de preuve. L’annonce ne dispense toutefois ni d’une analyse de risques, ni d’un contrôle des données et sous-traitants.
Pour un assistant connecté à Odoo, le corpus doit refléter les droits réels: un utilisateur ne devrait pas récupérer un contrat, une facture ou une fiche RH qu’il ne peut pas ouvrir dans l’ERP. Le test doit donc mesurer non seulement la justesse, mais aussi l’absence de fuite inter-sociétés, la fraîcheur des données et le comportement lorsque les sources se contredisent.
3. Analyse Underside: aucune métrique ne suffit seule
Red Hat distingue la correction du contexte récupéré, la fidélité de la réponse à ce contexte et la correction finale. Cette distinction est essentielle: un modèle peut répondre fidèlement à des passages qui ne contiennent pas les bons faits. Un bon score de fidélité ne prouve donc pas la qualité globale. Les jeux de test doivent couvrir les échecs critiques, les cas multilingues français-néerlandais-anglais et les documents complexes propres aux opérations belges ou françaises.
L’usage d’un LLM comme juge ajoute une autre dépendance. Il faut versionner ce juge, surveiller sa dérive et faire valider humainement un échantillon. Pour une IA locale, privée ou hybride, la souveraineté se mesure aussi par la localisation du vector store et des journaux, la maîtrise des clés, l’export des résultats, la portabilité des modèles et la capacité à reconstruire l’index.
4. Un cycle de gouvernance exploitable
Commencez par identifier les décisions que le système peut influencer et les erreurs inacceptables. Construisez un jeu d’évaluation à partir de cas métier, avec sources et réponses vérifiables. Comparez les configurations sous contraintes de précision, latence et coût; testez séparément les droits et les suppressions. Versionnez ensuite corpus, parseur, embeddings, modèle, prompts et seuils. Toute modification importante d’un document, d’un modèle ou d’une permission doit déclencher une réévaluation ciblée.
Priorité concrète: avant un pilote RAG relié à Odoo ou à une base documentaire, définissez un jeu de référence, trois métriques complémentaires, un budget de latence et de coût, puis un événement clair de réindexation et de réévaluation.
Cadrer un RAG gouverné