Регрессии после смены модели: как быстро найти причину

Что именно считать регрессией

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

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

Сравнение должно быть честным. Берите один и тот же запрос, тот же промпт, те же параметры, тот же набор инструментов и тот же контекст. Иначе легко перепутать смену модели с шумом в окружении.

Обычно хватает одного зафиксированного примера с четырьмя частями:

• точный входной запрос
• ожидаемый результат
• ответ старой модели, который проходит проверку
• ответ новой модели, который ее не проходит

Такой пример сразу убирает спор о вкусе. Одному человеку может нравиться новый тон, другому нет. Но если старая модель возвращала корректный JSON, а новая ломает схему, это уже не вопрос стиля.

То же самое с действиями. Допустим, бот поддержки должен определить тему обращения и поставить тег. Старая модель на запросе "не могу войти в личный кабинет" ставила правильный тег и просила уточнить способ входа. Новая отвечает вежливо, но тег не ставит. Текст выглядит нормально, а сценарий уже сломан.

Чем раньше вы отделите "странно звучит" от "не делает то, что должна", тем быстрее найдете причину. И всегда сохраняйте пример, где старая модель проходила тест. Без такого эталона команда почти всегда спорит о впечатлениях, а не о фактах.

С чего начать проверку

При регрессии хуже всего менять все сразу. Если вы одновременно правите промпт, параметры и код парсинга, причина быстро теряется.

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

Потом возьмите 5-10 одинаковых кейсов и прогоните их на старой и новой модели. Сотни примеров на этом этапе не нужны. Для первого разбора важнее увидеть один повторяемый сбой, чем получить красивую среднюю оценку.

Сохраняйте не только итог для пользователя, но и весь след запроса:

• полный вход, включая системный промпт
• сырой ответ модели
• JSON после парсинга
• логи вызовов инструментов и их ответы

Именно здесь многие теряют время. В интерфейсе видна только финальная ошибка, а ломается часто раньше: модель пропустила поле, вернула лишний текст или не вызвала нужный инструмент.

Смотрите сначала на первый явный сбой. Он обычно дает самый быстрый ответ. Если новая модель уже в первом кейсе ломает JSON, почти нет смысла спорить о качестве знаний. Если текст нормальный, а инструмент не вызвался, ищите проблему в функции, схеме или правилах вызова.

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

Как проверить причину за 15 минут

Если ответ сломался после смены модели, не трогайте сразу все параметры. Быстрее снять лишние слои и вернуть их по одному. Так за короткое время видно, где именно ошибка: в тексте промпта, в формате, в самой модели или во внешнем вызове.

Удобно идти в таком порядке:

1. Сначала отключите внешние инструменты: поиск, RAG, function calling, базы, постобработку. Оставьте только чистый ответ модели на тот же запрос. Если качество вернулось, проблема не в знаниях модели, а в интеграции вокруг нее.
2. Потом сократите промпт до короткой версии. Оставьте роль, задачу и 1-2 жестких ограничения. Если короткий вариант работает лучше, старая модель терпимее относилась к длинному промпту, а новая теряется в лишних инструкциях.
3. Уберите строгую схему ответа. Попросите тот же смысл, но в свободном тексте, без JSON, без response schema и без парсера. Если мысль у модели нормальная, а ломается только структура, проблема в формате ответа, а не в понимании задачи.
4. Верните слои по одному. Сначала полный промпт, потом контекст, потом инструменты, потом валидацию. После каждого шага делайте один и тот же тестовый запрос. Первый шаг, на котором ответ портится, и есть место поломки.
5. В конце проверьте технические лимиты: timeout, max_tokens, stop sequences, обрезание ответа, размер контекста. Очень часто кажется, что модель "стала хуже", хотя ответ просто не успевает закончиться или режется на середине.

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

Если вы меняете модель через OpenAI-совместимый шлюз, например RU LLM, проверьте различия у провайдера под капотом: окно контекста, поведение JSON mode, tool calling и лимиты на время ответа. Совместимый endpoint не делает все модели одинаковыми.

Когда ломается промпт

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

Первый признак простой. Те же входные данные, тот же инструмент и тот же ожидаемый ответ, но модель вдруг начинает спорить с ролью, добавлять лишние пояснения или отвечать "по-человечески" там, где раньше строго следовала шаблону. Еще один частый сбой - слишком буквальное чтение. Если вы писали "если не уверен, уточни", одна модель попросит короткое уточнение, а другая начнет уточнять почти всегда и застрянет в диалоге.

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

