Udtrykket "at træne en AI" bærer konnotationer af massive datasæt, GPU-klynger, machine learning-ekspertise, og den slags computerkraft, som kun velfinansierede forskningstudier kan tillade sig. Denne opfattelse, selvom præcis for at bygge fundamentale modeller fra bunden, er enormt misvisende, når det kommer til at skabe en chatbot, der forstår din specifikke virksomhed. Sondringen betyder noget, fordi det forhindrer tusinder af virksomheder i at implementere conversational AI-løsninger, der ikke blot ligger inden for deres rækkevidde, men kan implementeres på mindre tid, end det tager at skrive en mødeagenda.
At træne en chatbot på virksomhedsspecifik viden kræver ikke at træne en sprogmodel fra bunden. Det kræver at give en eksisterende sprogmodel den kontekst, den har brug for til at besvare spørgsmål om din virksomhed præcist. Modellen ved allerede, hvordan man forstår spørgsmål, konstruerer sammenhængende svar og opretholder conversational flow. Det, der mangler, er kendskab til dine specifikke produkter, politikker, procedurer og terminologi. At levere denne viden handler om at uploade dokumenter, ikke om at køre træningsloops på tværs af tusinder af GPU'er. Processen ligner nærmere at give en ny medarbejder en orienteringsmappe end det ligner noget, der minder om machine learning-forskning.
ChatBot API'en på yeb.to gør denne proces eksplicit og strømlinet. Upload dine viden-dokumenter. Systemet behandler dem til en søgbar viden-base. Definer use cases, der beskriver, hvad chatbotten skal være i stand til at gøre. Start samtaler. Chatbotten trækker på den uploadede viden for at besvare spørgsmål, give information og vejlede brugere gennem processer, der er specifikke for din virksomhed. Femten minutter fra første upload til første brugbar samtale er ikke markedsføringoptimisme. Det er den faktiske tidslinje, når viden-dokumenterne allerede er organiseret, og use cases er klare.
Hvad der tæller som viden, og hvordan uploaden fungerer
Viden-uploaden accepterer en række dokumentformater, der dækker de måder, de fleste virksomheder gemmer deres institutionelle viden på. PDF'er af produktmanualer, Word-dokumenter indeholdende politikhåndbøger, tekstfiler med FAQ-kompilationer, Markdown-filer med teknisk dokumentation og almindelig teksteksport fra wiki-systemer fungerer alle som gyldige videnskilder. Systemet optager disse dokumenter, bryder dem ned i semantisk sammenhængende chunks og indekserer dem på en måde, der gør det muligt for chatbotten at hente relevante passager, når den besvarer spørgsmål.
Kvaliteten af chatbottens svar afhænger direkte af kvaliteten og fuldstændigheden af den uploadede viden. En produktmanual, der grundigt beskriver funktioner, use cases, begrænsninger og fejlfindingstrin, producerer en chatbot, der kan besvare detaljerede produktspørgsmål med nøjagtighed. Et sparsomt dokument, der kun dækker basale funktioner, producerer en chatbot, der kan besvare basale spørgsmål, men udviger på alt mere specifikt. Dette er ikke en begrænsning af teknologien, men en afspejling af det fundamentale princip, at chatbotten ved, hvad den er blevet fortalt, og at fortælle den mere giver bedre resultater.
Uploadprocessen håndterer dokumentformatering automatisk, fjerner irrelevant layoutinformation, mens den bevarer den semantiske struktur, der betyder noget for forståelse. Headers bliver sektionsgrænser. Punkter bliver opregningsbare elementer. Tabeller opretholder deres række-kolonne-forhold. Målet er at udtrække informationsindholdet fra dokumentet, mens man kasserer præsentationslaget, fordi chatbotten skal forstå, hvad dokumentet siger, ikke hvilken skrifttype det bruger. Denne automatiserede behandling eliminerer behovet for manuel dokumentforberedelse, hvilket betyder, at eksisterende virksomhedsdokumenter kan uploades, som de er, uden omformatering.
Flere dokumenter kan uploades for at opbygge en omfattende viden-base, der spænder over forskellige aspekter af virksomheden. En komplet opsætning kunne omfatte et produktkatalog, en kundeservicemanual, en teknisk FAQ, en prisvejledning og et virksomhedsoversigt dokument. Hver dokument bidrager til et andet aspekt af chatbottens viden, og systemet integrerer dem problemfrit, så en enkelt samtale kan trække på information fra flere kilder. En kunde, der spørger om en produktfunktion og derefter spørger om prissætning, modtager sammenhængende svar på begge spørgsmål, selvom informationen kommer fra forskellige uploadede dokumenter.
Use cases og at lære chatbotten, hvad den skal gøre
Upload af viden fortæller chatbotten, hvad den ved. At definere use cases fortæller den, hvad den skal gøre med denne viden. En use case er en beskrivelse af et conversationelt scenarie, som chatbotten skal være forberedt på at håndtere: besvare produktspørgsmål, vejlede brugere gennem en opsætningsproces, kvalificere salgsemner, håndtere supportforespørgsler, eller ethvert andet conversationelt mål, der stemmer overens med virksomhedens behov.
Use cases fungerer som adfærdsvejledninger, der former, hvordan chatbotten anvender sin viden. Uden definerede use cases reagerer chatbotten på spørgsmål ved at hente relevant viden og præsentere den. Med definerede use cases forstår chatbotten ikke blot, hvilken information der skal leveres, men også hvordan man strukturerer samtalen omkring denne information. En support use case kunne instruere chatbotten til at stille præciseringsspørgsmål, før den giver løsninger. En salgskvalificering use case kunne instruere den til at indsamle information om prospektets behov, før den anbefaler produkter. En generel FAQ use case kunne instruere den til at give direkte svar uden omfattende indledning.
Processen med at definere use cases kræver ikke programmering eller prompt engineering-ekspertise. Hver use case er beskrevet på naturligt sprog: hvilken type spørgsmål eller anmodninger brugeren kunne have, hvilken information chatbotten skal give, hvilken tone den skal bruge, og hvilke handlinger den skal foreslå. Systemet oversætter disse beskrivelser til adfærdsparameter, der vejleder chatbottens svar. En ikke-teknisk virksomhedsejer kan definere use cases lige så effektivt som en udvikler, fordi definitionerne udtrykkes på det samme naturlige sprog, som chatbotten selv bruger.
Antallet og specificiteten af use cases skal afspejle chatbottens tilsigtede omfang. En kundeservice-chatbot kan have brug for ti til femten use cases, der dækker forskellige supportkategorier. En simpel FAQ-chatbot har måske brug for tre eller fire. En salgskvalificerings-chatbot kan have brug for fem til syv use cases, der dækker forskellige produktlinjer eller kundesegmenter. At starte med færre, bredere use cases og forfine sig til mere specifikke baseret på faktiske conversationsmønstre er en praktisk tilgang, der producerer gode resultater hurtigt og forbedres over tid, da brugsdata afslører, hvilke scenarier der har brug for mere detaljeret håndtering.
Den første samtale og hvad chatbotten faktisk ved
Det afgørende øjeblik ankommer, når det første rigtige spørgsmål stilles. Ikke et testspørgsmål, som udvikler allerede kender svaret på, men et ægte spørgsmål fra nogen, der forventer et brugbart svar. Dette er hvor kvaliteten af viden-basen og klarheden af use cases enten viser sig eller afslører huller. En velpreparet chatbot håndterer det første spørgsmål selvfølgeligt, giver et nøjagtigt svar, der er hentet fra den uploadede viden og præsenteret i en tone, der stemmer overens med de definerede use cases. En dårligt preparet chatbot fumler, giver generiske svar, der kan gælde enhver virksomhed eller udviger med variationer af "kontakt venligst support for mere information."
De første få dage af live-operation er mest værdifulde for at forbedre chatbottens effektivitet. Samtaler afslører de spørgsmål, som rigtige brugere faktisk stiller, hvilket ofte er meget forskelligt fra de spørgsmål, virksomheden forventede, at de ville stille. En produkt-chatbot kan modtage flere spørgsmål om prissætning og tilgængelighed end om funktioner, hvilket tyder på, at viden-basen skal have stærkere prisdokumentation. En support-chatbot kan modtage spørgsmål formuleret på måder, som use case-definitionerne ikke forventede, hvilket tyder på justeringer af de conversationale retningslinjer.
At iterere på viden-basen og use cases baseret på rigtige samtaledata er nøglen til hurtig forbedring. Hver samtale, der producerer et utilfredsstillende svar, identificerer et specifikt hul: enten mangler viden-basen den relevante information, eller use case-definitionen vejleder ikke chatbotten til at anvende tilgængelig information korrekt. At imødegå disse huller er inkrementel arbejde, tilføjelse af et dokument her, raffinement af en use case der, og hver forbedring gavner alle fremtidige samtaler, der rører samme emne. Chatbotten bliver betydeligt bedre med hver runde af raffinement, og hastigheden for forbedring er hurtigst i de første par uger, når de mest almindelige huller bliver identificeret og udfyldt.
Læringskurven for chatbottens vedligeholdere er lige så hurtig. Ved slutningen af den første uge forstår personen, der administrerer chatbotten, hvilken slags viden, der producerer de bedste svar, hvor specifikke use case-definitioner skal være, og hvilke conversationale mønstre, der kræver opmærksomhed. Denne operationelle fortrolighed, opnået gennem direkte erfaring i stedet for dokumentationslæsning, er hvad der omdanner chatbotten fra et setup-og-glem-værktøj til et kontinuerligt forbedret aktiv, der bliver mere værdifuldt for virksomheden med hver forløbende uge.
Ingen ML-ekspertise påkrævet og hvad det faktisk betyder
Påstanden om, at ingen machine learning-ekspertise er påkrævet, fortjener at blive pakket ud, fordi det lyder som markedsføringssprog, og det er vigtigt at forklare, hvorfor det faktisk er sandt. ChatBot API'en håndterer alle de teknisk komplekse operationer internt: dokumentchunking, vektorindlejring, semantisk søgning, kontekstvinduesstyring, prompt-konstruktion og svargenerering. Disse er de operationer, der kræver ML-viden at implementere fra bunden. De kræver ikke ML-viden at bruge gennem en API, der abstraherer dem bag et simpelt interface.
De færdigheder, der kræves for at opsætte og vedligeholde en chatbot gennem dette system, er helt ikke-tekniske: evnen til at organisere virksomhedsviden ind i dokumenter, evnen til at beskrive conversationale scenarier på naturligt sprog, og evnen til at læse samtalelogger og identificere, hvor svar faldt til kort. Dette er færdigheder, som enhver virksomhedsleder, kundeservice-leder eller marketingfagperson besidder. Den tekniske infrastruktur håndteres af API'en, og virksomhedsintelligensen håndteres af de mennesker, der forstår virksomheden.
Denne ansvarsfordeling er hvad der gør femten-minutter-deployment realistisk i stedet for aspirationalt. De teknisk svære dele er allerede løst og kører som en service. De virksomhedsspecifikke dele, som kun virksomheden kan levere, er ligetil at levere gennem dokumentupload og naturligt sproget use case-definitioner. Skæringspunktet for disse to inputs producerer en chatbot, der kombinerer conversationale evner fra en stor sprogmodel med specifik viden og adfærdsvejledninger fra virksomheden, uden at kræve, at nogen involveret forstår, hvordan sprogmodellen eller videnindsamlingssystemet fungerer internt.
Resultatet er en chatbot, der kender dine produkter, taler i din brands tone, håndterer de scenarier, du definerer, og forbedres, når du fodrer den med bedre viden og klarere retningslinjer. Hele ML-pipelinen kører bag kulisserne, usynlig for forretningsbrugeren, hvilket er præcis sådan det burde fungere. Virksomheden behøver ikke at forstå transformers og embeddings mere end en chauffør skal forstå brændstofindsprøjtning og transmissionsteknik. Køretøjet fungerer. Destinationen nås. Motordetaljerne er en andens problem.