Jeg trenerte en AI-chatbot på mine bedriftsdokumenter på femten minutter

Uttrykket "trenering av AI" bærer med seg konnotasjoner av massive datasett, GPU-klynger, maskinlæringsekspertise, og den slags beregningsbudsjetter som bare velfinansierede forskningsteder har råd til. Denne oppfatningen, mens nøyaktig for bygging av grunnleggende modeller fra grunnen av, er villledende når det gjelder å lage en chatbot som forstår din spesifikke virksomhet. Skillet er viktig fordi det hindrer tusenvis av bedrifter fra å implementere løsninger for samtalebasert AI som ikke bare er innenfor deres rekkevidde, men kan distribueres på mindre tid enn det tar å skrive en møteagenda.

Trenering av en chatbot på firmaspesifikk kunnskap krever ikke trenering av en språkmodell fra grunnen av. Det krever å gi en eksisterende språkmodell den konteksten den trenger for å svare nøyaktig på spørsmål om virksomheten din. Modellen vet allerede hvordan man forstår spørsmål, konstruerer sammenhengende svar, og opprettholder samtaleflyt. Det som mangler er kunnskap om dine spesifikke produkter, retningslinjer, prosedyrer og terminologi. Å gi den kunnskapen er et spørsmål om å laste opp dokumenter, ikke om å kjøre treningsløkker på tusenvis av GPU-er. Prosessen ligner mer på å gi en ny ansatt en orienteringsmappe enn på noe som helst som ligner maskinlæringsforskning.

ChatBot API på yeb.to gjør denne prosessen eksplisitt og strømlinjeformet. Last opp kunnskapsdokumentene dine. Systemet behandler dem til en gjennomarbeidbar kunnskapsbase. Definer bruksscenarier som beskriver hva chatboten skal kunne gjøre. Start samtaler. Chatboten bruker den opplastede kunnskapen til å svare på spørsmål, gi informasjon, og guide brukere gjennom prosesser som er spesifikke for virksomheten din. Femten minutter fra første opplasting til første nyttig samtale er ikke markedsoptimisme. Det er den faktiske tidslinjen når kunnskapsdokumentene allerede er organisert og bruksscenarioene er klare.

Hva teller som kunnskap og hvordan opplastingsprosessen fungerer

Kunnskapsopplastingen godtar en rekke dokumentformater som dekker måtene de fleste bedrifter lagrer sin institusjonelle kunnskap på. PDF-er av produktmanualer, Word-dokumenter som inneholder politikhåndbøker, tekstfiler med FAQ-samlinger, Markdown-filer med teknisk dokumentasjon, og teksteksporter fra wiki-systemer fungerer alle som gyldige kunnskapskilder. Systemet inntaker disse dokumentene, deler dem inn i semantisk sammenhengende deler, og indekserer dem på en måte som tillater chatboten å hente relevante avsnitt når den svarer på spørsmål.

Kvaliteten på chatbotens svar avhenger direkte av kvaliteten og fullstendigheten på den opplastede kunnskapen. En produktmanual som grundig beskriver funksjoner, bruksscenarier, begrensninger, og feilsøkingstrinn, produserer en chatbot som kan svare på detaljerte produktspørsmål med nøyaktighet. Et sparsomt dokument som bare dekker grunnleggende funksjoner produserer en chatbot som kan svare på grunnleggende spørsmål, men avstår fra noe mer spesifikt. Dette er ikke en begrensning av teknologien, men en refleksjon av det grunnleggende prinsippet at chatboten vet hva den har blitt fortalt, og å fortelle den mer produserer bedre resultater.

Opplastingsprosessen håndterer dokumentformatering automatisk, fjerner irrelevant layoutinformasjon mens den bevarer den semantiske strukturen som er viktig for forståelse. Overskrifter blir seksjonsgrenser. Kulepunkter blir gjennomtellbare elementer. Tabeller opprettholder sine rad-kolonne-forhold. Målet er å trekke ut informasjonsinnholdet fra dokumentet mens man forkaster presentasjonslaget, fordi chatboten må forstå hva dokumentet sier, ikke hvilken skrifttype det bruker. Denne automatiserte behandlingen eliminerer behovet for manuell dokumentforberedelse, som betyr at eksisterende bedriftsdokumenter kan lastes opp som de er uten omformatering.

