Teknologi ensam garanterar inte antagande: Lärdomar från att bygga en intern AI-chattbot

När AI-användningen accelererade över branscherna, verkade det logiskt att distribuera en chattbot för att stödja en nyligen lanserad intern applikation. Applikationen i sig utmanade dock konventionella användarförväntningar. Den introducerade nya arbetsflöden byggda på ny teknik som var främmande för de flesta användare.

För att minska friktion och förbättra antagande, designades chattboten för att svara på frågor om applikationen och den underliggande tekniken. Målet var att hjälpa användare att förstå inte bara vad de skulle göra, utan också varför systemet betedde sig på det sätt det gjorde. Vi trodde att tillhandahållande av kontextuella förklaringar skulle accelerera inlärning och minska förvirring.

Från början var AI-agenten tänkt som en lösning med begränsad omfattning. Den var designad strikt för att stödja dokumentation och ge användarstöd. Konceptuellt var chattboten tänkt att fungera som en dynamisk ersättning för en traditionell Vanliga frågor-dokument, som erbjöd en konversationsbaserad, sökbar och kontinuerligt tillgänglig gränssnitt med utökad funktionalitet bortom statiskt innehåll.

För att integrera agenten i organisationens interna chattmiljö, behövde vi förstå hur strukturerade meddelanden renderades, hur konversationshistorik lagrades och hur systemet identifierade deltagare inom trådar. Detta gjorde att vi kunde bestämma de grundläggande variablerna som krävdes för att börja bearbeta användarfrågor.

Att förankra modellen: Från hallucination till tillförlitlig kontext

Stora språkmodeller är kraftfulla, men utan kontextuell förankring är de benägna att hallucinera. För att hantera detta, implementerade vi en vektorembeddningsteknik.

Användarhandböcker, intern dokumentation och produktvisionen omvandlades till numeriska vektorella representationer av text. Dessa inbäddningar fångade semantisk mening, vilket gjorde att systemet kunde matcha koncept snarare än att förlita sig på enkel nyckelordsmatchning.

När en användare ställde en fråga, omvandlade systemet frågan till en vektorell representation och jämförde den med de lagrade inbäddningarna. Det hämtade de mest semantiskt relevanta dokumenten och injicerade dem i modellens prompt. Modellen genererade sedan ett svar som var förankrat i dessa specifika dokument, ofta sammanfattande den relevanta informationen.

Detta tillvägagångssätt förbättrade signifikant svarsaccuracitet. Istället för att generera svar baserat på ren allmän kunskap, svarade modellen med hjälp av vår organisations egen dokumentation som kontext.

Den dolda komplexiteten i kontextshantering

Det var avgörande att inkludera konversationshistorik i prompten så att boten kunde tolka uppföljningsfrågor och upprätthålla kontinuitet. Utan historia blev interaktioner fragmenterade och upprepade. Användare förfinade ofta sina frågor gradvis, och utan kontext kunde boten inte tolka referenser som “den där alternativet” eller “det föregående steget.”

Men att inkludera för mycket historia skapade ett annat problem: tokenbegränsningar. Dessa uppstår när språkmodeller trunkerar indata som överskrider deras maximala kontextfönster. Om en fråga eller konversation blev för lång, kunde viktig information gå förlorad. Detta producerade inte ett explicit fel, men snarare försämrade svarsqualitet eller påverkade hämtningsaccuracitet.

För att mildra detta, implementerade vi strategier för att kontrollera promptstorlek, prioritera relevant innehåll och övervaka frågelängd. Vi experimenterade med att sammanfatta äldre meddelanden och selektivt inkludera endast de mest relevanta delarna av konversationen. Kontext var avgörande, men den måste hanteras noggrant.

Att utöka funktioner och skapa förvirring

Utöver att svara på dokumentbaserade frågor, utvidgade vi botens funktioner genom att lägga till bakändsfunktioner som kunde hämta viss offentlig information direkt från applikationen. Detta tillät användare att hämta data från chatten utan att logga in i appen själv. Idén var att minska friktion och förstärka chattboten som ett användbart gränssnitt, inte bara ett statiskt kunskapslager.

