Del via

Bruk generative orkestreringsmuligheter

Generativ orkestrering er utviklingen av utviklingen av samtalebaserte agenter i Copilot Studio. Den introduserer et stort planleggingslag drevet av språkmodeller (LLM) som tolker brukerens intensjon, bryter ned komplekse forespørsler, velger riktige verktøy og kunnskap, og gjennomfører flertrinnsplaner med retningslinjer for sikkerhet og etterlevelse. I stedet for å stole utelukkende på håndlagde samtaleemner, setter generativ orkestrering sammen gjenbrukbare byggeklosser – handlinger, temaer, kunnskapskilder, barneagenter og autonome triggere – til intelligente arbeidsflyter.

I Copilot Studio gir generativ orkestrering bedre svar med mindre manuell skripting. I denne artikkelen lærer du om arkitekturen bak generativ orkestrering, og hvordan du kan lage effektive instruksjoner og teste og finjustere dine orkestrerte agenter.

Hvorfor er generativ orkestrering viktig?

Tradisjonelle temadrevne design krever flere håndlagde emner, rigid forgreining og manuell logikk for utfylling av plasser. Denne tilnærmingen kan føre til:

  • Store temainventarer med overlappende logikk.
  • Vanskeligheter med å håndtere tvetydige eller flerintensjonsuttalelser.
  • Inkonsekvente opplevelser når brukere formulerer spørsmål forskjellig.
  • Høye vedlikeholdskostnader når API-er eller forretningsregler endres.

Generativ orkestrering løser disse utfordringene ved å:

  • Redusere temaspredning ved å skrive gjenbrukbare byggeklosser.
  • Automatisering av utfylling av spor basert på inndatadefinisjoner.
  • Å tilpasse responsstil og planstruktur dynamisk.
  • Forbedring av relevans gjennom semantisk kunnskapsgjenfinning.
  • Muliggjør proaktive forslag til neste trinn.

Arkitektur og komponenter

På et overordnet nivå består en generativ orkestratoragent av flere nøkkelkomponenter som jobber sammen:

  • Orchestrator (planlegger): Den LLM-drevne hjernen til agenten som gjør en input, som en brukermelding eller hendelse, om til en strukturert plan. Orkestratoren identifiserer intensjonene, velger hvilke verktøy, emner eller agenter som skal kalles for hvert steg, og definerer sekvensen og dataflyten mellom stegene. Den gir ut en ordnet liste med steg (en "plan") som kjøretiden utfører, og sikrer at hvert steg er innenfor policyen. For eksempel søker den godkjenning for sensitive handlinger.

  • Kunnskapslag: Et sett med hentekilder, som interne kunnskapsbaser, dokumenter, databaser og mer, som agenten kan spørre i for å forankre svarene sine. Orkestratoren bruker dette laget til å hente faktainformasjon eller veiledning. Resultatene inkluderer ofte sitater og metadata, som agenten kan inkludere i svarene for åpenhet. Kunnskapslaget er skrivebeskyttet og gir bevis eller kontekst.

  • Verktøy og koblinger: Eksterne handlinger, API-er eller automatiseringsflyter som agenten kan kalle som en del av en plan. Hvert verktøy har et definert grensesnitt: inndataparametere (med forventede typer), utgangsvariabler og eventuelt feilbetingelser. De er i bunn og grunn agentens «ferdigheter» for å utføre operasjoner, som å slå opp en bestilling, sende en e-post eller kjøre et manus. Du bør grundig teste verktøy og sikre at de oppfører seg deterministisk gitt de samme inputene, siden orkestratoren behandler dem som pålitelige funksjoner.

  • Temaer og inline-agenter: Gjenbrukbare samtaleemner eller mini-dialoger som oppsummerer spesifikk logikk. I generativ orkestrering kan planleggeren påkalle temaer ikke bare ved triggerfraser, men også når det beskrevne formålet samsvarer med brukerens behov. Inline-agenter refererer til små, fokuserte temaer eller rutiner som brukes som undertrinn i en større plan. De kjører innenfor hovedagentens kontekst og håndterer diskrete oppgaver slik at hovedorkestratoren ikke trenger å skripte disse detaljene eksplisitt.

  • Hendelsesutløsere (autonomi): Mekanismer som starter orkestratoren uten en brukermelding. Disse mekanismene kan være planlagte triggere eller hendelsesbaserte triggere, som en oppdatering av databaseposten, som får agenten til å starte en plan autonomt. Hver trigger kan ha sine egne betingelser og instruksjoner. Autonome triggere lar agenten handle proaktivt ved å starte arbeidsflyter når visse betingelser er oppfylt, i stedet for kun å reagere på brukerens chatinput.

