LLM-as-Judge в критических задачах: корзина метрик вместо одной оценки

АГЕНТ 1 (основной): Генерирует ответ на критическую задачу → текст + обоснование

АГЕНТЫ 2-N (специалисты): Каждый оценивает ту же задачу с позиции своей роли → текст + обоснование

АГЕНТ-АРБИТР (LaJ): Сравнивает выводы → проверяет:
  - Покрытие рисков (все ли критичные моменты упомянуты)
  - Корректность (нет ли фактических ошибок)
  - Приоритизация (верно ли расставлены акценты)
  - Качественные ворота (соблюдены ли жёсткие правила домена)
  → Оценка согласованности (0-1)

ТРИГГЕР: Если согласованность < порога → человеческая проверка

Все шаги выполняются как отдельные запросы к модели с разными system prompts.

Ситуация: Готовишь важное бизнес-решение — выход на новый рынок с риском вложить 5 млн рублей. Нужно проверить, не упустил ли ты критические риски.

Промпт 1 — Основной аналитик:

Ты бизнес-аналитик с фокусом на стратегию выхода на новые рынки.

Задача: Оцени риски запуска сервиса доставки готовой еды в Казани с бюджетом 5 млн рублей на первый год.

Контекст:
- Целевая аудитория: офисные работники 25-40 лет
- Средний чек 400₽
- Конкуренты: Яндекс Еда, Delivery Club
- Команда: 3 человека (я + маркетолог + разработчик)

Формат ответа:
1. Топ-5 критических рисков
2. Каждый риск с обоснованием ИЗ контекста
3. Приоритет (высокий/средний/низкий)

Промпт 2 — Специалист по финансам:

Ты финансовый директор с опытом в стартапах.

Оцени ТОЛЬКО финансовые риски того же проекта (контекст тот же).

Формат: список рисков с обоснованием и приоритетом.

Промпт 3 — Специалист по операционке:

Ты операционный директор с опытом в логистике и доставке.

Оцени ТОЛЬКО операционные риски того же проекта.

Формат: список рисков с обоснованием и приоритетом.

Промпт 4 — Арбитр:

У меня есть 3 оценки рисков для одного проекта от разных экспертов.

Твоя задача:
1. Найди риски, которые упомянул основной аналитик, но пропустили специалисты
2. Найди риски, которые упомянули специалисты, но пропустил основной
3. Оцени согласованность по критичным рискам (высокий приоритет)
4. Если есть расхождения в оценке критичности одного и того же риска — флаг на проверку

Оценки:
[вставить 3 ответа выше]

Формат ответа:
- Согласованность: X% (сколько критичных рисков пересекаются)
- Пропущено основным аналитиком: [список]
- Расхождения в оценке: [список]
- Нужна проверка: ДА/НЕТ

Результат:

Модель покажет процент согласованности между оценками. Если основной аналитик пропустил риск, который два специалиста назвали критическим (например, "нужен запас на выплаты курьерам в праздники" или "проблемы с поставщиками при масштабировании"), арбитр это флагнет. Если согласованность низкая (например, 40% вместо 80%), это сигнал: модель неуверена, иди разбираться вручную.

LLM плохо детектит пропуски — если модель не упомянула риск, стандартные метрики (BLEU, ROUGE) этого не поймают, потому что они сравнивают только то, что есть в тексте. Единственный способ найти пропуск — вернуться к исходнику и сверить вручную. Но если у тебя несколько агентов с разными ролями оценивают одно и то же, вероятность, что все одновременно пропустят критичный момент — ниже.

Согласованность между агентами — прокси для уверенности модели. Если три агента называют один и тот же риск критическим, это сигнал, что модель в этом уверена. Если один говорит "критично", другой "средне", третий вообще не упомянул — это флаг неопределённости, а не надёжный вывод. В критических задачах низкая согласованность = триггер на человеческую проверку.

Контекстная чувствительность через качественные ворота. Не все ошибки одинаково опасны. Например, в медицинском кейсе из исследования пропуск истории приёма bleomycin (химиотерапия) может убить пациента на операции через кислородное отравление лёгких, даже если это было 10 лет назад. Пропуск другого препарата — просто неточность. Определи заранее, какие типы ошибок критичны (качественные ворота), и проверяй их отдельно.

