Hur du ger instruktioner till ett Conversational AI-system

I dag har LLM blivit det bultande hjärtat i Conversational AI-system. Mer specifikt gör LLM:er det möjligt för Conversational AI — som ursprungligen byggdes kring omfattande telefonmenyer — att erbjuda dynamisk funktionalitet och upplevelser som känns mänskliga. Men LLM:er är ingen universallösning; de kräver specialanpassade instruktioner eftersom de inte är finjusterade för mänskligt tal som standard.

Utvecklare gör ofta samma misstag när de instruerar LLM:er för Conversational AI: de återanvänder samma manual som användes för att utbilda mänskliga medarbetare. Trots att strategin låter enkel ger den sällan resultat. LLM:er gör andra antaganden än vanliga människor, och deras standardton och omfattning lämpar sig inte för muntliga interaktioner.

I dag går vi igenom vad vi vet om hur man instruerar LLM:er för att bygga framgångsrika Conversational AI-system. Du kan också läsa en mer omfattande och teknisk guide om ämnet i ElevenLabs utvecklardokumentation.

Det gamla systemet

Före LLM:er använde Conversational AI-system omfattande logikträd där förfrågningar sorterades utifrån muntliga inmatningar. Den här lösningen var vanlig hos kundtjänstnummer, till exempel flygbolagens telefonlinjer, och betalningssystem, till exempel telefontjänster för kreditkort.

De här äldre systemen var långsamma, kändes robotliknande och kunde bara hantera mycket begränsad mänsklig inmatning. Du har säkert upplevt det själv: att du kort och gott skriker ”JA” i telefonen för att svara på en uppmaning. Den dåliga upplevelsen fick de flesta användare att försöka ”besegra systemet” för att få prata med en mänsklig handläggare.

Men dessa telefonmenyer hade en fördel — de var avgränsade. Det fanns bara ett begränsat antal vägar ett samtal kunde ta, och utvecklare kunde enkelt införa skyddsräcken som ignorerade otillåtna inmatningar. Den här begränsningen ligger bakom både för- och nackdelarna med LLM:er: De går långt bortom telefonmenyernas begränsade möjligheter, men är också oförutsägbara och öppnar en Pandoras ask av fallgropar — som att ge omöjliga löften, bli arga på kunder eller röja känsliga data.

Standardbrister

Om LLM:er enbart tränas på en handbok som ursprungligen skapats för människor blir resultaten medelmåttiga på grund av några grundläggande brister. Genom att förstå dem kan du utforma instruktioner som hanterar dem:

Fel tonläge

LLM:er tränas med förstärkningsinlärning, där mänsklig återkoppling uppmuntrar LLM:er att ge strukturerade svar. LLM-svar tenderar särskilt att vara utförliga och fyllda med punktlistor, faktarutor och rubriker.

I Conversational AI-sammanhang behöver LLM:er däremot efterlikna den kortfattade och mindre strukturerade formen hos muntliga interaktioner.

Antagandebrister

LLM:er har en tendens att fylla i det okända med slutsatser i stället för att ställa frågor. Det kan leda till felaktiga antaganden som vilseleder användare — eller till kostsamma misstag, som utlovade återbetalningar. Senare ska vi se hur en kunskapsbas och skyddsräcken kan ge LLM:er bättre faktagrund, så att de inte ger felaktiga löften eller utför otillåtna åtgärder.

Latens

LLM:er kan programmässigt anropa funktioner och hämta eller skriva data åt människor. Det är ofta en av LLM:ernas största fördelar, men innebär också att tidigare träningsinstruktioner som lät telefonagenter ”vinna tid” medan de utförde uppgifter inte längre behövs. Funktionsanrop sker dock inte heller omedelbart, vilket betyder att LLM:er måste förvarna användaren korrekt när en fördröjning förväntas, till exempel ”ge mig en stund att granska ditt ärende”.

Konfigurationer

Personlighet

LLM:er är ganska bra på att anpassa tonläget efter en stil. En LLM kan konfigureras för att låta vänlig, humoristisk, kortfattad, formell eller som en kombination av stilar. Det är en viktig uppgift när du instruerar en LLM.

Utvecklare av en Conversational AI-applikation för kundtjänst, utformad för att hjälpa missnöjda flygpassagerare, kan till exempel använda en instruktion som:

Format

LLM:er behöver få tydliga instruktioner om hur de ska svara. För att säkerställa att de inte lägger till utfyllnadstext bör LLM:er få en struktur som omsluter svaret som skickas till användaren.

LLM:er kan till exempel instrueras att:

Den här strukturen uppmuntrar LLM:en att ge ett svar som är utformat för att läsas upp.

