Agentforce-guiden till att uppnå tillförlitligt agentbeteende

Olfa Kharrat, chef för produkthantering – Agentforce
Reinier van Leuken, senior chef för produkthantering – Agentforce

Förtroende har varit ett kärnvärde sedan Salesforce grundades 1999 och företaget har varit banbrytande med en ny teknikmodell inom cloud computing och SaaS. Företagen ger Salesforce sitt förtroende när de lagrar värdefulla företagsdata i molnet och känner sig trygga med att dessa data är skyddade och styrs av lämpliga åtkomstkontroller. Detta är fortfarande viktigt, men i en tid av agentisk AI blir definitionen av förtroende ännu bredare. I takt med att företag förlitar sig allt mer på autonoma agenter för att utföra kritiska affärsfunktioner måste agenter bli betrodda affärspartners vars arbete är korrekt, relevant och framför allt tillförlitligt.

Så hur bygger du en tillförlitlig agent? Tillförlitlighet innebär vanligtvis att samma indata ger samma resultat. Agenter fungerar dock inte nödvändigtvis så eftersom de drivs av stora språkmodeller (LLM:er) som till sin natur är icke-deterministiska. Det innebär att agenter kan utveckla kreativa lösningar som är skräddarsydda utifrån specifika omständigheter utan att varje tillstånd eller situation som uppstår behöver programmeras uttryckligen. Agenter behöver dock också styrning för att följa affärskrav och verksamhetsriktlinjer. När de utför affärsprocesser måste de visa att de är tillförlitliga och producera affärsresultat som överensstämmer med deterministiska begränsningar. Determinism innebär en stelhet och disciplin som står i konflikt med den autonomi och flexibilitet som agenter tillhandahåller. Nyckeln till att skapa bra agenter är därför att hitta rätt balans mellan kreativ flexibilitet och företagskontroll.

Detta dokument går igenom viktiga överväganden för utveckling av tillförlitliga agenter. Det definierar fem nivåer av agentisk kontroll och tillhandahåller bästa praxis för att få och behålla kontroll över agentiskt beteende för var och en av dessa nivåer. Vägledningen går igenom hur Agentforce-resonemangsmotorn fungerar. I takt med att Agentforce växer uppdateras detta dokument med senaste bästa praxis.

Detta dokument förutsätter grundläggande kännedom om att designa och skapa Agentforce-agenter. Som en introduktion till Agentforce rekommenderar vi följande:

• Gå igenom resurserna på agentforce.com.
• Följ spåret Bli en Agentblazer Champion . Detta spår utforskar centrala AI-koncept och hjälper dig att skapa en grundläggande agent för viktiga uppgifter.
• Läs mer om Agentforce på help.salesforce.com , särskilt Designa och implementera agenter . Denna inlärningskarta vägleder dig genom alla viktiga steg i livscykeln, från att idéutveckla lösningen till att konfigurera agenten och testa, distribuera och övervaka.

För att förstå agentiskt beteende bättre ska vi först jämföra agenter med deras stela motsvarigheter: chattbottar.

Chattbottar: stela regelföljare

Chattbottar följer förutbestämda beslutsträd som strukturerar de dialoger de kan delta i. Navigeringen genom dessa beslutsträd baseras på de svar som användaren ger. Svaret kan vara ett val från en förutbestämd uppsättning alternativ eller ett fritextsvar. Vid fritextsvar används en prediktiv modell för klassificering av syfte. Dessa träd kartlägger alla potentiella konversationsvägar och dikterar chattbottens svar i varje steg. Chattbottens beteende avgörs stelt av fördefinierade regler. Om en användares indata inte matchar en identifierad väg eller om den prediktiva modellen inte har tränats för att identifiera ett visst syfte svarar chattbotten inte på lämpligt sätt.

Agenter: adaptiva och intuitiva

Däremot utnyttjar agenter kraften hos LLM:er och deras avancerade funktioner inom naturlig språkbehandling (NLP). LLM:er gör det möjligt för agenter att förstå syftet bakom en användares indata, även om de formuleras på ett oväntat sätt. Baserat på förståelsen för syftet kan agenten välja den lämpligaste åtgärden bland en rad alternativ. En agent kan till och med formulera helt nya svar. Denna flexibilitet och anpassningsförmåga skiljer agenter från deras motsvarigheter chattbottarna.

En liknelse inom matlagning

Skillnaden mellan chattbottar och agenter kan liknas vid skillnaden mellan en nybörjare i köket och en erfaren kock.

• Nybörjaren (chattbotten) är beroende av ett detaljerat recept med exakta mått, steg-för-steg-instruktioner och specifika tillagningstider. Avvikelser från receptet leder till en matkatastrof. På samma sätt måste en chattbot fungera inom ramen för sitt förprogrammerade beslutsträd.
• Den erfarna kocken (agenten) har många års erfarenhet av matlagning och intuition. Med hjälp av en allmän förståelse för dina preferenser och en kort beskrivning av tillgängliga ingredienser kan de laga en läcker måltid som passar dina behov. De exakta stegen kan variera mellan gångerna och versionerna av maträtten kan ha små skillnader, men det övergripande resultatet är alltid tillfredsställande. På samma sätt kan en agent anpassa sin strategi baserat på kontexten för och syftet med användarens indata så att en interaktion blir lyckad.

Sammanfattningsvis ligger den grundläggande skillnaden mellan agenter och chattbottar i deras anpassningsförmåga och kapacitet att hantera oväntade indata.

Ett distinkt inslag i en agents intelligens är dess förmåga att orkestrera och utlösa de lämpligaste åtgärderna vid rätt tidpunkt. Tack vare denna flexibilitet behöver inte varje potentiell användarinteraktion programmeras i stor omfattning.

I Agentforce ingår ämnen, åtgärder och instruktioner och beskrivningar på naturligt språk i att skapa en agent.

Ämnen

Ämnen är de jobb som agenten ska utföra. Ämnen har attribut, till exempel en klassificeringsbeskrivning, omfattning och instruktioner, som definierar varje jobb och hur det görs. Ämnen innehåller åtgärder som agenten kan utföra samt instruktioner som styr hur dessa åtgärder utförs.

Åtgärder

Åtgärder är de fördefinierade uppgifter som agenten kan utföra för att göra sitt jobb. Det finns fem olika typer av åtgärder:

• kör Apex-kod
• anropa ett API
• utför ett flöde
• få ett LLM-svar på en promptmall
• anropa en prediktiv modell.

Instruktioner och beskrivningar på naturligt språk

En agents definition innehåller instruktioner på naturligt språk som beskriver agentens tillgångar och definierar de riktlinjer som den måste följa. Instruktioner skrivs för åtgärder och ämnen.

• Åtgärder. En åtgärd innehåller
  • instruktioner som beskriver vad åtgärden gör och meddelar resonemangsmotorn när åtgärden ska utföras
  • indata med en beskrivning på naturligt språk så att agenten kan förbereda dem
  • utdata med en beskrivning på naturligt språk av hur de ska formateras och användas.
• Ämne. Ett ämne innehåller instruktioner som styr hur dess åtgärder ska utföras på en högre nivå. Instruktioner kan till exempel ange skyddsräcken om tonfall, önskad åtgärdssekvens, möjliga förutsättningar eller när konversationer ska eskaleras till människor. Ämnet innehåller också en klassificeringsbeskrivning och en omfattningsavgränsning. Sammantaget säkerställer detta att agenten håller sig inom omfattningen för sin definierade roll och utför jobbet.
• Data. Agenter behöver data för att lyckas i sina jobb. Data kan vara strukturerade, till exempel CRM-data, eller ostrukturerade, till exempel företagskunskapsartiklar. Agenter får tillgång till data med hjälp av åtgärdsindata. En åtgärd kan till exempel anropa en promptmall som är grundad i CRM-data eller förstärkt med ostrukturerade deldata med hjälp av RAG-tekniker.

