Évaluation des LLM
Le processus d'évaluation de la qualité des réponses d'un LLM. Deux familles : les benchmarks (MMLU, GPQA, SWE-bench — jeux de données fixes) et les evals de production (spécifiques au trafic réel, souvent LLM-as-judge). Discipline standard en ingénierie ML depuis 2024.
Outils : OpenAI Evals, LangSmith, Braintrust, Helicone, Phoenix (Arize). Catégories : exactitude factuelle, taux d'hallucination, conformité au format, sécurité, latence, coût. Conception du jeu de test : représentatif de la production, vérité terrain annotée à la main ou LLM-as-judge pour passer à l'échelle. Bonne pratique actuelle : l'eval-driven development — écrire les evals d'abord, puis itérer sur le prompt, le modèle et les outils. Avant les LLM, les équipes ML utilisaient précision/rappel/F1 ; l'ère des LLM impose l'évaluation de sorties ouvertes, donc LLM-as-judge ou notation humaine. À distinguer de l'observabilité (latence, taux d'erreur) : l'eval mesure la qualité du résultat.