Samotná technologie nezajišťuje přijetí: Lekce z vývoje interního chatbota AI

Jakmile se přijetí umělé inteligence zrychlovalo napříč odvětvími, zdálo se logické rozhodnutí nasadit chatbota na podporu nově spuštěné interní aplikace. Nicméně sama aplikace vyzyvala 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á.

Abychom snížili tření a zlepšili 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 pochopit nejen to, co mají dělat, ale také proč systém chová se určitým způsobem. Věděli jsme, že poskytování kontextových vysvětlení urychlí učení a sníží zmatek.

Od samého začátku byl AI agent koncipován jako řešení omezeného rozsahu. 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 rozšířenou funkcionalitou nad statický obsah.

Abychom integrovali agenta do interního chatového prostředí organizace, museli jsme pochopit, jak jsou strukturované zprávy vykreslovány, jak je uchovávána historie konverzace a jak systém identifikuje účastníky v rámci vláken. To nám umožnilo určit základní proměnné nezbytné pro zahájení 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žení.

Uživatelské příručky, interní dokumentace a produktová vize byly transformovány do numerických vektorových reprezentací textu. Tyto vložení zachycovala semantický význam, umožňující systému shodovat koncepty místo toho, aby se spoléhal 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 se uloženými vloženími. Načetl nejsemantičtěji relevantní dokumenty a vložil je do modelového promptu. 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 reagoval pomocí naší interní dokumentace jako kontextu.

Skrývaná komplexita správy kontextu

Bylo nezbytné zahrnout historii konverzace do promptu, aby mohl bot interpretovat následné otázky a udržet kontinuitu. Bez historie se interakce staly fragmentovanými a opakujícími se. Uživatelé často postupně upravovali své otázky, a bez kontextu nemohl bot interpretovat odkazy jako „ta možnost“ nebo „předchozí krok“.

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

Abychom tento problém zmírnili, implementovali jsme strategie pro kontrolu velikosti promptu, priorizaci relevantního obsahu a monitorování délky otázky. Experimentovali jsme se shrnutí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ě spravován.

Rozšiřování schopností 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 jako statickou znalostní vrstvu.

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 požadovat, aby provedl akce, které vyžadovaly přímou interakci uvnitř platformy. Předpokládali, ž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í exekucí nebylo vždy jasné.

Integrace živých dat také přinesla nové technické úvahy. Museli jsme definovat, kdy má otázka projít skrze načtení založené na vložení a kdy má aktivovat backend volání. Toto rozhodnutí logiky vyžadovalo pečlivé navržení. Kromě toho jsme museli upravit odpovědi tak, aby se technické výjimky zpracovávaly elegantně a aby se surové systémové chyby nezobrazovaly uživatelům.

Multilingvální schopnost není automatická

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

Ne podporoval mezi-jazykové načtení nebo semantické srovnání napříč jazyky. Jako výsledek, neanglické dotazy často načítaly méně relevantní dokumentaci, vedoucí k slabším odpovědím.

To ukázalo důležitou inspiraci: multilingvální schopnost není automatická.

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

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

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探索 účely nesouvisející s aplikací. V průběhu času očekávání přesáhla roli botu, vytvářející mezеру 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í klesalo, a chatbot byl nakonec vyřazen, s úsilím směrovaným k předběžnému návrhu aplikace samotné, aby se stala intuitivnější a snazší na použití.

Skutečná lekce: Interakční design

Z hlediska inženýrství fungoval systém rozumně dobře. Načítal dokumentaci, zahrnoval historii konverzace, snižoval halucinace skrze vložení, zpracovával backend volání a spravoval velikost promptu. Architektura fungovala tak, jak byla navržena.

Ale chyběl úmyslný interakční design.

Bot jasně neformoval konverzace. Neustále nezajišťoval svůj rozsah. Nevedl uživatele strukturovanými příklady toho, co může a nemůže udělat. Odpovídal na otázky, ale neudával 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 ukázkové prompty, zjasňovat omezení a přesměrovat otázky mimo rámec konzistentně.

Bez tohoto úmyslného rámcování může i technicky správná implementace bojovat se udržení hodnoty. Uživatelé mohou přecenit schopnosti nebo se odpojit, když nejsou splněna neočekávaná očekávání.

Základní inspirace je jednoduchá, ale silná.

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

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

Samotná technologie nezajišťuje přijetí. Čistý interakční design ano.