Einfach zu entwickeln, schwer zu bereitzustellen: Muss man zuerst das „Evaluieren“ lernen, um Enterprise-Agenten zu meistern?

Vor dem Einsatz von Milliarden von Agenten hat Amazon die Agenten zuerst darin trainiert, Bestände zu verwalten und Personal einzustellen. In dem entsprechenden Artikel hat Matt Garman, CEO von Amazon Web Services (im Folgenden „AWS“), vorhergesagt, dass in Zukunft Milliarden von Agenten in allen Branchen weit verbreitet sein werden. Eine solche Aussicht ist zwar erfreulich, aber man muss auch einige realistische Hinweise geben.

Im vergangenen Juli veröffentlichte das MIT Project NANDA einen Bericht, der auf Interviews mit über 300 KI-Projekten, 52 Organisationen und Umfragen unter 153 Führungskräften basiert: Obwohl Unternehmen 30 bis 40 Milliarden US-Dollar in generative KI (GenAI) investiert haben, haben nur 5 % der Organisationen erfolgreich eine skalierte Bereitstellung erreicht und erhebliche finanzielle Erträge erzielt. Dieses Phänomen wird als „GenAI-Lücke“ (The GenAI Divide) bezeichnet, und die überwiegende Mehrheit der Organisationen steckt in der Pilotphase mit „hoher Akzeptanzrate und niedriger Umsetzungsrate“ fest.

Im Bereich der Agenten gibt es ebenfalls eine solche Lücke: Die Demo funktioniert hervorragend, aber wenn sie in echten Szenarien eingesetzt wird, versagt sie. Wenn in Zukunft Milliarden von Agenten entstehen, ist es schwer zu sagen, wie viele davon tatsächlich nutzbar sind. Die Wurzel des Problems liegt möglicherweise nicht darin, dass das Modell nicht leistungsstark genug ist, da Agenten tief in spezifische Geschäftsszenarien eintauchen müssen – ingenieurtechnische Probleme sind möglicherweise wichtiger als die Fähigkeiten des Modells. In dem kürzlich von AWS veröffentlichten „Leitfaden für die Entwicklung und Bereitstellung von Agenten im Produktionsbetrieb“ (im Folgenden „Leitfaden“) wird erwähnt, dass traditionelle Software-Engineering-Methoden für Agenten nicht mehr funktionieren, was auf drei wesentliche Unterschiede zwischen traditioneller Software und Agenten zurückzuführen ist:

Nicht-Determinismus. Die Ausführungslogik traditioneller Software ist deterministisch, mit klaren Kriterien für Richtig und Falsch. Agenten, die auf großen Modellen basieren, liefern probabilistische Ausgaben – dieselbe Eingabe führt nicht unbedingt zu derselben Ausgabe. Dass ein Test gestern erfolgreich war, bedeutet nicht, dass das System heute noch stabil ist. Bisher hat kein führender Modellanbieter vollständig deterministische Ausgaben zugesichert.

Prompt als Quellcode. Bei traditioneller Software hinterlassen Codeänderungen Spuren, es gibt Versionskontrolle und statische Analysetools – bei Prompts ist das nicht der Fall. Selbst eine geringfügige Änderung eines Wortes in einem natürlichsprachlichen Prompt kann zu drastischen Verhaltensänderungen des Agenten führen, und derzeit gibt es keine ausgereiften Tools in der Branche, um den Einflussbereich solcher Änderungen zu bewerten.

Implizite Abhängigkeiten. Agenten weisen implizite Abhängigkeiten von den zugrunde liegenden großen Modellen auf – wenn der Modellanbieter das Modell im Hintergrund aktualisiert, ohne dass eine einzige Codezeile geändert wird, kann sich die Servicequalität des Agenten bereits verändert haben.

Die Kombination dieser drei Unterschiede führt dazu, dass das Bewertungs- und Testsystem für traditionelle Software für Agenten vollständig unwirksam wird, was wiederum dazu führt, dass Unternehmen bei der Umsetzung von Agenten in den Produktionsprozess ins Stocken geraten. Was sollten Unternehmen also konkret tun, wenn sie durch Agenten Kosten senken und die Effizienz steigern wollen?

01 Von SDLC zu ADLC: Die Bewertung ist der Kern

Chu Ruisong, Global Vice President von Amazon, hat einmal die Ansicht geäußert: Wenn Unternehmen KI-Agenten entwickeln, können sie die zugrunde liegende technische Plattform durch Einkäufe erwerben, aber die Bewertungskriterien müssen sie selbst kontrollieren. Der zentrale Wettbewerbsvorteil von Unternehmen liegt in ihren eigenen Gold-Datensätzen und Bewertungskriterien. Diese Aussage widerspricht ein wenig der allgemeinen Erwartung: Modelle, Infrastruktur und Entwicklungstools können gekauft werden (für die überwiegende Mehrheit der Unternehmen ist die Eigenentwicklung tatsächlich nicht realistisch). Warum sind Bewertungskriterien dann so wichtig?