När dessa olika byggstenar har skapats korrekt hjälper de en agent att uppfylla sitt avsedda syfte samtidigt som den håller sig inom lämpliga gränser.

Agentforce-resonemangsmotorn orkestrerar dessa byggstenar i korrekt agentiskt beteende. Den utnyttjar de instruktioner och beskrivningar på naturligt språk som definieras i ämnen och åtgärder. Den bygger på ReAct, ett nytt resonemangsparadigm för LLM:er som introducerades 2022 av Yao et al. Detta paradigm imiterar mänsklig uppgiftshantering genom att resonera om ett problem, vidta åtgärder, observera åtgärdens resultat och upprepa cykeln tills uppgiften har slutförts.

Salesforce-agenter följer detta paradigm:

1. Resonera: Förstå användarnas syfte och se till att det överensstämmer med rätt ämne och åtgärder.
2. Agera: Inled rätt åtgärdskedja.
3. Observera: Utvärdera åtgärdens resultat i förhållande till användarens syfte. Om syftet inte har uppfyllts ska de resonera vidare baserat på det uppnådda resultatet hittills och på instruktionerna och beskrivningarna för ämnet/åtgärden. Om syftet har uppfyllts ska de ge det slutliga svaret och följa eventuella formateringsinstruktioner.
4. Upprepa: Upprepa dessa steg tills det sista instruerade steget har nåtts.

Resonemangsmotorn använder LLM:er i varje Resonera- och Observera-steg. Beroende på åtgärdstyp kan den också använda LLM:er i Agera-steget.

Denna sektion beskriver en skiktad strategi för att förbättra agenters determinism. Varje nivå bygger på den föregående, med ökad komplexitet och kapacitet som ger mer kontroll över agentens beteende.

Den första nivån fokuserar på att göra det möjligt för agenter att autonomt identifiera relevanta ämnen och sedan välja lämpliga åtgärder med hjälp av mål snarare än uttryckliga instruktioner. I den centrala mekanismen ingår att använda en kontextuell förståelse för att svara på användarindata. Även om alla typer av åtgärder tekniskt sett kan läggas till förutsätter vi på denna nivå att åtgärderna är promptåtgärder. Instruktionsfria ämnen med promptåtgärder ger ett snabbt och effektivt sätt att hantera vanliga frågor.

På denna nivå ligger fokus på att upprätta en baslinjenivå för agenters respons och autonomi genom dynamisk förståelse.

Denna nivå bygger vidare på grunden med val av instruktionsfria åtgärder. Här introduceras uttryckliga instruktioner som vägleder agenternas beteende. Exakta instruktioner ger en ökad kontroll över hur agenter reagerar på olika situationer. Instruktioner till agenter kan uttryckas som regler, riktlinjer, skyddsräcken och exempel. De ger agenten specifik vägledning om hur de ska hantera olika ämnen, utföra åtgärder och bearbeta deras utdata. Målet för denna nivå är att ge agenten tydlig vägledning för att öka enhetligheten och förbättra efterlevnaden av företagets riktlinjer och processer.

Grundning innebär att koppla agentens förståelse och svar till externa kunskapskällor. Grundning säkerställer att informationen som agenten tillhandahåller är mer korrekt, aktuell och relevant. På denna nivå integreras åtkomst till databaser, kunskapsbaser och andra informationsarkiv. När agentens svar grundas i verifierade data blir de mer tillförlitliga.

Denna nivå lägger till agenters förmåga att arbeta med variabler. Med hjälp av variabler kan agenter anpassa interaktioner, behålla kontext i flera interaktioner och dynamiskt justera sitt beteende baserat på specifika datapunkter som upprätthålls under agentsessionen. En agent kan till exempel samla in användarpreferenser, orderuppgifter och annan relevant information och sedan använda dessa data för att skräddarsy interaktionen. Med variabler blir agenter bättre på att hantera mer komplexa, mer föreskrivna och mer anpassade interaktioner.

I det sista steget integreras agenten med Salesforces kärnfunktioner: Apex, API:er och flöde. Genom integrering kan agenten utföra komplexa åtgärder inom Salesforce-ekosystemet, till exempel få åtkomst till och hantera data, utlösa arbetsflöden och interagera med andra system.

• Apex tillhandahåller programmatisk kontroll.
• API:er möjliggör sömlös integrering med andra applikationer.
• Flöden möjliggör automatisering av komplexa affärsprocesser.

På denna nivå omvandlas agenten till ett kraftfullt verktyg som kan utföra avancerade uppgifter och bidra direkt till affärsresultat.

Utgå från en baslinje för agenters respons och autonomi, och tänk på en agent som bara består av ämnen och åtgärder med motsvarande beskrivningar. Vi kan använda denna exempelagent för att introducera resonemangsmotorns olika steg och för att visa hur den använder dessa beskrivningar för att välja rätt ämnen och sedan åtgärder som ska utföras. Genom att utelämna ämnesinstruktioner i detta exempel kan vi observera att agenter på denna första nivå har störst frihet jämfört med agenter på högre nivåer. På nivå ett kan agenten helt fritt välja den åtgärd som den anser är lämplig, enbart baserat på den pågående konversationen.

Gå igenom följande överväganden för resonemangsmotorn:

• Konfigurationsinställningarna är fasta för resonemangsmotorns LLM. Agentverktyg kan inte ändra dem. För närvarande används OpenAI-LLM:er för resonemangsfunktioner. Detta kan dock komma att ändras när fler modeller läggs till.
• Standardhistorik för resonemangsmotorn: När en begäran görs till resonemangsmotorn (steg 2–5) hämtar den automatiskt historiken för de senaste begärandena och svaren. Detta säkerställer att konversationskontexten upprätthålls för resonemangsmotorn. Förutom kundinteraktioner omfattar dessa anrop till planerar-LLM:en anrop till resonemangsmotor-LLM:en för andra begäranden, till exempel ämnesval.

Resonemangsprocessen består av fyra huvudsakliga steg:

1. ämnesval
2. åtgärdsval
3. agentisk loop
4. grundningskontroll.

Ämnen är utformade för att agenter ska klassificera rätt åtgärd eller åtgärdssekvens mer korrekt. Varje ämne bör bestå av semantiskt distinkta åtgärder som kan tillhöra en kortfattad ämnesbeskrivning och därmed tillhöra en liknande agentfunktion.

Rätt ämne väljs av resonemangsmotor-LLM:en (steg 2–3 i diagrammet). Den väljer det ämne vars klassificeringsbeskrivning matchar det senaste yttrandet bäst, med hjälp av en ämnesprompt. Denna ämnesprompt innehåller klassificeringsbeskrivningarna för alla ämnen och konversationshistoriken. Förutom yttranden och agentsvar innehåller konversationshistoriken utförda åtgärder och deras resultat. Dessutom innehåller prompten viktiga instruktioner som föreskriver analys inom ramen för konversationshistoriken och kräver att LLM:en anger sin tankeprocess.

Fler överväganden:

• Ytterligare ett dolt ämne för irrelevanta yttranden finns automatiskt tillsammans med de synliga ämnena. Detta ämne väljs när inget annat befintligt ämne överensstämmer med yttrandet. Det hjälper agenten att undvika felklassificering. Detta ämne har inga åtgärder. Det finns bara för att hjälpa resonemangsmotorn att formulera ett lämpligt svar senare.
• Det är bara ämnets namn och klassificeringsbeskrivning som används i ämnesprompten.
• Resonemangsmotor-LLM:en kan bara välja ett ämne åt gången.
• Konversationer kan oväntat ändra riktning. När ett yttrande tas emot går resonemangsmotorn vidare till steget för ämnesval. Det innebär att ett nytt ämne kan väljas vid varje nytt yttrande.

Syftet med ämnen är dubbelt:

1. minska risken för att resonemangsmotorn blir förvirrad genom att gruppera åtgärder, så att den inte väljer fel åtgärder
2. vägleda val och utförande av åtgärder med instruktioner (mer om det i nivå två: agentisk kontroll: lägg till instruktioner).