Kontrolllag og beslutningsgrenser

I en produksjonsagent bør du ikke overlate alle avgjørelser til AI-en. Vanligvis finnes det tre lag med kontroll:

  • Deterministisk lag: Dette laget bruker tradisjonell, regelbasert logikk som du fortsatt håndhever for oppdragskritiske eller irreversible handlinger. For eksempel, når du behandler en betaling eller sletter en post, kan du bruke et strengt forfattet tema eller flyt som utføres steg for steg uten noen AI-tolkning. Dette laget kan også inkludere eksplisitte kontroller eller valideringer av sensitive data. Hvis noe må skje nøyaktig som spesifisert, håndter det deterministisk. Du kan konfigurere den generative orkestratoren til ikke å overstyre eller endre disse flytene. I praksis kan det hende du enten ikke eksponerer slike handlinger for AI-planleggeren, eller alltid pakker dem inn i et tema som krever brukerbekreftelse.

  • Hybrid (intercept) lag: Dette laget gir noe AI-fleksibilitet rundt hovedsakelig deterministiske strukturer. Du lar orkestratoren operere innenfor fastsatte grenser med mulighet for menneskelig eller regelbasert avlytting. For eksempel kan en agent automatisk utarbeide et svar eller utføre en handling, men du kan sette inn et godkjenningssteg for å få en leder til å gjennomgå det. Eller agenten kan håndtere en oppgave opp til en viss verdigrense, og deretter bli pålagt å eskalere. Det hybride laget forhåndsdefinerer punkter hvor AI-ens autonome plan blir sjekket. Bruk denne tilnærmingen for prosesser med middels risiko: la AI-en gjøre det tunge arbeidet, men hold et menneske informert for tilsynet.

  • AI-orkestratorlaget: Dette laget er fullt generativt. LLM-planleggeren har frihet (innenfor rekkverket) til å utarbeide og gjennomføre planer for lavrisikospørsmål. De fleste spørsmål-og-svar-interaksjoner, informasjonsoppslag eller enkle flerstegsforespørsler faller inn under denne kategorien. For de fleste brukerspørsmål kan agenten autonomt bestemme hvordan de skal løses og iverksette tiltak. Dette laget gir tilpasningsevnen og kraften til generativ AI. Den er bundet av retningslinjer. For eksempel kan AI-en vite at den ikke har lov til å kalle visse admin-verktøy eller avsløre viss informasjon. Agenten trenger ikke stoppe opp og be om tillatelse til rutineoppgaver.

Gitt disse lagene, definer eksplisitt beslutningsgrenser. Se på hvilke handlinger og temaer:

  • Kan utføres uten bekreftelse (AI-en kan bare gjøre dem)
  • Krev brukerens bekreftelse i samtalen (for eksempel: «Er du sikker på at du vil slette alle poster?»)
  • Krev offline-godkjenning (for eksempel må en administrator bekrefte via en godkjenningsflyt)

Håndhev disse grensene gjennom temadesignet ditt, for eksempel ved å legge til en bekreftelsesnode, gjennom plattformens godkjenningsfunksjoner, eller via logikk i triggerne. Ved å legge lag på kontroll sikrer du at agenten opererer trygt—AI-en håndterer det den er god på, mens mennesker eller strenge regler håndterer det AI-en ikke bør bestemme alene.

Beste praksis for agentinstruksjoner

Riktig utformede agentinstruksjoner påvirker kvaliteten på planutarbeidelsen.

  • Kontekstuell relevans

    • Sørg for at instruksjonene kun refererer til verktøy og kunnskap tilgjengelig for megleren.
    • Bruk nøyaktige verktøynavn, variabelnavn og Power Fx-identifikatorer.

  • Samtaleretningslinjer

    • Spesifiser svarformat (lister, tabeller, fet skrift).
    • Gi stilistisk veiledning («kortfattet», «inkluder referanser», «foreslå neste steg»).
    • Unngå å navngi spesifikke kunnskapskilder direkte. Beskriv dem i stedet.

  • Å bestemme når man skal bruke verktøy eller kunnskap

    • Foretrekker å bruke verktøynavn. Navn veier tyngre enn beskrivelser.
    • Beskriv kunnskapskapasiteter generelt for å unngå feil informasjon.

  • Autonome utførelsesinstruksjoner

    • Definer forventet rekkefølge av handlinger for flertrinnsarbeidsflyter.
    • Kombiner prosessinstruksjoner med spesifikke prompter.

