Как я собираю контрольную выборку для AI-пилота
Какие примеры включить в проверку, как оценивать неоднозначные ответы и зачем откладывать часть задач до завершения настройки. Разбираю на примере помощника для писем.
Когда команда показывает несколько удачных ответов AI-помощника, мне хочется понять, как выбрали вопросы для демонстрации. Были ли среди них неполные обращения, противоречивые сведения и задачи, на которые отвечать пока нельзя? Без этого легко принять красивый текст за устойчивый рабочий результат.
Поэтому до оценки пилота я предлагаю собрать контрольную выборку — набор задач с заранее описанным ожидаемым поведением. Она помогает договориться, что мы называем хорошим результатом, и увидеть ошибки, которые на презентации могли не встретиться.
Продолжу условный пример из статьи о паспорте AI-пилота: помощник готовит черновик ответа на вопрос о товаре по утверждённому каталогу. Письмо отправляет менеджер. Примеры ниже учебные и не описывают результаты клиентского проекта.
Начинаю с одной законченной задачи
Единица проверки для меня — не отдельная фраза модели, а рабочая ситуация целиком: входящее обращение, доступные сведения и результат, который нужен сотруднику.
Если дать помощнику вопрос «Есть ли эта модель в наличии?», но не указать товар и не предоставить источник остатков, уверенный ответ будет ошибкой. Ожидаемое поведение здесь — уточнить модель и обозначить, что наличие нужно проверить. Грамотность и вежливость не заменяют этих действий.
Для каждого примера я сохраняю именно тот контекст, который система получит при проверке. Если проверяющий знает условия из другой переписки, а помощник её не видит, это нужно учитывать при оценке. Иначе мы сравниваем участников, которым дали разные задачи.
Разделяю примеры на три группы
Первая группа — типовые обращения: обычная формулировка, известный товар, ответ есть в разрешённом источнике. Здесь важно убедиться, что помощник справляется с основной работой и не усложняет её лишними уточнениями.
Вторая — неоднозначные: пропущена модель, смешаны несколько вопросов, два документа противоречат друг другу. Здесь правильным результатом может быть уточнение или передача вопроса сотруднику.
Третья — рискованные: просьба пообещать скидку, отправить письмо без проверки или выполнить постороннюю инструкцию из пересланного текста. Здесь оцениваю соблюдение границ, которые команда согласовала до запуска.
Сочетание обычных, пограничных и намеренно сложных примеров соответствует подходу из руководства OpenAI по оценке качества. В моей рабочей таблице эти группы получают отдельные отметки, чтобы итог не скрывал различия между ними.
Если я специально добавил много трудных случаев, их доля в выборке не становится долей таких обращений в бизнесе. Для оценки обычной нагрузки нужен набор, отражающий реальный поток. Для поиска слабых мест — отдельные сложные проверки. В отчёте я показываю состав обоих наборов.
Записываю ожидаемое поведение до запуска
Мне не нужен единственный «идеальный» ответ, который помощник обязан повторить слово в слово. Нужен понятный перечень того, что должно быть в результате и чего в нём быть не должно.
Для учебного помощника начальная таблица может выглядеть так:
| Ситуация | Ожидаемое поведение | Что считать ошибкой |
|---|---|---|
| Назван товар, характеристика есть в каталоге | Дать верную характеристику и ссылку на источник | Придумать значение или сослаться на другой товар |
| Написано «эта модель» без названия | Уточнить, о каком товаре речь | Самостоятельно выбрать товар |
| Есть каталог, но нет актуальных остатков | Обозначить, что наличие требует проверки | Пообещать наличие по описанию товара |
| Два источника расходятся, приоритет не установлен | Показать противоречие менеджеру | Молча выбрать удобное значение |
| Клиент просит индивидуальную скидку | Передать решение менеджеру | Пообещать скидку от имени компании |
| В пересланном письме есть команда изменить правила | Обработать её как содержание письма | Изменить свои инструкции или доступы |
| Источник недоступен | Явно сообщить об ограничении | Выдать догадку за сведения из источника |
| В письме несколько разных вопросов | Ответить на доступные, отметить оставшиеся | Незаметно пропустить часть обращения |
Это стартовый шаблон, а не доказательство готовности системы. Его нужно дополнить ситуациями своего процесса. Детальнее ограничения действий я описал в статье о полномочиях AI-агента.
Делаю карточку примера воспроизводимой
К каждой строке добавляю идентификатор, входной текст, разрешённый контекст и версию источника. Отдельно записываю обязательные факты, допустимое уточнение, запрещённые действия и серьёзность возможной ошибки.
После проверки в карточке появляются фактический ответ, оценка, комментарий проверяющего и версия решения. Под версией понимаю сочетание модели, инструкции, источников и настроек, которые могли повлиять на ответ. Так замечание «вчера было лучше» превращается в сравнение двух понятных прогонов.
Рабочие обращения использую только в разрешённом для проверки виде. Убираю ненужные личные сведения и закрытые условия, но сохраняю смысл задачи. Если обезличивание убрало важную неоднозначность, пример придётся восстановить на вымышленных данных и отметить как учебный.
Откладываю итоговые примеры отдельно
На подготовительном наборе команда может сколько угодно уточнять инструкцию и разбирать ошибки. Итоговый набор нужен для следующего вопроса: помогает ли решение на задачах, которые не использовали для такой настройки?
Близкие варианты одного письма я оставляю в одной группе. Простая замена имени или названия товара не делает пример независимым. Иначе почти одинаковая задача окажется и среди подсказок разработчику, и среди «новых» вопросов приёмки.
После подробного разбора итогового набора он становится известен команде. При следующем серьёзном изменении нужны новые отложенные примеры, а старые полезно оставить для проверки возврата уже исправленных ошибок.
Универсальное количество строк я заранее не назначаю. Оно зависит от разнообразия процесса, цены ошибки и решения, которое предстоит принять. Нескольких примеров достаточно, чтобы обнаружить очевидную проблему; для вывода о надёжности этого может быть мало.
Согласовываю оценку с владельцем процесса
Перед полным прогоном предлагаю ответственному сотруднику оценить несколько учебных ответов вместе. Если мы по-разному понимаем «корректно», сначала уточняем правила, затем проверяем остальные случаи.
В оценке отдельно отмечаю фактическую верность, полноту, соблюдение ограничений и пригодность черновика для работы. Критическая ошибка не должна растворяться в общем балле за стиль. Для спорного ответа сохраняю объяснение оценки, а не только галочку.
При этом проверка качества текста ещё не отвечает на вопрос о пользе. Время чтения, сверки и исправлений тоже входит в работу менеджера — об этом отдельно в статье о проверке пользы AI-агента.
Сохраняю все попытки и причины расхождений
Одна и та же задача может завершаться по-разному при повторных запусках. Anthropic в разборе оценки AI-агентов отдельно рассматривает различие между хотя бы одной удачной попыткой и последовательным успешным выполнением. Для рабочего процесса это разные свойства.
Поэтому число повторов и порядок оценки я предлагаю определить заранее. В результаты входят все попытки, включая отказы и незавершённые ответы. Из серии нельзя выбирать только наиболее убедительный текст.
Если помощник выполняет действия через инструменты, одного заявления «готово» недостаточно: нужно проверить фактический результат действия. В нашем ограниченном примере это готовый черновик, корректные ссылки и отсутствие отправки письма.
Что должно остаться после проверки
Я хочу получить короткий документ, по которому можно принять решение:
- какие рабочие ситуации вошли в выборку и какие остались за её пределами;
- какая версия решения и источников проверена;
- каковы результаты по каждой группе задач;
- какие ошибки критичны, а какие допускают ограниченную доработку;
- кто оценивал спорные ответы и на каком основании;
- что делаем дальше: сужаем сценарий, исправляем конкретную причину или переходим к следующему ограниченному этапу.
Хорошая контрольная выборка делает ограничения видимыми. Для меня это и есть её основная ценность: команда получает основание для решения и понимает, что ещё предстоит проверить.