Ces approches concernent différentes parties d'un système. Elles ne sont pas interchangeables, et une application utile peut les combiner avec des règles logicielles classiques.
Avant de choisir, identifier ce qui bloque : accès à l'information, format de sortie, exécution de tâches ou application environnante.
Accéder à des informations actuelles
Une approche fondée sur la recherche retrouve des éléments dans un corpus autorisé et les fournit au modèle. Elle peut convenir aux questions documentaires, aux politiques internes ou aux connaissances produit.
Le travail comprend la préparation des sources, les permissions, les mises à jour et l'évaluation de la réponse par rapport aux éléments retrouvés. Ajouter de la recherche ne prouve pas à lui seul l'exactitude ni le respect des accès.
Obtenir un comportement ou un format récurrent
Commencer par des instructions claires, des exemples et des validations. Si cela ne suffit pas, une adaptation ou un fine-tuning peut être évalué sur un jeu de données convenu.
La décision doit suivre une amélioration mesurable de la tâche, pas l'idée qu'un modèle entraîné sur mesure serait toujours supérieur. Séparer les exemples d'entraînement et d'évaluation pour apprécier la généralisation.
Le fine-tuning ne remplace ni une source vivante pour des faits changeants ni les contrôles d'accès applicatifs.
Produire des informations structurées
La bonne conception peut associer un schéma, une extraction, des validations et un écran de revue. Un assistant conversationnel n'est pas nécessaire simplement parce que l'entrée est un document.
Définir les champs pouvant être déduits, ceux exigeant une source directe et ceux restant vides si rien ne les étaye. Les contraintes de la destination déterminent la sortie, pas les préférences de formulation du modèle.
Enchaîner des actions
Cartographier le processus et distinguer transitions fixes et étapes d'interprétation. Une file de tâches classique et quelques appels de modèles peuvent mieux convenir qu'un agent ouvert.
Lorsqu'un agent choisit des outils ou propose des actions, préciser ses permissions, ses conditions d'arrêt, ses validations et sa reprise sur erreur. Le logiciel autour du modèle reste nécessaire.
Comparer sur la même tâche
Préparer des exemples représentatifs, les critères d'acceptation et les échecs pertinents. Comparer qualité, effort de revue, latence, coût et complexité de réalisation.
Une architecture complexe ne mérite pas d'être acceptée parce qu'elle comporte davantage de composants. À l'inverse, une démonstration simple plus rapide sur un exemple propre ne justifie pas de supprimer les contrôles nécessaires.
Une question de départ
Compléter : « L'utilisateur doit transformer cette entrée en ce résultat accepté, avec ces sources et ces permissions. »
Cette phrase constitue une meilleure base d'architecture que « il nous faut du RAG » ou « nous voulons un agent autonome ».
Parler de l'architecture · Assistants de connaissances · Automatisation