Lær mer i Konfigurer høykvalitetsinstruksjoner for generativ orkestrering.

Utforming av temainn- og utdata

Når du skriver temaer, bør du være ekstra oppmerksom på deres input- og outputparametere i generativ orkestreringsmodus:

  • Definer klare inputparametere med beskrivelser: Hvis et tema eller en handling krever viss informasjon (som «Brukernavn» for et passordtilbakestillingstema), opprett et emneinndata for det og gi det et beskrivende navn og eksempel. Orkestratoren bruker disse navnene og beskrivelsene for automatisk å spørre brukeren om verdien mangler. Bruk av en liste over aksepterte verdier eller en Power Fx-valideringsformel for input kan bidra til å sikre at boten samler inn gyldige data (for eksempel å begrense en landskode til to bokstaver).

  • Bruk automatisk prompting: I generativ modus genererer agenten spørsmål selv i stedet for at du manuelt må legge til spørsmålsnoder for å be om manglende informasjon. Denne tilnærmingen er en stor endring fra klassiske bots. Nøkkelen er at inndatanavnene dine skal være menneskevennlige (for eksempel «startdato», «e-postadresse») slik at AI-en kan stille et naturlig spørsmål. Hvis AI-ens automatisk genererte spørsmål ikke er formulert ideelt, bør du vurdere å forbedre beskrivelsen eller navnet på inputen. Denne funksjonen effektiviserer dialogene betydelig, men den er avhengig av veldefinerte input.

  • Spesifiser utdata for temaer der det er hensiktsmessig: Et emne kan produsere utdatavariabler som orkestratoren bruker for å kompilere det endelige svaret. For eksempel kan et «Store Finder»-tema gi .NearestStoreLocation Ved å sende ut informasjon i stedet for å sende en melding direkte til brukeren, lar du orkestratoren kombinere denne informasjonen med andre steg på en elegant måte. Hvis innholdet i et tema brukes i et større svar, fang det som en utdatavariabel og la orkestratoren håndtere den endelige meldingen. Finn ut mer i orchestrate agentvirkemåte med generativ AI.

  • Unngå «dobbel håndtering» av data i prompts: Hvis du konfigurerer outputs, ikke også mater disse outputene inn i LLM-en som åpen kontekst. For eksempel, hvis en handling returnerer en oppsummeringstekst, send denne oppsummeringen som en strukturert utdata og la orkestratoren inkludere den, i stedet for å skrive en instruksjon som «Resultatet av handlingen sier {summary}.» Denne tilnærmingen forhindrer at modellen overgenererer eller gjentar innhold. Utdata bør være endelige datapunkter når det er mulig.

Sammenkobling av handlinger, temaer og kunnskap

