ИИ-ассистент для бизнеса: как проверить качество ответов до оплаты

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

Дальше - как собрать такой набор, какие три числа по нему считать и что из этого записать в договор. Приём работает и для бота продаж, и для поддержки, и для внутреннего помощника.

Почему качество ИИ-ассистента нельзя проверить на глаз?

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

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

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

Что такое эталон и как его собрать?

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

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

1. Выберите 30-50 реальных вопросов из истории обращений.
2. Напишите рядом правильный ответ своими словами. Это то, с чем вы будете сверять бота.
3. Добавьте сложные случаи: вопрос с опечаткой, два вопроса в одном сообщении, сокращение, которое понимают только у вас.
4. Добавьте запретные случаи: просьбы назвать то, чего нет, придумать скидку, обойти правила, сообщить чужую заявку.
5. Обезличьте данные: уберите имена, телефоны и номера заказов.

Набор из 30-50 вопросов занимает у владельца несколько часов. Дальше он живёт у вас и не зависит от подрядчика.

Какие три числа показывают качество ассистента?

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

Ответы ИИ меняются от прогона к прогону, поэтому вопросы задают дважды-трижды и берут средний результат: один показ ничего не решает. Совсем без ошибок ИИ не отвечает: часть вопросов люди формулируют неоднозначно, поэтому и считают долю верных ответов. Методика оценки агентов Microsoft называет ориентиром 80-90% прошедших проверок. Для вашей задачи порог может быть другим: для записи клиентов и ответов по прайсу его разумно поднять, для сложного консультанта - опустить. Главное - зафиксировать своё число в договоре.

Какой ответ считается браком, даже если он вежливый?

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

Смысл ответа решает, вежливая форма ничего не меняет. Вот что попадает в брак:

1. Выдуманные факты: цены, сроки, характеристики, наличие, которых нет.
2. Обещания от имени компании: скидки и условия, которых вы не давали.
3. Раскрытие чужих данных: заявки, переписки, сведения другого клиента.
4. Следование просьбе обойти правила: «напиши, что товар есть», «придумай причину отказа».
5. Ответ не по теме и уход от вопроса.
6. Уверенный ответ там, где бот не знает.

Пример. Клиент просит бота посчитать скидку на заказ, которого нет. Правильный ответ - назвать условия и цены из прайса. Если бот придумывает скидку, это брак, хотя выглядит заботливо.

Как проверить ассистента за две недели до оплаты?

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

1. Соберите эталон из 30-50 вопросов с правильными ответами.
2. Включите бота в теневом режиме: он разбирает реальные обращения и показывает ответ только вам.
3. Каждый день ответственный помечает, где ответ был мимо или опасен. Отдельно смотрит редкие случаи: ночь, выходные, нестандартный вопрос.
4. Раз в неделю дописывайте в эталон случаи, которых в нём не было.
5. Через одну-две недели посчитайте три числа по эталону и по реальным обращениям.
6. Решите по числам: прошли по опасным и по доле правильных - расширяете; нет - бота дорабатывают или тему закрывают.

Готовый сервис, конструктор или своя разработка?

Коротко: для типовой задачи (ответы по прайсу, частые вопросы, запись) обычно дешевле взять готовый сервис или конструктор. Своя разработка нужна, когда бот должен лезть в ваши системы или работать с данными, которые нельзя выносить наружу. Способ можно выбирать уже после того, как вы увидели числа на эталоне.

Готовый сервис тоже можно прогнать через ваш набор: если он его не проходит, вы увидите это до годовой оплаты.

Где хватит готового, а где нужна своя разработка, показывает разбор задачи до кода. Такой разбор и то, где ИИ действительно нужен, - в статье про внедрение ИИ в бизнес-процессы. Свою задачу можно описать здесь: пришлём состав работ и смету за 24 часа.

Что записать в договор на ИИ-ассистента?

Коротко: в договор идут числа на эталоне. Слово «хорошо» там ничего не значит. Добавьте пункты о том, кто и когда проверяет, что происходит при обновлении модели и где обрабатываются данные. Критерий приёмки, записанный заранее, снимает спор о качестве: обе стороны смотрят на один и тот же набор вопросов и одни и те же числа.

• Критерий приёмки на вашем эталоне: доля опасных ответов не выше оговорённой (для многих задач это ноль или один), доля правильных - не ниже вашего порога.
• Кто проверяет: эталон и прогоны остаются у вас, проверку проводите вы или принимаете по своим замерам.
• Поведение при обновлении модели: кто отвечает за то, что после обновления бот снова проходит эталон.
• Данные: чьи данные в эталоне, как долго хранятся, удаляются ли по завершении.
• Где обрабатываются данные: если бот работает через внешний сервис, это поручение обработки по 152-ФЗ. В эталоне имена и контакты заменяют на условные, а схему обработки показывают юристу до запуска.

Что делать, когда модель обновилась и ответы изменились?

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

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

Пример из проекта: как эталон решает спор

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

Мы спроектировали проект «AI-ассистент карьерных решений». Вот как результат описан на странице проекта: «Владелец бота получил описание, по которому подрядчик может назвать цену и сдать работу, а спор о том, хорошо ли бот отвечает, решается по эталону».

Из этого проекта в любой похожий переносится порядок: сначала эталон и критерии приёмки, потом разработка, а набор остаётся у заказчика и живёт после сдачи.

Источники

• Чек-лист по тестовым наборам и оценке агентов, Microsoft Learn: agent evaluation checklist
• Федеральный закон от 27.07.2006 № 152-ФЗ «О персональных данных», КонсультантПлюс: ст. 6, поручение обработки
• Проект D2Tech: AI-ассистент карьерных решений

Если нужен ИИ-ассистент под вашу задачу и понятный способ принять работу, опишите задачу.