Рычаги управления: - Количество агентов — больше агентов = выше вероятность поймать пропуск, но дороже в токенах. Для критичных задач 3-5 агентов. - Порог согласованности — поставь 70-80% для критичных задач: если меньше — проверка вручную. - Роли агентов — чем специфичнее роль, тем острее фокус на своей области и меньше шанс пропустить профильный риск. - Формат ответа — если просишь "обоснование ИЗ контекста", модель даёт verbatim цитаты из исходника, и ты видишь на что она опиралась.

=== ПРОМПТ 1: Основной агент ===
Ты {роль основного агента}.

Задача: {описание задачи}

Контекст:
{контекст задачи}

Формат ответа:
1. Топ-{N} критических {что ищем: рисков/фактов/выводов}
2. Каждый с обоснованием ИЗ контекста
3. Приоритет (высокий/средний/низкий)

---

=== ПРОМПТ 2-N: Агенты-специалисты ===
Ты {роль специалиста — узкая экспертиза}.

Оцени ТОЛЬКО {область специалиста} для той же задачи.

Контекст: {тот же контекст}

Формат: список {что ищем} с обоснованием и приоритетом.

---

=== ПРОМПТ ФИНАЛЬНЫЙ: Арбитр ===
У меня есть {N} оценок для одной задачи от разных экспертов.

Твоя задача:
1. Найди {что ищем}, которые упомянул основной агент, но пропустили специалисты
2. Найди {что ищем}, которые упомянули специалисты, но пропустил основной
3. Оцени согласованность по {критерий: высокий приоритет / критичность}
4. Если есть расхождения в оценке критичности — флаг на проверку

Оценки:
{вставить ответы агентов}

Формат ответа:
- Согласованность: X%
- Пропущено основным: [список]
- Расхождения: [список]
- Нужна проверка: ДА/НЕТ

Плейсхолдеры: - {роль основного агента} — основная экспертиза (бизнес-аналитик, юрист, редактор) - {описание задачи} — конкретная задача - {контекст задачи} — данные для анализа - {N} — сколько топ-пунктов нужно - {что ищем} — риски / ошибки / факты / выводы - {роль специалиста} — узкая экспертиза (финансы, операционка, юридика) - {область специалиста} — фокус этого агента

🚀 Быстрый старт — вставь в чат:

Вот шаблон multi-agent оценки с арбитром. Адаптируй под мою задачу: [твоя задача]. 
Задавай вопросы, чтобы заполнить поля.

[вставить шаблон выше]

LLM спросит: какая основная роль нужна, какие специалисты, что конкретно оцениваем, какой контекст. Она возьмёт структуру из шаблона (основной агент → специалисты → арбитр) и адаптирует под твою задачу.

⚠️ Пропуски всё равно возможны: Если все агенты обучены на одних данных, они могут одновременно пропустить редкий, но критичный момент. Метод снижает риск, но не обнуляет.

⚠️ Дорого в токенах: 3-5 агентов + арбитр = 4-6 запросов на одну задачу. Для некритичных вопросов избыточно.

⚠️ Только для задач с fact-checking: Если задача креативная (написать слоган, придумать сценарий), согласованность не показатель качества — наоборот, разнообразие ценно.

⚠️ Модель не становится надёжнее: Метод не улучшает качество каждого отдельного агента, он только детектит расхождения. Если модель слабая во всех ролях — расхождений не будет, но ответ всё равно плохой.

Исследование показывает, что одна LLM-оценка (LLM-as-Judge) ненадёжна в критических задачах — она наследует bias, нестабильна при изменении формулировок, плохо детектит пропуски. Это не про "улучшить промпт", это про архитектурный принцип: в критических сценариях нужна множественность оценок + прозрачный триггер на человеческую проверку.

