TL;DR
Когда OpenAI или Anthropic выпускают новую версию модели и говорят "стала умнее" — это правда только в среднем. Исследователи взяли три пары версий GPT (5.4→5.5, 5.5→Sol, 5.4→Sol) и прогнали 900 задач по 50 раз каждую на старой и новой модели, чтобы отделить реальные изменения от случайного шума. Оказалось: даже там, где общий балл вырос, часть конкретных задач стала решаться надёжно хуже, чем раньше.
Главная боль: маркетинг говорит "новая модель лучше на 7 процентных пунктов", а на деле до 8% конкретных типов запросов при этом обновлении регрессировали — стали давать более частые ошибки, чем в старой версии. И наоборот: там, где общий балл упал, до 10% задач незаметно улучшились. Средний показатель — это как оценка "класс в среднем сдал экзамен лучше", хотя треть учеников написали хуже, чем в прошлый раз. Отдельно всплыла деталь: на задачах, где важен точный формат ответа (строгий JSON, точное следование инструкции), регресс концентрируется именно в соблюдении формата, а не в качестве самого ответа — то, что выглядит как "модель стала глупее", часто означает "модель стала небрежнее с форматированием".
Метод не про промптинг — это про как проверять модель перед переходом на новую версию, если у тебя есть повторяющаяся задача (бот, автоматизация, регулярный сценарий использования). Суть: не верить общему баллу, а прогнать свои собственные типичные запросы на старой и новой модели и сравнить результат построчно, а не в среднем.
Схема исследования
ШАГ 1: Взять 900 задач из 3 категорий (знания, математика, следование инструкциям)
ШАГ 2: Прогнать каждую задачу 50 раз на старой и 50 раз на новой версии модели
ШАГ 3: Для каждой задачи посчитать: стала решаться надёжно лучше / хуже / без изменений / неясно
ШАГ 4: Проверить результат против случайного шума (пермутационный тест)
ШАГ 5: Сравнить общий балл (в среднем) с картиной по отдельным задачам
Пример применения
Задача: У тебя есть бот в Telegram на базе GPT, который классифицирует входящие заявки клиентов по категориям и выдаёт ответ в строгом формате — например, JSON с полями "категория", "приоритет", "рекомендация менеджеру". OpenAI выпускает новую версию модели и обещает "прирост качества". Ты хочешь понять — можно ли просто заменить модель в коде бота, или что-то отвалится.
Промпт (для проектирования проверки, не для самой задачи):
Я использую LLM для {описание твоей повторяющейся задачи, например:
классификация обращений клиентов в JSON-формате}.
Сервис предлагает переход на новую версию модели.
Помоги мне составить план проверки перед переходом:
1. Собери 15-20 моих типичных примеров запросов (я их вставлю).
2. Предложи, как прогнать каждый пример несколько раз на старой
и новой версии модели, чтобы увидеть не только "стало лучше/хуже
в среднем", но и какие конкретные примеры сломались.
3. Обрати особое внимание на случаи, где важен точный формат ответа
(JSON, нумерация, структура) — там риск регресса выше даже если
смысл ответа не изменился.
Результат: LLM предложит структуру мини-теста — список твоих характерных запросов, критерии сравнения (не только "правильно/неправильно", но и "соблюдён ли формат"), и подскажет на что смотреть при расхождении старой и новой версии. Ты получишь чек-лист, а не готовое число — но сможешь заметить проблему до того, как она всплывёт у реальных клиентов.
Почему это работает
LLM — вероятностная система: один и тот же запрос может дать разный ответ в разных попытках. Поэтому единичная проверка ("спросил один раз — сработало") ничего не говорит о надёжности. Нужно несколько попыток, чтобы отличить реальное изменение от случайного разброса.
Модель тестируют и обновляют по агрегированным метрикам — общему проценту правильных ответов по огромному набору задач. Это удобно для отчётов, но скрывает то, что происходит с конкретными типами запросов. Улучшение в среднем — это баланс: что-то стало лучше, что-то хуже, а наружу вылезает только итоговая разница.
Метод авторов — не что-то новое технически, а дисциплина проверки: смотреть не на средний балл, а на изменение по каждому отдельному случаю использования. Для обычного пользователя это переносится просто: если у тебя есть регулярный сценарий с LLM (не разовый вопрос, а бот, шаблон, автоматизация) — при смене версии модели протестируй именно свои типичные примеры, а не доверяй общим заявлениям "стало лучше".
Рычаг, который стоит запомнить: если твоя задача требует точного формата вывода (JSON, строгая структура, парсинг кода) — риск регреста при обновлении модели выше, чем для задач "просто ответь по смыслу". Формат ломается чаще, чем смысл.
Ограничения
⚠️ Не готовая техника промптинга: это исследовательский вывод про поведение LLM API, а не метод для написания промптов. Применить можно только принцип — тестировать свои кейсы вручную.
⚠️ Требует повторяющегося сценария: если ты используешь LLM для разовых вопросов в чате, эта находка почти не касается тебя. Она важна для тех, у кого есть бот, автоматизация или регулярный шаблон использования, зависящий от стабильности поведения модели.
⚠️ Точная проверка требует много повторов: авторы прогоняли каждую задачу 50 раз, чтобы отличить реальные изменения от шума. В чате вручную такую строгость не повторить — можно сделать только облегчённую версию (прогнать 10-20 своих примеров пару раз каждый).
Как исследовали
Исследователи взяли три версии GPT из одной линейки (5.4, 5.5, 5.6 Sol) и сравнили их попарно — как если бы компания проверяла, можно ли безопасно перевести клиентов со старой версии на новую. Для этого они собрали 900 задач из трёх открытых бенчмарков — знания, олимпиадная математика, следование инструкциям — и каждую задачу прогнали по 50 раз на каждой модели, чтобы отличить настоящее изменение поведения от случайного разброса ответов.
Результат проверили строгим статистическим тестом с контролем ложных срабатываний и добавили "нулевую линию" — перемешали данные случайным образом и посмотрели, сколько "изменений" вылезет из чистого шума. Оказалось — почти ничего: 95-й процентиль случайного шума был на нуле, значит все найденные изменения — реальные, не артефакт случайности.
Самое любопытное: во всех девяти парах "модель-бенчмарк" одновременно нашлись задачи, которые стали решаться лучше, И задачи, которые стали решаться хуже — даже когда общий балл вырос. А на бенчмарке про следование инструкциям авторы заметили, что при переходе на последнюю версию (Sol) разрыв между "строгой" и "мягкой" проверкой формата вырос почти в 4 раза — то есть регресс во многом объясняется не ухудшением сути ответов, а небрежностью с форматом.
Ресурсы
What Aggregate Scores Miss: Measuring Item-Level Regressions in Commercial LLM API Migrations Xiaonan Xu (Georgia Institute of Technology), Wenjing Wu (University of Colorado Boulder) Полный архив ответов и данные: github.com/WenJing95/gpt-regression-data