Eine Antwort aus einer Batch-Bewertung änderte case_id von gold-pair-078 zu gold-pair-079. Ihre Aufgabenkennung verwies weiterhin auf den ursprünglichen Fall. Aus dem Fehlerprotokoll rekonstruierte Felder:
task_id: gold-pair-078::gold-pair-078-candidate-127
candidate_id: gold-pair-078-candidate-127
case_id: gold-pair-079
Das Element gehörte zu einem Batch mit 20 Kandidaten. JSON war lesbar, die Strukturprüfung bestand. Die anschließende Einzelprüfung fand den Fehler, doch die Batch-Quittung enthielt bereits status: ok. Originalfehler und Codefundstelle
Eine vollständige formale Bewertung entstand nicht. Zurück blieb jedoch ein Wiederaufnahmerisiko: Der alte „Erfolg“ widersprach dem späteren Fehlerprotokoll. Ein Import, der nur Erfolgsquittungen beachtete, konnte den Batch erneut annehmen.
Die Korrektur war eindeutig: Erfolg muss nach der Identitätsprüfung aller Elemente gespeichert werden. Zu welcher Aufgabe eine Anfrage gehört, weiß der Aufrufer bereits. Das Programm muss dies abgleichen, statt dem Modell die Garantie zu überlassen.
Den ganzen Batch abnehmen, dann Erfolg schreiben
Ein Schema für Typen und Struktur erlaubt zwei unterschiedliche, jeweils gültige Zeichenketten. Dynamische Schemas können Identitätswerte weiter einschränken; dieses System vergleicht Antworten zusätzlich direkt mit den tatsächlichen Anfragen.
Die aktuelle Implementierung prüft nacheinander oberstes case_id, Aufgabenabdeckung, Elementstruktur und Identität. Die Abdeckung vergleicht Anzahl und Menge, um fehlende, doppelte und zusätzliche Aufgaben zu finden. Danach werden task_id, case_id, candidate_id und Kandidatentyp abgeglichen.
Der folgende Lehrcode zeigt die zentrale Reihenfolge. Die Produktionsimplementierung enthält zusätzlich Phasenschemas, Quittungen und Wiederholungsbehandlung.
expected = {task["task_id"]: task for task in requests}
if len(expected) != len(requests):
raise InvalidBatch("Die Anfrage enthält doppelte Aufgaben")
ids = [item["task_id"] for item in response["items"]]
if len(ids) != len(expected) or set(ids) != set(expected):
raise InvalidBatch("Aufgaben fehlen, sind doppelt oder zusätzlich")
for item in response["items"]:
task = expected[item["task_id"]]
for key in ("task_id", "case_id", "candidate_id"):
if item[key] != task[key]:
raise InvalidBatch(f"Abweichendes Identitätsfeld: {key}")
commit_success(response)
Die Verknüpfung per Kennung erlaubt eine andere Antwortreihenfolge. Redundante Felder abzugleichen verhindert, dass ein Modul dasselbe Objekt über task_id Fall 078 zuordnet und ein anderes über case_id Fall 079.
Das Programm korrigiert 079 nicht einfach zu 078. Allein aus der Abweichung ist unklar, ob das Modell eine Kennung falsch kopierte oder eine andere Aufgabe verstand. Den ganzen Batch scheitern zu lassen und die Rohantwort zu erhalten, bewahrt beide Untersuchungsmöglichkeiten.
Die Gesamtabnahme kostet: Auch die scheinbar korrekten übrigen 19 Elemente werden nicht wiederverwendet. Dafür entsteht eine einfache Speichergrenze. Teilannahme würde unabhängige Einzelprüfung, Ergänzung fehlender Elemente und Behandlung doppelter Einreichung verlangen — ein anderes Wiederaufnahmekonzept.
Alte Erfolgsdateien erneut prüfen
Nach der Korrektur neuer Aufrufe bleiben historische Quittungen bestehen. Deshalb prüft auch der Import jedes Element erneut. Findet er den Identitätsfehler aus dem früheren Fehlerprotokoll, bleibt der ganze Batch Diagnosematerial; kein Element gelangt in einen nutzbaren Checkpoint.
Bereits entstandene Aufrufkosten bleiben verbucht. Ein Neustart darf das Laufverzeichnis wechseln, aber frühere Versuche nicht löschen. Sonst enthielte der ausgewiesene Aufwand pro brauchbarem Ergebnis nur noch den letzten erfolgreichen Teil.
Die Batch-Größe muss sich an diesen Gesamtkosten orientieren. Große Batches verteilen gemeinsame Eingaben, verstärken bei vollständiger Wiederholung aber einzelne Fehler. Später erlaubte das Projekt deterministische Aufteilung nur für festgelegte Batches mit ausgeschöpften Versuchen; ein Einzelfehler konnte den Lauf weiterhin beenden. Aufteilen ist begrenzte Wiederherstellung, kein Grund für endlose Wiederholungen.
Der Regressionstest beschädigt absichtlich die Identität eines Elements der ersten Antwort und prüft drei Punkte: Fehlerquittung, kein Erfolgscheckpoint und erst nach korrekter Antwort eine Erfolgsaufzeichnung. Er testet genau die Lücke dieses Vorfalls.
Der Fertigzähler sollte erst wachsen, wenn Antworten zu Anfragen passen, der ganze Batch abgenommen ist und danach Erfolg gespeichert wird.