Technologie sama o sobě nezajišťuje přijetí: Lekce z budování interního chatbota AI

Když se přijetí umělé inteligence zrychlovalo napříč odvětvími, nasazení chatbota na podporu nově spuštěné interní aplikace se zdálo jako logické rozhodnutí. Nicméně, sama aplikace vybízela konvenční uživatelské očekávání. Zaváděla nové pracovní postupy založené na vznikající technologii, která byla většině uživatelů neznámá.

Aby se snížila tření a zlepšila přijetí, byl chatbot navržen tak, aby odpovídal na otázky týkající se aplikace a podkladové technologie. Cílem bylo pomoci uživatelům porozumět nejen tomu, co mají dělat, ale také proč systém funguje určitým způsobem. Věděli jsme, že poskytování kontextových vysvětlení urychlí učení a sníží zmatek.

Od začátku byl AI agent koncipován jako omezený řešení. Byl navržen striktně pro podporu dokumentace a poskytování uživatelské pomoci. Konceptuálně měl chatbot sloužit jako dynamická náhrada za tradiční dokument Frequently Asked Questions, nabízející konverzační, vyhledatelnou a kontinuálně dostupnou rozhraní s prodlouženou funkcionalitou beyond statického obsahu.

Abychom integrovali agenta do interního chatového prostředí organizace, museli jsme pochopit, jak jsou strukturované zprávy renderovány, jak je konverzační historie uložena a jak systém identifikuje účastníky ve vláknech. To nám umožnilo určit základní proměnné, které jsou vyžadovány pro zpracování uživatelských otázek.

Zakotvení modelu: Od halucinace k spolehlivému kontextu

Velké jazykové modely jsou silné, ale bez kontextového ukotvení jsou náchylné k halucinacím. Abychom tuto otázku řešili, implementovali jsme techniku vektorového vložování.

Uživatelské příručky, interní dokumentace a produktová vize byly transformovány do numerických vektorových reprezentací textu. Tyto vložené reprezentace zachycovaly semantický význam, což umožnilo systému shodovat koncepty spíše než spoléhat se na jednoduché shody klíčových slov.

Když uživatel položil otázku, systém převedl dotaz na vektorovou reprezentaci a porovnal ji s uloženými vloženými reprezentacemi. Načetl nejsemanticky relevantnější dokumenty a vložil je do modelové výzvy. Model poté vygeneroval odpověď založenou na těchto konkrétních dokumentech, často shrnující relevantní informace.

Tento přístup výrazně zlepšil přesnost odpovědí. Místo generování odpovědí založených čistě na obecných znalostech model odpověděl pomocí naší vlastní dokumentace jako kontextu.

Skrývaná složitost kontextového řízení

Bylo nezbytné zahrnout konverzační historii do výzvy, aby mohl bot interpretovat následné otázky a zachovat kontinuitu. Bez historie se interakce staly fragmentovanými a opakovanými. Uživatelé často postupně upravují své otázky, a bez kontextu, bot nemohl interpretovat odkazy jako „ta možnost“ nebo „předchozí krok“.

Nicméně, zahrnutí příliš dlouhé historie vytvořilo jiný problém: token limits. Tyto nastávají, když jazykové modely zkracují vstupy, které překračují jejich maximální kontextové okno. Pokud se otázka nebo konverzace stala příliš dlouhou, mohla být ztracena důležitá informace. To nevyvolalo žádnou explicitní chybu, ale spíše snížilo kvalitu odpovědi nebo ovlivnilo přesnost načtení.

Abychom tento problém zmírnili, implementovali jsme strategie pro řízení velikosti výzvy, priorizaci relevantního obsahu a monitorování délky otázky. Experimentovali jsme se zkracováním starších zpráv a selektivním zahrnutím pouze nejrelevantnějších částí konverzace. Kontext byl kritický, ale musel být pečlivě řízen.

Rozšiřování funkcí a vytváření zmatku

