156 lines
7.2 KiB
Markdown
156 lines
7.2 KiB
Markdown
# Investigation v14: einmalige Befunde statt redundanter Antwortfelder
|
|
|
|
## Ziel und Scope
|
|
|
|
Die LLM gibt die kausale Bewertung nur noch in den Befunden des Arbeitsstands
|
|
ab. Referenzmengen, Review-Effekt, Verwaltungsnotiz und Änderungsprotokoll werden
|
|
vom Controller abgeleitet. Keine zusätzliche Zusammenfassungsabfrage, kein
|
|
Euro-Limit, keine Kürzung der Recherchepayloads. Caseinterpretation und
|
|
Hypothesengenerierung sowie deren Promptverträge bleiben unverändert.
|
|
|
|
Neue projektgestützte Investigation-Schritte verwenden `investigation_project_v14`.
|
|
Gespeicherte ältere Schritte behalten ihren exakten Vertrag, einschließlich v13.
|
|
|
|
## Antwortvertrag
|
|
|
|
```json
|
|
{
|
|
"assessment": {
|
|
"semantic_score": 90,
|
|
"reason": "Das neue Ergebnis liefert einen konkret eingegrenzten Gegenbeleg."
|
|
},
|
|
"update": {
|
|
"confidence": "weakened",
|
|
"resolve_questions": [],
|
|
"add_questions": [],
|
|
"working_brief": {
|
|
"format_version": 2,
|
|
"findings": [
|
|
{
|
|
"id": "B0001",
|
|
"direction": "against",
|
|
"text": "Der als fehlend vermutete Callback ist im untersuchten Source vorhanden.",
|
|
"scope": "Commit A, keine Aussage über tatsächliche Ausführung im Deployment.",
|
|
"evidence_refs": ["E000001"]
|
|
}
|
|
],
|
|
"uncertainties": ["Welcher Stand war beim ursprünglichen Recording ausgeliefert?"],
|
|
"next_question": "Deploymentabweichung prüfen oder diesen Mechanismus verwerfen?",
|
|
"retired": []
|
|
}
|
|
},
|
|
"next": {"kind": "finish", "reason": "Der konkrete Mechanismus ist nicht hinreichend belegt."}
|
|
}
|
|
```
|
|
|
|
Das ist ein Formatbeispiel, keine Vorgabe für eine bestimmte Bugursache.
|
|
`assessment` ist ohne vorheriges Ergebnis `null`. Andernfalls bindet der
|
|
Controller sie an die ID dieses Ergebnisses. Dessen Informationswert und die
|
|
Richtung der kausalen Evidenz bleiben ausdrücklich getrennt.
|
|
|
|
Die redundanten Felder `update.evidence_refs`, `update.causal_review`,
|
|
`update.note` und `assessment.evidence_refs` entfallen auf der Leitung. Das
|
|
Schema weist sie in v14 zurück, statt zwei widersprüchliche Wahrheiten zu dulden.
|
|
|
|
## Deterministische Ableitung
|
|
|
|
- Der Controller bildet Referenzmengen aus den Befunden und dem gerade
|
|
bewerteten Ergebnis. Bei entfernten Befunden bleibt auch deren frühere
|
|
Belegbasis im kanonischen Update nachvollziehbar.
|
|
- Nur Pro-Befunde ergeben `supports`, nur Contra-Befunde `contradicts`, beide
|
|
Seiten `mixed`, keine Seite `neutral`. Die bisherige Confidence-Kalibrierung
|
|
bleibt bestehen. Inhaltliche Richtigkeit ist weiterhin eine Modellaufgabe.
|
|
- Die Verwaltungsnotiz verwendet die bereits vorhandene nächste Prüffrage.
|
|
Eine knappe kanonische Review-Begründung wird aus den Befundtexten abgeleitet;
|
|
bei Bedarf ausdrücklich gekürzt, während die vollständigen Texte erhalten bleiben.
|
|
- Jeder Befund darf weiter bis zu acht Referenzen haben. Die automatisch
|
|
gebildete Vereinigungsmenge kann bis zu 128 unterschiedliche Referenzen
|
|
enthalten; kein künstliches zweites Acht-Referenzen-Limit erzeugt neue Retries.
|
|
|
|
Die ursprüngliche Modellantwort wird **nicht** überschrieben oder nachträglich
|
|
als andere Antwort ausgegeben. Der aktive Schritt speichert die Originalantwort
|
|
und prüft beim Ausführen/Wiederaufnehmen deren Call-/Requestbindung und das
|
|
zugehörige eingefrorene Antwortschema. Erst dann erzeugt die Normalisierung die
|
|
Controllerdarstellung. Das gilt auch nach Pakettransport und Prozessneustart.
|
|
|
|
## Änderungsnachweis
|
|
|
|
Der Controller vergleicht die neuen Befunde mit dem letzten Arbeitsstand und
|
|
protokolliert hinzugefügte, entfernte und veränderte IDs/Felder automatisch.
|
|
Die Befundhistorie bleibt append-only als versioniertes Artefakt erhalten.
|
|
|
|
- Text-/Scope-Präzisierungen, Umordnung oder zusätzliche Beleg-IDs benötigen
|
|
keinen eigenen LLM-generierten `changes`-Eintrag.
|
|
- Richtungsänderungen oder das Entfernen bestehender Beleg-IDs benötigen
|
|
`revision_reason` am betroffenen Befund.
|
|
- Vollständig entfernte Befunde benötigen genau einen `retired`-Eintrag mit
|
|
ihrer bisherigen ID und Begründung. Unbekannte oder doppelte IDs bleiben ungültig.
|
|
- Unbekannte Beleg-IDs bleiben verboten. Die Controller-Normalisierung erfindet
|
|
keine Referenzen, Bewertungen oder Beobachtungen.
|
|
|
|
Die Strukturprüfung kann nicht erkennen, ob eine umformulierte Aussage mit
|
|
gleicher Richtung ihre Bedeutung unzulässig verändert. Die vollständige alte
|
|
und neue Fassung sind nachvollziehbar, alle Belege bleiben im Kontext und die
|
|
finale Diagnose bleibt die unabhängige Prüfung. Automatisches Protokollieren
|
|
ist keine automatische semantische Freigabe.
|
|
|
|
Die persistierte Fallakte verwendet weiter die kanonische Brief-Version 1,
|
|
ergänzt um `change_audit`. Dadurch bleiben bisherige Lese-/Diagnoseschnittstellen
|
|
verwendbar. Der Wire-Vertrag Version 2 ist davon getrennt. Das Modell erhält
|
|
keine erneut mitgesendete Änderungshistorie und keine redundante Referenzliste
|
|
am ausgewählten Hypothesenzustand, aber sämtliche Recherchebelege bleiben da.
|
|
|
|
## Konkrete Korrekturhinweise
|
|
|
|
Bei einem ungültigen Befund erhält der nächste Versuch etwa:
|
|
|
|
```json
|
|
{
|
|
"previous_rejection": "INVESTIGATION_BRIEF_REFERENCE",
|
|
"previous_rejection_details": {
|
|
"field": "update.working_brief.findings",
|
|
"ids": ["E999999"],
|
|
"requirement": "known_evidence_ids"
|
|
}
|
|
}
|
|
```
|
|
|
|
Schemafehler liefern zusätzlich sichere Feldpfade und bekannte Feldnamen, zum
|
|
Beispiel `/update/working_brief` und `retired`. Bei eindeutig erkanntem
|
|
Aktions-Discriminator wird der Fehler in dessen passender Schemaalternative
|
|
lokalisiert. Freier Providertext, Antwortwerte und unbekannte Eigenschaftsnamen
|
|
werden nicht in diese Diagnostik übernommen. Fehlerhinweise sind keine neue
|
|
Evidenz. Ablehnungen bleiben vor Budgetabrechnung und externen Toolaktionen.
|
|
|
|
## Offline-Ergebnis
|
|
|
|
Reproduktion ohne API-Aufruf:
|
|
|
|
```powershell
|
|
.\.venv\Scripts\python.exe scripts/measure_investigation_contract.py <bug17.zip> <bug20.zip> --output <messung.json>
|
|
```
|
|
|
|
Die beiden letzten Live-Tests enthalten 26 Investigation-Aufrufe. Bei 23 sind
|
|
strukturierte Antwortdokumente gespeichert; drei bereits an der Schema-Prüfung
|
|
gescheiterte Antworten sind nicht rekonstruierbar und werden nicht als repariert
|
|
gezählt. Der Projektionsalgorithmus kopiert Befundtexte, Richtungen, Scopes,
|
|
Konfidenz und Toolentscheidungen unverändert und übernimmt ausschließlich bereits
|
|
vorhandene Änderungsbegründungen.
|
|
|
|
| Metrik, kanonische UTF-8-Darstellung | v13 | v14-Projektion |
|
|
|---|---:|---:|
|
|
| Sichtbare Antwort-JSON, 23 Dokumente | 41.718 B | 30.334 B |
|
|
| Strukturierte Vertragsablehnungen | 5 | 1 |
|
|
| Nachrichteninhalt der 26 Anfragen | 1.932.966 B | 1.882.022 B |
|
|
| Live-Transport der Anfragen | 504.704 B | 502.869 B |
|
|
|
|
Die sichtbare Antwort-JSON sinkt um **27,29 %**. Der zusätzliche Inputgewinn
|
|
ist gering; der Schwerpunkt dieser Änderung liegt auf Ausgabe und vermeidbaren
|
|
Korrekturversuchen. Der verbliebene Fehler ist eine nicht begründete Änderung
|
|
der kausalen Richtung eines alten Befunds und wird weiterhin abgelehnt.
|
|
|
|
Die Projektion ist kein neuer LLM-Test und prüft nicht erneut externe Tools oder
|
|
die semantische Wahrheit alter Aussagen. Denken und Ausgabeformat des Providers
|
|
können sich ändern. Daher ist 27,29 % kein Versprechen gleicher Token- oder
|
|
Euroersparnis. Messdatei: `measurements/investigation-v14-replies-20261017.json`.
|