Технологія сама по собі не гарантує прийняття: уроки з будівництва внутрішнього чат-бота AI

Під час прискорення прийняття AI в різних галузях, розгортання чат-бота для підтримки нової внутрішньої програми здавалося логічним рішенням. Однак сама програма поставила під сумнів традиційні очікування користувачів. Вона ввела нові робочі процеси, засновані на новій технології, незнайомій більшості користувачів.

Щоб зменшити тертя та покращити прийняття, чат-бот був розроблений для відповідей на питання про програму та основну технологію. Метою було допомогти користувачам зрозуміти не тільки те, що потрібно зробити, але й чому система поводиться певним чином. Ми вважали, що надання контекстних пояснень прискорить навчання та зменшить плутанину.

Від самого початку AI-агент був задуманий як рішення з обмеженим обсягом. Він був розроблений строго для підтримки документації та надання допомоги користувачам. Концептуально чат-бот мав служити динамічною заміною традиційного документа з частими питаннями, пропонуючи розмовний, пошуковий та постійно доступний інтерфейс з розширеними функціями за межами статичного контенту.

Щоб інтегрувати агента в внутрішнє середовище чату організації, нам потрібно було зрозуміти, як структуровані повідомлення відображаються, як зберігається історія розмов та як система ідентифікує учасників у потоках. Це дозволило нам визначити основні змінні, необхідні для початку обробки запитів користувачів.

Закріплення моделі: Від галюцинацій до надійного контексту

Потужні мовні моделі, але без контекстного закріплення, схильні до галюцинацій. Щоб звернути увагу на це, ми реалізували векторне вкладення.

Користувацькі посібники, внутрішня документація та бачення продукту були перетворені на числові векторні представлення тексту. Ці вкладення захопили семантичний сенс, дозволивши системі зіставляти концепції, а не покладатися на просте співпадіння ключових слів.

Коли користувач запитував питання, система перетворила запит на векторне представлення та порівняла його з збереженими вкладеннями. Вона витягнула найбільш семантично відповідні документи та ввела їх у підказку моделі. Модель тоді генерувала відповідь, засновану на цих конкретних документах, часто підсумовуючи відповідну інформацію.

Цей підхід суттєво покращив точність відповідей. Замість генерації відповідей, заснованих чисто на загальних знаннях, модель відповідала, використовуючи власну документацію організації як контекст.

Прихована складність контекстного управління

Було важливо включити історію розмови в підказку, щоб бот міг інтерпретувати подальші запитання та підтримувати безперервність. Без історії взаємодії ставали фрагментованими та повторюваними. Користувачі часто уточнювали свої запитання поступово, і без контексту бот не міг інтерпретувати посилання, такі як “та опція” або “попередній крок”.

Однак включення занадто великої історії створило іншу проблему: ліміт токенів. Це відбувається, коли мовні моделі обрізають вхідні дані, які перевищують їх максимальне контекстне вікно. Якщо питання чи розмова ставали занадто довгими, важлива інформація могла бути втрачена. Це не призводило до явної помилки, а радше погіршувало якість відповідей або впливало на точність пошуку.

Щоб пом’якшити це, ми реалізували стратегії контролю розміру підказки, пріоритету відповідного контенту та моніторингу довжини запитань. Ми експериментували з підсумовуванням старих повідомлень та вибірковим включенням лише найбільш відповідних частин розмови. Контекст був критично важливим, але його потрібно було ретельно керувати.

Розширення можливостей та створення плутанини

Поза відповідями на запитання, пов’язані з документацією, ми розширили можливості бота, додавши функції бекенду, які могли витягувати певну публічну інформацію безпосередньо з програми. Це дозволило користувачам отримувати дані з чату без входу в програму. Ідеєю було зменшити тертя та зміцнити чат-бот як корисний інтерфейс, не тільки статичний шар знань.

Однак це розширення створило плутанину для деяких користувачів. Коли бот почав витягувати живі дані, користувачі почали запитувати його про виконання дій, які вимагали прямої взаємодії всередині платформи. Вони припускали, що чат-бот може замінити операційні кроки, включаючи ті, які вимагали аутентифікації або свідомого виконання всередині платформи.

Бот ніколи не був розроблений для виконання цих дій, але відмінність між інформаційною допомогою та операційним виконанням не завжди була чіткою.

Інтеграція живих даних також ввела нові технічні міркування. Нам потрібно було визначити, коли запит має проходити через вкладення та коли він повинен спровокувати виклик бекенду. Ця логіка рішення вимагала ретельного проектування. Крім того, нам потрібно було налаштувати відповіді, щоб вони могли гарно обробляти технічні винятки та уникати відкриття сирої системної помилки користувачам.

Багатомовна здатність не є автоматичною

Під час тестування ми зрозуміли, що бот постійно працював краще англійською, ніж іншими мовами, використовуваними в Jalasoft. Основною причиною була структура: більшість документації, використаної для генерації вкладень, була написана англійською, і модель вкладення, яку ми обрали, була оптимізована для англійської семантичної подібності.

Вона не підтримувала міжмовний пошук або семантичне порівняння між мовами. Внаслідок цього запити неанглійською часто витягували менш відповідну документацію, що призводило до слабших відповідей.

Це підкреслило важливий висновок: багатомовна здатність не є автоматичною.

Коли очікування розширюються за межі обсягу

Щоб контролювати витрати на використання, ми реалізували щоденний ліміт на кількість запитів, які користувачі могли задати. Однак ми не явно обмежили обсяг цих запитів. Користувачі могли запитувати все.

Ця відкритість призвела до несподіваних моделей використання. Деякі користувачі почали взаємодіяти з ботом для особистих або дослідницьких цілей, не пов’язаних з програмою. З часом очікування виросли за межі ролі бота, створивши розрив між тим, що користувачі сподівалися, що він може зробити, і тим, що він був розроблений для підтримки.

Ця невідповідність поступово знищила його сприйману корисність. Витрати на використання зменшилися, і чат-бот був врешті-решт вилучений, а зусилля були перенаправлені на переробку програми самої по собі, щоб зробити її більш інтуїтивною та легкою у використанні.

Наступний урок: Проектування взаємодії.

З інженерної точки зору система працювала досить добре. Вона витягнула документацію, включила історію розмови, зменшивши галюцинації через вкладення, обробила виклики бекенду та керувала розміром підказки. Архітектура функціонувала так, як передбачалося.

Але їй бракувало свідомого проектування взаємодії.

Бот не чітко сформував розмови. Він не послідовно зміцнював свій обсяг. Він не направляв користувачів структурованими прикладами того, що він міг і не міг робити. Він відповідав на запитання, але не встановлював очікування.

Ми зрозуміли, що системи розмовного AI вимагають більше, ніж сильні моделі та структуровані дані. Вони вимагають ретельно розроблених очікувань. Користувачам потрібна ясність щодо ролі агента, його меж та його сильних сторін. Система повинна активно надавати прикладні підказки, уточнювати обмеження та перенаправляти запитання, що виходять за межі обсягу, послідовно.

Без цього свідомого кадрування навіть технічна реалізація може боротися за підтримання цінності. Користувачі можуть переоцінювати можливості або роз’єднуватися, коли неявні очікування не задовольняються.

Ключовий висновок простий, але потужний.

Розробка розмовного AI не є тільки технічним викликом. Це також виклик проектування взаємодії.

Сильний контекст, точний пошук та міцна архітектура необхідні, але недостатні. Ефективність системи залежить рівною мірою від того, як вона визначає свою роль, спілкується своїми межами та формує очікування користувачів.

Технологія сама по собі не гарантує прийняття. Чітке проектування взаємодії робить.