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

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

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

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

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

Основание модели: от зрелищ до надежного контекста

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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