Start / Seminare / Microsoft Copilot Studio in der Praxis
Modul
Generative Orchestrierung
Modul 5 von 11 aus dem Seminar Microsoft Copilot Studio in der Praxis
5 Kapitel in diesem Modul-Video · Laufzeit
Für Teams
Die Videos zeigen, wie es geht. Die Schulung sorgt dafür, dass Ihr Team es danach tut.
Ein Video kann niemanden fragen, warum es ausgerechnet in Ihrem Repository nicht funktioniert. Es kann kein Team auf eine gemeinsame Konvention bringen. Und es setzt sich niemand freiwillig drei Tage hin. In der Schulung sind am Ende alle auf demselben Stand, gearbeitet wurde am eigenen Code, und die offenen Fragen sind entschieden — in ein paar Tagen statt irgendwann nebenbei.
Vorgespräch am Telefon · Programm nach Maß · ab 1 Tag (8 Unterrichtseinheiten) · Teilnahmezertifikat
Transkript
Der gesprochene Text dieses Moduls zum Mitlesen, Überfliegen und Durchsuchen. Ein Klick auf einen Zeitstempel springt an die Stelle im Video.
Generative Orchestrierung
0:00 Gestern haben Sie Bausteine gebaut — Wissensquellen und ein Topic. Heute beschäftigen wir uns mit der Frage, wer eigentlich entscheidet, welcher dieser Bausteine bei einer Anfrage zum Zug kommt. Im generativen Modus ist das nicht mehr eine Liste von Stichworten, sondern der Agent selbst. Das ist bequem und im Alltag erstaunlich gut — aber es verschiebt Ihre Arbeit.
0:21 Sie steuern nicht mehr über Regeln, sondern über Sprache: über die Beschreibung jedes Bausteins. Dieses Modul zeigt, wie das funktioniert, wie man es beobachtet und wo man dem Agenten die Entscheidung besser abnimmt.
Generative Orchestrierung
0:34 Der dritte Tag beginnt mit dem Auswahlverhalten: Was fließt überhaupt in die Entscheidung des Agenten ein? Danach geht es um Beschreibungen, die auseinanderhalten — das wichtigste Handwerkszeug dieses Modus. Im dritten Kapitel lernen Sie den Aktivitätsverlauf kennen, mit dem Sie nicht mehr raten müssen, warum eine Antwort so ausfiel.
0:53 Und zum Schluss ziehen wir eine Grenze: Wo darf der Agent nicht mehr selbst entscheiden?
Wie der Agent auswählt
0:59 Fangen wir beim Grundprinzip an — und bei einem wichtigen Unterschied zur klassischen Betriebsart. Wer von dort kommt, muss hier eine Gewohnheit ablegen: Es gibt keinen Treffer mehr, sondern eine Auswahl. Der Unterschied ist grundlegender, als es zunächst wirkt. Klassisch sucht der Agent ein einzelnes Topic, das am besten zu den hinterlegten Phrasen passt — wie ein Sortierer, der jeden Brief in genau ein Fach legt.
1:23 Generativ stellt er sich dagegen einen kleinen Plan zusammen: vielleicht eine Wissensquelle, dann ein Topic, dann ein Werkzeug. Und noch eine Angabe, die Sie kennen sollten: Neue Agents stehen standardmäßig auf generativer Orchestrierung. Sie müssen das also nicht einschalten — Sie müssen es abschalten, wenn Sie es nicht wollen.
1:43 Achten Sie auf die unteren beiden Zeilen, dort steckt der praktische Unterschied für Ihre Arbeit. Generativ fragt der Agent fehlende Angaben selbst nach und formuliert die Antwort selbst. Klassisch müssen Sie beides bauen — Frageknoten für jede Angabe, Nachrichtenknoten für jede Antwort. Das erspart im generativen Modus viel Fleißarbeit.
2:02 Es nimmt Ihnen aber auch Kontrolle ab, ohne dass Sie gefragt werden. Genau diesen Tausch sollten Sie bewusst eingehen — und wissen, wo Sie ihn zurücknehmen. Der erste Punkt ist der wichtigste des ganzen Moduls: Wichtigster Faktor ist die Beschreibung. Nicht der Name, nicht die Technik — die Beschreibung. Dazu kommen der Name sowie die Namen und Beschreibungen der Ein- und Ausgaben.
2:25 Und dann etwas, das im Alltag für Verwirrung sorgt: Der bisherige Gesprächsverlauf beeinflusst die Entscheidung ebenfalls. Deshalb kann eine Anfrage im frischen Testchat anders ausgehen als im laufenden Gespräch. Das ist kein Fehler — das ist die Funktion, die Rückfragen überhaupt erst möglich macht. Vier dokumentierte Eigenheiten, die man kennen sollte. Der erste Punkt ist der eben erwähnte Kontexteinfluss.
2:49 Der zweite ist eine echte Lücke: Das Systemthema für mehrere Treffer wird derzeit nicht aufgerufen — der Agent fragt also nicht nach, wenn zwei Topics gleich gut passen, sondern wählt einfach. Der dritte betrifft die Länge des Gesprächsverlaufs, die begrenzt ist; frühe Angaben können später fehlen. Und der vierte überrascht viele Umsteiger: Das Systemthema Conversational boosting greift im generativen Modus nicht mehr, Anpassungen daran bleiben wirkungslos.
Zuständigkeiten unterscheidbar beschreiben
3:16 Damit sind wir beim Handwerk dieses Modus. Beschreibungen sind hier keine Dokumentation — sie sind Steuerung. Und weil sie in Sprache geschrieben sind, wirkt jede Nachlässigkeit sofort auf das Verhalten. Stellen Sie sich die Beschreibungen als Türschilder in einem Amt vor. Stehen an zwei Türen ähnliche Schilder, laufen die Leute zur falschen — und niemand kann vorhersagen, zu welcher. Genau so verhält sich die Orchestrierung.
3:43 Microsoft empfiehlt deshalb erstaunlich konkrete Regeln: einfache, direkte Sprache, Aktiv und Präsens, ein bis zwei Sätze, ein eindeutiger und beschreibender Name statt eines allgemeinen. Und Stichwörter aus der Sprache der Nutzenden, nicht aus der internen Fachsprache. Klingt nach Redaktionsarbeit. Ist es auch. Schauen Sie sich an, was die drei Beschreibungen gemeinsam haben: Jede sagt in einem ersten Satz, was sie tut — und in einem zweiten, was sie nicht tut.
4:11 Genau dieser zweite Satz macht die Arbeit. Nachschlagen nimmt keine Anfrage auf. Aufnehmen gibt keine Auskunft. Das klingt nach Überdeutlichkeit, ist aber genau das Mittel, das zwei ähnliche Zuständigkeiten zuverlässig trennt — zuverlässiger als jedes zusätzliche Stichwort. Wenn Sie aus diesem Modul eine Sache mitnehmen, dann diese.
4:32 Der rote Faden: Überschneidungen findet man nicht beim Schreiben, sondern beim Nebeneinanderlegen. Deshalb Schritt eins — alle Bausteine mit Namen und Beschreibung auf eine Seite. Dann Paare suchen, die sich überschneiden. Dann den Unterschied in einem Satz benennen; wenn Ihnen das schwerfällt, haben Sie vermutlich zwei Bausteine, die eigentlich einer sein sollten.
4:53 Danach beiden den Ausschluss des jeweils anderen hinzufügen. Und zum Schluss mit denselben Anfragen erneut testen — sonst wissen Sie nicht, ob Ihre Redaktionsarbeit etwas bewirkt hat. Der erste Punkt ist das Musterbeispiel aus der Dokumentation: „beantwortet Fragen" — das hilft der Auswahl kein Stück, weil es auf jeden Baustein zutrifft.
5:13 Der zweite ist der Fachjargon, den das Modell genauso wenig einordnen kann wie ein neuer Kollege. Der dritte betrifft Umsteiger: Beim Wechsel in den generativen Modus werden Beschreibungen automatisch aus den Triggerphrasen erzeugt. Die sind oft brauchbar — aber eben nur oft. Und der vierte ist der gedankliche Fehler dahinter: Beschreibungen für Menschen zu schreiben, obwohl sie Steuerung sind.
Aktivitätsverlauf lesen
5:37 Und jetzt das Werkzeug, mit dem Sie aufhören können zu raten. Denn die häufigste Frage bei einer seltsamen Antwort lautet: Warum hat er das gemacht? Darauf gibt es eine Antwort, man muss nur hinsehen. Die Aktivitätskarte ist eine Art Fahrtenschreiber für den Agenten: Sie zeigt, welche Bausteine gewählt wurden, in welcher Reihenfolge sie liefen und welche Eingaben der Agent selbst gefüllt hat.
6:00 Das klingt unscheinbar, ist aber der Unterschied zwischen systematischer Arbeit und Herumprobieren. Denn sie beantwortet die eine Frage, auf die es ankommt: War der richtige Baustein gar nicht da — oder war er da und wurde nicht gewählt? Das sind zwei völlig verschiedene Probleme mit zwei völlig verschiedenen Lösungen. Genau diese Unterscheidung steckt in Schritt drei, dem Kern des Vorgehens.
6:22 Davor steht etwas Unscheinbares, das trotzdem häufig schiefgeht: die Anfrage im Wortlaut festhalten, nicht sinngemäß. Wer beim zweiten Versuch anders formuliert, misst etwas anderes. Schritt vier leitet die Maßnahme aus der Ursache ab — Beschreibungen bei falscher Auswahl, Quellen bei fehlendem Wissen. Und Schritt fünf verlangt den Beleg.
6:42 Beachten Sie dazu die Fußzeile: Ein Modellwechsel kann das Verhalten ändern, testen Sie also mit dem Modell, das der Agent wirklich nutzt. Der Gedanke dahinter ist einfach und wird trotzdem oft übergangen: Eine fehlende Quelle behebt man mit Dokumenten, eine falsche Auswahl mit Formulierungen. Wer das verwechselt, legt noch mehr Dokumente nach, obwohl das Problem in der Beschreibung steckt — und wundert sich, dass nichts besser wird.
7:08 Oder schleift an den Beschreibungen, obwohl schlicht ein Dokument fehlt. Beides kostet Tage. Der letzte Punkt ist der methodische: Ohne festgehaltene Anfrage lässt sich die Verbesserung später nicht belegen. Der erste Punkt ist der Reflex: ändern, bevor man nachgesehen hat. Der zweite ist der wissenschaftliche Kardinalfehler, der auch hier gilt — mehrere Änderungen gleichzeitig, und danach ist nicht mehr zuzuordnen, welche gewirkt hat.
7:33 Der dritte ist ein Detail mit Folgen: Der Testchat zählt nicht in die Auswertung des Agenten, Beobachtungen aus dem Bauen gehen also verloren, wenn Sie sie nicht selbst notieren. Und der vierte ist eine Darstellungssache — Verknüpfungen aus Dokumenten erscheinen in der Antwort als reiner Text, nicht als anklickbarer Link.
Feste Schritte für sensible Aktionen
7:51 Bleibt die Frage, wo das Selbstentscheiden aufhört. Und da ist die Antwort erfreulich eindeutig — anders als bei vielem, was wir heute besprochen haben. Diese Grenze ist keine Geschmacksfrage. Die Linie verläuft zwischen Holen und Handeln. Welche Auskunft der Agent holt, darf er selbst entscheiden — im schlimmsten Fall ist die Antwort unpassend, und jemand fragt nach.
8:14 Ob eine folgenreiche Aktion ausgeführt wird, darf er nicht selbst entscheiden. Dafür gibt es drei Mittel: ein Topic mit Bestätigung, die Einstellung, vor dem Aufruf eines Werkzeugs zu fragen, und menschliche Freigaben im Agent Flow. Alle drei sind vorhanden. Sie müssen nur gesetzt werden — von allein passiert das nicht. Die Sortierung folgt einer einzigen Frage: Was passiert, wenn der Agent sich irrt? Bei einer Auskunft ist die Antwort unpassend.
8:41 Bei einem lesenden Blick ins Fachsystem ebenso — deshalb stehen die ersten beiden Zeilen auf frei wählbar. Ab der dritten Zeile hinterlässt ein Irrtum Spuren: ein Vorgang, eine Nachricht an Dritte, eine Kostenfolge. Und Spuren muss jemand beseitigen. Beachten Sie die letzte Zeile: Bei Kostenfolgen genügt keine Bestätigung durch irgendwen — es braucht eine benannte Rolle.
9:04 Das ist eine der wichtigsten Voreinstellungen im ganzen Produkt, und sie steht auf Nein. Vor dem Ausführen zu fragen, ist je Werkzeug einzeln einzuschalten. Wer das vergisst — und man vergisst es —, lässt eine schreibende Aktion ohne Rückfrage laufen. Der dritte Punkt ist ebenso wichtig: Eine Bestätigung wirkt nur, wenn sie zeigt, was gleich passiert.
9:25 „Soll ich fortfahren?" ist keine Bestätigung, sondern eine Höflichkeitsfloskel. Und der vierte hilft beim Abbruch: Der Knoten zum Beenden aller Themen stoppt auch die bereits geplanten Schritte. Der erste Punkt ist die inhaltsleere Bestätigung, die wir gerade besprochen haben. Der zweite ist die Bequemlichkeit im Entwurf: Eine schreibende Aktion wird zum frei wählbaren Werkzeug, weil der Testablauf damit flüssiger ist.
9:50 Der dritte ist besonders tückisch — zwei Werkzeuge können dasselbe, aber nur eines ist abgesichert; der Agent wählt dann irgendwann das andere. Und der vierte ist der Umgehungsfall: Der feste Schritt existiert, aber der Agent erreicht das Ziel auch ohne ihn. Prüfen Sie das gezielt.
Übung
10:07 Jetzt beobachten Sie das Auswahlverhalten selbst — mit Anfragen, die es absichtlich schwer machen. Genau solche Anfragen stellen Menschen im Alltag, ohne zu ahnen, wie anspruchsvoll sie damit sind. Der Lernlotse hat inzwischen zwei Topics und eine Wissensquelle. Drei Anfragen bringen ihn in Bedrängnis: eine mehrteilige, die zwei Dinge auf einmal will; eine mehrdeutige, die zu beiden Topics passen könnte; und eine, die auf eine frühere Angabe im Gespräch zurückgreift.
10:35 Das sind keine konstruierten Sonderfälle — so reden Menschen. Genau deshalb sind sie der ehrlichste Test für die Orchestrierung. Das Lernziel hat zwei Teile: erklären und beeinflussen. Erklären heißt, aus dem Aktivitätsverlauf abzulesen, was passiert ist. Beeinflussen heißt, genau eine begründete Änderung an Beschreibung oder Anweisung vorzunehmen.
10:56 Und dann folgt der Teil, der die Übung wertvoll macht: der zweite Durchlauf, der die Wirkung belegt. Wer früh fertig ist, ergänzt eine vierte Anfrage, die zwei Bausteine hintereinander auslösen muss — daran sehen Sie, wie der Agent Schritte verkettet. Zwei Dinge sind an diesem Ablauf entscheidend. Erstens: Die erwartete Auswahl wird vorher notiert. Sonst passt man die Erwartung unbewusst an das an, was passiert ist.
11:22 Zweitens: jede Anfrage im frischen Testchat. Denn im laufenden Gespräch trägt der Kontext mit, und Sie messen etwas anderes als gedacht. Schritt vier begrenzt bewusst auf genau eine Änderung je Anfrage. Und Schritt fünf stellt beide Durchläufe nebeneinander — erst dieser Vergleich macht aus Ihrer Änderung einen Nachweis.
11:43 Alle vier Punkte sind Messfehler, keine Baufehler. Der erste ist der Kontext aus dem laufenden Gespräch. Der zweite sind mehrere Änderungen auf einmal. Der dritte ist die nachträglich notierte Erwartung. Und der vierte ist der, den man am leichtesten übersieht: Ein einziger Durchlauf gilt als Beweis, obwohl wir heute gelernt haben, dass das Verhalten schwanken kann.
12:05 Wenn Ihnen ein Ergebnis wichtig ist, stellen Sie die Frage zweimal. Im nächsten Modul geben wir dem Agenten Werkzeuge — und damit die Möglichkeit, tatsächlich etwas zu tun.
Dieses Modul als Schulung für Ihr Team
Das Video zeigt den Stoff. In der Schulung arbeitet Ihr Team damit — an Ihrem eigenen Code, mit Übungen und mit den Fragen, die ein Video nicht beantwortet. Sie wählen die Module aus Microsoft Copilot Studio in der Praxis, wir bauen daraus ein Programm.
5 Tage·ab 900 EUR netto pro Tag (bis 3 Teilnehmende) ·Termin nach Vereinbarung