Un système RAG est un produit de données, pas une requête.

La génération augmentée par récupération est souvent présentée comme un patron de requête : trouver des passages pertinents, les placer dans le contexte du modèle et demander une réponse. Cette description est reconnaissable sur le plan technique, mais incomplète sur le plan opérationnel. En production, la requête est la dernière étape d'un parcours de données gouverné.

Le système doit décider quelles sources sont admissibles, comment les documents sont segmentés, quelles métadonnées les accompagnent, quels droits s'appliquent au moment de la recherche, quels passages sont retenus, comment les affirmations se rattachent aux preuves et ce qui sera consigné. Ces décisions déterminent si la réponse est utile, traçable et appropriée pour l'utilisateur.

Pourquoi le modèle ne constitue pas tout le système

Le NIST AI Risk Management Framework demande d'évaluer les systèmes et leurs composants dans des conditions semblables au déploiement, de documenter les résultats et de les suivre en production. Le profil NIST sur l'IA générative traite l'ancrage et la récupération comme des contrôles qui doivent eux-mêmes être gouvernés, mesurés et réévalués, notamment lorsque des ressources tierces changent.

La récupération peut échouer alors que le langage demeure fluide. Le système peut choisir la mauvaise version, omettre le passage décisif, exposer du contenu interdit à l'utilisateur ou citer une preuve qui ne soutient pas l'affirmation. Un tableau de bord limité à la qualité du modèle ne montrera pas ces défaillances.

Cinq décisions de conception pour une plateforme RAG gouvernée

1. Définir l'admissibilité des sources

Ne partez pas de tout ce qui peut être indexé, mais de ce qui peut servir un objectif nommé. Attribuez à chaque collection un propriétaire, une finalité, un statut d'autorité, une classification et une date de révision. Excluez les brouillons, doublons et documents aux droits incertains, sauf permission explicite du cas d'usage.

2. Transmettre l'identité jusqu'à la récupération

L'autorisation doit être appliquée avant que les passages entrent dans le contexte du modèle. Un utilisateur qui ne peut ouvrir le document source ne doit pas en recevoir le contenu dans une réponse générée. Conservez les droits lors de l'ingestion, testez-les à la récupération et prévoyez le retrait des contenus lorsque les permissions changent.

3. Préserver la provenance et la version

Chaque passage récupéré doit conserver un identifiant stable, une version ou date d'effet, sa collection, son propriétaire et sa classification. Les citations ne sont pas décoratives. Elles permettent à l'utilisateur, à l'exploitant ou au réviseur de vérifier pourquoi le système affirme quelque chose et si la source était à jour.

4. Évaluer séparément récupération et génération

Une réponse peut être fausse parce que la bonne preuve n'a pas été retrouvée ou parce que le modèle a mal utilisé une bonne preuve. Mesurez ces couches séparément. Pour un jeu de questions représentatif, vérifiez d'abord si les passages nécessaires sont récupérés, puis si la réponse est soutenue, complète et correctement nuancée.

5. Traiter chaque changement comme une mise en production

Un nouveau modèle de plongement, une règle de segmentation, un reclasseur, une collection ou une correspondance de droits peut changer le comportement sans modifier l'interface. Consignez ces dépendances, nommez l'approbateur et rejouez l'évaluation pertinente avant la mise en production. Après le lancement, suivez les échecs de récupération et de citation, pas seulement la latence.

Les preuves minimales avant la mise en production

Ce que la direction devrait demander

• Qui peut autoriser une collection pour ce cas d'usage?
• Un utilisateur peut-il recevoir un contenu qu'il ne peut ouvrir dans le système source?
• Pouvons-nous reconstruire la version qui soutenait une réponse importante?
• Savons-nous si l'échec vient de la récupération ou de la génération?

Si ces réponses sont floues, l'architecture n'est pas terminée. Le travail manquant se trouve dans le produit de données autour du modèle.

Si le parcours des sources, des permissions, de l'évaluation ou des versions demeure flou, la pratique d'architecture de plateforme RAG sert à le rendre explicite.

Sources et portée

Références principales : NIST AI RMF Core, notamment Measure 2 et Measure 3; NIST AI 600-1, profil sur l'IA générative; et le NIST Research Data Framework pour la provenance et l'adéquation à l'usage. Cet article présente des orientations générales d'architecture. Les contrôles doivent être adaptés aux informations, aux utilisateurs et aux décisions visées.