Errori

La distinzione per cui esiste questa pagina: un'esecuzione fallita e un'esecuzione andata in errore sono cose diverse, e presentare l'una come l'altra dice a uno sviluppatore che la sua modifica è sbagliata quando la verità è che l'infrastruttura di test è caduta.

Un fallimento è un risultato. Un errore no.

FAIL significa che un gate è stato valutato e che l'evidenza era al di sotto della soglia. È un risultato di qualità sulla modifica.

RUN_ERROR significa che l'esecuzione non è stata completata. Nessun gate è stato valutato e nulla della modifica è stato misurato. Non è uno stato di decisione, e non lo sono neppure PARTIAL o CANCELLED: descrivono ciò che è accaduto a un'esecuzione, non ciò che è stato deciso su un sistema.

Che cosa riporta un'esecuzione incompleta

Un gate su un'esecuzione incompleta esce con 5, non con 1. L'evidenza manca anziché essere negativa, e le due situazioni richiedono risposte diverse: un gate che fallisce ti chiede di guardare la tua modifica, uno incompleto ti chiede di guardare la tua infrastruttura.

Casi che non è stato possibile misurare

Un caso andato in errore viene delimitato, non scartato. Ogni metrica registra quattro conteggi — totali, idonei, osservati e mancanti — e l'intervallo tiene conto dei casi che non ha potuto vedere.

Questo conta più di quanto sembri. Una metrica che conta come zero un caso non valutato addebita al modello, come fallimenti di qualità, le interruzioni del sistema stesso, e un denominatore che si riduce silenziosamente quando un sistema inizia a fallire è il modo in cui un sistema che fallisce riporta un punteggio in crescita. Entrambe le cose sono state osservate su un assistente in produzione, dove il 13,8% delle chiamate restituiva HTTP 500.

Fallimenti transitori

Un sistema può dichiarare che un fallimento era transitorio, e un fallimento transitorio viene ritentato anziché registrato come risultato di qualità. Un timeout del provider non è evidenza su un prompt.

La dichiarazione è esplicita: un sistema richiamabile solleva TransientError con retryable=True. retryable vale False per impostazione predefinita, e un TransientError senza di esso viene registrato sul caso come qualsiasi altra eccezione, quindi il caso risulta mancante anziché ritentato. Un sistema HTTP e un provider di giudici non hanno bisogno di alcuna dichiarazione: un timeout, una connessione interrotta, un 429 o un 5xx vengono ritentati per loro. In entrambi i casi una chiamata viene tentata al massimo quattro volte, con backoff, e un caso che fallisce ancora risulta mancante. Avanzamento e concorrenza mostra entrambe le situazioni.

Errori di configurazione

Il codice di uscita 2 significa che l'invocazione o la configurazione era sbagliata e che non è stato eseguito nulla. Un rifiuto per quota è uno di questi: è un errore di configurazione con una motivazione esplicita, rifiutato prima che venga eseguito il primo caso, e non è mai uno stato di decisione. Un fatto commerciale non deve presentarsi travestito da verdetto di qualità.

Diagnosticare ciò che è fallito

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

L'intervento è ciò sotto cui vengono rieseguiti i casi falliti — gold-context, top-k o reranker — e il criterio indica di quale valutatore considerare i fallimenti. Una diagnosi riporta fattori di fallimento con conteggi, gli id degli scenari che li sostengono e le ipotesi adottate. Nomina un fattore, non una causa: il motore non afferma che una cosa ne abbia prodotta un'altra, e nemmeno lo fa alcuna schermata che la mostri.

Dove andare dopo

• Concetti fondamentali tratta gli stati di decisione e i denominatori.
• Gating in CI elenca ogni codice di uscita.
• Valutazione RAG illustra una diagnosi dall'inizio alla fine.