Перейти к содержимому
← Все кейсыConsensus PatternAI

Мульти-модельный консенсус

4 LLM-провайдера × 2-stage deliberation — disagreement rate 28% выявляет ошибки, которые single-model пропускает

Проблема

Что не работает

Когда критическое бизнес-решение принимает одна LLM, ошибки неизбежны: галлюцинации, предвзятость к собственным паттернам, отсутствие самопроверки. В A/B тесте на 150 решениях single-model давал 22% ложных одобрений — каждое 5-е решение было ошибочным.

Решение

Архитектурный подход

Панель из 4 независимых провайдеров (OpenAI o4-mini, Claude Opus + thinking, Gemini 2.5 Pro + thinking, DeepSeek Reasoner) оценивает параллельно. Решение принимается кворумом ≥3/4. Во втором раунде модели видят аргументы друг друга и уточняют позицию. Disagreement rate между моделями ~28% — именно в этих случаях consensus предотвращает ошибки.

Вызовы

Что было сложно

Каждый LLM-провайдер возвращает ответ в своём формате — unified parsing занял больше времени, чем сам consensus-алгоритм. Стоимость 4 параллельных вызовов требовала тщательной оптимизации: пришлось балансировать между дешёвыми моделями для объёма и дорогими для критичных решений. Latency 4 параллельных API непредсказуема — нужен был graceful degradation при таймауте одного провайдера.

Роль

Моя роль и вклад

Архитектор и единственный разработчик

Полностью спроектировал и реализовал архитектуру: выбор 4 провайдеров с разными сильными сторонами (reasoning tokens, thinking blocks), протокол кворума ≥3/4, 2-stage deliberation с обменом аргументами, механизм отказоустойчивости MIN_PROVIDERS=2. Провёл A/B тест: 150 решений single-model vs consensus — ложные одобрения снизились с 22% до 13%.

Демо

Как это выглядит

Скриншоты

Реальные скриншоты

Архитектура

Архитектура системы

OpenAI o4-miniClaude OpusGemini 2.5 ProDeepSeek R1asyncio.gather()parallel callsAggregatorcount votesQuorum3/4APPROVEDorREJECTEDRound 2: models see each other's argumentsMulti-Model Consensus Protocolvotevote
Реализация

Как это работает

Асинхронные вызовы через asyncio.gather() к 4 API. Каждая модель использует свои сильные стороны (reasoning tokens, thinking blocks). Результаты агрегируются с порогом MIN_PROVIDERS=2 для отказоустойчивости. 2-stage deliberation: round 1 — независимые голоса, round 2 — обмен аргументами. Каждое решение логируется в AgentLog с per-provider результатами.

Архитектурное решение

Почему именно так

2-stage deliberation вместо 1-pass vote

Альтернатива

Параллельное голосование без обмена аргументами (как в v1 системы)

Почему не подошла

1-pass: модели голосуют в вакууме. Если Gemini отклонил из-за ложного срабатывания — нет шанса пересмотреть. 2-stage: модели видят аргументы друг друга и могут уточнить позицию.

Результат

Меньше ложных отклонений, качество решений выше. Цена: +1 раунд API (~$0.02)

Метрики

Результаты

01
A/B тест: 150 решений, ложные одобрения 22% → 13%
02
Disagreement rate между моделями: ~28%
03
Кворум ≥3/4 для одобрения
04
$0.01–0.05 за решение (4 модели параллельно)
05
Используется в board-svc (go/no-go) и review-svc (код-ревью)
Бизнес-импакт

Влияние на бизнес

A/B тест на 150 решениях: single-model — 22% ложных одобрений (каждое стоит $0.50–2.00 за напрасную кодогенерацию), consensus — 13%. Disagreement rate ~28% показывает, что модели расходятся в каждом 4-м решении — именно там consensus критичен. Стоимость: $0.01–0.05 за решение.

Методы

Алгоритмы и паттерны

Multi-annotator votingLLM-as-JudgeStructured JSON outputMulti-provider consensusA/B Testing (single vs consensus)asyncio.gather()
Стек

Технологии

  • Python
  • asyncio
  • OpenAI API
  • Anthropic API
  • Google GenAI
  • DeepSeek API

Готовы обсудить?

Если вам нужен архитектор, который строит автономные AI-системы — напишите.

Сербия (Белград) · CET/CEST · рабочие часы совпадают с EU · Опыт международных контрактов