feat: Prüf-Prompt prüft Parametereinheit gegen ausdrückliche Textdefinition

Neuer Schritt 1b im Pruef-Prompt: jedes Parameter-Feld unit wird gegen
eine ausdrückliche Definition im Aufgabentext abgeglichen (Betrag→€,
Menge→Stück, Zeit→h). Widerspricht die unit der Definition (z. B.
unit 'Stück' bei einem als 'Betrag' definierten Parameter l_i/u_i),
wird ein missing_assumption-Eintrag gefordert – löst eine
Korrekturrunde aus, die die Parameter-Einheit anpasst.

Anlass: Portfoliomanagement §3 definiert l_i/u_i als Schranken für den
investierten Betrag; das Modell trug unit='Stück' ein, von keiner Prüfung
gefangen (Befund 1 aus STAND.md). Die vorherige Regel (Commit c99e6f6)
zielte auf Annahmen, nicht auf das Parameter-Feld unit.

Ausschlussliste angepasst: 'Einheit je Parameter' nur noch ausgeschlossen,
wenn der Text NICHT ausdrücklich definiert. 436 Tests grün.
This commit is contained in:
Dieter Schlüter 2026-09-18 21:27:55 +02:00
commit e80a104cf9

View file

@ -24,7 +24,10 @@ Schritt 1 – Zielgröße (objective_check), immer zuerst:
6. Bei matches False gib in correction die korrigierte Zielfunktion in LaTeX an (ohne Begrenzer).
7. Ausnahme zu 4 – entscheidungsunabhängige Terme, deren Wert der Text NICHT nennt: Hat ein Term für jede zulässige Lösung denselben Wert (z. B. gleichbleibender Einkaufspreis × fest vorgegebener Gesamtbedarf), ändert er die optimale Entscheidung nicht, und ohne Zahl im Text lässt er sich nicht ausrechnen. Dann sind zwei Formen gleich richtig: (a) den Term weglassen oder (b) ihn als Konstante mit Symbol mitführen. Beide erfüllen matches = True, wenn eine Annahme in open_assumptions ausdrücklich sagt, dass der Zielwert diesen Term nicht bzw. nur symbolisch enthält und warum die Entscheidung davon unberührt ist. Verlange keine Umstellung von (a) auf (b) oder umgekehrt, und führe den fehlenden Zahlenwert nicht als missing_assumptions auf, wenn eine solche Annahme existiert. Fehlt die Annahme, gehört genau sie in missing_assumptions. Nennt der Text den Wert, gilt Regel 4: dann gehört der Term in die gefragte Gesamtgröße.
Schreibweise: In allen Textfeldern (task_evidence ausgenommen, das ist ein wörtliches Zitat) steht jede Formel und jedes Symbol in \( … \), z. B. „modelliert wird \(w^\top \Sigma w\)“. Keine $-Zeichen als Formelbegrenzer.
Schritt 1b – Parametereinheiten gegen ausdrückliche Definitionen:
Gehe jeden Parameter durch, dessen Feld unit ausgefüllt ist. Definiert der Aufgabentext die Größe ausdrücklich – etwa „\(l_i, u_i\): Schranken für den investierten Betrag“ oder „\(d_t\): Bedarf in Stück“ –, prüfe, ob die unit-Angabe zur Art der definierten Größe passt (Betrag → €/Geld, Menge → Stück, Zeit → h). Widerspricht die unit der ausdrücklichen Definition (z. B. unit „Stück“ bei einem als „Betrag“ definierten Parameter), hat das Modell stillschweigend eine falsche Einheit gewählt: melde einen Eintrag in missing_assumptions, der besagt, welche Einheit der Text verlangt und dass das Modell sie ohne Annahme anders gesetzt hat. Nur prüfen, wenn der Text ausdrücklich definiert – rätst du die Einheit, erzeugst du Fehlalarme.
Schreibweise: In allen Textfeldern (task_evidence ausgenommen, das ist ein wörtliches Zitat) steht jede Formel und jedes Symbol in \( … \), z. B. „modelliert wird \(w^\top \Sigma w\)". Keine $-Zeichen als Formelbegrenzer.
Schritt 2 – Vorgehen für jede Annahme:
1. Suche die zugehörige Stelle im Aufgabentext und zitiere sie wörtlich (task_evidence).
@ -42,7 +45,7 @@ Schritt 2 – Vorgehen für jede Annahme:
- contradicts_task, stricter_than_task, weaker_than_task: wie oben beschrieben; gib dann in correction die korrigierte Annahme bzw. Formel (LaTeX) an.
Was du NICHT prüfst (das rechnet die Pipeline ohne LLM nach – verschwende dafür keine Zeichen):
- Einheit je Parameter, Summen der Ergebnistabellen, Zulässigkeit der Lösung, Länge des Weges im Graphen, Streuung der Startpunkte, deklarierte Symbole, unerklärte Fachbegriffe, ob ein im Text verlangtes Verfahren (z. B. Dijkstra) verwendet wurde.
- Einheit je Parameter GEGEN EINE NICHT AUSDRÜCKLICHE TEXTDEFINITION (nur wenn der Text die Größe ausdrücklich definiert, prüfst du sie – siehe Schritt 1b), Summen der Ergebnistabellen, Zulässigkeit der Lösung, Länge des Weges im Graphen, Streuung der Startpunkte, deklarierte Symbole, unerklärte Fachbegriffe, ob ein im Text verlangtes Verfahren (z. B. Dijkstra) verwendet wurde.
- Ob Problemklasse und Stack zueinander passen: dafür gibt es eine feste Tabelle. Deine Aufgabe ist die Zielgröße und die Annahmen – dort sitzen die Fehler, die keine Tabelle findet.
Zusätzlich: