Modellwahl ist eine Messfrage

—Frage

Welches KI-Modell sollte eine konkrete Aufgabe bearbeiten?

Ein einzelner Modellname erwies sich in meiner Arbeit als unzureichende Antwort. Ein Modell war stark beim Erklären und teuer bei Routineaufgaben. Ein anderes löste einfache Coding-Aufgaben zuverlässig, brach jedoch bei bestimmten Ausgabeformaten ein. Aktuelle Recherche erforderte einen Pfad mit Websuche. Bei Code zählte vor allem, ob die Tests bestanden wurden.

Die Forschungsfrage wurde dadurch präziser:

Lässt sich Modellwahl als messbare, auditierbare und korrigierbare Systementscheidung organisieren?

Daraus entstand Ivy Conductor. Das System sitzt als Entscheidungsschicht vor den aufgerufenen Modellen. Es ordnet eine Aufgabe ein, wählt Modell, Workflow und Werkzeuge, speichert die Entscheidung und führt das evaluierte Ergebnis in die weitere Auswahl zurück. Die großen Modelle selbst werden dabei nicht trainiert.

Der vorliegende Text prüft diese eng gefasste These. Er prüft noch nicht, ob Conductor generell besser arbeitet als ein starkes Einzelmodell. Der dafür geplante Vergleich ist offen.

—Setup

Eine Episode beschreibt Aufgabe, Kontext und Evaluationsbedingungen. Ein Run ist die Ausführung einer Episode mit einem Modell- oder Workflow-Arm. Eine binäre Auswertung zählt als bestanden, wenn der hinterlegte Evaluator den Run mit mindestens 0,999 bewertet. Bei Code kommen Tests in einer Docker-Sandbox zum Einsatz. Andere Suites verwenden deterministische Regeln oder spezifizierte Judges.

Methodischer Rahmen

• Umgebung: Hetzner-Ausführung, OpenRouter-Modellpool, aktivierte Docker-Sandbox.
• Metriken: binäre Passrate, Kosten, Latenz und Fehler; dieser Artikel konzentriert sich auf Passrate und Kosten.
• Intervalle: 95-%-Wilson-Intervalle in den ausgewerteten Berichten E-0007 und E-0013.
• Interne Stoppschwelle: mindestens 300 binäre Auswertungen und Intervallbreite höchstens 0,12.
• Paarvergleich: McNemar-Test bei identischen Aufgaben und binären Ergebnissen.
• Evidenzklassen: gemessen, live beobachtet, implementiert und geplant.

Die Stoppschwelle ist eine interne Betriebsregel. Sie ist kein allgemein anerkannter wissenschaftlicher Reifegrad. Zudem dokumentiert E-0007 die Zahl der Auswertungen, aber keine vollständige Clusterstruktur aus einzigartigen Aufgaben, Wiederholungen und Modellarmen. Die Wilson-Intervalle sind daher als deskriptive Präzisionsangabe innerhalb dieses Evaluationssystems zu lesen. Da anhand der Intervallbreite gestoppt wurde, handelt es sich außerdem nicht um eine formal sequenziell adjustierte Confidence Sequence.

Runtime-Learning-Stack

Neben dem manuellen Entwicklungs-Decision-Log erzeugt Conductor im Betrieb ein eigenes Runtime-Logging. Produktive Ausführungspfade protokollieren Routingentscheidungen mit gewähltem Modell, Workflow, Confidence, Erklärung sowie Kontext- und Evidenzmetadaten. Ausgeführte Modell- oder Workflow-Schritte werden als Ausführungsprotokolle mit technischen Laufdaten wie Tokens, Kosten, Latenz, Status und Feedback-Bezügen festgehalten. Reine Entscheidungs-Endpunkte können optional persistiert werden; deshalb ist das Runtime-Log nicht als pauschale Zählung jedes möglichen API-Aufrufs zu lesen.

