Стэнфордская проверка признала устаревшими 44% выводов об LLM

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

Исследователи Стэнфорда Оуэн Куин и Джеймс Цзоу повторно проверили 50 широко цитируемых выводов о больших языковых моделях на 20 моделях восьми разработчиков. По их оценке, 44% выводов уже перестали воспроизводиться, ещё 34% заметно ослабли. Полностью сохранились лишь 16%, а 6% проявились сильнее. Для 22 результатов, срок жизни которых удалось оценить, среднее значение составило 15,7 месяца.

Это не означает, что исследования бесполезны. Это означает, что фраза «LLM ведут себя так» почти всегда слишком широкая. Корректнее говорить: «эта модель, в этой версии, на эту дату и при таком тесте показала такой результат».

Быстрее всего исчезают понятные технические провалы

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

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

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

Поведенческие риски живут дольше

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

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

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

Что менять в разработке продукта

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

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

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