Flere dokumenter kan lastes opp for å bygge en omfattende kunnskapsbase som spenner over ulike aspekter av virksomheten. En fullstendig oppsett kan inneholde en produktkatalog, en kundeservicemanual, en teknisk FAQ, en prisguide, og et bedriftsoversiktsdokument. Hvert dokument bidrar til et annet aspekt av chatbotens kunnskap, og systemet integrerer dem sømløst slik at en enkelt samtale kan hente informasjon fra flere kilder. En kunde som spør om en produktfunksjon og deretter spør om prising, mottar sammenhengende svar på begge spørsmål selv om informasjonen kommer fra ulike opplastede dokumenter.

Bruksscenarier og å lære chatboten hva den skal gjøre

Opplasting av kunnskap forteller chatboten hva den vet. Definisjon av bruksscenarier forteller den hva den skal gjøre med den kunnskapen. Et bruksscenario er en beskrivelse av et samtaletilfelle som chatboten bør være forberedt på å håndtere: svare på produktspørsmål, guide brukere gjennom en oppsettsprosess, kvalifisere salgsemner, håndtere støtteanmodninger, eller noe annet samtaleformål som stemmer overens med virksomhetens behov.

Bruksscenarier fungerer som atferdsmessige retningslinjer som former hvordan chatboten bruker sin kunnskap. Uten definerte bruksscenarier, svarer chatboten på spørsmål ved å hente relevant kunnskap og presentere den. Med definerte bruksscenarier, forstår chatboten ikke bare hvilken informasjon som skal gis, men hvordan man strukturerer samtalen rundt den informasjonen. Et støttescenario kan instruere chatboten til å stille avklaringsspørsmål før den gir løsninger. Et salgskvalifiseringscenario kan instruere den til å samle informasjon om prospektets behov før den anbefaler produkter. Et generelt FAQ-scenario kan instruere den til å gi direkte svar uten omfattende introduksjon.

Definisjonen av bruksscenarier krever ikke programmerings- eller prompt-engineering-ekspertise. Hvert bruksscenario beskrives på naturlig språk: hva slags spørsmål eller forespørsler brukeren kan ha, hvilken informasjon chatboten skal gi, hvilken tone den skal bruke, og hvilke handlinger den skal foreslå. Systemet oversetter disse beskrivelsene til atferdsmessige parametere som styrer chatbotens svar. En ikke-teknisk bedriftseier kan definere bruksscenarier like effektivt som en utvikler, fordi definisjonene uttrykkes på det samme naturlige språket som chatboten selv bruker.

Antallet og spesifisiteten av bruksscenarier bør reflektere chatbotens tiltenkte omfang. En kundeupportchatbot kan trenge ti til femten bruksscenarier som dekker ulike støttekategorier. En enkel FAQ-chatbot kan trenge tre eller fire. En salgskvalifiseringschatbot kan trenge fem til sju bruksscenarier som dekker ulike produktlinjer eller kundesegmenter. Å starte med færre, bredere bruksscenarier og foredle til mer spesifikke basert på faktiske samtalemønstre er en praktisk tilnærming som produserer gode resultater raskt og forbedres over tid når brukerdata avslører hvilke scenarier som trenger mer detaljert håndtering.

Den første samtalen og hva chatboten faktisk vet

Sannhetens øyeblikk ankommer når det første virkelige spørsmålet stilles. Ikke et testspørsmål som utvikleren allerede vet svaret på, men et genuint spørsmål fra noen som forventer et nyttig svar. Dette er hvor kvaliteten på kunnskapsbasen og klarheten på bruksscenarioene enten betaler seg eller avslører mangler. En godt forberedt chatbot håndterer det første spørsmålet med selvtillit, og gir et nøyaktig svar hentet fra den opplastede kunnskapen og presentert i en tone som er konsistent med definerte bruksscenarier. En dårlig forberedt chatbot snubler, og gir generiske svar som kunne gjelde enhver bedrift eller utsetter med variasjoner av "vennligst kontakt support for mer informasjon."

