Как построить совет AI-моделей для принятия решений: проблемы параллельного опроса и критики (Council)

Я — Denis Shokhirev, Enterprise AI Architect из Эрлангена, Германия. В DennisCraft AI Studio я строю AI-агентов для B2B-клиентов в DACH-регионе, часто под строгими требованиями к безопасности и объяснимости решений. За последние полгода развернул 14 production-агентов на стеке Claude, Supabase, n8n и self-hosted Postgres. Ниже — реальный опыт: почему построить совет (council) AI-моделей для принятия решений сложнее, чем кажется на демо, и из-за чего параллельный опрос и критика моделей в проде — это отдельная инженерная боль.

Зачем вообще совет моделей: реальные мотивы

В B2B-задачах, особенно в логистике и финтехе, нельзя доверять одной модели: слишком высока цена ошибочного ответа. Стандартное требование — иметь систему, способную объяснить процесс принятия решения и снизить вероятность системных сбоев. Именно поэтому паттерн совета (Council) — когда несколько независимых моделей выдают свои мнения, а потом происходит агрегация и критика — становится базовым.

Но когда речь доходит до продакшена, выясняется: большинство open-source решений не масштабируются под реальные SLA и не учитывают, например, GDPR-ограничения на обработку данных.

Параллельный опрос: где ломается теория

Базовая схема

Классический паттерн: запрос уходит параллельно 3–5 моделям (чаще всего — разным версиям GPT, Claude, Llama), результаты собираются и агрегируются через простое голосование, weighted scoring или ручную бизнес-логику.

import concurrent.futures

models = [claude_call, gpt_call, llama_call]

def query_all(prompt):
    with concurrent.futures.ThreadPoolExecutor() as executor:
        future_to_model = {executor.submit(model, prompt): model for model in models}
        results = []
        for future in concurrent.futures.as_completed(future_to_model):
            results.append(future.result())
        return results

Реальные проблемы

В недавнем проекте по автоматизации проверки транзакций я столкнулся с ситуацией, когда median-время ответа по council-стеку составляло 8,2 секунды (из-за задержек GPT-4 API), а SLA клиента — не больше 3 секунд. Простое масштабирование не решает проблему, приходится строить failover-логику и fallback на ускоренные локальные модели.

Критика и агрегирование: инженерные ловушки

Кто критикует кого?

Есть два паттерна:

• Peer critique — каждая модель "оценивает" ответы других.
• External critic — отдельная модель/агент (например, Claude или Llama 3), который агрегирует и анализирует все ответы.

В первом случае — лавинообразное удорожание: если 5 моделей дают 5 ответов и каждый оценивает остальных, получается 20 дополнительных запросов. Во втором — single point of failure, критик может сам ошибиться или деградировать под нагрузкой.

Как агрегировать?

Голосование — только самый базовый способ. На практике приходится реализовывать сложные схемы:

• Weighted voting: веса могут определяться историей успешных ответов моделей (по аналогии с Bandit-алгоритмами).
• Rule-based scoring: ручная логика по бизнес-правилам.
• Trust decay: если модель часто ошибается — её голос занижается.

def aggregate(results, weights):
    scores = {}
    for model, result in results.items():
        scores[model] = evaluate(result) * weights.get(model, 1)
    return max(scores, key=scores.get)

В production-проектах (например, автоматизация supply chain для среднего DACH-клиента) я фиксировал случаи, когда peer critique приводил к циклическим зависимостям и некорректным финальным решениям. На практике приходится вводить "stop rules" и лимиты на количество раундов критики.

Безопасность и аудит: что реально ломается

Сбор и хранение логов

В совете моделей появляется сложная аудит-цепочка: нужно сохранять не только финальный ответ, а все промежуточные голоса, оценки и критику. Для этого я применяю Supabase + self-hosted Postgres, с раздельными таблицами под raw-ответы, оценки и критику. Пример схемы:

CREATE TABLE council_raw_responses (
    id SERIAL PRIMARY KEY,
    model VARCHAR(32),
    prompt TEXT,
    response TEXT,
    ts TIMESTAMP
);

CREATE TABLE council_critiques (
    id SERIAL PRIMARY KEY,
    critic_model VARCHAR(32),
    target_model VARCHAR(32),
    critique TEXT,
    ts TIMESTAMP
);

Логи нужны не только для аудита, но и для анализа ошибок, обучения и обоснования решений перед регулятором/клиентом.

Контроль безопасности

На Dev-стадии я всегда использую statical analysis (semgrep, bandit) для всех AI-генерируемых частей кода и SQL, чтобы ловить паттерны типа SQL-injection или unsafe eval. На одной из последних интеграций я поймал 4 уязвимости CWE-89 (SQL injection) в сгенерированном коде, что совпадает с выводами Stanford CodeML 2024 (38% LLM-кода содержит CWE-89, source).

В продакшене нужен runtime sandbox и отдельный слой human review для критических решений.

Интеграция с workflow: через n8n и Supabase

На практике интеграция совета моделей в реальный бизнес-процесс идёт через n8n (оркестрация) и Supabase (хранилище и API). В n8n можно реализовать parallel flow, а Supabase использовать для хранения промежуточных результатов. Пример yaml-фрагмента для n8n:

- name: Model Council
  type: parallel
  branches:
    - call: gpt_call
    - call: claude_call
    - call: llama_call
- name: Critique
  type: map
  action: model_critique
- name: Aggregate
  type: function
  action: aggregate_results

Такой подход позволяет масштабировать и быстро модифицировать council под разные задачи, не переписывая всю инфраструктуру.

FAQ

Как выбирать состав моделей для совета?

Я ориентируюсь на задачи: для финансовых операций — минимум одна локальная модель и одна облачная, чтобы компенсировать возможные сбои API.

Можно ли построить council только на open-source?

Технически да (Llama, Mistral), но для production-SLA часто не хватает скорости и качества, особенно в сложных задачах.

Как объяснять решения совета перед регуляторами?

Сохранять все промежуточные ответы, критику, логику агрегации, и уметь быстро выгружать их в формате, удобном для аудита.

Сколько времени занимает настройка такого паттерна?

В среднем — 2–4 недели под ключ, если есть опыт работы с n8n и Supabase. Без автоматизации — дольше.

Что чаще всего ломается в продакшене?

Проблемы с rate limits, задержки в API и несовместимость с GDPR по части хранения персональных данных.

В каких местах вашего AI-совета чаще всего возникает конфликт между скоростью и качеством ответа? Отдаёте ли вы приоритет explainability или latency? Я провожу бесплатный 30-минутный аудит AI-стека для DACH-компаний в регулируемых рынках. Пишите в LinkedIn или на @ger_dennis_ai.