Genom att noggrant organisera agentförmågor i tydligt definierade ämnen som består av relaterade åtgärder fungerar agenten mer effektivt och förutsägbart. Det blir också enklare att uppdatera och utöka. Det finns två möjliga strategier för ämnesdesign: uppifrån och ner eller nerifrån och upp.

• Med strategin uppifrån och ner utformas ämnena först som jobb på hög nivå som agenten ska utföra och sedan definieras de enskilda åtgärderna för dessa ämnen.
• Med strategin nerifrån och upp definieras först alla enskilda åtgärder som sedan grupperas i ämnen.

Båda strategierna leder till goda resultat när de följs korrekt.

Strategin nerifrån och upp

Denna sektion går igenom strategin nerifrån och upp eftersom den stämmer väl överens med orsakerna till att resonemangsmotorn behöver ämnen från början.

Steg 1: Lista alla agentåtgärder

Börja med att lista alla specifika åtgärder som agenten bör kunna utföra. I denna fas är det bättre att vara mycket specifik snarare än för vag. Undvik att försöka gruppera eller förenkla åtgärder för tidigt. Målet är att skapa en heltäckande och granulär bild av vad agenten kan göra.

När det till exempel gäller en kundserviceagent kan den inledande listan innehålla följande:

• Returnera en order: används för att påbörja returprocessen för en order.
• Kontrollera lagertillgänglighet: används för att verifiera om en produkt finns i lager.
• Kontrollera policyer för produktbyte: används för att hämta information om bytesregler.
• Svara på frågor med kunskap: används för att svara på allmänna eller vanliga frågor.
• Kontrollera kampanjer: används för att kontrollera om det finns några tillgängliga kampanjer eller rabatter.
• Förutsäg leveransdatum: används för att uppskatta förväntat leveransdatum/-tid.
• Kontrollera orderstatus: används för att hitta aktuell status för en kunds order.
• Hitta kundorder: används för att hämta alla tidigare eller aktiva order för en specifik kund.
• Felsök tekniska problem: används för att lösa tekniska problem med en produkt eller tjänst.
• Hitta kundordervillkor: används för att hämta alla villkor som rör en order.
• Hitta kundtillgångar: används för att identifiera eller hämta tillgångar som är kopplade till en kund.
• Ändra leveransadress.

Observera att en åtgärd som ”Åtgärda kundklagomål” är för bred i detta läge. Åtgärder bör representera den lägsta granularitetsnivån i agenters beteende. Det kan finnas många typer av klagomål och de omfattas redan av olika åtgärder:

• Problem efter leverans, till exempel felsökning av skadade eller defekta produkter, omfattas redan av ”Felsök tekniska problem”.
• Problem före leverans, till exempel saknade leveranser, ändring av leveransdatum eller ändring av order, omfattas redan av åtgärder som ”Kontrollera orderstatus”, ”Förutsäg leveransdatum” eller ”Returnera en order”.
• Allmänna kundfrågor, till exempel policyförfrågningar, omfattas redan av ”Svara på frågor med kunskap” eller ”Kontrollera policyer för produktbyte”.

Steg 2: Markera åtgärdspar (eller -multiplar) som kan orsaka förvirring i resonemanget

Markera åtgärder som liknar varandra eftersom de kan orsaka förvirring för resonemangsmotorn. Deras beskrivningar kommer inte att vara tillräckligt olika semantiskt, och därför kommer resonemangsmotorn inte att veta vilken åtgärd den ska välja i steg 5.

”Felsök tekniska problem” och ”Svara på frågor med kunskap” har till exempel liknande beskrivningar, men deras funktion kan skilja sig avsevärt. Genom att markera sådana semantiska överlappningar blir det lättare att identifiera vilka åtgärder som ska separeras mellan flera ämnen.

Steg 3: Skapa inledande grupperingar av åtgärder i ämnen

När åtgärder har definierats tydligt och deras semantiska överlappningar har identifierats kan åtgärder grupperas i preliminära ämnen. Ett ämne är en logisk kategori av funktioner – en gruppering av åtgärder som tillsammans representerar en sammanhängande förmåga eller färdighet hos agenten.

När du skapar dessa grupperingar ska du

• undvika semantisk överlappning genom att använda så få ämnen som möjligt
• säkerställa att varje ämne innehåller åtgärder som är relaterade på ett meningsfullt sätt
• se till att stödjande åtgärder som måste utföras i en kedja finns i samma ämne.

Här är ett exempel på en inledande gruppering för en kundserviceagent:

Ämne 1:

• Returnera en order
• Kontrollera lagertillgänglighet
• Kontrollera policyer för produktbyte
• Kontrollera kampanjer
• Förutsäg leveransdatum
• Hitta kundordervillkor
• Kontrollera orderstatus
• Hitta kundorder
• Hitta kundtillgångar
• Svara på frågor med kunskap
• Ändra leveransadress

Ämne 2:

• Felsök tekniska problem
• Hitta kundtillgångar

Steg 4: Skriv klassificeringsbeskrivningar för ämnen och dela upp ämnen om det behövs

När du har den inledande grupperingen skriver du klassificeringsbeskrivningar för alla ämnen.

• Det är tydligt att ämne 2 i vårt exempel handlar om tekniska problem med produkter.
• Ämne 1 har dock en bredare omfattning. Det handlar till stor del om orderhantering men innehåller också vissa åtgärder som inte är relaterade till orderhantering, till exempel att kontrollera kampanjer och svara på frågor med kunskap. Ämne 1 kan inte beskrivas kort och koncist i en enda mening och därför bör ämnet delas upp i olika ämnen.

När vi har förfinat får vi följande:

• Ämne 1: Orderhantering: Beskriver åtgärder som rör hantering och ändring av kundorder och relaterad logistik, förutom allt som rör byte och retur.
  • Kontrollera lagertillgänglighet: avgör om en produkt finns i lager.
  • Förutsäg leveransdatum: uppskatta när en order levereras.
  • Kontrollera orderstatus: hitta statusen för en kunds order.
  • Hitta kundorder: hämta alla order som gjorts av en kund.
  • Ändra leveransadress.
• Ämne 2: Felsökning
  • Hitta kundtillgångar: hämta kundens registrerade enheter eller produkter.
  • Felsök tekniska problem: ge teknisk hjälp eller diagnostik.
• Ämne 3: Byte: Beskriver åtgärder som är relaterade till orderbyte och retur.
  • Returnera en order: påbörja processen för orderretur.
  • Kontrollera policyer för produktbyte: tillhandahåll bytesregler för produkter.
  • Hitta kundorder: hämta alla order som gjorts av en kund.
  • Hitta kundordervillkor: hämta alla villkor som rör en beställning.
• Ämne 4: Produktsupport: Beskriver övergripande åtgärder som används för hämtning och vidarebefordran av information.
  • Svara på frågor med kunskap: svara på allmänna kundförfrågningar med hjälp av kunskapsbasinformation.
  • Kontrollera kampanjer: visa aktuella kampanjer eller rabatter.

Sammanfattningsvis ska du först skapa en heltäckande lista över alla möjliga åtgärder och sedan markera semantisk överlappning mellan åtgärderna. Skapa sedan en uppsättning ämnen som åtminstone löser all semantisk överlappning (så att resonemangsmotorn inte blir förvirrad inom ramen för ett ämne). Skriv därefter alla ämnens klassificeringsbeskrivningar. Om ämnena har för bred omfattning delar du upp dem i mer granulära ämnen. Genom att implementera denna vägledning kan du skapa en agent som inte bara presterar bra, utan också är lätt att underhålla och utöka.

Denna struktur stöder bättre resonemang, mer exakt utförande och tydligare beslutsgränser inom agentens beteende. Den bygger också på samarbete mellan designers, ingenjörer och ämnesexperter för att göra agentens förmågor mer transparenta och modulära.