Mimo odpovědi na dokumentační otázky jsme rozšířili schopnosti botu přidáním backend funkcí, které mohly extrahovat určitou veřejnou informaci přímo z aplikace. To umožnilo uživatelům načíst data z chatu bez přihlášení do aplikace samotné. Nápadem bylo snížit tření a posílit chatbota jako užitečné rozhraní, ne pouze statickou vrstvu znalostí.

Toto rozšíření však vytvořilo zmatek pro některé uživatele. Jakmile bot začal načítat živá data, uživatelé začali klást otázky, zda může provést akce, které vyžadují přímou interakci uvnitř platformy. Připustili, že chatbot může nahradit provozní kroky, včetně těch, které vyžadují autentizaci nebo úmyslné provedení uvnitř platformy.

Bot nebyl navržen pro provedení těchto akcí, ale rozlišení mezi informační pomocí a provozní realizací nebylo vždy jasné.

Integrace živých dat také přinesla nové technické úvahy. Museli jsme definovat, kdy by se otázka měla zpracovat pomocí vložené reprezentace a kdy by měla spustit backend volání. To vyžadovalo pečlivé návrhy. Kromě toho jsme museli upravit odpovědi, aby elegantně zpracovávaly technické výjimky a zabránily expozici syrových systémových chyb uživatelům.

Multijazyčná schopnost není automatická

Během testování jsme zjistili, že bot konzistentně fungoval lépe v angličtině než v jiných jazycích používaných v rámci Jalasoft. Hlavním důvodem byla strukturální: většina dokumentace použitá pro generování vložených reprezentací byla napsána v angličtině, a vložený model, který jsme vybrali, byl optimalizován pro anglickou semantickou podobnost.

Nepodporoval cross-lingvistické načítání nebo semantické srovnání napříč jazyky. V důsledku toho často non-anglické dotazy načítaly méně relevantní dokumentaci, vedoucí k slabším odpovědím.

To ukázalo důležitou skutečnost: multijazyčná schopnost není automatická.

Když očekávání přesahují rámec

Abychom kontrolovali náklady na použití, implementovali jsme denní limit počtu otázek, které mohli uživatelé položit. Nicméně, neomezili jsme explicitně rozsah těchto otázek. Uživatelé mohli klást jakékoli otázky.

Tato otevřenost vedla k neočekávaným vzorcům použití. Někteří uživatelé začali interagovat s botem pro osobní nebo průzkumné účely nesouvisející s aplikací. S časem se očekávání vyvinula za rámec původně zamýšlené role chatbota, vytvářející mezery mezi tím, co uživatelé doufali, že může udělat, a tím, co bylo navrženo pro podporu.

Tento nesoulad postupně snižoval jeho vnímanou užitečnost. Používání pokleslo, a chatbot byl nakonec deaktivován, s úsilím přesměrovaným na přepracování aplikace samotné, aby byla intuitivnější a snazší na použití.

Skutečná lekce: Interakční návrh.

Z hlediska inženýrství fungoval systém poměrně dobře. Načítal dokumentaci, zahrnoval konverzační historii, snižoval halucinace pomocí vložených reprezentací, zpracovával backend volání a řídil velikost výzvy. Architektura fungovala tak, jak byla zamýšlena.

Ale postrádal úmyslný interakční návrh.

Bot jasně netvořil konverzace. Neustále nezajišťoval rámec. Nevedl uživatele strukturovanými příklady toho, co mohl a nemohl udělat. Odpovídal na otázky, ale nestanovoval očekávání.

Naučili jsme se, že konverzační systémy AI vyžadují více než silné modely a strukturovaná data. Vyžadují pečlivě navržená očekávání. Uživatelé potřebují jasnost o roli agenta, jeho hranicích a jeho silných stránkách. Systém musí proaktivně poskytovat příklady výzev, zjasňovat omezení a konsistentně přesměrovat otázky mimo rámec.

Stavba konverzační AI není pouze technickou výzvou. Je to také interakční designová výzva.

Silný kontext, přesné načítání a robustní architektura jsou nezbytné, ale ne dostatečné. Účinnost systému závisí stejně na tom, jak definuje svou roli, komunikuje své hranice a formuje uživatelská očekávání.

Technologie sama o sobě nezajišťuje přijetí. Čistý interakční návrh ano.