Evaluierungs-zentrierte KI-Agenten: Wie Zepto den Kundensupport auf Databricks und MLflow skaliert

Zeptos Streben nach zuverlässigem Kundensupport in Echtzeit

Zepto ist eine der am schnellsten wachsenden Quick-Commerce-Plattformen Indiens, mit mehr als Tausenden von Produkten, einer Präsenz in über 60 Städten und Lieferzeiten, die in Minuten gemessen werden. In einem Geschäft, in dem Geschwindigkeit das Produkt ist, muss der Kundensupport genauso schnell sein.

Um diese Erwartung zu erfüllen, betreibt Zepto den Kundensupport mit einem Multi-Agenten-KI-System, das über hunderttausend Tickets pro Tag verarbeitet. Anfangs konnte das Team Agenten schnell entwickeln und bereitstellen. Die schwierigere Frage war, wie diese Agenten zuverlässig bleiben, wenn das Volumen wuchs, Kategorien erweitert wurden und sich das Kundenverhalten ständig änderte. Zepto arbeitete mit Databricks zusammen, um diese Frage zu beantworten, nicht indem mehr Agenten bereitgestellt wurden, sondern indem die Evaluierung zum primären Weg gemacht wurde, wie Agenten erstellt, getestet und betrieben werden.

Dieser Blog beschreibt diese Reise: die Systemarchitektur, das Evaluierungsframework auf Databricks und MLflow, die Produktionsgeschichten, in denen es sich bewährt hat, sowie die daraus resultierenden Ergebnisse und Lehren.

Warum „Einfach den Agenten bereitstellen“ bei Skalierung scheitert

In einem schnelllebigen Geschäft funktioniert „Einfach den Agenten bereitstellen“ so lange, bis es bei Skalierung scheitert. Bei mehr als 100.000 KI-Agenten-Tickets pro Tag führt selbst eine Fehlerrate von 1 % zu Tausenden von schlechten Ergebnissen und einem echten Umsatzverlust – jeden einzelnen Tag.

Der Druck kam in ungleichmäßigen Wellen. Wetterereignisse, Diwali und der Sommerbeginn führten zu starken Spitzen im Ticketvolumen. Die Expansion von Lebensmitteln in Bekleidung, Elektronik und Kosmetik führte zu neuen Rückerstattungs-, Umtausch- und Rücksendeprozessen. Gleichzeitig brachte eine vielfältigere, mehrsprachige Kundenbasis eine breitere Palette von Supportanfragen mit sich – und alle paar Wochen traten neue Fehlermodi auf.

Das tiefere Problem ist die Sicherheitslücke. Agentensysteme arbeiten als mehrstufige Workflows – Absicht klassifizieren, Wissen abrufen, Eingaben analysieren, Entscheidungen treffen, Transaktionstools aufrufen und Antworten generieren – sodass Fehler überall auf dem Weg auftreten können, nicht nur in der endgültigen Antwort.

Diese Sicherheitslücke führte zu konkreten Problemen:

• Fehler waren unsichtbar, bis Kunden sich beschwerten
• Fehlerbehebungen waren langsam
• Die endgültige Antwort verbarg interne Fehler
• Es fehlte ein prinzipieller Weg, Kosten, Leistung und Qualität für den Agenten auszugleichen
• Das Agentendesign berücksichtigte nicht alle kritischen Stakeholder-Perspektiven
• Die Zuverlässigkeit war angesichts der schnellen Agentenentwicklung schwer zu gewährleisten

Das Ziel wurde klar: ein Evaluierungsframework auf Databricks und MLflow zu entwickeln, das als zentrale KI-Infrastruktur fungiert, auf der Agenten aufgebaut und betrieben werden.

Warum ein Evaluierungsframework und seine Ergebnisse

Ein robustes Evaluierungsframework beeinflusst direkt fünf Achsen der Produktionsreife:

