Один удачный ответ не доказывает качество промпта. После изменения формулировки модель может лучше справляться с демонстрационным примером и хуже — с короткими сообщениями, противоречивыми данными или отсутствующими полями. Тестовый набор превращает впечатление «стало лучше» в проверяемое сравнение. Его можно вести в обычной таблице, не начиная с отдельной платформы.
Материал подготовлен для Tarasov Code — проекта Ильи Тарасова и TarasovWeb. Ниже приведён учебный набор для обработки обращений; он не является статистикой работы конкретного сервиса.
Определите, какое решение принимает промпт
Начните с одной задачи. Например: распределять обращения по темам «доставка», «оплата», «возврат» и «нужно уточнение». Если тот же промпт одновременно пишет ответ, определяет приоритет и назначает сотрудника, оценивать его одной отметкой трудно. Разделите результаты на отдельные поля и критерии, сохранив общую проверку готового процесса.
Опишите правило правильного ответа. Для обращения «Где заказ и почему списали дважды?» допустимы две темы или необходимость уточнения — это зависит от вашей системы. Эталон должен отражать выбранное правило, а не личный вкус проверяющего. До тестирования согласуйте спорные случаи с человеком, который понимает рабочую задачу.
Соберите обычные, пограничные и ошибочные входы
- Обычные обращения с явно указанной темой.
- Короткие сообщения без контекста: «Не пришло», «Опять ошибка».
- Смешанные вопросы, где требуется несколько меток.
- Опечатки, переносы строк и разговорные формулировки.
- Сообщения вне области задачи.
- Текст, который пытается изменить инструкцию классификатора.
Уберите персональные данные и сохраните происхождение примера: реальный обезличенный случай или синтетический тест. Синтетические сообщения полезны для проверки конкретного ограничения, но не доказывают качество на всей реальной переписке. Держите часть набора отдельно от примеров, по которым редактируете промпт, чтобы не оптимизировать его только под знакомые формулировки.
Учебный расчёт: одинаковая точность скрывает разные ошибки
Предположим, в наборе 20 обращений: 12 обычных, 4 неоднозначных и 4 вне области задачи. Первая версия правильно обрабатывает 18 из 20, вторая — тоже 18. Но первая ошибается в двух обычных сообщениях, а вторая уверенно назначает отдел для двух сообщений вне области. Общая доля совпадений одинакова — 90%, однако риск для процесса отличается.
Поэтому считайте качество по группам и отдельно отмечайте критические нарушения. Если правило требует задавать вопрос при недостатке данных, уверенная выдуманная классификация должна попадать в собственную категорию ошибок. В маленьком наборе одна ошибка меняет показатель сразу на пять процентных пунктов: не делайте вид, что такая оценка точна до сотых.
Промпт для подготовки таблицы оценки
Помоги спроектировать тесты для промпта ниже.
Задача и допустимые ответы: [описание]. Критические ошибки: [список].
Предложи разные категории тестов и по два синтетических примера на категорию.
Для каждого примера укажи ожидаемый результат, основание и неопределённость.
Не объявляй свои эталоны правильными без проверки человеком.
Верни таблицу: ID, категория, вход, ожидаемый результат,
критерий проверки, происхождение, комментарий редактора.
Промпт: [текст].Сравнивайте версии при одинаковых условиях
Сохраните текст промпта, идентификатор модели, доступные настройки и дату запуска. Если одновременно меняются модель, инструкция и входные данные, трудно понять причину улучшения. Для нестабильных задач повторите часть запусков и посмотрите, насколько меняется результат. Стоимость и задержку фиксируйте отдельно от качества, чтобы быстрый ответ не считался правильным автоматически.
Рекомендации OpenAI по оценке полезны как источник принципов проектирования проверок. Конкретный тестовый набор всё равно должен соответствовать вашей задаче. Не переносите чужой показатель качества на собственные документы или клиентов без проверки.
Если ответы оценивает другая модель, проверьте её решения на примерах, разобранных человеком. Оценщик тоже может ошибаться, предпочитать длинный ответ или реагировать на порядок вариантов. Для объективных ограничений используйте обычные проверки: допустимый набор меток, наличие обязательного поля, правильный формат и отсутствие лишних действий.
Частые вопросы
Сколько примеров достаточно?
Начните с набора, который покрывает основные типы ошибок. Затем добавляйте реальные сбои. Универсального числа нет: объём определяется разнообразием задачи и последствиями ошибки, а не красивой круглой цифрой.
Можно ли менять эталон после неудачного теста?
Можно, если обнаружена ошибка в самом эталоне. Зафиксируйте причину и пересчитайте обе версии на одинаковом наборе. Нельзя незаметно подгонять ожидаемый ответ под новый промпт.
Когда выпускать новую версию?
Когда она проходит обязательные ограничения, не ухудшает критические группы и даёт понятное улучшение. Сохраните предыдущую версию и журнал изменений, чтобы вернуться к ней при новых проблемах.