Голосование агентов: как несколько LLM договариваются об ответе

Идея простая до банальности: если один эксперт может ошибиться, спросите нескольких и возьмите ответ, который повторяется чаще. Для больших языковых моделей это оформилось в набор техник, которые называют по-разному — self-consistency, majority voting, multi-agent debate, mixture-of-agents. Общий принцип один: модель (или несколько разных моделей) генерирует несколько ответов, а дальше эти ответы сводят к одному через голосование, агрегацию или спор между агентами. Метод старый по меркам отрасли, но с распространением дешёвых моделей и агентных фреймворков он снова стал практичным для продакшена, а не только для статей.

Что именно происходит под капотом

Базовый вариант описан в работе Google Research о self-consistency (Wang et al., 2022): вместо одного прогона с температурой 0 модель генерирует несколько цепочек рассуждений с ненулевой температурой, а финальным ответом становится тот, который встречается в большинстве цепочек. Логика такая: к правильному ответу ведёт много разных путей рассуждения, а неправильные ответы разбросаны и не совпадают между собой. На арифметических и логических задачах авторы показали заметный прирост точности по сравнению с обычным chain-of-thought — конкретные цифры зависят от бенчмарка, смотрите оригинальную работу.

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

Три основных схемы

• Majority / self-consistency. N прогонов одной модели, побеждает самый частый ответ. Дёшево в реализации, хорошо работает там, где ответ дискретный: число, класс, да/нет.
• Multi-agent debate. Несколько агентов обмениваются аргументами в 2-3 раунда. Дороже, но помогает на задачах, где важно поймать ошибку рассуждения, а не просто редкий выброс.
• Mixture-of-agents. Иерархия: слой генераторов плюс слой-агрегатор, который синтезирует финальный ответ из чужих. Подходит, когда хочется совместить сильные стороны разных моделей.

Голосование не делает модель умнее — оно снижает дисперсию. Если модель систематически ошибается в одном и том же месте, десять её копий ошибутся десять раз и уверенно проголосуют за неправильный ответ.

Где это реально помогает

Голосование даёт выигрыш, когда ошибки модели случайны и разбросаны, а правильный ответ — устойчивая точка притяжения. Это математика, извлечение структурированных данных, классификация, задачи с проверяемым результатом. Здесь несколько прогонов честно повышают долю верных ответов.

Оно почти не помогает там, где нет одного правильного ответа: генерация текста, креатив, открытые вопросы. Голосовать за «лучшее эссе» бессмысленно — вы либо усредните до серости, либо будете выбирать наугад. И оно опасно там, где ошибка систематическая: если модель не знает свежий факт, увеличение числа прогонов только укрепит её ложную уверенность.

Кому это пригодится

• Разработчику пайплайна извлечения данных. Парсите инвойсы или резюме — три прогона с голосованием по каждому полю заметно снижают число битых значений.
• Команде, где цена ошибки высока. Медицинские подсказки, финансовые расчёты, юридический препроцессинг: дебаты между агентами ловят часть галлюцинаций до того, как их увидит человек.
• Инженеру, собирающему автономного агента^*. Голосование на шаге принятия решения (какой инструмент вызвать, какое действие выполнить) снижает риск залипания на неверном плане.

Кому не стоит

• Чат-боту первой линии поддержки. Latency и стоимость важнее лишних процентов точности — пользователь ждёт ответ за секунду, а не за пять прогонов.
• Любому креативному генератору. Тексты, картинки, идеи — голосование их только пригладит.
• Задачам с фактами, которых нет в модели. Здесь нужен RAG^** и внешний источник, а не десять уверенных копий одного незнания.

Сравнение подходов

Цена вопроса

Главный минус очевиден из таблицы — вы платите за каждый прогон. Пять голосующих прогонов означают примерно пятикратный расход токенов на входе и выходе плюс кратное увеличение времени ответа, если гоняете последовательно. Параллельный запуск снимает проблему latency, но не проблему счёта: у большинства API оплата идёт за токены, а не за время.

Отсюда практический совет: считайте прирост точности в процентных пунктах и сопоставляйте его с ростом счёта. Если пять прогонов дают плюс два пункта на задаче, где ошибка ничего не стоит, — это не окупается. Если на задаче, где каждая ошибка означает ручную переделку человеком, — окупается легко. Число прогонов подбирают эмпирически: часто выигрыш от голосования выходит на плато после 5-10 сэмплов, и дальнейшее увеличение почти не помогает.

Что учесть при внедрении

1. Определите, дискретный ли у вас ответ. Если да — голосование почти наверняка поможет.
2. Начните с self-consistency на одной модели: это дешевле и проще, чем оркестровать несколько.
3. Замеряйте точность на своём наборе данных, а не на публичных бенчмарках — распределение задач у вас другое.
4. Проверьте, нет ли систематической ошибки. Если модель ошибается стабильно, голосование её замаскирует, а не исправит.
5. Считайте бюджет токенов заранее и ставьте потолок на число прогонов.

^* Агент — программа, которая с помощью LLM не просто отвечает на запрос, а планирует действия и вызывает внешние инструменты (поиск, код, API) для достижения цели.

^** RAG (retrieval-augmented generation) — подход, при котором модель перед ответом подтягивает релевантные документы из внешней базы и отвечает, опираясь на них, а не только на память.