Design bedste praksis for at undgå dublerede beskeder

I standardharnesset kan flere komponenter håndtere en brugers anmodning, og hver enkelt handler ud fra sit eget synspunkt. Et emne kan vise en besked eller et adaptivt kort, et værktøj kan returnere data, og en child eller tilknyttet agent kan svare fra sin egen kontekst. Orkestreringslaget fortsætter planen fra en kontekst, der måske ikke matcher det svar, brugeren modtager. Når disse synspunkter glider fra hinanden, kan brugeren se en gentagen besked eller et ubesvaret svar. Producenter oplever denne adfærd oftere med nyere modeller end med ældre.

Forstå, hvorfor duplikater opstår, før du designer en løsning. Lær mere om kontekstfordeling i standardharnesset.

For at forstå disse anvendelsestilfælde bør man betragte to overflader separat: det bruger-synlige output (hvad brugeren ser i chatten) og den aktive kontekst (den information, en komponent har tilgængelig, når den beslutter, hvad den skal gøre næste gang). Skaberne ser ikke den aktive kontekst direkte. Derfor er det vigtigt at forstå hver komponents perspektiv og bruge input og output for at holde disse perspektiver på linje.

For at fejlfinde et symptom i en live agent skal du starte med fejlfinding af dublettede beskeder og missede svar , og derefter vende tilbage til denne artikel for vejledning om redesign.

Design med kontekst for øje

Hvis en anmodning håndteres af et enkelt trin efterfulgt af et 'Slut alle emner', kommer kontekststyring ikke i spil. Men når en forespørgsel skal kæde flere komponenter sammen, eller når brugeren laver mere end én forespørgsel i samme session, er kontekststyring vigtig. De fleste virkelige anvendelsestilfælde dækker flere komponenter pr. session, så design derefter.

• Én komponent, så afslut alle emner. Et enkelt emne, værktøj, child agent eller connected agent håndterer forespørgslen, og sessionen slutter. Hvis den komponent skriver det komplette svar og rapporterer den fuldførelse, har orkestreringslaget ingen grund til at skrive et nyt svar.
• Flere komponenter i sessionen. En session kan køre flere komponenter, før den giver brugeren et komplet svar. En session kan også spænde over flere forespørgsler. En komponent kan besvare en del af anmodningen, mens en anden skal besvare resten. Hver komponent, der virker, skal rapportere, hvad den har gjort. Ellers kan en senere komponent handle på kontekst, der virker ubesvaret, og reagere igen.

Designkomponenter til at rapportere, hvad der skete

En komponent sender en gentagen besked eller duplikerede beskeder, når orkestreringslaget ikke kan opdage arbejde, som en tidligere komponent har udført. Brug den samme designtilgang hver gang for at undgå dubletter – instruer hver komponent i at rapportere sine handlinger til orkestreringslaget. For hver del af forespørgslen tildeles præcis én komponent til at skrive det svar, brugeren modtager. Alle andre komponenter udfører sit arbejde og returnerer kontekst uden at skrive til brugeren.

Brug disse praksisser sammen som en samlet designtilgang:

1. Return-output, der registrerer, hvad der skete. Udgange alene er som regel nok til ældre modeller.
2. Tilføj en instruktion til emne- eller underagentbeskrivelsen , der definerer, hvad et vellykket run betyder. Denne tilgang gør designet robust.
3. Tilføj en topniveau-instruktion , så orkestreringslaget tjekker disse output, før det svarer. Nyere modeller drager mest fordel af denne tilgang.

Kun komponenter, der understøtter brugerdefinerede output, kan returnere output og inkludere beskrivelsesinstruktioner. For komponenter, der ikke understøtter brugerdefinerede output, undgå duplikerede beskeder ved at begrænse den kontekst, de modtager, og ved at tilføje en topniveau-instruktion.

Design en robust topniveau-instruktion for at undgå gentagne beskeder

