Когда маленькие LLM лучше роя: как деление на разделы дало слабой модели ×4

Почему маленькие модели нужны, но не в роях

Тепломеханик, начальник отдела в проектной организации с 14 годами опыта, потратил весну на попытку создать эмерджентный рой из слабых локальных моделей. Эксперимент называлась Мицелий — вдохновение пришло из работ о диссипативных структурах и популяциях моделей, которые сами распределяют роли и договариваются о языке общения. Но рой не взлетел: на 200 задачах из MBPP он решил 29% против 52% у банального best-of-N, где модели просто дают несколько попыток. Однако по дороге он обнаружил, что одна идея из проектного бюро держит колоссальную нагрузку.

Все эксперименты запускались на GTX 1660 SUPER с 6 ГБ памяти. Автор был вынужден брать действительно маленькие модели: qwen2.5-coder-1.5b, qwen3-1.7b, llama-3.2–1b, internvl3-2b, gemma-3-1b и smollm2-1.7b. Из-за ограничений памяти нужно было держать в ней несколько моделей сразу и гонять их тысячами вызовов. Код всех опытов писали ИИ-агенты, автор ставил задачи и придирался к цифрам.

Структура проектного бюро вместо роя

Идея пришла из истории Альберта Кана, американского архитектора, который проектировал заводы для Форда. В 1929–1932 годах его фирма спроектировала для СССР около 500 заводов, включая Сталинградский тракторный. Говорят, советские проектные институты выросли из его московского бюро. Автор каждый день живет в этой оргструктуре.

ГИП (главный инженер проекта) делит объект на разделы: тепломеханику, электрику, строительство, автоматику — каждый ведет свой отдел. Готовый раздел проверяют внутри отдела (ВДП, внутридисциплинарная проверка). Потом разделы сверяют друг с другом на стыках (МДП, междисциплинарная проверка) — у одного насос, у строителей под него фундамент, и они должны совпасть. Спорные места несут главному специалисту. В конце нормоконтроль смотрит оформление, и только после этого альбомы уходят заказчику. Целиком станцию не держит в голове никто — она туда не влезает. Маленькая модель, которой дали 18 записей и попросили найти нужные, находится в том же положении.

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

На 40 тестовых задачах модели искали все транзакции с заданной категорией И регионом в наборе из 18 записей. Подходящих было от 2 до 5, рядом лежали ловушки — записи с нужной категорией, но чужим регионом, и наоборот, по 2–4 штуки. Модель должна была выдать ТОЛЬКО список подходящих ID через запятую, без пояснений, и назвать ровно нужный набор — без лишних и без пропусков.

Использованные модели в GGUF формате: qwen2.5-coder-1.5b–instruct (Q4_0), llama-3.2–1b–instruct (Q4_0), qwen3-1.7b (Q4_0), internvl3-2b (Q4_K_M), gemma-3-1b–it (Q5_K_S), smollm2-1.7b–instruct (Q4_K_M). Ответы на целом списке были взяты с диска из прошлых опытов, чтобы исключить вариативность генерации. Всего 720 вызовов, 614 секунд на GTX 1660 SUPER.

Результаты: деление на разделы

Без нарезки уже было видно плохое распределение по позициям: первую запись модели находили в 61% случаев, последнюю в 21%. Автор сначала решил, что к концу списка модель просто чаще говорит нет, но потом проверил — и был неправ. К концу модель становится скупее незначительно (0,21 против 0,50 в начале), но гораздо хуже различает похожие строки. Нужных находит меньше (0,30 против 0,50), а ложных отметок среди неподходящих становится больше (0,16 против 0,14).

Потом 18 записей разрезали скриптом на 3 блока по 6 подряд — порядок внутри блока сохранялся. Каждая из шести моделей читала каждый блок отдельно. Если модель называла ID, которого в её блоке нет, это выдумка, и код выкидывал такой ответ (поймано всего 5 выдумок за весь прогон). Голос за запись засчитывался только из того блока, где она лежит.

Результаты по точному совпадению (модель назвала ровно нужный набор):

| Модель | Без нарезки | С блоками по 6 | Прирост | |--------|-----------|-----------------|----------| | qwen2.5-coder-1.5b | 17,5% | 70% | +52,5 п.п. | | llama-3.2–1b | 40% | 72,5% | +32,5 п.п. | | internvl3-2b | 57,5% | 82,5% | +25 п.п. | | qwen3-1.7b | 72,5% | 85% | +12,5 п.п. | | gemma-3-1b | 0% | 5% | +5 п.п. | | smollm2-1.7b | 0% | 0% | 0 п.п. |

Чем слабее модель — тем больше прирост. Разрыв между началом и концом списка сократился с 20 п.п. до 2 п.п. На целом списке полнота в конце была 0,30, с нарезкой стала 0,57.

Миф об эмерджентности

Главной целью был поиск эмерджентности — когда собранный ответ верен, а ни одна модель сама не справилась. По исходной неверной формулировке получилось 34 задачи из 40. Автор почти открыл шампанское, а потом посмотрел, что с чем сравнивает. С одной стороны весь конвейер: блоки, проверка, голосование, сборка. С другой одиночная модель, которой выдали все 18 записей разом. Условия разные, такое сравнение ничего не значит.

При честном сравнении (пропустить лучшую модель qwen3-1.7b через тот же конвейер с блоками) она дает 0,850. Все шесть вместе дают 0,900. Оракул «хоть одна из шести справилась» дает 0,975. Строгая эмерджентность вышла ноль: собранный ответ никогда не выходил за пределы того, что уже умела хотя бы одна модель. Рой добавил всего 5 пунктов к лучшей одиночной модели.

Из семи элементов конторы сработал один

Нагрузку держало только деление на разделы. Что дал каждый элемент: ГИП делит объект на разделы (деление 18 записей на 3 блока по 6) — почти всё: разрыв 0.20 → 0.02, точный набор 0.75 → 0.90. Исполнители (6 моделей на каждый блок) — +0.05 сверх лучшей одиночной. ВДП (ID не из своего блока идет в брак) — поймано 5 выдумок. МДП (сверка на стыках блоков) — блоки независимы, сверять нечего. Нормоконтроль (проверка формата) — ошибок не было. Главный специалист (точечный вопрос по одной строке) — не понадобился. Ревизии (повторный круг, пока ответ неуверенный) — не понадобились.

Практический вывод: режьте маленькие модели на куски, когда кормите их пачкой документов или длинным списком. В этом опыте оптимум был 6 записей на блок — первые 6 позиций находились лучше всего. Нарезка по токенам почти бесплатна: три куска по трети дают той же объем плюс три раза шапка промпта. Вызовов втрое больше, зато они короче. Рой из шести моделей поверх этого стоит вшестеро дороже и дает 5 пунктов. Автор такой обмен не одобряет, но инструмент (деление на разделы) работает.