Fler överväganden för att skapa effektiva ämnen

• Optimalt antal ämnen: För att förbättra LLM:ernas prestanda när det gäller att klassificera rätt ämne är det generellt sett lämpligt att inte överskrida tio ämnen. Men detta är bara en tumregel. Dessutom bör varje ämne ha en tydlig och distinkt beskrivning. I slutändan beror det optimala antalet ämnen på det semantiska avståndet mellan ämnens klassificeringsbeskrivningar. Om ämnena har klassificeringsbeskrivningar som är mycket olika minimeras risken för ämnesöverlappning. Mer bästa praxis för att undvika överlappning mellan ämnen beskrivs här .
• Balansera ämnens storlek och tydlighet: Det är generellt sett bra att ha små ämnen när det gäller åtgärder och instruktioner för enklare klassificering, men det kan leda till förvirring att skapa för många ämnen med mycket liknande beskrivningar, precis som semantisk överlappning mellan åtgärder leder till felklassificering. Därför är det viktigt att ha tydligt semantiskt differentierade ämnesbeskrivningar. Du kan använda LLM:er för att skapa de differentierade klassificeringarna.
• Standardspråk och kontextuell tydlighet: LLM:er kanske inte känner till företags specifika betydelser och förkortningar. Använd standardspråk eller var mycket tydlig när du förklarar ords betydelser i din specifika kontext.
• Endast ämnets namn och beskrivning skickas i ämnesprompten. Därför påverkas inte ämnesvalet om ämnets omfattning eller instruktioner ändras.

Exempel i praktiken

Tänk dig att en serviceagent får en garantipolicybegäran som rör en klocka. Garantiproblemet verkar inte vara relaterat till produktbyte eller support. Orderhantering verkar vara det lämpligaste ämnet för att hantera denna begäran. Därför väljs det senare ämnet av resonemangsmotorn som det mest sannolika för att uppfylla begäran.

Efter ämnesvalet väljer resonemangsmotorn rätt åtgärder som ska utföras från det valda ämnet. Resonemangsmotor-LLM:en är återigen ansvarig för detta, med hjälp av en annan prompt som kallas observationsprompten. Syftet med observationsprompten är att hämta nästa steg i resonemangsprocessen. Nästa steg kan vara något av följande:

• starta en åtgärd
• begära åtgärdsindata från användaren
• begära förtydligande av användarens begäran
• skicka det slutliga svaret till användaren (uppfylla användarbegäran) när åtgärdsloopen har slutförts (mer information finns i resonemangssteg 3).

Indata till observationsprompten utgörs av alla beskrivningar av alla åtgärder från ämnet samt från konversationshistoriken.

Bästa praxis för åtgärdsdesign

Åtgärder är de fördefinierade uppgifter som agenten kan utföra för att göra sitt jobb. Åtgärder är de mest finkorniga definitionerna av arbete. Det finns fem olika typer av agentåtgärder: (1) utför Apex-kod, (2) anropa ett API, (3) utför ett flöde, (4) få ett LLM-svar på en promptmall och (5) anropa en prediktiv modell. De flesta av dessa åtgärder kan vara deterministiska. Ett undantag är att få ett svar på en promptmall (förutsatt att det externa systemet, flödes- eller Apex-åtgärden inte innehåller sannolikhetsbaserade element som promptanrop). Vi kommer att ta upp dessa frågor på den femte nivån av agentisk kontroll.

1. Kontrollera agentiskt beteende i promptåtgärder. Det finns två sätt att tillämpa kontroll över agentens beteende i promptåtgärder: (1) lägg till fler instruktioner i promptmallen genom promptteknik och (2) konfigurera hyperparametrarna för LLM:en som genererar promptsvaret, särskilt temperaturen (se dokumentationen ). Om temperaturen sänks minskar variationen i de genererade svaren, vilket ökar deras repeterbarhet och agenternas tillförlitlighet.
2. Optimalt antal åtgärder inom ett enda ämne: I likhet med det maximala antalet ämnen bör antalet åtgärder inom ett ämne inte överstiga tio. Men detta är återigen en tumregel. Den verkliga drivande faktorn är det semantiska avståndet mellan åtgärderna. När åtgärder tydligt kan särskiljas genom deras beskrivning kan detta tal vara större. Det finns dock inget numeriskt mått för semantiskt avstånd utan det beror på agentverktygets tolkning. Ju större skillnaden i betydelse är mellan åtgärdsbeskrivningarna, desto större blir det semantiska avståndet. Du bör alltid undvika överlappningar här.
3. Åtgärdsbeskrivningar: I motsats till vad namnet antyder fungerar ”åtgärdsinstruktionen” i själva verket som en instruktion som resonemangsmotor-LLM:en använder för att välja rätt åtgärd från ämnet. Observera att klassificeringarnas kvalitet kan förbättras avsevärt om semantiskt distinkta åtgärdsbeskrivningar används. Gå noggrant igenom dessa beskrivningar och jämför i synnerhet alla åtgärdsbeskrivningar som tillhör ett enda ämne.

Exempel i praktiken

Vi ska fortsätta med det tidigare exemplet där en serviceagent fick en fråga om garantipolicyn för en klocka. När ämnet Orderhantering har valts väljs den mest sannolika åtgärden. Eftersom detta är ämnet Orderhantering är det första logiska steget att söka efter ordern (vad finns det annars att hämta garantiinformation för?) genom att starta åtgärden för att söka efter order.

Ett användaryttrande kan utlösa flera åtgärder innan ett svar skickas tillbaka till användaren. Det beror på den agentiska loopen, som fortsätter att välja och utföra nästa lämpligaste åtgärd tills något av följande villkor har uppfyllts:

• Resonemangsmotor-LLM:en avgör om begäran är fullständig. I detta fall bedömer den att användarbegäran har uppfyllts av svaret. Observera att en del av denna kontroll omfattar en jordningskontroll som verifierar att svaret är grundat i åtgärdsutdata. Ingen information i svaret bör konstrueras av resonemangsmotor-LLM:en, eftersom det kan leda till hallucinationer eller på annat sätt felaktiga svar.
• Inga fler lämpliga åtgärder hittas.
• Maximalt antal tillåtna LLM-anrop för det aktuella steget nås. Detta antal bestäms av själva resonemangsmotorn.

Åtgärder omfattas inte av en specifik tidsgräns. Syftet med detta är att undvika avbrott när tider för åtgärdsutförande varierar beroende på deras komplexitet. Vissa åtgärder är helt enkelt mer komplexa att utföra än andra.

Exempel i praktiken

Efter att resonemangsmotorn har startat en ordersökning utvärderar den svaret som har genererats hittills. Sedan beslutar den att det behövs mer arbete innan ett svar kan skickas tillbaka till användaren. Den är på väg att söka efter garantipolicyn nu när ordern finns i konversationshistoriken.

Agenten inser dock därmed att kunden i själva verket har köpt två klockor, vilket hämtas av åtgärden ”ordersökning”. Därför väljer nu resonemangsmotorn i den agentiska loopen att be kunden att ange vilken klocka de behöver garantiinformation om.

Undvik överdrivet specifika manus

Undvik att skriva överdrivet specifika manus för hur agenter ska ha konversationer med användare. Överdrivet specifika manus kan hämma en agents förmåga att skapa förtroende, förstå unika användarbehov och reagera effektivt i realtid på dynamiska omständigheter. Dessutom kan långa instruktioner göra att agenten reagerar långsammare och förvirra resonemangsmotorn. Att framtvinga determinism via instruktioner är inte den lämpligaste strategin.

Vad du inte ska göra

