Agentforce-gids voor betrouwbaar agentisch gedrag

Olfa Kharrat, Director of Product Management - Agentforce
Reinier van Leuken, Senior Director of Product Management - Agentforce

Vertrouwen is de toonaangevende waarde bij Salesforce. Dat is al zo sinds de oprichting in 1999, toen we met cloud computing en SaaS nieuwe technologische modellen introduceerden. Bedrijven vertrouwen erop dat Salesforce hun waardevolle bedrijfsdata veilig opslaat in de cloud. Ze weten immers dat deze data wordt beschermd door de juiste toegangscontroles. Dat is nog altijd van cruciaal belang, maar in het tijdperk van agentische AI is de definitie van vertrouwen nog breder. Nu bedrijven steeds meer vertrouwen op autonome agents om kritieke bedrijfsfuncties uit te voeren, moeten deze agents vertrouwde zakenpartners zijn die nauwkeurig, relevant en vooral betrouwbaar werk verrichten.

Maar hoe bouw je een betrouwbare agent? Betrouwbaarheid betekent meestal dat een bepaalde input steeds tot hetzelfde resultaat leidt. Alleen werken agents soms anders, omdat ze worden aangestuurd door grote taalmodellen (LLM's) die van nature niet-deterministisch zijn. Dit geeft agents de flexibiliteit om creatieve oplossingen te ontwikkelen die zijn afgestemd op specifieke omstandigheden, zonder dat je elke omstandigheid of situatie expliciet hoeft te programmeren. Agents moeten echter worden beheerd om te voldoen aan zakelijke vereisten en operationele richtlijnen. Bij het uitvoeren van bedrijfsprocessen moeten ze aantoonbaar betrouwbaar zijn en bedrijfsresultaten produceren die voldoen aan deterministische beperkingen. Determinisme legt een rigiditeit en discipline op die botst met de autonomie en flexibiliteit die agents kunnen bieden. Om succesvolle agents te kunnen creëren, moet je dan ook de juiste balans vinden tussen creatieve flexibiliteit en zakelijke controle.

In dit document vind je belangrijke overwegingen voor het ontwikkelen van betrouwbare agents. Het omschrijft vijf niveaus van agentische controle en biedt best practices voor het verkrijgen en behouden van controle over agentisch gedrag voor elk van deze niveaus. Je krijgt ook uitleg over de manieren waarop de Agentforce-redeneringsengine werkt. Naarmate Agentforce verder wordt ontwikkeld, wordt dit document bijgewerkt met de nieuwste best practices.

Dit document gaat uit van een basiskennis van het ontwerpen en bouwen van Agentforce-agents. Voor een introductie tot Agentforce raden we het volgende aan:

• Bekijk de informatie op agentforce.com.
• Volg de trail Become an Agentblazer Champion . Deze trail introduceert de belangrijkste AI-concepten en helpt je bij het bouwen van een basisagent voor essentiële taken.
• Lees meer over Agentforce op help.salesforce.com , met name Design and Implement Agents . Deze leskaart begeleidt je bij alle belangrijke levenscyclusstappen, van het bedenken van je oplossing en het instellen en configureren van je agent, tot het testen, implementeren en monitoren.

Om agentisch gedrag beter te begrijpen, vergelijken we agents eerst met hun rigide tegenhangers: chatbots.

Chatbots: rigide regelvolgers

Chatbots volgen vooraf bepaalde beslisbomen die structureren aan welke dialogen ze kunnen deelnemen. Het doorlopen van deze beslisbomen is afhankelijk van de antwoorden die de gebruiker geeft. Dit antwoord kan een selectie zijn uit een vooraf bepaalde reeks opties of een vrij tekstantwoord. Bij een vrij tekstantwoord wordt een voorspellend model gebruikt om de intentie te classificeren. Deze bomen omvatten alle mogelijke gesprekstrajecten en dicteren de antwoorden van de chatbot bij elke stap. Het gedrag van de chatbot wordt volledig bepaald door vooraf ingestelde regels. Als de input van een gebruiker niet overeenkomt met een herkend pad of als het voorspellende model niet is getraind om een bepaalde intentie te herkennen, kan de chatbot niet correct reageren.

Agents: flexibel en intuïtief

Agents daarentegen maken gebruik van de kracht van LLM's en hun geavanceerde mogelijkheden op het gebied van natuurlijke-taalverwerking (NLP). LLM's stellen agents in staat om de intentie achter de input van een gebruiker te begrijpen, zelfs als deze op een onverwachte manier wordt geformuleerd. Op basis van zijn begrip van de intentie kan de agent de meest geschikte actie uit een reeks mogelijkheden selecteren. Een agent kan zelfs geheel nieuwe antwoorden formuleren. Deze flexibiliteit en dit aanpassingsvermogen onderscheiden agents van chatbots.

Een culinaire analogie

Je kunt het onderscheid tussen chatbots en agents vergelijken met het verschil tussen een beginnende kok en een doorgewinterde chef-kok.

• De beginnende kok (chatbot) vertrouwt volledig op een gedetailleerd recept met exacte hoeveelheden, stapsgewijze instructies en specifieke kooktijden. Elke afwijking van het recept leidt tot een rampzalig gerecht. Op dezelfde manier moet een chatbot functioneren binnen de grenzen van zijn voorgeprogrammeerde beslisboom.
• Doorgewinterde chef-koks (agents) profiteren van een jarenlange ervaring en hun intuïtie. Omdat ze in grote lijnen weten wat je voorkeuren zijn, kunnen ze aan de hand van een korte beschrijving van de ingrediënten een heerlijke maaltijd bereiden die voldoet aan je behoeften. De exacte stappen kunnen elke keer variëren en het gerecht kan verschillende varianten hebben, maar het resultaat is altijd bevredigend. Ook kan een agent zijn aanpak aanpassen op basis van de context en intentie van de input van de gebruiker, wat resulteert in een succesvolle interactie.

Kortom: het fundamentele verschil met chatbots is dat agents zich kunnen aanpassen en om kunnen gaan met onverwachte input.

Een onderscheidend kenmerk van de intelligentie van een agent is het vermogen om de meest geschikte acties op het juiste moment te vinden en te activeren. Door deze flexibiliteit is het niet nodig om elke mogelijke gebruikersinteractie tot in detail te programmeren.

Het bouwen van een agent in Agentforce bestaat uit onderwerpen, acties, en instructies en beschrijvingen in natuurlijke taal.

Onderwerpen

Onderwerpen zijn de taken die moeten worden uitgevoerd door de agent. Onderwerpen hebben kenmerken zoals een classificatiebeschrijving, bereik en instructies die elke taak en het uitvoeren ervan definiëren. Onderwerpen bevatten acties die de agent kan uitvoeren, samen met instructies die bepalen op welke manier deze acties worden uitgevoerd.

Acties

Acties zijn de vooraf gedefinieerde taken die de agent kan uitvoeren om zijn taak te voltooien. Er zijn vijf verschillende soorten acties:

• voer Apex-code uit
• roep een API aan
• voer een stroom uit
• krijg een LLM-antwoord op een taakaanwijzingssjabloon
• roep een voorspellend model aan

Instructies en beschrijvingen in natuurlijke taal

De definitie van een agent bevat instructies in natuurlijke taal die de activa van de agent beschrijven en de richtlijnen definiëren waarbinnen de agent moet werken. Er worden instructies geschreven voor acties en onderwerpen.

• Acties. Een actie bevat:
  • instructies die beschrijven wat de actie doet, zodat de redeneringsengine weet wanneer deze actie moet worden uitgevoerd.
  • inputs met een beschrijving in natuurlijke taal, zodat de agent ze kan voorbereiden.
  • outputs met een beschrijving in natuurlijke taal van format en gebruik.
• Onderwerp. Een onderwerp bevat instructies die bepalen hoe acties op een hoger niveau moeten worden uitgevoerd. Instructies kunnen bijvoorbeeld kaders specificeren voor de tone of voice, de gewenste volgorde van acties, mogelijke voorwaarden of wanneer gesprekken naar mensen moeten worden doorgezet. Het onderwerp bevat ook een classificatiebeschrijving en een afbakening van het bereik. Al deze onderdelen zorgen ervoor dat de agent binnen het bereik van de gedefinieerde rol blijft en de taak uitvoert.
• Data. Agents hebben data nodig om hun taken te kunnen uitvoeren. Data kan gestructureerd (zoals CRM-data) of ongestructureerd (zoals knowledge-base-artikelen van het bedrijf) zijn. Agents hebben toegang tot data via actie-inputs. Een actie kan bijvoorbeeld een taakaanwijzingssjabloon aanroepen dat is gebaseerd op CRM-data of is verrijkt met stukjes ongestructureerde data met behulp van RAG-technieken.

Als agents bestaan uit de correcte bouwstenen, kunnen ze het beoogde doel bereiken en binnen de juiste grenzen werken.

De redeneringsengine van Agentforce beheert deze bouwstenen en zorgt zo voor het juiste agentische gedrag. Hij maakt gebruik van de instructies en beschrijvingen in natuurlijke taal die zijn gedefinieerd in de onderwerpen en de acties. De engine is gebouwd op ReAct, een nieuw redeneringsparadigma voor LLM's dat in 2022 werd geïntroduceerd door Yao et al. Dit paradigma bootst het taakbeheer door mensen na door te redeneren over een probleem, actie te ondernemen, de resultaten van de actie te observeren en de cyclus te herhalen totdat de taak is voltooid.

Salesforce-agents houden zich aan dit paradigma:

1. Redeneren: Begrijp de intentie van de gebruiker en stem deze af op het juiste onderwerp en de juiste actie(s).
2. Actie uitvoeren: Start de juiste actiereeks.
3. Observeren: Beoordeel de resultaten van de acties op basis van de intentie van de gebruiker. Als de intentie niet wordt vervuld, redeneer dan verder op basis van het tot nu toe verkregen resultaat en van de instructies en beschrijvingen van onderwerp/actie. Als aan de intentie is voldaan, geef dan het definitieve antwoord en houd je aan eventuele opmaakinstructies.
4. Herhalen: Herhaal deze stappen totdat de laatste stap in de instructies is bereikt.

De redeneringsengine gebruikt LLM's voor elke redenerings- en observatiestap. Afhankelijk van het actietype kan het ook LLM's gebruiken in de stap 'Actie uitvoeren'.

Dit gedeelte beschrijft een gelaagde aanpak om het determinisme van agents te verbeteren. Elk niveau bouwt voort op het vorige, met toenemende complexiteit en mogelijkheden die je meer controle over het gedrag van de agent geven.

Het eerste niveau richt zich op het zelfstandig identificeren van relevante onderwerpen, waarna de juiste acties worden geselecteerd op basis van doelen in plaats van expliciete instructies. Het kernmechanisme omvat het gebruik van een contextueel begrip om te reageren op input van gebruikers. Hoewel technisch gezien elk type actie kan worden toegevoegd, gaan we er op dit niveau vanuit dat de acties taakaanwijzingsacties zijn. Instructievrije onderwerpen met taakaanwijzingsacties zorgen voor een snelle en efficiënte afhandeling van veelvoorkomende vragen.

Op dit niveau ligt de nadruk op het vaststellen van een basisniveau van responsiviteit en autonomie van agents door middel van een dynamisch begrip.

Dit niveau bouwt voort op de basis van de instructievrije actieselectie en voegt expliciete instructies toe om het gedrag van agents te bepalen. Het toevoegen van nauwkeurige instructies geeft je meer controle over de manier waarop agents reageren op verschillende situaties. Instructies voor agents kunnen worden uitgedrukt als regels, richtlijnen, vangrails en voorbeelden. Deze geven de agent specifieke instructies voor het omgaan met verschillende onderwerpen, het uitvoeren van acties en het verwerken van hun output. Op dit niveau krijgt de agent een duidelijke sturing om de consistentie te vergroten en de naleving van bedrijfsrichtlijnen en -processen te verbeteren.

Grounding betekent dat het begrip en de antwoorden van de agent worden gebaseerd op externe kennisbronnen. Dankzij grounding is de informatie die door de agent wordt verstrekt nauwkeuriger, actueler en relevanter. Dit niveau integreert de toegang tot databases, knowledge bases en andere informatiebronnen. Omdat de antwoorden van de agent zijn gebaseerd op geverifieerde data, zijn ze betrouwbaarder.

Op dit niveau kunnen agents met variabelen werken. Met variabelen kunnen agents interacties personaliseren, context onthouden tijdens verschillende interacties en hun gedrag dynamisch aanpassen op basis van specifieke datapunten tijdens de agentsessie. Een agent kan bijvoorbeeld gebruikersvoorkeuren, orderdata en andere relevante informatie vastleggen en die data vervolgens gebruiken voor een interactie op maat. Met variabelen zijn agents beter in staat om complexere, meer voorgeschreven en meer gepersonaliseerde interacties te verzorgen.

De laatste stap integreert de agent met de kernfuncties van Salesforce: Apex, API's en stromen. Deze integratie stelt de agent in staat om complexe acties uit te voeren binnen het Salesforce-ecosysteem, zoals het openen en aanpassen van data, het activeren van workflows en interactie met andere systemen.

• Apex levert programmatische controle.
• API's zorgen voor naadloze integratie met andere applicaties.
• Stromen maken de automatisering van complexe bedrijfsprocessen mogelijk.

Dit niveau maakt van de agent een krachtige tool die geavanceerde taken kan uitvoeren en direct kan bijdragen aan de bedrijfsresultaten.

Deze agent bestaat uitsluitend uit onderwerpen en acties met de bijbehorende beschrijvingen. Dit is de ondergrens van reactievermogen en autonomie. Aan de hand van deze voorbeeldagent kunnen we de verschillende stappen van de redeneringsengine introduceren en laten zien hoe hij deze beschrijvingen gebruikt om de juiste onderwerpen te selecteren en vervolgens acties uit te voeren. Door de onderwerpinstructies uit dit voorbeeld weg te laten, zien we dat agents op dit eerste niveau de grootste mate van vrijheid hebben in vergelijking met agents op hogere niveaus. Op niveau 1 kan de agent in volledige vrijheid de actie selecteren die hij geschikt acht, uitsluitend op basis van het lopende gesprek.

Belangrijke overwegingen met betrekking tot de redeneringsengine:

• De configuratie-instellingen liggen vast voor de LLM van de redeneringsengine. Agentbuilders kunnen deze niet aanpassen. Momenteel worden OpenAI LLM's gebruikt voor de redeneringscapaciteiten. Dit kan echter veranderen naarmate er meer modellen worden toegevoegd.
• Standaardgeschiedenis van de redeneringsengine: Wanneer een verzoek wordt gedaan aan de redeneringsengine (stap 2-5), haalt deze automatisch de geschiedenis van de meest recente verzoeken en antwoorden op. Dit zorgt voor de gesprekscontext van de redeneringsengine. Naast klantinteracties omvatten deze aanroepen naar het planner-LLM ook aanroepen naar het redeneringsengine-LLM voor andere verzoeken, zoals onderwerpselectie.

Het redeneringsproces omvat vier stappen:

1. Onderwerpselectie
2. Actieselectie
3. Agentische lus
4. Groundingcontrole

Onderwerpen zijn ontworpen om de nauwkeurigheid te verbeteren waarmee agents de juiste actie of volgorde van acties classificeren. Elk onderwerp moet bestaan uit semantisch afzonderlijke acties die allemaal tot een beknopte onderwerpbeschrijving en dus tot een vergelijkbare agentfunctie kunnen behoren.

Het juiste onderwerp wordt geselecteerd door het redeneringsengine-LLM (stap 2-3 van het diagram). Dit selecteert het onderwerp waarvan de classificatiebeschrijving het meest overeenkomt met de laatste uiting, met behulp van een onderwerptaakaanwijzing. Deze taakaanwijzing bevat de classificatiebeschrijvingen van alle onderwerpen en de gespreksgeschiedenis. Naast uitingen en antwoorden van agents omvat de gespreksgeschiedenis ook de uitgevoerde acties en hun resultaten. Bovendien bevat de taakaanwijzing cruciale instructies die analyse binnen de context van de gespreksgeschiedenis mogelijk maken en vereisen dat het LLM zijn denkproces deelt.

Aanvullende overwegingen:

• Naast de zichtbare onderwerpen wordt er automatisch een extra verborgen onderwerp toegevoegd voor 'off topic'-uitingen. Dit onderwerp wordt geselecteerd als er geen ander bestaand onderwerp overeenkomt met de uiting. Hiermee kunnen agents onjuiste classificatie voorkomen. Dit onderwerp heeft geen acties. Het bestaat alleen om de redeneringsengine te helpen later een passend antwoord te formuleren.
• Alleen de naam en de classificatiebeschrijving van het onderwerp worden gebruikt in de onderwerptaakaanwijzing.
• Het redeneringsengine-LLM kan slechts één onderwerp tegelijk kiezen.
• Gesprekken kunnen onverwacht een andere wending nemen. Wanneer een uiting wordt ontvangen, gaat de redeneringsengine verder naar de selectie van het onderwerp, wat betekent dat bij elke nieuwe uiting een nieuw onderwerp kan worden gekozen.

Het doel van onderwerpen is tweeledig:

1. Verminderen van het risico dat de redeneringsengine verward raakt door acties te groeperen. Dit voorkomt dat de engine de verkeerde acties selecteert.
2. De selectie en het uitvoeren van acties sturen met instructies (meer hierover bij niveau 2: Agentische controle: instructies toevoegen).

Door de capaciteiten van agents zorgvuldig te organiseren in duidelijk gedefinieerde onderwerpen die bestaan uit gerelateerde acties, worden ze effectiever en voorspelbaarder en is het gemakkelijker om ze te updaten en uit te breiden. Er zijn twee benaderingen voor het ontwerpen van onderwerpen: top-down en bottom-up.

• In de top-down-benadering worden onderwerpen eerst ontworpen als taken op hoog niveau die door de agent moeten worden uitgevoerd. Vervolgens worden de individuele acties voor die onderwerpen gedefinieerd.
• In de bottom-up-benadering worden eerst alle individuele acties gedefinieerd, om ze vervolgens te groeperen op onderwerp.

Beide benaderingen leiden tot goede resultaten als ze goed worden uitgevoerd.

Bottom-up-benadering

In dit gedeelte wordt de bottom-up-benadering behandeld, omdat deze nauw aansluit bij de redenen waarom de redeneringsengine onderwerpen nodig heeft.

Stap 1: maak een lijst van alle agentische acties

Maak eerst een lijst van alle specifieke acties die de agent moet kunnen uitvoeren. In dit stadium moet je het niet te algemeen houden en kun je beter heel specifiek zijn. Probeer acties niet te snel te groeperen of te vereenvoudigen. Het doel is om een uitgebreid en gedetailleerd beeld te creëren van waar de agent toe in staat is.

Voor een klantenservicemedewerker kan de eerste lijst bijvoorbeeld het volgende bevatten:

• Een bestelling retourneren: wordt gebruikt om het retourproces voor een bestelling te starten.
• Beschikbaarheid uit voorraad controleren: wordt gebruikt om te controleren of een product op voorraad is.
• Beleid voor productomruiling controleren: wordt gebruikt om informatie over omruilbeleid op te halen.
• Vragen beantwoorden op basis van kennis: wordt gebruikt om algemene of FAQ-achtige vragen te beantwoorden.
• Controleren op promoties: wordt gebruikt om te controleren op beschikbare promoties of kortingen.
• Leverdatum voorspellen: wordt gebruikt om de verwachte leverdatum/-tijd te schatten.
• Orderstatus controleren: wordt gebruikt om de huidige status van de bestelling van een klant te achterhalen.
• Klantorders zoeken: wordt gebruikt om alle eerdere of actieve bestellingen van een specifieke klant op te halen.
• Technische problemen oplossen: wordt gebruikt om technische problemen met een product of service op te lossen.
• Voorwaarden zoeken voor klantorders: wordt gebruikt om alle voorwaarden op te halen met betrekking tot een bestelling.
• Klantactiva vinden: wordt gebruikt om activa te identificeren of op te halen met betrekking tot een klant.
• Het bezorgadres wijzigen.

Denk eraan dat een actie als 'klachten van klanten oplossen' in dit stadium te breed is. Acties moeten volgen uit een zo gedetailleerd mogelijk omschreven gedrag van agents. Er kunnen veel verschillende soorten klachten zijn en verschillende acties voorzien hier al in:

• Problemen na bezorging - zoals het oplossen van problemen met beschadigde of slecht werkende producten - worden al behandeld door 'Technische problemen oplossen'.
• Problemen voorafgaand aan de bezorging - zoals niet-plaatsgevonden bezorgingen, het wijzigen van leverdata of het aanpassen van bestellingen - worden al behandeld door acties zoals 'Orderstatus controleren', 'Leverdatum voorspellen' of 'Een bestelling retourneren'.
• Algemene vragen van klanten - zoals vragen over het beleid - worden al behandeld in 'Vragen beantwoorden op basis van kennis' of 'Beleid voor productomruiling controleren'.

Stap 2: markeer actieparen (of veelvouden) die mogelijk verwarring bij de redenering veroorzaken

Markeer acties die van zichzelf vergelijkbaar zijn, omdat deze voor verwarring kunnen zorgen bij de redeneringsengine. De semantische verschillen in hun beschrijvingen zijn niet duidelijk genoeg. Daardoor weet de redeneringsengine niet welke actie moet worden geselecteerd in stap 5.

'Technische problemen oplossen' en 'Vragen beantwoorden op basis van kennis' hebben bijvoorbeeld vergelijkbare beschrijvingen, maar hun functionaliteit kan aanzienlijk verschillen. Het markeren van dergelijke semantische overlappingen helpt bij het identificeren van acties voor verschillende onderwerpen.

Stap 3: groepeer acties in voorlopige onderwerpen

Zodra acties duidelijk zijn gedefinieerd en hun semantische overlappingen zijn geïdentificeerd, kunnen acties worden gegroepeerd in voorlopige onderwerpen. Een onderwerp is een logische functiecategorie, een groepering van acties die samen een samenhangende capaciteit of vaardigheid van de agent vertegenwoordigen.

Let op het volgende bij het maken van deze groepen:

• Vermijd semantische overlapping door het minimale aantal benodigde onderwerpen te gebruiken.
• Zorg ervoor dat elk onderwerp daadwerkelijk gerelateerde acties bevat.
• Zorg ervoor dat ondersteunende acties die in een reeks moeten worden uitgevoerd in hetzelfde onderwerp voorkomen.

Hier is een voorbeeld van een voorlopige groepering voor een klantenservicemedewerker:

Onderwerp 1:

• Retourneer een bestelling
• Controleer de voorraad
• Controleer het beleid voor productomruiling
• Bekijk promoties
• Voorspel de leverdatum
• Zoek voorwaarden voor klantorders
• Controleer de orderstatus
• Vind bestellingen van klanten
• Vind activa van klanten
• Beantwoord vragen op basis van kennis
• Wijzig het bezorgadres

Onderwerp 2:

• Los technische problemen op
• Vind activa van klanten

Stap 4: schrijf classificatiebeschrijvingen voor onderwerpen en deel onderwerpen zo nodig op

Zodra je de voorlopige groepering hebt gemaakt, schrijf je classificatiebeschrijvingen voor elk onderwerp.

• Onderwerp 2 in ons voorbeeld gaat duidelijk over technische problemen met producten.
• Onderwerp 1 heeft echter een breder spectrum. Het gaat voornamelijk over orderbeheer, maar bevat ook enkele acties die hier geen verband mee houden, zoals het controleren op promoties en het beantwoorden van vragen op basis van kennis. Onderwerp 1 kan niet duidelijk en beknopt in één zin worden beschreven. Daarom moet het worden opgesplitst in verschillende onderwerpen.

Na deze verfijning is dit het resultaat:

• Onderwerp 1: orderbeheer: Beschrijft acties met betrekking tot het beheren en wijzigen van klantorders en gerelateerde logistiek, behalve alles wat verband houdt met omruiling en retourzending.
  • Controleer de voorraad: bepaal of een product op voorraad is.
  • Voorspel de leverdatum: schat wanneer een bestelling aankomt.
  • Controleer de orderstatus: vind de status van de bestelling van een klant.
  • Vind bestellingen van klanten: haal alle bestellingen op die door een klant zijn geplaatst.
  • Wijzig het bezorgadres:
• Onderwerp 2: problemen oplossen
  • Vind activa van klanten: haal de geregistreerde apparaten of producten van de klant op.
  • Los technische problemen op: bied technische ondersteuning of diagnostiek.
• Onderwerp 3: omruiling: Beschrijft acties met betrekking tot het omruilen en retourneren van bestellingen.
  • Retourneer een bestelling: start het retourproces voor bestellingen.
  • Controleer het beleid voor productomruiling: geef de omruilingsregels voor producten.
  • Vind bestellingen van klanten: haal alle bestellingen op die door een klant zijn geplaatst.
  • Voorwaarden zoeken voor klantorders: haal alle voorwaarden op met betrekking tot een bestelling.
• Onderwerp 4: productondersteuning: Beschrijft transversale acties die worden gebruikt voor het ophalen en doorsturen van informatie.
  • Beantwoord vragen op basis van kennis: reageer op algemene vragen van klanten met behulp van informatie uit de knowledge base.
  • Bekijk promoties: bekijk huidige promoties of kortingen.

Dus samengevat: maak eerst een uitgebreide lijst van alle mogelijke acties en markeer vervolgens semantische overlapping tussen deze acties. Maak vervolgens een set onderwerpen die minimaal alle semantische overlappingen oplost (zodat de redeneringsengine niet in de war raakt bij de afhandeling van één onderwerp). Schrijf vervolgens de classificatiebeschrijving van elk onderwerp. Als de onderwerpen te breed zijn geformuleerd, verdeel ze dan in meer gedetailleerde onderwerpen. Door deze richtlijnen te implementeren, bouw je een agent die niet alleen goed presteert, maar ook gemakkelijk te onderhouden en uit te breiden is.

Deze structuur zorgt voor een betere redenering, een nauwkeurigere uitvoering en duidelijkere beslissingsgrenzen binnen het gedrag van de agent. Ook de samenwerking tussen ontwerpers, engineers en experts op het gebied van de betreffende onderwerpen is belangrijk. Zo maak je de agent transparanter en modulair.

Verdere overwegingen voor het effectief creëren van onderwerpen

• Optimaal aantal onderwerpen: Om ervoor te zorgen dat LLM's het juiste onderwerp beter classificeren, is het over het algemeen raadzaam om niet meer dan tien onderwerpen te hebben. Dit is echter maar een vuistregel. Bovendien moet elk onderwerp een duidelijke en onderscheidende beschrijving hebben. Uiteindelijk hangt het optimale aantal onderwerpen af van het semantische verschil tussen de classificatiebeschrijvingen van de onderwerpen. Als de onderwerpen erg verschillende classificatiebeschrijvingen hebben, is het risico op overlappingen van onderwerpen veel minder groot. Hier vind je meer best practices om overlapping tussen onderwerpen te voorkomen.
• Balans tussen omvang en duidelijkheid van onderwerpen: Over het algemeen is het beter om acties en instructies onder te verdelen in kleinere onderwerpen, omdat dit de classificatie eenvoudiger maakt. Toch kan het creëren van te veel onderwerpen met zeer vergelijkbare beschrijvingen tot verwarring leiden, net zoals semantische overlapping tussen acties leidt tot een onjuiste classificatie. Daarom zijn duidelijke, semantisch gedifferentieerde onderwerpbeschrijvingen van groot belang. Je kunt LLM's gebruiken om je te helpen bij het maken van deze goed gedifferentieerde classificaties.
• Standaardtaal en contextuele duidelijkheid: LLM's herkennen mogelijk geen specifieke zakelijke definities en afkortingen. Gebruik dus standaardtaal of wees zeer expliciet bij het uitleggen van de betekenissen van woorden binnen je specifieke context.
• Alleen de onderwerptitel en -beschrijving worden in de onderwerptaakaanwijzing verzonden. Daarom heeft het wijzigen van het bereik of de instructies van het onderwerp geen invloed op de selectie van het onderwerp.

Praktijkvoorbeeld

Stel je voor dat een klantenservicemedewerker een vraag krijgt over de garantiebepalingen van een horloge. De garantiekwestie lijkt geen verband te houden met het omruilen of de support van het product. Orderbeheer lijkt het meest geschikte onderwerp om aan dit verzoek te voldoen. Daarom wordt dit onderwerp door de redeneringsengine gekozen als het meest waarschijnlijke dat aan het verzoek kan voldoen.

Na de onderwerpselectie selecteert de redeneringsengine de juiste acties voor het gekozen onderwerp. Nogmaals: het redeneringsengine-LLM is hiervoor verantwoordelijk, waarbij deze gebruikmaakt van de observatietaakaanwijzing. Het doel van de observatietaakaanwijzing is om de volgende stap in het redeneringsproces te verkrijgen. Deze stap kan een van de volgende zijn:

• Een actie starten
• Vragen om actie-inputs aan van de gebruiker
• Vragen om een toelichting op het verzoek van de gebruiker
• Verzenden van het definitieve antwoord naar de gebruiker (waarbij aan het verzoek van de gebruiker wordt voldaan) zodra de actielus is voltooid (zie voor meer informatie redeneringsstap 3)

De input voor de observatietaakaanwijzing wordt gevormd door alle beschrijvingen van alle acties voor het onderwerp, evenals de gespreksgeschiedenis.

Best practices voor actieontwerp

Acties zijn de vooraf gedefinieerde taken die de agent kan uitvoeren om aan een verzoek te voldoen. Acties zijn de meest verfijnde definities van werk. Er zijn vijf verschillende soorten agent-acties: (1) Apex-code uitvoeren, (2) een API aanroepen, (3) een stroom uitvoeren, (4) een LLM-antwoord krijgen op een taakaanwijzingssjabloon en (5) een voorspellend model aanroepen. De meeste van deze acties kunnen deterministisch zijn. Een uitzondering is het krijgen van een antwoord op een taakaanwijzingssjabloon (op voorwaarde dat het externe systeem, de stroom- of de Apex-actie geen probabilistische elementen bevat, zoals het aanroepen van taakaanwijzingen). We behandelen deze kwesties in het gedeelte over het vijfde niveau van agentische controle.

1. Agentisch gedrag controleren bij taakaanwijzingsacties. Er zijn twee manieren om controle uit te oefenen over het agentisch gedrag bij taakaanwijzingsacties: (1) voeg meer instructies toe aan het taakaanwijzingssjabloon via engineering van taakaanwijzingen en (2) configureer de hyperparameters van het LLM dat de taakaanwijzingsreactie genereert, met name de temperatuur (zie documentatie ). Het verlagen van de temperatuur vermindert de variabiliteit in de gegenereerde reacties, wat de herhaalbaarheid en betrouwbaarheid van agents verhoogt.
2. Optimaal aantal acties binnen één onderwerp:: Net als bij het maximum aantal onderwerpen mag het aantal acties binnen een onderwerp in principe niet groter zijn dan tien. Maar nogmaals, dit is slechts een vuistregel. Het wordt voornamelijk bepaald door het semantische verschil tussen de acties. Wanneer acties duidelijk te onderscheiden zijn door hun beschrijving, kan dit aantal groter zijn. Er is echter geen numerieke meting voor semantische verschillen. Dit is aan de interpretatie van de Agentbuilder. Hoe groter het verschil in betekenis tussen de actiebeschrijvingen, hoe groter het semantische verschil. Overlapping moet hier hoe dan ook worden vermeden.
3. Actiebeschrijvingen: In tegenstelling tot wat de naam suggereert, is de 'actie-instructie' eigenlijk een instructie die het redeneringsengine-LLM gebruikt om de juiste actie voor het onderwerp te selecteren. Merk op dat het gebruik van semantisch verschillende actiebeschrijvingen de kwaliteit van hun classificaties aanzienlijk kan verbeteren. Lees deze beschrijvingen zorgvuldig en vergelijk vooral alle actiebeschrijvingen die bij één onderwerp horen.

Praktijkvoorbeeld

Laten we verdergaan met het eerder genoemde voorbeeld, waarin een klantenservicemedewerker een vraag krijgt over de garantiebepalingen van een horloge. Na het selecteren van het onderwerp Orderbeheer wordt de meest waarschijnlijke actie gekozen. Omdat dit over orderbeheer gaat, is de eerste logische stap het opzoeken van de bestelling (waar moet je anders garantiebepalingen voor ophalen?) door de actie 'zoeken naar bestellingen' te starten.

Een uiting van een gebruiker kan de uitvoering van meerdere acties activeren voordat een antwoord naar de gebruiker wordt gestuurd. Dit komt door de agentische lus, die de meest geschikte vervolgactie blijft selecteren en uitvoeren tot er aan een van de volgende voorwaarden is voldaan:

• Het redeneringsengine-LLM bepaalt dat het verzoek is afgehandeld. In dit geval concludeert het dat aan het verzoek van de gebruiker is voldaan. Een deel van deze controle betreft een groundingcontrole, waarbij wordt geverifieerd dat het antwoord is gebaseerd op de actie-outputs. Het redeneringsengine-LLM mag zelf geen informatie bedenken voor het antwoord, omdat dit kan leiden tot hallucinaties of anderszins onjuiste antwoorden.
• Er zijn geen geschikte acties meer gevonden.
• Het maximaal toegestane aantal LLM-aanroepen voor de huidige stap is bereikt. Dit aantal wordt bepaald door de redeneringsengine zelf.

Acties zijn niet onderhevig aan een specifieke time-out. Zo wordt onderbreking voorkomen wanneer de uitvoeringsduur van acties variëren op basis van hun complexiteit. Sommige acties zijn nu eenmaal complexer om uit te voeren dan andere.

Praktijkvoorbeeld

Na het starten van het opzoeken van een bestelling beoordeelt de redeneringsengine het tot nu toe gegenereerde antwoord. Vervolgens besluit deze dat hij meer werk moet doen voordat een antwoord naar de gebruiker kan worden gestuurd. Nu de bestelling aanwezig is in de gespreksgeschiedenis, gaat de engine de garantiebepalingen opzoeken.

Daarbij realiseert de agent zich echter dat de klant twee horloges heeft gekocht, zoals blijkt uit het resultaat van de actie 'zoeken naar bestellingen'. Daarom besluit de redeneringsengine in de agentische lus om de klant te vragen voor welk horloge hij de garantiebepalingen nodig heeft.

Vermijd te gedetailleerde beschrijvingen

Vermijd te gedetailleerde beschrijvingen van de manieren waarop agents gesprekken met gebruikers moeten voeren. Te gedetailleerde beschrijvingen tasten het vermogen van een agent aan om een relatie op te bouwen, unieke gebruikersbehoeften te begrijpen en in realtime effectief te reageren op dynamische omstandigheden. Bovendien kunnen lange instructies de agent trager laten reageren en de redeneringsengine in verwarring brengen. Het forceren van determinisme via instructies heeft niet de voorkeur.

Wat je niet moet doen

Het is bijvoorbeeld niet nodig om een agent te vertellen dat deze niet naar concurrenten moet verwijzen bij antwoorden voor de klantenservice. Dit kan leiden tot ongewenst gedrag, omdat de agent dan ook kan weigeren vragen te beantwoorden over integratie met een aanbieder die ook een concurrent is. In plaats daarvan kan de instructie zoiets zijn als "houd bij het bespreken van concurrenten het belang van het bedrijf in gedachten". Dit voorkomt beperkende, voorwaardelijke instructies zoals "vermeld alleen concurrent xyz in het geval van…" en maakt in plaats daarvan gebruik van de redeneringsmogelijkheden van het LLM. Dit voorbeeld laat zien hoe instructies kunnen worden gegeven op een hoger, meer abstract niveau. Dit is vergelijkbaar met de manier waarop nieuwe menselijke klantenservicemedewerkers worden getraind.

Laten we eens kijken naar meer voorbeelden van wat je niet moet doen. Dit zijn enkele slechte instructies aan een serviceagent die kandidaatprofielen verwerkt op een wervingswebsite. Deze instructies proberen te anticiperen op elke mogelijke uiting van de klant en moeten daarom worden vermeden:

Instructie 1: De agent ontvangt de volgende uiting: "Kan ik een foto toevoegen aan mijn profiel?". Vraag de klant dan direct: "Wat is je profieltype?"

Instructie 2: Als de klant aangeeft een premiumprofiel te hebben, antwoord dan "Ik zal je contractgegevens controleren", zoek dan naar contractgegevens en controleer of is overeengekomen dat de klant de profielfoto kan aanpassen.

Als is overeengekomen dat de kandidaat dit mag doen, antwoord dan: "Ja, dat is mogelijk, ik zal het voor je aanpassen. Kun je me je nieuwe foto geven?" Zodra de foto is ontvangen, pas je het profiel van de kandidaat aan. Als het contract niet voorziet in het aanpassen van de profielfoto, zeg je: "Sorry, dit is niet mogelijk. Ik breng je in contact met een menselijke medewerker”

Instructie 3: Zonder premiumprofiel: Als de klant aangeeft geen premiumprofiel te hebben, antwoord je: "Je kunt je foto niet aanpassen. Als je wilt, kan ik je in contact brengen met een menselijke medewerker."

Instructie 4: Als het niet duidelijk is welk profiel de klant heeft, antwoord je: "Ik heb niet begrepen wat je profieltype is."

Wat je wel moet doen

Gebruik in plaats van dit soort gedetailleerde instructies meer flexibele richtlijnen voor de agent. Overweeg de volgende best practices:

1. Gebruik RAG-/kennisacties voor beleid en regels die in knowledge-base-artikelen staan (in plaats van ze als instructies te omschrijven). De relevante informatie wordt dan op het juiste moment opgehaald. Voor het bovenstaande voorbeeld betekent dit dat in een knowledge-base-artikel met de titel 'Foto aanpassen' het volgende moet staan: "Alleen kandidaten met een premiumprofiel waarvan het contract voorziet in het aanpassen van foto's kunnen hun foto aanpassen".
2. Schets de belangrijkste richtlijnen en vangrails afzonderlijk, onafhankelijk van het gesprek. Geef agents een duidelijke en beknopte uitleg van het verwachte gedrag of de verwachte procedure.

Op basis van deze best practices kan een betere set instructies er als volgt uitzien:

Instructie 1 : "Gebruik knowledge-base-acties om het beleid te controleren bij verzoeken om accountaanpassingen".

Instructie 2 : "Beantwoord geen vragen waarvoor geen toepasselijk beleid kon worden gevonden".

Het toepassen van de bovenstaande richtlijnen kan de resultaten van agents verbeteren. Als de klant de agent nu om een profielaanpassing vraagt, zal de agent begrijpen dat hij het vereiste beleid uit de knowledge base moet ophalen, de opgehaalde regels moet interpreteren, deze regels moet toepassen op de context en ten slotte op de klant moet reageren. In tegenstelling tot de te gedetailleerde beschrijvingen is deze gedragsaanpak veel algemener en breder toepasbaar. Als je niet elk mogelijk gesprek helemaal uitschrijft, kan de agent flexibel reageren met het gewenste gedrag op een breder scala aan gespreksonderwerpen.

Een actievolgorde afdwingen

De observatietaakaanwijzing bevat instructies en actiebeschrijvingen, alleen niet in een vastgestelde volgorde. Als de volgorde van acties van essentieel belang is, moet dit expliciet in dezelfde instructie worden vermeld.

Laten we verder gaan met het voorbeeld van agents op een wervingswebsite. De agent moet in staat zijn om sollicitatiegesprekken met de juiste recruiters te plannen. Hiertoe moet de agent eerst de beschikbaarheid van de recruiters controleren en vervolgens drie mogelijke tijdstippen voorstellen aan de kandidaat.

Om de volgorde van uitvoering te garanderen, mogen de instructies in dit geval niet in aparte segmenten staan:

1. Instructie 1: Controleer de beschikbaarheid van recruiters.
2. Instructie 2: Stel vervolgens passende tijdstippen voor aan de kandidaat.

Deze instructies werken niet omdat de redeneringsengine niet weet waar 'vervolgens' in instructie 2 naar verwijst. Dit komt doordat de instructies als groep naar de redeneringsengine worden gestuurd en niet in een bepaalde volgorde.

In plaats daarvan moeten sequentiedefiniërende instructies worden samengevoegd tot één omschrijving:

1. Instructie 1: Controleer de beschikbaarheid van recruiters. Stel vervolgens passende tijdstippen voor aan de kandidaat.

Output van acties afdwingen zonder te herschrijven

De redeneringsengine is zelf een LLM. Hij is verantwoordelijk voor het genereren van het definitieve antwoord op basis van de agentische lus. De aanpak is nodig om agent-instructies af te dwingen die vangrails bieden voor het genereren van antwoorden, of om te komen tot gecombineerde outputs van meerdere acties die deel uitmaakten van de agentische lus. Dit is noodzakelijk om aan het gebruikersverzoek te voldoen.

Wanneer echter wordt verwacht dat er slechts één taakaanwijzingsactie is uitgevoerd, kan een instructie worden geïmplementeerd om de agent te instrueren om nooit de output van een actie te wijzigen. Dit zorgt voor voorspelbaarder en betrouwbaarder agentisch gedrag.

Het afdwingen van deze strikte gebondenheid aan goedgekeurde taakaanwijzingssjablonen is van cruciaal belang in bepaalde scenario's, vooral wanneer consistentie, naleving en vooraf gedefinieerde berichten belangrijk zijn. Dit zijn twee voorbeelden:

• Gereguleerde sectoren: Organisaties die actief zijn in sterk gereguleerde sectoren (zoals de financiële sector, de gezondheidszorg of de juridische sector) hebben vaak strikte controle nodig over alle klantgerichte communicatie. Goedgekeurde taakaanwijzingssjablonen zorgen ervoor dat antwoorden voldoen aan wetten en regelgeving, waardoor het risico op verkeerde interpretatie, aansprakelijkheid of verspreiding van onnauwkeurige informatie wordt geminimaliseerd.
• Vooraf geteste en gevalideerde antwoorden: Wanneer taakaanwijzingssjablonen strenge tests en validatie hebben ondergaan om nauwkeurigheid, effectiviteit en gewenste resultaten te garanderen. Het afwijken van deze templates kan hun effectiviteit en waarde ondermijnen. Strikte naleving garandeert dat de beproefde boodschap consistent wordt geleverd.

Deze instructie beperkt de vrijheid van de agent om de output van acties te wijzigen. Zorg ervoor dat de instructie verwijst naar de output van de taakaanwijzingssjabloon (bijvoorbeeld 'promptResponse'), zoals getoond in deze Plantracker.

De instructie in dit geval kan dus zijn:

“ Wijzig de output promptResponse niet, ongeacht het kanaal van de agent. ”

Beperkingen voor het afdwingen van strikte naleving:

Wanneer een interactie meerdere afzonderlijke agent-acties vereist, is het niet mogelijk om de strikte naleving van één template af te dwingen. In dit scenario moet de redeneringsengine deze acties samenvoegen tot één reactie en dus elke afzonderlijke actie-output aanpassen.

Optimaal aantal instructies

Op basis van algemene LLM-eigenschappen ligt het ideale aantal instructies tussen 5 en 10, afhankelijk van de complexiteit van de instructie en de interactie met de instructie. Deze instructie-eigenschappen beïnvloeden het aantal instructies dat de redeneringsengine kan volgen:

• Duidelijkheid en specificiteit: Goed gedefinieerde regels zijn gemakkelijker te volgen.
• Conflicten tussen regels: Als regels elkaar tegenspreken, is extra logica nodig om ze op te lossen.
• Lengte en complexiteit: Als elke regel diepgaand moet worden beredeneerd, overweeg dan om de regels op te splitsen in kleinere instructies.

Als het erg belangrijk is om een instructie expliciet op te volgen, voeg dan termen toe die hun belang onderstrepen:

• Urgentie en belang (onmiddellijk, dringend, kritiek, essentieel, verplicht)
• Autoriteit en handhaving (vereist, verplicht, strikt gehandhaafd)
• Gevolgen en waarschuwingen (overtreding zal leiden tot, niet-naleving zal leiden tot, niet-naleving kan resulteren in, strikte sancties zijn van toepassing, zero tolerance)
• Duidelijkheid en directheid (moet, illegaal, verboden, niet toegestaan, altijd/nooit)

Het baseren van antwoorden op data ('grounding') verbetert de betrouwbaarheid van agents aanzienlijk. Gegronde antwoorden zijn gebaseerd op feitelijke informatie in plaats van op speculatie of verouderde kennis. Retrieval Augmented Generation (RAG) is een veelgebruikte techniek waarmee een agent toegang heeft tot een knowledge base en deze kan gebruiken om nauwkeurigere en contextueel relevante antwoorden te formuleren. Op basis van de vraag van een gebruiker gebruikt een agent RAG om relevante informatie uit toepasselijke databronnen op te halen en vervolgens de taakaanwijzing aan te vullen met deze informatie voordat deze naar het LLM wordt verzonden. Een agent die RAG gebruikt, heeft een hogere kwaliteit, is nauwkeuriger en biedt betere interacties. Dit verhoogt het vertrouwen en de tevredenheid van gebruikers. Best practices voor RAG worden uitgebreid beschreven in een vrij beschikbare whitepaper met de titel Agentforce and RAG: best practices for better agents .

Kennis versus instructies

Het maken van onderscheid tussen kennis en instructies is belangrijk voor het vinden van de juiste balans tussen sturing en flexibiliteit, omdat ze verschillende doelen hebben:

• Kennis: Beschouw kennis als de bibliotheek met boeken waartoe de agent toegang heeft tijdens het genereren van antwoorden. Voorbeelden zijn onder meer documenten, knowledge-base-artikelen en whitepapers. Bedenk dat dit ook beleidsregels en algemene bedrijfsregels kunnen zijn. Kennis kan ook verwijzen naar transactionele bestanden, zoals e-mails, gesprekstranscripties en zelfs de geschiedenis van (agent)gesprekken. Tot slot omvat kennis lange tekstvelden in gestructureerde data. Kennis komt meestal via RAG bij de agent terecht.
• Instructies: Beschouw instructies als de minimale set regels die de agent duidelijk maken wanneer elke actie moet worden toegepast. Instructies kunnen ook grenzen bepalen voor het hele gesprek, zoals de vereiste toon van het gesprek. Vaak kunnen instructies beknopter en flexibeler worden gemaakt, zonder dat dit ten koste gaat van de duidelijkheid of intentie. In plaats van een rigide script met specifieke antwoorden te geven voor elk mogelijk klantscenario, kan worden overwogen om algemene richtlijnen en principes te implementeren die de agent helpen de juiste actie(s) te selecteren in verschillende situaties.

Retrieval Augmented Generation

Retrieval Augmented Generation (RAG) fungeert als een slimme datalaag voor kennis. Hiermee hebben agents toegang tot informatie in verschillende formats en beschikken ze over relevante tekstfragmenten voor het beantwoorden van vragen. Met RAG kunnen agents nauwkeurigere LLM-antwoorden krijgen zonder de LLM-taakaanwijzing te overspoelen met externe inhoud of het contextvenster te overschrijden.

Wanneer RAG wordt uitgevoerd, doorloopt het drie stappen:

1. Ophalen: Het AI-systeem doorzoekt een grote database of kennisbron om relevante informatie te verzamelen voor de LLM-taakaanwijzing. Dit wordt gedaan met behulp van semantisch zoeken, een geavanceerdere techniek dan traditionele zoekopdrachten op basis van trefwoorden. In tegenstelling tot zoeken op trefwoord, waarbij exacte termen moeten worden gevonden, wordt bij semantisch zoeken gekeken naar de betekenis of context achter de woorden. Het identificeert relevante informatie op basis van de concepten of relaties tussen termen, in plaats van alleen te zoeken naar exacte woordovereenkomsten. Zoeken op trefwoord kan ook een rol spelen in dit ophaalproces, waardoor de semantische zoekopdracht wordt uitgebreid met trefwoordvergelijking voor specifieke terminologie of namen. Dit type zoekactie wordt hybride zoeken genoemd.
2. Augmenteren: De opgehaalde informatie wordt toegevoegd aan de taakaanwijzing.
3. Genereren: Het LLM genereert een contextueel passende en nauwkeurigere reactie dankzij de taakaanwijzing die is aangevuld met opgehaalde kennis.

In Agentforce kan RAG worden gebruikt met of zonder een taakaanwijzingssjabloon:

1. Taakaanwijzinggebaseerde RAG: Bij deze aanpak staan de instructies die aangeven hoe het antwoord moet worden gegenereerd in de taakaanwijzingsinstructies in een taakaanwijzingssjabloon. In dit geval hangt het antwoord volledig af van wat het LLM genereert. Afgezien van de taakaanwijzingsinstructies kan de beantwoording worden beïnvloed, zoals LLM-configuratie-instellingen in Einstein Studio, maar het resultaat is nog steeds niet deterministisch.
2. Redeneringsengine-gebaseerde RAG: In plaats van een taakaanwijzingssjabloon te gebruiken, gebruikt de agent een actie die stukjes data ophaalt (via een stroom of Apex-klasse) en deze opslaat in een variabele (zie de volgende sectie). Bij deze aanpak genereert de redeneringsengine (en dus niet het LLM) rechtstreeks antwoorden, gebaseerd op de opgehaalde data. De instructies die het genereren van antwoorden bepalen, zijn agent-instructies in plaats van taakaanwijzingssjabloon-instructies. De variabele die de opgehaalde inhoud bevat, kan nog steeds expliciet worden doorgegeven als invoer voor een actie. Het kan ook aan de redeneringsengine worden doorgegeven door deze toegang te verlenen tot de inhoud van de variabele. Deze aanpak heeft echter enkele nadelen. Er bestaat een risico dat de redeneringsengine wordt overspoeld door inhoud en verantwoordelijkheden. In tegenstelling tot een taakaanwijzing zijn de parameters van het redeneringsengine-LLM bovendien niet configureerbaar. Aan de andere kant kan de redeneringsengine een antwoord genereren met behulp van zowel de opgehaalde stukjes data als de geschiedenis van het gesprek.

De aanbevolen methode is optie 1. Deze vermindert het aantal taken dat de redeneringsengine moet uitvoeren en verbetert zo de antwoordkwaliteit. In het volgende gedeelte wordt een uitzondering op deze regel besproken, waarbij de inhoud tijdens het gesprek wordt vastgehouden en expliciet wordt doorgegeven aan een actie.

Best practices voor RAG

• Gescripte RAG-instructies vermijden: In plaats van instructies rechtstreeks te koppelen aan specifieke artikelen voor bepaalde vragen, maak je gebruik van de intelligentie van RAG om dynamisch de meest relevante databron en het meest nauwkeurige tekstfragment te vinden. Het matchingsproces van RAG is gebaseerd op een breder begrip van de vraag, niet alleen op de exacte vraag-naar-bron-mapping.
• Onderwerpen consolideren: Groepeer gerelateerde vraagcategorieën in één onderwerp. RAG kan effectief relevante antwoorden identificeren op basis van het vraagtype, zelfs binnen een breder onderwerp. Productkwesties zoals onderhoud en accuproblemen kunnen bijvoorbeeld worden samengevoegd tot een uitgebreider onderwerp.

RAG-output opslaan in een variabele: Wanneer het aantal interactielimieten kan worden bereikt, sla je de RAG-output op in een variabele. Dit houdt de informatie toegankelijk voor het richting geven aan interacties van agents buiten de standaarddrempel. Een voorbeeld hiervan vind je in het volgende gedeelte.

Bepaalde bedrijfsprocessen vereisen een nog voorspelbaardere uitvoering, zoals het afdwingen van een specifieke actiereeks of voorwaarden voor het activeren van acties of onderwerpen.

Om dit deterministische gedrag te bereiken, kunnen variabelen worden gebruikt. Variabelen functioneren als een gestructureerde vorm van het kortetermijngeheugen van een agent, dat kan dienen als actie-input of -output. Bovendien kan de status van een variabele de activering van specifieke onderwerpen en acties bepalen.

Manieren waarop variabelen determinisme ondersteunen

Variabelen kunnen op de volgende manieren bijdragen aan gestuurd determinisme van agents:

1. Persistente dynamische grounding: Variabelen stellen agents in staat om hun begrip van de wereld voortdurend bij te werken en tegelijkertijd belangrijke informatie te bewaren die niet wordt beïnvloed door latere interacties. Deze methode zorgt ervoor dat kritieke informatie (wat ongestructureerde data die via RAG is opgehaald kan zijn, maar ook gestructureerde data zoals informatie over gebruikersprofielen) gedurende het hele gesprek blijft behouden, onafhankelijk van de gesprekslengte.
2. Actie-input/-output: Variabelen kunnen worden gebruikt als zowel input als output voor acties. De actie verwijst expliciet naar variabelen en de uitvoering van de actie is niet afhankelijk van de redeneringsengine voor het instellen van deze input en output, wat het determinisme van de agent vergroot.
3. Filteren: Variabelen kunnen worden gebruikt om de voorwaardelijke uitvoering van acties of onderwerpen te bepalen. Variabelen zorgen voor een specifieke informatiestroom tussen acties en determinisme in de uitvoering van acties. Deze mogelijkheid is met name cruciaal voor beveiligingsregels waarbij acties niet kunnen worden gestart als specifieke input-variabelen, zoals e-mail, niet zijn geverifieerd.

Soorten variabelen in Agentforce

Agentforce heeft twee soorten variabelen:

• Contextvariabelen zijn door het systeem gegenereerde variabelen met informatie over de gebruiker en de gesprekssessies.
• Aangepaste variabelen kunnen door de gebruiker worden geïnstantieerd. Ze bevatten alle soorten informatie die worden gebruikt voor een van de drie manieren waarop variabelen determinisme ondersteunen.

Variabeletypen ondersteunen de volgende mogelijkheden:

Laten we variabelen eens nader bekijken aan de hand van een voorbeeld van een use case: een klantgerichte probleemoplossingsagent. In dit voorbeeld worden variabelen gebruikt voor alle drie de doeleinden: persistente dynamische grounding, actie-input/-output en filteren.

In dit voorbeeld helpt de agent een klant bij het oplossen van een technisch probleem met een apparaat. Probleemoplossing omvat meestal het doorlopen van een aantal stappen. De agent moet een klantenservice-ervaring bieden die het werk van een menselijke medewerker nabootst. Om dit te doen, moet de agent niet alle stappen voor probleemoplossing gelijktijdig aan de klant verstrekken. In plaats daarvan moet hij stap-voor-stap instructies bieden, samen met de mogelijkheid om tussen stappen te navigeren (zoals teruggaan naar eerder behandelde stappen) op basis van de reactie van de klant.

Een uitdaging hierbij is het vermogen van de agent om alle stappen voor probleemoplossing tijdens het gesprek te onthouden. Met het oog op het beperkte geheugen van de agent vanwege het beperkte aantal interacties dat deze kan opslaan, kunnen deze stappen voor de redeneringsengine uit de context worden verwijderd als het gesprek te lang wordt.

Je pakt dit aan door een variabele te gebruiken om de redeneringsengine dynamisch te grounden in stappen voor de probleemoplossing. Door de informatie op te halen en op te slaan in een variabele, blijft deze tijdens het gesprek beschikbaar en kan deze worden bijgewerkt. De redeneringsengine gebruikt de informatie die in deze variabele is opgeslagen voor dynamische grounding.

In dit voorbeeld bevat een onderwerp twee acties. Deze twee acties zijn nodig om een consistente datastroom in stand te houden. De eerste actie wordt gebruikt voor het vullen van de variabele met alle stappen voor de probleemoplossing. De tweede actie maakt gebruik van die variabele tijdens het oplossen van het probleem zelf.

1. Actie 1: "Oplossingsstappen toevoegen". Dit is de eerste actie, die wordt geactiveerd als de agent voor het eerst wordt geconfronteerd met het probleem. Het maakt gebruik van Retrieval Augmented Generation om alle benodigde oplossingsstappen uit een geïndexeerde knowledge base te halen. De actie slaat de resulterende output op in een variabele met de naam 'Oplossingsstappen'.
2. Actie 2: "Gebruiken tijdens het oplossen van een probleem". Dit is een actie op basis van een taakaanwijzing die de meest waarschijnlijke volgende stap voor probleemoplossing uitvoert en die tijdens het probleemoplossingsproces moet worden gebruikt. De agent krijgt de instructie om deze actie te gebruiken terwijl hij bezig is met het oplossen van een probleem.

De oorspronkelijke vraag van de klant is de input voor beide acties. De tweede actie heeft een andere input: de inhoud van de variabele 'Oplossingsstappen'. Deze variabele is ingesteld door de eerste actie. Bedenk dat de tweede actie de stappen voor probleemoplossing niet zelf ophaalt, maar ze ontvangt als input van de eerste actie via de variabele. Het volgende diagram toont de datastroom tussen deze twee acties.

De actie 'Gebruiken tijdens het oplossen van een probleem' verwijst altijd naar de oorspronkelijke stappen voor probleemoplossing die zijn opgehaald door de actie 'Oplossingsstappen toevoegen'. Deze datastroom zorgt ervoor dat probleemoplossingsstappen coherent worden bewaard en altijd aanwezig zijn, ongeacht de gespreksduur.

Om de acties uit te voeren die in dit voorbeeld zijn gedefinieerd, zijn specifieke instructies nodig, zoals 'Altijd eerst 'oplossingsstappen invullen' uitvoeren.' Gezien echter de niet-deterministische aard van LLM's die door agents worden gebruikt, kan dit in bepaalde gevallen leiden tot een andere volgorde. Om een deterministische volgorde van uitvoering te garanderen, passen we voorwaardelijke filters toe op deze variabelen om de juiste actievolgorde af te dwingen. De agent leest de waarde van de variabele 'Oplossingsstappen' en definieert twee filters op basis van de vraag of deze variabele een waarde heeft of niet.

• De actie 'Oplossingsstappen toevoegen' kan alleen worden uitgevoerd als de variabele 'Oplossingsstappen' leeg is.
• 'Gebruiken tijdens het oplossen van een probleem' kan alleen worden uitgevoerd als de variabele 'Oplossingsstappen' is gevuld.

Deze voorwaardelijke filters forceren nu de volgorde van uitvoering van acties deterministisch: 'Gebruiken tijdens het oplossen van een probleem' moet wachten tot 'Oplossingsstappen toevoegen' zijn werk heeft voltooid, waardoor wordt gegarandeerd dat de variabele 'Oplossingsstappen' altijd een waarde heeft.

Om ervoor te zorgen dat de actie correct wordt uitgevoerd, is een derde actie nodig om de variabele 'Oplossingsstappen' opnieuw in te stellen als het probleem volledig is opgelost. Als gevolg hiervan wordt de agent opnieuw ingesteld op de vereiste status om te helpen bij een mogelijk nieuw, ander probleem. Deze derde actie heet 'Oplossingsvariabele leegmaken'. Het volledige actieschema is hieronder afgebeeld.

Variabelen zijn cruciaal om onze agent in staat te stellen problemen van klanten op te lossen door het volgende mogelijk te maken:

• Persistente dynamische grounding:: Variabelen slaan stappen voor probleemoplossing op, zodat ze tijdens het gesprek beschikbaar zijn, ongeacht de lengte of het aantal interacties. Dit voorkomt dat de agent context vergeet.
• Datastroom: Variabelen vergemakkelijken de datastroom tussen acties. De variabele 'Oplossingsstappen' slaat bijvoorbeeld de opgehaalde stappen voor probleemoplossing op uit de actie 'Oplossingsstappen toevoegen' en geeft deze als input voor de actie 'Gebruiken tijdens het oplossen van een probleem'.
• Determinisme: Variabelen kunnen worden gebruikt als filters om een specifieke volgorde van uitvoering van acties af te dwingen. De actie 'Gebruiken tijdens het oplossen van een probleem' wordt bijvoorbeeld alleen uitgevoerd als de variabele 'Oplossingsstappen' Step is gevuld, zodat de actie 'Oplossingsstappen toevoegen' eerst moet worden uitgevoerd.

In het tijdperk van generatieve AI blijft voorspellende AI van cruciaal belang. Het vormt immers de fundamentele intelligentie die generatieve mogelijkheden aanstuurt, verbetert en context geeft. Waar generatieve AI zich richt op het creëren van nieuwe content zoals tekst, afbeeldingen en video's, doen voorspellende modellen voorspellingen over de toekomst op basis van input uit realtime bedrijfsdata. Voorbeelden van bedrijfsresultaten zijn onder meer de waarschijnlijkheid van klantverloop, conversiewaarschijnlijkheden, kans op escalatie van cases, customer lifetime value en case-classificatie. Voorspellingen helpen met anticiperen op de behoeften van gebruikers, het personaliseren van output, het nemen van beslissingen en het in realtime optimaliseren van de relevantie van content - allemaal door trends en cijfers te analyseren. In toepassingen zoals gepersonaliseerd leren, gezondheidszorg of financiële planning zorgt voorspellende AI er bijvoorbeeld voor dat generatieve output aansluit bij individuele contexten en waarschijnlijke toekomstige scenario's. Samen zorgen voorspellende en generatieve AI voor een krachtige synergie, waarbij vooruitziendheid wordt gecombineerd met creativiteit om meer intelligente, adaptieve en impactvolle technologieoplossingen te stimuleren.

Zo integreer je voorspellende modeloutput in agentworkflows

Om voorspellende modeloutput op te nemen in agentworkflows, voeg je gewoon voorspellende modelacties toe aan de Agentforce-activa. Model Builder biedt de middelen om voorspellende modellen te bouwen of te registreren (BYO). Deze modellen worden vervolgens door de agent gebruikt om voorspellingen te doen. De resulterende voorspellingen (evenals de voorspellers) kunnen worden opgeslagen in aangepaste variabelen. Agents kunnen deze variabele waarden gebruiken als input voor en het conditionaliseren van de uitvoering van specifieke acties en onderwerpen.

Voorbeelden van use cases die zijn geïntegreerd met voorspellende modellen

• Segmentatie: Voer classificatie met meerdere klassen uit voor klantsegmentatie en gebruik het resulterende segment om bepaalde acties te filteren. Reserveer bijvoorbeeld premium acties voor premium-klanten.
• Kans op escalatie: Voorspel de kans op escalatie voor een servicecase. Als deze kans een bepaalde drempel overschrijdt, sta dan de uitvoering toe van acties die de case sneller oplossen of sneller escaleren naar menselijke medewerkers.
• CPG: Plan een promotie alleen als de toename in sales (score berekend door een voorspellend model) een bepaalde drempel overschrijdt.
• Commerce: Stel alleen een product voor als de koopbereidheid een bepaalde drempel overschrijdt.

Bepaalde bedrijfsprocessen moeten in een nauwkeurige volgorde worden uitgevoerd en vereisen geen gebruikersinvoer tijdens de uitvoering. In dit geval kan een vooraf bepaalde stappenstroom worden afgedwongen via stromen, API's of Apex. Als je een bestaande stroom hebt waarop in de productie wordt vertrouwd, is dit een goede indicatie dat deze door de agent kan worden bewaard en gebruikt voor de uitvoering van dat bedrijfsproces. Alle volgende voorbeelden bevatten vooraf bepaalde stappenreeksen die de agent kan uitvoeren zonder gebruikersinvoer. Het agentische gedrag bestaat in dit geval uit het identificeren van welk deterministisch proces moet worden uitgevoerd, hoe de nodige input moet worden verzameld en hoe de outputs moeten worden geïnterpreteerd en verwerkt.

Bedrijfsprocessen met veel opeenvolgende stappen (meer dan drie, als vuistregel) en veel afhankelijkheden van variabelen worden te complex en omslachtig om af te dwingen met instructies. In dit geval is het mogelijk om ze gewoon te programmeren in hardcode met behulp van de deterministische actietypen die in dit gedeelte worden vermeld. Merk ten slotte op dat deze implementaties niet-deterministische elementen kunnen bevatten, zoals het aanroepen van LLM's met opgeloste taakaanwijzingssjablonen. Daarom zijn ze end-to-end niet altijd volledig deterministisch en kunnen ze nog steeds de gewenste flexibiliteit laten zien waar agents om bekend staan.

De volgorde van stappen in een marketingtraject wordt bepaald door vaste regels en is niet afhankelijk van conversational gebruikersinput. Daarom kan de stroom als een Agentforce-actie worden gebruikt. Een aanroepbare actie kan worden gemaakt om achtergrond- of gebeurtenisgestuurde taken uit te voeren vanuit een oplossingscomponent die een stroom of Apex-klasse kan aanroepen. Voeg een aanroepbare actie toe aan een stroom of Apex-klasse en geef de taak op die de agent moet voltooien, evenals de voorwaarden die de agent activeren. Aanroepbare acties kunnen ook de contextvariabelen van de agent bevatten en belangrijke informatie doorgeven.

Salesforce-stromen kunnen worden gebruikt om routinetaken te automatiseren, zoals het maken van vervolgtaken, het verzenden van herinneringse-mails of het bijwerken van records. Stromen maken het werk efficiënter en productiever. Agents kunnen ook stromen uitvoeren met behulp van stroomacties. Vanwege hun determinisme zijn stromen een geweldige manier om agentisch gedrag te sturen wanneer een bedrijfsproces in een bepaalde volgorde moet worden uitgevoerd. Een goede indicatie dat een stroomactie de voorkeur heeft, is wanneer het onderwerp anders instructies zou bevatten zoals "eerst dit doen, dan dit doen en uiteindelijk dit doen". Het afdwingen van reeksen van meer dan drie stappen wordt lastig om te beheren via instructies en variabelen.

Stromen kunnen ook niet-deterministische elementen bevatten door taakaanwijzingen aan te roepen. Een taakaanwijzingsknooppunt in de stroom roept een taakaanwijzingssjabloon aan en verzamelt het antwoord dat kan worden doorgegeven aan andere elementen in de stroom. Deze verdere elementen kunnen ook weer taakaanwijzingsknooppunten zijn, bijvoorbeeld het samenvatten van het vorige antwoord. Zo ontstaat een keten van taakaanwijzingen. Dit is vooral handig wanneer de regels voor taakaanwijzingsketens worden gedefinieerd door vaste elementen en niet afhankelijk zijn van gebruikersinput. Een voorbeeld is agentische RAG, waarin een vooraf gedefinieerde reeks retrievers of taakaanwijzingen in een stroom toegang heeft tot specifieke databronnen in een bepaalde volgorde. Denk daarbij aan het eerst ophalen van data uit het landdocument van een gebruiker, om vervolgens naar behoefte andere bronnen te raadplegen. Dit ketenmechanisme dwingt een betrouwbare en geordende extractie van relevante informatie af.

Net als flows zijn Apex- en API-acties deterministisch, omdat een vooraf gedefinieerde reeks acties kan worden gecodeerd. Deze acties kunnen niet-deterministische elementen bevatten, zoals het aanroepen van taakaanwijzingssjablonen of LLM-aanroepen. Per definitie voeren ze deze stappen echter deterministisch uit, wat de agentische variabiliteit vermindert door de actie op het juiste moment aan te roepen, de benodigde input te verzamelen en de output te verwerken. Deze verantwoordelijkheden moeten nog steeds worden beheerd door agentische instructies, dus zijn ze niet-deterministisch. Apex- en API-acties zijn het pro-code-equivalent van stroomacties.

Het bereiken van betrouwbaar agentisch gedrag vereist een gestructureerde aanpak die de inherente flexibiliteit van grote taalmodellen (LLM's) afstemt op de behoefte aan controle en voorspelbaarheid op bedrijfsniveau. Dit artikel schetste een gelaagde strategie voor het implementeren van 'gestuurd determinisme', waarmee agents kunnen worden gemaakt die niet alleen slim en autonoom zijn, maar ook altijd nauwkeurig zijn en afgestemd zijn op bedrijfsprocessen. De sleutel tot het bouwen van deze vertrouwde agents ligt in een progressieve implementatie van controlemechanismen, die elk een nieuwe laag van betrouwbaarheid toevoegen:

1. Fundamenteel onderwerp- en actieontwerp:: Het proces begint met het zorgvuldig toewijzen van de mogelijkheden van een agent aan verschillende onderwerpen en gedetailleerde acties. Door semantisch verschillende en logische groepen te creëren, verminderen we het risico dat de redeneringsengine zo verward raakt dat hij de verkeerde actie selecteert. Dit is basis van voorspelbaar gedrag.
2. Expliciete instructies:: Instructies voor agents gaan uit van deze basis en vormen het volgende controleniveau. Deze instructies fungeren als vangrails en richtlijnen voor de redeneringsengine, die daardoor weet hoe acties binnen zijn bevoegdheid moeten worden uitgevoerd, hoe hij zich aan bedrijfsbeleid moet houden en hoe hij gesprekken kan sturen zonder de interactie te veel te scripten.
3. Data grounding met RAG: Om antwoorden feitelijker en relevanter te maken, brengt data grounding de agent in contact met geverifieerde kennisbronnen. Methoden zoals Retrieval Augmented Generation (RAG) stellen agents in staat om in realtime nauwkeurige informatie op te halen uit knowledge-base-artikelen en bedrijfsdata, wat speculatie minimaliseert en de betrouwbaarheid verbetert.
4. Context- en statusbeheer met variabelen: Voor complexere en statusafhankelijke interacties bieden variabelen een vorm van kortetermijngeheugen. Ze stellen de agent in staat om de context te behouden, rekening te houden met belangrijke data tijdens een gesprek en een deterministische volgorde van operaties af te dwingen door de uitvoering van acties af te stemmen op de status van een variabele.
5. Deterministische uitvoering met stromen, Apex en API's: Voor bedrijfsprocessen die een rigide, onveranderlijke uitvoering vereisen, wordt het hoogste niveau van controle bereikt door middel van deterministische acties. Door agents te integreren met Salesforce-stromen, Apex en API's, kunnen vooraf gedefinieerde reeksen nauwkeurig worden uitgevoerd. Ze zijn dan niet meer afhankelijk van gebruikersinput of LLM-input voor kritieke stappen.

Door deze controlelagen systematisch toe te passen (van een doordacht ontwerp en duidelijke instructies tot data grounding, statusbeheer en deterministische procesautomatisering), kunnen developers betrouwbare agents bouwen met consistente bedrijfsresultaten. Deze strategische aanpak zorgt ervoor dat je Agentforce-agents met vertrouwen kritieke bedrijfsfuncties kunt laten uitvoeren, met de nauwkeurigheid en consistentie die nodig zijn in het bedrijfsleven.