Gelernt wird erst, wenn ein Qualitätssignal vorliegt: etwa durch Replay-Evaluation, Gold-Test, automatische Evaluation oder menschliches Feedback. Daraus entstehen aggregierte Lernstatistiken pro Kontext und Handlungsoption. Sie erfassen Anzahl der bewerteten Updates, Qualität, Kosten, Latenz und einen daraus abgeleiteten Reward. Conductor lernt dabei nicht nur Modell- und Workflow-Arme, sondern auch Tool-Nutzung, Compute-Budget, Modalität, Kontextkompression, RAG/Memory und Aktualitätsbedarf als eigene Routing-Dimensionen.

Ein internes Dashboard aggregiert diese Signale für Monitoring, Fehleranalyse, Kostenkontrolle und Benchmark-Fortschritt. Es ist ein operatives Werkzeug, keine öffentliche Live-Evidenzquelle. Öffentliche Darstellungen zeigen deshalb keine Rohprompts, Outputs, Nutzerkontexte, Live-Zähler, konkrete Kostenkanäle oder vollständigen Modellmix.

Ein zweiter Screenshot zeigt den Modell-Mix und die Reward-Verteilung über die letzten 14 Tage aus Sicht des internen Dashboards.

—Beobachtung

Im Evidenzlauf E-0007 vom 27. Juni 2026 erreichten vier Fokus-Suites die interne Stoppschwelle. Factuality kam auf 304 bestandene von 505 Auswertungen, Grounding auf 359 von 549, LiveCodeBench auf 107 von 306 und Multimodal auf 94 von 305. Der dokumentierte OpenRouter-Verbrauch der beiden abschließenden ASAP-Läufe lag zusammen bei rund 0,95 US-Dollar. Dieser Betrag umfasst weder Entwicklung noch Betrieb oder frühere Experimente.

Ein zweiter Befund entstand durch einen Fehler. In E-0009 bevorzugte die Meta-Policy zunächst einen Arm mit sehr kleiner Stichprobe und scheinbar perfektem Reward. Nach einer Bayes-Schrumpfung zum Kontextmittel und dem Entfernen eines Human-Vote-Lecks wechselte sie auf einen Arm mit breiterer Evidenz. Das dokumentierte Holdout-Delta gegenüber der Bandit-Auswahl änderte sich von -0,015 auf 0,0000. Dieser Wert zeigt hier die Reproduktion der Bandit-Auswahl, keinen eigenständigen Qualitätsgewinn.

E-0013 verglich sechs Modelle auf 40 identischen Hard-Coding-Aufgaben je Arm. GLM 5.2 erreichte 15,0 Prozent Pass@1, DeepSeek v4-pro und Claude Sonnet 4.6 jeweils 12,5 Prozent. GPT-5.5 und Kimi K2.7-code lagen bei null Prozent. Die Intervalle waren breit und die Nullwerte verlangen ein Output- und Evaluator-Audit.

GLM 5.2 gegen GPT-5.5 ergab McNemar p=0,0312. Bei sechs Armen entstehen 15 mögliche Paarvergleiche. Unter einer einfachen Bonferroni-Korrektur läge die Schwelle bei 0,0033. Das Ergebnis ist damit explorativ und hält diese Mehrfachvergleichskorrektur nicht.

—Bewertung

Der stärkste bisherige Befund ist die überprüfbare Entscheidungsschicht. Modellwahl wird als Hypothese behandelt: Ein Ergebnis kann sie bestätigen, ihre Sicherheit reduzieren oder eine andere Auswahl nahelegen.

Das ist praktisch relevant. Ein einzelner guter Wert bei kleinem N führte zu einer Fehlentscheidung, die durch Schrumpfung korrigiert wurde. Ein früherer Vergleich produzierte Nullwerte, weil dem Service-User der Zugriff auf den Docker-Socket fehlte. Teilweise korrekter Code wurde dadurch als fehlgeschlagen gewertet. Seit der Ursachenanalyse gehört der Sandbox-Zugriff zum Deployment-Check.

Beide Fälle zeigen, weshalb eine Rangliste allein wenig aussagt. Aussagekraft entsteht erst aus Messkette, Unsicherheit, Audit-Trail und dokumentierten Gegenbelegen. Das manuelle Entwicklungs-Decision-Log reicht bis D-0087 und enthält auch überholte Bau- und Methodikentscheidungen. Es ist kein Runtime-Protokoll jedes Conductor-Calls. Die Kennung D-0018 ist doppelt vergeben, was die Nachvollziehbarkeit nicht verhindert, aber bereinigt werden sollte.

