92 lines
5.6 KiB
Markdown
92 lines
5.6 KiB
Markdown
# Gemeinsame Interpretation und Hypothesengenerierung
|
|
|
|
Diese Seite dokumentiert das erhaltene v1-Protokoll. Neue gemeinsame Revisionen verwenden
|
|
[v2 mit Quellenbeschränkungen und gezielten Abhängigkeitsprüfungen](joint-case-planning-v2.md).
|
|
|
|
## Modus und Grenze
|
|
|
|
`trial run --planning-mode joint` aktiviert für eine neue, noch nicht interpretierte
|
|
Analysis Revision einen gemeinsamen Aufruf. Standard bleibt `separate` als Vergleich.
|
|
Der Modus wird samt Hypothesenpolicy und vorherigen Generationen im unveränderlichen
|
|
Interpretationskontext gespeichert. Beim Wiederaufnehmen bleibt dieser Kontext
|
|
maßgeblich, auch ohne erneute Angabe des Schalters. Ein bereits eingefrorener
|
|
getrennter Kontext wird nicht rückwirkend umgestellt.
|
|
|
|
`case_plan_v1` ist ein neuer englischer Prompt für einmaliges Fallverständnis:
|
|
Beobachtungen, Erwartungs-/Beschreibungsprovenienz, Identitäten und Wissenslücken
|
|
werden eingeordnet; daraus werden unterschiedliche ungetestete Mechanismen abgeleitet.
|
|
Er verkettet nicht die bisherigen Systemprompts und überträgt den Fall nur einmal.
|
|
Die bestehende deterministische Kontextselektion und JSON-Konsolidierung bleiben aktiv.
|
|
Die Namensauflösung davor und die Hypothesenuntersuchung danach bleiben eigenständig.
|
|
`docs/architecture.md` wird nicht verändert; die fachlichen Phasengrenzen bleiben erhalten.
|
|
|
|
## Antwort und unabhängige Annahme
|
|
|
|
Der echte Modellaufruf liefert:
|
|
|
|
```json
|
|
{
|
|
"interpretation": {"...": "bestehender Interpretationsvertrag"},
|
|
"hypotheses": {"hypotheses": ["Vorschläge mit interpretation_paths"]}
|
|
}
|
|
```
|
|
|
|
Die vollständigen Kindverträge stehen einmal im Prompt. Der Transportvertrag erlaubt
|
|
unabhängig fehlerhafte/fehlende Kindblöcke. Ein gültiger Interpretationsblock geht deshalb
|
|
nicht durch eine ungültige Hypothese verloren. Jeder Block wird separat mit dem bisherigen
|
|
Schema und den fachlichen Provenienz-/Identitäts-/Diversitätsregeln geprüft.
|
|
Hypothesen verwenden zunächst exakte JSON-Pointer zu ganzen Aussagen der Interpretation,
|
|
z.B. `/interpretation/observed_behavior/0`. Erst nach Annahme der Interpretation bildet
|
|
der Controller diese auf die deterministischen I-IDs des kanonischen Hypothesenkontexts ab.
|
|
Unbekannte Pointer werden abgelehnt. Das Modell erfindet keine internen I-IDs.
|
|
|
|
Die Interpretation wird mit dem bisherigen Complete-Checkpoint gespeichert. Danach kann
|
|
der Hypothesenbuilder ohne weiteren API-Aufruf den zweiten Block übernehmen und die
|
|
bestehende Registry mit gleichen Startbudgets erzeugen. Beide fachlichen Artefakte
|
|
referenzieren denselben echten Call. Es entstehen keine künstlichen LLM-Runden; Usage
|
|
ist aus den `llm/operations/*/round-*.json`-Datensätzen einmalig zu summieren, nicht aus
|
|
den wiederholten Metadaten der fachlichen Artefakte.
|
|
|
|
## Fehler und Wiederaufnahme
|
|
|
|
- Gemeinsame lokale JSON-Korrektur und begrenztes Capture greifen weiterhin im Gateway.
|
|
- Jeder Kindblock kann zusätzlich unabhängig durch dieselben konservativen
|
|
Objekt-/Array-Normalisierungsregeln geprüft werden. Der unveränderte Originalcall
|
|
bleibt erhalten; die Projektion wird beim Lesen deterministisch erneut berechnet.
|
|
- Gültige Interpretation, ungültige Hypothesen: Interpretation bleibt unverändert;
|
|
nur der Hypothesenblock wird über den bestehenden, begrenzten Korrekturpfad ersetzt.
|
|
Der Folgeprompt enthält die akzeptierte Interpretation als Kontext, verlangt aber
|
|
ausschließlich Hypothesen. Er erzeugt keine zweite Interpretation.
|
|
- Ungültige Interpretation: `case_plan_interpretation_repair_v1` verlangt ausschließlich
|
|
eine korrigierte Interpretation, mit deren Quellenkontext und konkretem Fehlerhinweis.
|
|
Die Hypothesen des ursprünglichen Calls werden vorsichtshalber verworfen, weil ihre
|
|
Abhängigkeit von der fehlerhaften Interpretation nicht sicher auszuschließen ist.
|
|
Nach Annahme erzeugt der normale Hypothesenpfad neue Vorschläge.
|
|
- Nicht parsebare oder unvollständige Gesamtausgaben bleiben kontrolliert abgelehnt.
|
|
Es werden keine fehlenden Fakten oder Endklammern ergänzt.
|
|
- Die bestehenden Retry-, Failover-, Fall-Locks, erwarteten Generationen und
|
|
Maximalversuche bleiben verbindlich. Nach Abbruch zwischen den zwei fachlichen
|
|
Complete-Checkpoints wird der gespeicherte Call verwendet, nicht neu generiert.
|
|
- Replay prüft Originalrequest, Hash, Identität, Phase, akzeptierte Interpretation und
|
|
die exakte Pointerprojektion. Eine nachträglich geänderte Interpretation kann keine
|
|
alten Hypothesen legitimieren.
|
|
|
|
`--stop-after interpretation` bleibt ein fachlicher Haltepunkt: Der gemeinsame Call
|
|
hat Hypothesen bereits geliefert, veröffentlicht sie aber erst beim späteren Builder-
|
|
Dispatch nach eigener Prüfung. Die Dispatchanzahl muss dadurch nicht um eins sinken;
|
|
die Zahl tatsächlich kostenpflichtiger Aufrufe sinkt im gültigen Fall um eins.
|
|
|
|
## Messung und zurückgestellte Arbeit
|
|
|
|
Offline mit dem gespeicherten BUG-20-Kontext des shared-recovery-Laufs:
|
|
37.999 Nachrichtzeichen für den neuen gemeinsamen Prompt gegenüber 41.419 für die
|
|
Interpretation plus 42.287 für die erfolgreiche Hypothesengenerierung (83.706 zusammen).
|
|
Das ist eine Zeichenmessung ohne neue API-Anfrage, kein Nachweis für eine bestimmte
|
|
Token-/Kostenersparnis oder unveränderte semantische Qualität. Der Realtest muss
|
|
Gesamteingabe, sichtbare Ausgabe, Denktokens, Korrekturen, Laufzeit und Qualität vergleichen.
|
|
|
|
Nach Umsetzung und Erprobung dieses Modus bleiben ausdrücklich zurückgestellt:
|
|
Untersuchung der gespeicherten beschädigten Originalantworten auf sichere Reparierbarkeit;
|
|
Vereinfachung ausführlicher Untersuchungsstarts und deterministische Ableitung unnötiger
|
|
Zustandsangaben; weitere gezielte Senkung von Denk- und Korrekturkosten.
|