Ein Bayes’sches Framework für A/B Tests von AI Agents

AI Agents zu evaluieren, ist alles andere als einfach. Agent-Builder, Architekt:innen, Engineers und Forschende erleben das täglich in der Praxis. Bereits eine Anpassung am Prompt oder in einem Dialogschritt verändert die Metriken – manchmal deutlich. Wird dieselbe Simulation erneut ausgeführt, bleiben die Ergebnisse oft nicht stabil. Das liegt in der Natur stochastischer, mehrschichtiger Systeme.

Ohne fundierte (statistische) Methoden zur Einordnung dieser Schwankungen lässt sich schwer sagen, ob eine Änderung den Agent wirklich verbessert hat oder ob er diesmal nur besser scheint.

Deshalb haben wir ein Framework entwickelt, das statistische Präzision in die Evaluierung von AI Agents bringt.

Auf einen Blick

Wir stellen ein hierarchisches Bayes’sches Modell für A/B-Tests von AI Agents vor. Es kombiniert deterministische, binäre Metriken mit Bewertungen und LLM-Judge-Scores in einem einzigen Framework, das Variationen über verschiedene Gruppen hinweg berücksichtigt.

Kürzlich haben wir dieses Modell genutzt, um GPT-4.1 und GPT-4o in Kundenservice-Simulationen zu vergleichen. Dabei zeigte sich nicht nur, welcher Agent insgesamt besser abschnitt, sondern auch, wo ihre jeweiligen Stärken in verschiedenen Szenarien lagen. Weil das Modell explizit Unsicherheiten und Unterschiede – etwa bei Kunden-Intents und Use Cases – in verschiedenen Aufgabentypen einbezieht, liefert es Teams eine fundiertere Entscheidungsgrundlage für den Einsatz des passenden Agents.

Das Modell steht noch am Anfang, aber die Ergebnisse sind vielversprechend. In den kommenden Monaten werden wir das Framework weiter stresstesten, um sicherzustellen, dass es der Last standhält, und zu prüfen, wie wir es in unsere Plattform integrieren können – damit unsere Partner ihre Lösungen schneller und mit noch mehr Sicherheit entwickeln können.

Die Herausforderung, AI Agents zu evaluieren

Viele Evaluierungen von AI Agents – selbst in wissenschaftlichen Veröffentlichungen, wie schon oft kritisiert – stützen sich noch immer auf Einzelwerte, ohne Unsicherheiten oder Variabilität zu berücksichtigen. Das bedeutet: keine Fehlerbalken, Konfidenzintervalle, kein Gefühl dafür, wie sich Ergebnisse in verschiedenen Durchläufen oder Szenarien verändern könnten. Dies flacht Daten ab und blendet wichtige Details aus – etwa, wo der Agent stark performt oder wo er Schwierigkeiten hat.

Dieser Ansatz mag funktionieren, wenn man nur prüft, ob ein Agent in einem einfachen Test-Set korrekt geantwortet hat – also einem vordefinierten, limitierten Set von Beispiel-Inputs und erwarteten Outputs. Zum Beispiel könnte eine Kundin fragen „Was sind Ihre Öffnungszeiten?“ und der erwartete Output ist eine Standard-Protokoll-Antwort. Entweder der Agent gibt die Antwort oder nicht.

Doch im realen Einsatz reicht das nicht. Denn Nutzer:innen formulieren Dinge unerwartet, wechseln Themen, zeigen Emotionen oder Dringlichkeit – und erfordern häufig eine Multi-Turn-Logik.

Angenommen, du evaluierst einen Kundenservice-Agent lediglich mit einer Checkliste aus „bestanden/nicht bestanden“ oder indem du ein paar Beispielgespräche manuell überprüfst. Dann erhältst du nur einen Ausschnitt dessen, wie echte Kundenkonversationen verlaufen. Du kannst offensichtliche Fehler erkennen, aber keine Nuancen:

• Wie lassen sich einfache Ja/Nein-Ergebnisse mit subjektiveren, abgestuften LLM-Scores kombinieren, etwa wie natürlich der Agent klingt oder wie hilfreich er ist?

