Обновление модели без падения качества ответов

MAATRIX

Вышла новая версия модели, которую вы используете в продакшене, — общий рейтинг выше, бенчмарки лучше, вендор обещает улучшения почти по всем направлениям. Соблазн простой: обновить endpoint или тег, и всё станет только лучше. На практике именно так ловят регресс — новая версия оказывается хуже старой на вашей конкретной задаче, хотя в среднем по больнице она объективно сильнее. Ниже — рабочий процесс, который не даёт полагаться на репутацию модели вместо проверки на своих данных.

Почему «новее» не значит «лучше для вашей задачи»

Общие рейтинги и бенчмарки языковых моделей измеряют усреднённую производительность на широком наборе задач — математика, код, общие знания, следование инструкциям в среднем по больнице. Вендор, улучшая модель по этим осям, оптимизирует под то, что меряет бенчмарк, а не под ваш конкретный сценарий использования.

Отсюда фундаментальная проблема: модель, которая стала лучше в целом, теоретически может стать хуже в каком-то узком аспекте, важном именно для вас. Несколько типичных сценариев, где это реально происходит:

• Изменился стиль ответов. Новая версия стала более многословной, или наоборот — более сухой и менее разговорной. Если у вас чат-бот поддержки с чётко откалиброванным тоном, это регресс, даже если по метрикам полезности модель выросла.
• Изменилось следование формату. Модель стала лучше рассуждать, но чуть менее строго держит JSON-схему или разметку, которую парсит ваш код после генерации.
• Сместился баланс безопасности и полезности. Более осторожная версия чаще отказывается или уходит в оговорки там, где раньше отвечала по существу — это может быть желаемым улучшением в одном домене и порчей в другом.
• Просел конкретный узкий навык. Модель лучше пишет код, но чуть хуже держит контекст на вашем специфическом наборе документов для RAG, потому что тренировочная выборка сдвинулась в другую сторону.

Важно: ни один из этих эффектов не виден в общих рейтингах, и ни один вендор не публикует регресс-отчёт по вашему сценарию — потому что не знает о нём. Единственный источник правды о том, как новая модель поведёт себя именно на ваших запросах, — ваши собственные тесты на ваших собственных данных. Общий принцип выбора модели под задачу (не только при обновлении, но и при первом выборе) разобран в статье про методику выбора модели под задачу: там же объясняется, почему рейтинги — это отправная точка для сужения списка кандидатов, а не финальный критерий.

Практический вывод из этого раздела прост и не меняется от того, о какой модели идёт речь: смена модели в продакшене — это значимое изменение критичной системы, и относиться к нему нужно с той же осторожностью, что и к любому другому такому изменению — миграции базы, смене версии рантайма, замене очереди сообщений. Не как к «обновлению версии», которое безопасно по умолчанию просто потому, что формально считается новее.

Шаг 1: обязательный прогон своей батареи тестов на кандидате

Прежде чем новая модель увидит хотя бы один процент реального трафика, она должна пройти вашу регрессионную батарею тестов — набор реальных характерных для вас запросов с эталонными или хотя бы приемлемыми ответами, по которым можно сравнить старую и новую версию. Если такой батареи ещё нет, как её собрать и организовать разобрано в статье про батарею тестов для своей LLM — коротко: это набор реальных (обезличенных) запросов из продакшн-логов плюс edge-кейсы, которые уже ломали систему раньше.

Процесс на практике выглядит так:

1. Разворачиваете кандидата отдельно, без доступа реального трафика — например, второй Ollama-инстанс на другом порту или отдельный API-ключ у облачного вендора.
2. Прогоняете через него всю батарею тестов, сохраняя ответы рядом с ответами текущей продакшн-версии на те же запросы.
3. Сравниваете попарно — не по абстрактной шкале «хорошо/плохо», а по вашим собственным критериям: держит ли формат, не потерял ли факты, не изменился ли тон, не начал ли чаще отказываться.
4. Отдельно прогоняете edge-кейсы — короткие и очень длинные запросы, погранично корректный JSON на входе, запросы на грани политики безопасности. Именно здесь чаще всего всплывает скрытый регресс.

