Teknologi alene garanterer ikke adopsjon: Leksjoner fra bygging av en intern AI-chatbot

Som AI-adoptsjon accelererte over industrier, å deploye en chatbot for å støtte en nylig lansert internapplikasjon syntes som en logisk beslutning. Imidlertid utfordret applikasjonen selv konvensjonelle brukerforventninger. Den introduserte nye arbeidsflyter bygget på fremvoksende teknologi som var uvant for de fleste brukerne.

For å redusere friksjon og forbedre adopsjon, ble chatboten designet for å svare på spørsmål om applikasjonen og den underliggende teknologien. Målet var å hjelpe brukerne å forstå ikke bare hva de skulle gjøre, men også hvorfor systemet oppførte seg på en bestemt måte. Vi trodde at å gi kontekstuelle forklaringer ville akselerere læring og redusere forvirring.

Fra begynnelsen av ble AI-agenten konseptualisert som en løsning med begrenset omfang. Den ble designet strengt for å støtte dokumentasjon og gi brukerhjelp. Konseptuelt var chatboten ment å fungere som en dynamisk erstatning for en tradisjonell ofte stilte spørsmål-dokument, og tilby en konversasjonsbasert, søkbar og kontinuerlig tilgjengelig grensesnitt med utvidet funksjonalitet utover statisk innhold.

For å integrere agenten i organisasjonens interne chatsystem, måtte vi forstå hvordan strukturerte meldinger ble rendret, hvordan samtalehistorikk ble lagret og hvordan systemet identifiserte deltakere i tråder. Dette tillot oss å bestemme de grunnleggende variablene som var nødvendige for å begynne å prosessere brukerspørsmål.

Grundlag for modellen: Fra hallusinasjon til pålitelig kontekst

Store språkmodeller er kraftfulle, men uten kontekstuell forankring er de utsatt for hallusinasjoner. For å løse dette, implementerte vi en vektor-embedding-teknikk.

Brukerhåndbøker, interne dokumenter og produktvisjonen ble transformert til numeriske vektorrepresentasjoner av tekst. Disse vektorrepresentasjonene fanget semantisk mening, og tillot systemet å matche konsepter i stedet for å bare stole på enkel nøkkelordmatching.

Når en bruker stilte et spørsmål, konverterte systemet spørsmålet til en vektorrepresentasjon og sammenlignet den med de lagrede vektorrepresentasjonene. Det hentet de mest semantisk relevante dokumentene og injiserte dem i modellens prompt. Modellen genererte deretter et svar som var basert på disse dokumentene, ofte sammenfattende den relevante informasjonen.

Dette tilnærmingen forbedret betydelig svartidens nøyaktighet. I stedet for å generere svar basert på ren generell kunnskap, svarte modellen ved å bruke vår organisasjons egen dokumentasjon som kontekst.

Den skjulte kompleksiteten i kontekststyring

Det var essensielt å inkludere samtalehistorikk i prompten så chatboten kunne tolke oppfølgende spørsmål og opprettholde kontinuitet. Uten historikk ble interaksjoner fragmenterte og repetitive. Brukere ofte finjusterte sine spørsmål inkrementelt, og uten kontekst, kunne chatboten ikke tolke referanser som “den valget” eller “den forrige steget.”

Men å inkludere for mye historikk skapte et annet problem: tokenbegrensninger. Disse oppstår når språkmodeller forkorter inndata som overstiger deres maksimale kontekstvindu. Hvis et spørsmål eller samtale ble for lang, kunne viktig informasjon gå tapt. Dette produserte ikke en eksplisitt feil, men snarere forringet svartidens kvalitet eller påvirkte hentingens nøyaktighet.

For å mildne dette, implementerte vi strategier for å kontrollere prompt-størrelse, prioritere relevant innhold og overvåke spørsmålets lengde. Vi eksperimenterte med å sammenfatte eldre meldinger og selektivt inkludere bare de mest relevante delene av samtalen. Kontekst var kritisk, men den måtte håndteres med omsorg.

Utvidelse av funksjoner og skapelse av forvirring

Utenom å svare på dokumentasjonsbaserte spørsmål, utvidet vi chatbotens funksjoner ved å legge til bakendefunksjoner som kunne hente bestemt offentlig informasjon direkte fra applikasjonen. Dette tillot brukerne å hente data fra chatten uten å logge inn i applikasjonen selv. Ideen var å redusere friksjon og styrke chatboten som et nyttig grensesnitt, ikke bare et statisk kunnskapslag.