• Was, wenn derselbe Agent je nach Gesprächstyp oder User-Intent unterschiedlich performt?

• Und woher weißt du, ob diese Leistungsunterschiede verlässlich sind – oder bloßer Zufall?
  
  

Das sind entscheidende Fragen für AI-Systeme im produktiven Betrieb. Sie beeinflussen, wie schnell Teams neue Versionen ausrollen können, wie sich Interaktionen mit Agents für Kund:innen anfühlen und ob tatsächlich Performance-Verbesserungen vorliegen. Doch heutige Evaluierungs-Pipelines sind meist nicht darauf ausgelegt, diese Fragen zu beantworten.

Unser Ansatz: ein hierarchisches Bayes’sches Modell

Klassische A/B-Tests behandeln alle Ergebnisse gleich, unabhängig vom Kontext. Das wird zum Problem, wenn es um die Evaluierung von AI Agents geht. Denn deren Performance kann sich je nach Gesprächstyp, Kund:in oder Situation verändern. Wer alle Ergebnisse in einen Topf wirft, übersieht diese Unterschiede.

• Unsere Methode verwendet ein hierarchisches Bayes’sches-Modell mit partiellem Pooling (Partial Pooling), um beide Arten von Variation zu erfassen (und so ein realistischeres Bild der Agent-Performance zu erhalten). Dabei berücksichtigten wir:

• Unterschiede innerhalb von Gruppen, zum Beispiel, wie ein Agent in ähnlichen Szenarien performt

• Unterschiede zwischen Gruppen, zum Beispiel, wie sich die Leistung über verschiedene Gesprächstypen hinweg verändert.
  
  

Beides fließt in ein einheitliches Framework, das die Komplexität realer Interaktionen widerspiegelt.

„Auch wenn diese Art von Modellierung in der akademischen Statistik gängig ist, wird sie bei der LLM-Agent-Evaluierung selten eingesetzt – vor allem nicht im Produktivbetrieb.

Das Neue an unserem Ansatz ist zudem, wie wir binäre Ergebnisse – etwa ‘Hat der Agent den Namen des Kunden bestätigt?’ – mit subjektiven Bewertungen von LLM-Judges kombinieren, beispielsweise Qualitätsbewertungen auf einer Skala von 1 bis 7.”

Der entscheidende Unterschied ist, dass wir die Evaluierung als probabilistisches Problem behandeln und nicht nur als Gewinn-Verlust-Bilanz. Statt also zu fragen „Welcher Agent hatte die höhere Erfolgsquote?" fragen wir „Wie sicher sind wir, dass ein Agent besser performt – und in welchen Szenarien, in welchen Metriken?"

Unser Modell erfasst:

1. Binäre Checks

Manche Evaluierungskriterien sind eindeutig, zum Beispiel ob der Agent nach dem Kundennamen gefragt hat. Das ist ein simples Ja oder Nein. In einfachen Szenarien könnte man einfach zählen, wie oft das passiert, und es dabei belassen. Doch sobald Gespräche variieren (etwa in verschiedenen Use Cases), funktioniert dieser Ansatz nicht mehr.

Stattdessen nutzen wir ein statistisches Modell (konkret: Beta-Binomial), das sowohl schätzt, wie häufig eine Aktion auftritt, als auch wie sicher wir uns bei dieser Rate sind – und dabei verschiedene Gesprächstypen berücksichtigt.

So entsteht ein klareres Bild davon, wie konsistent der Agent ist, und nicht nur, wie hoch der Prozentwert ausfällt.

2. LLM-Judge-Scores

LLM-Judges sind Modelle, die bewerten, wie gut ein anderes Modell performt hat. Zum Beispiel:

„Hat der Agent den Anrufenden begrüßt?“ – und GPT antwortet möglicherweise „Ja.“

Doch dieses „Ja“ ist nicht immer so eindeutig, wie es klingt. Diese Modelle arbeiten mit Token-Wahrscheinlichkeiten. Das heißt: Auch wenn die Antwort „Ja“ lautet, könnte das Modell beiden Optionen – „Ja“ und „Nein“ – fast dieselbe Wahrscheinlichkeit zuweisen, je nach Formulierung oder Mehrdeutigkeit.