Det finns till exempel ingen anledning att be en agent att undvika att hänvisa till konkurrenter i servicesvar. Detta kan leda till oönskat beteende, eftersom agenten även kan vägra att svara på frågor som rör integrering med en leverantör som också är en konkurrent. Istället kan instruktionen se ut som ”Vid diskussioner om konkurrenter, svara med företagets intresse i åtanke.” På så sätt undviks begränsande, villkorliga instruktioner som ”Nämn bara konkurrenten xyz när det gäller…” och istället utnyttjas LLM:ens resonemangsfunktioner. Detta exempel visar hur instruktioner kan ges på en högre, mer abstrakt nivå, ungefär som en mänsklig servicemedarbetare skulle utbildas efter att ha börjat på företaget.

Vi ska titta på några fler exempel på vad du inte ska göra. Här är några dåliga instruktioner som ges till en serviceagent som hanterar kandidatprofiler på en rekryteringswebbplats. Dessa instruktioner försöker förutse varje möjligt kundyttrande och bör därför undvikas:

Instruktion 1: Agenten får följande yttrande: ”Kan jag lägga till en bild i min profil?”, fråga omedelbart kunden: ”Vilken profiltyp har du?”

Instruktion 2: Om kunden anger en premiumprofil, svara ”Låt mig kontrollera dina kontraktsuppgifter” och sök sedan efter kontraktsuppgifter och kontrollera om det har avtalats att de kan uppdatera profilbilden.

Om det har avtalats att kandidaten kan göra det, svara ”Ja, det är möjligt. Jag kan uppdatera den åt dig. Kan du skicka din nya bild?” När bilden har tagits emot, uppdatera kandidatens profil med den. Om ändringar av profilbilden inte ingår i kontraktet, säg ”Detta är tyvärr inte möjligt. Jag vidarebefordrar dig till en mänsklig agent.”

Instruktion 3: Icke-premiumprofil: Om kunden anger en icke-premiumprofil, svara: ”Du kan inte uppdatera din bild. Meddela mig om du vill göra det, så överför jag dig till en mänsklig agent.”

Instruktion 4: Om profiltypen är oklar, svara: ”Jag förstod inte din profiltyp.”

Vad du ska göra istället

Istället för denna typ av detaljstyrning ska du använda en mer flexibel strategi som instruerar agenternas beteende. Utgå från följande bästa praxis:

1. Använd RAG-/kunskapsåtgärder för policyer och regler som finns i kunskapsartiklar (istället för att skriva dem som instruktioner). Relevant information hämtas vid rätt tidpunkt. I exemplet ovan innebär det att en kunskapsartikel med titeln ”Bilduppdatering” bör innehålla följande: ”Endast kandidater med en premiumprofil vars kontrakt tillåter bildändringar kan uppdatera sin bild.”
2. Beskriv de viktigaste riktlinjerna och skyddsräckena individuellt, oberoende av konversationen. Ge agenter en kort och koncis förklaring av det förväntade beteendet eller den aktuella proceduren.

Baserat på denna bästa praxis kan en bättre uppsättning instruktioner se ut så här:

Instruktion 1 : ”Använd kunskapsåtgärder för att kontrollera policyer vid begäranden om kontoändringar.”

Instruktion 2 : ”Svara inte på frågor för vilka ingen tillämplig policy hittades.”

Om riktlinjerna ovan tillämpas kan agentens resultat förbättras. Om kunden ber agenten om en profiländring förstår agenten nu att den behöver hämta den nödvändiga policyn från kunskapsbasen, tolka reglerna som hämtats, tillämpa dessa regler på kontexten och slutligen svara kunden. I motsats till överdrivet specifika manus är denna beteendestrategi mycket mer generell och allmänt tillämplig. Utan att behöva skriva ut varje möjlig konversation kan agenten nu flexibelt svara med önskat beteende på ett bredare spektrum av konversationsämnen.

Tillämpa åtgärdssekvens

Observationsprompten innehåller instruktioner och åtgärdsbeskrivningar men utan någon definierad ordning. Om åtgärdssekvensen är viktig måste den uttryckligen anges i samma instruktion.

Vi ska fortsätta med exemplet om agenter på rekryteringswebbplatsen. Agenten bör kunna hantera intervjuplanering med lämplig intervjuare. För att göra det bör agenten först kontrollera rekryterarnas tillgänglighet och sedan föreslå tre möjliga tider för kandidaten.

I detta fall bör instruktionerna inte vara i separata rutor för att upprätthålla utförandets ordning:

1. Instruktion 1: Kontrollera intervjuarnas tillgänglighet.
2. Instruktion 2: Föreslå då lämpliga tider för kandidaten.

Dessa instruktioner fungerar inte eftersom resonemangsmotorn inte vet vad ”då”-satsen i instruktion 2 avser. Detta beror på att instruktionerna skickas till resonemangsmotorn som en grupp, inte i någon särskild ordning.

Istället bör sekvensdefinierande instruktioner kombineras till en sats och skrivas som nedan:

1. Instruktion 1: Kontrollera intervjuarnas tillgänglighet. Föreslå då lämpliga tider för kandidaten.

Tillämpa åtgärdsutdata utan att skriva om

Resonemangsmotorn i sig är en LLM. Den ansvarar för att generera det slutliga svaret enligt den agentiska loopen. Strategin behövs för att tillämpa agentinstruktioner som tillhandahåller skyddsräcken för svarsgenerering, eller för att kombinera utdata från flera åtgärder som var en del av den agentiska loopen, för att uppfylla användarbegäran.

Men när det förväntas att bara en promptåtgärd har utförts kan en instruktion implementeras för att instruera agenten att aldrig ändra en åtgärds utdata. Detta ger ett mer förutsägbart och tillförlitligt agentbeteende.

Det är avgörande att tillämpa denna strikta efterlevnad i godkända promptmallar i vissa scenarier, särskilt när enhetlighet, efterlevnad och fördefinierade meddelanden är viktiga. Här är två exempel:

• Reglerade branscher: Organisationer som är verksamma inom starkt reglerade sektorer (till exempel finans, hälso- och sjukvård eller juridik) kräver ofta strikt kontroll av all kundorienterad kommunikation. Godkända promptmallar säkerställer att svaren uppfyller juridiska och regulatoriska krav, vilket minimerar risken för feltolkning, skadeståndsskyldighet eller spridning av felaktig information.
• Förhandstestade och validerade svar: När promptmallar har genomgått noggranna tester och validering för att säkerställa noggrannhet, effektivitet och önskade resultat. Vid avvikelser från dessa mallar kan deras effektivitet och värde undergrävas. Strikt efterlevnad säkerställer att de beprövade meddelandena levereras på ett enhetligt sätt.

Denna instruktion begränsar agentens frihet att ändra åtgärders utdata. Se till att instruktionen hänvisar till promptmallens utdata (till exempel ”promptResponse”), som visas i denna ämnesplanerare.

Instruktionen i detta fall kan därför vara följande:

” Ändra inte promptResponse-utdata, oavsett agentens kanal. ”

Begränsningar av tillämpning av strikt efterlevnad:

När en interaktion kräver flera distinkta agentåtgärder är det inte möjligt att tillämpa strikt efterlevnad av en enda mall. Faktum är att resonemangsmotorn i detta scenario behöver konsolidera dessa åtgärder till ett enda svar och därför ändra varje enskild åtgärds utdata.

Optimalt antal instruktioner

Baserat på allmänna LLM-egenskaper varierar målantalet instruktioner mellan fem och tio, beroende på instruktionernas komplexitet och interaktion. Dessa instruktionsegenskaper påverkar antalet instruktioner som resonemangsmotorn kan följa:

• Tydlighet och specificitet: Väldefinierade regler är enklare att följa.
• Konflikter mellan regler: Om regler motsäger varandra krävs ytterligare logik för att lösa dem.
• Längd och komplexitet: Om varje regel kräver djupgående resonemang kan du dela upp dem i mindre instruktioner.

Om det är mycket viktigt att en instruktion följs uttryckligen kan du lägga till termer som visar deras betydelse:

