TL;DR
Исследователи заменяли модель на новую версию из той же линейки, не трогая промпт, и сравнивали оценки с эталоном от людей. Итоговая точность может вырасти, а отдельные верные оценки при этом потеряются: что старая версия оценивала правильно, новая оценивает неправильно. Метод проверки простой: прогнать один и тот же набор примеров через старую и новую модель и посчитать регрессии. Регрессия — это пример, который старая модель оценила верно, а новая нет.
Больно здесь вот что. Вы обновляете модель в автоматизации, цифры «в среднем» те же или лучше, и вы спокойны. А внутри часть правильных оценок тихо сломалась, и на их месте появились новые ошибки. Бывает и хуже: средняя точность падает почти вдвое после перехода на «более продвинутую» версию. Причина в том, что промпт настроен под повадки конкретной модели. Новая версия иначе читает те же инструкции. Она по-другому взвешивает критерии, строже трактует «релевантно» и чаще цепляется за совпадающие слова.
Практический вывод такой: любая смена версии модели — это новый релиз, который нужно проверить на своих примерах. Подмена названия модели в настройках проверкой не считается. Сложный многошаговый промпт-рубрика на мелких обновлениях ломается чаще простого. При крупной смене поколения он, наоборот, смягчает удар.
Схема метода
ШАГ 1: Собрать золотой набор (50–200 примеров с оценкой человека)
ШАГ 2: Зафиксировать промпт, рубрику, температуру 0. Менять ТОЛЬКО модель
ШАГ 3: Прогнать набор через старую и новую версию → две таблицы оценок
ШАГ 4: Сравнить по каждому примеру: старая верно + новая неверно = регрессия
ШАГ 5: Посмотреть на причины регрессий (в ответах модели) → решить: чинить промпт или оставить старую модель
ШАГ 6: То же в обратную сторону, если хотите «удешевить» и откатиться на старую модель
Шаги 3–4 выполняются отдельными запусками. Шаг 5 можно сделать одним запросом к самой LLM (шаблон ниже).
Пример применения
Задача: Вы руководите контентом в онлайн-школе. LLM-судья в автоматизации (n8n или Make, без кода) проверяет ответы чат-бота поддержки по шкале 0–3: «не помог / частично / помог / идеально». Эталон — оценки трёх ваших кураторов на 80 диалогах. Вышла новая версия модели, она дешевле и «умнее», и коллега предлагает просто поменять название модели в настройках. Вы сначала проверяете, что теряется.
Промпт (анализ регрессий, вставляете в чат с таблицей):
Ты аналитик качества LLM-судей. Я заменил модель-судью на новую версию и оставил тот же промпт.
Ниже таблица. Для каждого диалога: эталонная оценка кураторов, оценка старой модели, оценка новой модели и её краткое обоснование.
Задача:
1. Найди регрессии: диалоги, где старая оценка == эталон, а новая != эталон. Посчитай их долю от диалогов, которые старая модель оценила верно.
2. Найди улучшения: старая != эталон, новая == эталон. Посчитай долю.
3. Для каждой регрессии определи причину по обоснованию новой модели. Выбери одну:
а) перевесила один аспект (например, тон ответа важнее решения);
б) слишком строго трактует критерий («помог» ставится только при идеале);
в) зацепилась за ключевые слова вместо смысла;
г) другая причина (опиши).
4. Сгруппируй регрессии по причинам и покажи по 2 примера на группу.
5. Предложи правки в промпт судьи под каждую группу. Не меняй то, что не связано с регрессиями.
Данные:
{таблица_диалогов}
Промпт судьи (для справки):
{промпт_судьи}
Результат: Модель выдаст две доли: регрессии и улучшения. Дальше пойдёт список регрессий, сгруппированный по причинам, с примерами. В конце будут точечные правки в промпт судьи. Вы увидите, что обновление дало не просто «лучше» или «хуже». Часть оценок ушла в другую сторону, и видно, в какую именно.
Почему это работает
Слабость. Промпт не живёт сам по себе. Он «подогнан» под то, как конкретная версия модели читает инструкции. Новая версия обучена иначе: у неё другие привычки, другая строгость, другой вес «аспектов». Поэтому те же слова дают другие оценки. Средняя метрика это прячет: удачи в одних местах компенсируют потери в других.
Сильная сторона. Сравнивать две версии на фиксированном наборе примеров дёшево и однозначно. Не нужно гадать, «лучше ли модель вообще». Достаточно посмотреть, какие конкретные случаи сломались. Саму LLM можно использовать как аналитика причин, она читает обоснования судьи и группирует их.
Как метод использует это. Разбор «по каждому примеру» вместо «в среднем» превращает размытое «вроде стало хуже» в конкретный список ошибок и их причин. Эти причины уже можно чинить правкой промпта.
Рычаги: - Размер золотого набора. Больше примеров дают устойчивые доли. Меньше можно, но тогда не делайте выводов по единичным случаям. - Простой или многошаговый промпт. Многошаговая рубрика (сначала вопросы, потом оценка по каждому) на мелких обновлениях ломалась чаще. На крупных сменах поколения она смягчала провал: у одной пары моделей потери упали с 28% до 11,5%. Если вы часто обновляетесь «по мелочи», выбирайте простое. Если меняете поколение, рубрика даст страховку. - Направление проверки. Проверяйте и в обратную сторону. Откат на старую дешёвую модель теряет много больше, чем переход вперёд: в одном из случаев 21,8% против 6,7%. - Температура 0. Фиксируйте её, чтобы различия давала модель, а не случайность. Повторные прогоны в исследовании давали почти одинаковые результаты.
Шаблон промпта
Это регрессионный тест для вашей LLM-автоматизации. Сам судья — ваш рабочий промпт, который вы не меняете. Ниже шаблон для анализа результатов:
Ты аналитик качества LLM-судей. Я заменил модель {старая_модель} на {новая_модель}, промпт судьи остался прежним.
Данные: {таблица}. Колонки: {id}, {эталон_человека}, {оценка_старой}, {оценка_новой}, {обоснование_новой}.
1. Регрессии: оценка_старой == эталон И оценка_новой != эталон. Посчитай долю от всех верных ответов старой модели.
2. Улучшения: оценка_старой != эталон И оценка_новой == эталон. Посчитай долю.
3. Каждую регрессию отнеси к причине:
— перевес одного аспекта,
— чрезмерная строгость,
— совпадение по ключевым словам вместо смысла,
— другое (опиши).
4. Покажи по 2 примера на причину.
5. Предложи правки в промпт под каждую причину.
6. Дай вывод: можно ли менять модель, нужна ли доработка промпта или лучше остаться на старой.
Подставьте названия моделей и таблицу. Эталон должен быть от людей, а не от другой модели.
🚀 Быстрый старт — вставь в чат:
Вот шаблон регрессионной проверки при смене модели LLM-судьи. Адаптируй под мою задачу: {что_оцениваешь_и_по_какой_шкале}.
Задавай вопросы, чтобы заполнить поля.
[вставить шаблон выше]
LLM спросит про шкалу оценок, формат вашей таблицы и откуда взят эталон. Эти данные нужны, чтобы корректно посчитать регрессии. Она возьмёт структуру шаблона и подгонит под ваш формат.
Ограничения
⚠️ Нужен эталон от людей. Без размеченного вручную набора регрессии не посчитать. Придётся один раз потратить время на оценку нескольких десятков примеров.
⚠️ Одна область. Эксперименты проведены на оценке релевантности (подходит ли фрагмент текста запросу) на двух наборах TREC. Для других задач судейства механика, скорее всего, та же, но числа не переносятся.
⚠️ Маленькие открытые модели. Для Qwen и Llama брали модели размером около 7–9 млрд параметров. Поведение больших моделей может быть иным. Для ранних версий Llama авторы сами указывают, что оценки по рубрике были неполными.
⚠️ Причины регрессий описаны общо. Три механизма (перевес аспекта, строгость, ключевые слова) названы, но универсального рецепта их устранения нет. Правки в промпт придётся подбирать и проверять самому.
⚠️ Нет хода «просто улучшить промпт». Авторы не проверяли, возвращает ли перепроектирование промпта утраченное качество. Они показывают проблему и необходимость перепроверки.
Как исследовали
Идея была простой: заморозить всё, кроме модели. Команда взяла четыре семейства (Gemini, GPT, Qwen, Llama) и последовательные версии внутри каждого. Два фиксированных промпта-судьи: UMBRELA (один запрос с описанием критериев и пошаговой процедурой) и EXAM (сначала генерируются вопросы-рубрика, потом по ним оценивается фрагмент). Задача: поставить оценку 0–3 парам «запрос — фрагмент текста» и сравнить с оценками людей. Чтобы не смешивать эффекты, рубрику EXAM сгенерировали один раз самой старой моделью семейства и использовали для всех.
Сначала смотрели средние метрики: точное совпадение, средняя ошибка, корреляция. Единой картины «новее — лучше» не получилось: у Gemini Flash прирост со временем вышел на плато, у Qwen точность скакала. У GPT mini при переходе с 4o на 5 точное совпадение для простого промпта упало примерно с 56% до 36%, а для рубрики выросло. То есть эффект обновления зависит от промпта.
Затем пошли на уровень отдельных примеров. Когда в среднем рост, всё равно терялись правильные оценки. Например, при смене GPT-4o mini на GPT-5 mini потеряно 28% верных оценок простого промпта. У Qwen 2.5 → 3 было 22,6%. При этом последние мелкие обновления Gemini (3.7 → 3.8) давали всего 2,3%. Это говорит о том, что крупные смены поколений опаснее.
Неожиданности две. Сложная рубрика сильнее ломалась на мелких обновлениях, возможно, потому что один шаг цепочки меняет итог. Зато при больших сдвигах рубрика работала как «леса» и удерживала качество. А откат на старую модель теряет больше, чем переход вперёд. Для практики это значит: дешёвая старая модель вам не бесплатна. Для надёжности авторы трижды повторили прогон на Gemini, и результаты почти не менялись. Значит, дело не в шуме API, а в самих моделях.
Адаптации и экстраполяции
🔧 Техника: зафиксировать «золотой набор» → одна команда на любое обновление.
Храните свои 50–100 размеченных примеров вместе с промптом. При любом обновлении модели в вашей автоматизации сначала запускайте их, а потом уже переключайте боевой поток. Это идея авторов, превращённая в привычку, а не в разовую проверку.
🔧 Экстраполяция на агентов (идея адаптации, в статье не проверялась):
Если вы настраиваете агента через CLAUDE.md или системный промпт, сохраните 10–20 типовых задач с принятым результатом. После смены модели прогоните их и сравните с прошлым результатом. Поведение агента по тем же правилам тоже может сместиться.
В репозитории лежит файл tests/golden_tasks.md с 15 типовыми задачами и ожидаемыми результатами. После смены модели: выполни каждую задачу, сравни с ожидаемым результатом и перечисли расхождения с причинами.
Ресурсы
- Статья: The Impact of Backbone Evolution on LLM-Based Relevance Assessments, Chuting Yu, Guido Zuccon, Teerapong Leelanupab, University of Queensland, Австралия
- Код и результаты: https://github.com/ielab/judge-backbone-evolution
- UMBRELA — Upadhyay et al., открытая реализация подхода Thomas et al.
- EXAM — Farzi & Dietz, рубрика на основе вопросов
- Dietz et al. — LLM-эволюция как угроза воспроизводимости оценок
- Данные: TREC Deep Learning 2019 и 2020, passage ranking