Im Hintergrund lag das Modell vielleicht bei 51% „Ja“ und 49% „Nein“. Es gab eine klare Antwort, war sich aber nicht sicher.

Das ist wie jemanden, der sich nicht sicher ist, nach dem Weg zu fragen. Die Person sagt vielleicht „Ich glaube, es geht nach links", aber man merkt, dass sie nur geringfügig überzeugter von dieser Antwort ist als von der Alternative. Die Worte klingen entschlossen, aber die Überzeugung dahinter ist schwach.

Unser Framework nimmt diese Antwort nicht einfach für bare Münze, sondern modelliert die zugrunde liegende Unsicherheit. Das hilft dir zu erkennen, wann sich ein Agent möglicherweise auf wackeligen Bewertungen durchmogelt, selbst wenn der Score oberflächlich gut aussieht.

3. Szenario-Gruppen

Manche Agents performen in bestimmten Situationen besser. Vielleicht ist einer hervorragend bei Abrechnungsfragen, hat aber Schwierigkeiten bei Kündigungen. Die meisten Evaluierungssysteme ignorieren diese Variation entweder komplett oder isolieren sie vollständig.

Wir machen beides nicht.

Unser Modell gruppiert Gespräche nach Szenarien und nutzt „Partial Pooling”, um statistische Aussagekraft über Gruppen hinweg zu teilen, ohne sie zu vermischen. So reduzieren wir das Risiko, Ergebnisse aus kleinen Stichproben oder Sonderfällen überzuinterpretieren. Ein Modell, das in einem Bereich stark, in einem anderen aber schwächer ist, wird dadurch weder unfair begünstigt noch benachteiligt.

Warum Partial Pooling entscheidend für faire Evaluierung ist

Ohne die Gruppierung nach Szenarien besteht die Gefahr, falsche Schlüsse zu ziehen.

Nehmen wir ein Modell, das vergisst, nach der Rolle des Users zu fragen. In manchen Fällen, etwa beim Einrichten von Benutzerrechten, ist das ein kritischer Fehler. In anderen – zum Beispiel bei einer allgemeinen Produktanfrage – ist das nicht wichtig. Aber wenn wir alle Szenarien gleich behandeln, bestrafen wir das Modell womöglich für ein „Fehlverhalten“, das nur in einigen Kontexten tatsächlich eines ist.

Stell dir vor, du vergleichst Testergebnisse von zwei sehr unterschiedlichen Schulen:

• Die eine verfügt über gute finanzielle Mittel, hat kleine Klassen, Laptops für alle Schüler:innen und Tutor:innen auf Abruf.

• Die andere ist unterfinanziert, überfüllt und hat keinen Zugang zu vergleichbarer Infrastruktur.

Wenn ein Schüler von jeder Schule 85% in derselben Prüfung erzielt, sagt ein flacher Vergleich: „Beide haben gleich gut abgeschnitten.“ Doch der Kontext erzählt eine andere Geschichte: Diese 85% könnten für den Schüler aus der gut ausgestatteten Schule unter den Erwartungen liegen und für den Schüler mit deutlich weniger Unterstützung weit darüber.

Ein gepooltes Modell würde beide Ergebnisse gleich behandeln. Ein hierarchisches Modell mit Partial Pooling hingegen würde den Kontext erkennen und sagen:

„Angesichts der verfügbaren Ressourcen hat der zweite Schüler überperformt, und der erste blieb möglicherweise unter den Erwartungen."

Indem wir Szenario-Gruppen explizit modellieren:

• Reduzieren wir falsch-positive Ergebnisse beim Modellvergleich

• Quantifizieren wir Variation über verschiedene Kunden-Absichten hinweg

• Bilden wir die Unsicherheit ab, die reale Gespräche enthalten

Genau das macht Partial Pooling in der LLM-Evaluierung: Es berücksichtigt szenariospezifische Erwartungen, anstatt alles in einem globalen Benchmark zu glätten.

