Benchmark: gemini-3.7-flash + 3.6-flash gegen die Produktionsmodelle (16.08.2026)

Auftrag

Dennis: „New round of Gemini Models, new round of benchmarks. 3.6 flash, 3.7 flash, test all szenarios against current models. Verify prompting guidelines as published by Google for the models you test including the old ones. Create a grounded comparison report. Most important AI actions: estimate free text input, estimate portion size, estimate foto."

Dazu zwei Präzisierungen während des Laufs:

• „Preise sind relativ egal, bessere Qualität sticht immer Preis."
• „Gemittelte Präzision ist viel mehr wert als Konsistenz." — Streuung zwischen zwei Aufrufen (650 vs. 710 kcal) ist die erwartete Spanne, kein Mangel. Die Bewertung unten rankt deshalb ausschließlich auf mittlerer Treffgenauigkeit; Reproduzierbarkeit wird nur nachrichtlich geführt.

⚠️ Diese Kurzfassung ist überholt — siehe Abschnitt 11

Dennis hat nach der ersten Fassung drei weitere Fotos echter Teller mit HelloFresh-Wahrheit geliefert. Auf diesen vier echten Tellern kippt das Urteil: gemini-3.7-flash belegt die Plätze 1–3, der unten gekürte Sieger 3.6-flash [minimal] fällt auf Platz 8. Die 12 HF-Studiofotos, auf denen die erste Foto-Empfehlung beruhte, haben aktiv in die falsche Richtung gezeigt. Die Punkte 2, 4 und 5 unten gelten weiter; Punkt 1 und 3 sind widerrufen.

Kurzfassung (erste Fassung — Punkte 1 und 3 durch Abschnitt 11 widerrufen)

