4.9 KiB
Aufgabenrahmung und Abfrageplanung v18
Neue Projekt-Untersuchungskontexte verwenden investigation_project_v18. Die Änderung betrifft ausschließlich die Hypothesenuntersuchung. Alte gespeicherte Requests bleiben reproduzierbar; docs/architecture.md bleibt unverändert. Es gibt keinen zusätzlichen LLM-Aufruf.
1. Entscheidungskriterien mitführen
Bei einer normalen Entscheidung liefert update.next_step entweder null für einen Abschluss oder ein Objekt mit goal, supports_if, weakens_if und investigate_if (je höchstens 180 Zeichen). Werkzeug-, Recall- und Testaktionen benötigen ein solches Objekt. Der Controller speichert diese Modellplanung unverändert als optionales brief.next_step im neuen unveränderlichen Arbeitsbrief. Sie wird beim nächsten Turn als investigation_step.decision übernommen, auch nach portabler Wiederaufnahme. Kriterien sind Modellannahmen, keine neuen Belege oder automatischen Confidence-/Budgetänderungen. Die rohe Antwort bleibt erhalten. Alte Briefe ohne Plan verwenden weiterhin die bestehende Frage-/Mechanismus-Auswahl als Einstieg.
2. Belegte Eingrenzungen anbieten
investigation_step.known_inputs enthält höchstens zwei jüngste verfügbare Schlüssellisten. Sie stammen aus tatsächlich gelesenen Resultaten bzw. belegten kumulativen Befunden. Primärschlüsselspalten müssen durch einen vollständigen Schema-Capture mit exakt derselben Herkunft/Snapshotbindung nachgewiesen sein. Weder Spaltennamen noch Beziehungen werden aus Bezeichnungen wie id oder guid geraten. Zusammengesetzte Schlüssel bleiben Tupel, die Werte behalten ihren Typ; fehlende, boolesche oder zu lange Schlüsselwerte erzeugen keine Vermutungen.
Jede Liste nennt Datenbeleg, Schema-ID, Capture-Index, Tabelle und Schlüsselspalten. Es werden maximal 32 zurückgegebene Schlüssel-Tupel angezeigt; all_returned_keys_included zeigt eine Kürzung explizit an. query_complete beschreibt davon unabhängig die ursprüngliche exakte Queryabdeckung. Originalresultate und andere Gegenbelege bleiben vollständig erhalten und lokal lesbar. Eine Liste ist weder ein vollständiger Suchraum noch ein Beweis für Fremdschlüssel-/Tabellenbeziehungen.
3. Gezielte Abfrageregel
Der Prompt bevorzugt relevante bekannte Schlüssel, passende Filter und die für die Entscheidung nötigen Spalten/Zeilen. Er verbietet breite Discovery-Abfragen nicht: unbekannte Identitäten, ungeklärte Beziehungen, ein anderer Scope oder neue Gegenbelege können sie rechtfertigen. Die Begründung gehört in Erkenntnisziel und verbleibende Unsicherheit. Es wird kein Suchraum deterministisch auf vorhandene IDs eingeschränkt, kein Abfragelimit angehoben und keine Query automatisch umgeschrieben.
4. Erkenntnisziel statt Tabellenname
Das Ziel soll fachlich sagen, welches Wissen der gewählte Schritt liefern muss, etwa ob die bereits beobachteten Objekte an ein Ereignis gebunden sind. Ein Tabellenname allein genügt der Anweisung nicht. Die tatsächliche semantische Qualität kann ein JSON-Schema nicht garantieren; sie bleibt Gegenstand des Live-Tests. Die Kriterien liefern eine überprüfbare Erwartung, gegen die das nächste Resultat bewertet werden kann.
5. Allgemeine Instruktionen verkürzen
Der neue englische Systemprompt fasst die bisherigen Schutzregeln kompakter zusammen und integriert Aufgabenrahmung und Abfrageregeln ohne den zuletzt angehängten allgemeinen Zusatzblock. Die erforderlichen Toolargumente bleiben ausdrücklich dokumentiert, insbesondere path_prefix bei Source-Suchen. Der bereits gespeicherte Plan wird in der Modellansicht nur einmal übertragen; identische doppelte Zielformulierungen im alten next_question-Feld können entfallen. Es gibt keine zusätzliche LLM-Zusammenfassung und keine Änderung an Caseinterpretation, Hypothesengenerierung oder finaler Diagnose.
Die Vorprüfung aus v17 (Abdeckung, Schema/Anzahl, bekannte Schemas, identische Abfragen) bleibt erhalten. Lokales Recall, frische Resultate, Gegenbefunde, unabhängige Abschlussdiagnose und die niedrigere Denkintensität des engen Frühabschluss-Aufrufs bleiben bestehen. Für diesen Aufruf wird kein neues Planfeld verlangt; er behält seinen bisherigen Vertrag.
Prüfung und Grenzen
Lokale Tests prüfen Plan- und Kriterienerhalt über Checkpoints/portable Wiederaufnahme, Budgetabrechnung, Belegerhalt, Grenzen der Schlüsselhinweise, alte Promptversionen und den Frühabschluss. Offline-Projektionen derselben v17-Kontexte stehen in investigation-v18-framing-20261018.json. Diese alten Kontexte haben noch keine gespeicherten v18-Pläne: sie messen den Einstieg, nicht den gesamten künftigen Verlauf. Dort beträgt die mediane Drahttext-Differenz -503 Zeichen. Zusätzliche Pläne/Schlüsselhinweise können den Input anderswo vergrößern. Eine Ersparnis an Denktokens, Aufrufen oder Kosten ist damit nicht nachgewiesen; sie muss gegen die Ergebnisqualität im nächsten Live-Test gemessen werden.