Vorhaben·○ Bald·Plattform·aktualisiert 2026-06-07

Modell-Routing: gepinnt, gemessen, bewusst gewechselt

Welches KI-Modell eine App-Aufgabe bedient, behandeln wir wie einen Dependency-Lockfile: einmal gemessen, gepinnt, stabil — geändert nur durch eine bewusste, datierte Entscheidung, nie durch einen Autopiloten. Das Fundament steht (Routing pro Aufgabe ist live); hier steht das System drumherum.

Schritte

Was als Nächstes ansteht

  1. Eingefrorene Benchmark-Sets als Konvention festschreiben: pro Operation ein versioniertes Golden-Set (Bilder, Prompts, Cases) als Lineal, gegen das altes wie neues Modell auf demselben Maßstab gemessen wird. Das nutriphi-Food-Set (15 Bilder) ist v1.
  2. Migrations-Playbook schreiben: Prompt-Neutuning → Schatten-Test (neues Modell parallel, kein Nutzer betroffen) → Canary → Promote, mit dem alten Pin als Sofort-Rollback.
  3. `sync-aliases` als Bequemlichkeit bauen — aus der Eval-Empfehlung einen Vorschlags-Diff aufs Lockfile schreiben, den ein Mensch merged. Kein Auto-Apply.
  4. Weitere Operationen pinnen, wo eine Messung einen echten Unterschied zeigt (Apps senden `mana/op/<operation>`); der Rest erbt die Klassen-Kette.
Offene Punkte

Was uns aufhält, was wir noch nicht entschieden haben

Die ehrliche Seite: wenn etwas nicht weiterkommt, liegt es meist an einer der hier gelisteten Abhängigkeiten oder offenen Fragen.

Offene Fragen
  • Wer setzt die „deutlich genug"-Schwelle für einen Wechsel? Ein Herausforderer 2 % besser rechtfertigt die Migrationskosten nicht — das ist eine Wert-Entscheidung, kein Automatismus.
  • Wie oft schärfen wir ein eingefrorenes Set nach, bevor es an der Realität vorbeimisst — und wie dokumentieren wir den dann bewussten Vergleichbarkeits-Bruch?

Vorhaben sind die vorwärts-gerichtete Schwester des Devlogs. Erledigtes wandert in die passende Kalenderwoche, damit hier nur das steht, was wirklich noch ansteht.