Évaluer les LLM métriques et protocoles

Évaluer une application basée sur un LLM est bien plus complexe que de mesurer l’exactitude d’un modèle de classification. Un bon score sur un jeu de test synthétique ne garantit pas que le produit sera utile, sûr ou rentable. Une évaluation robuste doit couvrir plusieurs angles : l’exactitude factuelle, l’utilité pour l’utilisateur, la sécurité contre les abus, et bien sûr, les coûts opérationnels. Le processus est un entonnoir : on valide en interne (offline) avant de mesurer l’impact réel en production (online).

le funnel d’évaluation

Chaque étape filtre les mauvaises versions et augmente la confiance avant le déploiement complet.

les métriques utiles

L’évaluation d’un LLM est multi-axiale. Il faut regarder au-delà de la simple justesse de la réponse.

les protocoles d’évaluation

offline: la validation sur des “golden datasets”

Avant toute chose, on teste le modèle sur un jeu de données de référence (“golden dataset”) qui représente les cas d’usage critiques. C’est une étape de non-régression : on s’assure que la nouvelle version est au moins aussi bonne que la précédente sur des exemples connus.

Questions fermées: On mesure l’exactitude avec des métriques comme EM (Exact Match) ou F1-score.
Questions ouvertes: L’évaluation est souvent qualitative, via un jugement humain ou une comparaison faite par un LLM plus puissant (ex: GPT-4).

red teaming: la recherche de failles de sécurité

Le red teaming consiste à attaquer activement votre propre application pour trouver ses failles de sécurité avant que d’autres ne le fassent.

Prompt injection: Essayer de manipuler le prompt système pour faire dévier le LLM de sa tâche.
Jailbreaking: Tenter de contourner les filtres de sécurité pour générer du contenu interdit.
Fuite de données: Essayer d’extraire des informations sensibles du contexte ou des données d’entraînement.

online: l’a/b test pour mesurer l’impact métier

C’est le test ultime. On expose deux versions du modèle à deux groupes d’utilisateurs distincts et on mesure l’impact sur un KPI métier. C’est la seule façon de savoir si une amélioration “offline” se traduit par une réelle valeur ajoutée.

-- Comparer le taux de conversion entre deux variantes de prompts ou de modèles
SELECT
    variant_name,
    COUNT(DISTINCT user_id) as users,
    ROUND(100.0 * COUNT(DISTINCT CASE WHEN converted = true THEN user_id END) / COUNT(DISTINCT user_id), 2) AS conversion_rate_pct
FROM
    llm_ab_test_outcomes
WHERE
    experiment_start_date >= '2023-03-01'
GROUP BY 1;

gouverner les changements

Un processus d’évaluation rigoureux nécessite de la discipline.

Changelog: Maintenir un historique des changements de prompts et de versions de modèles.
Gel des versions: Ne jamais changer le prompt ou le modèle au milieu d’un A/B test.
Traçabilité: Associer chaque run d’évaluation à un identifiant unique, au hash du code et au lot de tests utilisé.

lire les résultats et décider

L’analyse des résultats doit mener à une décision claire et documentée.

Gain faible, coût élevé ? -> On conserve l’ancienne version.
Latence en hausse ? -> On explore des optimisations (cache, streaming) avant de déployer.
Sécurité dégradée ? -> On renforce les filtres et les instructions du prompt système.
Décision: Chaque cycle d’évaluation se termine par une conclusion de 3 lignes : “Le modèle v2 a montré une hausse de 5% de la conversion, mais augmente la latence de 200ms. Décision : déployer, et créer un ticket pour optimiser la latence.”

pièges frequents

Symptôme: Un modèle avec 99% d’exactitude en offline fait chuter la satisfaction client en production.
- Cause: Confondre réussite synthétique et impact métier.
- Correctif: L’A/B test sur un KPI métier (conversion, rétention) est le seul juge de paix.
Symptôme: Les résultats d’un A/B test sont incohérents et non reproductibles.
- Cause: Des changements ont été faits pendant le test.
- Correctif: Geler strictement les prompts, les modèles et le code pendant toute la durée d’un test.
Symptôme: On découvre une faille de sécurité majeure après le déploiement.
- Cause: Avoir oublié la sécurité.
- Correctif: Intégrer une session de red teaming dans le protocole d’évaluation, avant tout déploiement, même limité.

faq

Comment évaluer un modèle pour des tâches créatives (ex: écriture) ? C’est le cas le plus difficile. Les métriques automatiques sont souvent inutiles. La meilleure approche est l’évaluation par préférence humaine : on présente les sorties de deux modèles côte à côte à des utilisateurs et on leur demande de voter pour la meilleure.
Par où commencer si je n’ai pas d’infrastructure d’évaluation ? Commencez simple. Créez un “golden dataset” de 50 exemples dans un tableur. Avant chaque déploiement, faites tourner votre nouvelle version sur ces 50 exemples et comparez manuellement les résultats à la version précédente. C’est déjà mieux que de ne rien faire.

Menu