Del via

Anvend generative orkestreringsmuligheder

Generativ orkestrering er udviklingen af samtaleagentudvikling i Copilot Studio. Den introducerer et stort sprogmodel (LLM) drevet planlægningslag, der fortolker brugerens intention, bryder komplekse forespørgsler ned, vælger de rette værktøjer og viden og udfører flertrinsplaner med sikkerheds- og overholdelsesrammer. I stedet for udelukkende at stole på håndlavede samtaleemner, sammensætter generativ orkestrering genanvendelige byggesten – handlinger, emner, videnskilder, børneagenter og autonome triggere – til intelligente arbejdsgange.

I Copilot Studio giver generativ orkestrering bedre svar med mindre manuel scripting. I denne artikel lærer du om arkitekturen bag generativ orkestrering, og hvordan du laver effektive instruktioner og tester og finjusterer dine orkestrerede agenter.

Hvorfor betyder generativ orkestrering noget?

Traditionelle emnedrevne designs kræver flere håndlavede emner, stiv forgrening og manuel logik til at udfylde pladser. Denne tilgang kan føre til:

  • Store emneinventarer med overlappende logik.
  • Vanskeligheder med at håndtere tvetydige eller flerorienterede ytringer.
  • Inkonsekvente oplevelser, når brugere formulerer spørgsmål forskelligt.
  • Høje vedligeholdelsesomkostninger, når API'er eller forretningsregler ændres.

Generativ orkestrering løser disse udfordringer ved at:

  • At reducere emnespredning ved at skrive genanvendelige byggesten.
  • Automatisering af udfyldning af slots baseret på inputdefinitioner.
  • Tilpasning af responsstil og planstruktur dynamisk.
  • Forbedring af relevans gennem semantisk videnssøgning.
  • Muliggør proaktive forslag til næste skridt.

Arkitektur og komponenter

