ThinkingBox: «Erledigt» muss sich im Systemzustand zeigen

Microsoft und Hugging Face beschrieben am 22. Oktober die Weiterentwicklung von ThinkingBox für Training mit ausführbaren Zustandsprüfungen. Das Forschungsprojekt ist zugänglich; daraus folgt keine fertige Integration in einen realen Betrieb. (Microsoft / Hugging Face)

Die Erfolgsaussage vor dem Versuch festlegen

Eine gute Prüfregel bleibt gültig, auch wenn der Agent einen anderen Lösungsweg findet als erwartet. Statt «drei Werkzeuge wurden aufgerufen» sollte sie den fachlichen Endzustand beschreiben. Das verhindert, dass eine formal passende Werkzeugfolge als Erfolg zählt, obwohl der Auftrag nicht erfüllt wurde.

Illustratives CRM-Szenario: Eine zulässige Anfrage soll einem vorhandenen Kunden zugeordnet werden, genau einen offenen Arbeitsauftrag erhalten und bei der vereinbarten Person landen. Ohne Freigabe darf keine Nachricht versendet werden. Diese Vorgaben sind ein eigenes Beispiel; sie stammen nicht aus einem hier ausgeführten ThinkingBox-Test.

Ausgangszustand, Werkzeuge und Urteil trennen

Der Framework-Ansatz umfasst Szenarien, Werkzeugumgebungen und Ergebnisbewertung. Das ist ein Forschungsbaustein, keine fachliche Freigabe für einen eigenen Produktivprozess. (Microsoft)

Für die eigene Prüfumgebung sollten Startdaten und Berechtigungen feststehen. Nach jedem Durchlauf wird ein frischer Ausgangszustand benötigt, wenn Versuche vergleichbar sein sollen. Verbleibende Datensätze aus einem früheren Versuch können sonst scheinbaren Erfolg erzeugen oder einen späteren Versuch unberechtigt scheitern lassen.

Illustrative Abnahme, keine Datenbankabfrage ausgeführt:
Anfrage vorhanden und zulässig?
  Kundenbezug == erwarteter Bezug
  neue Arbeitsaufträge für diese Anfrage == genau einer
  zuständige Person == vereinbarte Person
  unerlaubte Nachrichten == keine
  offene Ausnahmen == sichtbar dokumentiert

Ein Erfolg und verlässlicher Erfolg sind verschiedene Beobachtungen

Ein einmal richtiger Durchlauf zeigt eine mögliche Lösung. Für die Betriebsentscheidung interessiert zusätzlich, ob das Ergebnis unter vergleichbaren Bedingungen wiederholt eintritt. Zeigen Sie deshalb nicht nur ein ausgewähltes Beispiel. Erfassen Sie Wiederholungen, Fehlertypen und den Aufwand bis zum verwertbaren Ergebnis getrennt.

Die Wiederholbarkeit sollte nicht durch immer neue Hinweise während der eigentlichen Prüfung verbessert werden. Änderungen an Aufgaben, Modell oder Werkzeugen müssen dokumentiert werden; danach beginnt ein neuer Vergleich. Sonst werden unterschiedliche Versuchsbedingungen zu einer scheinbar eindeutigen Kennzahl vermischt.

Fehler so klassifizieren, dass jemand handeln kann

• Fachlicher Fehler: falscher Zielzustand trotz formal gültiger Werkzeugantworten.
• Berechtigungsfehler: eine Aktion überschreitet die erlaubte Grenze.
• Werkzeug- oder Umgebungsfehler: der Versuch kann den vorgesehenen Prozess nicht ausführen.
• Bewertungsfehler: die Prüfregel beurteilt den richtigen Zustand falsch oder lässt eine wichtige Nebenwirkung aus.
• Unklarer Ausgang: ein Fremdsystem bestätigt seine Änderung nicht eindeutig.

Diese Klassen helfen, Reparatur am Agenten von Reparatur der Testumgebung zu unterscheiden. Auch die Prüfregel selbst ist Software und benötigt überprüfbare Beispiele. Ein automatisches Urteil wird nicht allein deshalb fachlich richtig, weil es einen Zahlenwert liefert.

Lizenz und ausführbarer Betrieb separat prüfen

Das Training-Repository nennt MIT als Lizenz und beschreibt einen spezialisierten Trainingsstack. Modellgewichte, Daten und weitere Abhängigkeiten müssen jeweils separat geprüft werden; ein Repository-Label deckt nicht den ganzen Versuchsaufbau ab. (Microsoft)

Für einen ersten eigenen Evaluationsentwurf genügen eine abgegrenzte Aufgabe, synthetische Daten und klare Zustandsregeln. Installation, benötigte Hardware, externe Endpunkte und laufende Kosten werden erst danach konkret geprüft. Die veröffentlichten Forschungswerte werden hier weder reproduziert noch auf ein Schweizer Unternehmen übertragen.