Hur du ger instruktioner till ett Conversational AI-system

Idag har LLM blivit hjärtat i conversational AI-system. Specifikt möjliggör LLMs conversational AI — ursprungligen byggt kring omfattande telefonträd — att ha dynamisk funktionalitet och ge mänskliga upplevelser. Men LLMs är inte en universallösning; de kräver specialiserade instruktioner eftersom de inte är finjusterade för mänskligt tal som standard.

Utvecklare gör ofta misstaget att återanvända samma strategi som användes för att träna mänskliga anställda när de ger instruktioner till LLMs för conversational AI. Denna strategi, trots att den låter enkel, är sällan fruktbar. LLMs gör andra antaganden än vanliga människor, och deras standardton och omfattning är inte lämpade för verbala interaktioner.

Idag kommer vi att avslöja vad vi vet om hur man ger instruktioner till LLMs för att bygga framgångsrika conversational AI-system. Du kan också läsa en mer omfattande och teknisk guide om detta ämne i ElevenLabs Developer docs.

Det gamla systemet

Innan LLMs använde conversational AI-system omfattande logikträd som förfrågningar skulle sorteras genom baserat på verbala inmatningar. Denna uppsättning var populär bland kundtjänstnummer (t.ex. flygbolagshotlines) och betalningssystem (t.ex. kreditkortstjänster via telefon).

Dessa äldre system var långsamma, kändes robotlika och tillät endast mycket begränsade mänskliga inmatningar. Det finns en god chans att du själv har upplevt detta, när du rakt ut skrek “JA” i telefonen för att svara på en fråga. Denna dåliga upplevelse ledde till att de flesta användare försökte “överlista systemet” för att tvinga fram en konversation med en levande mänsklig agent.

Men det fanns en fördel med dessa telefonträd — de var begränsade. Det fanns bara så många vägar en konversation kunde ta, och utvecklare kunde enkelt implementera skyddsräcken för att bortse från otillåtna inmatningar. Denna begränsning ligger till grund för för- och nackdelarna med LLMs: De expanderar dramatiskt bortom telefonträdens begränsade natur, men de är också oförutsägbara, vilket öppnar en Pandoras ask av fallgropar — som att ge omöjliga löften, bli arg på kunder eller bryta mot känsliga data.

Standardluckor

Om LLMs bara tränas på en handbok ursprungligen designad för människor, kommer de att ha medioker framgång på grund av några kärnluckor. Att förstå dessa luckor hjälper dig att designa instruktioner för att hantera dem:

Tonmissmatch

LLMs tränas via förstärkningsinlärning, där mänsklig feedback uppmuntrar LLMs att ge strukturerad feedback. Specifikt tenderar LLM-svar att vara ordrika och fyllda med punkter, utrop och rubriker.

Men i kontexten av conversational AI behöver LLMs efterlikna den koncisa och platta naturen hos verbala interaktioner.

Antagandeluckor

LLMs har en tendens att fylla okända med antagen kunskap istället för att ställa frågor. Detta kan leda till att de gör felaktiga antaganden som vilseleder användare — eller leder till kostsamma misstag (t.ex. lovade återbetalningar). Senare kommer vi att se hur vi kan använda en kunskapsbas och skyddsräcken för att bättre förankra LLMs från att ge felaktiga löften och utföra otillåtna handlingar.

Fördröjning

LLMs kan programmatiskt anropa funktionssamtal, samla in och skriva data på människors vägnar. Även om detta generellt är en av de största fördelarna med LLMs, betyder det också att tidigare träningsinstruktioner, som tillät samtalsagenter att “köpa tid” medan de utförde uppgifter, inte längre behövs. Men funktionssamtal är inte heller omedelbara, vilket betyder att LLMs behöver noggrant förvarna användaren när en fördröjning förväntas (t.ex. “ge mig ett ögonblick för att undersöka ditt fall”).

Konfigurationer

Personlighet

LLMs är ganska framgångsrika på att justera tonen för att matcha en stil. En LLM kan konfigureras för att låta vänlig, humoristisk, koncis, formell eller en kombination av stilar. Detta är en viktig inmatning när man ger instruktioner till en LLM.

Till exempel kan utvecklare av en kundtjänst conversational AI-applikation designad för att stödja missnöjda flygbolagskunder använda en instruktion som:

Format

LLMs behöver få tydliga instruktioner om hur de ska svara. För att säkerställa att de inte inkluderar extra text, bör LLMs ges en struktur som kapslar in svaret som skickas till användaren.

Till exempel kan LLMs instrueras att:

Denna struktur uppmuntrar LLM att ge ett svar som är designat att läsas upp.