LLM:er kan dock ibland snubbla på sådant som intuitivt kanske inte skiljer sig från skrivet innehåll. Ett vanligt exempel är siffror — en LLM kan skriva ut ett postnummer som 10023, vilket får text-to-speech-modellen att säga ”tiotusen tjugotre”. I stället bör LLM:en uttryckligen instrueras att säga siffrorna var för sig och tydliggöra vad de betyder, till exempel ”Postnumret är ett noll noll två tre.”

Temperatur

Temperatur är en avgörande parameter när LLM:er konfigureras för Conversational AI. En lägre temperatur ger mer fokuserade, deterministiska svar som passar uppgiftsorienterade samtal, medan högre temperaturer skapar mer kreativa och varierade svar.

En låg temperatur är idealisk för Conversational AI-system som föredrar konsekventa svar, till exempel en kundtjänstlinje för återbetalningar. För system som vill ge kunderna en mer engagerande och realistisk upplevelse, till exempel en digital coach, är en hög temperatur bättre:

Kunskapsbaser

För Conversational AI-system som använder större kunskapsreservoarer bör en kunskapsbas användas för att minimera instruktionens längd. I produktion görs detta vanligtvis via en vektordatabas, som Pinecone eller Elasticsearch, eller LLM-leverantörens direkta kunskapslager.

Generellt är kunskapsbaser avgörande för att förankra LLM-svar i faktabaserad, godkänd information. När du bygger ett Conversational AI-system bör du ge LLM:en en omfattande kunskapsbas med korrekt och aktuell information om produkter, tjänster, policyer och processer. Det hindrar LLM:en från att hallucinera eller hitta på information och främjar samtidigt konsekventa och tillförlitliga svar i olika samtal.

Process

Eftersom LLM:er ofta anropar funktioner åt användaren behöver de också veta vilka inmatningar som uttryckligen krävs. Om en LLM till exempel ska hjälpa en användare att boka en klipptid måste den säkerställa att den har:

1. Användarens namn
2. Önskat datum och tid
3. Användarens adress
4. Användarens önskemål om tjänst

En naiv implementering kan leda till att LLM:en frågar efter all information i en och samma samtalsomgång. Det fungerar bra i text, men i ett samtal kan det kännas överväldigande:

Eftersom information vanligtvis samlas in stegvis i ett samtal måste LLM:er uppmuntras att hämta den bit för bit. Resultatet blir en betydligt mer samtalslik upplevelse:

Skyddsräcken

Behörigheter

När du bygger distribuerade system utgår du från att servern kommer att krascha någon gång. På samma sätt bör du utgå från att din LLM kommer att göra ett misstag någon gång när du bygger AI-system. För att begränsa konsekvenserna av misstaget bör du ge systemen minsta möjliga behörighet för uppgiften. Här är några sätt att göra det på:

• Ange läs- och skrivbehörigheter korrekt: Om LLM:en bara behöver läsa information från en datakälla ska du se till att den får en skrivskyddad endpoint.
• Begränsa åtkomsten till API-endpoints: Om LLM:en bara behöver åtkomst till vissa endpoints ska du se till att den inte kommer åt några andra.
• Eskaleringar med människa i loopen: Om en högriskåtgärd behöver utföras bör du överväga ett human-in-the-loop-workflow som kräver ”chefsgodkännande” innan åtgärden utförs.

Validering och verifiering

När du skapar AI-röstagent-system för samtal som utför åtgärder med hjälp av verktyg är det bra att bygga in en process för validering och verifiering, så att du samlar in rätt information från användarna. När du i dag talar med en mänsklig handläggare upprepar hen viktig information du lämnar för att bekräfta att den uppfattats korrekt och att kunden inte råkade säga fel. LLM:er kan dra nytta av en liknande nivå av felkontroll:

Vid validering bör all information som tas emot från kunden kontrolleras mot den typiska strukturen för den sortens information. Har telefonnumret rätt antal siffror? Ligger kundens angivna ålder inom ett rimligt intervall? Har kunden angett en giltig adress?

Beroende på användningsområde kan du verifiera all mottagen information eller endast information som inte klarade verifieringen. Du kan dessutom välja att verifiera varje uppgift när den kommer in eller kontrollera allt i slutet.

En avslutande tanke

Att framgångsrikt instruera ett Conversational AI-agent-system handlar om att balansera rätt konfigurationer och skyddsräcken för att skapa en upplevelse som efterliknar ett samtal med en människa, men med högre effektivitet. Processen är inte så enkel som att använda gammalt utbildningsmaterial för att instruera en LLM. LLM:er är i stället verktyg som behöver en specialanpassad struktur och strategi för att ge förutsägbara och effektiva resultat.