Dette utvidelsen skapte forvirring for noen brukere likevel. Når chatboten begynte å hente live-data, begynte brukerne å spørre den om å utføre handlinger som krevde direkte interaksjon innenfor plattformen. De antok at chatboten kunne erstatte operasjonelle steg, inkludert de som krevde autentisering eller bevisst utførelse innenfor plattformen.

Chatboten var aldri designet for å utføre disse handlingene, men skillet mellom informasjonsbasert hjelp og operasjonell utførelse var ikke alltid klart.

Integrering av live-data innførte også nye tekniske overveielser. Vi måtte definere når et spørsmål skulle gå gjennom vektor-embedding-basert henting og når det skulle utløse en bakendekall. Denne beslutningslogikken krevde omhyggelig design. I tillegg måtte vi finjustere svarene for å håndtere tekniske unntak på en elegant måte og unngå å eksponere rå systemfeil for brukerne.

Flerspråklig funksjonalitet er ikke automatisk

Under testingen innsett vi at chatboten konsistent utførte bedre på engelsk enn på andre språk som ble brukt innen Jalasoft. Den primære årsaken var strukturell: mesteparten av dokumentasjonen som ble brukt til å generere vektorrepresentasjoner var skrevet på engelsk, og vektor-embedding-modellen vi valgte var optimalisert for engelsk semantisk likhet.

Den støttet ikke kryss-språklig henting eller semantisk sammenligning over språk. Som resultat hentet ikke-engelske spørsmål ofte mindre relevante dokumenter, noe som ledet til svakere svar.

Dette understreket en viktig innsikt: flerspråklig funksjonalitet er ikke automatisk.

Når forventninger utvides utenfor omfang

For å kontrollere brukskostnader, implementerte vi en daglig grense for antall spørsmål brukerne kunne stille. Imidlertid implementerte vi ikke eksplisitt noen begrensninger på spørsmålenes omfang. Brukere var frie til å spørre om hva som helst.

Dette åpne utfallet ledet til uventede bruksmønster. Noen brukere begynte å interagere med chatboten for personlige eller utforskende formål som ikke var relatert til applikasjonen. Over tid utvidet forventningene seg utenfor chatbotens ment å støtte rolle, og skapte et gap mellom hva brukerne håpet den kunne gjøre og hva den var designet for å støtte.

Dette misforholdet reduserte gradvis dens opplevde nytte. Bruken avtok, og chatboten ble til slutt avskrevet, med innsats rettet mot å redesigne applikasjonen selv for å gjøre den mer intuitiv og enklere å bruke.

Den virkelige leksjonen: Interaksjonsdesign

Fra et ingeniørperspektiv fungerte systemet rimelig godt. Det hentet dokumenter, inkluderte samtalehistorikk, reduserte hallusinasjoner gjennom vektorrepresentasjoner, håndterte bakendekall og kontrollerte prompt-størrelse. Arkitekturen fungerte som ment.

Men den manglet bevisst interaksjonsdesign.

Chatboten formet ikke tydelig samtaler. Den forsterket ikke konsistent sitt omfang. Den guidet ikke brukerne med strukturerte eksempler på hva den kunne og ikke kunne gjøre. Den svarte på spørsmål, men den satte ikke forventninger.

Vi lærte at konversasjons-AI-systemer krever mer enn sterke modeller og strukturert data. De krever omhyggelig designet forventninger. Brukere trenger klarhet om agentens rolle, dens begrensninger og dens styrker. Systemet må proaktivt tilby eksempelprompter, klargjøre begrensninger og omdirigere spørsmål utenfor omfang på en konsistent måte.

Uten denne bevisste rammen kan selv en teknisk lykkesrik implementering slite med å opprettholde verdi. Brukere kan overvurdere funksjonalitet eller frakoble når uutsagte forventninger ikke møtes.

Kjerneinnsikten er enkel, men kraftfull.

Bygging av konversasjons-AI er ikke bare en teknisk utfordring. Det er også en interaksjonsdesign-utfordring.

Stærk kontekst, nøyaktig henting og robust arkitektur er nødvendig, men ikke tilstrekkelig. Systemets effektivitet avhenger like mye av hvordan det definerer sin rolle, kommuniserer sine begrensninger og former brukerforventninger.

Teknologi alene garanterer ikke adopsjon. Klart interaksjonsdesign gjør.