Вводные

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

Люди, особенно в бизнес-сегменте, заинтересованы в правдивых ответах бота на проверенных источниках данных. Для этого существует технология RAG (Retrieval-Augmented Generation — генерация с дополненной выборкой), когда помощник дообучается на достоверной определенной человеком выборке данных, что снижает количество галлюцинаций. Соответственно, нужен продукт, который закроет эту потребность.

Постановка задачи ограничивалась идеей, отвечающей на вопросы «что мы делаем и почему это должно сработать». Но не для кого и зачем, как продуктом будут пользоваться.

Провела небольшое исследование рынка, поштормила с программистом и СРО (идейным вдохновителем), сформулировала базовые данные по задаче.

Таким образом, запрос пользователя звучит так: «Хочу получать (и предоставлять другим) достоверную информацию на основе моих данных. Соответственно, нужен такой бот, в которого могу данные загрузить, а потом пользоваться как мне удобно».

Работа шла в специфических условиях: ограниченное время, ограниченные ресурсы и технические возможности, без полного понимания технологии (выясняли прямо по ходу разработки).

Ключевой функционал и нюансы на старте:

В целом, вот такая простая схема:

Создаваю наброски сценариев и проверяю, как они могут объединятся в глобальные флоу. Ищу оптимальную форму для ключевого функционала: билдер Ассистента.

Было две первичных версии:

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

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

Чат расположила по центру экрана, сделав его основной рабочей областью

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

Так же определили формат настроек (Модель уходит на второй план относительно Знаний как редко изменяемый параметр) и примерный список разделов продукта:

Процесс дизайна был довольно веселым, в силу условий выполнения. Часть функционала отрисовывалась примерно, чтобы программист понимал общую структуру, и уточнялась после проведения технического исследования. Поэтому некоторые участки интерфейса выглядели как-то так чуть ли не до последних этапов разработки (функционал написания промпта при настройке модели):

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

Чат расположила по центру экрана, сделав его основной рабочей областью

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

Так же определили формат настроек (Модель уходит на второй план относительно Знаний как редко изменяемый параметр) и примерный список разделов продукта:

Основной сценарий после тестирований

Посмотреть весь сценарий со всеми тонкостями: Кликабельный прототип

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

Шаг 5: Разработка нового чат-виджета

Data Agent показал отличные результаты на западном рынке (цифры под NDA), подтвердив свою нужность.

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

Его успех вдохновил компанию на разработку Jay Copilot и Jay Knowledge Hub для российского рынка.

Постановка задачи ограничивалась идеей, отвечающей на вопросы «что мы делаем и почему это должно сработать». Но не для кого и зачем, как продуктом будут пользоваться.

Провела небольшое исследование рынка, поштормила с программистом и СРО (идейным вдохновителем), сформулировала базовые данные по задаче.

Таким образом, запрос пользователя звучит так: «Хочу получать (и предоставлять другим) достоверную информацию на основе моих данных. Соответственно, нужен такой бот, в которого могу данные загрузить, а потом пользоваться как мне удобно».