RAG, agents et évaluations : rendre l’IA exploitable

La plupart des prototypes IA fonctionnent sur quelques exemples bien choisis. La difficulté commence quand le système doit traiter des données réelles, des cas incomplets, des documents ambigus et des demandes qui ne rentrent pas dans le scénario initial.

Le RAG n’est pas une recherche magique

Un pipeline RAG fiable dépend d’abord de la qualité de l’indexation. Le découpage des documents, les métadonnées, le choix du modèle d’embeddings et la stratégie de reranking influencent directement la réponse finale. Si le bon passage n’est pas récupéré, le modèle ne peut pas l’inventer proprement.

• Chunking par structure logique plutôt que par taille fixe quand le document le permet.
• Métadonnées explicites pour filtrer par source, date, client, version ou type de document.
• Hybrid search lorsque les mots exacts comptent autant que la proximité sémantique.
• Reranking sur les meilleurs candidats pour limiter le bruit transmis au modèle.

Les agents sont surtout des boucles de décision

Un agent utile n’est pas un modèle “plus autonome”. C’est une boucle qui choisit une action, appelle un outil, lit le résultat, puis décide si elle doit continuer ou s’arrêter. La qualité vient des garde-fous : permissions, limites d’itération, schémas de sortie, gestion des erreurs et journalisation.

Les appels outils doivent rester explicites. Un modèle qui peut créer un ticket, interroger une base ou envoyer un email doit travailler avec des entrées validées, des confirmations sur les actions sensibles et des messages d’erreur compréhensibles.

Évaluer avant de généraliser

Sans jeu d’évaluation, chaque changement de prompt, de modèle ou de retriever devient une décision au ressenti. Il faut des cas de test représentatifs : questions faciles, documents contradictoires, absence de réponse, formats attendus, contraintes métier.

• Mesurer la récupération : le bon contexte est-il présent dans les passages fournis ?
• Mesurer la réponse : est-elle exacte, complète et suffisamment sourcée ?
• Mesurer le format : le JSON ou la sortie structurée respecte-t-il le schéma attendu ?
• Mesurer le coût et la latence pour savoir si le système tient en usage réel.

Un système IA fiable se construit moins autour d’un prompt parfait qu’autour d’une boucle observable.

La bonne architecture dépend du risque. Un assistant interne peut tolérer plus d’incertitude qu’un outil qui modifie des données métier. Dans tous les cas, les briques techniques doivent rendre les erreurs visibles, testables et corrigibles.