Leaders technologie··7 min de lecture

RAG en production : ce que le CTO office doit posséder vs déléguer

Le retrieval-augmented generation est une plateforme data et un modèle opérationnel, pas une étape notebook. Guide de propriété pour CTO, équipes plateforme et partenaires CX.

Résumé exécutif

  • ·Le RAG échoue en production sur la fraîcheur, le contrôle d’accès et la responsabilité, pas seulement sur le choix du modèle.
  • ·Le CTO office doit posséder le cycle de vie des index, les frontières de sécurité, l’observabilité et la gouvernance des coûts.
  • ·CX et produit définissent les corpus, les grilles qualité des réponses et l’escalade quand le système se trompe.
  • ·Les prestataires doivent recevoir des composants bornés avec passation écrite, pas « tout le programme RAG ».
  • ·Les jeux d’évaluation doivent refléter de vraies requêtes opérateurs et clients, pas seulement des FAQ marketing.
  • ·Commencez avec un corpus, une cohorte et des SLA mesurables d’hallucination et de fraîcheur avant de scaler les connecteurs.

Le problème

Les board decks traitent le retrieval-augmented generation comme une fonctionnalité modèle. En production, c’est un problème de plateforme data couvrant pipelines d’indexation, retrieval conscient de l’identité, plafonds de coût, surveillance de la dérive et escalade humaine quand les réponses affectent clients ou workflows réglementés. Les équipes qui délèguent tout le RAG à un prestataire ou une seule squad ML découvrent généralement les lacunes au go-live : index obsolètes, règles PII floues, aucun propriétaire pour les jobs de ré-embedding, et des responsables CX surpris par des réponses fausses mais confiantes.

Ce qui change entre pilote et production

Les pilotes utilisent souvent des exports statiques, un accès permissif et une revue manuelle. La production ajoute la prolifération de connecteurs, l’accès par rôle, les exigences d’audit, la rotation d’astreinte et les requêtes adverses. Le CTO office est le propriétaire naturel de ces propriétés de production, même quand CX possède la vérité client.

Parcours RAG en production
Systèmes sources
Ingestion & tiering PII
Chunk & embed
Index & ACL
Retrieve
Generate
Revue humaine
Action & log

Chaque étape a besoin d’un propriétaire et d’un SLA. La plupart des programmes sur-investissent dans Generate et sous-investissent dans Ingest, ACL et Action & log.

Carte de propriété : qui possède quoi

RACI RAG (simplifié)
EnjeuCTO officeData / plateformeCX / produitPrestataire
Cycle de vie index & ré-embedARCC
Contrôle d’accès & auditARIC
Sélection corpus & grillesCIA/RI
Observabilité & plafonds coûtARIC
Build connecteur (borné)CCCR

A = accountable, R = responsible, C = consulted, I = informed. Adaptez aux noms de votre org, mais ne laissez pas de cellules vides.

Gates de gouvernance avant le choix des outils

  1. Classer les corpus par tier de sensibilité et éligibilité à l’automatisation.
  2. Définir quels rôles peuvent retriever quelles sources, tester avec de vraies identités.
  3. Publier des grilles qualité des réponses avec CX : citation requise, déclencheurs d’escalade, sujets interdits.
  4. Fixer des SLA de fraîcheur par corpus ; mesurer le taux de retrieval obsolète chaque semaine.
  5. Instrumenter taux d’hallucination et d’abstention sur des requêtes proches de la production.
SignalPlage saine (indicative)Action si hors plage
Taux de chunks obsolètes< 5 % pour corpus réglementésCorriger les SLA pipeline avant nouveaux connecteurs
Taux d’abstentionBande stable par cohorteInvestiguer lacunes corpus ou décalage grille
Incidents fuite PII0 dans le harness de testStopper le déploiement ; corriger ACL et redaction
Coût par requête résolueDans le plafondAjuster retrieval k, cache ou routage modèle

Limites prestataires sensées

Les prestataires peuvent accélérer le développement de connecteurs, les harness d’évaluation ou l’exploitation d’index managés, si les critères de passation sont explicites. Ils ne doivent pas posséder les grilles qualité, la politique d’escalade client ou la responsabilité d’astreinte production, sauf si vous achetez délibérément un service managé en connaissant le TCO long terme.

Fausses hypothèses

  • ·Toute équipe capable de fine-tuner un modèle peut posséder retrieval et indexation en production.
  • ·La sécurité RAG repose sur la même checklist qu’une API REST générique.
  • ·Les utilisateurs métier peuvent rejoindre après le lancement pour « ajuster les prompts ».
  • ·Plus de connecteurs augmentent toujours la confiance, sans tiering, ils augmentent le risque.
  • ·Les benchmarks prestataires remplacent l’évaluation spécifique au corpus.

