Вечером пишет инженер: не выходит завести схему planner + executor + judge. Собрал её на бесплатных моделях — одна упирается в лимит вызовов посреди задачи, другая гонит мусор. Вывод у него простой: проще отдать всё одной большой модели, чем чинить это трио.
Знакомая история — я собрал десятки таких конвейеров, и первые разваливались ровно так же. Разберу три ошибки, которые почти всегда стоят за «рой хуже одной модели». Рой не виноват.
Ошибка первая: бесплатные модели
Соблазн понятен: агентов много, вызовов много, пусть работают бесплатные. Но у бесплатных моделей (через сервисы-агрегаторы вроде OpenRouter) есть цена, просто она спрятана: лимиты вызовов посреди задачи, очереди, тихие смены версии, отключения без предупреждения. Конвейер из трёх звеньев, каждое из которых падает по-своему, не работает не потому, что схема плохая, — он не работает потому, что стоит на песке.
Правило простое: воркер должен быть дешёвым, но надёжным. Дешёвый и бесплатный — разные вещи. Самый предсказуемый дешёвый исполнитель сегодня — маленькая модель на вашей же видеокарте: без лимитов, без очередей, без сюрпризов. Обычной игровой видеокарты хватает, чтобы несколько малых моделей сидели в памяти одновременно, — я именно так и работаю.
Ошибка вторая: роли розданы не тем
В доках и гайдах кочует догма: «судья должен быть самым умным». Она пришла из мира бенчмарков, где одна топ-модель оценивает ответы других на сложные вопросы. Для проверки фактов и документов эта догма вредна: там решает не интеллект одного судьи, а независимость нескольких взглядов. Один гений пропустит ошибку из-за своего слепого пятна; три разные маленькие модели с разными слепыми пятнами пропустят её только все вместе — что случается реже.
Рабочая раздача ролей выглядит так. План — самой умной модели, которая у вас есть: планирование действительно требует ума, и здесь экономить нельзя. Исполнение — дешёвой и надёжной, ей ум не нужен, нужна предсказуемость. Проверка — не одному «самому умному судье», а нескольким разным дешёвым моделям плюс правилам: всё, что проверяется кодом — числа, форматы, ссылки, — проверяет код, а не модель.
И честное следствие из той же логики: если ваша задача — написать текст или код с нуля, одна сильная модель почти всегда сделает это лучше роя. Рой выигрывает не на творчестве, а на проверке и на массовых однотипных операциях. «Одна модель пишет лучше» — это не приговор рою, это признак того, что рой поставили не на ту работу.
Ошибка третья: нет эталона
Самая тихая ошибка. Когда конвейер выдаёт результат хуже ожидаемого, невозможно понять: схема плохая? модели слабые? промпт кривой? Без эталона любая настройка — гадание, а сравнение «одна модель против трио» — на глаз.
Эталон звучит страшно, а делается за вечер: десять-двадцать задач из вашей практики с заранее известными правильными ответами, файл и скрипт, который прогоняет систему и считает попадания. С этого момента каждый эксперимент отвечает цифрой. У меня такой замер регулярно заворачивает мои же «улучшения», которые выглядели очевидно правильными, — самый показательный день описан в истории консилиума. Как этот слой устроен целиком — я разбирал на истории про проверку документов.
С чего начать, если рой развалился
- Выбросьте бесплатные модели из конвейера. Поставьте локальную маленькую через Ollama или возьмите дешёвую платную — стабильность дороже нуля в счёте. Что и как ставить — в обзоре инструментов.
- Раздайте роли заново: план — умной, исполнение — надёжной, проверку — нескольким разным плюс коду.
- Соберите эталон из десяти задач и гоняйте каждую версию через него. Одна цифра вместо ощущений.
И проверьте главное: та ли это работа для роя. Если задача творческая — отдайте её одной сильной модели и не мучайтесь. Рой — инструмент недоверия, а не гениальности: он нужен там, где цена пропущенной ошибки выше цены лишней проверки.