Output holder orkestreringslaget opdateret. Tilføj en topniveau-instruktion, der fortæller nyere modeller at tjekke outputt, før de svarer.

Følgende topniveau-agentinstruktion er et eksempel designet til at fungere på tværs af brugstilfælde, uanset om en komponent kommunikerer direkte med brugeren eller ej. Rediger og tilpas det efter behov.

Når et emne eller en agent bliver kaldt, skal du altid lede efter det 'besvarede' booleske output, før du beslutter, hvad du vil svare. Emner og agenter har deres egen kommunikationskanal med brugeren. Hvis 'besvaret' er sandt, antag altid, at anmodningen er blevet besvaret korrekt ved brug af mindst én af outputvariablerne, og tjek hvilke baseret på outputbeskrivelsen. Giv ikke en akavet anerkendelse af det besvarede indhold. Giv kun de ubesvarede resultater, og fortsæt samtalen naturligt med næste skridt.

Begrebet kanal refererer ikke til en integrationskanal som Teams eller en hjemmeside. Det er en prompting-enhed, der fortæller orkestreringslaget, at brugeren måske allerede har set svaret eller foretaget et valg gennem en anden komponent, såsom et emne, kort eller en subagent. Denne formulering får modellen mest effektivt til at tjekke sit svar, før den svarer.

Håndter emner

Et emne kommunikerer ofte direkte med brugeren ved at vise en besked, stille et spørgsmål eller præsentere et Adaptivt Kort. Orkestreringskonteksten modtager emnets tekst som almindelig tekst, men registrerer ikke, om brugeren har set den. Konteksten modtager heller ikke handlinger eller valg af adaptive kort. Hvis emnet svarer brugeren, men ikke rapporterer den handling til orkestreringslaget, behandler orkestreringslaget anmodningen som uafklaret og svarer igen.

Udform et emne som en mini-agent. Returnér et output med status som besvaret, så orkestreringslaget ved, at anmodningen blev håndteret, og returnér alle værdier, emnet viser, eller det valg, det har indsamlet, som et senere trin skal bruge. Outputtene gør handlingerne og resultaterne tilgængelige for resten af planen. Tilføj en instruktion til emnebeskrivelsen, der definerer, hvad en vellykket gennemkørsel betyder.

Lær mere i Design-emner som mini-agenter, der undgår duplikerede beskeder.

Håndter børne- og tilknyttede agenter

Design under- og tilknyttede agenter, som du designer enhver anden komponent. Deres frem og tilbage med brugeren er usynlig for forælderen, som kun finder ud af, hvad der skete, gennem output, og først efter agenten er færdig.

Børne- og tilknyttede agenter kan også modtage hidtil ubesvarede anmodninger, som forbliver i forældreagentens kontekst.

For hver agent skal dens opgave afgrænses med et input, angives om den svarer brugeren eller forbliver tavs, og returnerer output, der fortæller forældreagenten, hvad der er sket.

Lær mere i Design subagents, der undgår dublerede beskeder.

Håndter viden

Viden er en topniveaukonstruktion, som agenten bruger på. Den modtager en anmodning baseret på agentens design, og den modtager agentens kontekst. De fleste gentagne beskedproblemer opstår, når agentens kontekst mangler information fra andre komponenter. Design viden til at påvirke, hvordan agenten formulerer anmodningen. Sørg for, at andre komponenter bruger deres output korrekt.

Håndter genererede svarnoder

En generativ svarnode, der lever inden for et emne og svarer ud fra viden. Den modtager forældrekonteksten plus det, der sendes i dens input, så den opfører sig som topniveau viden og supplerer sit svar fra den aktuelle kontekst. Den kan skrive sit svar direkte til chatpanelet eller gemme det i en emnevariabel, men den kan ikke returnere noget til topniveau-konteksten alene. Som med alt emneindhold forbliver svaret i emnet, medmindre emnet returnerer et output.