Авторы тестировали это на медицинском кейсе: агентный фреймворк для предоперационной оценки риска пациента. Агент-анестезиолог готовит бриф рисков, агенты-специалисты (кардиолог, пульмонолог, нефролог, гематолог) оценивают каждый свою область, агент-арбитр сравнивает согласованность и проверяет "качественные ворота" (quality gates) — жёсткие правила безопасности типа "если в истории bleomycin → флаг на ограничение кислорода при анестезии". Если арбитр находит низкую согласованность между агентами — триггер на проверку человеком-анестезиологом.

Ключевой инсайт: контекстная чувствительность ошибок. Пропуск истории bleomycin может убить пациента (кислородное отравление лёгких во время операции), пропуск другого препарата — просто неточность. Стандартные метрики (BLEU, ROUGE, cosine similarity) этого не видят — они меряют совпадение слов, а не критичность пропущенной информации. В исследовании радиологов строковые метрики вообще не коррелировали с экспертными оценками качества ответов.

Исследование также разбирает почему RAG и Knowledge Graphs недостаточны для критических задач: если граф устарел или неполон, ошибки пропагируются в вывод; если retrieval вытаскивает нерелевантный контекст, RAG ухудшает качество. Более того, даже с RAG риск пропусков остаётся высоким — модель может просто не включить важную информацию в ответ, даже если она есть в контексте.

Практический вывод для пользователя чатов: если задача критичная (финансовое решение, юридический вопрос, медицинский совет), не полагайся на один ответ LLM. Проси несколько мнений с разными ролями, сравнивай согласованность, и если расхождения большие — это сигнал неуверенности модели, а не "разные точки зрения".

Команда из University of York и Bradford Royal Infirmary подошла с позиции safety assurance: не "как улучшить LLM", а "какие доказательства нужны, чтобы утверждать что LLM-система безопасна в критическом контексте". Они взяли реальный медицинский use case — предоперационную оценку риска пациента — и построили агентный фреймворк с LLM-as-Judge арбитром.

Логика была такая: если человек-анестезиолог использует агентный фреймворк как помощника, какие гарантии нужны, чтобы он мог на него положиться? Исследователи создали набор клинических ролей (анестезиолог, кардиолог, пульмонолог, нефролог, гематолог, онколог), каждая с профилем в JSON и специфическими инструкциями. Каждый агент готовит риск-бриф для одного и того же пациента, извлекая verbatim-цитаты из медкарты как evidence.

Дальше интересное: они не мерили accuracy модели, а смотрели на метрики оценки как на свидетельства для safety case. Типичные метрики (BLEU, ROUGE, Jaccard index, cosine similarity) показали слабую корреляцию с экспертными оценками — радиологи в одном исследовании вообще не согласились с численными скорами. Это подтвердило гипотезу: строковые метрики не видят критичность ошибок.

Что удивило: даже с extensive augmentation (RAGuard, SafetyClamp) риск пропусков оставался существенным. Одна команда в nuclear medicine Q&A нашла, что RAGAS (LLM-based метрика) лучше коррелирует с экспертами, чем ROUGE, но всё равно correlation была умеренной. Другая команда (medical text understanding) создала error taxonomy (hallucination, omission, incompleteness) через LaJ с клинической проверкой и нашла, что chain-of-thought failing доминирует на числах, единицах измерения, аббревиатурах (ровно то, что критично в анестезии: дозы, FiO2, lab values).

Инсайт для практики: если согласованность между агентами высокая (80%+), это не значит что ответ правильный (все могут ошибаться одинаково), но если согласованность низкая (<70%) — это чёткий сигнал неуверенности модели. Исследование предлагает использовать этот порог как триггер на human review в critical paths.

Ещё один вывод: качественные ворота (quality gates) = domain-specific safety rules. Например, "if bleomycin in history → FiO2 restriction mandatory". Эти правила можно проверить детерминированно (exact match в evidence), и если они нарушены — флаг критической ошибки. Композиция: мягкие метрики (согласованность агентов) + жёсткие правила (quality gates) + порог confidence (триггер на проверку) = доказательная база для safety case.

Evaluating Metrics for Safety with LLM-as-Judges (preprint, expected early 2026)

Kester Clegg, Richard Hawkins, Ibrahim Habli — Centre for Assuring Autonomy, University of York, UK

Tom Lawton — Bradford Royal Infirmary, UK