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

[кат]

Откуда вообще эти замеры

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

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

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

Код всех опытов писали ИИ-агенты, я ставил задачи и придирался к цифрам. Параллельно ковыряю форк llama.cpp, чтобы большие модели шли на той же карте на 6 ГБ, про это была прошлая статья. Под ней спрашивали, есть ли от маленьких моделей толк, кроме токенов в секунду. Эта статья как раз про качество, про то, что уцелело от роя.

Контора Кана

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

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

Целиком станцию не держит в голове никто, она туда не влезает. Маленькая модель, которой дали восемнадцать записей и попросили найти нужные, по-моему, в том же положении, что инженер, которому выдали всю станцию разом. Вот и захотелось сделать с моделями то, что ГИП делает с нами.

Профдеформация, да.

Задача

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

База транзакций:
TXN-0003 | account: Fernwood Industries | category: software-licensing | amount: 295.60 | region: LATAM | date: 2026-12-14
TXN-0014 | account: Granite Ridge LLC | category: office-supplies | amount: 243.44 | region: APAC | date: 2026-01-09
TXN-0017 | account: Ironpeak Supply | category: consulting | amount: 219.51 | region: EU-West | date: 2026-12-04
TXN-0001 | account: Cinderpath Co | category: software-licensing | amount: 320.54 | region: LATAM | date: 2026-10-16
TXN-0005 | account: Cobalt & Finch | category: software-licensing | amount: 44.56 | region: EU-West | date: 2026-10-25
...

Найди ID всех транзакций, у которых category = "software-licensing" И region = "LATAM".
Выведи ТОЛЬКО список подходящих ID через запятую, без пояснений. Если подходящих нет, выведи слово НЕТ.

Потом по найденным строкам надо посчитать сумму, количество или максимум и сравнить с порогом, ответ ДА или НЕТ. Арифметику я моделям не доверял, ее делал код. От модели требовалось одно: найти строки. Задача засчитывалась, только если модель назвала ровно нужный набор, без лишних и без пропусков.

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

Чем дальше, тем хуже

Первое, что я сделал, не запуская ничего нового: пересчитал по позициям старые ответы моделей. На 120 задачах, все шесть моделей вместе, первую запись в списке находили в 61% случаев, последнюю, восемнадцатую, в 21%. Кривая ползет вниз почти ровно, с первой строки до последней. Знаменитого провала посередине, как в статье Lost in the Middle (Liu и др., 2023), у меня не вышло.

Сначала я решил, что к концу списка модель просто чаще говорит «нет». Так и написал в отчете, а потом и в посте на Реддите. Один читатель предложил проверить это на тех же данных, и правильно сделал. Модель к концу не становится скупее: и в первой трети списка, и в последней она отмечает примерно пятую часть записей (0,21 и 0,19). Только в конце она чаще отмечает не те. Нужных находит меньше, 0,30 против 0,50, а ложных отметок среди неподходящих становится больше, 0,16 против 0,14. Хуже различает похожие строки, если по-простому. Поправка теперь в отчете, старый вывод я оставил рядом, чтобы было видно, где ошибся.

Разрезал на разделы

Дальше все по Кану. Восемнадцать записей режутся на три блока по шесть подряд, порядок внутри блока сохраняется. Режет скрипт, модель к этому я не подпускаю. В другом опыте я дал маленькой модели самой придумать разбивку задачи на шаги. Четверть планов даже не разобралась как JSON, до правильного ответа из ста задач дошла одна. ГИП из нее никакой.

Каждая модель читает каждый блок отдельно. Потом работает ВДП: если модель называет ID, которого в ее блоке нет, это выдумка, и код такой ответ выкидывает. За прогон выдумок набралось пять. Голос за запись засчитывается только из того блока, где она лежит. Пороги, по которым считать опыт удачным, я записал в протокол до прогона, чтобы потом не было соблазна их подвинуть. Всего 720 вызовов, десять минут на той же GTX 1660 SUPER.

Разрыв между началом и концом списка почти исчез:

На этих 40 задачах кривая для целого списка падает не так круто, как на 120, но падает. После нарезки позиция записи почти перестала влиять на то, найдут ли ее.

А дальше то, чего я не ждал. Вот доля задач, где модель назвала ровно нужный набор:

Чем слабее модель, тем больше прирост. Кодер вырос вчетверо и с нарезкой почти догнал лидера без нее: 0,700 против 0,725 у qwen3-1.7b на целом списке. Собственно, ради этого Кан и делил работу: при правильном делении середнячки подтягиваются, и их труд начинает складываться. gemma и smollm задачу не тянут совсем, им нарезка не помогла.

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

Где я чуть не открыл шампанское

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

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

Число 34 так и лежит в файле результатов вместе с ошибочным вердиктом. Удалять не стал, пусть дефект формулировки будет виден.

Что из схемы держало нагрузку

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

Что с этим делать

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

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

Чего я не мерил

Модели только 1-2B, у меня 6 ГБ видеопамяти. На больших моделях я это не проверял. По таблице видно, что чем сильнее модель, тем меньше прирост: у qwen3-1.7b уже +0,125. На 7B и выше я бы ждал еще меньше, но это догадка, замера нет. Задач сорок, семейство задач одно, разбиение одно.

Финальный ответ ДА/НЕТ сошелся во всех 40 задачах, но это мягкая мера: угадать «да» можно и с неверным набором. Поэтому считаю по точному набору, там 0,900.

Где цифры

Отчет, протокол (написан до прогона), скрипты и сырые ответы моделей лежат на GitHub: https://github.com/Deadatreides/LLM-MEASUREMENTS/blob/main/experiments/theory_emergent_swarm/reports/REPORT_K1.md. Там же поправка про механизм распада и скрипт, которым ее проверяли.

Дальше напишу про тесты, которые модель пишет к собственному коду. Там картина неприятная. 42% наборов тестов вообще не запустились. Из тех, что запустились, 60% забраковали заведомо верное решение. Проверяльщик из маленькой модели вышел не лучше, чем ГИП.

А вопрос к тем, кто строит мультиагентные системы: вы сравнивали свой рой с лучшим одиночным агентом, пропущенным через тот же конвейер? У меня разница вышла пять пунктов. Интересно, получилось ли у кого-нибудь больше, чем шум.