• Zuverlässigkeit: Systemweite Garantien, dass Agenten über alle Schritte hinweg korrekt agieren und nicht nur „richtig klingen“
• Geschwindigkeit: Schnellere, sicherere Iteration von Prompts, Richtlinien und Modellen, da Änderungen automatisch regressiongetestet werden
• Kosten- vs. Qualitäts- vs. Leistungskontrolle: Fähigkeit, optimale Modelle, Prompt-Strategien oder hybride Routing-Strategien zu wählen, um den optimalen Punkt bei Einschränkungen zu treffen, gestützt durch harte Evaluierungsdaten
• Governance: Auditierbare Spuren, versionierte Evaluierungs-Baselines und klar definierte Schwellenwerte für Bereitstellung und Rollback. Entscheidungen werden nicht mehr aus dem Bauch heraus getroffen („diese Version fühlt sich besser an“), sondern evidenzbasiert („diese Version übertrifft die Baseline bei den vereinbarten Metriken“)
• Stakeholder-Zusammenarbeit: Erfassung von Erfolgs- und Zuverlässigkeitskriterien aus der Perspektive der Stakeholder und explizite und messbare Darstellung von Kompromissen für alle

Mit Databricks + MLflow als Evaluierungs-Backbone und einer Evaluierungs-First-Agentenarchitektur erreichte Zepto

Kosten & Effizienz

• 80% und mehr Tickets vollständig von KI-Agenten mit menschlicher Aufsicht verwaltet
• 65% Reduzierung der Supportkosten oder Support-Tickets
• Amortisationszeit von weniger als einem Monat

Qualität & Reputation

• 20% Verbesserung der Kundenzufriedenheit (CSAT)
• 8% Verbesserung der Genauigkeit

Leistung & Betrieb

• 3x schnellere Entwicklungszyklen
• 4x schnellere Lösungszeit

Das Framework aufbauen: Eine Doppelschleife für Vertrauen und Kontrolle

Im Mittelpunkt dieses Ansatzes steht das Doppelschleifenmodell: eine Entwicklungsschleife und eine Produktionsschleife, verbunden durch ein Qualitäts-Gate. Dieser Abschnitt beschreibt, wie diese Schleifen zusammenarbeiten.

• Entwicklungsschleife: Hier entwerfen, iterieren und evaluieren Sie Agentenversionen, um sie mit Vertrauen zu erstellen, bevor sie bereitgestellt werden
• Produktionsschleife: Hier überwachen Sie das Live-Verhalten und erkennen Fehler, um Agenten mit Vertrauen zu betreiben
• Feedback-Schleife: Hier werden Produktionsfehler an die Entwicklung zurückgespielt, um die nächste Iteration zu bereichern
• Qualitäts-Gate: Steuert die Bewegung zwischen den Schleifen und entscheidet, welche Versionen in die Produktion gelangen dürfen und welche für bessere Iterationen an die Entwicklung zurückgegeben werden

Zusammen stellen diese beiden Schleifen sicher, dass Agenten kontrolliert erstellt und betrieben werden. Jeder Fehler wird automatisch erfasst, zurückgemeldet und korrigiert. Dadurch werden Agenten mit Vertrauen erstellt, kontrolliert ausgeführt und kontinuierlich verbessert, um Produktionsfehler im Laufe der Zeit besser zu handhaben. Die Doppelschleife bildet den Kern unseres Frameworks.

Phase 0: Tracing aktivieren: Transparente Agenten von Design her

Jede Agenten-Invocation sendet eine detaillierte Ausführungsspur, die Prompts, Completions, abgerufene Dokumente, Tool-Aufrufe, Latenzen und Entscheidungspfade erfasst, sodass der gesamte Workflow auf granularer Ebene beobachtbar ist und nicht nur als Eingabe und Endausgabe.

Wir haben dies mit einem hybriden Ansatz unter Verwendung von MLflow ermöglicht. Eine einzelne Zeile, mlflow.<library>.autolog(), aktiviert automatisches Tracing, und der @mlflow.trace -Decorator fügt benutzerdefinierte Spans hinzu, wo immer wir mehr Details benötigen. Traces werden in Echtzeit als OpenTelemetry-Spans mit eindeutigen IDs ausgegeben, sodass sie zusammensetzbar bleiben, und die Integration von MLflow mit Unity Catalog zentralisiert die Protokollierung in Delta-Tabellen.

