Testen und evaluieren

Testen und evaluieren

0:00 Jeder, der schon einmal einen Agenten gebaut hat, kennt diesen Moment: Man stellt eine Frage, die Antwort ist gut, und man denkt — es funktioniert. Am nächsten Tag stellt jemand dieselbe Frage anders, und plötzlich funktioniert es nicht. Das ist kein Zufall und kein Pech, sondern eine Eigenschaft der Technik. Deshalb braucht es hier eine andere Art zu prüfen als bei klassischer Software: nicht einmal ausprobieren, sondern wiederholbar messen.

0:26 Copilot Studio bringt dafür eine eigene Evaluation mit. Schauen wir uns an, wie man sie sinnvoll einsetzt.

Testen und evaluieren

0:33 Vier Themen. Zuerst die beiden Werkzeuge — Testchat und Evaluation — und wofür sie jeweils taugen. Dann der Aufbau eines Testsets, das mehr prüft als nur den Erfolg. Im dritten Kapitel geht es um die Bewertung und ihre Grenzen. Und zum Schluss um Regressionstests, also die Frage, wie Sie belegen, dass eine Änderung wirklich etwas verbessert hat.

Reproduzierbar testen

0:55 Beginnen wir mit der Unterscheidung zweier Werkzeuge, die leicht verwechselt werden. Beide heißen im Alltag „testen" und beantworten doch ganz verschiedene Fragen. Der Testchat ist die Werkbank: eine Frage, eine Antwort, sofort sichtbar, ideal beim Bauen. Die Agent-Evaluation ist die Prüfstation: viele Testfälle in einem Lauf, gleicher Maßstab, wiederholbar.

1:17 Ein Testfall ist dabei eine einzelne Interaktion — eine Frage oder auch ein ganzes Gespräch — und er kann die erwartete Antwort enthalten. Diese Erwartung ist der Kern der Sache: Erst sie macht aus einem Ausprobieren eine Messung. Ohne sie bewerten Sie nur Ihren eigenen Eindruck. Die Gegenüberstellung zeigt einen Tausch. Links volle Kontrolle über das Gespräch, aber kaum Wiederholbarkeit.

1:42 Rechts weniger Kontrolle, dafür derselbe Maßstab über verschiedene Stände hinweg. Beides hat seinen Platz, und die Dokumentation empfiehlt ausdrücklich, beides zu nutzen. Übersetzt in die Praxis: Der Testchat zeigt Ihnen den Weg, die Evaluation zeigt Ihnen die Verteilung. Wer nur das eine macht, kennt entweder die Ursachen nicht oder das Ausmaß.

2:04 Der zweite Punkt ist der methodische Kern: Erst die Wiederholbarkeit macht aus einer Beobachtung einen Befund. Im Gespräch klingt „das hat gestern anders geantwortet" nach Meinung. Mit zwei vergleichbaren Läufen ist es eine Feststellung. Praktisch nützlich ist auch der dritte Punkt — zu jedem Testfall können Sie Details, Transkript und Aktivitätskarte ansehen.

2:25 Damit verbinden sich die beiden Werkzeuge: Die Evaluation findet den Fall, die Aktivitätskarte erklärt ihn. Und beachten Sie den letzten Punkt: Testchat-Aktivität erscheint nicht in der Auswertung. Der erste Punkt ist der verbreitetste in Pilotprojekten: Der Testchat gilt als Nachweis, obwohl nichts davon wiederholbar ist.

2:45 Der zweite ist der halbe Schritt — Testfälle in einem Dokument statt im Testset; gepflegt wird so eine Datei nie. Der dritte ist ein Messfehler, den man leicht macht: beim Wiederholen umformulieren. Und der vierte ist der unangenehmste, weil er unbewusst passiert — die erwartete Antwort wird nach dem Lauf angepasst, bis sie passt. Dann misst man nur noch sich selbst.

Testsets zusammenstellen

3:07 Kommen wir zum Aufbau. Und zur wichtigsten Frage dabei: Was gehört eigentlich hinein? Die Antwort fällt anders aus, als die meisten beim ersten Testset vermuten. Ein Testset bündelt Testfälle, und es gibt drei Wege dorthin: erzeugen lassen aus Wissen und Topics, aus einer Datei importieren oder von Hand schreiben. Das Erzeugen ist verlockend und ein guter Start — es hat aber einen blinden Fleck, auf den wir gleich kommen.

3:33 Und eine Besonderheit lohnt Aufmerksamkeit: Zu einem Lauf gehört wahlweise ein Nutzerprofil. Damit können Sie nachstellen, wie der Agent gegenüber Menschen mit anderen Rechten antwortet. Genau das ist im Betrieb der Normalfall. Achten Sie auf das Verhältnis: Nur die erste Zeile prüft, ob der Agent etwas kann. Die übrigen prüfen, ob er ehrlich bleibt, wenn er es nicht kann.