• brådskande och viktigt (omedelbart, brådskande, kritiskt, viktigt, obligatoriskt)
• befogenhet och tillämpning (obligatoriskt, nödvändigt, strikt tillämpat)
• konsekvenser och varningar (överträdelse kommer att resultera i, underlåtenhet att följa kommer att leda till, bristande efterlevnad kan resultera i, strikta påföljder tillämpas, nolltolerans)
• tydlighet och direkthet (måste, otillåtet, förbjudet, inte tillåtet, alltid/aldrig).

Om svar grundas i data förbättras agenternas tillförlitlighet avsevärt. Grundade svar baseras på faktisk information snarare än på spekulation eller föråldrad kunskap. Retrieval Augmented Generation (RAG) är en allmänt vedertagen teknik som gör det möjligt för en agent att få åtkomst till och använda en kunskapsbas för att formulera mer exakta och kontextuellt relevanta svar. Baserat på en användares fråga använder en agent RAG för att hämta relevant information från tillämpliga datakällor och förstärker sedan prompten med denna information innan den skickas till LLM:en. En agent som använder RAG har högre kvalitet, korrekthet och övergripande nytta när det gäller agentinteraktioner, vilket ökar användarnas förtroende och nöjdhet. Bästa praxis för RAG beskrivs utförligt i den offentligt tillgängliga rapporten Agentforce och RAG: bästa praxis för bättre agenter .

Kunskap kontra instruktioner

Det är viktigt att skilja mellan kunskap och instruktioner när det gäller att hitta rätt balans mellan vägledning och flexibilitet, eftersom de har olika syften:

• Kunskap: Du kan se kunskap som biblioteket med böcker som agenten har tillgång till när de genererar sina svar. Några exempel är dokument, kunskapsartiklar och rapporter. Observera att dessa kan omfatta policyer och allmänna företagsregler. Kunskap kan också avse transaktionsfiler, till exempel e-postmeddelanden, samtalsutskrifter och till och med historiken för (agent-)konversationer. Slutligen omfattar kunskap långtextfält i strukturerade data. Kunskap skickas vanligtvis till agenten via RAG.
• Instruktioner: Du kan se instruktioner som den minsta uppsättningen regler som klargör för agenten när varje åtgärd ska användas. Instruktioner kan också införa skyddsräcken för hela konversationen, till exempel obligatoriskt tonfall. Instruktionerna kan ofta göras mer kortfattade och flexibla utan att tydlighet eller syfte påverkas. Istället för att tillhandahålla ett stelt manus med specifika svar för varje möjligt kundscenario kan du implementera allmänna riktlinjer och principer som hjälper agenten att välja rätt åtgärder i en mängd olika situationer.

Retrieval Augmented Generation (RAG)

Retrieval Augmented Generation (RAG) fungerar som ett intelligent datalager för kunskap. Den ger agenter tillgång till information i olika format och tillhandahåller relevanta textfragment för att svara på frågor. Med hjälp av RAG kan agenter få mer exakta LLM-svar utan att överbelasta LLM-prompten med irrelevant innehåll eller överskrida dess kontextfönster.

Vid körning utför RAG tre steg:

1. Hämtning: AI-systemet söker i en stor databas eller kunskapskälla för att samla in relevant information till LLM-prompten. Detta görs med hjälp av semantisk sökning, en mer avancerad teknik jämfört med traditionell nyckelordsbaserad sökning. Till skillnad från nyckelordssökning, som matchar exakta termer, förstår semantisk sökning ordens betydelse eller kontext. Den identifierar relevant information baserat på koncepten eller relationerna mellan termer, snarare än att bara leta efter exakta ordmatchningar. Nyckelordssökning kan också ingå i denna hämtningsprocess, vilket stärker den semantiska sökningen med nyckelordsmatchning för specifik terminologi eller specifika namn. Denna typ av sökning kallas hybridsökning.
2. Förstärkning: Den hämtade informationen läggs till i prompten.
3. Generering: LLM:en genererar ett kontextuellt lämpligt och mer exakt svar tack vare prompten som förstärktes med hämtad kunskap.

I Agentforce kan RAG användas med eller utan en promptmall:

1. Promptbaserad RAG: Med denna strategi finns instruktionerna som anger hur svaret ska genereras i promptinstruktionerna i en promptmall. I detta fall beror svaret helt på vad LLM:en genererar. Förutom promptinstruktionerna finns det olika sätt att påverka svaret, till exempel LLM-konfigurationsinställningar i Einstein Studio, men resultatet är ändå inte deterministiskt.
2. Resonemangsmotorbaserad RAG: Istället för att använda en promptmall använder agenten en åtgärd som hämtar delar (via ett flöde eller en Apex-klass) och lagrar dem i en variabel (se nästa sektion). Med denna strategi genererar resonemangsmotorn (istället för LLM:en) svar direkt, grundat i hämtade data. Instruktionerna som styr svarsgenerering är agentinstruktioner snarare än promptmallinstruktioner. Variabeln med det hämtade innehållet kan fortfarande uttryckligen skickas som indata till en åtgärd. Den kan också ges till resonemangsmotorn genom att ge den standardåtkomst till variabelns innehåll. Denna strategi medför avvägningar. Det finns en potentiell risk för att överbelasta resonemangsmotorn med innehåll och ansvar. Dessutom är parametrarna för resonemangsmotorns LLM, till skillnad från en prompt, inte konfigurerbara. Å andra sidan kan resonemangsmotorn generera sitt svar med hjälp av både de hämtade delarna och konversationens historik.

Den rekommenderade metoden är alternativ 1. Det minskar antalet uppgifter som resonemangsmotorn ska utföra och förbättrar därmed svarskvaliteten. Nästa sektion utforskar ett undantag från denna regel, där innehållet bevaras under hela konversationen och därmed uttryckligen ges till en åtgärd.

Bästa praxis för RAG

• Undvika fördefinierade RAG-instruktioner: Istället för att länka instruktioner direkt till specifika artiklar för särskilda frågor kan du utnyttja RAG:s intelligens för att dynamiskt hitta den mest relevanta datakällan och det mest exakta textfragmentet. RAG:s matchningsprocess bygger på en bredare förståelse av frågan, inte bara exakt mappning mellan frågan och källan.
• Konsolidera ämnen: Gruppera relaterade frågekategorier under ett enda ämne. RAG kan effektivt identifiera relevanta svar baserat på frågetyp, även inom ett bredare ämne. Till exempel kan produktfrågor som underhålls- och batteriproblem aggregeras till ett mer heltäckande ämne.

Lagra RAG-utdata i en variabel: När gränserna för antalet interaktioner kan nås ska RAG-utdata lagras i en variabel. Detta gör informationen tillgänglig för att vägleda agentinteraktioner utöver standardtröskelvärdet. Ett exempel på detta ges i nästa sektion.

Vissa affärsprocesser kräver ännu mer förutsägbart utförande, till exempel tillämpning av en specifik åtgärdssekvens eller villkor för att utlösa åtgärder eller ämnen.

För att uppnå detta deterministiska beteende kan variabler användas. Variabler fungerar som en strukturerad form av korttidsagentminne som kan utgöra åtgärdsindata eller -utdata. Dessutom kan en variabels tillstånd styra utlösandet av specifika ämnen och åtgärder.

Olika sätt som variabler stöder determinism

Variabler kan bidra till att uppnå guidad determinism för agenter på följande sätt:

1. Beständig dynamisk grundning: Variabler gör det möjligt för agenter att kontinuerligt uppdatera sin förståelse av världen samtidigt som de sparar viktig information som förblir opåverkad av efterföljande interaktioner. Denna metod säkerställer att viktig information, som kan vara ostrukturerade data som hämtas via RAG eller strukturerade data som användarprofilinformation, underhålls under hela konversationen, oberoende av konversationens längd.
2. Åtgärdsindata/-utdata: Variabler kan användas som både indata och utdata för åtgärder. Åtgärden hänvisar uttryckligen till variabler och åtgärdens utförande är inte beroende av resonemangsmotorn för att ange dessa indata och utdata, vilket ökar agentens determinism.
3. Filtrering: Variabler kan användas för att fastställa villkorligt utförande av åtgärder eller ämnen. Variabler möjliggör ett specifikt informationsflöde mellan åtgärder och determinism vid åtgärdsutförande. Denna förmåga är särskilt avgörande för säkerhetsregler där åtgärder inte kan påbörjas om specifika indatavariabler, till exempel e-post, inte har verifierats.