Werfen wir einen Blick zurück in die Geschichte: In den 1960er Jahren erlebte die Informatik eine rasante Entwicklung, aus der sich die Vorläufer des Produktionsrahmens entwickelten, der schließlich zum SDLC (Software Development Lifecycle, Software-Entwicklungslebenszyklus) wurde. Der Kern von SDLC besteht darin, den Entwicklungsprozess in mehrere Phasen wie Anforderungsanalyse, Design, Codierung, Test, Bereitstellung und Wartung zu unterteilen. Da KI-Agenten einen großen Teil der Entwicklungsarbeiten übernehmen, entstand die Methodik des ADLC (Agent Development Lifecycle, Agent-Entwicklungslebenszyklus). Der größte Unterschied zu SDLC besteht darin: ADLC ist ein Schwungrad, kein Fließband.

ADLC endet nicht, wenn man es einmal durchläuft, sondern dreht sich ständig und iteriert kontinuierlich. Sechs Phasen – Festlegung von Kriterien, Entwicklung und Implementierung, Effektbewertung, Graubereichs-Bereitstellung, kontinuierliche Überwachung und Verbesserungszyklus – fließen von der letzten zurück zur ersten Phase, um die Bewertungskriterien und Referenzdatensätze zu aktualisieren. Während traditionelle Software dem Muster „Entwicklung → Test → Bereitstellung“ folgt, verläuft der Prozess für Agenten wie folgt: „Kriterien festlegen → Entwicklung → Bewertung → Bereitstellung → Überwachung → Fehleranalyse → Kriterien aktualisieren → erneute Entwicklung“. Die Bewertung ist sowohl der Ausgangspunkt als auch das Ende.

Wenn Sie als Manager eines Unternehmens ein Agentenprojekt starten und ein geeignetes Szenario gefunden haben, müssen Sie vor Beginn der Entwicklung zunächst definieren, was ein „guter“ Agent ist. Dazu gehören die Definition des Agenten (was er ist und was er tun soll), Tonfall und Persönlichkeit (wie er spricht), Definition von Tools und Parametern (was er nutzen kann und wie) sowie Referenzdatensätze (was bedeutet „gut ausgeführt“).

Nach der Bereitstellung des Agenten müssen die Daten aus der Produktionsumgebung kontinuierlich in das Bewertungssystem zurückfließen. Dies erfordert den Aufbau eines umfassenden Beobachtbarkeitssystems (im Leitfaden wird die Verwendung von OpenTelemetry empfohlen). Ohne Beobachtbarkeit gibt es keine kontinuierliche Bewertung, und das Schwungrad kann sich nicht drehen. Schließlich muss die Systemarchitektur bewertbar gestaltet werden – dies ist der am stärksten ingenieurtechnische Teil und die Infrastruktur, auf der die Bewertung umgesetzt werden kann. Der Leitfaden empfiehlt ein dreistufiges Design: Authentifizierungsebene (zur Bestätigung der Benutzeridentität), Autorisierungsebene (Gateway, die steuert, was der Agent tun darf) und Sitzungsisolationsebene (damit verschiedene Benutzer sich nicht gegenseitig stören).

Der Agent ist entwickelt – wie kann man beurteilen, ob er funktioniert? Das ist die am schwierigsten zu beantwortende Frage. Die Umsetzung von großen Modellen zu Agenten ist vergleichbar mit einem Baum, der Blätter treibt, blüht und Früchte trägt: Man braucht möglicherweise nur ein oder wenige große Modelle, aber Agenten gibt es in unzähligen verschiedenen Ausführungen. Ebenso sollte für jeden Agenten ein spezifisches Bewertungsverfahren vorhanden sein – man darf ihn nicht einfach mit dem Gedanken „es fühlt sich ungefähr richtig an“ in den Betrieb überführen.

02 Bewertungsmethodik: Zwei Säulen

Personen, die bereits Agenten entwickelt haben, kennen möglicherweise das folgende Szenario: Die Tests verlaufen reibungslos, aber wenn der echte Datenverkehr startet, treten „intermittierende Fehler“ auf. Bei derselben Art von Anfrage tritt ein oder zwei Mal von zehn Problemen auf – das ist sehr ärgerlich.

Für Agenten sind Fähigkeit (Capability) und Konsistenz (Reliability/Consistency) nicht dasselbe. „Können“ bedeutet nicht „jedes Mal zuverlässig funktionieren“. Agenten kombinieren mehrstufige Schlussfolgerungen, Tool-Aufrufe und Schreibvorgänge in externe Zustände – die Zufälligkeit jedes einzelnen Schritts wird kaskadenartig verstärkt. Nur durch umfangreiche, wiederholte Bewertungen kann man das Ziel „jedes Mal zuverlässig funktionieren“ annähern.

Der Leitfaden stellt die „zwei Säulen“ der Bewertungsmethodik vor: Die erste Säule bestimmt die Granularität der Bewertung – von der Betrachtung der endgültigen Antwort (Black-Box) über die Verfolgung des vollständigen Ausführungsablaufs (Glass-Box) bis hin zur Analyse einzelner Schritte (White-Box). Die zweite Säule bestimmt das Gewicht jedes Bewertungspunkts – von maschinell überprüfbar (Ebene 1) über halbobjektiv (Ebene 2) bis hin zu standardmäßig subjektiver Bewertung (Ebene 3).