Phase 1: Evaluierungsdimensionen festlegen: Säulen und Gates

Nachdem das Tracing aktiviert ist, besteht der nächste Schritt darin, aus der Perspektive jedes Stakeholders zu erfassen: „Was bedeutet Erfolg für diesen Agenten für Sie?“. Wir formalisieren dies als Evaluierungssäulen, jede mit spezifischen Gates.

Dies verwandelt eine Multi-Stakeholder-Debatte in einen gemeinsamen, messbaren Vertrag. Agenten werden entlang der Dimensionen evaluiert, die für jeden Stakeholder tatsächlich wichtig sind. Typische Säulen umfassen Kundenerfahrung, operative Effizienz, Risiko und Compliance sowie finanzielle Auswirkungen; jede Säule hat klare numerische Schwellenwerte, die vor der Bereitstellung erfüllt werden müssen.

Phase 2: Der Golden Dataset: Eckpfeiler der Zuverlässigkeit

Der Golden Dataset ist die einzige Quelle der Wahrheit für die Evaluierung des Agentenverhaltens in der Entwicklungsschleife. Er sollte:

• Normale Fälle, Grenzfälle und Fehlerfälle abdecken, die der Agent handhaben muss
• Erwartungen verschiedener Stakeholder als Beispiele enthalten
• Reichhaltig mit Metadaten annotiert sein (Szenariotyp, Geschäftsbereich, Risikostufe usw.)

Alle Beteiligten arbeiten zusammen, um den Datensatz zu gestalten, zum Beispiel das Sicherheitsteam, das Beispiele für Angriffsvektoren wie Prompt-Injection, Identitätsangriffe und Datenexfiltrationsversuche beisteuert. Dies stellt sicher, dass die Zuverlässigkeit sowohl unter realen Szenarien als auch im normalen Gebrauch gemessen wird.

Datensätze sind ein lebendiges Gut, und ihre Qualität verbessert sich im Laufe der Zeit. Die Lücke zwischen Entwicklungs- und Produktionsgenauigkeit ist selbst ein Signal für die Datensatzqualität. Zepto investierte sechs Monate lang kontinuierlich in MLflow-Evaluierungsdatensätze und reduzierte die Genauigkeitslücke zwischen Entwicklung und Produktion von 8 Punkten bei 500 Beispielen auf 2 Punkte bei 2.000 Beispielen und schließlich auf 0,4 Punkte bei 5.247 Beispielen. Jede Stunde, die in die Datensatzqualität investiert wird, spart etwa zehn Stunden Produktions-Debugging. Der goldene Datensatz wird so zu einem 10-fachen Multiplikator: Jeder Produktionsfehler fügt Fehlerspuren zum goldenen Datensatz hinzu und macht das System für alle zukünftigen Versionen robuster.

Phase 3: Prompt Engineering automatisieren: Automatisch generieren und optimieren

Anstatt Prompts manuell zu schreiben, haben wir Prompt Engineering zu einem datengesteuerten, automatisierten Prozess gemacht. Prompt-Design ist die kritische Phase, in der Ingenieure die meiste Zeit verbringen, und die Qualität der Prompts hat einen unverhältnismäßig großen Einfluss auf die Qualität und Leistung der Agenten-Outputs.

Mithilfe der MLflow Prompt-Optimierung registrieren wir einen initialen Prompt, generieren und optimieren Varianten anhand derselben Scorers, die den Einsatz steuern, führen automatisch A/B-Evaluierungen durch und deployen das beste Ergebnis. Der Optimierer reflektiert mit einem starken Modell und bewertet Kandidaten in der Produktion mit einem günstigeren Modell, sodass die Suche selbst in der Produktion kostenbewusst bleibt. Dies reduzierte manuelle Prompt-Experimente, verbesserte die Genauigkeit und stellte sicher, dass Prompt-Verbesserungen immer gegen den goldenen Datensatz gemessen wurden, bevor sie in Produktion gingen.

