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

Авторы: команда исследователей Robonaissance

Перевод: TechFlow

TechFlow читателям: В условиях всё более напряженной гонки бенчмарков среди ведущих больших языковых моделей результат «Модель А получила на 8 баллов больше, чем Модель B» часто примитивно интерпретируется технологическим сообществом и рынком капитала как показатель разницы в интеллекте. Однако новейшее эмпирическое исследование команды Google Cloud AI Research совместно с Северо-Западным университетом полностью развеивает этот миф: без малейшего изменения внутренних весов модели, лишь путем перестройки внешней рабочей среды (Harness), модель с изначально низким рейтингом может легко опередить флагманские модели при выполнении офисных и профессиональных задач.

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

Один AI-агент получил задачу по программированию и продемонстрировал исключительно добросовестный подход.

Он детально расписал, какой файл кода откроет, какую команду терминала выполнит и какие проверки планирует провести.

Однако главная проблема заключалась в том, что он ограничился лишь «словесными обещаниями». Агент просто вывел список всех вызовов инструментов в виде обычного текста, словно ученик, стоящий в стороне со скрещенными на груди руками и дающий советы по ремонту, на самом деле ни разу не запустив ни строки кода. В итоге за выполнение задачи из возможных 100 баллов он набрал лишь 60.

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

Этот яркий пример взят из передовой научной статьи, совместное издание которой Google Cloud AI Research и исследователи Северо-Западного университета опубликовали 9 октября 2026 года. Тестовые данные в статье основаны на собственных экспериментах авторов и пока не прошли независимое внешнее воспроизведение.

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

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

Сегодня работу по оптимизации этой внешней оболочки вокруг моделей можно полностью автоматизировать с помощью другого ИИ. В реальных задачах масштабы тонкой настройки этой окружающей среды способны полностью перевернуть исходный рейтинг превосходства моделей. Поэтому, сталкиваясь с утверждениями о том, что «Модель А превосходит Модель B», действительно обоснованным вопросом должен быть: в какой именно системной среде она работает? И какая именно поддержка оказывается ей со стороны?

Встречный удар: как слабая модель обходит сильную

Самым впечатляющим выводом исследования является демонстрация драматического перераспределения рейтингов.

В пакетном тесте из 100 офисных задач, включающих написание кода, веб-поиск и обработку документов, каждая оценивалась по 100-балльной шкале с использованием скрытых тестовых случаев, проверок целостности файлов и судейства на базе больших моделей. В стандартной среде «из коробки» китайская открытая модель GLM-5 показала средний результат 64,2 балла; при идентичных условиях Gemini 3.5 Flash от Google набрала в среднем 72,4 балла. Согласно данным самого стандарта оценки, Gemini определенно сильнее, имея преимущество примерно в 8 баллов.

Однако после всего одного раута автоматической тонкой настройки окружающей конфигурации средний балл GLM-5 немедленно вырос до 75,7. Это на 11,5 балла превышает его исходный результат и даже на 3,3 балла превосходит родную версию Gemini «из коробки».

Во втором готовом тестовом наборе «из коробки» та же закономерность подтвердилась: оптимизированная GLM-5 получила 75,3 балла, опередив Gemini с 74,5. Авторы статьи прямо резюмируют: модель с относительно слабым базисом, получив более качественную системную оболочку, вполне способна победить более сильные модели, работающие в своей исходной заводской среде.

Это абсолютная правда, но ее истинный смысл гораздо более строг и осторожен, чем кажется на первый взгляд. Это вовсе не означает, что базовые когнитивные способности GLM-5 превзошли Gemini. Потому что при применении абсолютно аналогичного системного тюнинга к Gemini, ее баллы также поднимутся до 77,5.

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

Разбор системной оболочки: офисные компоненты вне мозга

В сфере ИИ-инжиниринга эта системная среда, окружающая модель, образно называется «обвязкой (Harness)», хотя ее суть куда проще и понятнее, чем звучит этот термин.

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

Системная оболочка ИИ по сути является цифровым двойником этого рабочего пакета. Статья систематически разделяет ее на восемь ключевых компонентов: долгосрочные системные инструкции (Standing Instructions), защитные ограждения (Guardrails), модуль памяти (Memory), пакеты профессиональных навыков (Skills), руководства по вызовам инструментов (Tool Guidance), автоматические скрипты (Scripts), вспомогательные субагенты (Helper Agents), а также легкий плагин, способный динамически перехватывать и корректировать поведение агента. Каждый из них представляет собой отдельный файл, ни один из которых не изменяет базовые веса модели. Они меняют лишь то, что сообщается модели, что она запоминает, и что ей разрешено или напоминает делать.

Эта офисная аналогия полностью совпадает с другой точки зрения: если поместить талантливого специалиста либо в упорядоченный высокоэффективный офис, либо в хаотичную управленческую трясину, вы получите в оценке совершенно разных людей. Никто не стал бы воспринимать такой тест как чистую меру личного навыка сотрудника; однако сегодня отрасль при чтении «Модель А набрала 72 балла» почти без исключения попадает в эту одномерную когнитивную ловушку.

Адаптивное развитие без эталонных ответов: исправление поведения вместо оценки правильности

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

Механизм пошаговой оптимизации выглядит следующим образом: агент сначала целиком выполняет задачу в текущей оболочке, и этот протокол становится опорным образцом (Reference Run). Затем модель-редактор анализирует весь трек выполнения и предлагает две новые схемы оптимизированной оболочки: первая направлена на универсальные слабые места агента, такие как планирование задач, вызовы инструментов и отслеживание контекста; вторая заполняет пробелы знаниями и жесткими бизнес-правилами конкретной предметной области.

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

