AI
Бриф на AI-чат-бота: границы ответа, уточнения и передача человеку
Как сформулировать требования к AI-боту: допустимые темы, знания, память диалога, разрешённые действия, оценка ответов и передача оператору.
Определите полезный диалог и его границы
Бриф на AI-чат-бота должен начинаться с задач, которые пользователь сможет решить в разговоре. «Отвечать на любые вопросы» не является проверяемым требованием. Укажите аудиторию, канал, доступные темы и результат: объяснить условия, помочь выбрать следующий шаг, собрать исходные данные или передать обращение специалисту. Для каждой задачи нужен пример законченного диалога.
Разделите консультацию и действие. Объяснить порядок изменения заказа — одна возможность, действительно изменить заказ — другая. Во втором случае требуются проверка роли, определение объекта, подтверждение намерения и результат внешней операции. Не включайте действия в проект неявно под общей формулировкой «умный помощник». Их последствия должны быть понятны владельцу процесса.
Назовите темы, в которых бот не должен давать самостоятельные обещания. Например, индивидуальные условия, ещё не утверждённая скидка или решение нестандартного спора. Конкретные ограничения определяются бизнесом. Их полезно записывать вместе с допустимым следующим шагом: уточнить, показать проверенное правило, создать обращение или передать человеку. Один запрет без альтернативы оставляет пользователя в тупике.
Задайте источники и поведение при неизвестности
Для каждой темы укажите источник ответа и ответственного за его актуальность. Отделите действующие документы от архивов, маркетинговых материалов и переписки. Бот должен понимать границы доступного контекста, а интерфейс — не выдавать предположение за подтверждённое правило. Если источник противоречив, поведение должно быть заранее определено и включено в тестовую выборку.
Полезно описывать ответы через критерии: относится к вопросу, подтверждается разрешёнными данными, не пропускает существенную оговорку и предлагает подходящий следующий шаг. Требование «пишет дружелюбно» добавляет тон, но не проверяет содержание. Для критичных условий сначала проверяют правильность, затем удобство формулировки. Убедительный стиль не должен маскировать отсутствие сведений.
Учебный пример: человек спрашивает, можно ли получить заказ к конкретному времени, но бот не имеет доступа к актуальной доставке. Правильное действие — обозначить ограничение и предложить проверку доступным способом. Выдуманный точный срок является ошибкой, даже если выглядит полезнее осторожного ответа. В брифе нужны такие отрицательные примеры с объяснением причины.
Опишите уточнения и память разговора
Уточняющий вопрос нужен, когда без него нельзя надёжно выбрать ответ или действие. Составьте перечень обязательных данных для каждой задачи и порядок их получения. Не заставляйте человека отвечать на длинную анкету, если достаточно одного признака. При этом пропуск важного уточнения ради короткого диалога может привести к неверному решению.
Определите, какие сведения сохраняются в пределах сессии и какие доступны между обращениями. Пользователь может поменять предмет разговора, исправить номер заказа или начать работу с другого устройства. Бот должен учитывать явное исправление и не продолжать использовать устаревший контекст. В тестах нужны местоимения, краткие ответы, смена темы и возвращение к прежнему вопросу.
Память связывают с подтверждённым пользователем и разрешённой задачей. Одинаковое имя не означает один аккаунт, а открытая вкладка не всегда принадлежит прежнему человеку. В брифе задайте срок жизни сессии, очистку и поведение после выхода. Объём сохраняемых данных должен быть объясним: хранить весь разговор бессрочно только ради «персонализации» не является технической необходимостью.
Ограничьте действия и недоверенные инструкции
Если бот вызывает инструменты, каждому инструменту нужен контракт: входные данные, допустимые роли, проверка объекта, подтверждение и результат. Модель может предложить действие, но окончательное разрешение должно проверяться системой. Текст пользователя или найденного документа не должен самостоятельно менять права и правила выполнения операции.
OWASP описывает prompt injection как риск смешения инструкций и недоверенного содержимого. В требованиях к боту отделите управляющие правила от текста документов и сообщений. Для вашего процесса подготовьте тесты, где источник просит раскрыть данные, игнорировать ограничения или вызвать неподходящий инструмент. Защита оценивается по фактическому поведению, а не по наличию красивой фразы в системном промпте.
Повтор инструментального действия также требует проверки. Если пользователь повторил просьбу после задержки ответа, бот должен выяснить результат предыдущей операции, а не бездумно создать второе обращение. Для необратимых шагов задайте явное подтверждение и возможность отказа до выполнения. Не обозначайте начатую операцию завершённой, пока внешний сервис не подтвердил согласованный результат.
Сделайте передачу человеку частью сценария
Передача оператору должна сохранять полезный контекст: задачу пользователя, уже уточнённые сведения, проверенные факты и причину эскалации. Не нужно автоматически пересылать всё содержимое разговора, если для решения достаточно ограниченного набора. Согласуйте, какие данные допустимы получателю и где оператор увидит обращение.
Опишите доступность сотрудников и поведение вне рабочего времени. Если оператор сейчас не подключится, пользователь должен получить честное сообщение и доступный следующий шаг. Нельзя имитировать присутствие человека или обещать ответ через несколько минут без подтверждённого процесса. Бот может принять обращение, но должен ясно различать приём и фактическое начало работы специалиста.
Добавьте сценарий возврата из ручной обработки. Кто закрывает обращение, может ли бот продолжить разговор и как он узнает актуальное решение? Без этого диалог иногда застревает между каналами: сотрудник уже ответил, а бот продолжает предлагать старое действие. В брифе полезна простая схема состояний с владельцем каждого перехода.
Соберите набор диалогов для оценки
Тестовый набор должен покрывать задачи, а не только популярные формулировки. Включите обычный вопрос, неполные данные, противоречие, смену темы, неизвестный ответ, ограничение доступа и передачу человеку. Для инструментов добавьте отказ, тайм-аут и повтор. Ожидаемый результат может быть не точной фразой, а набором обязательных фактов и запрещённых последствий.
NIST AI Risk Management Framework предлагает рассматривать риски AI системно и на протяжении жизненного цикла. Для небольшого бота практическим продолжением этого подхода служат назначенные владельцы качества, критерии критической ошибки и повторная оценка после изменений. Это наша прикладная структура проверки, а не утверждение, что отдельный тест означает соответствие какому-либо стандарту.
Разделите оценки правильности, полноты, полезности следующего шага и соблюдения границ. Средняя хорошая оценка не должна скрывать выдачу чужих данных или опасное действие. Критические нарушения фиксируют отдельно и используют как условие остановки запуска. Порог обычных ошибок согласуют с учётом задачи, а не выбирают только для получения красивого процента.
Подготовьте пилот и наблюдение за качеством
Пилот ограничивают темами, каналом или доступной аудиторией. Укажите, кто смотрит спорные диалоги и как быстро отключается проблемный сценарий. Сохраняйте версию модели, источников, правил и инструментов, чтобы изменение качества можно было связать с конкретным выпуском. Без этого команда сравнивает результаты разных систем, не замечая разницы в условиях.
Для наблюдения полезны доля задач с подтверждённым завершением, причины передачи человеку, повторные вопросы и ошибки источников. Эти показатели не равны продажам. Если заказ или заявка не связаны с диалогом подтверждённым способом, не приписывайте их боту. Неизвестные значения остаются неизвестными; отсутствие данных не означает отсутствие проблемы.
План поддержки должен включать исправление знаний, изменение сценариев и регрессионную проверку. После добавления нового инструмента старые тесты всё ещё нужны: расширение возможностей может изменить привычное поведение. Если исправление одного ответа ухудшает другой, решение следует оценивать на наборе задач, а не по одному удачному примеру из демонстрации.
Передайте бриф с примерами и ограничениями
В приложенном шаблоне предусмотрены аудитории, источники, память, действия, передача человеку и оценка. Заполните его несколькими настоящими обезличенными вопросами и собственными ожидаемыми ответами. Отметьте открытые решения: кто утверждает знания, какой канал принимает эскалацию и какие операции пока запрещены. Это делает оценку разработки предметной.
Для первой очереди выберите узкий законченный сценарий, где можно проверить пользу и ошибки. Например, бот помогает определить тип обращения, получает необходимые сведения и передаёт их ответственному с понятным подтверждением. Добавлять свободные ответы по всем темам до появления проверенных знаний и оценки качества обычно означает расширять неопределённость проекта.
Связанные материалы о боте для сайта, оценке AI и требованиях к агентам помогут уточнить технические части. Разработка начинается после согласования границ разговора и действий. Хороший результат — помощник, который решает определённые задачи, распознаёт недостаток данных и передаёт сложный случай человеку, сохраняя ответственность и проверяемость процесса.
Источники
- LLM Prompt Injection Prevention Cheat Sheet
OWASP / доступ 2026-10-12
Первичный источник для соответствующей технической темы. Структура брифа и учебные проверки разработаны редакцией; возможности конкретной системы проверяются перед внедрением.
- AI Risk Management Framework
NIST / доступ 2026-10-12
Первичный источник для соответствующей технической темы. Структура брифа и учебные проверки разработаны редакцией; возможности конкретной системы проверяются перед внедрением.
- Скачать заполняемый бриф / ТЗ (.txt)
Малевич — практическое приложение / доступ 2026-10-12
Сохраните файл и заполните исходные данные, решения и критерии приёмки своего проекта.
FAQ
Сколько примеров нужно для оценки AI-бота?
Универсального числа нет. Набор должен покрывать разные задачи, неоднозначные запросы, неизвестные ответы, ограничения доступа и опасные действия. Сначала согласуют покрытие и критические ошибки, затем расширяют выборку реальными обезличенными ситуациями. Большое число однотипных вопросов не гарантирует полезной проверки.
Должен ли бот отвечать уверенно на любой вопрос?
Нет. Отсутствие проверенных данных, конфликт условий или недостаток контекста требуют уточнения, ограничения ответа либо передачи человеку. В брифе задают конкретные примеры такого поведения и проверяют их отдельно от обычных успешных диалогов. Уверенный тон не является мерой достоверности.
Можно ли дать боту общий административный аккаунт?
Такой подход затрудняет ограничение действий и аудит. Инструментам нужны минимальные разрешения, проверка роли пользователя и понятный журнал операций. Модель не должна самостоятельно расширять свои права или превращать текст из документа в разрешение на изменение данных.