3:56 Das ist bei dieser Technik die eigentliche Qualität. Die Fußzeile ergänzt etwas, das Sie nicht selbst bauen müssen: Vier Sicherheitsprüfungen kommen dazu — Hass und Unfairness, sexuelle Inhalte, Gewalt, Selbstverletzung. Die laufen zusätzlich zu Ihren fachlichen Fällen. Sie sind eine Unterstützung, keine Garantie; das sagt Microsoft selbst deutlich.

4:18 Hier schließt sich ein Bogen zum ersten Tag: Schritt eins holt die Akzeptanzkriterien aus Modul 2 hervor. Wenn Sie die damals prüfbar formuliert haben, ist dieser Teil heute fast geschenkt. Schritt drei benennt den blinden Fleck erzeugter Testsets — fehlendes Wissen und Werkzeugfehler müssen Sie ausdrücklich aufnehmen, die entstehen nicht von selbst.

4:37 Schritt vier wählt ein passendes Profil. Und Schritt fünf ist eine Warnung vor dem eigenen Eifer: Der Umfang soll so sein, dass das Set gepflegt wird. Nicht größer. Der erste Punkt ist die Falle des bequemen Wegs: Das Set wird erzeugt und nie durchgesehen — dann prüft es die eigenen Annahmen und bestätigt sie zuverlässig.

4:56 Der zweite ist das reine Erfolgsset. Der dritte ist der Wildwuchs: Bei jeder Änderung kommen Fälle dazu, bis niemand mehr pflegt. Und der vierte ist der, der uns diese Woche begleitet — geprüft wird mit einem Profil, das mehr Rechte hat als die Zielgruppe. Dann bestehen alle Tests, und im Betrieb schweigt der Agent.

Ergebnisse bewerten

5:16 Jetzt haben wir Zahlen. Bleibt die Frage, was sie eigentlich aussagen — und, fast noch wichtiger, was sie nicht aussagen. Denn eine Punktzahl wirkt verbindlicher, als sie ist. Der Ablauf ist einfach: Die Fragen gehen an den Agenten, die Antworten werden festgehalten, mit der Erwartung oder einem Qualitätsmaßstab verglichen, und jeder Fall bekommt eine Bewertung.

5:37 Interessant ist, dass ein Testset mehrere Prüfmethoden gleichzeitig nutzen kann — der Vergleich der Bedeutung etwa und die Textähnlichkeit. Das ist nützlich, weil die Methoden verschiedene Dinge sehen: Die eine erkennt, ob dasselbe gemeint ist, die andere, ob dasselbe dasteht. Hier wird es grundsätzlich. Eine Bewertung sagt, ob eine Antwort der Erwartung entspricht — nicht, ob sie richtig ist.

6:00 Und die Erwartung hat ein Mensch formuliert, der sich irren kann. Auch die Sicherheitsprüfungen ändern daran nichts: Sie unterstützen verantwortliche Nutzung, garantieren aber nichts. Das steht so in der Dokumentation, und es ist ein wichtiger Satz für jedes Freigabegespräch. Eine Punktzahl ersetzt keine fachliche Freigabe. Sie macht sie nur begründbar.

6:22 Die Logik dieser Tabelle: Das Muster des Fehlschlags verrät die Ursache. Fällt eine ganze Fallart durch, fehlt etwas Strukturelles — Wissen oder ein Werkzeug. Schwanken einzelne Fälle, sind wir beim Thema von gestern: Beschreibungen und Quellenangaben. Die dritte Zeile ist die, an die man zuletzt denkt — Antwort richtig, Bewertung schlecht heißt oft, dass die Erwartung zu eng formuliert war.

6:45 Und die vierte betrifft mehrsprachige Agents, bei denen ein Sprachwechsel die Prüfung scheitern lässt. Der erste Punkt ist typisch für Berichte nach oben: Die Gesamtpunktzahl wird gemeldet, die Einzelfälle sieht sich niemand an — dabei stecken dort alle Hinweise. Der zweite ist bequem und falsch: einen schlecht bewerteten Fall verwerfen, statt ihn zu untersuchen.

7:07 Der dritte ist der, vor dem wir eben gewarnt haben — die fachliche Freigabe auf die Bewertung schieben. Und der vierte ist eine Einschränkung für den öffentlichen Sektor: In Government-Umgebungen fehlen Nutzerprofile und die Ähnlichkeitsmethode.

Regressionstests nach Änderungen

7:21 Zum Schluss die Disziplin, die aus Messen Verbesserung macht. Denn eine einzelne Messung ist nur eine Momentaufnahme — interessant wird es erst im Vergleich zweier Stände. Ein Regressionstest wiederholt ein unverändertes Testset nach einer Änderung. Das entscheidende Wort ist „unverändert" — daran hängt die ganze Aussagekraft.

