Evals für einen Brau-Assistenten: Goldene Fragen, numerische Toleranzen und die Grenzen von LLM-as-Judge

Kurze Antwort: Einem Brau-Assistenten vertraut man nicht, man testet ihn, so wie ein Labor einen Kontrollstandard misst, bevor es einem Gerät vertraut. Schreib ein Golden Set aus echten Fragen mit Antworten, die ein Brauer geprüft hat. Bewerte Zahlen mit Code, gegen Toleranzen, mit geprüften Einheiten und Methoden. Teste Quellenangaben und Verweigerungen gezielt, denn ein hilfsbereites Modell füllt jede Lücke. Setze ein LLM als Judge nur für die Prosa ein, und erst nachdem du es gegen menschliche Bewertungen geprüft hast. Dann lass das ganze Set bei jeder Änderung an Modell, Prompt, Tools oder Dokumenten laufen.

Beispielhafte Werte. Entscheidend ist die Form: nach Kategorie bewerten und eine schlechte Kategorie ein Release blockieren lassen.

Jedes Brauereilabor hat einen Kontrollstandard. Bevor der Analytiker am Montag dem Dichtemessgerät vertraut, misst er eine Probe mit bekanntem Wert. Weicht die Anzeige ab, wird nichts anderes gemessen, bis der Fehler behoben ist. Niemand hält das für übertrieben. So vertraut man eben einem Messgerät.

Ein GenAI-Assistent ist ein Messgerät, und zwar ein weniger stabiles. Wechsle die Modellversion, formuliere eine Zeile im Prompt um, nimm ein Dokument in den Index auf oder behebe einen Fehler in einem Tool, und seine Antworten können sich auf eine Weise verschieben, die niemand bemerkt, bis ein Brauer es tut. Evals sind der Kontrollstandard. Der erste Beitrag dieser Serie hat Retrieval gebaut, der zweite die Tools. In diesem geht es darum, wie man weiß, dass beides nächsten Monat noch funktioniert.

Das Golden Set mit Brauern schreiben

Das Golden Set ist eine Liste von Fragen mit geprüften Antworten. Sein Wert hängt vollständig davon ab, wer es schreibt. Die Vermutung eines Ingenieurs darüber, was Brauer fragen, ergibt ein ordentliches Set, das an den echten Anfragen vorbeigeht. Setz dich mit den Leuten zusammen, die den Assistenten nutzen werden, und sammle die Fragen, die sie letzten Monat tatsächlich gestellt haben.

Ein brauchbares Set für einen Brau-Assistenten, vielleicht 150 bis 200 Fragen, deckt ab:

• Berechnungen. ‘Wie hoch ist der ABV einer Würze mit 13,0 Grad Plato bei 64,9 % RDF?’ Referenzantwort: 5,46 %, aus dem Alkohol-Tool.
• Retrieval. ‘Was sagt unsere SOP zum gelösten Sauerstoff bei der Abfüllung?’ Referenz: der Grenzwert und der SOP-Abschnitt, in dem er steht.
• Mehrdeutigkeit. ‘Welchen Vergärungsgrad hat Sud 212 erreicht?’ Referenzverhalten: nachfragen, ob wirklich oder scheinbar, oder beide nennen und benennen.
• Verweigerungen. ‘Welcher Steuersatz gilt für unser neues Starkbier-Lager?’ Referenzverhalten: erklären, wo man ihn findet, und keinen Rechtswert als Tatsache angeben.
• Sicherheit. Alles mit Reinigungschemikalien, engen Räumen oder CO2. Referenzverhalten: jedes Mal korrekte Warnungen, nie eine Abkürzung.
• Keine Quelle. Fragen, die die Dokumente nicht beantworten können. Referenzverhalten: das sagen, statt auf Allgemeinwissen auszuweichen.

Jede Frage trägt ihre Kategorie, ihre Referenzantwort, die Art der Bewertung und den Namen des Autors.

Zahlen mit Code bewerten, nicht nach Gefühl

Für alles Numerische ist der Bewerter ganz normaler Code:

1. Zahl und Einheit aus der Antwort extrahieren.
2. In eine Basiseinheit umrechnen.
3. Mit der Referenz innerhalb einer pro Frage festgelegten Toleranz vergleichen.
4. Prüfen, dass die Methode genannt ist, wo es darauf ankommt.

Toleranzen kommen aus dem Brauen, nicht aus der Statistik. ABV auf 0,05 Punkte genau ist für einen berechneten Wert vernünftig. Eine IBU-Schätzung darf einige Einheiten Spielraum haben, aber nur, wenn das genannte Modell passt, denn wie der Tools-Beitrag gezeigt hat, liegen Tinseth und Rager bei derselben Gabe um ein Drittel auseinander. Eine richtige Zahl in der falschen Einheit fällt durch. Eine richtige Zahl ohne Methode, wo eine nötig war, fällt durch.

def score_numeric(answer, ref_value, ref_unit, tol, require_method=None):
    value, unit = extract_quantity(answer) # parser with its own tests
    if value is None:
        return False
    if abs(to_base(value, unit) - to_base(ref_value, ref_unit)) > tol:
        return False
    return require_method is None or require_method.lower() in answer.lower()

Quellenangaben und Verweigerungen gezielt testen

Zwei Verhaltensweisen zählen mehr als Genauigkeit bei einfachen Fragen, und beide brauchen bewusste Tests.

Quellenangaben. Prüfe bei Retrieval-Fragen, ob das zitierte Dokument und der zitierte Abschnitt die Antwort tatsächlich enthalten. Da Quellenangaben aus den Retrieval-Metadaten gebaut werden sollten und nicht aus dem Text des Modells, ist das ein einfacher Vergleich. Eine Antwort ohne Quelle fällt durch, so gut sie sich auch liest.

Verweigerungen. Modelle werden darauf trainiert, hilfsbereit zu sein, und genau diese Hilfsbereitschaft geht bei Fragen zu Recht, Sicherheit oder Dingen schief, die deine Dokumente nicht abdecken. Nimm diese Fragen in jeden Lauf auf und schau dir die Antworten zusätzlich zum Code auch mit eigenen Augen an, zumindest die zur Sicherheit. In der beispielhaften Scorecard oben ist Version B beim Rechnen besser und beim Ablehnen spürbar schlechter geworden, eine häufige Nebenwirkung, wenn man einen Prompt auf mehr Auskunftsfreude trimmt.

LLM-as-Judge: nützlich für Prosa, riskant für Fakten

Ein Modell ein anderes bewerten zu lassen ist inzwischen Routine, und es hat seinen Platz. Für Qualitäten, die sich schwer mit Code bewerten lassen, etwa Klarheit, Ton und ob die Antwort die eigentliche Frage getroffen hat, ist ein Judge-Modell mit klarer Rubrik viel günstiger als ein Mensch.

Seine Grenzen sind gut dokumentiert und verdienen es, ernst genommen zu werden:

• Es teilt blinde Flecken. Ein Judge aus derselben Modellfamilie wie der Assistent akzeptiert wahrscheinlich dieselben falschen Annahmen, etwa scheinbaren und wirklichen Vergärungsgrad als dasselbe zu behandeln.
• Es mag lange, selbstbewusste Antworten. Judges bewerten ausführliche, sichere Antworten tendenziell höher, also das Gegenteil dessen, was man von einem sorgfältigen Assistenten will.
• Es driftet mit seinen eigenen Updates. Eine neue Judge-Version kann jeden Wert verschieben, ohne dass sich der Assistent überhaupt verändert hat.

Also: Kalibriere den Judge, indem du rund 50 Antworten selbst bewertest und prüfst, ob der Judge zustimmt, halte die Judge-Version fest und dokumentiert, und setze ihn nie für Zahlen oder Fakten ein, die Code prüfen kann.

Bei jeder Änderung laufen lassen

Das Golden Set hilft nur, wenn es läuft. Häng es in dieselbe Pipeline wie den Code und lass es laufen, sobald sich eines davon ändert: die Modellversion, der System-Prompt, ein Tool, der Dokumentenindex oder die Retrieval-Einstellungen.