Den här utvidgningen skapade dock förvirring för vissa användare. När boten började hämta live-data, började användare fråga den om att utföra åtgärder som krävde direkt interaktion inom plattformen. De antog att chattboten kunde ersätta operativa steg, inklusive de som krävde autentisering eller medveten exekvering inom plattformen.

Boten var aldrig designad för att utföra dessa åtgärder, men skillnaden mellan informationsbaserat stöd och operativ exekvering var inte alltid tydlig.

Att integrera live-data introducerade också nya tekniska överväganden. Vi behövde definiera när en fråga skulle gå genom inbäddningsbaserad hämtning och när den skulle utlösa en bakändsfunktion. Den beslutslogiken krävde noggrann design. Dessutom behövde vi justera svar för att hantera tekniska undantag på ett snyggt sätt och undvika att exponera råa systemfel för användare.

Multispråkig kapacitet är inte automatisk

Under testning, insåg vi att boten konsekvent presterade bättre på engelska än på andra språk som användes inom Jalasoft. Den primära anledningen var strukturell: de flesta av dokumentationen som användes för att generera inbäddningar var skriven på engelska, och inbäddningsmodellen vi valde var optimerad för engelsk semantisk likhet.

Den stödde inte tvåspråkig hämtning eller semantisk jämförelse över språk. Som ett resultat, hämtade icke-engelska frågor ofta mindre relevanta dokument, vilket ledde till svagare svar.

Detta belyste en viktig insikt: multispråkig kapacitet är inte automatisk.

När förväntningar expanderar bortom omfattning

För att kontrollera användningskostnader, implementerade vi en daglig gräns för antalet frågor som användare kunde ställa. Men vi begränsade inte explicit omfattningen av dessa frågor. Användare var fria att fråga vad som helst.

Den här öppenheten ledde till oväntade användningsmönster. Vissa användare började interagera med boten för personliga eller utforskande ändamål som inte var relaterade till applikationen. Över tiden, växte förväntningarna bortom botens avsedda roll, vilket skapade en gap mellan vad användare hoppades den kunde göra och vad den var designad för att stödja.

Detta missförhållande minskade gradvis dess upplevda användbarhet. Användning minskade, och chattboten avvecklades slutligen, med ansträngningar omriktade mot att omforma applikationen själv för att göra den mer intuitiv och lättare att använda.

Den verkliga lärdomen: Interaktionsdesign.

Från ett tekniskt perspektiv, fungerade systemet relativt bra. Det hämtade dokumentation, inkorporerade konversationshistorik, minskade hallucinationer genom inbäddningar, hanterade bakändsfunktioner och kontrollerade promptstorlek. Arkitekturen fungerade som avsett.

Men den saknade avsiktlig interaktionsdesign.

Boten formade inte tydligt samtal. Den förstärkte inte konsekvent sin omfattning. Den guidade inte användare med strukturerade exempel på vad den kunde och inte kunde göra. Den svarade på frågor, men den satte inte förväntningar.

Vi lärde oss att konversationsbaserade AI-system kräver mer än starka modeller och strukturerad data. De kräver noggrant designade förväntningar. Användare behöver tydlighet om agentens roll, dess gränser och dess styrkor. Systemet måste proaktivt tillhandahålla exempelpromptar, förklara begränsningar och omdirigera frågor som ligger utanför omfattningen konsekvent.

Utan denna avsiktliga ram, kan även en tekniskt sund implementering kämpa för att upprätthålla värde. Användare kan överskatta kapacitet eller koppla bort när outtalade förväntningar inte uppfylls.

Den centrala insikten är enkel men kraftfull.

Att bygga konversationsbaserad AI är inte bara en teknisk utmaning. Det är också en interaktionsdesignutmaning.

Stark kontext, exakt hämtning och robust arkitektur är nödvändiga, men inte tillräckliga. Systemets effektivitet beror lika mycket på hur det definierar sin roll, kommunicerar sina gränser och formar användarförväntningar.

Teknologi ensam garanterar inte antagande. Tydlig interaktionsdesign gör.