Checklist production du CTO office

  • Responsabilité CTO office

    Cycle de vie des index, limites prestataires, standards d’observabilité, modèle de sévérité incident et gouvernance des coûts.

  • Responsabilité data / plateforme

    Pipelines, jobs d’embedding, séparation des environnements, harness d’évaluation, backup/restore des index.

  • Responsabilité CX / produit

    Corpus source de vérité, grilles, chemins de revue humaine, workflows d’excuse et correction face client.

  • Déléguer au prestataire (borné)

    Composants nommés uniquement, ex. deux connecteurs et harness eval, avec code, runbooks et drill d’astreinte inclus dans la passation.

  • Revue de readiness production

    Drill d’astreinte, tests ACL sur identités échantillon, et fire drill de fraîcheur avant GA.

  • Règles d’arrêt

    Conditions pré-accordées pour suspendre le déploiement : incident PII, dépassement taux obsolète, ou backlog escalade CX au-delà du seuil.

Ce que je ferais

  • ·Publier un RACI d’une page et le faire signer par CX, juridique et plateforme avant le choix des outils.
  • ·Construire des jeux d’évaluation à partir de vraies requêtes clients, agents et opérateurs, inclure les cas limites.
  • ·Piloter sur un corpus avec SLA de fraîcheur et d’hallucination visibles par les exécutifs.
  • ·Implémenter des tests de retrieval conscient de l’identité comme gate de release, pas comme audit post-lancement.
  • ·Définir plafonds de coût et politique de routage (petit vs grand modèle) avec visibilité finance.
  • ·Planifier une revue mensuelle des corpus avec CX, retirer les sources qui créent des réponses fausses mais confiantes.

Points clés

  • ·Le RAG en production est un modèle opérationnel possédé principalement par le CTO office et les équipes plateforme.
  • ·CX possède la vérité client ; la technologie impose les gates techniques, les politiques parallèles échouent.
  • ·Évaluez sur de vraies requêtes et workflows, pas sur des FAQ de démo.
  • ·Ne scalez les connecteurs qu’après fraîcheur, ACL et chemins d’escalade en conditions proches de la production.
  • ·Le périmètre prestataire doit être borné avec des artefacts de passation exploitables.
  • ·Mesurez abstention, obsolescence et réponse incident, pas seulement la fluidité.

Questions fréquentes

Qui doit posséder l’index vectoriel en production ?

La plateforme ou data engineering sous responsabilité du CTO office. Ils possèdent les plannings de ré-embedding, backup, promotion d’environnement et intégration d’accès. CX possède ce qui appartient à l’index ; ils ne doivent pas lancer des jobs d’embedding ad hoc.

En quoi le RAG diffère-t-il de la recherche entreprise ?

Le RAG ajoute une synthèse générative, ce qui augmente les dégâts d’un mauvais retrieval. Vous héritez des problèmes ACL de la recherche plus de nouveaux modes d’échec : hallucination, sur-confiance et injection de prompt via documents.

Que doivent fournir les responsables CX avant de scaler le RAG ?

Listes de corpus avec tiering, grilles de réponses, exemples travaillés de bonnes et mauvaises réponses, et workflows d’escalade quand la sortie IA atteint clients ou agents.

Quand un prestataire RAG managé est-il approprié ?

Quand vous acceptez un modèle opérationnel managé, chiffrez le TCO long terme, et assignez quand même des propriétaires internes pour grilles, politique ACL et escalade client. Une propriété prestataire partielle sans gates internes échoue à l’échelle.

Quelles métriques figurent sur un dashboard exécutif ?

Fraîcheur/obsolescence, taux d’abstention, incidents par sévérité, time-to-correction, coût par requête résolue, et adoption par cohorte, aux côtés d’échantillons qualitatifs de revue CX.

Pour, Responsables CX

Intégrez propriétaires VoC et connaissance dès la semaine un à la sélection des corpus. Le CTO office peut imposer les gates techniques ; vous définissez quelles vérités client ne doivent jamais être devinées. Co-rédigez grilles et chemins d’escalade avant que les connecteurs ne se multiplient.

Perspective associée: Données VoC et IA : la gouvernance avant les modèles

More on this track

Un programme sur ce sujet ? Décrivez votre contexte, tech, expérience, ou les deux.

Parler d’un projet