Официальное описание метода честно говорит о роли его базового запуска: он «раскрывает поведенческие характеристики оболочки, а не абсолютную правильность конечного продукта». Вот честное ядро метода. Он сам не способен априори определить, верно ли решение; он способен уловить только уязвимости самого процесса выполнения, и успешно исправляются именно те видимые поведенческие дефекты.

Рассмотрим типичные провалы, успешно исправленные методом: в сложной профессиональной задаче агент должен был собрать отчет-мемо из таблиц графика, мест проведения, человеко-часов и бюджетов. Первоначальный запуск дал лишь 43,1 балла; логи показали, что агент нигде не перекрестно сверял цифры из разных файлов и никогда не открывал готовый документ обратно для проверки. После автонaстройки оболочка заставила его выписать каждый источник данных, отследить происхождение каждой цифры и в конце выполнить скрипт повторного открытия файла для ревью. Итоговый балл сразу подскочил до 77,8.

В юридической задаче агенту нужно было отредактировать арбитражное постановление. Изначально все правки шли через слой отслеживания изменений Word, из-за чего при чтении чистым текстом оставался только финальный вариант без следов комментариев. Новый пакет навыков заставил его явно прописывать добавления и удаления прямо в теле документа, баллы мгновенно взлетели с 44,4 до 94,5. В третьем случае ассистент-агент, занимавшийся сбором данных, завяз в бесконечном цикле поиска, подойдя к дедлайну с пустыми руками. Плагин защиты, выдавший аварийное предупреждение после заданного количества вызовов инструментов, навсегда решил проблему затягивания сроков.

Очевидно, что ни один из этих дефектов не связан с нехваткой знаний модели. Эти агенты обладают достаточным запасом юридических статей, арифметической логики и кодовых стандартов; им не хватает лишь хороших рабочих привычек: внимательно перепроверять свои результаты, фиксировать выводы на бумаге, убедиться, что правки видны читателю, и вовремя нажимать кнопку запуска. Рабочие привычки ясно видны в треке выполнения, что радикально отличается от абстрактной правильности ответа. Именно поэтому сравнение трек выполнения позволяет найти корень проблемы без эталонного ответа. Также это объясняет, почему в двух из трех базовых тестов более слабая модель дала больший прирост: ей чаще приходилось избавляться от дурных привычек.

Цена встречного удара: мощный редактор и дополнительные вычислительные затраты

Следует отметить, что оптимизированная GLM-5 выиграла эту схватку не в одиночку. Ее базовую оболочку переписала лично Claude Opus 4.8, чьи возможности значительно превышают уровень любого участника противостояния; более того, перед выдачей финального результата каждая задача запускалась многократно: один раз базовый запуск, по одному разу для двух кандидатских вариантов и один раз для итогового объединенного варианта. Для сравнения, конкурентная Gemini работала в одном запуске со своей стандартной заводской оболочкой.

Таким образом, суть этого контрудара заключается в том, что GLM-5 вступает в бой, используя мощного редактора-наставника и многократный дополнительный расход ресурсов, против голого Gemini без посторонней помощи. Затраты энергии и вычислительной мощности сторон несопоставимы, и сами результаты эксперимента никогда не пытались скрыть этот факт.

Однако два сильных эмпирических доказательства отсекают простую интерпретацию успеха как «полностью делегированного производства сильной моделью». Во-первых, ученые провели серию контролируемых экспериментов по самооптимизации оболочки самими моделями, охватив пять моделей разного уровня — от GLM-5 до Claude Opus 5. Результаты показали, что каждая модель при данной механике достигла тотального роста баллов во всех тестах. Это значит, что основа метода не жестко привязана к внешнему старшему учителю, хотя для максимальной эффективности в основных таблицах использовалась лучшая модель в качестве редактора.

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

Столь же важно опасаться, что модификация оболочки не всегда гарантирует положительный эффект. В других опубликованных в индустрии схемах усиления агентов иногда наблюдались падения баллов ниже исходного оригинала, причем в задачах программирования спуск достигал 6,6 баллов; еще один подход показал снижение результатов ниже базовой линии в 7 из 12 комбинаций тестов. Даже собственный редактор этой статьи при слепом прямом переписывании оболочки без верификации через базовые запуски и базы кейсов обрушил баллы по программированию с 73,4 до 63,2. Эта системная структура вокруг больших моделей обладает огромным рычажным эффектом, способным вызвать жестокие скачки итоговых показателей; стабильный рост здесь обеспечен строгой дисциплиной: любая правка проходит обязательную проверку на реальном поведении агента.

Границы эмпирического вывода и уроки: бенчмарки — это никогда не дуэль голых интеллектов

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

Она ни капли не доказывает, что эти улучшения в глубоком философском смысле означают абсолютный интеллектуальный скачок. Оценка заданий во многом зависит от судейства самой большой модели, а в юриспруденции используется количественная балльная система, а не идеальное выполнение всей работы. Авторы сами признают: сравнение паттернов поведения без твердого фактического эталона не дает математической гарантии абсолютной правильности и не гарантирует бесшовной адаптации правок в совершенно новых средах. Кроме того, выборка ограничена (от 25 до 100 заданий на область), где редкий выброс искажает средний балл; наконец, данные не показывают чудес雪球式 самоэволюции, команда не проводила сверхдолгих стресс-тестов потоков и не заявляла о беспредельном росте собственного интеллекта.

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

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

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