🔗Мультимодельная разработка

Написать этот пост подтолкнула одна статья, вышедшая на днях (в рефах ниже она стоит первой). Дело в том, что после выхода превью DeepSeek-V4-Flash я практикую подход, при котором задачи по написанию кода уходят этой модели, а код-ревью и правками занимается GLM-5.3.

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

1️⃣ Стоимость

При feature-based кодинге (а я использую в основном его) потребление токенов на непосредственно разработку кода в разы больше, чем на ревью изменений в нём. DeepSeek-V4-Flash же является очень дешёвой моделью, даже после недавнего подорожания тарифов, а с выходом V4.1 у него (по ощущениям первого дня плотной работы с этой моделью) прям сильно поднялось качество работы с агентскими сценариями и генерируемого им кода. Ну и его vision-версия развернута у меня локально, под задачи на-всю-ночь. Кроме того, при 2-3 одновременно разрабатываемых проектах, лимитов максимальной подписки GLM для задач кодинга лично мне явно не хватит.

2️⃣ Почему бы не ревьюить той же моделью?

Этой теме посвящена последняя статья в рефах. Если вкратце, то слишком высока вероятность, что модель (или даже семейство моделей), допустившая ошибку, пропустит её на ревью. Причем, именно по тем же причинам, по которым она её допустила.

В целом это бьётся и с моими наблюдениями, т.к. периодически я устраиваю (и не только этой парочке) ревью против саморевью с последующим сравнением результатов. И саморевью почти всегда дает менее качественный результат. Это можно чуть нивелировать, если пускать его в режиме goal'а типа «повторное ревью не должно выявить новых проблем уровней must и should fix», но блин... токенов там потратится значительно больше, чем при ревью другой моделью.

3️⃣ Почему слабая модель кодит, а сильная — ревьюит, а не наоборот?

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

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

И вот упомянутые две модели, на моих задачах, показывают себя на отлично, позволяя при этом оставаться в бюджете до $200 ежемесячно, если вынести за скобки наличие локального дипсика. Если не выносить, то $144 — это стоимость подписки Max v2 в GLM. Можно конечно сюда стоимость железа и электричества ещё присовокупить, но это оставлю для тех, кто разворачивает инференс у себя дома для дела, а не по фану, который бесценен)

🙌

🗂Рефы

• «Reviewer Capability Governs Rejection Targeting, Not Repair Skill», arXiv:2609.04270 (2026).

• «An Empirical Study on Strong-Weak Model Collaboration for Repo-level Code Generation», arXiv:2505.20182 (CMU, 2025).

• «Improving Code Generation via Small Language Model-as-a-judge», arXiv:2602.11911 (2026).

• «Variation in Verification: Understanding Verification Dynamics in Large Language Models», arXiv:2509.17995 (2025).

• SWR-Bench, arXiv:2509.01494 (2025).

• «On the Self-Verification Limitations of Large Language Models», arXiv:2402.08115 (2024).

#LLM #ИИ_инструменты