Wie sieht das hierarchische Bayes’sche-Modell in der Praxis aus?

Um das Framework zu testen, führten wir einen direkten Vergleich zwischen GPT-4.1 und GPT-4o durch. Unser Ziel war nicht, einen Gewinner zu küren, sondern das Framework stresszutesten und zu sehen, wie gut das Modell mit komplexen Szenarien umgeht.

Wir nutzten zwei realitätsnahe Simulationen:

• Eine basierend auf Kundengesprächen eines europäischen Versicherungsunternehmens

• Eine andere auf Basis von Prompt-Varianten für den Callcenter-Agent einer globalen Reiseplattform

In beiden Fällen evaluierten wir die Agents mit demselben Ansatz wie zuvor: einer Kombination aus Bestanden-/Durchgefallen-Checks mit LLM-Judge-Scores. Zusätzlich gruppierten wir die Gespräche nach Szenario-Typ (wie Abrechnung, Onboarding oder Kündigungen), um abzubilden, wie die Leistung in der Praxis variiert.

GPT-4.1 vs. GPT-4o bei der Simulation von Versicherungsszenarien

Für die Simulation verwendeten wir über 100 reale Kundengespräche und erstellten zehn Varianten jedes Dialogs, um die natürliche Variabilität abzubilden, wie Nutzer:innen dasselbe Anliegen ausdrücken.

Anschließend nutzten wir das Bayes’sche Modell, um die Wahrscheinlichkeit zu schätzen, mit der GPT-4.1 GPT-4o bei einer Reihe spezifischer Aufgaben übertraf.

• Ein Wert nahe 1 bedeutet, dass GPT-4.1 bei dieser Aufgabe durchgängig besser abschnitt als GPT-4o.

• Ein Wert nahe 0 zeigt, dass GPT-4o die bessere Performance lieferte.

• Werte um 0,5 deuten auf keinen nennenswerten Unterschied hin

Von dort aus hat das Modell seinen Job gemacht: Es schätzte die Wahrscheinlichkeit, dass GPT-4.1 GPT-4o übertraf – nicht nur insgesamt, sondern innerhalb jedes Szenarios. Die folgende Tabelle fasst zusammen, wie die beiden Agents bei zentralen Metriken abgeschnitten haben:

Posterior-Wahrscheinlichkeit, dass GPT-4.1 GPT-4o in einem simulierten Versicherungsszenario über fünf Metriken hinweg übertrifft. Höhere Werte zeigen eine größere Sicherheit für den Vorteil von GPT-4.1.

Diese Tabelle zeigt sowohl klare Performance-Unterschiede als auch Bereiche, in denen die Datenlage tatsächlich unsicher ist. Beispielsweise übertrifft GPT-4.1 GPT-4o konstant bei Aufgaben wie der Abfrage einer Policennummer.

Auf der anderen Seite fokussiert sich eine Metrik wie „Nachrichten an User enthalten keinen Code" auf die Sauberkeit der Ausgabe. Die Kennzahl markiert Fälle, in denen ein Agent versehentlich unbeabsichtigten Code oder Formatierungsartefakte in seine Antwort einbaut, etwa rohe HTML-Tags, nicht gerenderte Template-Variablen oder System-Anweisungen.

Diese Probleme mögen auf den ersten Blick unbedeutend wirken, doch sie beeinträchtigen das Kundenerlebnis. In diesem Fall ergab das Bayes’sche Modell eine Posterior-Wahrscheinlichkeit von rund 0,495 – das bedeutet, dass das Modell keine klare Tendenz in die eine oder andere Richtung aufweist.

Diese Mehrdeutigkeit ist wertvoll. Denn statt so zu tun, als gäbe es einen klaren Gewinner, zeigt das Framework, wann die Evidenz – ob GPT-4.1 oder GPT-4o besser darin ist, das Problem zu vermeiden – schlichtweg noch nicht aussagekräftig genug ist.

Warum beeinflusst die Szenario-Gruppierung, wie sicher das Modell in seiner Bewertung ist?

