Обновление библиотеки ИИ-моделей: как проверить результат до релиза
Команда обновила библиотеку модели, все импорты проходят, сервер отвечает без ошибки — значит ли это, что можно выпускать версию? Нет. Изменение токенизатора, шаблона диалога, режима внимания или обработки изображения может поменять результат, не вызвав исключения. Проверять нужно не только запуск, но и задачу, за которую пользователь платит временем или деньгами. Ниже — короткий маршрут для рабочего релиза, а не универсальный тест всех моделей.
Зафиксируйте старую версию
Перед обновлением сохраните версии библиотеки, модели, токенизатора и параметров генерации. Если модель берётся из удалённого репозитория, зафиксируйте ревизию, а не только красивое имя. Запишите тип оборудования и способ запуска. Один и тот же запрос с разной температурой не позволяет отделить регрессию библиотеки от обычной вариации ответа.
Подготовьте 20–30 примеров из реальной задачи: короткий и длинный вход, пустое поле, кириллицу, таблицу, отказ в доступе и один случай, который раньше ломался. Персональные данные в тестовой выборке замените без потери структуры. Сохраните исходный вход и ожидаемые признаки результата: обязательные поля, допустимые значения, подтверждение источником, время обработки. Полный текст ответа не всегда нужно сравнивать посимвольно — иногда правильных формулировок несколько.
Разведите технический и смысловой тест
Первый слой проверяет контракт: схема JSON, типы полей, максимальная длина, отсутствие пустых ответов и стабильность вызова. Второй слой смотрит на смысл. Например, после обновления модель по-прежнему возвращает JSON, но путает сумму договора и дату оплаты. Такой случай не поймает один только тест формата. Для каждого примера отметьте, где нужен автоматический критерий, а где ручная проверка эксперта.
Не превращайте вчерашний ответ модели в единственную «истину». Сравнивайте с исходным документом и заранее согласованной разметкой. В разборе Model Integration Contracts показан другой масштаб этой проблемы: тесты библиотеки могут пропускать сбой конкретной модели. Ваш набор решает более узкую задачу — выпуск собственного продукта. Если обновляется не библиотека, а сама модель, начните с отдельной проверки перехода на новую модель.
Примите решение до выкладки
Запустите старую и новую версии на одних входах. Считайте не только долю верных ответов, но и критические ошибки, число ручных исправлений и время до готового результата. Если хотя бы один критический сценарий ухудшился, выпуск остановите, разберите причину и проверьте исправление повторно. При равенстве качества посмотрите на задержку и стоимость, но не объясняйте ухудшение точности экономией токенов без согласия владельца процесса.
Проведите ограниченный запуск на доле запросов с возможностью быстро вернуть прежнюю версию. Сохраните лог идентификатора версии и причины отката. «Тесты зелёные» — не решение само по себе; решение состоит в том, что известные риски измерены и назначен человек, который вправе остановить релиз.
Частые вопросы
Достаточно ли сравнить один промпт? Нет: он не покажет редкие входы и изменения формата. Можно ли использовать прежние ответы как эталон? Только после ручной проверки фактов и допустимых вариантов. Что делать, если новая версия быстрее, но чаще ошибается? Вернуться к порогу качества, согласованному до теста, а не менять критерий задним числом.