Erreurs

La distinction pour laquelle cette page existe : une exécution en échec et une exécution en erreur sont deux choses différentes, et présenter l’une comme l’autre dit à un développeur que son changement est mauvais alors qu’en vérité c’est le banc de test qui est tombé.

Un échec est un résultat. Une erreur n’en est pas un.

FAIL signifie qu’une porte a été évaluée et que les preuves étaient sous le seuil. C’est un résultat de qualité sur le changement.

RUN_ERROR signifie que l’exécution ne s’est pas terminée. Aucune porte n’a été évaluée et rien n’a été mesuré sur le changement. Ce n’est pas un état de décision, pas plus que PARTIAL ou CANCELLED — ils décrivent ce qui est arrivé à une exécution, pas ce qui a été décidé à propos d’un système.

Ce que rapporte une exécution incomplète

Une porte sur une exécution incomplète se termine avec 5, pas 1. Les preuves sont manquantes plutôt que mauvaises, et les deux appellent des réponses différentes : une porte en échec vous demande d’examiner votre changement, une porte incomplète vous demande d’examiner votre infrastructure.

Les cas qui n’ont pas pu être mesurés

Un cas en erreur est borné, pas écarté. Chaque métrique enregistre quatre effectifs — total, éligible, observé et manquant — et l’intervalle tient compte des cas qu’elle n’a pas pu voir.

Cela compte plus qu’il n’y paraît. Une métrique qui compte un cas non noté comme un zéro impute au modèle, comme des échecs de qualité, les pannes du système lui-même ; et un dénominateur qui rétrécit discrètement quand un système commence à échouer, c’est ainsi qu’un système en échec affiche un score en hausse. Les deux ont été observés sur un assistant en service, où 13,8 % des appels renvoyaient HTTP 500.

Échecs transitoires

Un système peut déclarer qu’un échec était transitoire, et un échec transitoire est retenté plutôt qu’enregistré comme résultat de qualité. Un délai d’attente dépassé chez un fournisseur n’est pas une preuve sur un prompt.

La déclaration est explicite : un système appelable lève TransientError avec retryable=True. retryable vaut False par défaut, et une TransientError sans lui est enregistrée sur le cas comme n’importe quelle autre exception ; le cas est alors manquant plutôt que retenté. Un système HTTP et un fournisseur de juge n’ont besoin d’aucune déclaration : un délai dépassé, une connexion interrompue, un 429 ou un 5xx sont retentés pour eux. Dans les deux cas, un appel est tenté au plus quatre fois, avec un délai croissant, et un cas qui échoue encore est manquant. Progression et concurrence montre les deux.

Erreurs de configuration

Le code de sortie 2 signifie que l’invocation ou la configuration était erronée et que rien ne s’est exécuté. Un refus de quota en fait partie : c’est une erreur de configuration avec une raison nommée, refusée avant l’exécution du premier cas, et ce n’est jamais un état de décision. Un fait commercial ne doit pas se présenter sous l’habit d’un verdict de qualité.

Diagnostiquer ce qui a échoué

oloproof diagnose RUN_ID --intervention gold-context --criterion answer_correct

L’intervention est la condition sous laquelle les cas en échec sont réexécutés — gold-context, top-k ou reranker — et le critère indique de quel évaluateur prendre les échecs. Un diagnostic rapporte des facteurs d’échec avec leurs effectifs, les identifiants de scénarios qui les sous-tendent et les hypothèses qu’il a faites. Il nomme un facteur, pas une cause : le moteur n’affirme pas qu’une chose en a produit une autre, et aucun écran qui l’affiche ne le fait non plus.

Pour aller plus loin

• Concepts fondamentaux traite des états de décision et des dénominateurs.
• Porte de CI liste tous les codes de sortie.
• Évaluation RAG déroule un diagnostic de bout en bout.