Le développement RAG associe un modèle de langage à une couche de recherche gouvernée qui choisit des sources pertinentes à chaque requête, les fournit comme contexte et préserve les preuves de la réponse ou action.
Un prototype convaincant naît en quelques jours depuis un dossier et une base vectorielle. La production échoue sur d’autres questions: quelle version fait autorité, l’utilisateur peut-il voir la source, comment parser tableaux et scans, que faire des contradictions et comment savoir si une réponse est étayée plutôt que plausible?
Le RAG est un produit d’information, pas un accessoire de prompt. Qualité de recherche, gouvernance des sources, politique de réponse, interface et feedback opérationnel doivent être conçus ensemble. Le but n’est pas de répondre à tout, mais de traiter utilement le prouvable et de refuser, qualifier ou escalader le reste.
Architecture
Séparer recherche, politique de réponse et génération
La recherche détermine les preuves disponibles. La politique décide ce qui peut en être conclu. La génération transforme la conclusion permise en langage ou structure utile. Ces couches peuvent employer des modèles, mais exigent interfaces et tests séparés. Sinon, un changement de prompt modifie silencieusement droits, refus et logique métier.
Conservez une trace avec contexte utilisateur, transformation de requête, sources éligibles, passages, rangs, décision de politique, version du modèle, citations et résultat. Les données sensibles peuvent imposer masquage ou rétention limitée, mais assez d’observabilité doit permettre le diagnostic et la recherche de réponses liées.
| Couche | Question | Preuve de qualité |
|---|---|---|
| Ingestion | Contenu et structure faisant foi ont-ils survécu? | Fixtures de parsing versionnées et coordonnées |
| Recherche | La preuve autorisée a-t-elle atteint le contexte? | Questions jugées et rappel par classe de source |
| Politique | La preuve suffit-elle pour ce mode? | Labels réponse, réserve, refus et escalade |
| Génération | Chaque affirmation suit-elle les passages? | Revue affirmation-citation et tests de conflit |
| Produit | L’utilisateur accomplit-il la tâche sans risque? | Résultat, correction et signaux d’incident |
Évaluation
Créer le jeu de test avant d’optimiser la démonstration
Collectez les formes réelles de questions: fait direct, synthèse, comparaison, temps, tableau, ambiguïté, absence, conflit et contenu restreint. Chaque cas identifie la preuve à retrouver et le comportement acceptable. Une expansion synthétique augmente ensuite la couverture une fois le noyau établi par les responsables.
Rapportez les métriques par segment. Un système peut réussir sur des politiques courtes et échouer sur des annexes scannées, ou perdre des termes composés allemands. Suivez les régressions sur un set fixe et ajoutez les échecs revus de production. Ne réglez pas sur les cas qui serviront à prouver la qualité finale.
- Séparer pertinence de recherche et exactitude de réponse.
- Inclure des questions dont le bon résultat est l’absence de réponse.
- Tester chaque rôle de permission avec la même requête.
- Mesurer le support des citations par affirmation et non par page.
- Conserver un jeu de livraison tenu à part et un budget de régression.
Livraison
Choisir le partenaire sur une tranche de production
Un engagement crédible commence par une tâche bornée, des sources réelles, de vrais droits et un jeu de réception mesurable. La première tranche verticale inclut ingestion, recherche, politique, interface, évaluation et observabilité. Un chat alimenté par des documents nettoyés à la main prouve trop peu.
Demandez comment le partenaire gère suppression de source, changement de droits, réindexation, remplacement du modèle, plafond de coût et incident. Exigez code, définition d’infrastructure, données de test, runbooks et transfert. L’organisation doit remplacer un composant sans reconstruire le produit ni perdre les comparaisons.
- Choisir un domaine où les mauvaises réponses sont visibles et corrigibles.
- Fournir des documents représentatifs imparfaits plutôt qu’un dossier de démonstration.
- Définir la réception sur le résultat et le traitement des échecs.
- Exécuter une mise à jour de source et un retrait d’accès pendant le pilote.
- Exiger traces et fixtures d’évaluation exportables pour la reprise.
Ce qui caractérise un bon résultat
Résultats concrets pour développement application RAG
- Le système retrouve des passages actuels, autorisés et contextuels plutôt que seulement des chunks similaires.
- Les utilisateurs inspectent des citations menant à la version et à l’emplacement exacts qui étayent une affirmation.
- Preuves absentes, contradictoires et insuffisantes déclenchent des comportements différents.
- Les jeux de test hors ligne et retours de production relient les changements aux tâches utilisateur mesurables.
- Ingestion, index, modèle et prompt peuvent être livrés, observés et annulés indépendamment.
Modèle opératoire
Comment exécuter le travail
- 01
Cadrer la tâche et le contrat de réponse
Définissez qui pose la question, quelle décision suit, quelles sources font autorité et ce qu’une réponse utile contient. Classez les questions à répondre, refuser ou router. Fixez latence, citations, fraîcheur, confidentialité et conséquence avant de choisir modèles ou infrastructure.
- 02
Construire la chaîne sources et permissions
Inventoriez dépôts, formats, responsables, accès, signaux de mise à jour et autorité documentaire. Parsez titres, tableaux, listes et coordonnées plutôt que d’aplatir tout le texte. Transportez identité, version, validité et métadonnées d’accès dans chaque chunk et index dérivé.
- 03
Concevoir une recherche mesurable
Créez des questions représentatives avec jugements de pertinence. Comparez recherche lexicale, dense et hybride, réécriture, filtres et reranking. Adaptez les chunks aux sources et tâches. Mesurez si la preuve requise atteint le contexte, pas seulement si un passage voisin apparaît.
- 04
Générer sous une politique de preuve
Donnez au modèle question, passages autorisés, structure et règles de citation, incertitude et conflit. Reliez chaque affirmation matérielle à une source. Gardez les règles déterministes hors de la génération libre. Sans preuve, retournez une limite utile et une prochaine action au lieu de compléter.
- 05
Évaluer, livrer et exploiter le produit
Testez séparément recherche, ancrage, utilité, citations, permissions, robustesse et latence. Exécutez des cas adversariaux d’accès. Livrez derrière des interfaces observables, échantillonnez les traces sous contrôles de confidentialité et renvoyez chaque échec vers source, recherche, politique ou interface.
Évaluation
Les questions qui changent la décision
- Quelle source ou quel responsable fait autorité lorsque des documents se contredisent?
- Les permissions s’appliquent-elles avant la recherche, après ou aux deux étapes?
- Quel seuil de preuve permet une réponse directe, qualifiée ou une escalade?
- Quelles parties exigent un calcul ou workflow déterministe plutôt que la génération?
- Comment tracer versions source, embedding, retriever, reranker, prompt et modèle par réponse?
Modes d’échec
Où les équipes perdent le contrôle
Une bonne génération masque une mauvaise recherche et fait paraître étayée une réponse simplement plausible.
Des droits appliqués après le chunking peuvent divulguer des faits via index, caches ou citations.
Des chunks naïfs séparent tableaux, définitions et exceptions des clauses qui donnent leur sens.
Un score global cache si l’échec vient de la recherche, de l’ancrage, de l’utilité ou des outils.
Une ingestion automatique sans autorité ni expiration peut faire passer un brouillon avant la source approuvée.
Mesure
Mesurer le travail terminé
La mesure porte sur le processus terminé, y compris la revue et les exceptions. Le volume produit ne prouve pas à lui seul que le processus est meilleur.
- rappel de la preuve requise à la frontière du contexte pour les questions représentatives
- précision des citations et part des affirmations matérielles totalement étayées
- taux correct de refus ou escalade face aux preuves absentes et contradictoires
- violations de permissions dans les tests adversariaux
- réussite de tâche, effort de correction et acceptation par classe de question
- latence de bout en bout, coût, retard de fraîcheur et taux d’échec en production
Questions
Questions fréquentes
Que comprend le développement d’une application RAG?
Il comprend ingestion, parsing, métadonnées, permissions, index, recherche, reranking, politique, génération, citations, évaluation, interface, déploiement et suivi.
Le RAG empêche-t-il les hallucinations?
Non. Il fournit des preuves actuelles et inspectables, mais la génération peut encore mal les lire, les omettre ou les dépasser. Tests d’ancrage, politiques, citations et escalade restent nécessaires.
Quand construire une application RAG?
Lorsque la tâche dépend de connaissances privées ou changeantes récupérables à la requête. Si la tâche est déterministe, sans sources gouvernées ou sans tolérance à l’incertitude, une autre architecture peut mieux convenir.
Quelle différence entre RAG entreprise et prototype chatbot?
Le RAG entreprise maintient autorité des sources, permissions, fraîcheur, évaluation, observabilité, erreurs et propriété dans le temps. Un prototype montre souvent seulement recherche et génération sur un échantillon propre.
Sources
Sources primaires
À propos de l’auteur
Tony Kim
Tony écrit sur l’IA appliquée, l’ingénierie produit fiable et les systèmes qui transforment les réponses complexes en exécution maîtrisée.
Zeke
Ingénierie de produits IA pour transformer un cahier des charges en produit fiable en production.
Directions produit, fondateurs et équipes d’ingénierie. Le point de départ est le processus existant, ses contraintes et les preuves déjà disponibles.
Découvrir Zeke→