„Welcher Prompt ist besser?” klingt wie eine einfache Frage. In der Praxis ist die Evaluierung von KI-Ausgaben eines der schwierigsten Probleme in der angewandten KI. Menschliche Evaluierung ist teuer und langsam. Automatisierte Metriken wie BLEU oder ROUGE verfehlen Nuancen. Und Single-Judge-LLM-Evaluierung wird durch Position, Ausführlichkeit und die eigenen Präferenzen des Judge-Modells verzerrt.
Wir haben ein Bakeoff-System entwickelt, das diese Probleme mit Multi-Judge-Bewertung, Positionsrandomisierung und statistischen Konfidenzintervallen adressiert. Dieser Beitrag behandelt die Architektur, die Statistik und die Erkenntnisse, die wir gewonnen haben.
Was ist ein Bakeoff?
Ein Bakeoff ist ein strukturierter Vergleich von zwei oder mehr KI-„Arms” — verschiedenen Prompts, Modellen, Recipes oder Workflows — evaluiert gegen dieselben Eingaben. Stellen Sie sich das als A/B-Tests für KI-Ausgaben vor, aber mit automatisierter Bewertung statt Benutzer-Klickraten.
JieGou unterstützt 6 Bakeoff-Modi:
- Prompt vs. Prompt — Dasselbe Recipe, unterschiedliche Prompt-Templates
- Modell vs. Modell — Dasselbe Recipe, unterschiedliche LLM-Anbieter
- Recipe vs. Recipe — Komplett unterschiedliche Recipes
- Workflow vs. Workflow — Unterschiedliche mehrstufige Workflows
- Workflow Modell vs. Modell — Derselbe Workflow, unterschiedliche Modelle
- A/B-Test — Live-Produktions-Routing mit Benutzerfeedback
Jeder Bakeoff kann bis zu 8 Arms und 10 Eingaben haben, begrenzt auf 40 Gesamtzellen (Arms mal Eingaben), um die Kosten überschaubar zu halten.
LLM-as-Judge-Evaluierung
Jede Zelle wird von einem LLM-Judge mit einem listenweisen Vergleichsansatz evaluiert. Anstatt jede Ausgabe unabhängig zu bewerten (was den relativen Kontext verliert), sieht der Judge alle Arm-Ausgaben nebeneinander und bewertet sie anhand definierter Kriterien.
Die Evaluierungskriterien sind gewichtet und reichen von 0 bis 100. Die Standard-Voreinstellung verwendet:
| Kriterium | Gewicht |
|---|---|
| Relevanz | 30 % |
| Vollständigkeit | 25 % |
| Klarheit | 20 % |
| Genauigkeit | 15 % |
| Format | 10 % |
Benutzer können diese Kriterien anpassen oder eigene erstellen. Gewichte müssen sich zu 100 % summieren.
Der Judge-Prompt präsentiert die Ausgabe jedes Arms mit einem randomisierten Label (A, B, C…) und fordert strukturierte Bewertungen an. Wir verwenden invokeLLMStructured() mit einem Zod-Schema, um sicherzustellen, dass der Judge gültige, parsbare Bewertungen zurückgibt.
Positionsrandomisierung
Eine bekannte Verzerrung bei LLM-Evaluierung ist die Positionspräferenz — Modelle bevorzugen tendenziell Ausgaben, die zuerst oder zuletzt präsentiert werden. Wir randomisieren die Arm-zu-Label-Zuordnung für jeden Evaluierungsaufruf. Arm 1 könnte in einem Lauf als „C” und im nächsten als „A” beschriftet sein.
Dies eliminiert die Positionsverzerrung nicht, verteilt sie aber zufällig über die Arms, anstatt systematisch einen zu bevorzugen. Über mehrere Eingaben hinweg gleicht sich der Effekt aus.
Multi-Judge-Konsens
Single-Judge-Evaluierung ist von Natur aus verrauscht. Verschiedene Modelle haben verschiedene Präferenzen, und selbst dasselbe Modell kann bei derselben Eingabe unterschiedliche Bewertungen vergeben. Wir führen 2-3 unabhängige Judges parallel auf derselben Evaluierung durch und messen ihre Übereinstimmung.
Kendalls Tau misst die Rangkorrelation durch Zählung konkordanter und diskordanter Paare. Wenn zwei Judges beide Arm A über Arm B ranken, ist das ein konkordantes Paar. Wenn sie sich nicht einig sind, ist es diskordant. Der Koeffizient reicht von -1 (perfekte Nichtübereinstimmung) bis 1 (perfekte Übereinstimmung).
Spearmans Rho bietet ein ergänzendes Maß: 1 - (6 * Summe der quadrierten Rangdifferenzen) / (n * (n^2 - 1)).
Wir klassifizieren die Übereinstimmung als:
- Hoch — Kendalls Tau ≥ 0,7
- Moderat — 0,4 ≤ Tau < 0,7
- Niedrig — Tau < 0,4
Niedrige Übereinstimmung ist selbst ein nützliches Signal. Es bedeutet gewöhnlich, dass die Kriterien mehrdeutig sind, die Ausgaben zu ähnlich sind, um sie zu unterscheiden, oder die Aufgabe keine klare „bessere” Antwort hat.
Konsens-Rankings werden durch Mittelung der Bewertungen über die Judges berechnet, mit aggregierten Gewinnzählern für jeden Arm.
Statistische Konfidenz
Für jeden Arm berechnen wir ein 95-%-Konfidenzintervall um den Mittelwert: Mittelwert +/- 1,96 * Standardabweichung / sqrt(n), wobei n die Anzahl der Eingaben ist.
Wenn sich Konfidenzintervalle zwischen zwei Arms überlappen, markieren wir das — der Unterschied ist möglicherweise statistisch nicht bedeutsam. Dies hindert Teams daran, Entscheidungen auf Basis von Rauschen zu treffen. Ein 2-Punkte-Bewertungsunterschied bei 3 Eingaben ist wahrscheinlich zufällig. Ein 15-Punkte-Unterschied bei 10 Eingaben mit nicht überlappenden KIs ist es wert, darauf zu reagieren.
A/B-Test-Integration
Bakeoffs beantworten „Welches ist theoretisch besser.” A/B-Tests beantworten „Welches performt in der Produktion besser.”
Wenn ein A/B-Test aktiv ist, werden eingehende Workflow-Läufe zufällig auf verschiedene Arms geleitet (50/50-Aufteilung). Benutzer geben Sternebewertungen (1-5) als Feedback zu jeder Ausgabe ab, und wir führen einen Chi-Quadrat-Test auf statistische Signifikanz durch.
Der Test stoppt automatisch, wenn zwei Bedingungen erfüllt sind: p-Wert < 0,05 und mindestens 30 Feedback-Antworten pro Arm. Dies verhindert sowohl voreilige Schlussfolgerungen als auch unnötig lange Tests.
Routing-Entscheidungen werden in Redis mit einer 30-Sekunden-TTL für Konsistenz gecacht — derselbe Benutzer, der den Endpunkt innerhalb des Cache-Fensters wiederholt aufruft, erhält denselben Arm.
Kostenmanagement
Multi-Judge-Evaluierung multipliziert die Ausführungskosten mit der Anzahl der Judges (2-3x). Wir stellen vorab Kostenschätzungen bereit, bevor ein Bakeoff beginnt, unter Verwendung historischer Token-Verbrauchs-Mediane als Baselines und unter Berücksichtigung des Judge-Multiplikators.
Die 40-Zellen-Begrenzung (8 Arms mal 10 Eingaben) und das 10-Kriterien-Limit halten individuelle Bakeoffs begrenzt. Für Workflow-Arms verwenden wir mehrstufige Token-Projektionen, die das Modell jedes Schritts und die erwartete Eingabe-/Ausgabegröße berücksichtigen.
Was wir gelernt haben
Positionsrandomisierung ist essentiell, nicht optional. In unseren frühen Tests ohne Randomisierung gewann die zuerst präsentierte Ausgabe 60-65 % der Evaluierungen unabhängig von der Qualität. Randomisierung brachte dies auf 48-52 %, was innerhalb des Rauschens liegt.
Zwei Judges erkennen die meisten Meinungsverschiedenheiten. Der Wechsel von 1 auf 2 Judges verbesserte die Zuverlässigkeit dramatisch. Von 2 auf 3 Judges verbesserte sie weiter, aber mit abnehmenden Erträgen. Für die meisten Anwendungsfälle sind 2 Judges mit Kendalls-Tau-Reporting der optimale Kompromiss.
Konfidenzintervalle verändern das Verhalten. Bevor wir KI-Reporting hinzufügten, optimierten Teams für 1-2 Punkte Bewertungsunterschiede. Jetzt sehen sie überlappende Intervalle und interpretieren sie korrekt als „kein bedeutsamer Unterschied.” Das spart Engineering-Zeit, die sonst für die Verfolgung von Rauschen aufgewendet würde.
Strukturierte Ausgabe-Schemas machen die Evaluierung zuverlässig. Frühe Versionen verwendeten freiformatige Judge-Antworten und parseten Bewertungen mit Regex. Dies brach ständig zusammen — Modelle fügten Erklärungen hinzu, verwendeten unterschiedliche Formate oder übersprangen Kriterien. Der Wechsel zu Zod-validierter strukturierter Ausgabe eliminierte Parsing-Fehler vollständig.