Регрессионные тесты при изменении поведения модели API

Короткий ответ: фиксируйте задачу, а не красивый единичный ответ

Golden-набор — это небольшой набор входов и ожидаемых свойств результата, который отражает реальные сценарии продукта. Для классификации это может быть допустимая категория, для извлечения — обязательные поля, для RAG — ссылка на разрешённый фрагмент, для tool use — безопасный отказ при недопустимом аргументе. Не превращайте набор в коллекцию «идеальных» промптов: добавьте короткие, неоднозначные, пустые и ошибочные входы. Каждый fixture должен иметь версию, владельца и обоснование, почему этот случай важен для пользователя.

Не храните в golden-наборе клиентские диалоги, персональные данные, пароли, ключи, закрытые URL и полный production-контекст. Если реальная проблема требует такого типа данных, создайте синтетический аналог с тем же техническим свойством. Полезно разделить набор на smoke, критический и расширенный: smoke запускается при каждом изменении маршрута, критический — перед rollout, расширенный — по расписанию или после обновления индекса. Это снижает стоимость проверки без ложного впечатления, что один тест покрывает все будущие ответы.

Определите сравнимые сигналы и пороги решения

Ответ модели часто недетерминирован, поэтому не начинайте с посимвольного сравнения текста. Сначала определите проверяемые свойства: JSON проходит schema, ответ не содержит запрещённой инструкции, обязательное поле заполнено, цитата относится к разрешённому document_id, latency не выходит за внутренний deadline. Для текстовых задач добавьте ручную выборку с понятной рубрикой: корректность, уместность, полнота и безопасный отказ. Порог должен иметь владельца и действие: продолжить canary, остановить rollout или направить случай на review.

Сравнивайте baseline и candidate при одинаковом серверном контракте: версии prompt template, инструменты, retrieval, лимиты входа, timeout и test fixtures. Если вместе с моделью меняются пять компонентов, причина расхождения теряется. В отчёте сохраняйте только безопасные метаданные: commit сценария, время запуска, candidate label, итог каждого теста и request_id приложения. Не используйте эти результаты как публичное обещание качества, точности, цены или доступности конкретной модели.

Проверяйте контракт и ошибки наряду с качеством

Поведение меняется не только в тексте. Новый маршрут может по-другому обрабатывать поле, возвращать неизвестный статус, прекращать streaming или давать иной код ошибки. Добавьте контрактные проверки для обязательных полей, типов данных и безопасной обработки неизвестного значения. Клиент должен уметь показать нейтральную ошибку и сохранить request_id приложения, а не падать при первом несовпадении. Не предполагайте полную совместимость по названию API: конкретные поля и возможности подтверждаются тестом в актуальной среде.

Негативные сценарии особенно важны: некорректная схема, превышенный размер входа, остановленная операция, timeout, неподдерживаемый model ID и временная ошибка сети. Тест не обязан заставить gateway вернуть определённый недокументированный код; он проверяет вашу реакцию. Например, backend не должен повторять операцию с побочным действием без идемпотентности, записывать секрет в лог или подменять ошибку выдуманным успешным ответом. Такие проверки делают перенос маршрута наблюдаемым и уменьшают риск тихой деградации.

Запускайте candidate через canary и держите rollback

После локального набора не переносите весь трафик одним переключателем. Сначала направьте candidate на synthetic или согласованный тестовый tenant, затем на малую долю обратимых сценариев. Отслеживайте заранее выбранные сигналы: ошибки контракта, долю безопасных отказов, внутреннее время обработки и результаты review выборки. Сравнивайте одинаковые окна и не объясняйте любой спад «случайностью». Если порог нарушен, feature flag возвращает baseline, а команда изучает отчёт до следующей попытки.

Rollback требует подготовленного старого маршрута, а не воспоминания о том, что было вчера. Сохраните версию конфигурации, prompt template, allowlist и тестовый отчёт рядом с выпуском. При откате не удаляйте следы и не переписывайте результаты; добавьте причину и последующее решение. Это не означает, что baseline всегда лучше: иногда тест обнаруживает проблему в данных или приложении. Но именно повторяемая процедура позволяет отличить изменение модели от изменения окружения и не переносить спор в production.

Сделайте результаты пригодными для регулярного решения

Каждый запуск должен отвечать на несколько конкретных вопросов: какой сценарий проверялся, какая версия набора использована, что сравнивалось, какие пороги действовали и кто утвердил следующий шаг. Простая таблица pass, warn, fail полезнее графика без контекста. Для failed case приложите безопасный идентификатор fixture и описание свойства, а не производственный текст. Если ручной reviewer меняет оценку, версия рубрики тоже фиксируется; иначе через месяц сравнение утратит смысл.

RussiaAPI — независимый gateway, поэтому не приписывайте ему официальные статусы OpenAI, Anthropic или других разработчиков и не используйте регрессионный тест как гарантию доступности. Создайте собственный тестовый ключ, проверьте текущий каталог и выполните server-side smoke test до изменения трафика. Никакой тест не отменяет контроль доступа, минимизацию данных и наблюдение после rollout. Его ценность в более скромной, но проверяемой цели: заметить важное расхождение до того, как его обнаружит пользователь.

Server-side пример

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

export function judgeCase({ requiredKeys, output, maxLatencyMs, latencyMs }) {
  const missing = requiredKeys.filter((key) => !(key in output));
  return {
    schema: missing.length === 0 ? 'pass' : 'fail',
    latency: latencyMs <= maxLatencyMs ? 'pass' : 'warn',
    missing,
  };
}
// Run fixtures from a server-side test job. Use a documented RussiaAPI model and process.env.RUSSIAAPI_API_KEY.

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