En generativ svarnode behøver ingen særlig håndtering ud over reglen, der gælder for hvert emne: giv resultatet som et emneoutput. Hvis noden besvarer brugeren i emnet, skal du tilføje et output for besvaret tilstand og et output for den viste værdi. Disse output giver orkestreringslaget en registrering af, at anmodningen blev besvaret, og forhindrer et senere trin i at besvare anmodningen igen.

Sørg for, at beskrivelser og instruktioner matcher synsvinkelen

Beskrivelser og instruktioner er også en del af kontekstkontrakten.

Denne instruktion leder til emnet:

When the user asks about their account balance, call the Account balance topic.

Denne instruktion ruter og tildeler svar-ejerskab til orkestreringslaget:

When the user asks about their account balance, call the Account balance topic and give the balance.

Hvis emnet allerede viser balancen, skaber den anden instruktion en anden svarsti. Hvis emnet ikke returneres balanceValue, kan orkestreringslaget kalde emnet igen eller svare, at det ikke kender værdien.

Brug beskrivelser og instruktioner, der matcher synsvinklen:

• En emnebeskrivelse hjælper orkestreringslaget med at beslutte, hvornår og hvordan emnet skal bruges. Den følger også instruktioner om, hvad der skal gøres eller outputtes næste gang.
• En beskrivelse af en forbundet agent kommer fra forældrenes synspunkt.
• En forbindelsesagent-instruktion læses fra den forbundnes synspunkt.
• En emne- eller connected-agent-outputbeskrivelse fortæller orkestreringslaget, hvordan den returnerede værdi skal fortolkes.

For et emne, der viser et svar til brugeren og sætter answered=true, beskriv både hvornår man skal routes til emnet, og hvad en vellykket kørsel betyder:

This topic handles account balance requests.
If its answered output is true, the user has already received their response and it should not be answered again.

For et emne, der kun skriver output, beskriv både hvornår du skal rute til emnet, og hvordan du skal svare:

This topic handles account balance requests and responds with the balance value in italics.

Genskab kontekst i lange samtaler

En værdi, som en komponent havde, kan forlade den aktive kontekst på to måder. I en lang session kan en værdi, der var tilgængelig for et par ture siden, måske ikke længere være i den aktive kontekst. Eller en komponent henter et komplet resultat, bruger den relevante del til at producere et svar og returnerer kun det svar, så resten af resultatet aldrig når orkestreringslaget. Uanset hvad kan agenten hente dataene igen eller bede brugeren om information, den allerede har, hvilket brugeren opfatter som et forkert svar. Orkestreringslaget opfører sig, som om det aldrig har modtaget værdien.

Design til dette scenarie ved at returnere og gemme vigtig kontekst og levere den tilbage, når det er nødvendigt:

• Returner et komplet resultat, ikke kun den del, der blev brugt til at besvare. Et hentet resultat har ofte mere end ét felt, mange rækker og lang tekst. Returnér alle de data, som en senere omgang kan få brug for, som output, så orkestreringslaget har dem uden at skulle hente dem igen.

• Gem og tjen værdier på tværs af ture. På de rigtige tidspunkter, før eller efter et værktøjskald, dirutér til et emne, der kan gemme eller levere værdien gennem dets input og output samt en global variabel, så planen ikke henter værdien eller beder om den igen.

Relaterede oplysninger

• Kontekstfordeling i standardharnessen
• Design emner som mini-agenter, der undgår dublerede beskeder
• Design subagenter, der undgår dublerede beskeder
• Fejlsøg dublerede beskeder og ubesvarede svar
• Anvend generative orkestreringsmuligheder
• Brug generative svar i et emne
• Orkestrere agentfunktionsmåde med generativ AI
• Styr emneinddata og emneuddata
• Konfigurér højkvalitetsinstruktioner til generativ orkestrering
• Mønstre for orkestrering med flere agenter og bedste praksis