58 lines
3.7 KiB
Markdown
58 lines
3.7 KiB
Markdown
# Schlanke Startrunde mit gemeinsamer Bewertung
|
|
|
|
Neue Fälle können mit `--investigation-config config/investigation.startup-batch.toml`
|
|
gestartet werden. Diese Konfiguration aktiviert `startup_batch_review = true` bei
|
|
`lean_loop = true` und `lean_protocol = 2`. Bisherige Konfigurationen und eingefrorene
|
|
Fallzustände werden nicht migriert. Ein geänderter expliziter Konfigurationsstand
|
|
wird bei bestehenden Fällen wie bisher kontrolliert abgelehnt.
|
|
|
|
## Ablauf und Grenzen
|
|
|
|
1. Der Controller wählt die vorhandenen Hypothesen in numerischer Reihenfolge.
|
|
Jede erhält eine schlanke `investigation_startup_v1`-Anfrage für genau einen
|
|
zulässigen Rechercheauftrag. Keine Confidence-Bewertung, kein Arbeitsstand,
|
|
keine Abschluss-/Wechselentscheidung. Bereits terminale Konten werden übersprungen.
|
|
2. Jeder Auftrag wird vor Ausführung vollständig technisch geprüft. Reservierung,
|
|
Kostenbelastung, Resultat und Provenienz werden sofort dauerhaft gespeichert.
|
|
Das Ergebnis wartet auf die semantische Bewertung; es gibt noch keinen Reward.
|
|
3. Alle erfassten Ergebnisse der Startrunde sind für die folgenden Hypothesen lesbar.
|
|
Es erfolgt weder eine zusätzliche LLM-Zusammenfassung noch eine Kürzung der Payloads.
|
|
4. Nach der Startrunde bewertet `investigation_startup_review_v1` alle ausstehenden
|
|
Hypothesen gemeinsam. Fallkontext und Ergebnisse stehen einmal im Prompt;
|
|
identische Bewertungsverträge ebenfalls nur einmal. Findings, Confidence,
|
|
Gegenbelege, offene Fragen und Informationswert werden pro Hypothese geprüft.
|
|
5. Gültige Einzelbewertungen werden mit echten LLM-Quellenverweisen übernommen;
|
|
fehlerhafte Geschwister werden nicht mit übernommen. Nur diese verbleibenden
|
|
Blöcke werden erneut angefordert. Sichere bestehende Formnormalisierung greift
|
|
auch auf die einzelnen Blöcke. Unbekannte Evidenz oder unzulässige Scores bleiben
|
|
ungültig. Eine begrenzte Anzahl fehlerhafter Runden führt zu BLOCKED.
|
|
6. Nach der vollständigen Bewertung setzt der bisherige Confidence-Scheduler fort.
|
|
Die weitere schlanke Schleife, Frühabschlussprüfung und finale Diagnose bleiben
|
|
inhaltlich unverändert. Die Startrunde ist auf die vorhandene Hypothesenmenge
|
|
ausgelegt und nicht auf exakt drei Einträge fest verdrahtet.
|
|
|
|
## Persistenz und Wiederaufnahme
|
|
|
|
Die versionierte Policy und `startup` im Investigation-State halten Reihenfolge,
|
|
Fortschritt, eingefrorene Bewertungskontexte, Anfragen, akzeptierte Einzelbewertungen
|
|
und deren Bindung an die tatsächlichen LLM-Antworten fest. Die Bewertungsanfragen
|
|
werden vor Aufruf gespeichert und bei Wiederaufnahme rekonstruiert/geprüft.
|
|
Budgetsettlements sind idempotent; bei einem Abbruch nach der Abrechnung wird die
|
|
bereits gespeicherte Antwort erneut projiziert, statt erneut angefragt/vergütet.
|
|
|
|
Neue Kontexte, Anfragen und Arbeitsstände werden durch bestätigte Checkpoints als
|
|
Analyseartefakte ausgewiesen. Sie verändern nicht nachträglich den Case-Inputhash.
|
|
Ein importiertes Paket trägt die benötigten Zustände und Antwortprovenienz mit sich.
|
|
Beide Prompttypen unterstützen die bestehende verlustfreie Cache-Aufteilung.
|
|
|
|
## Erprobung
|
|
|
|
Die lokalen Tests prüfen automatische Reihenfolge, gemeinsame Evidenzsicht,
|
|
ausstehende und abschließende Budgetabrechnung, getrennte Blockvalidierung,
|
|
Korrektur nur fehlerhafter Blöcke, Import/Wiederaufnahme, Abbruch nach Settlement,
|
|
verbotene Aktionen, Wiederholungsgrenzen, terminale Konten, Cache-Aufteilung,
|
|
variable Hypothesenmengen und den anschließenden Confidence-Scheduler.
|
|
Kostenpflichtige API-Tests erfolgen durch den Nutzer. Eine wirtschaftliche Einsparung
|
|
ist erst durch den Vergleich der gesamten Startrunde inklusive Bewertung und
|
|
Korrekturen nachweisbar; kleinere Einzelprompts allein reichen dafür nicht aus.
|