Phase 4: Scorers definieren und KI-Jury einrichten

Da Traces im Produktionskreislauf fließen, müssen wir sie entlang der Dimensionen bewerten, die für die Agentenqualität wichtig sind (Evaluierungsdimensionen). Stellen Sie sich dies als eine KI-Jury vor, bei der jeder Scorer seine Stärken ausspielt. MLflow bietet drei Optionen zum Erstellen von Scorern.

• Integrierte Judges – sofort einsatzbereite Scorer
• Benutzerdefinierte Judges – erstellen Sie angepasste Judges, um spezifische Anforderungen zu erfüllen
• Code-basierte Scorer – für deterministische Metriken wie Tool-Latenz oder Anzahl der Tool-Aufrufe

Wir verwenden LLM-basierte Scorer nur dort, wo menschenähnliches Urteilsvermögen erforderlich ist, und verlassen uns auf einfache Regeln, wo deterministische Logik ausreicht. Wir kalibrieren die Judges anhand menschlicher Labels, um eine Übereinstimmung von 80–90 % zu erreichen, und verwenden mehrere Judges für Entscheidungen mit hohem Risiko.

Phase 5: Modell-Optionalität einrichten

Modale Optionalität ist eine kritische Komponente, die es dem Framework ermöglicht, einfach durch Ändern von Modellnamen in Databricks zwischen vielen proprietären und Open-Source-Modellen zu wechseln. Dies bedeutet, dass der Entwicklungszyklus kontinuierlich nach einer besseren Kombination suchen kann, um den besten Kompromiss zwischen Kosten, Leistung und Qualität zu finden.

Phase 6: Auto-Regression aufbauen

Wir automatisieren die Regressionsbewertung, um einen wiederholbaren, konfigurierbaren und skalierbaren Entwicklungszyklus zu schaffen. Jede Änderung löst eine Auto-Regression aus und, wenn die Zuverlässigkeit gewährleistet ist, eine Auto-Bereitstellung.

Zusammengenommen folgt eine typische Änderung diesem Pfad:

1. Jemand ändert die Logik, den Prompt oder das Modell des Agenten.
2. Der Evaluierungs-Workflow wird automatisch mit drei Eingaben ausgelöst: der neuen Agentenversion, dem goldenen Datensatz und der aktuellen Produktions-Baseline.
3. Das System führt Evaluierungen durch und erstellt Metriken über alle Scorer und Säulen hinweg.
4. Das Qualitäts-Gate prüft:
   • Erfüllt die neue Version alle Gates (Kosten, Qualität, Leistung usw.)?
   • Erbringt sie mindestens die gleiche oder eine bessere Leistung als die Produktions-Baseline?
5. Wenn ja, wird die neue Version in Produktion genommen; wenn nicht, wird sie abgelehnt und der bestehende Agent bedient weiterhin den Traffic.

Phase 7: Produktionskreislauf aufbauen – Echtzeit-Sicherheitsnetz einrichten

Die Evaluierung von 100 % des Traffics ist teuer, aber eine naive 10 %ige gleichmäßige Stichprobenziehung übersieht die meisten Edge Cases. Wir haben eine stratifizierte Stichprobenziehung implementiert, bei der die Evaluierungs-Stichprobenraten von hochwertigen Kunden, neuen Funktionen oder kürzlich geänderten Abläufen, negativer Stimmung oder hohem Eskalationsrisiko sowie bildbasierten oder betrugsanfälligen Interaktionen abhängen. Dies ergibt eine effektive Evaluierungsstichprobe von 18–20 % (~14.400 Traces pro Tag) zu überschaubaren Kosten, während 45–60 % der Edge Cases erfasst und Probleme innerhalb von 4–6 Minuten erkannt werden.

