Der vorige Teil dieses Kapitels endete mit der kritischsten aller Fragen, nämlich der, woher man weiß, dass ein Agent seine Aufgabe verlässlich erledigt. Verlässlichkeit ist keine Eigenschaft, die man behauptet; sie muss nachgewiesen werden. Erst durch die Messung wird aus einem Agenten ein Werkzeug, das eine bestimmte Aufgabe zuverlässig erledigt.
Hier zahlt sich eine Eigenschaft aus, die sich als Leitidee durch die zweite Hälfte dieser Serie zieht: Der Agent läuft lokal und innerhalb des Prozesses, er ist kein externes, geschlossenes System, das sich nicht oder nur begrenzt beobachten lässt. Ein eingebetteter Agent kann so instrumentiert werden, dass jeder relevante Schritt sichtbar wird, nicht nur sein Ergebnis. Die meisten Agenten-Werkzeuge liefern den Agenten, aber keine eingebaute Funktion, um seine Verlässlichkeit systematisch zu messen und nachzuschärfen. Genau die gehört hier zur Laufzeit.
Ein Prüfrahmen, der mitläuft
Aus dieser Beobachtbarkeit wird ein Messinstrument. Ein Prüfrahmen fährt definierte Testszenarien, d.h. typische Aufgaben vom einfachen Fall über mehrstufige Pläne bis zur Fehlererholung, und lässt den Agenten sie der Reihe nach bearbeiten. Zu jedem Lauf entsteht ein strukturiertes Beobachtungsprotokoll, das von einem prüfenden Agenten ausgewertet wird, um die Qualität des Ergebnisses und des Weges dorthin zu beurteilen.
Der Ablauf ist eine Schleife. Vor dem Lauf wird festgelegt, welche Aspekte in welcher Tiefe beobachtet werden. Nach dem Lauf werden die Protokolle gegen vorab definierte Erfolgskriterien und Prüffragen ausgewertet. Dazu zählen Fragen wie: Wurde die Aufgabe richtig verstanden? Wurde das passende Werkzeug beim ersten Versuch gewählt? Gab es unnötige Iterationen?
Aus den Befunden werden interne Prompts, Werkzeugführung, Kontextzuschnitt oder Code nachgeschärft, dann wird der Lauf wiederholt. Verlässlichkeit entsteht also nicht aus einem einmaligen Test, sondern aus dieser empirischen Schleife: Messen, nachschärfen, erneut messen. Dieselben Szenarien lassen sich auch nutzen, um das Verhalten des Agenten unter verschiedenen Sprachmodellen sauber zu vergleichen.
Das ist keine graue Theorie: Genau mit diesem Prüfrahmen bewertet PROSTEP den eigenen Agenten. Die PROSTEP AI Workbench wird gegen diese Szenarien gemessen und Runde um Runde nachgeschärft. Die hier beschriebene Methodik ist also das Werkzeug, mit dem wir unsere eigene Agenten-Architektur weiterentwickeln. Wichtig für den Produktivbetrieb ist, dass die dafür nötige Protokollierung abschaltbar ist, so dass kein Mess-Overhead im Echtbetrieb entsteht.
Was gemessen wird
Gemessen wird nicht nur, ob am Ende eine plausible Antwort steht. Beobachtet wird die ganze Kausalkette des Verhaltens mit rund einem Dutzend Aspekten, darunter:
- Aufgabenverständnis: Hat der Agent die Aufgabe richtig zerlegt oder eine Anforderung missverstanden?
- Werkzeugwahl: Hat er das passende Werkzeug gewählt oder eine falsche Wahl kontrolliert korrigiert?
- Ergebnisdeutung: Hat er ein Werkzeug-Ergebnis korrekt gelesen oder einen Fehler übersehen?
- Planung, Entscheidungspunkte, Sackgassen: Wo hat er umgeplant, wo Iterationen verschwendet?
- Ergebnisqualität: Erfüllt das Ergebnis die vorab definierten Kriterien?
Dazu kommen nüchterne Betriebsgrößen je Lauf wie Iterationen, Werkzeugaufrufe, Tokens, Laufzeit. Erst diese Schrittbeobachtungen zeigen, ob ein Agent verlässlich arbeitet oder im Einzelfall nur Glück hatte. Und erst dadurch lässt sich überhaupt belastbar sagen, wo ein Agent stabil arbeitet und wo nicht. Bei Grundaufgaben liegen viele Systeme nah beieinander. Der Unterschied zeigt sich erst dort, wo die Architektur besondere Fähigkeiten ausspielt, etwa bei Aufgaben, die über viele Schritte hinweg Zustand, Entscheidungen und Zwischenergebnisse behalten müssen, oder bei Werkzeugen, die mehr als Text verarbeiten.
Wo APL die richtige und die falsche Antwort ist
Der Ehrlichkeit halber gehört zum Abschluss dieses Kapitels auch das Eingeständnis, dass APL nicht für alles die richtige Wahl ist. Wo eine Aufgabe einfach regelbasiert ist, genügt klassische Skript-Programmierung. Eine kompilierte Prozesssprache mit KI-Schritten wäre überdimensioniert. Und wo eine Aufgabe offen und explorativ ist, ohne wiederkehrende Form und ohne Anspruch auf Reproduzierbarkeit, kann ein extern betriebener Allzweck-Agent die pragmatischere Antwort sein.
APL zahlt sich genau dazwischen aus: Bei Prozessen, die produktiv, wiederholbar und nachprüfbar dasselbe leisten müssen und zugleich echte kognitive Schritte enthalten. Das ist kein schmaler Sonderfall, sondern das weite Feld industrietauglicher KI-Anwendungen. Aber es ist ein bestimmtes Feld, und das klar zu benennen, ist selbst Teil der Industrietauglichkeit.
Das Kapitel schließt sich
Der Anspruch von APL ist, die KI so einzubauen, dass ihre Arbeit beschrieben, begrenzt, beobachtet und verbessert werden kann: Ein deterministisches Rückgrat, punktuell eingesetzte KI, ein Agent, der in der Anwendung mitarbeitet, und eine Verlässlichkeit, die gemessen werden kann. Wie diese Prinzipien in echten Anwendungen funktionieren, z.B. in einem Traceability-Assistenten oder bei der Vertrags- und Lastenheftanalyse, zeigt das dritte Kapitel dieser Serie. Er führt die Aspekte aus der Produktperspektive zusammen.
