Jag Tränade en AI-Chatbot på Mina Företagsdokument på Femton Minuter

Vad räknas som kunskap och hur fungerar uppladdningen

Kunskapsupladdningen accepterar ett stort utbud av dokumentformat som omfattar hur de flesta företag lagrar sin institutionella kunskap. PDF-filer med produktmanualer, Word-dokument som innehåller policybeskrivningar, textfiler med FAQ-samlingar, Markdown-filer med teknisk dokumentation och vanlig textexport från wiki-system är alla giltiga kunskapskällor. Systemet absorberar dessa dokument, delar dem in i semantiskt sammanhängande delar och indexerar dem på ett sätt som gör att chatboten kan hämta relevanta passager när den svarar på frågor.

Kvaliteten på chatbotens svar beror direkt på kvaliteten och fullständigheten hos den uppladdade kunskapen. En produktmanual som noggrant beskriver funktioner, användningsfall, begränsningar och felsökningssteg producerar en chatbot som kan svara på detaljerade produktfrågor med noggrannhet. Ett sparsamt dokument som bara täcker grundläggande funktioner producerar en chatbot som kan svara på grundläggande frågor men skjuter upp något mer specifikt. Detta är inte en begränsning av tekniken utan en reflektion av den grundläggande principen att chatboten vet vad den har blivit tillsagd, och att berätta mer producerar bättre resultat.

Uppladdningsprocessen hanterar dokumentformatering automatiskt, tar bort irrelevant layoutinformation samtidigt som den bevarar den semantiska struktur som är viktig för förståelse. Rubriker blir sektionsgränser. Punktlistor blir uppräkningsbara objekt. Tabeller behåller sina rad-kolumn-relationer. Målet är att extrahera informationsinnehållet från dokumentet samtidigt som man kastar presentationslagret, eftersom chatboten måste förstå vad dokumentet säger, inte vilken typsnitt det använder. Denna automatiserade behandling eliminerar behovet av manuell dokumentförberedelse, vilket betyder att befintliga företagsdokument kan laddas upp som de är utan omformatering.

Flera dokument kan laddas upp för att bygga en omfattande kunskapsbas som sträcker sig över olika aspekter av verksamheten. En fullständig installation kan innehålla en produktkatalog, en kundtjänsthandboken, en teknisk FAQ, en prisguide och ett företagsöversiktsdokument. Varje dokument bidrar till en annan aspekt av chatbotens kunskap, och systemet integrerar dem sömlöst så att en enskild samtal kan hämta information från flera källor. En kund som frågar om en produktfunktion och sedan frågar om prissättning får sammanhängande svar på båda frågorna även om informationen kommer från olika uppladdade dokument.

Användningsfall och Att Lära Chatboten Vad den Ska Göra

Att ladda upp kunskap berättar för chatboten vad den vet. Att definiera användningsfall berättar vad den ska göra med denna kunskap. Ett användningsfall är en beskrivning av ett samtalsscenario som chatboten bör vara beredd att hantera: att svara på produktfrågor, guida användare genom en installationsprocess, kvalificera försäljningsleads, hantera supportärenden eller något annat samtalsmål som överensstämmer med verksamhetens behov.

Användningsfall fungerar som beteendeguidelinjer som formar hur chatboten tillämpar sin kunskap. Utan definierade användningsfall svarar chatboten på frågor genom att hämta relevant kunskap och presentera den. Med definierade användningsfall förstår chatboten inte bara vilken information som ska tillhandahållas utan hur man strukturerar samtalet kring denna information. Ett supportanvändningsfall kan instruera chatboten att ställa förtydligande frågor innan den tillhandahåller lösningar. Ett försäljningskvalificeringsanvändningsfall kan instruera den att samla in information om prospektets behov innan den rekommenderar produkter. Ett allmänt FAQ-användningsfall kan instruera det att tillhandahålla direkta svar utan omfattande introduktion.

Processen för att definiera användningsfall kräver inte programmerings- eller prompt engineering-expertis. Varje användningsfall beskrivs på naturligt språk: vilken typ av frågor eller förfrågningar användaren kan ha, vilken information chatboten ska tillhandahålla, vilken ton den ska använda och vilka åtgärder den ska föreslå. Systemet översätter dessa beskrivningar till beteendeparametrar som styr chatbotens svar. En icke-teknisk företagsägare kan definiera användningsfall lika effektivt som en utvecklare, eftersom definitionerna uttrycks på samma naturliga språk som chatboten själv använder.

Antalet och specificiteten hos användningsfall bör återspegla chatbotens avsedda omfattning. En kundsupportchatbot kan behöva tio till femton användningsfall som täcker olika supportkategorier. En enkel FAQ-chatbot kan behöva tre eller fyra. En försäljningskvalificerings-chatbot kan behöva fem till sju användningsfall som täcker olika produktlinjer eller kundsegment. Att börja med färre, bredare användningsfall och förfina in i mer specifika baserat på faktiska samtalmönster är ett praktiskt tillvägagångssätt som producerar goda resultat snabbt och förbättras över tid när användningsdata avslöjar vilka scenarier som behöver mer detaljerad hantering.