Die finanzielle Logik ist überzeugend: Im Vergleich zu einem gleichmäßigen Stichprobenansatz erzielte die stratifizierte Methodik eine Reduzierung der Überprüfungskosten pro identifiziertem Problem um 86 % und gleichzeitig eine 9-fache Verbesserung der Edge-Case-Erkennung, wodurch der Qualitätssicherungsprozess erheblich effizienter und skalierbarer wird.

Evaluierungsergebnisse werden in Delta-Tabellen geschrieben und über Dashboards und Alarmregeln in Databricks angezeigt. Kritische Alarme (alle 5 Minuten geprüft) überwachen Abfälle der Absichtsgenauigkeit, Groundedness-Verletzungen, hohes Eskalationsrisiko und P95-Latenzverletzungen. Hohe/mittlere Alarme verfolgen Empathie-Abbau, Kosten-Spitzen, Tool-Fehlerraten, CSAT-Trends, Betrugserkennungsrate und multimodale Latenz. Dies ermöglicht SRE-ähnliche Operationen für KI-Agenten: schnelle Erkennung, Triage und Mitigation.

Der Agenten-Stack mit zusammensetzbarer Architektur

Ein gutes Evaluierungs-Framework funktioniert wesentlich besser, wenn die Agentenarchitektur von vornherein beobachtbar und zerlegbar konzipiert ist. Der Support-Stack von Zepto ist um diese Idee herum aufgebaut.

Eine Kundenanfrage, in Chat- oder Bildform, durchläuft zunächst einen agentischen Orchestrator und Router. Der Router kann jederzeit an einen Menschen übergeben. Darunter teilt sich das System in zwei Arten von Agenten auf.

Vertikale Agenten sind Spezialisten, die jeweils eine einzelne, klar definierte Absichtsfamilie besitzen:

• WIMO: für Auftragsverfolgung und ETA-Fragen
• Fehlend: für nicht gelieferte oder Teillieferungen
• Ablauf: für abgelaufene verpackte Waren
• Rücksendungen: für Rückerstattungsstatus und -bearbeitung
• Qualität: für verdorbene oder faule Produkte
• Zahlungsunfähig: für Wallet-, Promo- und Zahlungsfehler
• Allgemein, als Fallback

Horizontale Agenten fungieren als Überwachungsebenen, die über Anwendungsfälle hinweg agieren:

• Bild-Deduplizierung: erkennt wiederverwendete Bilder über Ansprüche hinweg
• Artikelabgleich und Bildmanipulationserkennung: überprüft, ob hochgeladene Bilder mit Katalogartikeln übereinstimmen und nicht bearbeitet wurden

Diese Trennung zahlt sich doppelt aus. Metriken können pro vertikalem Agenten berechnet werden, wie z. B. WIMO Intent F1 oder Expiry OCR-Genauigkeit, und horizontale Agenten können auf übergreifende Anliegen wie Betrugspräzision, Bildwiederverwendung und Manipulationserkennung evaluiert werden. Jedes Element kann isoliert und in Kombination gemessen werden.

Das Framework in Aktion

Wenn Sie einen KI-Agenten zum ersten Mal in Produktion nehmen, fühlt es sich an, als würden Sie einen brillanten, aber unberechenbaren Praktikanten losschicken, um Ihr Unternehmen zu repräsentieren. Sie geben ihm Anweisungen und hoffen das Beste, aber solange er nicht unter Druck steht, fliegen Sie im Wesentlichen blind.

Frühzeitig erkannten wir, dass traditionelles Software-Monitoring für KI völlig nutzlos ist. Ein Agent kann eine perfekte Server-Uptime und null Fehler aufweisen, während er einem frustrierten Kunden immer wieder die exakt gleiche falsche Antwort gibt. Für die Ingenieure sieht das Dashboard grün aus. Für den Kunden ist es eine Katastrophe.