Men LLMs kan ibland snubbla på saker som kanske inte intuitivt 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, “tio tusen och tjugotre.” Istället bör LLM uttryckligen instrueras att säga siffrorna individuellt, och ange vad siffrorna betyder, t.ex. “Postnumret är ett noll noll två tre.”

Temperatur

Temperatur är en kritisk parameter när man konfigurerar LLMs för conversational AI. En lägre temperatur ger mer fokuserade, deterministiska svar som är idealiska för uppgiftsorienterade konversationer, medan högre temperaturer skapar mer kreativa, varierade svar.

En låg temperatur är idealisk för conversational AI-system som kanske föredrar konsekventa svar (t.ex. en kundtjänstlinje för återbetalningar). Samtidigt, för system som vill ge en mer engagerande och realistisk känsla till kunder (t.ex. en digital coach), är en hög temperatur bättre:

Kunskapsbaser

För conversational AI-system som utnyttjar större kunskapsreservoarer bör en kunskapsbas användas för att minimera instruktionens längd. I produktion uppnås detta vanligtvis via en vektordatabas (som Pinecone eller Elasticsearch) eller LLM-leverantörens direkta kunskapslager.

Generellt sett är kunskapsbaser väsentliga för att förankra LLM-svar i faktuell, godkänd information. När du bygger ett conversational AI-system bör du förse LLM med en omfattande kunskapsbas som innehåller korrekt, uppdaterad information om produkter, tjänster, policyer och procedurer. Detta förhindrar att LLM hallucinerar eller hittar på information samtidigt som det uppmuntrar konsekventa och pålitliga svar över konversationer.

Process

Eftersom LLMs ofta anropar funktioner på användarens vägnar, behöver de också veta vilka inmatningar som uttryckligen behövs. Till exempel, om en LLMs jobb är att hjälpa en användare att boka en klipptid, behöver de säkerställa att de har:

1. Användarens namn
2. Det önskade datumet och tiden
3. Användarens adress
4. Användarens tjänstepreferens

En naiv implementering kan resultera i att LLM frågar efter all information i ett enda samtal. Detta är helt okej som text, men i en konversation kan det bli överväldigande:

Eftersom information vanligtvis samlas in stegvis via konversation, måste LLMs uppmuntras att hämta denna information bit för bit. Resultatet är en mycket mer konversationell upplevelse:

Skyddsräcken

Behörigheter

När du bygger distribuerade system antar du att din server kommer att krascha vid något tillfälle. På samma sätt, när du bygger AI-system, bör du anta att din LLM kommer att göra ett misstag vid något tillfälle. För att minimera skadans omfattning bör du ge dessa system de lägsta behörigheterna som behövs för jobbet. Nedan följer några exempel på hur du kan göra detta:

• Ställ in läs-/skrivbehörigheter korrekt: Om LLM endast behöver läsa information från en datakälla, se till att den får en skrivskyddad slutpunkt.
• Begränsa åtkomst till API-slutpunkter: Om LLM endast behöver åtkomst till vissa slutpunkter, se till att den inte kan komma åt några andra.
• Människa-i-slingan eskaleringar: Om en högriskåtgärd behöver vidtas, överväg ett människa-i-slingan arbetsflöde som kräver “chefs godkännande” innan åtgärden utförs.

Validering och Verifiering

När du skapar konversations- AI-röstagent system som vidtar åtgärder genom verktygsanvändning, är det bra att bygga in en validerings- och verifieringsprocess för att säkerställa att du samlar in korrekt information från användare. Idag, när du pratar med en mänsklig agent, kommer de att upprepa all kritisk information du ger för att verifiera att de hörde rätt och att kunden inte sa fel. LLMs kan dra nytta av en liknande nivå av felkontroll:

För validering bör all information som tas emot från kunden kontrolleras mot den typiska strukturen för den informationen. Har telefonnumret rätt antal siffror? Faller åldern som kunden angav inom ett rimligt intervall? Gav kunden en giltig adress?

Beroende på ditt användningsfall kan du verifiera all mottagen information eller endast information som inte klarade verifieringen. Dessutom kan du välja att verifiera varje informationsdel när den kommer in eller verifiera allt i slutet.

En avslutande tanke

Att framgångsrikt ge instruktioner till ett konversations- AI-agent system innebär att balansera rätt konfigurationer och skyddsräcken för att skapa en upplevelse som efterliknar att prata med en människa med ökad effektivitet. Processen är inte så trivial som att använda gamla träningsmaterial för att ge instruktioner till en LLM; istället är LLMs verktyg som behöver specialiserad struktur och strategi för att skapa förutsägbara, effektiva resultat.