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

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

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

Что такое эталонный набор

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

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

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

Из каких задач его собирать

Начните с рабочих примеров, а не с придуманных идеальных запросов. Разделите их на три группы.

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

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

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

Для каждой задачи сохраните четыре вещи:

• исходный вход без украшения;
• обязательные элементы результата;
• недопустимые ошибки;
• действие при неопределённости.

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

Критерии формулируйте через наблюдаемое поведение. Вместо "ответ качественный" напишите: извлечены нужные поля, числа совпадают с документом, вывод отделён от предположения, запрещённые данные не появились, сомнительный случай отправлен на проверку.

Проверяйте весь процесс, а не только текст

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

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

Как принимать решение после теста

Не сводите результат к одной средней оценке. Разделите выводы:

• что проходит стабильно;
• что проходит только с проверкой сотрудника;
• что требует исправления процесса;
• что пока нельзя автоматизировать.

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

Минимальный набор для первого пилота

Возьмите одну повторяемую задачу и соберите рабочую папку:

1. примеры обычных, сложных и рискованных случаев;
2. ожидаемый результат для каждого примера;
3. короткий список обязательных и запрещённых признаков;
4. правило передачи человеку;
5. таблицу результатов нескольких прогонов.

Этого достаточно, чтобы разговор "кажется, стало лучше" заменить проверяемым сравнением. Большая платформа оценки понадобится позже, если пилот подтвердит ценность и число сценариев вырастет.

Вопросы по теме

Нужно ли включать в набор конфиденциальные документы?

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

Кто должен описывать ожидаемый результат?

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

Когда добавлять новый пример?

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

Можно ли сравнивать разные модели одним набором?

Да, если входы, инструменты и критерии одинаковы. Тогда сравнение показывает различия в результате, а не различия в условиях.

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