Wir wussten, dass wir unsere KI nicht auf Hoffnung skalieren konnten. Wir brauchten ein Evaluierungs-Framework, das nicht nur verfolgte, ob die KI sprach, sondern tatsächlich verstand, was sie sagte und wo sie versagte. Die folgenden Geschichten sind die Momente, in denen dieses Framework seinen Wert bewies und zeigte, dass ein gutes Evaluierungssystem völlig neue Produktfunktionen freischaltet.

Geschichte 1: Die ETA, die sich nie bewegte

Ein Produktionsproblem führte dazu, dass Fahrer im Stau steckten, während der Agent immer wieder mit „Ankunft in 10 Minuten“ antwortete, da er zwischengespeicherte Daten las. Der Kunde fragte, wo seine Bestellung sei, erhielt die gleiche Antwort, fragte erneut und erhielt wieder die gleiche Antwort.

Der Token-Zähler (Überwachung der Token-Nutzung) und die Warnungs-Scorer erkannten die Wiederholung und das hohe Eskalationsrisiko innerhalb von 5 Minuten und zeigten Spuren von stehenden Fahrern mit unveränderten ETAs auf. Das löste eine Regeländerung aus. Bleibt ein Fahrer länger als 10 Minuten stationär, gibt der Agent nun ein ehrliches Update und bietet proaktiv eine Stornierung mit vollständiger Rückerstattung an, anstatt ein veraltetes Versprechen zu wiederholen.

Eine durch Online-Evaluierung gewonnene Erkenntnis entwickelte sich zu einer ganzen Feature-Linie: Stornierung bei Verspätung, ein proaktives Angebot zur Stornierung bei Fahrermangel, automatische Stornierung, wenn innerhalb eines festgelegten Zeitfensters kein Fahrer zugewiesen wird, und eine bedingungslose Stornierung für hochwertige Kunden.

Geschichte 2: Die Stornierungs-Regression erkennen, bevor es die Kunden taten

Als Zepto die Stornierungsabwicklung zum WIMO-Agenten hinzufügte, begann das Modell, drei sehr unterschiedliche Absichten zu verwechseln: „Wo ist meine Bestellung?“, „Ich möchte stornieren“ und „Wurde meine Bestellung storniert?“

Die MLflow-Evaluierung in der Entwicklungsphase erkannte dies sofort. Die Gesamtgenauigkeit der Absichtserkennung sank von etwa 92,1 Prozent auf 87,4 Prozent, mit einem schlechten F1-Wert bei den neuen WIMO_CANCEL- und WIMO_CANCEL_STATUS-Absichten. Da die Regression anhand des goldenen Datensatzes auftrat, hat kein Kunde sie jemals gesehen. Prompt-Optimierung und Datensatz-Updates stellten die Gesamtgenauigkeit auf etwa 94,2 Prozent wieder her, besser als die ursprüngliche Baseline, mit nahezu perfektem Tool-Calling F1 bei den Stornierungs-APIs. Die Funktion wurde ohne Rücknahmen live geschaltet.

Geschichte 3: Multimodale Agenten anhand menschlicher Beurteilung kalibrieren

Die Qualität von Produkten ist wirklich schwer zu bewerten, und Menschen sind sich nicht immer einig. Dasselbe Bild von Pilzen könnte von einem Bewerter eine 2 von 5 und von einem anderen eine 3 von 5 erhalten. Wir haben diese Uneinigkeit mit Cohens Kappa gemessen und sie als unsere Zuverlässigkeitsobergrenze behandelt, da kein Modell konsistenter sein kann als die Menschen, von denen es lernt.

Wir stellten auch fest, dass die KI auf Nummer sicher ging. Allein gelassen, häufte sie Bewertungen bei 3 an, um schwierige Entscheidungen zu vermeiden, während menschliche Bewertungen bei 4 und 5 ihren Höhepunkt erreichten. Wir minimierten also nicht nur den Fehler gegenüber dem Durchschnitt. Wir passten die Form der menschlichen Bewertungsverteilung an. Die Online-Evaluierung zeigte auch Fälle auf, für die das System nicht ausgelegt war, wie geronnene Milch, die als verpacktes Gut gelagert wird, aber wie frische Produkte beurteilt werden muss, und Geschmacks- oder Geruchsbeschwerden, die ein Foto einfach nicht zeigen kann und die auf einen separaten Pfad geleitet wurden.