Минимальный скрипт для пакетного прогона батареи через два эндпоинта одновременно:

import json, requests

QUESTIONS_FILE = "regression_batch.jsonl"  # ваша батарея, одна строка — один запрос
OLD_MODEL_URL = "http://127.0.0.1:11434/api/generate"
NEW_MODEL_URL = "http://127.0.0.1:11435/api/generate"

results = []
with open(QUESTIONS_FILE) as f:
    for line in f:
        item = json.loads(line)
        prompt = item["prompt"]
        old_resp = requests.post(OLD_MODEL_URL, json={"model": "old-tag", "prompt": prompt, "stream": False}).json()
        new_resp = requests.post(NEW_MODEL_URL, json={"model": "new-tag", "prompt": prompt, "stream": False}).json()
        results.append({
            "prompt": prompt,
            "old": old_resp.get("response"),
            "new": new_resp.get("response"),
        })

with open("compare_old_vs_new.jsonl", "w") as out:
    for r in results:
        out.write(json.dumps(r, ensure_ascii=False) + "\n")

Дальше сравнение результатов — либо ручная разметка (для батареи в несколько десятков-сотен вопросов это реально сделать за пару часов), либо LLM-судья по вашим критериям, если батарея на тысячи запросов. Как оценивать качество ответов системно, а не на глазок, разобрано в статье про тестирование качества ответов своей модели.

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

Шаг 2: постепенный переход вместо мгновенного переключения

Даже успешно пройденная батарея тестов не гарантирует, что в реальном трафике не всплывёт что-то, чего не было в тестовом наборе — реальные пользователи формулируют запросы разнообразнее любой заранее собранной батареи. Поэтому после успешного шага 1 модель не переключается на 100% трафика одномоментно — она получает небольшую долю реального трафика, а основная масса остаётся на проверенной старой версии.

Это классическое канареечное развёртывание (canary release), применённое к модели вместо кода. Практическая реализация зависит от того, где стоит модель:

Через переменную окружения и вес маршрутизации — самый простой вариант для собственного прокси перед двумя инстансами модели:

import os, random

CANDIDATE_WEIGHT = float(os.environ.get("CANDIDATE_WEIGHT", "0.05"))  # 5% трафика на кандидата

def pick_backend():
    if random.random() < CANDIDATE_WEIGHT:
        return "http://127.0.0.1:11435"  # новая версия
    return "http://127.0.0.1:11434"      # проверенная старая версия

Дальше CANDIDATE_WEIGHT меняется без деплоя кода — правкой переменной окружения сервиса и его перезапуском (для systemd — systemctl edit myservice.service, добавить Environment=CANDIDATE_WEIGHT=0.25 и systemctl restart myservice), либо чтением из конфиг-файла, который перечитывается по сигналу, если хочется совсем без разрыва соединений.

Через nginx — если запросы к модели проксируются через nginx, split_clients даёт детерминированное распределение по хэшу (полезно, если хочется, чтобы один и тот же пользователь стабильно попадал в одну и ту же группу):

split_clients "${remote_addr}${http_user_agent}" $backend_pool {
    5%      candidate;
    *       stable;
}

upstream stable  { server 127.0.0.1:11434; }
upstream candidate { server 127.0.0.1:11435; }

server {
    location /api/generate {
        proxy_pass http://$backend_pool;
    }
}

Таблица типичных стадий раскатки — ориентир, не жёсткий стандарт: конкретные проценты и длительность зависят от объёма вашего трафика и от того, насколько быстро в нём видны проблемы.

Переход между стадиями — не по календарю, а по данным: если метрики качества (следующий раздел) стабильны и без аномалий, увеличивайте долю; если видите отклонение — не увеличивайте, разбирайтесь или откатывайтесь.

Шаг 3: мониторинг качества на ограниченной доле трафика

Канареечная доля бессмысленна без метрик, которые её оправдывают. Мониторить нужно не только доступность (модель отвечает, не падает по таймауту) — это необходимое, но недостаточное условие. Нужны метрики именно качества ответов: как часто ответ помечается пользователем как неудачный, как часто срабатывает ваш собственный валидатор формата, как часто нужен повторный запрос той же сессией (косвенный признак, что первый ответ не устроил). Подробная схема, какие метрики брать и как их собирать в проде, разобрана в статье про мониторинг качества ответов ИИ.

