Технология сама по себе не гарантирует принятие: уроки из создания внутреннего чат-бота на основе ИИ

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

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

С самого начала ИИ-агент был задуман как решение с ограниченным объемом. Он был разработан строго для поддержки документации и предоставления помощи пользователям. Концептуально чат-бот был предназначен служить динамичной заменой традиционному документу с часто задаваемыми вопросами, предлагая разговорный, поисковый и постоянно доступный интерфейс с расширенной функциональностью за пределами статического контента.

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

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

Большие языковые модели мощны, но без контекстного якорения они склонны к галлюцинациям. Чтобы решить эту проблему, мы реализовали технику векторного вложения.

Руководства пользователя, внутреннюю документацию и видение продукта преобразовали в числовые векторные представления текста. Эти вложения захватили семантическое значение, позволяя системе сопоставлять понятия, а не полагаться на простое совпадение ключевых слов.

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

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

Скрытая сложность управления контекстом

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

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

Чтобы смягчить это, мы реализовали стратегии для контроля размера подсказки, определения приоритета релевантного контента и мониторинга длины вопроса. Мы экспериментировали с суммированием старых сообщений и выборочным включением только наиболее релевантных частей разговора. Контекст был критичен, но он должен был быть тщательно управляем.

Расширение возможностей и создание путаницы

За пределами ответов на вопросы, основанные на документации, мы расширили возможности бота, добавив функции бэкенда, которые могли извлекать определенные публичные данные直接 из приложения. Это позволило пользователям получать данные из чата без входа в приложение. Идея заключалась в том, чтобы уменьшить трение и укрепить чат-бота как полезный интерфейс, а не только как статический слой знаний.

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

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

Интеграция актуальных данных также ввела новые технические соображения. Нам нужно было определить, когда вопрос должен пройти через извлечение на основе вложений и когда он должен вызвать бэкенд-вызов. Это решение требовало тщательного проектирования. Кроме того, нам нужно было настроить ответы, чтобы они могли корректно обрабатывать технические исключения и избегать показа сырых системных ошибок пользователям.

Мультимедийная возможность не является автоматической

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

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

Это подчеркнуло важный вывод: мультимедийная возможность не является автоматической.

Когда ожидания выходят за пределы объема

Чтобы контролировать затраты на использование, мы реализовали ежедневный лимит на количество вопросов, которые пользователи могли задать. Однако мы не явно ограничили объем этих вопросов. Пользователи были свободны задавать любой вопрос.

Эта открытость привела к неожиданным моделям использования. Некоторые пользователи начали взаимодействовать с ботом для личных или исследовательских целей, не связанных с приложением. Со временем ожидания выросли за пределы предполагаемой роли бота, создав разрыв между тем, что пользователи надеялись, что он может сделать, и тем, что он был разработан для поддержки.

Эта несоответствие постепенно уменьшило его воспринимаемую полезность. Использование уменьшилось, и чат-бот был в конечном итоге исключен, а усилия были перенаправлены на переработку приложения, чтобы сделать его более интуитивным и простым в использовании.

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

С точки зрения инженерии система работала достаточно хорошо. Она извлекала документацию, включала историю разговора, уменьшала галлюцинации с помощью вложений, обрабатывала бэкенд-вызовы и управляла размером подсказки. Архитектура функционировала как предполагалось.

Но ей не хватало намеренного проектирования взаимодействия.

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

Мы узнали, что системы ИИ для разговора требуют больше, чем сильные модели и структурированные данные. Они требуют тщательно разработанных ожиданий. Пользователям нужна ясность о роли агента, его границах и его силах. Система должна активно предоставлять примеры подсказок, уточнять ограничения и перенаправлять вопросы, выходящие за пределы объема, последовательно.

Без этого намеренного кадра даже технически правильная реализация может испытывать трудности в поддержании ценности. Пользователи могут переоценивать возможности или отключаться, когда неявные ожидания не удовлетворяются.

Основной вывод прост, но мощен.

Создание системы ИИ для разговора не является только технической задачей. Это также задача проектирования взаимодействия.

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

Технология сама по себе не гарантирует принятие. Ясное проектирование взаимодействия гарантирует.