7:41 Praktisch interessant sind die Wege, auf denen sich ein Lauf starten lässt: über die Oberfläche, über die Power-Platform-Schnittstellen oder als Aktion in Werkzeugen, Flows und Power Automate. Damit lässt sich die Prüfung in eine Bereitstellungskette einhängen. Für Teams, die schon mit solchen Ketten arbeiten, ist das die eigentlich gute Nachricht dieses Moduls.

8:02 Fünf Schritte, die aus der Wissenschaft stammen könnten: messen, genau eine Sache ändern, wieder messen, vergleichen, vollständig berichten. Besonders der letzte Punkt verdient Aufmerksamkeit — Verbesserungen und Verschlechterungen zusammen berichten. Denn fast jede Änderung an einem Agenten verbessert etwas und verschlechtert etwas anderes, das ist normal. Nur sieht man das Zweite nur, wenn man hinschaut.

8:25 Und die Fußzeile nennt den häufigsten Fehler: Wer das Testset mitändert, misst zwei Dinge auf einmal und kann keines belegen. Der erste Punkt ist eine ehrliche Beobachtung aus der Praxis: Ein Lauf per Hand wird ausgelassen, sobald es eilig wird — und eilig ist es immer. Als Aktion in einer Kette läuft die Prüfung dagegen bei jeder Änderung mit, ohne dass jemand daran denken muss.

8:48 Der dritte Punkt ist der längerfristige Nutzen: Ergebnisse über die Zeit zeigen Trends, die ein Einzellauf nie zeigt. Und der vierte ist eine Einschränkung, die man kennen sollte: Für Fabric-Datenagenten steht die Evaluation derzeit nicht zur Verfügung. Der erste Punkt ist der schwerwiegendste: Testset und Agent werden gemeinsam geändert — damit ist der Vergleich wertlos.

9:09 Der zweite ist menschlich, aber unaufrichtig: nur die Verbesserungen berichten. Der dritte ist ein Planungsfehler, der sich nicht heilen lässt — wer vor der Änderung nicht gemessen hat, kann hinterher nichts vergleichen. Und der vierte verengt den Blick: Nach einer Änderung nur den geänderten Bereich zu prüfen, übersieht genau die Nebenwirkungen, um die es beim Regressionstest geht.

Übung

9:31 Jetzt messen wir zum ersten Mal, wie gut der Lernlotse wirklich ist. Bis hierhin haben wir ihn gebaut und ausprobiert. Ab jetzt bekommen wir Zahlen — und die sind selten so gut wie der Eindruck. Der Lernlotse kann inzwischen drei Dinge: Fragen aus dem Bereich Weiterbildung beantworten, Anfragen aufnehmen und den Status aus Kursbuch lesen.

9:52 Damit ist er zum ersten Mal messbar — vorher hätten wir nur Einzelteile geprüft. Und das ist ein guter Zeitpunkt: früh genug, um noch etwas zu ändern, und spät genug, dass sich die Mühe lohnt. Das Lernziel verbindet den ersten Tag mit dem heutigen: aus Akzeptanzkriterien ein wiederholbares Testset bauen und Änderungen daran belegen.

10:12 Zwölf Fälle über alle vier Fallarten, zwei behobene Schwächen, ein zweiter Lauf als Nachweis. Wer früh fertig ist, führt zusätzlich einen Lauf mit einem Profil mit geringeren Rechten durch — und wird vermutlich überrascht sein. Das ist ausdrücklich erwünscht: Lieber hier überrascht werden als im Betrieb. Die Schritte folgen exakt dem Vorgehen aus Kapitel 4. Erst messen, dann zwei Schwächen auswählen und — wichtig — die Ursache benennen, bevor Sie etwas ändern.

10:39 Dafür haben Sie die Aktivitätskarte von gestern. Dann beheben, dann denselben Lauf wiederholen und beide Ergebnisse gegenüberstellen. Fünfundsiebzig Minuten sind dafür realistisch, wenn Sie die Kriterien aus Modul 2 dabei haben. Falls nicht, wissen Sie jetzt, wofür die gut waren. Der erste Punkt ist häufiger, als man denkt: Zwölf Fälle, die dasselbe in zwölf Formulierungen prüfen — das fühlt sich nach Gründlichkeit an und ist keine.

11:06 Der zweite ist das Vermuten statt Nachsehen. Der dritte ist die gleichzeitige Behebung beider Schwächen, womit die Wirkung nicht mehr zuzuordnen ist. Und der vierte ist das geänderte Testset im zweiten Lauf, das gar nichts belegt. Morgen bringen wir den Lernlotsen dorthin, wo die Leute wirklich arbeiten — und schauen, was das an Vorbereitung verlangt.