Практический минимум, который стоит считать раздельно для старой и новой версии на время канареечной фазы:

• Доля успешного парсинга структурированного ответа (если ожидается JSON/разметка) — падение здесь ловится автоматически, без участия человека.
• Доля явных отказов и оговорок («я не могу ответить на этот вопрос») — рост может быть как желаемым, так и регрессом, зависит от домена.
• Доля повторных запросов в одной пользовательской сессии — прокси-метрика неудовлетворённости первым ответом.
• Средняя длина ответа, если для вашего сценария важна лаконичность или наоборот полнота — резкий сдвиг стоит разобрать, даже если формально это «не хуже».
• Ручная выборочная разметка — 20–50 случайных ответов кандидата в день читает живой человек и ставит оценку по вашей шкале. Автоматика не ловит тон и фактическую точность на специфичных для вас темах.

Счётчики нужно вести с тегом версии модели (например, model_version="candidate-2026-08" как label в Prometheus), иначе сравнение по одному общему графику ничего не покажет — разница потеряется в шуме.

Шаг 4: быстрый откат — обязательное условие, а не опция

Процесс постепенного перехода не имеет смысла, если откат назад — это медленная сложная процедура. Откат должен быть таким же быстрым действием, как переключение веса маршрутизации в обратную сторону — минуты, не часы, и без участия нескольких команд или согласований по регламенту.

Условия, которые нужно выполнить заранее, до начала канареечной фазы, а не в момент, когда уже что-то пошло не так:

• Старая версия модели остаётся развёрнутой и доступной на всё время канареечной фазы и ещё некоторое время после полного перехода — не удаляйте и не выгружайте её сразу после того, как трафик перевели на 100% кандидата. Для локальных моделей это значит не стирать старый тег из хранилища (ollama rm old-tag подождёт), для облачного API — не отзывать доступ к предыдущей версии эндпоинта.
• Откат — это одна операция, а не пересборка деплоя. Проще всего — та же переменная веса маршрутизации, что и в шаге 2: CANDIDATE_WEIGHT=0 возвращает 100% трафика на проверенную версию мгновенно, без редеплоя кода.
• Не привязывайтесь к алиасу «последняя версия». Если вызов модели ссылается на алиас вроде latest вместо конкретного идентификатора версии, откат превращается не в «переключить обратно», а в «понять, какая версия была раньше, и найти способ её снова получить» — именно та проблема, ради которой затевается весь процесс. Почему явное закрепление версии важно само по себе, разобрано в статье про антипаттерн «latest» вместо версии.
• Триггеры отката формулируются заранее, а не придумываются под давлением инцидента — например, «доля успешного парсинга JSON у кандидата упала более чем на X п.п. за скользящее окно N часов» или «оценка ручной разметки ниже Y два дня подряд». Конкретные пороги — ваши, но сам факт, что они прописаны заранее, важнее их точных значений.

Практическая схема целиком

Собранный воедино процесс — от появления новой версии модели до полного перехода на неё:

1. Вышла новая версия/кандидат модели
2. Батарея регрессионных тестов офлайн, без реального трафика
   → заметно хуже по критичным критериям? не переходить, разобраться, отложить
3. Канареечный трафик: 3-5%, старая версия — основной маршрут, доступна для отката
4. Мониторинг метрик качества раздельно по версиям, несколько дней
   → аномалия? откат (вес кандидата → 0), разбор причины
5. Постепенное увеличение доли: 5% → 25% → 50% → 100%,
   на каждой стадии — та же проверка метрик перед следующим шагом
6. Полный переход, старая версия остаётся развёрнутой ещё некоторое время
   на случай отложенного эффекта, видимого не сразу

Ключевая мысль этой схемы — на каждом шаге есть путь назад, требующий только изменения одного параметра. Это и отличает контролируемое обновление модели от «просто обновили тег и посмотрим» — там откат тоже возможен, но требует восстанавливать то, что было настроено раньше, обычно уже при недовольных пользователях и без времени разбираться.

Частые вопросы