På et overordnet niveau består en generativ orkestratoragent af flere nøglekomponenter, der arbejder sammen:

  • Orkestratoren (planlægger): Den LLM-drevne hjerne hos agenten, der omdanner et input, som en brugerbesked eller begivenhed, til en struktureret plan. Orkestratoren identificerer intentionerne, vælger hvilke værktøjer, emner eller agenter der skal kaldes for hvert trin, og definerer sekvensen og dataflowet mellem trinene. Den udgiver en ordnet liste af trin ("en "plan"), som kørselstiden udfører, og sikrer, at hvert trin er inden for politikken. For eksempel søger den godkendelse til følsomme handlinger.

  • Videnslag: Et sæt hentekilder, såsom interne vidensbaser, dokumenter, databaser og mere, som agenten kan forespørge for at finde sine svar. Orkestratoren bruger dette lag til at hente faktuel information eller vejledning. Resultaterne indeholder ofte citater og metadata, som agenten kan indarbejde i svarene for gennemsigtighed. Videnslaget er skrivebeskyttet og giver beviser eller kontekst.

  • Værktøjer og connectors: Eksterne handlinger, API'er eller automatiseringsflows, som agenten kan kalde som en del af en plan. Hvert værktøj har en defineret grænseflade: inputparametre (med forventede typer), outputvariabler og eventuelt fejlbetingelser. De er i bund og grund agentens "færdigheder" til at udføre operationer, såsom at slå en ordre op, sende en e-mail eller køre et script. Du bør grundigt teste værktøjer og sikre, at de opfører sig deterministisk med de samme input, da orkestratoren behandler dem som pålidelige funktioner.

  • Emner og inline-agenter: Genanvendelige samtaleemner eller mini-dialoger, der indkapsler specifik logik. I generativ orkestrering kan planlæggeren påkalde emner ikke kun ved triggersætninger, men også når deres beskrevne formål matcher brugerens behov. Inline-agenter refererer til små, fokuserede emner eller rutiner, der bruges som deltrin inden for en større plan. De kører inden for hovedagentens kontekst og håndterer diskrete opgaver, så hovedorkestratoren ikke behøver at scripte disse detaljer eksplicit.

  • Hændelsestriggere (autonomi): Mekanismer, der starter orkestratoren uden en brugerbesked. Disse mekanismer kan være planlagte triggere eller hændelsesbaserede triggere, som en opdatering af databaseposten, der får agenten til autonomt at starte en plan. Hver trigger kan have sine egne betingelser og instruktioner. Autonome triggere gør det muligt for agenten at handle proaktivt ved at igangsætte arbejdsgange, når visse betingelser er opfyldt, i stedet for kun at reagere på brugerens chatinput.

Kontrollag og beslutningsgrænser

I en produktionskvalitetsagent skal du ikke overlade alle beslutninger til AI'en. Typisk findes der tre kontrollag:

  • Deterministisk lag: Dette lag bruger traditionel, regelbaseret logik, som du stadig håndhæver for missionkritiske eller irreversible handlinger. For eksempel, når du behandler en betaling eller sletter en post, kan du bruge et strengt forfattet emne eller flow, der udføres trin for trin uden nogen AI-fortolkning. Dette lag kan også inkludere eksplicitte kontroller eller valideringer af følsomme data. Hvis noget skal ske præcis som specificeret, skal det håndteres deterministisk. Du kan konfigurere den generative orkestrator, så den ikke overskriver eller ændrer disse flows. I praksis kan det være, at du enten ikke eksponerer sådanne handlinger for AI-planlæggeren eller altid indkapsler dem i et emne, der kræver brugerbekræftelse.

  • Hybrid (intercept) lag: Dette lag tilføjer noget AI-fleksibilitet omkring hovedsageligt deterministiske strukturer. Du tillader orkestratoren at operere inden for fastsatte grænser med mulighed for menneskelig eller regelbaseret aflytning. For eksempel kan en agent automatisk udarbejde et svar eller udføre en handling, men du kan indsætte et godkendelsestrin, så en leder kan gennemgå det. Eller agenten kan håndtere en opgave op til en vis værdigrænse og derefter blive pålagt at eskalere. Det hybride lag foruddefinerer punkter, hvor AI'ens autonome plan bliver checkpointet. Brug denne tilgang til processer med mellemstor risiko: lad AI'en tage sig af det tunge arbejde, men hold et menneske med i opsynet.

  • AI-orkestratorlag: Dette lag er fuldt generativt. LLM-planlæggeren har frihed (inden for sikkerhedsrammerne) til at udarbejde og udføre planer for lavrisikoforespørgsler. De fleste Q&A-interaktioner, informationsopslag eller simple flertrinsanmodninger falder ind under denne kategori. For de fleste brugerspørgsmål kan agenten selvstændigt beslutte, hvordan de skal løses og handle. Dette lag giver tilpasningsevnen og kraften fra generativ AI. Det er bundet af politikker. For eksempel kan AI'en vide, at den ikke må kalde visse admin-værktøjer eller afsløre visse oplysninger. Agenten behøver ikke stoppe op og bede om tilladelse til rutineopgaver.

Givet disse lag, definer eksplicit beslutningsgrænser. Se på hvilke handlinger og emner:

  • Kan udføres uden bekræftelse (AI'en kan bare gøre dem)
  • Krav brugerens bekræftelse i samtalen (for eksempel: "Er du sikker på, at du vil slette alle poster?")
  • Krav om offline-godkendelse (for eksempel skal en administrator bekræfte via en godkendelsesproces)

Handhæv disse grænser gennem dit emnedesign, for eksempel ved at tilføje en bekræftelsesnode, via platformens godkendelsesfunktioner eller via logik i triggerne. Ved at lægge kontrol på lag sikrer du, at agenten opererer sikkert—AI'en håndterer det, den er god til, mens mennesker eller strenge regler håndterer det, AI'en ikke bør beslutte alene.

Bedste praksis for agentinstruktioner

Korrekt udarbejdede agentinstruktioner påvirker kvaliteten af planudarbejdelsen.

  • Kontekstuel relevans

    • Sørg for, at instruktionerne kun refererer til de værktøjer og den viden, der er tilgængelig for agenten.
    • Brug de præcise værktøjsnavne, variabelnavne og Power Fx-identifikatorer.

  • Samtaleretningslinjer

    • Angiv svarformat (lister, tabeller, fed skrift).
    • Giv stilistisk vejledning ("kortfattet," "inkluder citater," "foreslå næste skridt").
    • Undgå at nævne specifikke videnskilder direkte. Beskriv dem i stedet.

  • At beslutte, hvornår man skal bruge værktøjer eller viden

    • Foretrækker at bruge værktøjsnavne. Navne vejer tungere end beskrivelser.
    • Beskriv videnskapaciteter generelt for at undgå forkerte oplysninger.

  • Autonome eksekveringsinstruktioner

    • Definér den forventede rækkefølge af handlinger for flertrinsarbejdsgange.
    • Kombiner procesinstruktioner med specifikke prompts.

Lær mere i Konfigurér højkvalitetsinstruktioner til generativ orkestrering.

Design af emneinput og -output

Når du skriver emner, skal du være ekstra opmærksom på deres input- og outputparametre i generativ orkestreringsmode:

  • Definér klare inputparametre med beskrivelser: Hvis et emne eller en handling kræver visse oplysninger (som "Brugernavn" for et emne til nulstilling af adgangskoden), så lav et emneinput til det og giv det et beskrivende navn og eksempel. Orkestratoren bruger disse navne og beskrivelser til automatisk at spørge brugeren, om værdien mangler. Brug af en liste over accepterede værdier eller en Power Fx-valideringsformel for input kan hjælpe med at sikre, at botten indsamler gyldige data (for eksempel ved at begrænse en landekode til to bogstaver).

  • Brug auto-prompting: I generativ tilstand genererer agenten spørgsmål selv i stedet for at kræve, at du manuelt tilføjer spørgsmålsnoder for at bede om manglende information. Denne tilgang er en markant ændring fra klassiske bots. Nøglen er, at dine inputnavne skal være menneskevenlige (for eksempel "startdato", "e-mailadresse"), så AI'en kan stille et naturligt spørgsmål. Hvis AI'ens autogenererede spørgsmål ikke er formuleret ideelt, kan du overveje at finjustere inputbeskrivelsen eller navnet. Denne funktion strømliner dialogerne betydeligt, men den er afhængig af veldefinerede input.

  • Angiv output for emner, hvor det er relevant: Et emne kan producere outputvariabler, som orkestratoren bruger til at kompilere det endelige svar. For eksempel kan et emne "Store Finder" give NearestStoreLocation. Ved at udsende information i stedet for direkte at sende en besked til brugeren, tillader du orkestratoren at kombinere den information med andre trin på en elegant måde. Hvis et emnes indhold bruges i et større svar, opfang det som en outputvariabel og lad orkestratoren håndtere den endelige besked. Få mere at vide i Orchestrate agent adfærd med generativ AI.

  • Undgå "dobbelthåndtering" af data i prompts: Hvis du konfigurerer outputs, så lad være med at føre dem ind i LLM'en som åben kontekst. For eksempel, hvis en handling returnerer en resumétekst, skal du sende denne opsummering som et struktureret output og lade orkestratoren inkludere den, i stedet for at skrive en instruktion som "Resultatet af handlingen siger {summary}." Denne tilgang forhindrer modellen i at overgenerere eller gentage indhold. Output bør være endelige datapunkter, når det er muligt.

Kæde handlinger, emner og viden sammen

Fordi orkestratoren kan bruge flere funktioner på én tur, design med komponerbarhed for øje:

  • Giv alt intuitive navne og beskrivelser: Planlæggeren beslutter i høj grad at bruge et værktøj eller emne baseret på, hvor godt navnet og beskrivelsen matcher brugerens anmodning. Brug aktive sætninger, der stemmer overens med brugerens intentioner. For eksempel er et værktøj kaldet "TranslateText" med beskrivelsen "Oversætter tekst til et specificeret sprog" mere sandsynligt at blive valgt, når brugeren spørger om oversættelse, sammenlignet med et generisk navngivet "Flow1." Navne betyder mere end noget andet. Undgå kryptiske navne. Hvis agenten vælger det forkerte emne, så genbesøg navnene og beskrivelserne.

  • Giv et rigt "værktøjssæt", men kurater det: Forbind alle de nyttige handlinger, dit scenarie kan have brug for (API'er, flows osv.), og lav emner til vigtige flows. Denne tilgang giver AI'en flere muligheder for at løse forespørgsler. Fjern eller deaktiver dog værktøjer og emner, som du ved er irrelevante eller risikable for agenten, så de ikke forvirrer planlæggeren. Et mindre sæt af kvalitetsvalg er bedre end et udtømmende sæt med overlap. Overlappende beskrivelser kan få agenten til at prøve flere ting på én gang, hvilket måske ikke er ønskeligt.

  • Stol på planlæggeren, inden for rimelighedens grænser: Når komponenterne er veldefinerede, lad orkestratøren blande og matche. For eksempel, hvis brugeren spørger om noget, der kunne adresseres med en vidensartikel eller et live data-API, kan planlæggeren vælge at bruge begge dele – hente viden til baggrund og kalde API'en for aktuel information. Denne tilgang kan give et bedre svar. Omfavn denne autonomi, men følg med tidligt for at sikre, at der træffes gode valg.

  • Håndter flere intentioner: Hvis en brugerforespørgsel automatisk beder om to separate ting (som "åbn en ny konto og send mig detaljerne"), forsøger den generative planlægger at opfylde begge ved at påkalde de relevante sekvenser efter tur. Du behøver ikke manuelt at scripte branching for multi-intent. Dit job som udvikler er at sikre, at hver delopgave (kontoåbning, afsendelsesdetaljer) dækkes af et værktøj eller emne, og at deres output og input hænger sammen, hvis det er nødvendigt.

  • Lad viden supplere emner og værktøjer: Orkestratoren kan proaktivt kalde videnssøgning, ikke kun som en backup. Hvis du har en rig vidensbase konfigureret, kan agenten besvare en del af en forespørgsel med et vidensartikeluddrag, selvom en handling dækker en anden del. Denne funktionsmåde er tilsigtet. Hold din vidensbase opdateret med information, der ikke er let tilgængelig via værktøjer.

  • Vær opmærksom på omfanget af vidensbrug: I øjeblikket kan du ikke tvinge agenten til at bruge en specifik vidensartikel på kommando. AI'en vælger relevante artikler baseret på forespørgslen. Bemærk også begrænsninger. For eksempel bruges systememner som "Flere emner matchet" ikke i generativ tilstand, da planlæggeren håndterer flertydiggørelse forskelligt. Lær mere om andre kendte begrænsninger for generativ orkestrering.

Test og justering af det orkestrerede middel

Generativ orkestrering flytter noget logik fra eksplicit design til AI'ens "hjerne." Iterativ test sikrer, at den opfører sig som tiltænkt. Her er bedste praksis for at teste og forbedre din orkestrerede agent:

  • Brug aktivitetskortet: Copilot Studio leverer et aktivitetskort under testning, som viser de trin, orkestratoren har besluttet. Efter at have stillet din agent en kompleks forespørgsel, så undersøg planen: Hvilke emner eller handlinger blev aktiveret? I hvilken rækkefølge? Stillede den et passende opfølgende spørgsmål? Hvis agenten valgte det forkerte emne eller overså et værktøj, kan det være nødvendigt at forfine komponentbeskrivelser eller justere instruktionerne.

  • Gennemgå transskriptioner: Når agenten er offentliggjort, gennemgå samtaletransskriptioner eller logfiler regelmæssigt. Se efter hallucinationer eller unøjagtigheder i svarene. Hvis brugere giver feedback som "det er ikke korrekt", så følg tilbage for at se, hvorfor agenten troede, det var korrekt. Løs problemer ved at tilføje manglende fakta til vidensbasen, stramme instruktionerne eller i nogle tilfælde tilføje et nyt emne for at dække et hul. Lær mere i Extract and analyze agent-samtaletransskriptioner (referencearkitektur).

  • Iterer med små ændringer: Du kan ofte forbedre et generativt stof ved at lave subtile ændringer. For eksempel, hvis agentens output er for udførligt eller ikke i det ønskede format, juster instruktionerne om stil og format og test igen. Hvis det kalder et unødvendigt værktøj hver gang, er værktøjets beskrivelse måske for bred, og du kan forfine den, så den kun aktiveres, når det er passende. Lav én ændring ad gangen og bemærk effekten på mæglerens beslutninger.

  • Giv eksempler på ytringer (omhyggeligt): Du kan opleve, at tilføjelse af et par eksempler på brugerforespørgsler i et emnes beskrivelse kan hjælpe LLM'en med at forstå, hvornår det pågældende emne skal bruges. For eksempel: "Formål: Nulstill en brugers adgangskode. F.eks. kan brugeren sige 'Jeg glemte min adgangskode' eller 'nulstillede min Contoso-kontoadgang.'" Disse eksempler giver modellen ekstra hints. Overdriv det ikke, og hold beskrivelserne korte og fokuserede. Modellen har allerede meget kontekst—sørg bare for, at dine metadata er klare.

  • Overvåg præstationsmålinger: Efterhånden som forbruget vokser, hold øje med nøglemålinger som succesrate (løste agenten faktisk brugerens anmodning?), fallback-rate (hvor ofte der stod "Beklager, jeg kan ikke hjælpe med det"), og brugertilfredshed, hvis det er muligt. Selv under test kan simple optællinger af, hvor ofte hvert emne og værktøj bruges, antyde nødvendige justeringer. For eksempel, hvis et trivielt smalltalk-emne bliver brugt for ofte og tilføjer støj, skal du deaktivere det eller indsnævre dets beskrivelse. Gennemgå vejledningen om, hvordan du tester dine agenters præstation.

Generative systemer lærer implicit af dine konfigurationer og rettelser. Hver forbedring af instruktioner eller metadata gør AI'ens næste beslutning bedre. Med tiden bliver din orkestrerede agent mere præcis og effektiv til at håndtere forespørgsler.

Brugerdefinerede triggere i generativ orkestrering

Emnetriggere findes specifikt til generativ orkestrering. Ved at bruge disse triggere kan du koble dig på agentens livscyklus og indsætte brugerdefineret logik på kritiske punkter i orkestreringsprocessen. Der findes tre hovedtriggere:

Udløse Når det udløses Purpose
Om Anmodning om viden Lige før agenten udfører en vidensbaseforespørgsel Denne trigger lader dig opsnappe det øjeblik, hvor orkestratoren er ved at søge i videnskilderne. Den giver skrivebeskyttet adgang til de SearchPhrase eller nøgleord, agenten har til hensigt at bruge, samt en systemvariabel til at levere tilpassede søgeresultater. For eksempel kunne du fange forespørgslen og sende den til et proprietært indeks eller indsætte flere data i resultaterne.
Dette er en avanceret ("hemmelig") trigger—den er ikke synlig i brugerfladen som standard og skal i øjeblikket aktiveres via en YAML-redigering (ved at navngive et emne præcist OnKnowledgeRequested). Brug det, hvis du har brug for at udvide eller tilpasse videnssøgningstrinnet, såsom at filtrere visse resultater eller sammenflette eksterne data i videnssvaret.
AI-respons genereret Efter AI'en har udarbejdet et udkast til svar, men før det sendes til brugeren Agenten aktiverer denne trigger, når den har oprettet den endelige svartekst (baseret på alle værktøjs- og emneoutput) og lige før den leveres. Dette trin giver dig mulighed for programmatisk at ændre svaret eller dets referencer. For eksempel kan du efterbehandle teksten for at rette formatering, eller erstatte rå URL'er med venlige tracking-links. Du kan endda vælge at tilsidesætte svaret. Triggeren kan give en egen brugerdefineret besked, og du kan bruge et ContinueResponse flag til at angive, om det oprindelige AI-svar stadig skal sendes eller ej.
Brug denne trigger til sidste-øjebliks justeringer eller forbedringer af AI'ens svar, såsom at tilføje en spørgeskemaprompt eller redigere noget, AI'en har inkluderet, men som du ønsker fjernet. Kraftig brug af denne trigger kan indikere en logik, der kunne have ligget i hovedinstruktionerne. Brug den til finkornet kontrol, når det er nødvendigt.
On Plan Fuldført Efter hele planen er udført, og svaret er sendt Når en plan er færdig, altså alle trin er færdige, og brugeren ser svaret, aktiveres denne trigger. Brug det typisk til at starte eventuelle afslutningsprocesser. En almindelig anvendelse er at omdirigere samtalen til et specifikt slutemne eller til en undersøgelse. For eksempel kan du have et emne i slutningen af chatten, der takker brugeren eller giver de næste skridt. Ved at bruge On Plan Complete kan du automatisk kalde det emne.
Men vær forsigtig: du vil sandsynligvis ikke afslutte samtalen efter hvert eneste brugerspørgsmål, især hvis en bruger måske stiller opfølgende spørgsmål. Tilføj logik til slutningen kun, hvis en bestemt kontekstvariabel er sat, eller hvis planen løste en bestemt type anmodning. Brug i bund og grund On Plan Complete til oprydningsaktioner eller til en elegant afslutning, når det er passende.

Mere generative orkestreringsmuligheder

Uddyb din forståelse af Copilot Studios orkestreringsmodel med avancerede funktioner, der udvider måden, agenter planlægger, handler og samarbejder på:

  • Last updated on