5.9 KiB
Hypothesenuntersuchung v16
Neue Projekt-Untersuchungskontexte verwenden investigation_project_v16. Gespeicherte Anfragen mit älteren Promptversionen bleiben unverändert reproduzierbar. Interpretation, Hypothesengenerierung und Abschlussdiagnose werden nicht umgebaut; docs/architecture.md bleibt unverändert.
Weniger unnötige Korrekturen
Der Prompt trennt Fallquellen F/O/B von gesammelten Recherchebelegen E… ausdrücklich. Ohne neue Recherchebelege darf findings leer bleiben. Falsche Referenzen erzeugen einen konkreten Hinweis am betreffenden JSON-Pfad; die Antwort selbst bleibt unverändert archiviert. Keine automatische Umdeutung einer Fall-Fakten-ID in einen Recherchebeleg.
Providerfehler behalten neben Nutzung und Abschlussgrund feste Kategorien: http_envelope/candidate/output_json und invalid_json/json_policy/invalid_structure/root_not_object. Bei JSON-Syntaxfehlern werden nur Zeile und Spalte gespeichert. Weder Exceptiontext, Schlüsselname noch rohe Providerantwort werden protokolliert. Das Fehlerdetail wird über Gateway, Call-Artefakt und Checkpoint bis zum folgenden Korrekturprompt transportiert. Fehler im Providerumschlag werden nicht fälschlich als inhaltlicher Beleg oder Schemafehler behandelt.
Enger Bewertungsauftrag vor dem Frühabschluss
Nur bei early_review.request.status=preparing wird investigation_review_v16.txt verwendet. Dieser Aufruf bewertet noch ausstehende eigene Resultate und aktualisiert den kumulativen Arbeitsstand, bevor die unabhängige Diagnose entscheidet. Er erlaubt ausschließlich defer oder begründetes reject, keine neue Recherche, Recall, Testanforderungen oder neuen Fragen. Normale Untersuchungsturns behalten sämtliche bisherigen Aktionen.
Frische/ausstehende eigene Ergebnisse und bereits gelesene Rohbelege bleiben erhalten, ebenso eigene und fremde Gegenbefunde, Fragen und Einschränkungen der ursprünglichen Interpretation. Die Modellansicht enthält für diesen Schritt keine Werkzeugbindungen, Schema-Inventare, allgemeinen Archiv-/Belegkataloge oder Budgetplanung mehr. Die vollständigen kanonischen Daten bleiben im Paket. Insbesondere werden ausstehende Ergebnisse weiterhin bewertet und abgerechnet, bevor die Diagnose beginnen darf. Keine zusätzliche Zusammenfassungs-LLM, kein automatisches Verwerfen konkurrierender Hypothesen.
Die Instruktion unterscheidet Abschwächen und Widerlegen: statische Horde-Spawns beweisen nicht die Abwesenheit dynamischer Allianzpfade. Die finale Diagnose bleibt unabhängig und kann den Frühabschluss weiterhin ablehnen.
Metadaten und Cache
Wiederholte Herkunftsobjekte an bekannten Ergebnis-/Schema-/Kataloggrenzen werden verlustfrei über shared_metadata/metadata_ref konsolidiert, wenn die Darstellung tatsächlich kürzer ist. Datenbankzellen bleiben literal; Herkunft, Queryumfang und Snapshot werden nicht gelöscht. Reguläre Schemata und gezieltes lokales Nachlesen bleiben verfügbar.
Cache-Anfragen berücksichtigen v16. Der engere Review-Systemprompt und sein Ausgabevertrag bilden einen eigenen Cache-Inhalt; ein regulärer Untersuchungscache wird nicht als identisch ausgegeben. Bei zu kleinem Präfix entscheidet der Provider, ob explizites Caching möglich ist; bestehende required/fallback-Konfigurationen behalten ihre Bedeutung. Es wird kein Cache durch Fülltext erzwungen.
Messung und Grenzen
Offline-Projektion derselben gespeicherten Bug20-Kontexte, ohne API: die beiden Review-Anfragen sinken von 24547 auf 16220 Zeichen (-33,92 %) und von 24182 auf 16725 (-30,84 %). Reguläre Anfragen verändern sich zwischen +2,50 % (zusätzliche klare Referenzregeln) und -0,92 % (mehr konsolidierbare Herkunftsobjekte). Diese Maßnahme ist dort primär Fehlervermeidung, keine große neue Inputreduktion.
Einzelwerte: investigation-v16-offline-20261017.json. Die Messung beweist weder weniger Denktokens noch tatsächliche Kostenersparnis. Denkintensität und Ausgabelimit wurden bewusst nicht pauschal abgesenkt. Der weiche Zeichenrichtwert bleibt bestehen; frische Gegenbelege werden dafür nicht abgeschnitten. Ein späterer Live-Regressionstest muss Aufrufzahl, Fehler, Denken, Cache und Ergebnisqualität gemeinsam vergleichen.
Separate Denkintensität für die Frühabschluss-Bewertung
Pro Provider kann investigation_review_reasoning_effort gesetzt werden:
reasoning_effort = "medium"
investigation_review_reasoning_effort = "low"
Nur der enge v16-Aufruf mit Aufgabe assess_pending_result_for_early_review, Status preparing und dem auf defer/reject begrenzten Antwortvertrag verwendet diesen Override. Normale Untersuchungsturns, Interpretation, Hypothesengenerierung und finale Diagnose behalten ihre Einstellungen. Für jeden Failover-Provider gilt dessen eigener Wert. Omission übernimmt die bisherige allgemeine Denkintensität; ohne Override bleibt auch der Konfigurationssnapshot mit früheren Operationen kompatibel.
Gemini erhält den angeforderten Wert als thinkingLevel, der kompatible Adapter als reasoning_effort. Die tatsächlich unterstützten Werte hängen weiterhin vom Modell ab. Keine automatische Abschaltung des Denkens, kein kleineres Ausgabelimit und kein verändertes Hypothesenbudget. Die Call-Metadaten speichern bei Anwendung reasoning_profile=investigation_review und den angeforderten reasoning_effort, auch bei kontrolliert fehlgeschlagenen Antworten. Das beweist die übermittelte Einstellung, nicht deren interne Umsetzung durch den Anbieter; dafür sind gemessene Denktokens maßgeblich.
Für den nächsten frischen lokalen Vergleich ist config/llm.early-review.local.toml vorbereitet: Kopie des bisherigen kompakten Profils, ergänzt um den Override low. Das vorige Profil wurde nicht geändert. Ein Konfigurationswechsel mitten in einer bereits gespeicherten LLM-Operation kann kontrolliert als LLM_OPERATION_CONFLICT abgelehnt werden; neue Vergleiche deshalb mit frischem Testworkspace starten. Es wurden keine kostenpflichtigen Aufrufe zur Einrichtung ausgeführt.