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

Препринт мая 2025 года от Института языковых технологий Карнеги - Меллона (Shubham Gandhi, Atharva Naik, Yiqing Xie, Carolyn Rosé). Вопрос чисто экономический: если сильная модель решает больше GitHub issues, но стоит гораздо дороже, какие способы разделения работы между сильной и слабой моделью позволяют приблизиться к результатам сильной модели за малую долю её стоимости?

Схема эксперимента

Всё работает внутри Agentless Lite - двухэтапного RAG-пайплайна. voyage-code-3 находит топ-5 релевантных файлов, затем модель генерирует патчи SEARCH/REPLACE, делая до десяти повторных попыток с повышением температуры на 0.1 после каждого некорректного патча. Бенчмарк - SWE-bench Lite: 300 задач из 11 Python-репозиториев, по одному прогону на каждую. В роли сильных моделей выступают o3-mini, o4-mini и GPT-4o-mini; в роли слабых - GPT-4o-mini и Qwen2.5-Coder в размерах 7B, 14B и 32B. Стоимость считается по расходам на API для всех 300 задач, без учёта поиска по коду, так как он одинаков во всех сценариях.

В одиночку o4-mini решает 45.33% за $33.33, o3-mini - 33.67% за $46.22, GPT-4o-mini - 15.33% за $4.53, а Qwen2.5-Coder-32B - 20.33% примерно за $7.02.

Стратегии делятся на четыре группы. Базовые варианты со слабой моделью при равном бюджете (cost-equated weak-only baselines) опрашивают слабую модель до тех пор, пока она не потратит столько же, сколько ушло бы на сильную, а затем выбирают патч голосованием большинства, кластеризацией, выбором самой слабой модели или через оракул best-of-n. Статическое расширение контекста (static context augmentation): сильная модель пишет что-то, что затем использует слабая, - саммари репозитория, FAQ по репозиторию, структуру RepoGraph, few-shot примеры или планы и Q&A под конкретную задачу. Разделение по пайплайну (pipeline division) запускает обе модели в фиксированном порядке: Strong LM First (сильная модель делает попытку, а слабая лишь итерирует, пока патч не станет валидным), Weak LM First (каскад, где слабая модель пробует решить задачу, а сильная получает одну попытку только в том случае, если валидный патч так и не получен) и Prompt Reduction (слабая модель сокращает найденный код перед тем, как сильная начнёт писать). Динамическое взаимодействие (dynamic collaboration) использует роутер - слабый или сильный, - чтобы пометить задачу как простую или сложную и направить её соответствующей модели. В подписи к рисунку насчитывается 14 техник, во введении говорится о 12 методах, а в статистическом приложении после разделения вариантов получается 19 конфигураций.

Результаты

Strong LM First побеждает по качеству. В связке o4-mini и GPT-4o-mini эта стратегия решает 41.67% за $25.34 против 45.33% за $33.33 у одной o4-mini, и примерно на 92% превосходит лучший базовый вариант со слабой моделью при том же бюджете (оракул best-of-n с 21.67%). В связке o3-mini и Qwen2.5-Coder-32B результат составляет 33.00% за $27.74 против 33.67% за $46.22 у одной o3-mini - это и есть заявленная в аннотации "эквивалентная точность при снижении затрат на 40%". В дисперсионном анализе (ANOVA) по методам Strong LM First и одиночная попытка сильной модели статистически значимо опередили все остальные подходы по точности.

Weak LM First - бюджетный вариант, и его качество напрямую зависит от того, насколько слаба слабая модель. В паре с o4-mini модель GPT-4o-mini по схеме Weak LM First решает 15.33% за $6.06 - столько же, сколько GPT-4o-mini в одиночку. В паре с o3-mini показатель Qwen2.5-Coder-7B вырастает с 4.67% до 19.33%, потому что 7B-модель настолько часто не может выдать валидный патч, что вызов передаётся сильной модели. Авторы рекомендуют Weak LM First и слабый роутер при жёстких бюджетных ограничениях, а Strong LM First - при более свободных бюджетах, при этом кривые "цена/качество" пересекаются.

Тратить бюджет сильной модели на большее число сэмплов слабой оказалось худшим вложением денег. Self-consistency примерно по 15 сэмплам GPT-4o-mini показал от 14.33% до 16.33% при стоимости на уровне o4-mini, что не лучше одной попытки слабой модели. Контекст на уровне репозитория (саммари, структура, FAQ) слабой модели не помог, а few-shot примеры часто вредили; при этом планы сильной модели под конкретную задачу сработали: 29.33% у GPT-4o-mini с планом от o4-mini. Слабый роутер часто выигрывал у сильного. В тексте сообщается о преимуществе в шесть процентных пунктов при снижении затрат примерно на 20%, что объясняется тем, что сильная модель излишне усложняет решение о маршрутизации; в таблице для o3-mini и Qwen2.5-Coder-32B слабый роутер набирает 29.00% за $32.77 против 23.00% за $40.76 у сильного роутера (в тексте для этой пары упомянута o4-mini, что не сходится ни с одной таблицей). Prompt Reduction снизил долю валидных патчей примерно до 65%, но иногда повышал долю решённых задач - компромисс с высоким разбросом результатов.

Как статью цитируют

Пост cross-model-code-review, из-за которого статья попала в базу, цитирует её как аргумент в пользу схемы, где слабая модель пишет код, а сильная делает ревью. В статье такая схема не тестируется. Ни одна из исследованных стратегий не включает этап ревью, а в наиболее эффективной роли распределены наоборот: сильная модель пишет код, а слабая лишь приводит в порядок форматирование. Стратегия, где слабая модель делает большую часть работы, - это дешёвый каскад, который даёт слабый прирост качества, если слабая модель достаточно компетентна, чтобы генерировать синтаксически валидные патчи. Что статья действительно подтверждает, так это общий тезис о том, что связка моделей выгоднее, чем трата тех же денег на генерацию большего числа сэмплов дешёвой моделью.

Ограничения

Один простой фреймворк вместо полноценного агента, один прогон на задачу, только Python, только методы на этапе инференса, затраты измеряются в API-токенах без учёта задержек или энергопотребления, и модели середины 2025 года. По мнению авторов, таксономия должна быть переносимой; конкретные цифры привязаны к Agentless Lite и выбранным парам моделей.

Ссылки

• cross-model-code-review - что эта и ещё пять статей говорят о разделении написания и проверки кода между моделями
• small-model-code-judges - более дешёвое разделение, где малая модель-судья выбирает среди вариантов от малого генератора
• scaffold-model-fit - почему результат, замеренный в одном скаффолде, отражает связку модели и скаффолда
• local-ai-is-not-opus - практический взгляд оператора на соотношение цены и качества сильных и слабых моделей