Wenn wir Szenarien nicht gruppieren – also alle Gespräche gleich behandeln, wie bei einer einfachen, nicht-hierarchischen Evaluierung –, wird das Modell übermäßig selbstsicher. Es könnte einen großen Unterschied zwischen Agents anzeigen, selbst wenn dieser Unterschied nur bei einem ganz bestimmten Aufgabentyp auftritt.

Nimm die Grafik unten: Das Modell behauptet einen sehr starken Unterschied zwischen Agents, wenn wir evaluieren, ob sie nach der Rolle des Anrufenden gefragt haben. Die Verteilungen für GPT-4.1 und GPT-4o überschneiden sich kaum, was auf eine nahezu vollständige Sicherheit hindeutet.

Aber das ist irreführend, denn diese „klare Trennung" ist ein Artefakt davon, dass die Szenario-Struktur ignoriert wird.

Das vereinfachte Modell zeigt überschätzte Gewissheit, weil es Gruppenunterschiede ignoriert. Das hierarchische Modell liefert eine vorsichtigere, realistischere Einschätzung.
Umgekehrt wird das Modell vorsichtiger, wenn wir nach Szenarien gruppieren (wie „Abrechnung" vs. „Onboarding"). Das siehst du in der nächsten Grafik. Die Ergebnisse für jeden Agent liegen näher beieinander, und es gibt mehr Überschneidung zwischen ihnen.


Dieselbe Metrik mit dem hierarchischen Modell. Die posteriore Überschneidung ist größer und spiegelt die reale Gruppenvariation wider.
Diese Überschneidung ergibt sich aus den Posterior-Verteilungen, die das Modell für die Leistung jedes Agents berechnet. Wenn sich diese Verteilungen überlappen, signalisiert das Modell Unsicherheit – und das ist gut. Es bedeutet, dass wir keine voreiligen Schlüsse auf Basis eines einzigen, kleinen Datenausschnitts ziehen.

Effekte auf Gruppen- und Agent-Ebene: Woher kommt die Variation?

Diese Diagramme helfen uns zu unterscheiden, woher Performance-Unterschiede stammen: Liegt es am Szenario (Gruppeneffekt), am Agent (Modelleffekt) oder an beidem?

Die Grafik unten zeigt, wie verschiedene Gesprächsszenarien – etwa solche mit Tool-Call-Flows – die Performance bei Zwischennachrichten beeinflussen, zum Beispiel bei den Antworten des Agents mitten in einer Aufgabe, wo er den User anleiten oder eine Aktion ausführen muss. Jeder Punkt repräsentiert eine bestimmte Gruppe, und die vertikalen Balken zeigen die Unsicherheit bezüglich des Effekts dieser Gruppe. Das Histogramm auf der rechten Seite gibt die Gesamtverteilung wieder.

Kurz gesagt: Dies bestätigt, dass der Szenario-Kontext einen klaren und messbaren Einfluss auf die Qualität von Zwischennachrichten hat, was die Notwendigkeit unterstreicht, Effekte auf Gruppen-Ebene zu modellieren.

Gruppeneffekte für die Generierung von Zwischennachrichten aus über 100 Basisgesprächen (links: Unsicherheit pro Gruppe, rechts: Verteilung über Gruppen hinweg). Verdeutlicht, wie Simulationsszenarien reale Performance-Variation erzeugen.
Vergleich auf Agent-Ebene über fünf Metriken, der sowohl die mittleren Wahrscheinlichkeitsunterschiede (oben) als auch die Effektstärken (unten) zwischen GPT-4.1 und GPT-4o zeigt. Enthält 95% Kredibilitätsintervalle. Grüne Balken spiegeln hoch zuverlässige Ergebnisse wider; rote Balken zeigen Leistungsdefizite.
Jetzt quantifizieren wir den Unterschied zwischen den Agents für jede Metrik. Die obere Grafik zeigt die mittlere Wahrscheinlichkeitsdifferenz (z.B. „GPT-4.1 fragte mit 13,7% höherer Wahrscheinlichkeit nach einer Policennummer“), inklusive Kredibilitätsintervalle. Die untere Grafik übersetzt dies in die Effektstärke (Cohens d), um zu veranschaulichen, wie signifikant und wie zuverlässig der Unterschied ist.