Typer av variabler i Agentforce

Agentforce har två typer av variabler:

• Kontextvariabler är systemgenererade variabler som innehåller information om användaren och konversationssessionerna.
• Anpassade variabler kan instansieras av användaren. De innehåller valfri typ av information som används för något av de tre sätten som variabler stöder determinism.

Variabeltyper stöder följande funktioner:

Vi ska fördjupa oss ytterligare i variabler med ett exempel på användningsfall: en kundorienterad felsökningsagent. I detta exempel används variabler för alla tre syften: beständig dynamisk grundning, åtgärdsindata/-utdata och filtrering.

I detta exempel hjälper agenten en kund att felsöka ett tekniskt enhetsproblem. Felsökning innebär vanligtvis att gå igenom ett antal steg. Agenten bör erbjuda en serviceupplevelse som efterliknar en mänsklig serviceagents arbete. För att göra det bör agenten inte ge kunden alla felsökningssteg på en gång. Istället bör den erbjuda steg-för-steg-instruktioner samt möjligheten att navigera mellan steg (inklusive att gå tillbaka till tidigare steg) baserat på hur kunden svarar.

En utmaning med detta är agentens förmåga att behålla alla felsökningssteg under hela konversationen. Med tanke på agentens begränsade minne på grund av det begränsade antalet interaktioner den kan lagra kan dessa steg tas bort från resonemangsmotorns kontext om konversationen blir lång.

Denna utmaning hanteras genom att använda en variabel för att grunda resonemangsmotorn dynamiskt i felsökningsstegen. Genom att hämta informationen och lagra den i en variabel förblir den tillgänglig och kan uppdateras under hela konversationen. Resonemangsmotorn använder informationen som lagras i denna variabel för dynamisk grundning.

I detta exempel innehåller ett ämne två åtgärder. Dessa två åtgärder behövs för att säkerställa ett enhetligt dataflöde. Den första åtgärden används för att fylla i variabeln som innehåller alla felsökningssteg. Den andra åtgärden använder den variabeln under själva felsökningen.

1. Åtgärd 1: ”Fyll i problemlösningssteg”. Detta är den inledande åtgärden, som utlöses av agentens första introduktion till problemet. Den använder Retrieval Augmented Generation (RAG) för att extrahera alla nödvändiga lösningssteg från en indexerad kunskapsbas. Åtgärden lagrar resulterande utdata i en variabel med namnet ”Lösningssteg”.
2. Åtgärd 2: ”Använd mitt i problemlösning”. Detta är en åtgärd baserad på en prompt vars utdata är det mest sannolika nästa felsökningssteg som ska användas under felsökningsprocessen. Agenten instrueras att använda denna åtgärd mitt i problemlösningen.

Den ursprungliga kundfrågan är indata till båda åtgärderna. Den andra åtgärden har andra indata: innehållet i variabeln ”Lösningssteg”. Denna variabel har angetts av den första åtgärden. Observera att den andra åtgärden inte kommer att hämta själva felsökningsstegen, utan istället hämta dem som indata från den första åtgärden via variabeln. Följande diagram visar dataflödet mellan dessa två åtgärder.

Åtgärden ”Använd mitt i problemlösning” hänvisar alltid till de ursprungliga felsökningsstegen som hämtas av åtgärden Problemlösningssteg. Detta dataflöde säkerställer att felsökningsstegen upprätthålls sammanhängande och alltid finns tillgängliga, oberoende av konversationens längd.

För att utföra de åtgärder som definieras i detta exempel behövs specifika instruktioner, till exempel ”Utför alltid ’Fyll i lösningssteg’ först”. Med tanke på den icke-deterministiska karaktären hos LLM:er som används av agenter kan detta dock leda till en annan ordning i vissa fall. För att säkerställa en deterministisk utförandeordning introducerar vi villkorliga filter för dessa variabler för att tillämpa rätt åtgärdssekvens. Agenten läser värdet av variabeln ”Lösningssteg” och definierar två filter beroende på om denna variabel har ett värde eller inte.

• Åtgärden Problemlösningssteg kan endast utföras om variabeln ”Lösningssteg” är tom.
• Åtgärden ”Använd mitt i problemlösning” kan endast utföras om variabeln ”Lösningssteg” har ett värde.

Dessa villkorliga filter tillämpar nu deterministiskt sekvensen för åtgärdsutförande: Åtgärden ”Använd mitt i problemlösning” måste vänta tills ”Problemlösningssteg” har slutförts, vilket säkerställer att variabeln ”Lösningssteg” alltid har ett värde.

För att säkerställa korrekt åtgärdsutförande krävs en tredje åtgärd för att återställa variabeln ”Lösningssteg” om problemet är helt löst. Därmed återställs agenten till nödvändigt tillstånd för att hjälpa till med ett annat, nytt problem. Denna tredje åtgärd har namnet ”Töm lösningsvariabeln”. Det fullständiga åtgärdsdiagrammet visas nedan.

Variabler är avgörande för att vår felsökningsagent ska kunna lösa kundproblem genom att möjliggöra följande:

• Beständig dynamisk grundning: Variabler lagrar felsökningssteg och säkerställer att de är tillgängliga under hela konversationen, oavsett längd och antal interaktioner. Det förhindrar att agenten glömmer kontexten.
• Dataflöde: Variabler underlättar dataflödet mellan åtgärder. Till exempel lagrar variabeln ”Lösningssteg” de hämtade felsökningsstegen från åtgärden Problemlösningssteg och tillhandahåller dem som indata till åtgärden ”Använd mitt i problemlösning”.
• Determinism: Variabler kan användas som filter för att tillämpa en specifik ordning för åtgärdsutförande. Till exempel utförs åtgärden Använd mitt i problemlösning endast om variabeln Lösningssteg har ett värde, vilket säkerställer att åtgärden Problemlösningssteg körs först.

I en tid av generativ AI är prediktiv AI fortfarande avgörande eftersom den utgör den grundläggande intelligensen som vägleder, förbättrar och kontextualiserar generativa funktioner. Medan generativ AI fokuserar på att skapa nytt innehåll, till exempel text, bilder och videor, ger prediktiva modeller förutsägelser om framtiden baserat på indata från affärsdata i realtid. Några exempel på affärsresultat är sannolikhet för kundbortfall, sannolikhet för konvertering, sannolikhet för eskalering av ärenden, kundens livstidsvärde och ärendeklassificering. Förutsägelser kan förutse användarnas behov, anpassa utdata, verkställa beslut, optimera innehållsrelevans i realtid – allt genom att analysera trender och siffror. I applikationer som anpassad inlärning, hälso- och sjukvård eller finansiell planering säkerställer till exempel prediktiv AI att generativa utdata överensstämmer med individuella kontexter och sannolika framtida scenarier. Tillsammans skapar prediktiv och generativ AI en kraftfull synergi där framsynthet kombineras med kreativitet för att skapa mer intelligenta, adaptiva och kraftfulla tekniklösningar.

Så här integrerar du prediktiva modellutdata i agentarbetsflöden

Om du vill integrera prediktiva modellutdata i agentarbetsflöden lägger du bara till prediktiva modellåtgärder i Agentforce-tillgångarna. Modellverktyget gör det möjligt att skapa eller registrera prediktiva modeller (BYO) som sedan används av agenten för att ge förutsägelser. De resulterande förutsägelserna (samt prediktorerna) kan lagras i anpassade variabler. Agenter kan använda dessa variabelvärden som indata till, och villkora utförandet av, specifika åtgärder och ämnen.

