Technologie alleen garandeert geen adoptie: lessen uit het opbouwen van een intern AI-chatbot

Toen de adoptie van AI versnelde in verschillende branches, leek het een logische beslissing om een chatbot in te zetten om een nieuw gelanceerde interne applicatie te ondersteunen. De applicatie zelf daagde echter conventionele gebruikersverwachtingen uit. Het introduceerde nieuwe workflows gebaseerd op opkomende technologie die onbekend was voor de meeste gebruikers.

Om wrijving te verminderen en adoptie te verbeteren, was de chatbot ontworpen om vragen over de applicatie en de onderliggende technologie te beantwoorden. Het doel was om gebruikers niet alleen te laten begrijpen wat ze moesten doen, maar ook waarom het systeem op een bepaalde manier werkte. We geloofden dat het verstrekken van contextuele verklaringen het leerproces zou versnellen en verwarring zou verminderen.

Vanaf het begin was de AI-agent bedoeld als een oplossing met beperkte reikwijdte. Het was ontworpen om strikt te worden gebruikt voor ondersteuning van documentatie en gebruikersondersteuning. Conceptueel was de chatbot bedoeld om te dienen als een dynamische vervanging voor een traditioneel document met veelgestelde vragen, met een conversatie, zoekbare en continu beschikbare interface met uitgebreide functionaliteit buiten statische inhoud.

Om de agent te integreren in de interne chat-omgeving van de organisatie, moesten we begrijpen hoe gestructureerde berichten werden weergegeven, hoe conversatiegeschiedenis werd opgeslagen en hoe het systeem deelnemers binnen threads identificeerde. Dit stelde ons in staat om de kernvariabelen te bepalen die nodig waren om gebruikersvragen te verwerken.

Gronding van het model: van hallucinatie tot betrouwbare context

Grote taalmodellen zijn krachtig, maar zonder contextuele verankering zijn ze gevoelig voor hallucinaties. Om dit aan te pakken, hebben we een vector-embedding-techniek geïmplementeerd.

Gebruikershandleidingen, interne documentatie en het productvisie werden omgezet in numerieke vectorweergaven van tekst. Deze embeddings vingen semantische betekenis, waardoor het systeem concepten kon matchen in plaats van te vertrouwen op eenvoudige trefwoordmatching.

Wanneer een gebruiker een vraag stelde, zette het systeem de query om in een vectorweergave en vergeleek het met de opgeslagen embeddings. Het haalde de meest semantisch relevante documenten op en injecteerde ze in de prompt van het model. Het model genereerde vervolgens een antwoord dat was gebaseerd op die specifieke documenten, vaak door de relevante informatie samen te vatten.

Deze benadering verbeterde de nauwkeurigheid van de antwoorden aanzienlijk. In plaats van antwoorden te genereren op basis van puur algemene kennis, antwoordde het model met behulp van de eigen documentatie van de organisatie als context.

De verborgen complexiteit van contextbeheer

Het was essentieel om conversatiegeschiedenis op te nemen in de prompt, zodat de bot follow-upvragen kon interpreteren en continuïteit kon behouden. Zonder geschiedenis werden interacties gefragmenteerd en herhaald. Gebruikers verfijnen hun vragen vaak incrementeel, en zonder context kon de bot geen verwijzingen zoals “die optie” of “de vorige stap” interpreteren.

Het opnemen van te veel geschiedenis creëerde echter een ander probleem: tokenlimieten. Deze treden op wanneer taalmodellen ingangen afkappen die de maximale contextwindow overschrijden. Als een vraag of conversatie te lang werd, kon belangrijke informatie verloren gaan. Dit produceerde geen expliciete fout, maar degradeerde de kwaliteit van de antwoorden of beïnvloedde de nauwkeurigheid van de opname.

Om dit te mitigeren, hebben we strategieën geïmplementeerd om de grootte van de prompt te controleren, relevante inhoud te prioriteren en de lengte van vragen te bewaken. We hebben geëxperimenteerd met het samenvatten van oudere berichten en het selectief opnemen van alleen de meest relevante delen van de conversatie. Context was kritiek, maar het moest zorgvuldig worden beheerd.

Uitbreiden van functionaliteit en creëren van verwarring

Naast het beantwoorden van vragen op basis van documentatie, hebben we de functionaliteit van de bot uitgebreid door backend-functies toe te voegen die bepaalde openbare informatie rechtstreeks uit de applicatie konden ophalen. Dit stelde gebruikers in staat om gegevens op te halen uit de chat zonder in te loggen op de app zelf. Het idee was om wrijving te verminderen en de chatbot te versterken als een nuttige interface, niet alleen een statische kennislaag.