Diese kalibrierte Baseline ermöglicht es uns zu entscheiden, welche Modelle pro Produkttyp verwendet werden sollen, wie Prompts gegen menschliches Urteilsvermögen iteriert werden und wie die Rückerstattungsrichtlinie nach Kundensegment basierend auf der tatsächlichen Agentenleistung angepasst werden kann.

Geschichte 4: Die Missbrauchs-Hintertüren schließen

Versuche von Rückerstattungsmissbrauch nutzten Katalogbilder, bearbeitete Fotos und Bilder, die über mehrere Ansprüche hinweg wiederverwendet wurden. Die multimodale Evaluierungspipeline führte Bilder durch Vorverarbeitungsprüfungen auf Unschärfe, Helligkeit und Auflösung, validierte sie mit OCR und nutzte dann eine Jury aus drei Vision-Modellen mit Konsensregeln, um zwischen automatischer Genehmigung und menschlicher Überprüfung zu entscheiden. Darüber lagen Unschärfeerkennung, Screenshot-Erkennung, Duplikaterkennung, Bild-gegen-SKU-Abgleich, Bild-gegen-angegebenen-Grund-Prüfungen und Liefernachweis-Validierung.

Was wir beim Betrieb in großem Maßstab gelernt haben

Durch den groß angelegten Einsatz dieses Frameworks haben wir eine Reihe von Grundsätzen gewonnen, die über den Bereich des „Quick Commerce“ hinaus gelten.

• Optimieren Sie niemals eine einzelne Metrik. Wir haben einmal die Intent-Genauigkeit isoliert verfolgt und sahen, wie der CSAT sank. Die alleinige Optimierung der Intent-Erkennung führte zu einem Gewinn von 5 Prozentpunkten bei der Intent-Genauigkeit, erhöhte aber die Latenz um 133 Prozent und kostete 0,4 Prozentpunkte beim CSAT. Ein zusammengesetzter, multiobjektiver Score gewann 3 Prozentpunkte bei der Intent-Erkennung bei nur 17 Prozent mehr Latenz und fügte 0,2 Prozentpunkte zum CSAT hinzu. Mehrere Perspektiven, LLM-Richter, regelbasierte Prüfungen, menschliche Labels und Produktionsmetriken schaffen gemeinsam die Wahrheit. Diese Redundanz ist eine Versicherung, keine Verschwendung.
• Goldene Datensätze sind die Grundlage. Investieren Sie frühzeitig, um Tausende von vielfältigen, hochwertigen Beispielen zu erhalten. Verfolgen Sie die Lücke zwischen Entwicklungs- und Produktionsgenauigkeit und optimieren Sie, bis sie konvergiert. Die Dev-Prod-Lücke ist ein Signal für die Datenqualität, kein Rätsel.
• LLM-Richter benötigen Kalibrierung. Behandeln Sie Richter als Modelle mit eigener Evaluierung. Messen Sie ihre Übereinstimmung mit Menschen, verwenden Sie Ensembles für Fälle mit hohem Risiko und kalibrieren Sie neu, wenn sich die Basismodelle ändern.
• Die Sampling-Strategie ist wichtiger als die Sampling-Rate. Naives gleichmäßiges Sampling ist günstig, aber blind. Stratifiziertes Sampling, das sich auf Hochrisikoflüsse konzentriert, bietet eine Größenordnung bessere Problemerkennung pro Dollar.
• Automatisieren Sie den Feedback-Loop am ersten Tag. Erkennen, labeln, neu trainieren, bereitstellen und überwachen sollte alles automatisiert werden, wobei jeder Fehler die nächste Trainingsrunde automatisch anreichert. Für uns sparte dies etwa 155 Stunden pro Monat, was dem Äquivalent von zwei Vollzeit-Ingenieuren entspricht, die für Feature-Arbeit umgeleitet wurden.
• Betrachten Sie die Evaluierung als Produktoberfläche. Dashboards und Metriken werden von Support-, Produkt-, Betrugs- und Betriebsteams verwendet. Sie müssen interpretierbar und umsetzbar sein, nicht nur technisch korrekt.

