Context Engineering — Section 11 : Évaluation & Télémétrie

Les Métriques de Qualité (pour les systèmes RAG)

Ces métriques cherchent à répondre à la question : "La réponse est-elle bonne ?". Elles sont au cœur de l'évaluation RAG.

Les Métriques Opérationnelles

Ces métriques répondent à la question : "Le système est-il viable en production ?". Une excellente qualité ne sert à rien si le système est trop lent ou trop cher.

Les Méthodes d'Évaluation de la Qualité

Comment calculer les métriques de qualité de manière scalable ?

• Évaluation Humaine : Le "gold standard". Des humains évaluent les réponses (notation de 1 à 5, comparaison A/B). C'est la source de vérité, mais c'est lent, cher et difficile à standardiser.
• LLM-as-a-Judge : Utiliser un LLM de pointe (GPT-4, Claude 3 Opus) comme un évaluateur. On lui fournit la question, le contexte, la réponse, et une grille d'évaluation (rubric), et il donne une note et une justification. C'est scalable et de plus en plus populaire.
• Métriques Programmatiques :
  - Classiques : ROUGE, BLEU (pour la similarité lexicale, utiles en résumé mais limités).
  - Basées sur les Embeddings : Calculer la distance cosinus entre l'embedding de la question et de la réponse pour mesurer la pertinence.

Télémétrie & Tracing de Bout-en-Bout

L'évaluation repose sur la collecte de données. La télémétrie est la collecte de métriques, tandis que le tracing est la capacité de suivre une seule requête à travers toutes les étapes de votre système.

Tests en Production : A/B Testing & Canary

L'évaluation sur un jeu de test statique ("golden set") est nécessaire mais pas suffisante. La vraie mesure de la performance se fait sur le trafic réel.

Frameworks d'Évaluation & d'Observabilité

Pièges & Erreurs à Éviter

• Se fier à une seule métrique : Une réponse peut avoir un excellent score de pertinence sémantique mais être complètement fausse. Il faut toujours évaluer sur plusieurs axes (ex: pertinence + fidélité).
• Ignorer les retours utilisateurs : Vos métriques automatisées peuvent être excellentes, mais si les utilisateurs cliquent sur "pouce vers le bas", c'est qu'il y a un problème. Le feedback qualitatif est irremplaçable.
• Évaluer sans tracer : Lancer des évaluations qui retournent juste un score (ex: "Faithfulness = 0.8") est inutile. Vous devez pouvoir cliquer sur les échecs et voir la trace complète pour comprendre *pourquoi* la réponse a été mauvaise.

Snippet 1 : Évaluation d'un RAG avec Ragas

from datasets import Dataset
from ragas import evaluate
from ragas.metrics import faithfulness, answer_relevancy, context_recall, context_precision

# 1. Préparer le "golden set" au format Hugging Face Datasets
dataset_dict = {
    "question": ["What is the capital of France?"],
    "answer": ["The capital of France is Paris."], # Réponse générée par votre système
    "contexts": [["France is a country in Europe. Paris is its capital."]], # Contextes récupérés
    "ground_truth": ["Paris is the capital of France."] # Réponse de référence
}
dataset = Dataset.from_dict(dataset_dict)

# 2. Lancer l'évaluation
result = evaluate(
    dataset=dataset,
    metrics=[faithfulness, answer_relevancy, context_precision, context_recall]
)

# 3. Afficher les résultats
print(result)
# {'faithfulness': 1.0, 'answer_relevancy': 0.98, ...}

Snippet 2 : Concept d'un "LLM-as-a-Judge"

EVALUATION_PROMPT = """
You are a fair and impartial AI evaluator.
Evaluate the quality of the submitted answer based on the provided context and question.
Provide a score from 1 to 5 for "faithfulness" and a brief justification.
A faithful answer uses ONLY information from the context.

[BEGIN DATA]
- Question: {question}
- Context: {context}
- Answer: {answer}
[END DATA]

Provide your output in JSON format: {"score": X, "justification": "..."}
"""

def evaluate_with_llm_judge(question, context, answer):
    prompt = EVALUATION_PROMPT.format(question=question, context=context, answer=answer)
    # response = client.chat.completions.create(model="gpt-4-turbo", ..., response_format={"type": "json_object"})
    # return json.loads(response.choices[0].message.content)

# evaluation = evaluate_with_llm_judge(
#     question="What color is the sky?",
#     context="The sky is a deep blue color.",
#     answer="The sky is blue."
# )
# -> {"score": 5, "justification": "The answer is directly supported by the context."}

Playbook de Déploiement

1. Étape 1 : Collecter le feedback utilisateur dès le jour 1. Même un simple système de 👍/👎 est infiniment mieux que rien. C'est la source la plus riche pour trouver des cas d'échec.
2. Étape 2 : Construire un "Golden Set" initial. Prenez 50 à 100 questions/réponses ratées identifiées via le feedback utilisateur. C'est votre premier filet de sécurité contre les régressions.
3. Étape 3 : Mettre en place la Télémétrie et le Tracing. Intégrez un outil comme LangSmith. On ne peut pas évaluer ou débugger à l'aveugle. C'est un prérequis, pas une option.
4. Étape 4 : Automatiser l'évaluation offline. Créez un script qui exécute votre golden set contre votre système et calcule les métriques de qualité (avec Ragas ou un LLM-as-a-Judge). Intégrez-le à votre CI/CD.
5. Étape 5 : Créer un Dashboard Opérationnel. Monitorez en temps réel la latence (TTFT, TPOT), le coût par requête, et le taux d'erreur. Mettez en place des alertes.
6. Étape 6 : Lancer des A/B tests pour les améliorations. Une fois que le système est stable, utilisez l'A/B testing pour valider de manière statistiquement significative que vos nouveaux prompts ou modèles sont réellement meilleurs sur le trafic de production.