Black-Box-Bewertung betrachtet die endgültige Ausgabe – ein Benutzer stellt eine Frage, der Agent gibt eine Antwort: Ist sie richtig? Glass-Box-Bewertung verfolgt den vollständigen Ablauf – welche Entscheidungen hat der Agent getroffen, welche Tools hat er aufgerufen, ist jede Schlussfolgerung sinnvoll? White-Box-Bewertung konzentriert sich auf einzelne Schritte – ist ein bestimmter Tool-Aufruf korrekt, ist eine bestimmte Schlussfolgerung gültig? Die drei Granularitätsstufen beantworten von grob zu fein die Fragen „Ist das Ergebnis richtig?“, „Ist der Prozess richtig?“ und „Ist jeder Schritt richtig?“. Bei der täglichen Entwicklung steht die Glass-Box-Bewertung im Vordergrund, ergänzt durch Black-Box- und White-Box-Bewertung.

Die erste Ebene des Beweisgewichts ist die maschinelle Überprüfung: Sie prüft, ob das Format korrekt ist, ob JSON analysiert werden kann usw. – vollständig automatisiert, ohne subjektive Bewertung. Die zweite Ebene ist die halbobjekte festgelegte Bewertung: Mit festen Bewertern und klaren Bewertungskriterien werden Punkte für bestimmte Dimensionen vergeben. Die dritte Ebene ist die standardmäßig subjektive Bewertung: Es gibt keine festen Kriterien, die Bewertung erfolgt durch menschliche Urteilskraft oder große Sprachmodelle. Dies entspricht drei Arten von Bewertern: Code-Regeln, Modelle und Menschen.

Die beiden Säulen stehen orthogonal zueinander: Indikatoren auf derselben Granularitätsebene können aus verschiedenen Beweisebenen stammen und umgekehrt – dies bildet eine 3×3-Matrix, bei der für jede Indikatorgruppe sowohl die Granularität als auch die Beweisstärke ausgewählt werden muss. Mit einer solchen Kombination kann man die Ausgabeergebnisse des Agenten umfassend bewerten. Nehmen wir den von AWS entwickelten Kundenservice-Agenten als Beispiel: Das größte Risiko im Kundenservice-Szenario liegt in der fehlerhaften Erkennung von Absichten – das heißt, das, was der Benutzer sagt, ist nicht das, was der Agent versteht. AWS hat daher mit dem zweigleisigen Bewertungsverfahren „echte Daten + virtuelle Kundensimulation“ den Testaufwand gering gehalten, um die Testabdeckung auf verschiedene Randfälle auszudehnen. Dadurch wurde sowohl die Genauigkeit der Absichtserkennung als auch die Kohärenz mehrstufiger Gespräche getestet.

Es ist erwähnenswert, dass bei der Bewertung auch automatische Modellbewertungen zum Einsatz kommen – daher bestimmt die Qualität der Bewertungsdatensätze die Obergrenze der Bewertungsqualität. Unternehmen müssen hochwertige Testdatensätze aufbauen, die manuell annotiert und geschäftlich validiert sind. Diese Datensätze werden ein zentrales Vermögenswert für das Unternehmen sein.

Es gibt viele detaillierte Dimensionen für die Bewertung von Agenten, und verschiedene Arten von Agenten legen Wert auf unterschiedliche Aspekte: Kundenservice-Agenten legen Wert auf die Genauigkeit der Absichtserkennung und die Gesprächskohärenz, Tool-Nutzungsagenten legen Wert auf die korrekte Auswahl von Tools und die Genauigkeit von Parametern, und Multi-Agent-Kooperationssysteme legen Wert auf die sinnvolle Aufteilung von Aufgaben und die Ausführungsstabilität. Daher werden diese Aspekte hier nicht im Detail erläutert.

Die von AWS bereitgestellten Ideen und Methoden stellen nur eine von vielen Möglichkeiten dar, wie Agenten erfolgreich eingesetzt werden können – es gibt möglicherweise andere Wege und praktische Beispiele. Aber eines ist sicher: Agenten sind Produktivitätswerkzeuge. Ob sie messbare geschäftliche Ergebnisse liefern können, ist das endgültige Kriterium, um zu beurteilen, ob sie „gut“ sind.

Im Zeitalter der Agenten ist es für Unternehmen eine neue Herausforderung in Bezug auf Technik und Geschäft, Agenten wirklich in den Produktionsbetrieb zu überführen. Selbst mit einem Leitfaden hängt der Erfolg von der Entschlossenheit und dem Engagement des Unternehmens selbst ab.

Dieser Artikel stammt aus dem WeChat-Offiziellen Konto „DoNews“ (ID: ilovedonews), Autor: Li Xinma. Veröffentlicht mit Genehmigung von 36Kr.