Evals для AI API: как выбрать модель на тестовом наборе

Короткий ответ: начните с продуктового решения

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

Один набор редко подходит всем сценариям. Разделите простые, пограничные и негативные примеры, а также ситуации с отсутствующими данными. Если задача обрабатывает персональные данные или коммерческие документы, используйте synthetic либо согласованно обезличенные случаи. Эта статья не заменяет юридическую оценку и не разрешает передачу данных в обход договора или правил.

Соберите версионируемый тестовый набор

Каждый кейс должен иметь стабильный ID, версию, вход, ожидаемые свойства и владельца. Для свободного текста используйте рубрику с понятными уровнями, а для структуры — JSON Schema и проверку обязательных полей. Не редактируйте набор после неудачного прогона так, чтобы он «подошёл» выбранной модели: внесите изменение отдельной версией с причиной и повторите сравнение всех кандидатов.

Добавьте сложные, но реалистичные примеры: неоднозначный запрос, отсутствие факта, запрет на действие, смешанный русский и английский текст, пустое поле и слишком длинный ввод. Цель не в том, чтобы поймать модель на каждом шаге, а в том, чтобы заранее увидеть границы продукта. Непройденный кейс — полезный сигнал для prompt, routing, human review или отказа.

Выберите метрики без ложной точности

Для каждого кандидата считайте pass rate по критическим проверкам, долю корректного отказа, ошибки схемы, медианную задержку и наблюдаемую стоимость в разрешённом биллинговом контуре. Показывайте размер выборки и диапазон, а не единственный процент с двумя знаками после запятой. Если поле usage или цена не подтверждены для маршрута, пометьте метрику как неподтверждённую вместо финансового обещания.

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

Проведите сравнение и разберите ошибки

Запускайте одинаковую версию набора с фиксированными параметрами, отдельным budget cap и server-side ключом проекта. Сохраняйте ID прогона, модель, дату, версию клиента, агрегаты и ссылки на безопасные synthetic примеры. Не кладите ключи, cookies, полный Authorization header и приватные prompts в общий отчёт. Для воспроизводимости важнее идентификатор набора и правила оценки.

Разберите ошибки по классам: неверный факт, нарушение схемы, отказ там, где нужен ответ, небезопасное действие, таймаут или слишком дорогой путь. У каждого класса должен быть следующий шаг: улучшить prompt, добавить валидацию backend, маршрутизировать на другую модель, включить human review или отклонить сценарий. Не маскируйте слабый результат бесконечным retry или несанкционированной передачей задачи другому аккаунту.

Canary и постоянная переоценка

Даже победитель evals включается через feature flag и малый canary. Наблюдайте те же инварианты в production-метаданных: схемы, safe refusal, задержку, расход и жалобы, но без сохранения лишнего содержания. Стоп-условия и rollback готовятся до релиза: неожиданный рост ошибок, нарушение политики данных, превышение бюджета или потеря обязательного свойства.

Повторяйте evals после смены model ID, версии, base URL, prompt, источника RAG или продуктового требования. Модели могут изменяться, а старый тест не доказывает неизменный результат. Такой цикл помогает выбрать модель на имеющихся доказательствах и честно обозначить границы, вместо того чтобы обещать «лучшую» модель для всех задач.

Server-side пример

Пример показывает безопасную проверку на сервере. Ключи берутся только из окружения; до запуска подтвердите маршрут и model ID в текущем каталоге RussiaAPI.

export function scoreCase({ requiredFields, output }) {
  const missing = requiredFields.filter((field) => output?.[field] === undefined);
  return { pass: missing.length === 0, missing };
}

export function summarizeEvals(runs) {
  const valid = runs.filter((run) => typeof run.pass === 'boolean' && Number.isFinite(run.ms));
  if (valid.length === 0) throw new Error('no_valid_runs');
  return {
    total: valid.length,
    passRate: valid.filter((run) => run.pass).length / valid.length,
    medianMs: [...valid].sort((a, b) => a.ms - b.ms)[Math.floor(valid.length / 2)].ms,
  };
}

// Keep test data synthetic or approved and anonymized; aggregate results before reporting.

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

Границы и безопасный запуск

Это инженерное руководство, а не юридическое заключение и не инструкция по обходу законов, санкций, региональных, платёжных или платформенных ограничений. Не передавайте в тесты персональные данные, коммерческие секреты, upstream-ключи, cookie, пароли или полный заголовок Authorization. Для чувствительных данных подтвердите цель, минимизацию, срок хранения и договорные условия с ответственными специалистами.

Ключ RussiaAPI хранится только в server-side secret store. Разделяйте development, staging и production, ограничивайте доступ и журналируйте только безопасные метаданные. Неизвестную функцию, модель или поле ответа считайте неподтверждёнными, пока не проверите их на текущем разрешённом тестовом контуре.