Zusammen zeigen diese Darstellungen, dass die gemeinsame Modellierung von Agent- und Gruppeneffekten ein verlässlicheres Bild der realen Leistung liefert, insbesondere wenn Entscheidungen von nuancierten Unterschieden und nicht nur von reinen Erfolgsquoten abhängen.

Wir validierten das Modell mit demselben Agent

Um das Framework zu validieren, führten wir auch A/B-Tests mit derselben Agent-Konfiguration durch. Dabei verwendeten wir Daten, die sowohl innerhalb derselben Szenario-Gruppen als auch gruppenübergreifend gezogen wurden. Wir wollten falsch-positive Ergebnisse überprüfen.

In einem Test entnahmen wir Stichproben aus denselben Szenario-Gruppen. In einem anderen mischten wir verschiedene Gruppen. Wenn das Modell korrekt arbeitet, sollten beide Tests keinen großen Unterschied zeigen, da sich der Agent nicht verändert hat.

Aber das traf nur auf das hierarchische Modell zu, das Unterschiede auf Gruppenebene einbezieht. Das einfache Modell, das davon ausgeht, dass alle Datenpunkte unabhängig und identisch verteilt (i.i.d.) sind, fehlinterpretierte natürliche Unterschiede zwischen den Szenario-Gruppen als Beleg dafür, dass sich das Verhalten des Agents verändert habe – obwohl das nicht der Fall war. Es berücksichtigte die Variation auf Gruppenebene nicht, was zu übermäßig selbstsicheren Ergebnissen führte, die nicht der Realität entsprachen.

Sonderfälle bei der Evaluierung eines Travel-Agents

Wir haben einen überarbeiteten Prompt getestet, der das Verhalten des Agents einer Reiseplattform verbessern soll, wenn ein Anrufender auflegt. Die Änderung entstand im Rahmen eines internen Iterationsprozesses, und wir führten Simulationen durch, um zu evaluieren, ob es einen messbaren Unterschied machte.

Wir nutzten zwei Test-Sets:

• Einen mit 30 gruppierten Szenarien, die auf realen „allgemeinen” Use Cases basieren, jeweils zehn Mal simuliert (30×10)

• Einen zweiten mit 100 nicht gruppierte Simulationen, die sich auf Fälle mit „unklarem Intent” fokussieren, wenn die Bedürfnisse des Anrufenden schwerer zu interpretieren sind
  
  

Performance-Vergleich zwischen GPT-4.1 und GPT-4o bei der Erkennung von Auflegeverhalten.
Der überarbeitete Prompt führte zu spürbaren Verbesserungen beim Umgang mit dem Beenden von Gesprächen in den allgemeinen Use Cases, zeigte jedoch keine Wirkung im Szenario mit unklarer Absicht. Das entspricht unseren Erwartungen: Wenn der Intent mehrdeutig ist, kann selbst ein stärkerer Prompt nichts ausrichten.

Allerdings lag das Konfidenzintervall für die beobachtete Verbesserung im allgemeinen Case nicht vollständig oberhalb von null. Das Modell zeigte zwar einen wahrscheinlichen Nutzen, signalisierte aber auch eine gewisse Unsicherheit, was eine wichtige Erinnerung daran ist, den Impact nicht aufgrund früher Ergebnisse zu überschätzen.

Ein bewusst vorsichtiges Modell

Wir haben das Modell so definiert, dass es standardmäßig vorsichtig agiert. Das bedeutet, es geht davon aus, dass die Unterschiede zwischen Agents gering sind – es sei denn, die Daten zeigen eindeutig etwas anderes.

• Wir wenden eine starke Shrinkage auf Agent-Effekte an, sodass das Modell Performance-Schätzungen in Richtung Durchschnitt zieht, sofern keine starken Gegenbeweise vorliegen.

