Как сильная модель улучшает слабую без переобучения

Когда сильная модель обустраивает слабой рабочее место

Обычно перенос способностей от большой модели к маленькой выглядит так: берут сильную модель, собирают с её помощью данные, потом дообучают слабую. Авторы этой работы предлагают другой ход. Что, если слабую модель вообще не трогать? Не менять веса. Не делать файн-тюнинг. Не запускать длинное обучение. Вместо этого попросить сильную модель построить для слабой хороший пайплайн на этапе инференса.

Идея звучит просто. Но результат получился неожиданно большим: в среднем качество слабой модели на четырёх бенчмарках на понимание чужих намерений и убеждений выросло с 0.49 до 0.91 в лучшем запуске. То есть почти вдвое.

Это важно, если вы работаете с дешёвыми моделями, агентами и сложными пайплайнами. Часто проблема не в том, что модель «слишком глупая». Проблема в том, что ей дали задачу в неудобном виде. Слишком много шагов. Плавающий формат ответа. Смешение подзадач. Хрупкие места, где модель легко путается. Если сильная модель умеет один раз разобрать задачу на части и оформить это в код, правила, маршрутизацию и проверки, слабая модель начинает работать заметно лучше.

Что исследовали

Авторы называют подход «сильный-к-слабому через обвязку». По сути это такой сценарий:

🟠 есть сильная модель-строитель, которая проектирует пайплайн

🟠 есть слабая целевая модель, которую нельзя дообучать

🟠 строитель видит только маленький валидационный набор — 5% данных

🟠 на этих 5% он итеративно улучшает обвязку: промты, маршрутизацию, правила, код, проверки, формат ответа

🟠 потом готовую обвязку тестируют на скрытом полном наборе

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

Ключевой момент здесь в том, что сильная модель не подсказывает ответы на конкретные примеры. Она строит переиспользуемую процедуру. Если процедура потом работает на скрытом тесте, значит переносится не запоминание, а структура решения.

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

Главный результат в цифрах

Самая слабая цель в основном эксперименте — GPT-5.4-mini. Без обвязки она набирала в среднем 0.488. С обвязкой средний результат по всем запускам вырос до 0.763. Лучший запуск добрался до 0.912.

Средняя точность связок «модель-строитель × платформа»: почти все варианты заметно выше базового вызова слабой модели без обвязки.

Коротко по цифрам:

🟣 базовый вызов GPT-5.4-mini без обвязки: 0.488

🟣 средний результат всех обвязок: 0.763

🟣 лучший результат: 0.912

🟣 прирост в лучшем случае: +0.423

🟣 все конфигурации превзошли базовую линию

Иногда дешевле и полезнее не брать модель классом выше, а окружить текущую модель правильным пайплайном. В работе есть и более сильное наблюдение: хорошо собранная обвязка для GPT-5.4-mini местами обгоняет более сильные модели без обвязки.

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

Откуда берётся выигрыш

Интересная часть работы — разбор механики. Авторы довольно честно показывают: дело не в том, что слабую модель просто заставили «больше рассуждать». И не в том, что ей дали больше попыток. Главный выигрыш приходит из трёх вещей.

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

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

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

Разные сильные обвязки исправляют разные ошибки базовой модели: вместе они покрывают почти все типы промахов.

Авторы вручную разобрали техники, которые реально использовали модели-строители. Самые частые:

🟠 контроль формата ответа

🟠 жёсткий режим генерации без случайности

🟠 маршрутизация по бенчмаркам и подтипам задач

🟠 принудительное пошаговое рассуждение там, где оно помогает

🟠 правила для отрицаний, полярности и логических инверсий

🟠 гибридные схемы: сначала правило, потом модель как запасной вариант

Редкие, но часто полезные техники:

🟠 детерминированные решатели

🟠 извлечение структурированного состояния задачи

🟠 верификация отдельным проходом

🟠 голосование между несколькими ответами

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

Как был устроен эксперимент

Эксперимент большой: 72 запуска. Меняли сразу несколько факторов.

🟣 модель-строитель: GPT-5.5, Opus-4.7, Sonnet-4.6, Gemini-3.1-Pro, Gemini-3.5-flash и другие

🟣 платформу, в которой строитель писал код: Cursor, Claude Code, GPT Codex

🟣 целевую модель: GPT-5.4-mini или Gemini-3.5-flash

🟣 число повторов для проверки стабильности

Все строители работали только с маленькой валидацией. В среднем делали около пяти прогонов на ней. И здесь ещё один вывод: больше прогонов по валидации почти не помогает. Качество итоговой обвязки слабо связано с количеством таких итераций. Зато очень сильно связано с качеством самой модели-строителя.

Иными словами, дело не в том, чтобы бесконечно перебирать варианты. Дело в том, чтобы сильная модель выдвинула правильную гипотезу о структуре задачи.

Сильнее строитель — лучше обвязка

Одна из самых чистых частей статьи — сравнение уровней «усилия рассуждения» у одной и той же модели-строителя, Opus-4.7. Ей давали разный бюджет на внутреннее рассуждение при написании обвязки: низкий, средний, высокий и очень высокий.

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

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

Это интересно по двум причинам.

Первая: вычисления на этапе построения обвязка окупаются. То есть полезно не только «думать во время ответа», но и «думать во время проектирования пайплайна».

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

Короткая выжимка:

🟠 больше усилия у строителя → лучше итоговой обвязки

🟠 больше прогонов по валидации → почти не влияет

🟠 платформа влияет меньше, чем качество самой модели-строителя

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

Платформа оказалась не главным фактором

Сегодня много спорят, влияет ли среда, в которой работает агент для программирования: Cursor, Codex, Claude Code и так далее. В этой работе эффект оказался вторичным.

Разница между платформами есть, но она небольшая и нестабильная. Главный фактор — сама модель-строитель. Платформа начинает заметнее помогать только тогда, когда у строителя уже хватает «бюджета рассуждения», чтобы использовать её возможности.

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

Кому обвязки помогают больше всего

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

Авторы сравнили GPT-5.4-mini и Gemini-3.5-flash как цели. Для слабой GPT прирост был огромным. Для Gemini — гораздо меньше. Более того, на задачах, где Gemini уже близка к потолку, дополнительная инженерия иногда ухудшала результат.

Логика тут простая: обвязка в первую очередь возвращает модели те способности, которые у неё уже как будто есть, но она применяет их нестабильно. Если модель и так справляется, лишние правила и маршруты начинают шуметь.

Вывод для практики:

🟣 обвязки особенно полезны для слабых и дешёвых моделей

🟣 для сильных моделей их стоит применять точечно, по подзадачам

🟣 перед этим полезно измерить, где у модели ещё есть запас для улучшения

Где проходит предел

Не всё можно «скомпилировать» в правила и код. Остаточные ошибки хорошо показывают границу метода.

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

Хуже всего — там, где нужно:

🟠 отслеживать глубокую вложенность чужих убеждений

🟠 учитывать обман и смену перспективы

🟠 делать байесовский вывод о целях по неоднозначным действиям

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

Почему это важно

Эта работа сдвигает фокус. Обычно мы спрашиваем: насколько хорошо модель решает задачу сама? Здесь вопрос другой: насколько хорошо сильная модель умеет построить условия, в которых слабая модель решит задачу лучше?

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

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

Вывод

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

Главные выводы работы такие:

🟠 сильная модель может заметно улучшить слабую без дообучения, только за счёт обвязки на этапе инференса

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

🟠 качество строителя важнее числа итераций по валидации и важнее платформы

🟠 слабые модели получают максимальную пользу, сильные — ограниченную и местами отрицательную

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

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