Files
VianoBugAnalysis/docs/shared-answer-recovery.md

115 lines
6.4 KiB
Markdown

# Gemeinsame Antwortverwertung und Fehlererfassung
## Geltungsbereich
Beide HTTP-Adapter (Gemini nativ und OpenAI-kompatibel) erfassen Modellantworten
phasenunabhängig. Gemeinsame lokale Formatbehandlung gilt auch für Namensauflösung,
Interpretation, Hypothesengenerierung, Untersuchung, Diagnose und Übergabe.
Die bestehenden phasenspezifischen Prüfer bleiben verbindlich. Fachliche Artefakte
werden weiterhin erst nach vollständiger Annahme veröffentlicht; aus einer
teilweise ungültigen Antwort wird kein Rechercheauftrag ausgeführt.
## Erfassung
`outcome.response_capture` enthält SHA-256 des UTF-8-Kandidatentextes, Bytezahl,
Vollständigkeit und entweder den vollständigen Text oder `retained=false`.
Keine abgeschnittenen JSON-Fragmente als vermeintlich vollständige Kopie.
Bei Tool-/Refusal-Ausgaben werden die nicht zum Denken gehörenden Kandidatenteile
als nicht vollständige Antwort archiviert. HTTP-Header, Schlüssel und interne
Denktexte werden nicht übernommen. Betriebslogs enthalten nur sichere Codes und
Metadaten; Kandidatentext liegt ausschließlich in der Fallakte.
Konfiguration unter `[llm]`:
```toml
response_capture_bytes = 65536
max_field_repairs = 1
```
Capture ist zusätzlich durch `max_response_bytes` und die 64-KiB-Sicherheitsgrenze
der aktuellen Recovery-Version begrenzt. Größere Antworten behalten Hash und Größe.
Dies ist keine Grenze des Case-Paketformats. `max_field_repairs` ist in Version 1
0 oder 1. Null deaktiviert Modell-Ersatzaufträge; die Erfassung bleibt aktiv.
Die neuen Standardwerte werden aus dem Konfigurationssnapshot ausgelassen, damit
unveränderte alte Operationen ihren Konfigurationshash behalten.
Schemafehler behalten zusätzlich das begrenzte strukturierte `rejected_document`.
Bei fachlicher Ablehnung befindet sich das Dokument bereits in der erfolgreichen
Protokollantwort; der Phasenfehler verweist auf diesen Call.
`response_assessment` bezeichnet die Protokoll-/Reparatureinordnung, nicht die
fachliche Annahme: protocol_valid, normalized_protocol_valid,
rejected_incomplete, rejected_syntax, schema_field_candidate,
rejected_other_schema oder no_candidate. Historisch fehlende Originalantworten
lassen sich nicht nachträglich wiederherstellen.
## Lokale Korrekturen ohne Modellaufruf
- Ein einzelner äußerer JSON-Codeblock und eine einmal JSON-kodierte Rootstruktur.
- Höchstens zwei Trennzeichenkorrekturen an vom JSON-Parser gemeldeten Positionen:
fehlendes Komma / fehlender Doppelpunkt bzw. ein nachgestelltes Komma.
- Schema-eindeutige Objektstrings und ein einzelnes vollständiges Objekt an
einer Arrayposition. Diese Normalisierung wird nur übernommen, wenn anschließend
das gesamte Antwortschema gültig ist.
Keine Änderungen innerhalb von Strings, Zahlenkonvertierungen, erfundenen
Schlüsseln/Werten, Ergänzung fehlender Endklammern oder Akzeptanz doppelter Keys.
Unvollständige Anbieterantworten (z.B. MAX_TOKENS/length) bleiben abgelehnt, auch
wenn ihr Text durch kosmetisches Schließen scheinbar parsebar würde.
Normalisierungen speichern Regeln und Ausgangsdarstellung. Vollständige
Schema-/Provenienz-/Aktions-/Budgetprüfungen folgen weiterhin.
## Gezielte Modellkorrektur
Die Infrastruktur unterstützt exakt einen Ersatzpfad und unveränderten Rest.
Der erste ausdrückliche Vertrag umfasst unabhängige redaktionelle Titel:
Root-Titel, Hypothesentitel und Human-Dev-Titel. Ein einzelner entsprechender
Schemafehler bzw. ein doppelter Hypothesentitel bei unterschiedlichen Mechanismen
kann gezielt ersetzt werden. Fehlende oder unbekannte Belege, IDs, Confidence,
Status, Toolaktionen und kausale Aussagen sind keine solchen Titelkorrekturen.
Weitere fachliche Ersatzfelder benötigen eigene Abhängigkeitsregeln.
Vor einem Aufruf wird mit einem temporären Titel geprüft, ob andere Schema- oder
fachliche Fehler bestehen. Der temporäre Wert wird niemals übernommen oder als
Beleg gespeichert. Bei weiteren Fehlern wird kein nutzloser Ersatzaufruf gestartet.
Ein unveränderlicher `recovery-declined-NNNN.json`-Nachweis hält den zusätzlichen
Phasenfehler und den Hash der betroffenen Antwort fest.
`response_field_repair_v1` erhält das betroffene Objekt, gegebenenfalls die übrigen Titel,
den Zielpfad, den Hash der vollständigen Ausgangsantwort und den Feldvertrag. Es erhält nicht erneut den vollständigen ursprünglichen
Case-/Toolkontext. Die Antwort ist nur `{replacement: ...}`. Zusätzliche Felder,
neue numerische/ID-Behauptungen, Änderungen außerhalb des Pfads und weiter
ungültige Gesamtdokumente werden abgelehnt. Die unabhängigen fachlichen Prüfer
prüfen danach nochmals die gesamte zusammengesetzte Antwort.
## Persistenz, Abbruch und Metriken
Original und Ersatz sind getrennte normale `llm/operations`-Aufrufe mit eigenen
Request-/Response-Artefakten und tatsächlichen Usage-Werten. Es gibt keine
Reparaturmodellschleife im HTTP-Adapter/Gateway. Der CaseRunner darf pro Antwort
höchstens einen zusätzlichen, separat gespeicherten Ersatzauftrag ausführen.
Transport-Retry/Failover bleibt davon getrennt und wiederaufnehmbar. Ein gespeicherter
Ersatz wird nach einem Absturz wiederverwendet; Konfigurationsfehler werden nicht
als bloße Modellfehler versteckt.
Der Zusammensetzungsnachweis ist ein weiterer Round-Datensatz der Originaloperation
mit `derived=true` und `outcome.response_recovery`: Referenzen und Hashes von
Original/Ersatz. Er ist keine weitere Modellantwort und enthält Usage/Kosten/Zeit
mit dem Wert 0. Kosten-/Call-Auswertungen müssen `derived=true` aus den echten
API-Aufrufzahlen ausschließen; die tatsächlichen Kosten stehen ausschließlich an
den beiden echten Calls. Das verhindert Doppelzählung.
Beim Lesen/Wiederaufnehmen werden Quellen, Request-/Response-Hashes, Identität,
Schema, Zielpfad und exakte Zusammensetzung erneut geprüft. Zyklen abgeleiteter
Nachweise sind unzulässig. Die bisherigen Ermittlungs-Formatkorrekturen bleiben
zusätzlich verfügbar und weiterhin auf ihre eigenen expliziten Pfade begrenzt.
## Lokale Prüfungen
Tests decken Parsergrenzen, unveränderte literale Werte, Ablehnungs-Capture,
Abschneidung, geheime Antworttexte außerhalb von Logs, Teilkorrekturen,
fachliche Vorprüfung, Registry-Wiederverwendung, manipulierte Zusammensetzung,
Abbruch nach gespeichertem Ersatz und Transport-Retry ohne Neugenerierung ab.
Kein zusätzlicher kostenpflichtiger API-Test wurde ausgeführt. Ein späterer
Realtest muss die Summe aus Erst-, Ersatz- und gegebenenfalls vollständigen
Korrekturaufrufen bewerten; kleinere Ersatzprompts allein beweisen keine Ersparnis.