Hur du Använder en Conversational AI

Today, the LLM has emerged as the beating heart of conversational AI systems. Specifically, LLMs enable conversational AI—originally built around sprawling phone trees—to feature dynamic functionality and provide human-like experiences. However, LLMs aren’t a silver bullet upgrade; they require specialized prompting as they aren’t fine-tuned to human speech by default.

Developers make a common mistake when prompting LLMs for conversational AI: recycling the same playbook that was used to train human employees. This strategy, despite sounding straightforward, is rarely fruitful. LLMs make different assumptions than typical humans, and their default tone and scope aren’t conducive to verbal interactions.

Today, we’ll uncover what we know about how to prompt LLMs to build successful conversational AI systems.

The Old System

Prior to LLMs, conversational AI systems leveraged sprawling logic trees that requests would triage through based on verbal inputs. This setup was popular among customer service numbers (e.g., airline hotlines) and payment systems (e.g., credit card phone services).

These older systems were sluggish, felt robot-like, and could only permit very limited human inputs. There’s a fair chance you experienced this yourself, bluntly yelling “YES” into a phone to answer a prompt. This poor experience led most users to attempt to “beat the system” to force a conversation with a live human agent.

However, there was an advantage to these phone trees—they were contained. There were only so many paths a conversation could take, and developers could easily implement guardrails to disregard disallowed inputs. This constraint underpins the pros and cons of LLMs: They expand dramatically past the limited nature of phone trees, but they are also unpredictable, opening a Pandora’s box of pitfalls—such as making impossible promises, getting angry with customers, or breaching sensitive data.

The Default Gaps

If LLMs are simply trained on a handbook originally designed for humans, they’ll have mediocre success due to a few core gaps. Understanding these gaps will help you design prompts to address them:

Tone Mismatch

LLMs are trained via reinforcement learning, where human feedback incentivizes LLMs to return structured feedback. Specifically, LLM responses tend to be verbose and filled with bullets, call-out blocks, and headlines.

However, in the context of conversational AI, LLMs need to emulate the concise and flattened nature of verbal interactions.

Assumption Gaps

LLMs have a tendency to fill any unknowns with inferred knowledge instead of asking questions. This can lead them to make incorrect assumptions that’ll mislead users—or lead to costly mistakes (e.g., promised refunds). Later, we’ll see how we can use a knowledge base and guardrails to better ground the LLMs from making incorrect promises and executing disallowed actions.

Latency

LLMs can programmatically invoke function calls, gathering and writing data on behalf of humans. While this is generally one of the biggest advantages of LLMs, it also means that previous training instructions, which allowed call agents to “buy time” while performing tasks, are no longer needed. However, function calls aren’t instantaneous either, meaning that LLMs need to accurately forewarn the user whenever a delay is expected (e.g., “give me a moment to examine your case”).

Configurations

Personality

LLMs are fairly successful at augmenting tone to match a style. An LLM could be configured to sound friendly, humorous, concise, formal, or a combination of styles. This is an important input when prompting an LLM.

For example, developers of a customer service conversational AI application designed to support disgruntled airline customers might use a prompt such as:

You are a friendly customer service agent who speaks in concise, clear, empathetic sentences.

• Add section embedding three example ElevenLabs apps

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:

Respond exclusively with the string that should be read aloud to the user

Denna struktur uppmuntrar LLM att ge ett svar designat för 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 instrueras att säga siffrorna individuellt, och förklara 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 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:

Low Temperature: Thank you for calling ElevenLabs support. How can I help you?

Hög Temperatur: Hej hej! Du har kommit till ElevenLabs support—redo att lösa dina tekniska problem! Vad har du på hjärtat?

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 uppnås detta vanligtvis via en vektordatabas (som Pinecone eller Elasticsearch) eller LLM-leverantörens direkta kunskapslager.

Generellt sett är kunskapsbaser viktiga för att förankra LLM-svar i faktuell, godkänd information. När du bygger ett conversational AI-system bör du ge LLM 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 för användarens räkning, 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. Önskat datum och tid
3. Användarens adress
4. Användarens tjänstepreferens

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

Supportagent: Kan du ge mig ditt namn, din adress, när du vill ha din tjänst och vilken tjänst du vill ha?

Kund: Mitt namn är Mathew och när som helst på onsdag eftermiddag fungerar. Vad mer frågade du efter?

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:

Supportagent: Kan du ge mig ditt namn?

Kund: Mitt namn är Mathew Pregasen.

Supportagent: Tack Mathew. När vill du boka en tid?

Kund: När som helst på onsdag eftermiddag fungerar bra.

Supportagent: Bra. Kan jag få din adress för att hitta närmaste plats?

Kund: 555 West Main Street

Supportagent: Perfekt. Vilken tjänst söker du?

Kund: Jag letar efter en klippning och om du också kan fixa mitt skägg vore det toppen!

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 konsekvenserna av det misstaget 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 bara behöver läsa information från en datakälla, se till att den får en skrivskyddad åtkomstpunkt.
• Begränsa åtkomst till API-ändpunkter: Om LLM bara behöver åtkomst till vissa ändpunkter, 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 conversational AI-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:

Supportagent: Bra. Kan jag få din adress för att hitta närmaste plats?

Kund: 555 West Main Street

Supportagent: Jag fick fem fem fem west main street. Missade jag något?

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?

Supportagent: Vad skulle vara ett bra återuppringningsnummer för dig?

Kund: 317-798-97289

Supportagent: Jag tror att jag kan ha hört fel. Jag hörde 11 siffror. Skulle du kunna upprepa det igen?

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

En Avslutande Tanke

Att framgångsrikt instruera ett conversational AI-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 instruera en LLM; istället är LLMs verktyg som behöver specialiserad struktur och strategi för att skapa förutsägbara, effektiva resultat.