—Grenzen

Die Ergebnisse erlauben keine universelle Modellrangfolge. Suite-N sind keine nachgewiesenen Zahlen unabhängiger Aufgaben. Abhängigkeiten durch wiederholte Episoden oder mehrere Modellarme wurden im Abschlussbericht nicht clusteradjustiert ausgewiesen. Auch Runtime-Metriken wie Runs, Kosten, Latenz, Feedback und interne Rewards sind Monitoring- und Lernsignale; sie beweisen für sich allein keine allgemeine Überlegenheit des Routings.

Die interne Dokumentation nennt teils 99-%-Intervalle, während E-0007 und E-0013 mit 95 % berichten. Dieser Artikel übernimmt die Werte der jeweiligen Primärberichte. Ein Folgeprotokoll muss das Niveau vor dem Lauf einheitlich festlegen.

E-0010, der geplante matched Vergleich mit mindestens 300 Aufgaben je Arm, enthält weiterhin keine Ergebnisse. E-0013 hat n=40 je Arm, breite Intervalle und unkorrigierte Paarvergleiche. Die Research-Suite meldet offenen Prüfbedarf bei Seeds und Bewertungslogik. Modellnamen, Preise und Providerverhalten sind eine Momentaufnahme aus Juni 2026.

Auch die Reproduzierbarkeit ist begrenzt: Befehle, Konfiguration und Experimentberichte sind dokumentiert, die vollständigen Rohdatenbanken und serverseitigen Laufartefakte sind diesem Artikel jedoch nicht als öffentliches Replikationspaket beigefügt. Der Bericht E-0013 wird im Quell-Repository zudem durch eine bestehende .gitignore-Regel ausgeschlossen und ist daher noch nicht versioniert. Sein geprüfter SHA-256 sowie die verwendeten Grafikdaten sind im internen Quellenmanifest eingefroren.

—Nächster Schritt

Der nächste Haupttest ist der offene matched Vergleich: identische Aufgaben, ausreichendes N je Arm, vorab registrierte Hypothesen, festgelegtes Intervallniveau und korrigierte Mehrfachvergleiche. Der Hard-Coding-Lauf wird mit größerer Stichprobe wiederholt. Vorher werden die Null-Ergebnisse auf Extraktion, Ausgabeformat und Sandboxeffekte geprüft.

Für die Suite-Scorecards sollte das Replikationspaket künftig eindeutige Task-IDs, Wiederholungen, Modellarme, Seeds, Rohurteile und Kosten enthalten. Clusteradjustierte Auswertungen oder eine taskbasierte Aggregation würden die statistische Einheit klarer machen. Für adaptives Stoppen wäre eine formal sequenziell gültige Methode geeigneter als ein gewöhnliches Wilson-Intervall.

Erst danach lässt sich die stärkere Frage beantworten: In welchen Kontexten erzeugt die Entscheidungsschicht einen messbaren Vorteil, und wo genügt ein einzelnes, gut gewähltes Modell?

—Quellenregister

Interne Primärquellen (liegen im internen Conductor-Repository und im eingefrorenen Quellenmanifest, nicht öffentlich verlinkt):

• E-0007: ASAP-Evidenzlauf (27. Juni 2026)
• E-0009: Full-Learning-Lauf (28. Juni 2026)
• E-0010: offener Frontier-Matched-H2H (Setup dokumentiert, ohne Ergebnisse)
• E-0013: Value-Coding-H2H (29. Juni 2026)
• Entwicklungs-Decision-Log D-0001 bis D-0087
• Methodik: Benchmark- und Statistik-Strategie
• Methodik: ASAP und sequenzielles Stoppen
• Portables Quellenmanifest mit Commit-Ständen und SHA-256-Prüfsummen

Externe Referenzen: keine für diese Fassung. Der Artikel stützt sich ausschließlich auf interne Evidenzläufe, Entwicklungs-Decision-Records und freigegebene Beschreibungen des Runtime-Learning-Stacks.