Fordi orkestratoren kan bruke flere funksjoner i én tur, design med komponerbarhet i tankene:

  • Gi alt intuitive navn og beskrivelser: Planleggeren bestemmer stort sett for å bruke et verktøy eller tema basert på hvor godt navnet og beskrivelsen samsvarer med brukerens forespørsel. Bruk aktive fraser som samsvarer med brukerens intensjoner. For eksempel er et verktøy kalt "TranslateText" med beskrivelsen "Oversetter tekst til et spesifisert språk" mer sannsynlig å bli valgt når brukeren spør om å oversette, sammenlignet med et generisk kalt "Flow1." Navn betyr mer enn noe annet. Unngå kryptiske navn. Hvis agenten velger feil tema, gå gjennom navnene og beskrivelsene på nytt.

  • Tilby et rikt «verktøysett», men velg det: Koble sammen alle nyttige handlinger scenarioet ditt kan trenge (API-er, flyter osv.), og lag temaer for viktige flyter. Denne tilnærmingen gir AI-en flere muligheter for å løse spørringer. Men fjern eller deaktiver verktøy og temaer som du vet er irrelevante eller risikable for agenten, slik at de ikke forvirrer planleggeren. Et mindre sett med høykvalitetsvalg er bedre enn et uttømmende sett med overlapp. Overlappende beskrivelser kan føre til at agenten prøver flere ting samtidig, noe som kanskje ikke er ønskelig.

  • Stol på planleggeren, innen rimelighetens grenser: Når komponentene er godt definert, la orkestratoren mikse og matche. For eksempel, hvis brukeren spør om noe som kan adresseres med en kunnskapsartikkel eller et live data-API, kan planleggeren velge å bruke begge deler – hente kunnskapen for bakgrunn og kalle API-et for aktuell informasjon. Denne tilnærmingen kan gi et bedre svar. Omfavn denne autonomien, men følg med tidlig for å sikre at gode valg blir tatt.

  • Håndter flere intensjoner: Hvis en brukerforespørsel iboende ber om to separate ting (som «åpne en ny konto og send meg detaljene»), forsøker den generative planleggeren å oppfylle begge ved å kalle de relevante sekvensene etter tur. Du trenger ikke manuelt å skripte forgreningen for multi-intent. Jobben din som utvikler er å sørge for at hver deloppgave (kontoåpning, sendingsdetaljer) dekkes av et verktøy eller tema, og at output og input henger sammen om nødvendig.

  • La kunnskap utfylle temaer og verktøy: Orkestratoren kan proaktivt kalle kunnskapssøk, ikke bare som en fallback. Hvis du har en rik kunnskapsbase på plass, kan agenten svare på deler av en forespørsel med et kunnskapsartikkelutdrag selv om en handling dekker en annen del. Denne virkemåten er i henhold til utformingen. Hold kunnskapsbasen din oppdatert med informasjon som ikke er lett tilgjengelig via verktøy.

  • Vær oppmerksom på omfanget av kunnskapsbruk: For øyeblikket kan du ikke tvinge agenten til å bruke en spesifikk kunnskapsartikkel på forespørsel. AI-en velger relevante artikler basert på søket. Legg også merke til begrensninger. For eksempel brukes ikke systemtemaer som «Flere temaer matchet» i generativ modus, siden planleggeren håndterer flertydighet annerledes. Lær mer om andre kjente begrensninger for generativ orkestrering.

Testing og justering av det orkestrerte middelet

Generativ orkestrering flytter noe logikk fra eksplisitt design til AI-ens «hjerne». Iterativ testing sikrer at den oppfører seg som tiltenkt. Her er beste praksis for å teste og forbedre din orkestrerte agent:

  • Bruk aktivitetskartet: Copilot Studio gir et aktivitetskart under testing, som viser stegene orkestratoren har valgt. Etter å ha stilt agenten din et komplekst spørsmål, undersøk planen: Hvilke temaer eller handlinger ble aktivert? I hvilken rekkefølge? Stilte den et passende oppfølgingsspørsmål? Hvis agenten valgte feil tema eller overså et verktøy, kan det hende du må forbedre komponentbeskrivelser eller justere instruksjonene.

  • Gå gjennom transkripsjoner: Når agenten er publisert, gå jevnlig gjennom samtaletranskripsjoner eller logger. Se etter hallusinasjoner eller unøyaktigheter i svarene. Hvis brukere gir tilbakemelding som «det er ikke riktig», følg tilbake for å se hvorfor agenten trodde det var det. Ta tak i problemer ved å legge til manglende fakta i kunnskapsbasen, stramme inn instruksjoner, eller i noen tilfeller legge til et nytt tema for å dekke et hull. Lær mer i Extract and analyze agent-samtaletranskripsjoner (referansearkitektur).

  • Iterer med små endringer: Du kan ofte forbedre en generativ agent ved å gjøre subtile endringer. For eksempel, hvis agentens utdata er for omfattende eller ikke i ønsket format, juster instruksjonene om stil og format og test igjen. Hvis den kaller et unødvendig verktøy hver gang, kan det hende at beskrivelsen av verktøyet er for bred og du kan forbedre den slik at den bare aktiveres når det er hensiktsmessig. Gjør én endring om gangen og legg merke til effekten på agentens beslutninger.

  • Gi eksempler på ytringer (forsiktig): Du kan oppdage at det å legge til et par eksempel-brukerspørringer i beskrivelsen av et emne kan hjelpe LLM-en å forstå når det skal brukes. For eksempel: «Formål: Tilbakestill en brukers passord. For eksempel kan brukeren si 'Jeg glemte passordet mitt' eller 'tilbakestilt Contoso-kontotilgangen min.'» Disse eksemplene gir modellen ekstra hint. Ikke overdriv, og hold beskrivelsene konsise og fokuserte. Modellen har allerede mye kontekst—bare sørg for at metadataene dine er tydelige.

  • Overvåk ytelsesmålinger: Etter hvert som bruken øker, følg med på nøkkelmålinger som suksessrate (løste agenten faktisk brukerens forespørsel?), fallback-rate (hvor ofte det sto «Beklager, jeg kan ikke hjelpe med det») og brukertilfredshet hvis tilgjengelig. Selv under testing kan enkle tellinger av hvor ofte hvert tema og verktøy brukes gi hint om nødvendige justeringer. For eksempel, hvis et trivielt småprattema blir brukt for ofte og legger til støy, deaktiver det eller snevrer inn beskrivelsen. Gå gjennom veiledningen om hvordan du kan teste ytelsen til agentene dine.

