Évaluer la qualité des sorties de LLM en production

En mars 2023, GPT-4 identifiait les nombres premiers avec une précision de 97,6 %. En juin 2023, ce même modèle était tombé à 2,4 % de précision. Personne n'a modifié le code. Personne n'a modifié le prompt. Le modèle a simplement dérivé.

C'est le problème fondamental des LLM en production. Vous ne contrôlez pas le modèle. C'est une dépendance qui dérive. Si vous ne la mesurez pas, vos utilisateurs vous diront qu'il est cassé.

Vous ne pouvez pas vous fier à votre intuition ou au « ça me semble correct ». Vous avez besoin de signaux reproductibles.

Le logiciel traditionnel est déterministe. Une même entrée produit la même sortie. Les LLM brisent cette règle. Ils sont non déterministes et la notion de « correct » est souvent floue.

Pour gérer cela, vous avez besoin de trois couches d'évaluation :

  • Évaluations hors ligne (offline evals) : Exécutez un ensemble de tests fixes à chaque modification pour détecter les régressions.
  • Vérifications sans référence (reference-free checks) : Utilisez des signaux tels que la détection d'hallucinations lorsque vous n'avez pas de « bonne » réponse.
  • Surveillance en production : Surveillez le trafic réel pour détecter la dérive et les baisses de qualité.

La base est un Golden Dataset. N'utilisez pas d'échantillons aléatoires. Utilisez un ensemble de cas difficiles soigneusement sélectionnés. Utilisez les entrées vides, les cas limites (edge cases) étranges et les prompts adverses. 80 exemples précis valent mieux que 8 000 exemples aléatoires.

Lorsque vous utilisez un LLM comme juge, surveillez ces biais :

  • Biais de position : Les juges favorisent souvent la première réponse qu'ils voient. Corrigez cela en effectuant des comparaisons dans les deux ordres.
  • Biais de verbosité : Les juges récompensent les réponses plus longues, même si elles sont moins claires.
  • Biais d'auto-valorisation (self-enhancement bias) : Les modèles préfèrent le texte issu de leur propre famille. Utilisez différentes familles de modèles pour juger les sorties.

Pour une surveillance en temps réel, utilisez la RAG Triad pour vérifier :

  • Fidélité (Faithfulness) : La réponse respecte-t-elle le contexte ?
  • Pertinence de la réponse : Répond-elle à la question ?
  • Pertinence du contexte : Le système a-t-il récupéré les bons documents ?

Cessez de considérer la qualité du modèle comme une propriété fixe. Traitez-la comme la latence ou les taux d'erreur. Elle évolue. Votre travail est de remarquer quand elle cesse d'être satisfaisante.

Commencez petit. Rédigez 20 exemples « golden ». Utilisez-les pour valider vos déploiements. Ajoutez des heuristiques de production peu coûteuses plus tard.

Les équipes qui dorment bien ne sont pas celles qui possèdent les modèles les plus intelligents. Ce sont celles qui savent, en moins d'une heure, si leur modèle devient moins performant.

Source: https://dev.to/nazar_boyko/evaluating-llm-output-quality-in-production-39an

Communauté d'apprentissage optionnelle: https://t.me/GyaanSetuAi