Technologie alleen garandeert geen adoptie: lessen uit de bouw van een interne AI-chatbot

Terwijl de adoptie van AI versnelde in verschillende branches, leek het deployen van een chatbot om een nieuw gelanceerde interne applicatie te ondersteunen een logische beslissing. Echter, de applicatie zelf daagde 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 helpen begrijpen wat ze moesten doen, maar ook waarom het systeem op een bepaalde manier werkte. We geloofden dat het bieden van contextuele verklaringen het leren 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 het ondersteunen van documentatie en het bieden van gebruikersondersteuning. Conceptueel was de chatbot bedoeld om te dienen als een dynamische vervanging voor een traditioneel Frequently Asked Questions-document, met een conversational, searchable 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 in threads identificeerde. Dit stelde ons in staat om de kernvariabelen te bepalen die nodig waren om gebruikersvragen te verwerken.

De basis leggen voor het model: van hallucinatie tot betrouwbare context

Grote taalmodellen zijn krachtig, maar zonder contextuele ankeren zijn ze vatbaar 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 deze met de opgeslagen embeddings. Het haalde de meest semantisch relevante documenten op en injecteerde deze 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 aanpak 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 onze eigen documentatie als context.

De verborgen complexiteit van contextbeheer

Het was essentieel om de conversatiegeschiedenis in de prompt op te nemen, zodat de bot follow-upvragen kon interpreteren en consistentie 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.

Echter, het opnemen van te veel geschiedenis creëerde een ander probleem: tokenlimieten. Deze treden op wanneer taalmodellen ingangen trunceren die hun maximale contextwindow overschrijden. Als een vraag of conversatie te lang werd, kon belangrijke informatie verloren gaan. Dit produceerde geen expliciete fout, maar eerder een afgenomen antwoordkwaliteit of beïnvloedde de opzoekenauwkeurigheid.

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

Capaciteiten uitbreiden en verwarring creëren

Verder dan het beantwoorden van documentatie-gebaseerde vragen, hebben we de capaciteiten van de bot uitgebreid door backend-functies toe te voegen die bepaalde openbare informatie rechtstreeks uit de applicatie konden extraheren. 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.

Dit uitbreiden van capaciteiten 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 operationele 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 bepalen wanneer een vraag via embedding-gebaseerde opzoeken moest worden verwerkt en wanneer deze 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.

Multilinguale capaciteit 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 hadden geselecteerd, was geoptimaliseerd voor Engelse semantische gelijkenis.

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

Dit benadrukte een belangrijke inzicht: multilinguale capaciteit is niet automatisch.

Wanneer verwachtingen de reikwijdte overschrijden

Om gebruiks kosten te controleren, hebben we een dagelijkse limiet ingesteld op het aantal vragen dat gebruikers konden stellen. Echter, we hebben de reikwijdte van die vragen niet expliciet beperkt. Gebruikers waren vrij om alles te vragen.

Deze openheid leidde tot onverwachte gebruiks patronen. Sommige gebruikers begonnen met de bot te communiceren voor persoonlijke of exploratieve 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 nuttigheid. Het gebruik daalde, en de chatbot werd uiteindelijk afgeschaft, met inspanningen omgeleid 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 werkte 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 zijn reikwijdte niet consistent. Het gaf gebruikers geen gestructureerde voorbeelden 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 data. Ze vereisen zorgvuldig ontworpen verwachtingen. Gebruikers hebben duidelijkheid nodig over de rol van de agent, zijn grenzen en zijn 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 afhaken wanneer onuitgesproken verwachtingen niet worden vervuld.

De kerninzicht is eenvoudig maar krachtig.

Conversational AI bouwen is niet alleen een technische uitdaging, maar ook een interactieontwerpuitdaging

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

Technologie alleen garandeert geen adoptie. Duidelijk interactieontwerp doet dat wel.