1. ~~gemini-3.7-flash ist für unsere drei Aktionen kein Fortschritt — es landet in der Rangfolge auf den Plätzen 6–8 von 9, hinter dem heutigen Produktionsmodell.~~ Widerrufen: galt nur für Freitext + Studiofotos.
2. Der Grund ist strukturell und nicht Pech: auf diesen Aufgaben schadet Denken. Innerhalb jeder Modellfamilie gilt „weniger Thinking = genauer" — und 3.7 hat als einziges Modell die unterste Stufe (minimal) verloren.
3. ~~Gewinner ist gemini-3.6-flash mit thinking_level=minimal (9,4 % mittlerer Fehler gegen 13,4 % heute), bei 1,5 s Antwortzeit.~~ Widerrufen — auf echten Tellern ist genau diese Konfiguration die zweitschlechteste (Abschnitt 11).
4. Der größte Fehlerhebel ist gar nicht das Modell: dasselbe Gericht als echter Teller vs. als Studiofoto verschiebt die Schätzung um 18 Prozentpunkte — dreimal so viel wie der Abstand zwischen bestem und schlechtestem Modell.
5. Googles Guidelines sind verifiziert; unser Code verletzt zwei davon. Beide nachgemessen: eine bringt etwas, eine nicht (Abschnitt „Runde B").

Status: Empfehlung, kein Deploy. Umstellung erst auf Dennis' Go (Memory prompt-aenderung-benchmarken).

Nachtrag vom selben Tag (Abschnitt 10): Dennis' Rückfragen zu einem Korrekturfaktor, zur Sicherheitsanzeige und zu Nicht-Google-Modellen sind nachgemessen — inklusive einer Auswertung seiner eigenen 73 Foto-Korrekturen aus dem Tagebuch. Das Ergebnis widerlegt die naheliegende Lösung (pauschaler Faktor) und findet stattdessen einen UI-Befund. Wer nur das Fazit braucht: direkt zu Abschnitt 10.

1. Was neu ist

google/gemini-3.7-flash ist seit 13.08.2026 auf OpenRouter, Kontextfenster 1 048 576 Token, max_completion_tokens 65 536. Preis dort 0,375 $ / 1 M Input — exakt die Hälfte von gemini-3.6-flash (0,75 $). Ein 3.7-flash-lite gibt es (noch) nicht; die lite-Linie endet aktuell bei 3.5.

2. Prompting-Guidelines — verifiziert, je Modell

Aus Googles eigener Dokumentation, nicht aus Sekundärquellen:

Die inhaltlichen Regeln, die für alle getesteten Modelle gelten:

• Denkstufe an die Aufgabe koppeln: „Use minimal or low thinking for fact retrieval or classification." Unsere drei Aktionen sind genau das — Abruf von Nährwertwissen plus Mengenschätzung, keine mehrstufige Planung.
• Knappe Prompts: „Be concise in your input prompts. Gemini 3 responds best to direct, clear instructions." Plus die ausdrückliche Warnung, dass die Modelle verbose Prompt-Engineering-Technik älterer Modelle über-analysieren.
• Sampling-Parameter streichen: temperature, top_p, top_k raus; falls doch gesetzt, Temperatur auf dem Default 1.0 lassen — „Lowering temperature may cause unexpected looping or degraded performance."
• Strukturierte Ausgabe: JSON über response_schema statt über Prompt-Text, Feldregeln in die description-Felder.

Was unser ai_jobs.py davon einhält: Sampling-Parameter setzen wir nirgends (gut). Die Denkstufe koppeln wir nicht an die Aufgabe — der Standardpfad lässt das reasoning-Feld weg und erbt damit den Modell-Default. Für das heutige gemini-3.5-flash-lite ist dieser Default zufällig minimal und damit richtig; bei einem Wechsel auf ein flash-Modell wäre er medium und damit falsch. Genau diese Falle hat 3.7 im Test gerissen.

Was wir verletzen: knappe Prompts (unsere drei Prompts sind lange Schema-Textblöcke) und response_schema. Beides in Runde B gemessen.

Zur Frage „Schema geht bei Gemini nicht — war das nicht eine bewusste Entscheidung?"

Geprüft in Code, Git-History, ADRs, Doku-Archiv und Lexis Wiki. Ergebnis:

• Es gibt keine solche Entscheidung. response_format kommt im gesamten Repo nie vor (git log -S findet genau einen Treffer: einen Doku-Commit vom 03.08., der es als „offene, nicht umgesetzte Verbesserung … separates Ticket wert" führt). Kein ADR, kein Wiki-Eintrag.
• Die andere Modellfamilie gibt es aber wirklich: llm_json fällt bei OpenRouter-Fehlern auf die claude-CLI zurück (ai_jobs.py:269). Dort lässt sich kein JSON-Schema übergeben — der Schema-Text im Prompt ist die einzige Absicherung. Konsequenz: Der Schema-Text muss im Prompt bleiben, auch wenn wir bei Gemini zusätzlich response_format setzen, sonst verrottet der Fallback-Pfad still.
• Technisch möglich ist es: heute nachgemessen auf allen 7 Konfigurationen, Text und Vision — sauberes JSON, alle Felder, finish_reason=stop, keine Ausnahme.

3. Aufbau

Harness: app/data/ai-bench/bench37.py (+ bench37_suppl.py, bench37_photo2.py, bench37_guidelines.py, Auswertung analyze37.py). Prompts verbatim aus ai_jobs.py, max_tokens=3000 exakt wie in Produktion. Offline — kein Finish-/APNs-Pfad, keine Live-Pushes an die Familie.

1 046 Messungen, 0 Fehler, 0 Parse-Fehler, 0 Trunkierungen, 2,43 $ Gesamtkosten.

Konfigurationen (9):

Das reasoning-Feld wegzulassen ist Absicht: genau das tut or_chat() heute, und der Vorgänger-Benchmark (03.08.) hatte gezeigt, dass ein explizit gesetztes Feld die lite-Modelle massiv ausbremst.

Ground Truth:

Das Teller-Foto ist doppelt belegt: Dennis' Rezept-JSON und zwei DB-Zeilen (W27 + W34) sagen übereinstimmend 1192 kcal / 2 Portionen. (Eine ältere W20-Zeile gleichen Namens hat 677 kcal — andere Variante, nicht diese.)

Ehrlichkeit über die Schwächen dieser Studie

• Ein Bewertungsfehler von mir: Mein Referenzband für „Pfefferbeißer" (8–20 g) war falsch — ein Pfefferbeißer ist eine dicke Snack-Wurst (~50 g/Stück), kein Mini-Stick. Alle neun Konfigurationen sagten 35–50 g und lagen richtig. Band korrigiert, Fall wegen weiterhin unsicherer Referenz nur nachrichtlich geführt.
• Ein schwacher GT-Fall entfernt: „Steinofen-Pizza Diavolo" — unser Etikett sagt 203 kcal/100 g, der Handelsschnitt liegt bei ~240. Alle Modelle lagen dort +15…+23 % daneben; das misst unser Etikett, nicht die Modelle. Aus der Wertung genommen.
• Der echte Teller ist EIN Fall. Aus n = 1 folgt nichts. Er wird nachrichtlich gezeigt, entscheidet aber nichts.
• Studiofotos sind kein Ersatz für echte Teller — siehe Abschnitt 5, das ist selbst ein Ergebnis.

4. Ergebnisse

Gesamtrangfolge — mittlere Treffgenauigkeit (Ø absoluter kcal-Fehler)

Der Vorsprung von 3.6-flash [minimal] ist paarweise stärker als der Mittelwert vermuten lässt: Es schlägt das Produktionsmodell in 7 von 9 Freitext-Fällen und in 10 von 12 Fotofällen.

Portion — kein Unterschied

Alle neun Konfigurationen treffen 21–24 von 24 Referenzbändern. Das ist ein Gleichstand; die Aufgabe ist für jedes dieser Modelle zu einfach, um zu differenzieren. Zwei qualitative Beobachtungen:

• 3.6-flash bei low/medium gibt für Spaghetti 200–220 g pro Portion an — das ist Kochgewicht, gefragt war die Trockenportion (80–125 g). Bei minimal passiert das nicht. Ein weiterer Beleg dafür, dass Denken hier schadet.
• Die 3.7-Konfigurationen deklarieren einen 500-g-Skyr-Becher als eine Einheit. Formal im Band, praktisch unbrauchbar zum Eintragen — 150 g wäre die nützliche Antwort.

Warum 3.7 verliert: Denken schadet auf diesen Aufgaben

Innerhalb jeder Familie sinkt der Fehler mit der Denkstufe:

Das deckt sich exakt mit Googles eigener Ansage („minimal or low for fact retrieval or classification"). 3.7-flash hat minimal nicht mehr — es kann die Stufe, die auf unseren Aufgaben gewinnt, gar nicht mehr einnehmen. Der Preisvorteil ist damit für uns bedeutungslos.

Nachgemessen: effort=minimal gegen gemini-3.7-flash wirft keinen Fehler, OpenRouter mappt still auf low (dokumentiertes Verhalten — identisches Denk-Token-Profil, Median 0 bei Freitext, ~250 bei Foto). Wer glaubt, minimal gesetzt zu haben, bekommt low.

5. Der größte Hebel ist nicht das Modell

Dasselbe Gericht, dieselbe Wahrheit (596 kcal), zwei Bilder:

Ausnahmslos jedes Modell schätzt am echten Teller höher und am Studiofoto niedriger. Die Ursache ist sichtbar in den Rohdaten: die geschätzte Tellermasse fällt von 450–550 g auf 420–520 g. Ein gestyltes, aufgeräumtes Studiofoto sieht nach weniger Essen aus.

Größenordnung: Der Bildtyp verschiebt das Ergebnis um ~18 pp. Der Abstand zwischen bestem und schlechtestem Modell beträgt ~6 pp. Wie das Foto entsteht, zählt dreimal so viel wie die Modellwahl.

Zwei Folgerungen: Der Negativ-Bias von −6…−16 % auf dem Studioset ist überwiegend ein Studio-Artefakt, kein Beweis, dass Modelle HF-Essen unterschätzen. Und die realistische Erwartung für den Alltag ist die Teller-Zahl: ~+10 % Überschätzung bei HF-Gerichten.

6. Runde B — Googles Guidelines angewandt statt nur zitiert

Getestet auf dem Produktionsmodell und dem 3.7-Kandidaten, gleiche Fälle: +schema = Produktions-Prompt plus response_format/json_schema; +konzis = Aufgabe in einem Satz, alle Feldregeln in den Schema-descriptions.

• response_schema bringt bei der Genauigkeit nichts — mal minimal besser, mal schlechter, alles innerhalb des Rauschens. Sein Wert liegt woanders: Robustheit. Wir hatten in diesem Lauf allerdings 0 Parse-Fehler in 1 046 Aufrufen, das Problem existiert derzeit also nicht. Kein Handlungsdruck.
• Der knappe Prompt sieht beim Freitext stark aus (7,2 % → 3,8 %), aber die Stichprobe ist klein und beim Foto kippt er für 3.7 deutlich ins Negative (6,1 % → 14,1 %). Kein belastbares Ergebnis — als eigenes Thema mit ordentlicher Fallzahl nachmessen, nicht nebenbei mitshippen.

7. Rausch-Grenze

Weil minimal auf 3.7 still auf low gemappt wird, liefen dort zwei identische Konfigurationen — ein geschenktes Maß für das Grundrauschen: Median 0 %, Ø 2,0 %, im Extremfall 15,6 % (Fall „HF-Wrap"). Unterschiede unterhalb von ~2 Prozentpunkten im Mittel sind daher keine Modellunterschiede. Der Vorsprung von 3.6-flash [minimal] (9,4 % gegen 11,6 % für den Zweiten) liegt knapp darüber und wird durch die paarweisen Siege (7/9 bzw. 10/12) gestützt.

Reproduzierbarkeit (nachrichtlich, laut Dennis kein Wertungskriterium): die lite-Modelle antworten fast identisch (Median 0,4–0,5 % Spanne), die Denk-Modelle schwanken stärker (3.5-flash 8,3 %, 3.6-flash [medium] 7,3 %).

8. Urteil und Empfehlung

Nicht umstellen auf gemini-3.7-flash. Es gewinnt in keinem der drei Szenarien, und der Grund ist strukturell: Auf Abruf- und Schätzaufgaben ist weniger Denken besser, und 3.7 kann die dafür nötige Stufe nicht mehr einnehmen.

Empfehlung, in dieser Reihenfolge:

1. estimate und photo auf gemini-3.6-flash mit reasoning={"effort": "minimal"} umstellen. Bester Wert in beiden belastbaren Sets, paarweise 7/9 bzw. 10/12 gegen heute, 1,5 s Antwortzeit. Wichtig: effort muss explizit gesetzt werden — ohne das Feld erbt 3.6 den Default medium und wird schlechter und dreimal langsamer.
2. portion unverändert lassen. Gleichstand über alle Modelle; ein Wechsel wäre Bewegung ohne Gewinn.
3. response_schema nicht jetzt. Kein Genauigkeitsgewinn, kein aktueller Robustheitsschmerz, und es verlangt, den Schema-Text im Prompt trotzdem zu behalten (claude-CLI-Fallback). Als eigenes Ticket parken.
4. Der eigentliche Qualitätshebel liegt beim Foto-Input, nicht beim Modell. 18 pp gegen 6 pp. Lohnende nächste Untersuchung.

Kosten (nachrangig, hier nur der Vollständigkeit halber): 3.6-flash [minimal] kostet ~0,0007 $ pro Aufruf gegen ~0,0004 $ heute. Bei unserem Volumen bewegt sich das im Bereich weniger Cent pro Monat.

9. Was diese Studie nicht gemessen hat

• Echte Teller mit belastbarer Wahrheit — genau ein Fall. Das ist die größte Lücke. Um die Foto-Empfehlung wirklich abzusichern, bräuchte es ~10 Fotos von Mahlzeiten mit bekannten Nährwerten (HF-Gericht gekocht und fotografiert, oder abgewogene Portionen).
• Die übrigen sieben ai_jobs.py-Use-Cases (receipt_pdf, cook_suggest, merge_suggest, ideas, steps, insights, …). Der Vorgänger-Benchmark vom 03.08. deckt sie ab; die Bestellung galt ausdrücklich den drei wichtigsten.
• Den claude-CLI-Fallback-Pfad (kostet Dennis' Sub, hier nicht angefasst).

10. Nachtrag: Korrekturfaktor, Sicherheitsanzeige, Fremdmodelle

Drei Rückfragen von Dennis nach der ersten Fassung:

„Ich habe mittlerweile sehr viele Teller-Fotos schätzen lassen und habe diesen systematischen Faktor von 10 % ebenfalls wahrgenommen. Es gibt viele Fälle, in denen ich die Portion im Dialog um 1/8 reduziere (kleinster Step der möglich ist). […] Meiner Meinung nach sollten wir uns anschauen, welches Modell am besten abschneidet, und uns dann überlegen, einen Faktor nachträglich auf die Berechnung anzuwenden (nur für Fotos). Alternativ könnte man auch einfach die ‚Sicherheit' der Schätzung mit anzeigen […] Auch zusätzlich noch weitere aktuelle Modelle heraus, die schnell antworten […] Grok, Kimi k3, GLM 5.3, Qwen 3.8, DeepSeek V4 Flash?"

10.1 Dennis' eigene 73 Korrekturen — die belastbarste Datenquelle im Haus

ai_jobs.note speichert die KI-Rohschätzung jedes Foto-Jobs, das Tagebuch den gebuchten Wert. Über Namensgleichheit und Zeitnähe ließen sich 73 von 77 Foto-Buchungen paaren. Damit ist Dennis' eigenes Urteil messbar.

Diese Null ist der entscheidende Befund. Sie hat eine technische Ursache: Der Portions-Stepper der nativen App kennt die Brüche [0, ¼, ⅓, ½, ⅔, ¾] (app/ios-native/Silverscale/Support/PortionFormat.swift:7). Ein Achtel gibt es nicht — die feinste Reduktion ab einer ganzen Portion ist ¾, also −25 %.

Schärfer noch: Vergleicht man das Verhältnis mit dem gebuchten portion_count, sind 64 der 73 Fälle exakt Mengenentscheidungen („ich habe die Mahlzeit tatsächlich auf zwei Portionen geteilt" — Dennis) und 9 weitere reine Einheiten-Umschreibungen (Pizza als 8 Stücke, Gesamt-kcal unverändert). In keinem einzigen Fall korrigiert Dennis den Kalorienwert selbst.

Daraus folgt ein stimmiges Gesamtbild:

1. Das Modell überschätzt am echten Teller um ~10 % (gemessen, Abschnitt 5).
2. Dennis nimmt das wahr.
3. Die UI kann −10 % nicht ausdrücken; der feinste Griff ist −25 %.
4. Also übernimmt er den Wert lieber unverändert — in 56 % der Fälle.
5. Ergebnis: die Foto-Einträge im Tagebuch sind vermutlich systematisch ~10 % zu hoch, und die Korrekturdaten können das nicht zeigen.

10.2 Wo der Fehler sitzt: Menge oder Kaloriendichte?

kcal = Menge × Dichte. Aus den HF-Zutatenmengen (dish_ingredients.grams) ist das echte Portionsgewicht bekannt, damit lässt sich der Fehler zerlegen:

Auf Studiofotos schätzen alle Modelle die Menge im Wesentlichen richtig; die gesamte Abweichung steckt in der Kaloriendichte. Auf Dennis' echtem Teller ist es umgekehrt: dort schätzen sie 450–550 g (echt: ~447 g Rohgewicht) und liegen bei der Dichte richtig (120–151 gegen 133 kcal/100 g).

Vorbehalt: Das Rohgewicht untererfasst — mit 0 g geführte Zutaten (Öl, Zwiebel, Gurke) und Wasserzugabe bei Reis/Suppe fehlen. Der Mengen-Bias ist dadurch nach oben, der Dichte-Bias nach unten verzerrt. Die Richtung ist belastbar, die absolute Höhe nicht.

Folgerung zum Korrekturfaktor: Ein pauschaler kcal-Faktor verschiebt beide Teile gleichzeitig. Er wäre nur richtig, wenn der Fehler wirklich multiplikativ und über Bildtypen stabil wäre — und genau das ist er nicht (Abschnitt 5: derselbe Faktor kippt zwischen Teller und Studiofoto um 18 pp das Vorzeichen). Ein Blindfaktor auf Basis von einem echten Teller ist nicht verantwortbar.

Die saubere Reihenfolge stattdessen:

1. Feinerer Portionsschritt (z. B. ein 0,9-Schritt) — macht genau das ausdrückbar, was Dennis heute nicht ausdrücken kann, ohne irgendetwas still zu verbiegen. (app/ios-native/ = MacClaudes Revier, per Bestellung.)
2. Danach kalibriert sich der Faktor von selbst: sobald die feine Stufe existiert, zeigen die Korrekturdaten, wie groß der Trimm wirklich ist. Der Faktor wird gemessen statt geraten.
3. Parallel ~10–15 echte Teller mit bekannter Wahrheit sammeln (gekochtes HF-Gericht fotografieren oder abwiegen) — das schließt die größte Lücke dieser Studie.

10.3 Sicherheit anzeigen — geht, trägt aber nichts

Das Label, das wir heute schon abfragen, ist wertlos. Über alle Foto-Messungen mit Ground Truth:

Die Modelle sagen in 96 % der Fälle „hoch" und liegen dabei im Schnitt 18 % daneben. Ein Wert ohne Streuung kann nichts anzeigen.

Die bessere Variante — ein Intervall statt eines Labels — ist ebenfalls überkonfident. Auftrag an das Modell war eine Spanne, die die Wahrheit zu ~80 % enthält:

Selbst nachdem der systematische Bias herausgerechnet ist, bleibt die Abdeckung bei 50–69 % statt 80 % — die Spannen sind zu schmal. Und die Trennschärfe ist negativ: ein breiteres Intervall markiert nicht den größeren Fehler.

Fazit: Es gibt derzeit kein brauchbares Signal pro Einzelfall. Wer Ehrlichkeit anzeigen will, kann nur die gemessene Bandbreite nennen („Schätzung, typisch ±15 %") — eine Eigenschaft des Verfahrens, nicht des Einzelbildes. Eine fallbezogene Sicherheitsanzeige wäre Schein-Ehrlichkeit.

10.4 Nicht-Google-Modelle: an der Antwortzeit gescheitert

Zwei der genannten existieren nicht: GLM 5.3 gibt es nicht (neuestes bildfähiges Z-AI-Modell ist glm-5v-turbo), und DeepSeek V4 Flash ebenfalls nicht — DeepSeek hat aktuell überhaupt kein bildfähiges Modell auf OpenRouter.

Vorauswahl auf demselben Foto (1 Aufruf je Modell):

Der Hauptlauf wurde auf Dennis' Ansage abgebrochen („bei den Zeiten brauchst du gar nicht weitermachen"). Das ist die richtige Entscheidung: Die Foto-Schätzung ist eine Aktion, bei der jemand mit dem Handy in der Hand wartet. 13 bis 65 Sekunden sind kein langsameres Feature, sondern ein anderes. Qualität sticht Preis — aber Wartezeit sticht beides. Google bleibt gesetzt.

11. Die Entscheidung: vier echte Teller — und die Kehrtwende

Die als größte Lücke benannte Schwäche („echte Teller mit belastbarer Wahrheit — genau ein Fall") hat Dennis noch am selben Tag geschlossen: drei weitere Fotos gekochter HelloFresh-Gerichte, jeweils mit dem zugehörigen Rezept-JSON.

Maßstab (Dennis, ausdrücklich): Jeder fotografierte Teller ist exakt eine HF-Portion. Verglichen wird ausschließlich Foto-Schätzung gegen Herstellerangabe; was ins Tagebuch gebucht wurde, ist irrelevant. (Eine 0,5-Buchung bei Jaqueline hieß nur, dass sie den Rest nicht geschafft hat und Dennis ihn später gegessen hat — der Teller auf dem Foto war eine ganze Portion. Der Döner-Teller stammt aus der Zeit vor der App, deshalb fehlt dort jede Buchung.)

108 Messungen: 4 Teller × 9 Konfigurationen × 3 Wiederholungen, 0 Fehler.

Die drei 3.7-Konfigurationen belegen geschlossen die Plätze 1–3. Das ist keine Zufallsschwankung: Die Trennung verläuft entlang der Modellfamilie, nicht zwischen Konfigurationen. Die 3.7-Gruppe liegt eng beieinander (7,2–7,8 %), die 3.6-Gruppe ebenso (12,6–16,0 %) — dazwischen klafft mehr als das Doppelte der in Abschnitt 7 gemessenen Rauschgrenze.

Gesamtbild über alle Ground-Truth-Sets

(Studiofotos nicht in die Gesamtwertung eingerechnet — siehe unten.)

Was ich falsch gemacht habe

Die Studiofoto-Spalte ist antikorreliert mit der Realität: Sie kürte 3.6-flash [minimal] (13,7 %, bester Wert) — auf echten Tellern ist genau diese Konfiguration die zweitschlechteste (16,0 %). Umgekehrt sah 3.7-flash [minimal] auf Studiofotos am schlechtesten aus (21,6 %) und gewinnt auf echten Tellern.

Ich hatte den Vorbehalt in Abschnitt 3 notiert („Studiofotos sind kein Ersatz für echte Teller") und in Abschnitt 5 sogar gemessen, dass der Bildtyp 18 pp verschiebt — und trotzdem eine Empfehlung darauf gestützt, weil 12 Fälle belastbarer aussahen als einer. Die Fallzahl war nicht das Problem, die Gültigkeit des Ersatzmaßes war es. Zwölf Messungen am falschen Gegenstand schlagen nicht eine am richtigen.

Der Korrekturfaktor erledigt sich damit

Der Bias von 3.7-flash auf echten Tellern beträgt +1 bis +3 % — es gibt praktisch nichts mehr systematisch herauszurechnen. Ein im Nachhinein auf genau diesen vier Tellern optimierter Faktor (also die freundlichstmögliche Rechnung) verbessert 3.7-flash [low] von 7,2 % auf 7,0 % — nichts. Zum Vergleich: beim heutigen Produktionsmodell brächte er 8,0 % → 4,8 %, bei einer Rest-Streuung von 18 pp, die auch der perfekte Faktor nicht wegnimmt.

Also: Modell wechseln statt nachträglich multiplizieren. Das ist auch die ehrlichere Lösung — ein stiller Faktor verbiegt eine Modellausgabe, ein besseres Modell braucht das nicht.

Dennis' wahrgenommene ~10 % Überschätzung deckt sich übrigens gut mit dem gemessenen Bias des heutigen Modells (+6,0 %) plus dem Umstand, dass der feinste UI-Trimm bei −25 % liegt (Abschnitt 10.1).

Revidierte Empfehlung

1. estimate und photo auf gemini-3.7-flash mit reasoning={"effort": "low"}. Beste mittlere Treffgenauigkeit über beide belastbaren Sets (6,6–7,3 %), nahezu bias-frei auf echten Tellern, 4,3–4,8 s. (minimal wird von OpenRouter auf low gemappt — identisches Verhalten, Abschnitt 4. Wer low schreibt, weiß, was er bekommt.)
2. gemini-3.6-flash in keiner Variante — auf echten Tellern durchgehend +11 bis +16 % daneben. Auch die cook_suggest-Nutzung (heute 3.6-flash, effort=high) ist damit einen eigenen Blick wert, wurde hier aber nicht gemessen.
3. Kein Korrekturfaktor. Siehe oben.
4. Kein Sicherheits-Label und kein Intervall — Abschnitt 10.3, unverändert.
5. portion unverändert — Gleichstand über alle Modelle, Abschnitt 4.

Was weiterhin offen bleibt

Vier echte Teller sind besser als einer, aber es sind vier. Der Abstand von 3.7-flash (7,2 %) zum heutigen Modell (8,0 %) liegt innerhalb der Rauschgrenze — belastbar ist nur, dass beide deutlich besser sind als die 3.6-Familie und dass 3.7 den kleineren systematischen Bias hat. Für eine echte Trennung zwischen 3.7 und dem Status quo bräuchte es ~10–15 Teller. Alle vier Gerichte sind außerdem HelloFresh — Restaurantessen, Selbstgekochtes ohne Rezept und Verpacktes sind nicht abgedeckt.

Rohdaten: app/data/ai-bench/results37-*.json, Läufe run37-*.log. Judge: StratoClaude (Memory ich-bin-der-judge) — kein bezahltes Fremdmodell.