Generative systemer lærer implisitt av dine konfigurasjoner og løsninger. Hver forbedring av instruksjoner eller metadata gjør AI-ens neste beslutning bedre. Over tid blir din orkestrerte agent mer nøyaktig og effektiv til å håndtere forespørsler.

Egendefinerte triggere i generativ orkestrering

Topic-triggere er tilgjengelige spesielt for generativ orkestrering. Ved å bruke disse triggerne kan du koble deg til agentens livssyklus og injisere tilpasset logikk på kritiske punkter i orkestreringsprosessen. Tre hovedtriggere er tilgjengelige:

Utløse Når det utløses Formål
På kunnskap etterspurt Rett før agenten utfører en kunnskapsbase-forespørsel Denne triggeren lar deg avskjære øyeblikket orkestratoren er i ferd med å søke i kunnskapskildene. Den gir skrivebeskyttet tilgang til nøkkelordene SearchPhrase agenten har til hensikt å bruke, samt en systemvariabel for å levere tilpassede søkeresultater. For eksempel kan du fange opp spørringen og rute den til en proprietær indeks eller injisere mer data i resultatene.
Dette er en avansert ("hemmelig") trigger—den er ikke synlig i brukergrensesnittet som standard og må for øyeblikket aktiveres via en YAML-redigering (ved å navngi et emne nøyaktig OnKnowledgeRequested). Bruk det hvis du trenger å utvide eller tilpasse kunnskapsgjenhentingssteget, som å filtrere visse resultater eller slå sammen eksterne data i kunnskapsresponsen.
AI-respons generert Etter at AI-en har komponert et utkast til svar, men før det sendes til brukeren Agenten utløser denne triggeren når den har laget den endelige svarteksten (basert på alle verktøy- og temautdata) og rett før den leveres. Dette steget gir deg en mulighet til å programmatisk endre svaret eller dets sitater. For eksempel kan du etterbehandle teksten for å fikse eventuell formatering, eller erstatte rå URL-er med vennlige sporingslenker. Du kan til og med velge å overstyre responsen. Triggeren kan gi en egen egendefinert melding, og du kan bruke et ContinueResponse flagg for å indikere om det opprinnelige AI-svaret fortsatt skal sendes eller ikke.
Bruk denne triggeren til siste-liten-justeringer eller forbedringer av AI-ens svar, som å legge til en undersøkelsesprompt eller redigere noe AI-en inkluderte, men du ønsker fjernet. Tung bruk av denne triggeren kan indikere en logikk som kan ha ligget i hovedinstruksjonene. Bruk den for finkornet kontroll når det trengs.
På planen fullført Etter at hele planen er gjennomført og svaret er sendt Når en plan er ferdig, altså alle steg fullført og brukeren ser svaret, utløses denne utløseren. Vanligvis bruker du det til å starte eventuelle avsluttende samtaleprosesser. En vanlig bruk er å omdirigere samtalen til et spesifikt slutttema eller til en undersøkelse. For eksempel kan du ha et slutt-av-chatten-tema som takker brukeren eller gir neste steg. Ved å bruke On Plan Complete kan du automatisk kalle det temaet.
Men vær forsiktig: du vil sannsynligvis ikke avslutte samtalen etter hvert eneste brukerspørsmål, spesielt hvis en bruker kan spørre oppfølginger. Legg til logikk til slutt kun hvis en bestemt kontekstvariabel er satt, eller hvis planen løste en bestemt type forespørsel. Bruk i praksis On Plan Complete for oppryddingstiltak eller for en elegant avslutning når det er passende.

Flere generative orkestreringsmuligheter

Utdyp forståelsen av Copilot Studios orkestreringsmodell med avanserte funksjoner som utvider hvordan agenter planlegger, handler og samarbeider:

  • Last updated on