Exempel på användningsfall som är integrerade med prediktiva modeller

• Segmentering: Utför klassificering i flera klasser för kundsegmentering och använd det resulterande segmentet för att filtrera vissa åtgärder. Förbehåll till exempel premiumåtgärder för kunder på premiumnivå.
• Sannolikhet för eskalering: Förutsäg sannolikheten för eskalering av ett serviceärende. Om denna sannolikhet överskrider ett visst tröskelvärde, tillåt utförande av åtgärder som löser ärendet snabbare eller eskalerar till mänskliga agenter snabbare.
• CPG: Planera endast en kampanj om försäljningsökningen (poäng som beräknas av en prediktiv modell) överskrider ett visst tröskelvärde.
• Handel: Föreslå endast en produkt om köpbenägenheten överskrider ett visst tröskelvärde.

Vissa affärsprocesser måste utföras i en exakt ordning och kräver inte användarindata under utförandet. I detta fall kan ett förutbestämt flöde av steg tillämpas via flöden, API:er eller Apex. Om du har ett befintligt flöde som är nödvändigt i produktionen är det en bra indikation på att det kan lagras och användas av agenten för att utföra den affärsprocessen. Alla exempel nedan omfattar förutbestämda sekvenser av steg som agenten kan utföra utan användarindata. Det agentiska beteendet i detta fall består i att identifiera vilken deterministisk process som ska utföras, hur nödvändiga indata ska samlas in och hur utdata ska tolkas och bearbetas.

Affärsprocesser med många sekventiella steg (fler än tre som tumregel) och många beroenden av variabler blir för komplexa och besvärliga att tillämpa med instruktioner. I detta fall är det möjligt att helt enkelt hårdkoda dem med hjälp av de deterministiska åtgärdstyper som anges i denna sektion. Observera slutligen att dessa implementeringar kan omfatta icke-deterministiska element, till exempel anrop av LLM:er med lösta promptmallar. Därför är de inte nödvändigtvis helt deterministiska, från början till slut, och de kan fortfarande ha de önskade flexibilitetsnivåerna som agenter är kända för.

Stegsekvensen i en marknadsföringsresa villkoras av fasta regler och är inte beroende av konversationsanvändarindata. Därför kan flödet användas som en Agentforce-åtgärd. En anropbar åtgärd kan skapas för att slutföra bakgrunds- eller händelseutlösta uppgifter från en lösningskomponent som kan anropa ett flöde eller en Apex-klass. Lägg till en anropbar åtgärd i ett flöde eller en Apex-klass och ange den uppgift som agenten slutför samt de villkor som utlöser agenten. Anropbara åtgärder kan också innehålla agentens kontextvariabler och vidarebefordra viktig information.

Salesforce-flöden kan användas för att automatisera rutinuppgifter, till exempel skapa uppföljningsuppgifter, skicka e-postpåminnelser eller uppdatera poster. Flöden gör arbetet mer effektivt och produktivt. Agenter kan också utföra flöden med hjälp av flödesåtgärder. Tack vare determinismen är flöden ett bra sätt att rikta agentiskt beteende när en affärsprocess behöver utföras i en viss sekvens. En bra indikation på att en flödesåtgärd är lämpligast är när ämnet annars skulle innehålla instruktioner som ”Gör först detta, gör sedan detta och gör slutligen detta”. Det blir besvärligt att hantera tillämpning av sekvenser med fler än tre steg via instruktioner och variabler.

Flöden kan också omfatta icke-deterministiska element genom att anropa promptar. En promptnod i flödet anropar en promptmall och samlar in svaret som kan vidarebefordras till andra element i flödet. Dessa ytterligare element kan återigen vara promptnoder, till exempel som sammanfattar föregående svar, vilket skapar en kedja av promptar. Detta är särskilt användbart när reglerna för promptkedja definieras av fasta element och inte är beroende av användarindata. Ett exempel är agentisk RAG där en fördefinierad sekvens av hämtningsverktyg eller promptar i ett flöde kan få åtkomst till specifika datakällor i en viss ordning, till exempel initialt hämta data från en användares landsdokument innan andra källor konsulteras efter behov. Denna kedjemekanism möjliggör en tillförlitlig och ordnad utvinning av relevant information.

I likhet med flöden är Apex- och API-åtgärder deterministiska på så sätt att en fördefinierad sekvens av åtgärder kan kodas. Dessa åtgärder kan omfatta icke-deterministiska element, till exempel anrop av promptmallar eller LLM-anrop. Men i sin definition utför de dessa steg deterministiskt, vilket minskar den agentiska variationen genom att anropa åtgärden vid rätt tidpunkt, samla in nödvändiga indata och bearbeta utdata. Dessa ansvarsområden måste ändå styras av agentiska instruktioner, så de är icke-deterministiska. Apex- och API-åtgärder är pro-kod-motsvarigheten till flödesåtgärder.

För att uppnå tillförlitligt agentbeteende krävs en strukturerad strategi som balanserar den inneboende flexibiliteten hos stora språkmodeller (LLM:er) med behovet av kontroll och förutsägbarhet på företagsnivå. I denna artikel beskrevs en skiktad strategi för att implementera ”guidad determinism” som gör det möjligt att skapa agenter som inte bara är intelligenta och autonoma utan också enhetligt korrekta och överensstämmande med affärsprocesser. Nyckeln till att skapa dessa betrodda agenter är en successiv implementering av kontrollmekanismer, som var och en lägger till ett nytt lager av tillförlitlighet:

1. Grundläggande ämnes- och åtgärdsdesign: Processen börjar med att en agents förmågor noggrant organiseras i distinkta ämnen och granulära åtgärder. Genom att skapa semantiskt distinkta och logiska grupperingar minskar vi risken för att resonemangsmotorn blir förvirrad och väljer fel åtgärd, vilket lägger grunden för förutsägbart beteende.
2. Uttryckliga instruktioner: Med utgångspunkt i denna grund ger agentinstruktioner nästa nivå av kontroll. Dessa instruktioner fungerar som skyddsräcken och riktlinjer som styr hur resonemangsmotorn ska utföra åtgärder inom sina ramar, följa företagspolicyer och hantera konversationsflödet utan överdrivet specifika interaktionsmanus.
3. Datagrundning med RAG: För att förbättra svaren med fakta och relevans kopplar datagrundning agenten till verifierade kunskapskällor. Strategier som Retrieval Augmented Generation (RAG) gör det möjligt för agenter att hämta korrekt information i realtid från kunskapsartiklar och företagsdata, vilket minimerar spekulationer och förbättrar tillförlitligheten.
4. Kontext- och tillståndshantering med variabler: För mer komplexa och tillståndsbaserade interaktioner introducerar variabler en form av korttidsminne. De gör det möjligt för agenten att behålla kontext, spara viktiga data under en konversation och tillämpa en deterministisk sekvens av åtgärder genom att villkora åtgärdsutförande enligt en variabels tillstånd.
5. Deterministiskt utförande med flöden, Apex och API:er: För affärsprocesser som kräver stelt och oföränderligt utförande uppnås den högsta kontrollnivån genom deterministiska åtgärder. Genom att integrera agenter med flöden, Apex och API:er i Salesforce kan fördefinierade sekvenser utföras med precision, vilket eliminerar beroendet av användarindata eller LLM-indata för viktiga steg.

Genom att systematiskt tillämpa dessa kontrollager, från genomtänkt design och tydlig instruktion till datagrundning, tillståndshantering och deterministisk processautomatisering, kan utvecklare hantera utmaningarna med att skapa tillförlitliga agenter med enhetliga affärsresultat. Denna strategi säkerställer att Agentforce-agenter kan få förtroendet att utföra viktiga affärsfunktioner med den korrekthet och enhetlighet som krävs i företagslandskapet.