Fehler

Die Unterscheidung, für die diese Seite existiert: Ein fehlgeschlagener Lauf und ein Lauf mit Fehler sind verschiedene Dinge, und wer das eine als das andere darstellt, sagt einem Entwickler, seine Änderung sei schlecht, während in Wahrheit der Harness umgefallen ist.

Ein Fehlschlag ist ein Ergebnis. Ein Fehler ist keines.

FAIL bedeutet, dass ein Gate ausgewertet wurde und die Evidenz unter dem Schwellenwert lag. Das ist ein Qualitätsergebnis über die Änderung.

RUN_ERROR bedeutet, dass der Lauf nicht abgeschlossen wurde. Kein Gate wurde ausgewertet, und nichts an der Änderung wurde gemessen. Es ist kein Entscheidungszustand, und PARTIAL oder CANCELLED sind es ebenso wenig — sie beschreiben, was mit einem Lauf geschehen ist, nicht, was über ein System entschieden wurde.

Was ein unvollständiger Lauf meldet

Ein Gate über einem unvollständigen Lauf endet mit 5, nicht mit 1. Die Evidenz fehlt, statt schlecht zu sein, und beides verlangt unterschiedliche Reaktionen: Ein fehlschlagendes Gate bittet Sie, sich Ihre Änderung anzusehen, ein unvollständiges bittet Sie, sich Ihre Infrastruktur anzusehen.

Fälle, die nicht gemessen werden konnten

Ein Fall mit Fehler wird begrenzt, nicht verworfen. Jede Metrik zeichnet vier Zählungen auf — gesamt, zulässig, beobachtet und fehlend — und das Intervall berücksichtigt die Fälle, die es nicht sehen konnte.

Das ist wichtiger, als es klingt. Eine Metrik, die einen unbewerteten Fall als Null zählt, lastet die eigenen Ausfälle eines Systems dem Modell als Qualitätsmängel an, und ein Nenner, der still schrumpft, sobald ein System zu versagen beginnt, ist der Weg, auf dem ein versagendes System einen steigenden Score meldet. Beides wurde bei einem produktiven Assistenten beobachtet, bei dem 13,8 % der Aufrufe HTTP 500 zurückgaben.

Vorübergehende Fehler

Ein System kann deklarieren, dass ein Fehler vorübergehend war, und ein vorübergehender Fehler wird wiederholt, statt als Qualitätsergebnis aufgezeichnet zu werden. Ein Timeout beim Anbieter ist keine Evidenz über einen Prompt.

Die Deklaration ist explizit: Ein aufrufbares System löst TransientError mit retryable=True aus. retryable ist standardmäßig False, und ein TransientError ohne diese Angabe wird wie jede andere Ausnahme am Fall aufgezeichnet, sodass der Fall fehlt, statt wiederholt zu werden. Ein HTTP-System und ein Judge-Anbieter brauchen keine Deklaration: Ein Timeout, eine abgebrochene Verbindung, ein 429 oder ein 5xx wird für sie wiederholt. In beiden Fällen wird ein Aufruf höchstens viermal versucht, mit Backoff, und ein Fall, der weiterhin fehlschlägt, fehlt. Fortschritt und Nebenläufigkeit zeigt beides.

Konfigurationsfehler

Exit-Code 2 bedeutet, dass Aufruf oder Konfiguration falsch waren und nichts gelaufen ist. Eine Ablehnung wegen eines Kontingents gehört dazu: Sie ist ein Konfigurationsfehler mit benanntem Grund, abgelehnt, bevor der erste Fall ausgeführt wird, und nie ein Entscheidungszustand. Eine geschäftliche Tatsache darf nicht im Gewand eines Qualitätsurteils daherkommen.

Diagnostizieren, was fehlgeschlagen ist

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

Die Intervention ist das, unter dem die fehlgeschlagenen Fälle erneut ausgeführt werden — gold-context, top-k oder reranker —, und das Kriterium gibt an, wessen Evaluator-Fehlschläge herangezogen werden. Eine Diagnose meldet Fehlerfaktoren mit Zählungen, den Szenario-IDs dahinter und den Annahmen, die sie getroffen hat. Sie benennt einen Faktor, keine Ursache: Die Engine behauptet nicht, dass eine Sache eine andere hervorgebracht hat, und keine Ansicht, die sie darstellt, tut das.

Wie es weitergeht

• Kernkonzepte behandelt Entscheidungszustände und Nenner.
• Gating in der CI führt jeden Exit-Code auf.
• RAG-Evaluation geht eine Diagnose von Anfang bis Ende durch.