De første dagene med aktiv drift er de mest verdifulle for å forbedre chatbotens effektivitet. Samtaler avslører spørsmålene som virkelige brukere faktisk stiller, som ofte skiller seg betydelig fra spørsmålene som bedriften forventet at de skulle stille. En produktchatbot kan motta flere spørsmål om prising og tilgjengelighet enn om funksjoner, noe som antyder at kunnskapsbasen trenger sterkere prisdokumentasjon. En støttechatbot kan motta spørsmål formulert på måter som bruksscenariodefinisjonen ikke forventet, noe som antyder refinement av retningslinjene for samtaler.

Iterering på kunnskapsbasen og bruksscenarier basert på virkelige samtaledata er nøkkelen til rask forbedring. Hver samtale som produserer et utilfredsstillende svar identifiserer en spesifikk mangel: enten mangler kunnskapsbasen den relevante informasjonen, eller bruksscenariodefinisjonen styrer ikke chatboten til å bruke tilgjengelig informasjon riktig. Å håndtere disse manglene er inkrementelt arbeid, adding et dokument her, refinement av et bruksscenario der, og hver forbedring gagner alle fremtidige samtaler som berører samme emne. Chatboten blir meningsfullt bedre med hver forbedring, og hastigheten på forbedring er raskest i de første ukene når de vanligste manglene blir identifisert og fyllt.

Læringskurven for chatbotens vedlikehold er like rask. Innen slutten av den første uken forstår personen som administrerer chatboten hva slags kunnskap som produserer de beste svarene, hvor spesifikk bruksscenaariodefinisjonen må være, og hvilke samtalemønstre som krever oppmerksomhet. Denne operasjonelle bekanntskapen, oppnådd gjennom direkte erfaring i stedet for dokumentasjonslesing, er hva som transformerer chatboten fra et setup-og-glemme-verktøy til en kontinuerlig forbedring av eiendel som blir mer verdifull for virksomheten med hver forbigåande uke.

Ingen ML-ekspertise kreves og hva det faktisk betyr

Påstanden om at ingen maskinlæringekspertise er nødvendig fortjener utpakking fordi den høres ut som markedsføringsspråk og det er viktig å forklare hvorfor det er genuint sant. ChatBot API håndterer alle teknisk komplekse operasjoner internt: dokumentsegmentering, vektorinnbygging, semantisk søk, kontekstvinduadministrasjon, promptkonstruksjon, og svargenering. Dette er operasjonene som krever ML-kunnskap for å implementere fra grunnen av. De krever ikke ML-kunnskap for å bruke gjennom et API som abstraherer dem bak et enkelt grensesnitt.

Ferdighetene som kreves for å sette opp og vedlikeholde en chatbot gjennom dette systemet er fullstendig ikke-tekniske: evnen til å organisere bedriftskunnskap i dokumenter, evnen til å beskrive samtalescenarier på naturlig språk, og evnen til å lese samtalelogger og identifisere hvor svar falt kort. Dette er ferdigheter som enhver bedriftsleder, kundeservicesjef, eller markedsføringsfachmann besitter. Den tekniske infrastrukturen håndteres av API-et, og forretningsintelligensen håndteres av personene som forstår virksomheten.

Denne ansvarsdelingen er det som gjør femten-minutters distribusjon realistisk snarere enn aspirasjonell. De teknisk vanskelige delene er allerede løst og kjør som en tjeneste. De forretningsspesifikke delene, som bare virksomheten kan gi, er enkle å levere gjennom dokumentopplasting og naturlig språk bruksscenariodefinisjoner. Skjæringspunktet for disse to inngangene produserer en chatbot som kombinerer samtalekompetansen til en stor språkmodell med den spesifikke kunnskapen og atferdsmessige retningslinjene for virksomheten, uten å kreve at noen involvert forstår hvordan enten språkmodellen eller kunnskapsgjenhentingssystemet fungerer internt.

Resultatet er en chatbot som kjenner dine produkter, snakker med merkevaretonalen din, håndterer scenarioene du definerer, og forbedres når du gir den bedre kunnskap og klarere retningslinjer. Hele ML-rørledningen kjør bak kulissene, usynlig for virksomhetsbrukeren, som er akkurat hvordan det skal fungere. Virksomheten trenger ikke forstå transformers og innbygginger mer enn en sjåfør trenger forstå drivstoffinjeksjon og transmisjonsteknikk. Kjøretøyet fungerer. Bestemmelsesstedet nås. Motordetaljer er noen annens bekymring.