Empfehlungen für Agenten-Entwickler

Für Organisationen, die agentenbasierte Systeme auf Databricks entwickeln, schlägt die Zepto-Erfahrung die folgende Roadmap vor:

• Beginnen Sie mit Traces, nicht nur mit Modellen: erzwingen Sie ein gemeinsames Trace-Schema und protokollieren Sie alles in Delta
• Machen Sie MLflow-Evaluierungen zu einem obligatorischen Gate in CI/CD: keine Bereitstellung ohne Übertreffen der Baseline bei vereinbarten Metriken
• Erstellen Sie goldene Datensätze als Asset, mit eigenen KPIs (Größe, Dev-Prod-Lücke, Edge-Case-Abdeckung)
• Verwenden Sie LLM-als-Richter für das, was Menschen heute beurteilen (Qualität, Empathie, Fundiertheit), aber kalibrieren und begrenzen Sie es auf die richtigen Segmente
• Implementieren Sie stratifiziertes Sampling und Echtzeit-Warnungen so früh wie möglich; die nachträgliche Anpassung der operativen Sichtbarkeit ist teuer
• Architektonisch können Agenten vertikal (spezialisiert) plus horizontal (Aufsicht) sein, sodass Sie sie isoliert und in Kombination evaluieren können

Fazit

Beim Übergang von experimentellen Demos zu missionskritischer Infrastruktur hat sich die primäre Einschränkung von der reinen Modellfähigkeit zur Systemsicherheit verlagert. Zeptos Weg zeigt, dass Organisationen durch die Etablierung der Evaluierung als grundlegendes Entwicklungsprimitiv Agenten zuverlässig skalieren können, um Zehntausende komplexer täglicher Interaktionen über multimodale Eingaben hinweg zu verwalten, unterstützt durch strenge Garantien für Qualität, Kosten und Risikominderung.

Databricks und MLflow dienen als das wesentliche Substrat für diese Entwicklung und bieten eine trace-zentrierte Dateninfrastruktur auf Unity Catalog und Delta, zusammen mit skalierbarer Evaluierung, automatisierter Prompt-Optimierung und nahtloser CI/CD-Integration. Dieser zusammensetzbare Stack, kombiniert mit Modell-Optionalität, ermöglicht es Teams, das Gleichgewicht zwischen Leistung und Kosten für jede spezifische Aufgabe fein abzustimmen.

Letztendlich liegt der Wettbewerbsvorteil in der strategischen Entscheidung, die Evaluierung nicht als abschließende Überprüfung, sondern als zentrale KI-Infrastruktur zu behandeln. Der Bauplan für den Betrieb von Agenten im Produktionsmaßstab ist kein Geheimnis mehr; Zepto und Databricks haben die Antwort geliefert. Die Herausforderung liegt nun in der Geschwindigkeit der Adoption. In der sich schnell entwickelnden KI-Landschaft werden die Führenden nicht diejenigen sein, die auf perfekte Gewissheit warten, sondern diejenigen, die von Tag eins an auf Zuverlässigkeit ausgelegt sind.

Für Entwickler, die Agenten entwickeln, die in Produktionsumgebungen Vertrauen verdienen müssen, stehen dieselben grundlegenden Bausteine auf Databricks und MLflow 3 bereit. Die Organisationen, die die nächste Grenze definieren, werden diejenigen sein, die ihre evaluierungszentrierte Reise heute beginnen.

Agenten auf Databricks erstellen
Erste Schritte mit MLflow-Evaluierung und -Monitoring

(Dieser Blogbeitrag wurde mit KI-gestützten Tools übersetzt.) Originalbeitrag