RAG, agents ou logiciel classique : choisir l’architecture selon le processus

Partir du processus et du coût de l’erreur

Décrivez le travail par étapes observables : déclencheur, entrées, décisions, systèmes consultés, actions, approbations humaines, sorties et exceptions. Marquez ensuite les étapes entièrement spécifiables et celles qui exigent l’interprétation d’information non structurée.

Un calcul, une permission, une règle d’acheminement, une transition d’état ou un seuil de conformité devrait normalement rester déterministe. L’interprétation linguistique peut aider à résumer, classer, rédiger ou expliquer. Le coût d’une mauvaise réponse détermine le niveau de validation et de contrôle humain.

Employer un logiciel classique lorsque la règle peut être connue

Le code déterministe est le meilleur choix lorsque les entrées et les résultats peuvent être spécifiés, que la répétabilité exacte compte ou qu’une erreur causerait un dommage important. Il est plus facile à tester, surveiller, comprendre et auditer.

« Classique » ne signifie pas simpliste. Une bonne recherche, des filtres, des formulaires structurés, un moteur de processus, de la validation et des intégrations résolvent souvent mieux le problème. L’IA peut soutenir une étape non structurée sans gouverner tout le système.

• Calculs et règles d’admissibilité
• Identité, permissions et isolation des espaces
• Validation de schémas et règles d’affaires
• Machines à états et chemins d’approbation connus
• Transformation exacte de données et opérations financières

Employer la recherche lorsque la personne a besoin des sources

La recherche par mots-clés, métadonnées ou sens peut suffire si la personne peut consulter le document original. Elle préserve la matière source et évite une réponse générée qui pourrait omettre une nuance.

Améliorez la structure du contenu, les permissions, les métadonnées, l’index et l’interface des résultats avant de supposer qu’un robot conversationnel est nécessaire. La qualité de la récupération restera essentielle si la génération est ajoutée plus tard.

Employer le RAG lorsque la réponse dépend d’un savoir contrôlé et changeant

La génération augmentée par récupération est pertinente lorsqu’une personne a besoin d’une synthèse ancrée dans un corpus approuvé qui évolue plus souvent qu’un modèle ne devrait être réentraîné. Le système récupère des sources puis les fournit au modèle comme contexte.

Le RAG ne garantit pas la vérité. Contrôles d’accès, découpage, indexation, fraîcheur, classement, assemblage du contexte, citations et évaluations déterminent la confiance. Testez la récupération séparément de la génération. S’il n’existe pas de source adéquate, un refus ou des résultats de recherche peuvent être préférables.

Employer des outils lorsque le système doit agir sur un état externe

Un modèle peut choisir parmi des outils étroitement définis pour lire une fiche, préparer un billet, interroger un service ou proposer une action. L’application — et non le modèle — doit appliquer l’authentification, l’autorisation, les schémas, les règles, l’idempotence et la journalisation.

Séparez la préparation de l’exécution. Le système peut proposer une action importante, montrer ce qui changera puis demander une confirmation humaine. Accordez le minimum de permissions et de données nécessaires.

Employer des agents seulement si la planification variable vaut son coût

Un agent choisit ou répète des actions selon les résultats intermédiaires. Cette souplesse peut servir à une recherche ouverte, une coordination entre systèmes ou une tâche dont la séquence ne peut être connue d’avance. Elle multiplie aussi les états, les coûts, la latence et les modes d’échec.

Vérifiez d’abord si un processus fixe avec une ou deux décisions de modèle suffit. Si l’autonomie reste justifiée, limitez l’objectif, les actions, le nombre d’itérations, le temps, le budget et les données. Rendez le progrès inspectable et définissez les conditions d’arrêt ou d’escalade.

Les systèmes de production combinent souvent plusieurs approches

Une architecture fiable peut utiliser des permissions et états déterministes, la recherche pour trouver les sources, le RAG pour expliquer, un appel de modèle pour classer une exception, un outil pour préparer un changement et une personne pour l’approuver. L’enjeu n’est pas de choisir l’étiquette gagnante, mais de décider ce qui peut être variable et ce qui doit rester exact.

Gardez chaque limite testable : ensemble récupéré, sortie du modèle, choix d’outil, validation de l’action et réussite de bout en bout. « L’IA a échoué » devient alors un problème d’ingénierie qu’on peut diagnostiquer.

Une séquence de décision compacte

Choisissez la solution la plus simple qui respecte le processus et le risque. La complexité doit produire un avantage observable.

• Des règles explicites peuvent-elles résoudre l’étape? Utilisez un logiciel déterministe.
• La personne doit-elle retrouver la matière originale? Améliorez la recherche.
• La réponse doit-elle synthétiser un corpus contrôlé? Envisagez le RAG.
• Le système doit-il lire ou modifier un autre système? Ajoutez des outils étroits et validés.
• Doit-il choisir une séquence variable? Envisagez une autonomie bornée.
• Une erreur pourrait-elle causer un tort important? Renforcez la validation, l’approbation humaine ou retirez l’autonomie.