Partager via


Présentation de l’évaluation et de la surveillance des applications RAG

L’évaluation et le contrôle sont des éléments essentiels pour comprendre si votre application RAG répond aux exigences de qualité, de coût et de latence dictées par votre cas d’utilisation. Techniquement, l’évaluation a lieu pendant le développement et le contrôle a lieu une fois que l’application est déployée en production, mais les composants fondamentaux sont similaires.

Le RAG sur les données non structurées est un système complexe comportant de nombreux éléments qui ont une incidence sur la qualité de l’application. L’ajustement d’un élément unique peut avoir des effets en cascade sur les autres. Par exemple, les modifications de mise en forme des données peuvent influencer les blocs récupérés et la capacité des GMLs à générer des réponses pertinentes. Il est donc essentiel d’évaluer chacun des composants de l’application en plus de l’application dans son ensemble afin de l’affiner de manière itérative sur la base de ces évaluations.

Évaluation et surveillance : ML classique et IA générative

L’évaluation et la surveillance des applications d’IA générative, y compris RAG, diffèrent du Machine Learning classique de plusieurs façons :

Sujet ML classique IA générative
Métriques Les métriques évaluent les entrées et sorties du composant, par exemple, la dérive des fonctionnalités, la précision, le rappel, la latence, etc. Étant donné qu’il n’y a qu’un seul composant, les métriques globales == les métriques de composant. Les métriques de composant évaluent les entrées et sorties de chaque composant, par exemple précision @ K, nDCG, latence, toxicité, etc. Les métriques composées évaluent l’interaction de plusieurs composants : la fidélité mesure l’adhésion du générateur aux connaissances d’un récupérateur qui nécessite l’entrée de chaîne, la sortie de chaîne et la sortie du récupérateur interne. Les métriques globales évaluent l’entrée et la sortie globales du système, par exemple, l’exactitude de la réponse et la latence.
Évaluation La réponse est de façon déterministe « bonne » ou « mauvaise ». Les métriques déterministes fonctionnent. La réponse est « bonne » ou « mauvaise », mais : • Il existe de nombreuses bonnes réponses (non déterministes). • Certaines bonnes réponses sont plus justes. Vous avez besoin de : • Commentaires humains pour être confiant. • Métriques évaluées par LLM pour mettre à l’échelle l’évaluation.

Composantes de l’évaluation et du suivi

L’évaluation et la surveillance efficaces de la qualité, du coût et de la latence des applications RAG nécessitent plusieurs composants :

  • Jeu d’évaluation : Pour évaluer rigoureusement votre application RAG, vous avez besoin d’un ensemble organisé de requêtes d’évaluation (et idéalement de sorties) représentatives de l’utilisation prévue de l’application. Ces exemples d’évaluation doivent être difficiles, diversifiés et mis à jour pour refléter la modification de l’utilisation et des exigences.
  • Définitions de métriques : Vous ne pouvez pas gérer ce que vous ne mesurez pas. Pour améliorer la qualité RAG, il est essentiel de définir ce que signifie la qualité de votre cas d’utilisation. Selon l’application, les métriques importantes peuvent inclure la précision de la réponse, la latence, le coût ou les évaluations des parties prenantes clés. Vous aurez besoin de métriques qui mesurent chaque composant, la façon dont les composants interagissent les uns avec les autres et le système global.
  • Juges GML : étant donné la nature ouverte des réponses GML, il n’est pas possible de lire chaque réponse unique chaque fois que vous évaluez pour déterminer si la sortie est correcte. L’utilisation d’un GML supplémentaire et différent pour examiner les résultats peut aider à mettre à l’échelle votre évaluation et à calculer des métriques supplémentaires telles que l’ancrage d’une réponse à des milliers de jetons de contexte, ce qui serait infaisable pour les évaluateurs humains à évaluer efficacement à l’échelle.
  • Harnais d’évaluation : Pendant le développement, un harnais d’évaluation vous permet d’exécuter rapidement votre application pour chaque enregistrement de votre jeu d’évaluation, puis d’exécuter chaque sortie par le biais de vos juges GML et des calculs de métriques. Cela est particulièrement difficile, car cette étape « bloque » votre boucle de développement interne, de sorte que la vitesse est de la plus grande importance. Un bon harnais d’évaluation parallélise ce travail autant que possible, souvent en épinglant une infrastructure supplémentaire telle que plus de capacité GML pour le faire.
  • L’interface utilisateur orientée vers l’IU : En tant que développeur, vous n’êtes pas forcément un(e) expert(e) du contenu de l’application que vous développez. Pour recueillir les commentaires d’experts humains capables d’évaluer la qualité de votre application, vous avez besoin d’une interface qui leur permette d’interagir avec l’application et de fournir des commentaires détaillés.
  • Journalisation des traces de production : Une fois en production, vous devez évaluer une quantité significativement plus élevée de requêtes/réponses et la façon dont chaque réponse a été générée. Par exemple, vous devez savoir si la cause racine d’une réponse de faible qualité est due à l’étape de récupération ou à une hallucination. Votre journalisation de production doit suivre les entrées, les sorties et les étapes intermédiaires, telles que la récupération de documents, afin d’activer la surveillance et le diagnostic précoces des problèmes qui surviennent en production.

Ces documents couvrent l’évaluation en détail dans Évaluer la qualité RAG.