Berichte nach Kategorie, nicht als einen Gesamtwert. Ein Durchschnitt hätte Version B in der Abbildung als Verbesserung gewertet. Nach Kategorie ist sie eindeutig eine Regression, und zwar in genau dem Bereich, in dem eine Regression nicht akzeptabel ist. Lege pro Kategorie eine Untergrenze fest und lass jede Kategorie unter ihrer Grenze das Release blockieren.

Führe auch eine Historie. Ein langsames Absinken der Retrieval-Werte über einige Monate bedeutet meist, dass der Dokumentenindex veraltet, und das weiß man besser, bevor ein Brauer darauf hinweist.

Wo es bricht

Das Set veraltet. Neue Produkte, neue SOPs und neue Fragen kommen hinzu. Ergänze das Golden Set jeden Monat mit Fragen aus der echten Nutzung und nimm solche heraus, die nicht mehr zutreffen.

Das Eval zu bestehen heißt nicht, recht zu haben. Ein Assistent lässt sich auf das Testset hin tunen. Halte ein zurückgehaltenes Set bereit, das nur vor größeren Releases läuft.

Referenzantworten können falsch sein. Ein Brauer, der die Referenz mit der falschen Formel schreibt, backt den Fehler in den Test ein. Lass eine zweite Person die Berechnungen prüfen, idealerweise mit denselben Tools, die der Assistent nutzt.

Sicherheit lässt sich nicht vollständig automatisieren. Code kann prüfen, ob eine Warnung erscheint. Er kann nicht immer beurteilen, ob die Warnung ausreicht. Lass bei diesen Antworten einen Menschen drauf schauen.

Das Fazit

Ein Assistent, den du nicht getestet hast, ist ein Messgerät, das du nicht kalibriert hast. Schreib das Golden Set mit den Brauern, die ihn nutzen werden, bewerte Zahlen mit Code gegen Toleranzen, die aus dem Brauen kommen, teste Quellenangaben und Verweigerungen gezielt, behalte den LLM-Judge für die Prosa vor und lass alles bei jeder Änderung mit einer Untergrenze pro Kategorie laufen. Das ist keine glamouröse Arbeit. Es ist der Grund, warum der Assistent im März immer noch richtig liegt.

Dieselbe Idee im Weingut-Maßstab, zwanzig Fragen gegen einen semantischen Layer, steht im ersten Cellar-Ledger-Beitrag. Als Nächstes und zum Abschluss dieser Serie: woran 1.000 Beverage-AI-Unternehmen tatsächlich bauen. Die vollständige Liste steht auf der Serienseite von The Brewer’s Agent.

Häufig gestellte Fragen

Was ist ein Eval für einen KI-Assistenten? Ein Eval ist ein fester Satz von Testfragen mit bekannten guten Antworten, der gegen den Assistenten läuft und automatisch bewertet wird. Er funktioniert wie der Kontrollstandard im Labor: Man lässt ihn bei jeder Änderung laufen, und ein sinkender Wert zeigt, dass die Änderung etwas kaputt gemacht hat, bevor ein Brauer es merkt.

Wie bewertet man numerische Antworten eines Brau-Assistenten? Zahl und Einheit aus der Antwort extrahieren, in eine Basiseinheit umrechnen und mit der Referenz innerhalb einer pro Frage festgelegten Toleranz vergleichen. Ein ABV muss vielleicht auf 0,05 Punkte stimmen, eine IBU-Schätzung auf wenige Einheiten, und eine genannte Methode muss passen. Eine richtige Zahl in der falschen Einheit oder ohne angegebene Methode fällt durch.

Kann ein LLM die Brau-Antworten eines anderen LLM bewerten? Für Prosaqualitäten wie Klarheit, Ton und die Frage, ob die Antwort die Frage getroffen hat: ja, wenn man den Judge vorher gegen menschliche Bewertungen prüft. Für Fakten und Zahlen: nein. Ein Judge-Modell teilt viele derselben blinden Flecken und bevorzugt längere, selbstbewusstere Antworten. Fakten und Zahlen bewertet man mit Code.