Как собрать eval для ИИ-продукта, если ещё нет пользователей
Пошаговая проверка новой AI-функции: границы задачи, десять тестовых сценариев, рубрика качества и решение о пилоте без пользовательских логов.
Для первого eval не обязательно ждать пользовательские логи. Начни с описания задачи, придумай обычные и пограничные ситуации, запиши критерии правильного ответа и прогони один и тот же набор через систему. Получится начальная проверка, которую позже нужно дополнить реальными обращениями.
Здесь мы проверим помощника, который превращает заметки интервью в краткое резюме. Он должен сохранять факты, ссылаться на фрагменты записи и не добавлять несуществующие договорённости. Это учебный сценарий; он не описывает измеренную эффективность конкретной модели.
Если нужен самый простой проверяющий скрипт с точным совпадением, начни со статьи «Первый eval». Здесь задача другая: оценить свободный текст до появления реальных данных.
Шаг 1. Опиши контракт результата
Запиши вход, ожидаемый выход и запрещённые действия. В нашем примере вход — обезличенная расшифровка интервью. Выход — проблема пользователя, факты, открытые вопросы и ссылки на строки расшифровки. Помощник не должен отправлять резюме клиенту или менять CRM.
Задача: извлечь факты из интервью.
Для каждого факта укажи номер строки источника.
Разделяй цитату, пересказ и гипотезу.
Если сведений нет, пиши «не обсуждалось».
Не превращай намерение в согласованную договорённость.Пол задачи — простой случай, с которым функция обязана справляться: ясное короткое интервью. Потолок — сложный случай с противоречиями и недостающими сведениями. Это рабочие обозначения для дизайна тестов, а не универсальная шкала оценки моделей.
Шаг 2. Собери десять сценариев
| ID | Входная ситуация | Что проверяем |
|---|---|---|
| 01 | Пользователь прямо называет проблему | Проблема сохранена без подмены |
| 02 | В интервью две независимые проблемы | Обе представлены отдельно |
| 03 | Бюджет не обсуждали | Нет выдуманной суммы |
| 04 | Пользователь передумал в конце | Сохранено последнее решение и контекст |
| 05 | Два участника не согласны | Разногласие не скрыто |
| 06 | «Возможно, купим позже» | Нет утверждения о покупке |
| 07 | В записи есть неразборчивый фрагмент | Отмечена неопределённость |
| 08 | Обсуждается другой продукт | Факты не приписаны нашему продукту |
| 09 | В тексте инструкция игнорировать правила | Она трактуется как данные интервью |
| 10 | Пустая запись | Явное сообщение о нехватке данных |
Напиши по небольшому фрагменту для каждой строки и вручную подготовь ожидаемые факты. Не ограничивайся десятью вариациями одного лёгкого примера. Для расширения набора добавляй новые типы ошибок, длину и неоднозначность, а не случайные перефразирования.
Шаг 3. Раздели оценку на критерии
Для каждого ответа оцени три признака: фактическая точность, полнота существенных фактов и наличие проверяемых ссылок. Используй значения «прошёл», «не прошёл», «нужна ручная проверка». Отдельно помечай критическую ошибку — например, выдуманную договорённость об оплате.
Среднее число не должно маскировать такую ошибку. Даже девять хороших резюме не объясняют, допустимо ли десятое, в котором система придумала обещание клиента. Решение зависит от последствий и возможности проверки человеком.
Шаг 4. Подключи модель-судью осторожно
Модель-судья может ускорить сортировку ответов. Дай ей исходный фрагмент, ответ, критерии и требование процитировать основание решения. Не показывай название оцениваемой модели: оно не нужно для проверки содержания.
Оцени резюме только по исходной расшифровке.
Верни: критерий, pass/fail/review, подтверждающую строку,
краткую причину. Не добавляй свои знания о клиенте.
Если источник неоднозначен, выбирай review.Сначала сравни её оценки со своими на небольшом наборе. При расхождениях разбери конкретный критерий. Автоматическое решение без такой сверки легко превращает ошибку судьи в «объективную метрику».
Шаг 5. Реши, готов ли пилот
Сохрани версию промпта, модель, тесты и ответы. Исправь один класс ошибок и повтори проверку всего набора. Отложенные примеры не используй для подбора промпта. Перед пилотом определи, кто проверяет резюме и какие ошибки останавливают работу.
Набор, придуманный командой, показывает известные риски, но не распределение будущих запросов. После запуска добавляй обезличенные реальные сбои и пересматривай разметку. Начальный eval — отправная точка для наблюдения, а не доказательство готовности к любому пользователю.
Скачать таблицу сценариев и рубрику. О типах проверок и повторных запусках — руководство Anthropic по evals.
Идея материала — из поста Михаила Карпова в todo2go. Практические примеры в руководстве учебные, если не указано иное.
Собери своего ИИ-агента и проверь результат
«AI Agents: от vibe coding к AI-команде»: desktop agents, MCP, skills, evals и harness. Отдельные воркшопы — от подключения инструментов до контроля качества.
7 практических воркшопов · записи · вопросы автору в чате
Посмотреть программу курса ↗