Deze uitbreiding creëerde echter verwarring bij sommige gebruikers. Zodra de bot live gegevens begon op te halen, begonnen gebruikers het te vragen om acties uit te voeren die rechtstreekse interactie binnen het platform vereisten. Ze gingen ervan uit dat de chatbot operatieve stappen kon vervangen, inclusief die welke authenticatie of doelgerichte uitvoering binnen het platform vereisten.

De bot was nooit ontworpen om die acties uit te voeren, maar het onderscheid tussen informatieve ondersteuning en operationele uitvoering was niet altijd duidelijk.

Het integreren van live gegevens introduceerde ook nieuwe technische overwegingen. We moesten definiëren wanneer een vraag door embedding-gebaseerde opname moest gaan en wanneer het een backend-aanroep moest triggeren. Die beslissingslogica vereiste zorgvuldige ontwerp. Bovendien moesten we antwoorden afstemmen om technische uitzonderingen op een elegante manier te verwerken en om raw systeemfouten voor gebruikers te verbergen.

Multilingualiteit is niet automatisch

Tijdens het testen realiseerden we ons dat de bot consistent beter presteerde in het Engels dan in andere talen die binnen Jalasoft werden gebruikt. De primaire reden was structureel: de meeste documentatie die werd gebruikt om embeddings te genereren, was geschreven in het Engels, en het embedding-model dat we selecteerden was geoptimaliseerd voor Engelse semantische gelijkenis.

Het ondersteunde geen cross-linguale opname of semantische vergelijking tussen talen. Als gevolg daarvan haalden niet-Engelse queries vaak minder relevante documentatie op, wat leidde tot zwakkere antwoorden.

Dit benadrukte een belangrijke inzicht: multilingualiteit is niet automatisch.

Wanneer verwachtingen de reikwijdte overschrijden

Om gebruikskosten te controleren, hebben we een dagelijkse limiet geïmplementeerd op het aantal vragen dat gebruikers konden stellen. We hebben echter niet expliciet de reikwijdte van die vragen beperkt. Gebruikers waren vrij om alles te vragen.

Deze openheid leidde tot onverwachte gebruikerspatronen. Sommige gebruikers begonnen de bot te gebruiken voor persoonlijke of exploratoire doeleinden die niet gerelateerd waren aan de applicatie. In de loop van de tijd groeiden de verwachtingen uit tot verder dan de beoogde rol van de bot, waardoor een kloof ontstond tussen wat gebruikers hoopten dat het kon doen en wat het was ontworpen om te ondersteunen.

Deze misalignering reduceerde geleidelijk de waargenomen bruikbaarheid. Gebruik nam af, en de chatbot werd uiteindelijk afgeschaft, met inspanningen omgericht naar het opnieuw ontwerpen van de applicatie zelf om het meer intuïtief en gemakkelijker te maken.

De echte les: interactieontwerp.

Vanuit een technisch oogpunt functioneerde het systeem redelijk goed. Het haalde documentatie op, nam conversatiegeschiedenis op, reduceerde hallucinaties via embeddings, verwerkte backend-aanroepen en beheerde promptgrootte. De architectuur functioneerde zoals bedoeld.

Maar het ontbrak aan intentioneel interactieontwerp.

De bot vormde geen duidelijke conversaties. Het versterkte niet consequent de reikwijdte. Het gaf geen gebruikers structuurvoorbeelden van wat het kon en niet kon doen. Het beantwoordde vragen, maar het stelde geen verwachtingen.

We leerden dat conversational AI-systemen meer nodig hebben dan sterke modellen en gestructureerde gegevens. Ze vereisen zorgvuldig ontworpen verwachtingen. Gebruikers hebben duidelijkheid nodig over de rol van de agent, de grenzen en de sterke punten. Het systeem moet proactief voorbeeldprompts bieden, beperkingen verduidelijken en vragen buiten de reikwijdte consistent omleiden.

Zonder deze intentionele kadering kan zelfs een technisch solide implementatie worstelen om waarde te behouden. Gebruikers kunnen de capaciteiten overschatten of zich afkeren wanneer onuitgesproken verwachtingen niet worden ingelost.

De kerninzicht is eenvoudig maar krachtig.

Conversational AI opbouwen is niet alleen een technische uitdaging. Het is ook een interactieontwerpuitdaging.

Sterke context, nauwkeurige opname en robuuste architectuur zijn noodzakelijk, maar niet voldoende. De effectiviteit van het systeem hangt evenzeer af van hoe het zijn rol definieert, de grenzen communiceert en gebruikersverwachtingen vormt.

Technologie alleen garandeert geen adoptie. Duidelijk interactieontwerp wel.