• Wir verwenden breite Priors für Variationen auf Gruppenebene und überlassen es den Daten zu bestimmen, wie stark die Leistung tatsächlich in verschiedenen Szenarien variiert.

• Wir behandeln LLM-evaluierte Scores mit Vorsicht, da sie subjektiv und anfälliger für Störfaktoren sind.

Gemeinsam verhindern diese Entscheidungen, dass das Modell auf zufällige Schwankungen überreagiert. Wenn es einen Agent als besser einstuft, dann deshalb, weil es sehr wahrscheinlich ist, dass er besser ist, etwa weil die Evidenz stark ist – nicht, weil er bei einer Stichprobe Glück hatte.

Laufende Modell-Evaluierung bei wachsender Datenbasis

Unser Bayes’sches Modell unterstützt auch inkrementelle Updates. Da neue Simulationsdaten hinzukommen, passen sich die Posterior-Verteilungen an. Der Test muss nicht neu gestartet werden. Das macht den Ansatz ideal für Produktivumgebungen, in denen kontinuierlich Modellvergleiche laufen und Deployment-Risiken gesteuert werden müssen.

Man kann es sich wie eine Live-Anzeigetafel vorstellen, die im Verlauf des Spiels immer präziser wird. Du musst nicht bis zum Ende warten, um eine Entscheidung zu treffen, da du schon früh sehen kannst, in welche Richtung sich die Ergebnisse entwickeln und wie belastbar sie sind.

Wir können diese Resultate in operativen Kennzahlen ausdrücken. Ein Ergebnis könnte beispielsweise lauten:

„Agent B hat eine Wahrscheinlichkeit von 93%, Agent A bei Prompts zur Nutzerführung zu übertreffen. Der Unterschied in den Fehlerraten wird auf 2,1% bis 4,3% geschätzt (glaubwürdiges Intervall).“

Dies sind die Antworten, die Engineering-Teams und Produktverantwortliche benötigen, um fundierte Entscheidungen für den Go-Live zu treffen.

Statistische Bescheidenheit ist essenziell für einen verantwortungsvollen Einsatz von AI

Bei Parloa werden unsere fortlaufende Forschung und Entwicklung (R&D) sowie Produktverbesserungen von einem tiefen Verantwortungsbewusstsein geleitet.

Dieses neue Evaluierungs-Framework basiert auf der Prämisse, dass Unsicherheit, Kontext und Zurückhaltung keine Fehler, sondern wesentliche Merkmale eines verantwortungsvollen Evaluierungsprozesses sind. Anstatt aus ersten Signalen oder zufälligen Schwankungen Schlüsse zu ziehen, verankern wir in jeder Ebene unserer Analyse ein hohes Maß an Vorsicht.

Mit diesem Bayes’schen Modell wollen wir Engineering-Teams und Product Leadern Gewissheit über die Performance der AI Agents geben – auf Basis von Wahrscheinlichkeiten, nicht von Behauptungen. Unsere Vision ist, dass jede:r AI Agent Builder beim Ausrollen von Modellen auf einen Blick erkennen kann:

• Wie stark ein Ansatz einem anderen in operativen Kennzahlen überlegen ist

• Nicht nur, ob eine Änderung „im Durchschnitt funktioniert", sondern wo, warum und mit welcher Zuverlässigkeit sie dies tut

• Wo mehr Daten oder Testing erforderlich sind, bevor eine Änderung ausgerollt und skaliert wird

Indem wir diese Methodik in unsere internen Tools integrieren, setzen wir einen neuen Standard dafür, wie agentische Systeme im Produktivbetrieb evaluiert und vertrauenswürdig gemacht werden.

Wir sind überzeugt, dass wir dadurch, dass wir die Messlatte höher legen, bessere und menschlichere AI mit noch mehr Sicherheit ermöglichen – bereit, das Vertrauen von Millionen Nutzer:innen weltweit zu gewinnen. Wir freuen uns darauf, mit der AI-Community zusammenzuarbeiten, um diesen Ansatz gemeinsam weiterzuentwickeln, zu verfeinern und auszubauen.