Det Första Samtalet och Vad Chatboten Faktiskt Vet

Sanningens stund kommer när den första riktiga frågan ställs. Inte en testfråga som utvecklaren redan vet svaret på, utan en genuint fråga från någon som förväntar sig ett användbart svar. Detta är där kvaliteten på kunskapsbasen och klarheten i användningsfallen antingen lönar sig eller avslöjar luckor. En väl förberedd chatbot hanterar den första frågan säkert, vilket ger ett korrekt svar hämtat från den uppladdade kunskapen och presenterat i en ton som överensstämmer med de definierade användningsfallen. En dåligt förberedd chatbot fuckar upp och tillhandahåller generiska svar som kan gälla för vilket företag som helst eller avleder med variationer på "vänligen kontakta support för mer information".

De första dagarna av live-drift är mest värdefulla för att förbättra chatbotens effektivitet. Samtal avslöjar de frågor som verkliga användare faktiskt ställer, vilket ofta skiljer sig betydligt från de frågor som företaget förväntade sig att de skulle ställa. En produktchatbot kan få fler frågor om prissättning och tillgänglighet än om funktioner, vilket tyder på att kunskapsbasen behöver starkare prisdokumentation. En supportchatbot kan få frågor formulerade på sätt som användningsfallsdefinitionerna inte förväntade sig, vilket föreslår förfinningar av de conversationella riktlinjerna.

Att iterera på kunskapsbasen och användningsfallen baserat på verklig samtalsdata är nyckeln till snabb förbättring. Varje samtal som producerar ett otillfredsställande svar identifierar ett specifikt gap: antingen kunskapsbasen saknar den relevanta informationen, eller användningsfallsdefinitionen styr inte chatboten att tillämpa tillgänglig information korrekt. Att åtgärda dessa luckor är inkrementellt arbete, lägga till ett dokument här, förfina ett användningsfall där, och varje förbättring gynnar alla framtida samtal som berör samma ämne. Chatboten blir meningsfullt bättre med varje omarbetningsomgång, och förbättringshastigheten är högst under de första veckorna när de vanligaste luckorna identifieras och fylls.

Inlärningskurvan för chatbotens underhållare är lika snabb. Vid slutet av den första veckan förstår den person som hanterar chatboten vilken typ av kunskap som producerar de bästa svaren, hur specifika användningsfallsdefinitioner måste vara och vilka samtalmönster som kräver uppmärksamhet. Denna operativa bekantskap, vunnen genom direkt erfarenhet snarare än läsning av dokumentation, är vad som omvandlar chatboten från ett verktyg för installation-och-glömt till en kontinuerligt förbättrad tillgång som blir mer värdefull för verksamheten med varje förflutande vecka.

Ingen ML-expertis Krävs och Vad Det Faktiskt Betyder

Påståendet att ingen maskinläring-expertis krävs förtjänar att packas upp eftersom det låter som marknadsföringsspråk och det är viktigt att förklara varför det är genuint sant. ChatBot API hanterar alla tekniskt komplexa operationer internt: dokumentdelning, vektorinbäddning, semantisk sökning, sammanhangsfönstershantering, promptkonstruktion och svargenerering. Dessa är de operationer som kräver ML-kunskap för att implementera från början. De kräver inte ML-kunskap för att användas genom ett API som abstraherar dem bakom ett enkelt gränssnitt.

De färdigheter som krävs för att ställa in och underhålla en chatbot genom detta system är helt icke-tekniska: förmågan att organisera företagskunskap i dokument, förmågan att beskriva samtalsscenarier på naturligt språk och förmågan att läsa samtalsloggar och identifiera var svaren blev otillräckliga. Dessa är färdigheter som alla affärschefer, kundsupportledare eller marknadsföringsproffs besitter. Den tekniska infrastrukturen hanteras av API:et, och affärsintelligensen hanteras av de personer som förstår verksamheten.

Denna ansvarsfördeling är vad som gör femton-minutersutplacering realistisk snarare än aspirativ. De tekniskt svåra delarna är redan lösta och körs som en tjänst. De affärsspecifika delarna, som endast verksamheten kan tillhandahålla, är enkla att tillhandahålla genom dokumentuppladdning och naturligt språk användningsfallsdefinitioner. Skärningen av dessa två inmatningar producerar en chatbot som kombinerar de conversationella förmågorna hos en stor språkmodell med den specifika kunskapen och de beteendeguidelinjer som gäller för verksamheten, utan att kräva att någon inblandad förstår hur varken språkmodellen eller kunskapshämtningssystemet fungerar internt.

Resultatet är en chatbot som vet dina produkter, talar i ditt varumärkes ton, hanterar de scenarier du definierar och förbättras när du matar den bättre kunskap och tydligare riktlinjer. Hela ML-pipelinen körs bakom kulisserna, osynlig för affärsanvändaren, vilket är precis hur det bör fungera. Verksamheten behöver inte förstå transformers och inbäddningar mer än en förare behöver förstå bränsleinsprutning och växellådsteknik. Fordonet fungerar. Destinationen nås. Motordetaljerna är någon annans angelägenhet.