Grundlinie 20260918-191400: 9 von 22 Läufen hatten Aufrufe, die an LLM_MAX_TOKENS abgeschnitten
wurden (Venice 4/28, Makora 2/43, übrige 0/54); hard_portfolio_kardinalitaet brach nach vier
Abschneidungen ab, Kosten gingen verloren.
- Abschneiden: sofort neu versuchen, Anbieter per provider.ignore meiden (_avoid_provider,
gemeinsam mit „zu langsam“)
- nach allen Wiederholungen LLMUnavailable (Stufe + Ursache); fatale Fehler bleiben unverpackt
- Solver-Stufe behält Modell und Prüfbericht (Solver-Fehler), Gegenprobe behält erstes Ergebnis,
davor Ergebnis ohne Spezifikation mit Kosten („LLM-Fehler“, Report „Lauf abgebrochen“)
- Benchmark: Status „LLM-Fehler“ statt ABBRUCH, zählt nicht als ehrliches Scheitern
- TextToModel.py: Shebang
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Status error nach allen Reparaturen -> reliable=False („Solver-Fehler: …“, auch bei
--resolve); vorher Exit-Code 0 ohne Warnkasten. Benchmark zählt einen Absturz nicht
als ehrliches Scheitern.
- Report: „längster Weg“ bei maximize; Harness druckt „Gefundener Weg“.
- check_requested_method: Verneinung kurz davor im selben Satz („ohne/nicht/statt/
anders als Dijkstra“) ist keine Forderung.
- Reparatur-Prompt enthält die Fehlertexte aller früheren Versuche.
- ruff (F, E9) als Test tests/test_lint.py, Konfiguration in pyproject.toml.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Reihenfolge (Nutzerentscheidung): Titel → Laufdaten → Warnkasten → klickbares
Inhaltsverzeichnis (HTML, H2+H3) → Aufgabe → beigelegte Daten → Was in der Aufgabe
steht → Einordnung → „Wie das Modell die Aufgabe sieht“ (eigene H2) → Mathematisches
Modell → Ergebnis → Prüfbericht → Solver-Programm.
- Aufgabe als Markdown mit gerenderten Formeln (markdown-it-py, html=False,
breaks=True; Formeln vorher durch Platzhalter geschützt); Formelsatz in reinem Text
(nur_formeln.md) bleibt <pre>.
- „$0$“ gilt als Formel, „$5 und $7“ weiter als Geldbetrag (_is_money).
- markdown-it-py ausdrücklich in requirements.txt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- discarded_completions: an LLM_MAX_TOKENS abgeschnittene oder am Schema gescheiterte
Antworten sind bezahlt und zählen jetzt als Stufe „<Stufe> (verworfen)“ in Kosten,
Tokens und Aufrufen (wagner_whitin_dijkstra: ~32.000 Tokens fehlten).
- OPENROUTER_SWITCH_BELOW (Default = OPENROUTER_MIN_THROUGHPUT, 75): liefert ein Aufruf
ab 1000 Tokens weniger Tokens/s, wird der Anbieter per provider.ignore für den Rest
des Laufs gemieden (höchstens 3) und eine neue session_id vergeben; „No endpoints
found“ hebt die Sperrliste auf. Anlass: Sticky Routing hielt einen Lauf 1575 s bei
~65 Tokens/s (Median über 1012 Aufrufe: 156). provider.ignore mit echtem Aufruf geprüft.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- check_generated_data: nennt extracted_values einen Wert als fehlend („nicht genannt“,
„unbekannt“, „offener Parameter“; Werte aus beigelegten Dateien ausgenommen) und
data_assumptions ist leer -> undeclared_data (Reparatur, sonst unzuverlässig).
An 211 gespeicherten Läufen 8 Treffer, alle echt.
- check_answers_disclose_assumptions: bei selbst erzeugten Daten muss Antwortsatz oder
eine Antwort das sagen -> Reparatur, sonst Warnung. 1 Treffer, echt.
- Summenprüfung: bleibt nach Abzug der Summenzeilen keine Zeile, ist nur die
Schlusszeile die Summe (Fehlalarm „Summe (0)“ kostete zwei Reparaturen).
Nachlauf 20260918-140124: ehrlich_fehlende_kursdaten und ehrlich_fehlender_bedarf 2/2.
Ändert die Prompt-Kennung (Solver-Prompt.txt).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
expected.json kann statt objective_value eine Liste "behavior" nennen
(rejected | unreliable | assumed_data), eines genügt. Treffer = Verhalten gezeigt,
erfüllt = zusätzlich alle Teilfragen beantwortet (außer bei Ablehnung). Bei erwarteter
Ablehnung wird kein Routing bewertet.
Vier Fälle: reine Gleichung, reine Rechenaufgabe (-> abgelehnt), fehlende Kursdaten,
fehlender Kundenbedarf (-> Annahme ausgewiesen oder unzuverlässig). Erste Messung
20260918-134339: 3/4; der fehlende Bedarf wird im Text parametrisch richtig behandelt,
maschinell aber als „optimal 270, zuverlässig“ ohne ausgewiesene Annahme gemeldet.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- check_objective_decomposition: bei LP/MILP/CP muss eine objective_column den Zielwert
belegen, eine abweichende Beitragsspalte ist überall ein Befund -> Solver-Reparatur,
bleibt es: Warnung. 90 von 90 linearen Läufen seit 17.09. hätten bestanden.
- Summenzeilen: „Gesamt…“/„Nutzen…“ nur noch in der letzten Zeile, einzelne Zeile nie,
Zwischensummen nicht gegen die Gesamtsumme. Vorher 15 Rucksack-Läufe mit falschem
„Summe (0) weicht vom Zielwert (51) ab“; von 17 Abweichungen bleibt 1 echte.
- SOLVER_TIMEOUT (Default 60) für alle Programmläufe und als {ZEITLIMIT} im Solver-Prompt
- Benchmark: dirty zählt nur versionierte Dateien; SOLVER_TIMEOUT in der Konfiguration
Ändert die Prompt-Kennung (Solver-Prompt.txt).
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Erzeugter Code las über pandas.io.common.os – ohne import os, an validate_imports
vorbei – den OPENROUTER_API_KEY und das gesamte Home-Verzeichnis (nachgewiesen).
Kein Netz, aber alles Gedruckte landet in Ergebnis-JSON und Report. In gespeicherten
Ergebnissen fand sich kein Schlüssel.
- Umgebung des Programms ist eine Positivliste (solver_env), auch bei SOLVER_SANDBOX=aus
- bubblewrap verdeckt das Home per --tmpfs; nur sys.prefix/sys.base_prefix wieder lesbar
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- UNDERSTAND_RETRIES=-1 (A/B-Arm der Verstehensstufe) stürzte seit dem Ablehnungstor ab
- Unlösbar-Gegenprobe bekommt Verständnis, Datenprofil und Datendateien; ihre Lösung
durchläuft dieselbe Abnahme (_assess_run)
- --von pruefung behält Verständnis, Abbildungen und Datenprofil
- --resolve überschreibt frühere Befunde nicht mehr (nur Zulässigkeit neu)
- --daten wirkt auch mit --resolve und --von
- Prüfung und Korrektur sehen das Datenprofil
- Reparaturmeldung nennt alle Befundarten zugleich
- Test der Balkenhöhe prüft die Höhe tatsächlich; unbenutzte Imports entfernt
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- CallRecord.responded_model / LLMUsage.responded_models: tatsächlich antwortendes
Modell (beim Alias ~deepseek/deepseek-flash-latest) in Log, Report und Benchmark
- normalize_number: führende Null ist nie Tausender (0.040 wurde als 40 gelesen)
- numbers_in: LaTeX-Dezimalkomma 0{,}08 als eine Zahl
- question_ids_in: '### Teil N' als Teilfrage; ausdrückliche Marker haben Vorrang
vor nummerierten Listen
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Text sprachlich neu gefasst (gleiche Werte, gleiche Teilfragen), eingebettetes Bild
byte-identisch; Rest einer Punktzahl hinter Teil b) entfernt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Prompt-Beispiel '1 → 2: 3' durch Schema 'A → B: Wert' ersetzt: eine Lesung hatte
nur die Beispielzeile übernommen statt aller fünf Pfeile; alle Datenpunkte verlangt
- canonical_figure_id: '1' und 'Abbildung 1' gelten als dieselbe Abbildung – beim
Vergleich, in der Pipeline und im Report (Formfehler im zweiten Testlauf)
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- check_figure_readings vergleicht Zahlentupel je Datenzeile statt aller Zahlen des
Freitexts (Fehlalarm im ersten echten Lauf: zusätzliche Knotenaufzählung); fängt
falsch zugeordnete Bewertungen und vertauschte Pfeilrichtungen
- feste Form 'Start → Ziel: Bewertung' in Verstehen- und Abbildungs-Prompt;
abweichende Lesungen stehen im Log
- Standardmodell ist der Alias ~deepseek/deepseek-flash-latest (derzeit V4.1 Flash);
Benchmarks weiter mit festen IDs
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Eingebettete Base64-Bilder und Bilddateien werden aus dem Aufgabentext gelöst und nur
der Verstehensstufe als Bild übergeben; sie überträgt jede Abbildung in Text. Eine
zweite, unabhängige Lesung wird Zahl für Zahl verglichen (bei Abweichung entscheidet
eine dritte, sonst reliable=False). Alle weiteren Stufen rechnen mit der Übertragung,
der Report zeigt Original und Übertragung nebeneinander. LLM_MODEL_UNDERSTANDING
wählt das Bildmodell.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Routing-Prompt: Restriktionsnamen als Muster beschrieben statt kopierbarer Beispiele,
kein Indexbuchstabe im identifier (Weiter_ab_Woche_k löste in 3/3 Läufen eine
unnötige Solver-Reparatur aus)
- check_constraint_coverage: identifier …_k passt zu …_2, nur ohne direkten Treffer
(nonneg_x/nonneg_y bleiben getrennt)
- check_answer_units: englische Einheitenwörter (tons, hours, euros …); vorher strich
eine Reparatur die richtige Einheit aus einer Antwort auf eine englische Aufgabe
- QUESTION_PATTERN erkennt **Teil 1:** Text
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- Routing-Prompt verlangt bei Dijkstra Restriktionsnamen in der Sprache der Aufgabe
statt Flusserhaltung; Solver-Prompt ohne Fachwort (löste Korrekturrunden aus)
- JARGON_EVERYDAY: beeinflusst/Einfluss/Überfluss zählen weder als Vorkommen noch als
Erklärung eines Fachbegriffs
- normalize_number liest eindeutige englische Zahlen (1,234.56; 12,345,678) richtig
- QUESTION_PATTERN erkennt Part/Question/Task N
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
- sandbox_warning: fehlt bubblewrap oder ist SOLVER_SANDBOX=aus, steht das im Log
und in SolverRun.warnings (vorher lief der Code stillschweigend ungeschützt)
- Dijkstra-Markierung: der Report erklärt den Begriff selbst (DIJKSTRA_EXPLANATION),
check_text_quality zählt das als Erklärung; Stamm 'markier' -> 'markierung'
- Pruef-Prompt Regel 7: entscheidungsunabhängige Terme ohne Zahlenwert dürfen
weggelassen oder symbolisch mitgeführt werden (wagner_whitin_dijkstra: 1+1 statt
2+1 Korrekturrunden, n=2)
- revision_reasons: jede Korrekturrunde nennt ihren Auslöser im Log
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
OpenRouter-Aufrufe eines Laufs tragen eine gemeinsame session_id (Sticky Routing,
damit der Anbieter-Cache greifen kann); Cache-Treffer werden je Aufruf und Stufe
erfasst und im Log als Anteil ausgewiesen. docs/Konzeptionelle_Fragen_und_Antworten.md
hält Pipeline-Stufen und die Abwägung ein Aufruf vs. Kette mit Messdaten und Quellen fest.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
check_scenarios_solved meldet Szenarien ohne Zielwert, die nicht belegt unlösbar
sind (beobachtet: SCIP-Zeitlimit ohne Lösung als 'keine Lösung' gemeldet);
Befund löst Solver-Reparatur aus, bleibt er, reliable=False. Solver-Prompt:
timelimit ohne Lösung ist keine Unlösbarkeit, Warmstart über createSol/addSol.
Der Fachbegriff Schlupf kam aus dem Prompt selbst und ist entfernt.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Wortstämme aus 252 gespeicherten Läufen, jeder gegen ngerman/american-english
geprüft; Wörter mit _ oder Binnenmajuskel gelten als Bezeichner.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
check_answer_units meldet Einheiten hinter Zahlen, die weder Aufgabentext noch
Datenprofil hergeben (nach Größenart, GE/ME neutral bei Kosten-/Mengenwörtern);
Befund löst Solver-Reparatur aus, bleibt er, Warnung. Reparaturmeldung und
Solver-Prompt nennen data_assumptions jetzt als Antwortfeld, nicht report()-Argument.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Ursache der Umschreibungen ist kein Encoding-Problem: das LLM schreibt
im erzeugten Python-Code ASCII (Portfolio Nr. 2: Code-Strings 0 echte
gegen 60 umschriebene Umlaute, Spezifikation 128 echte). Die
Prompt-Regel wurde ignoriert, die Warnung stand in fast jedem Lauf.
- Solver-Prompt: Umschreibungen in Bezeichnern, DATA-Schluesseln,
Restriktionsnamen und Kommentaren erlaubt; echte Umlaute nur in
Lesertexten, Regel direkt bei den report()-Argumenten.
- check_text_quality meldet keine Umlaute mehr (Fachbegriffe bleiben).
- umlaut_map baut je Lauf ein Woerterbuch aus Aufgabe und Spezifikation;
repair_texts wendet es vor UMLAUT_STEMS an. ASCII-Formen aus dem
Aufgabentext (Namen) bleiben, Restriktions-/Variablennamen unberuehrt.
An vier gespeicherten Laeufen: alle Umschreibungen in Lesertexten
berichtigt, 11 Ersetzungen, keine falsch. Prompt-Kennung 694c3eb3d59a.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Bisher erzeugte is_optimization_task=False nur eine Log-Warnung; eine
reine Gleichung wurde trotzdem in ein Optimierungsmodell gepresst.
Jetzt bricht run_pipeline direkt nach dem Verstehen ab: kein
Nachfassen, keine Extraktion, kein Solver. PipelineResult.rejected,
reliable=False, specification/review optional; Report "Aufgabe
abgelehnt", CLI-Exit-Code 3, Benchmark-Status "abgelehnt" (auch die
Ergebnistabelle verkraftet die Zeile), --von verweigert.
Der Verstehens-Prompt nennt reine Gleichungen/Rechenaufgaben als
Nicht-Aufgaben und Zulaessigkeitsfragen sowie moeglicherweise
unloesbare Planungen ausdruecklich als Aufgaben. Unvermessen;
Prompt-Kennung jetzt 0333bfd5f9fe.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
Im Wurzelverzeichnis liegt nur noch TextToModel.py (Ablauf und CLI).
Jede Stufe liegt mit Code und Prompt in einem eigenen Ordner: core,
understanding, modeling, checks, solving, reporting, data, benchmark;
Tests unter tests/, Aufgaben unter tasks/. understand_task,
text_to_model/revise_model und review_assumptions/needs_work/select_best
sind aus TextToModel.py zu ihren Prompts gewandert, inhaltlich
unveraendert. Prompt-Kennung des Benchmarks bleibt 93744636095a.
Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