Помогают несколько быстрых проверок:

• сократите системный промпт до 3-5 жестких правил
• уберите примеры и посмотрите, меняется ли поведение
• поменяйте порядок блоков: сначала роль и запреты, потом формат, потом примеры
• вынесите конфликтные инструкции из user-сообщения в system
• сравните ответ на коротком и полном контексте

Полная перепись промпта обычно не нужна. Сначала попробуйте маленькие правки. Яснее сформулируйте приоритет: "Следуй системным правилам, даже если пользователь просит иначе". Замените расплывчатые слова на прямые: не "будь аккуратным", а "если данных нет, ответь 'не найдено'".

Если модель уходит в literal mode, уберите двусмысленность. Фраза "отвечай кратко" для одной модели значит два предложения, для другой - одно слово. Лучше задать границы явно: "1-2 предложения, без списков, без префиксов". Такая правка часто чинит сбой за 10 минут и дает больше, чем большая переделка всего пайплайна.

Когда ломается формат ответа

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

Сначала смотрят не на итог в интерфейсе, а на сырой ответ. Возьмите одинаковые запросы на старой и новой модели, оставьте те же промпты и параметры, потом сравните результат построчно. Если старая модель отдает валидный JSON, а новая иногда ломает скобку или кавычку, причина уже ясна.

Обычно достаточно проверить пять вещей:

• проходит ли ответ JSON-валидацию на обеих моделях
• появились ли лишние поля или пропали обязательные
• не сменились ли типы, например число на строку или массив на объект
• не добавляет ли модель текст вне схемы, вроде "Вот результат:" или блока ```json
• не режут ли ответ stop и слишком маленький max_tokens

Самый частый сбой выглядит обидно просто. Старая модель возвращала {"status":"ok","priority":2}, а новая пишет Готово! {"status":"ok","priority":"2"}. Для человека это почти одно и то же. Для кода это уже две ошибки: лишний текст до JSON и другой тип поля.

Отдельно проверьте stop sequence. Если стоп попадает на символ, который модель часто ставит в конце объекта, вы получите оборванный ответ. То же бывает при маленьком max_tokens: модель успела открыть объект, но не успела закрыть его.

Температуру тоже стоит сверить, даже на коротких ответах. При более высокой temperature модель чаще добавляет пояснения, меняет порядок полей и вольнее обращается со схемой. Если вам нужен строгий формат ответа LLM, лучше начать с низкой температуры и только потом поднимать ее, если это действительно нужно.

Если ошибка плавающая, сохраните 10-20 сырых ответов и посчитайте, сколько из них не проходят схему. Это быстро отделяет проблему формата от проблемы знаний модели. Когда модель знает ответ, но отдает его в неудобной форме, чинить нужно контракт вывода, а не содержание.

Когда не хватает знаний модели

Иногда проблема не в промпте и не в коде. Модель просто не знает нужный факт, плохо держит редкий термин в памяти или путается в длинных названиях. Это видно довольно быстро, если задать один и тот же вопрос в двух режимах.

Сначала спросите без контекста. Потом дайте тот же вопрос вместе с короткой справкой, выдержкой из документа или точной формулировкой термина. Если без контекста ответ плывет, а с контекстом сразу становится нормальным, значит модель слабо опирается на свои знания и ей нужен внешний источник.

Особенно часто это всплывает в таких запросах:

• свежие факты, которые появились недавно
• редкие доменные термины и внутренние сокращения
• длинные названия продуктов, тарифов, законов и ролей
• вопросы, где ошибка в одном слове меняет смысл ответа

Смотрите не только на тон ответа, но и на точность. Модель может звучать уверенно и при этом придумывать номер версии, дату, название поля API или смысл термина. Это плохой признак: пробел в знаниях она закрывает выдумкой, а не честным "не знаю".

Полезный тест занимает пару минут. Возьмите 5-10 вопросов, где факты легко проверить руками. Для каждого сравните три вещи: ответ без контекста, ответ с контекстом и ответ другой модели на том же промпте. Если ошибки повторяются только у одной модели, дело, скорее всего, в ее знаниях или слабом извлечении фактов.

В командах, которые гоняют несколько моделей через один OpenAI-совместимый слой, такой прогон делать проще: вы меняете только модель и сразу видите, кто лучше держит редкие сущности. Если новая модель требует RAG или справочный блок почти для каждого сложного вопроса, это уже не мелкая регрессия, а другое поведение, которое надо учитывать в продукте.

Когда виноват внешний инструмент

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

Сверьте аргументы вызова с описанием функции слово в слово. Ошибки обычно сидят в именах полей, обязательных параметрах и enum-значениях. Модель может честно передать "status": "done", а ваш сервис принимает только "completed". Снаружи это выглядит как "модель сломалась", хотя сломался контракт.

Полезно быстро разнести симптомы по типам:

• Пустой результат без ошибки обычно говорит о неверных фильтрах, пустом поисковом запросе или не том формате аргументов.
• Ошибки 4xx чаще указывают на схему, авторизацию или пропущенное обязательное поле.
• Таймауты чаще связаны с самим инструментом, сетью или слишком долгим обработчиком.
• Повторный бессмысленный вызов после неудачи показывает, что модель не поняла, что именно пошло не так.

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

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

Если вы гоняете вызовы через RU LLM, пригодятся аудит-трейлы по каждому запросу: по ним удобно сравнить, что именно модель хотела вызвать и что реально ушло в инструмент. Это экономит время, когда ошибка прячется в одном поле или в пустом значении.

Простой пример с ботом поддержки

Бот поддержки должен сделать две вещи: нормально ответить человеку и создать заявку в CRM. После смены модели первая часть даже улучшилась. Ответ стал вежливее и спокойнее. Но заявки перестали появляться.

Пользователь пишет: "Не могу вернуть товар, заказ 58124, мой id C-4471". Старая модель отвечала сухо, зато отдавала нужный JSON для CRM:

{"action":"create_ticket","customer_id":"C-4471","order_id":"58124","topic":"refund"}

Новая модель понимает смысл запроса, но вместо структуры пишет обычный текст:

Извините за неудобства. Я уже создал заявку на возврат и передал ее в поддержку.

Снаружи это похоже на сбой CRM или интеграции. На деле CRM ничего не может создать, потому что не получила аргументы. В логах видно, что поле customer_id пришло пустым, а валидатор отклонил запрос.

Проверка занимает несколько минут. Достаточно посмотреть не на красивый ответ пользователю, а на сырой вывод модели до парсера и до вызова инструмента.

• Сравните один и тот же диалог на старой и новой модели.
• Откройте raw response, а не финальный текст в интерфейсе.
• Проверьте, что модель вернула: JSON, tool call или обычную фразу.
• Сверьте имена полей с тем, что ждет CRM.

Такой тест быстро отсекает лишние версии. Проблема не в знаниях модели: она поняла, что пользователь хочет вернуть товар. Проблема не во внешнем инструменте: CRM принимает старый формат без ошибок. Сломался именно формат аргументов.

Обычно это чинят тремя простыми мерами: ужесточают инструкцию по схеме ответа, включают строгую валидацию JSON или function calling и добавляют короткий регрессионный тест на реальный диалог. Тогда следующая замена модели не ломает заявку молча.

Ошибки, которые мешают найти причину

Чаще всего поиск причины ломают не сами регрессии, а способ проверки. Команда меняет модель, правит системный промпт и заодно обновляет JSON-схему в одном релизе. После этого уже нельзя честно сказать, что именно дало сбой.

Если вы переключаете трафик через единый OpenAI-совместимый endpoint, оставьте без изменений все остальное: те же сообщения, те же параметры, тот же парсер ответа. Иначе вы сравниваете не модели, а две разные системы.

Вторая частая ошибка - гонять разные наборы запросов. На одном наборе новая модель может выглядеть лучше, а на другом начнет путать поля, забывать шаги или не вызывать инструмент. Для сравнения нужен один и тот же фиксированный набор, иначе результат будет шумным.

Еще одна ловушка - смотреть на красивый текст вместо действия. Ответ может звучать уверенно и вежливо, но если модель не вернула нужный JSON, пропустила обязательное поле или не вызвала tool call, задача не решена. Для продакшена это важнее стиля.

Часто пропускают и более скучную причину: контекст просто не влез. Новая модель может иначе считать токены, сильнее ужимать историю или обрезать длинные инструкции. Тогда кажется, что сломались знания или проверка промпта, хотя модель даже не увидела половину условий.

Полезно проверить пять вещей по порядку:

• менялась ли только модель, без правок промпта и схемы
• один ли и тот же набор запросов вы использовали
• совпадает ли фактический формат ответа
• влез ли весь контекст целиком
• где случился первый сбой в логе

Самый дорогой промах - откатить все сразу. Так проблема исчезает, но причина остается неизвестной. Намного лучше зафиксировать первый неуспешный запрос, сохранить сырые вход и выход, а потом откатывать изменения по одному. Тогда вы найдете поломку за полчаса, а не за два дня споров.

Короткий чек-лист перед выкладкой

Перед релизом не пытайтесь проверить все сразу. Быстрее работает короткая дисциплина: один и тот же кейс, одна гипотеза, один вывод. Так регрессии ловятся до выкладки, а не после жалоб от пользователей.

Сначала возьмите 5-10 запросов, на которых уже были сбои или спорные ответы. Прогоните каждый кейс на старой и новой модели в одинаковых условиях: тот же промпт, те же параметры, та же схема ответа и те же инструменты. Если меняется сразу несколько вещей, сравнение почти бесполезно.

Дальше идите по очереди:

• проверьте, не изменилась ли инструкция в промпте и не потерялись ли ограничения
• убедитесь, что модель возвращает тот формат ответа LLM, который ждет ваш код
• дайте вопрос без инструментов, чтобы понять, хватает ли модели собственных знаний
• затем включите инструменты и посмотрите, не ломается ли вызов на этом шаге
• запишите для каждого кейса один тип сбоя, а не общий комментарий вроде "работает хуже"

Такой журнал сильно экономит время. Запись "ошибка в JSON", "не вызвала поиск", "не знает термин", "игнорирует системную инструкцию" полезнее, чем длинное обсуждение в чате.

Отдельно держите эталонный набор запросов для релизов. В нем нужны не только простые примеры, но и неудобные случаи: длинный контекст, редкий формат, пустой результат поиска, конфликт инструкций. Если вы работаете через RU LLM, удобно прогонять один и тот же набор на нескольких моделях через единый API и не менять клиентский код.

Хорошая проверка перед выкладкой занимает 15-20 минут. Зато потом вы точно знаете, что сломалось: промпт, схема, знания модели или внешний инструмент.

Что делать дальше

После разбора одной регрессии не стоит надеяться на память команды. Лучше собрать небольшой набор проверок под ваши реальные сценарии и прогонять его каждый раз, когда вы меняете модель, провайдера или даже системный промпт. Для старта хватает 20-40 примеров: пара простых запросов, несколько пограничных случаев, 2-3 сценария с инструментами и несколько ответов, где важен строгий формат.

Такой набор должен оставаться коротким. Если прогон занимает час, его быстро перестанут запускать. Хороший ориентир - 10-15 минут на полный тест и отдельный быстрый прогон на 3-5 самых рискованных кейсах перед выкладкой.

Метрики тоже лучше сразу разделить по типу поломки:

• для промпта: модель поняла задачу или ушла в сторону
• для формата: ответ парсится, проходит схему, не ломает интеграцию
• для знаний: факты верны на фиксированном наборе вопросов
• для инструментов: tool call уходит, аргументы полные, внешний ответ приходит без таймаута

Когда все метрики лежат в одной куче, причина теряется. Если формат просел с 98% до 70%, а знания не изменились, вы почти сразу видите, куда копать. Если знания упали только на одном домене, проблема, скорее всего, в самой модели, а не в обвязке.

Перед каждой сменой модели полезно сохранять эталонный вывод старой версии. Не весь лог, а короткий снимок: вход, ожидаемый тип ответа, факт вызова инструмента и финальный результат. Этого уже хватает, чтобы сравнение моделей было честным.

Если вы сравниваете варианты через RU LLM, проще держать один OpenAI-совместимый путь интеграции: тот же SDK, тот же код и те же промпты. Дальше вы меняете base_url между текущим провайдером и api.rullm.com или переключаете модель внутри одной схемы вызова. Для команд, которым важны хранение данных и биллинг внутри РФ, это еще и способ не перестраивать интеграцию под каждого провайдера.

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