Évaluer les réponses d'un système RAG

Vous avez modifié le découpage, changé de modèle de plongement et ajouté un reclasseur. Le système semble meilleur. Un utilisateur signale une régression sur une question qui fonctionnait la semaine dernière. Vous ne pouvez ni le confirmer ni l'infirmer, parce que votre seule méthode de validation consiste à taper quatre questions que vous connaissez par cœur et à trouver les réponses satisfaisantes. Vous ne savez pas laquelle de vos trois modifications a aidé, ni laquelle a nui, ni si la moyenne s'est améliorée.

C'est la situation par défaut de presque tous les projets RAG, et c'est ce qui les fait stagner. Un système RAG a deux étages qui échouent pour des raisons différentes et se réparent par des moyens différents : la récupération et la génération. Une métrique globale unique les mélange, donc elle ne vous dit jamais quoi corriger. La discipline minimale consiste à mesurer les deux séparément, sur un jeu de questions figé, avant chaque changement.

Construire le jeu de référence

Visez 50 à 150 questions. En dessous de 40, le bruit statistique dépasse les écarts que vous cherchez à mesurer. Au-delà de 200, le coût d'annotation devient dissuasif sans gain proportionnel.