DD · Оркестрация: разрешение спора судей и слияние результатов

Добор к Модулю 2 («Оркестрация и консилиум»). Урок 2.3 даёт архитектуру best-of-N + judge panel и турнир на выбывание, но останавливается на моменте «выбрано лучшее». Модуль закрывает три дыры сразу за этим моментом: (1) что делать, когда панель судей НЕ сходится — голосование/веса/мета-судья, а не только «выбор победителя»; (2) как не терять хорошие куски проигравших вариантов — слияние результатов, а не победитель забирает всё; (3) как менять промпты/модели при самообучении, не откатывая качество втихую — версионирование и регрессионные тесты. Метки честности — как в основном курсе: 🟢 проверено, 🟡 иллюстративно/первоисточник не найден, 🔴 исправлено.

0. Зачем это отдельный довесок, а не абзац в Уроке 2.3

Урок 2.3 учит: N explorer-агентов → судейская панель → knockout-турнир → «выбрано лучшее». Это работает, пока панель СОГЛАСНА и пока «лучшее» — один цельный вариант. На практике оба допущения ломаются, как только веер MVP или судейство контента становится реальным, а не демонстрационным:

• судья-технарь ставит варианту A высший балл за архитектуру, судья-по-бюджету — низший за дороговизну инфраструктуры; кто прав?
• вариант A побеждает по UI, но у варианта C лучше продумана логика бронирования столиков — обидно выбросить B и C целиком ради одного A;
• система дописывает свой собственный промпт критика по итогам месяца наблюдений (этап 2 самообучения из его профиля) — где гарантия, что новый промпт не станет хуже старого именно на тех кейсах, где старый работал отлично?

Все три ситуации — не крайние случаи, а норма для панели из разнородных судей и для системы, которая учится сама. Не закрыть их — значит либо получить панель, которая при первом же разногласии действует как один судья со случайным перевесом голоса (дисциплина «разнообразие судей» из Урока 2.3 ломается), либо терять ценность веера (зачем платить за 3-10 вариантов, если забирается только один целиком), либо однажды проснуться с системой, которая незаметно ухудшила качество, потому что «дописала себе промпт получше».

1. Когда консилиум не согласен: голосование, веса, мета-судья

По-человечески. Настоящий врачебный консилиум почти никогда не сходится единогласно с первой минуты — иначе он был бы одним мнением, продублированным трижды. У консилиума есть ПРОТОКОЛ на случай разногласий: большинство голосует за один диагноз — идут по нему; голоса специалистов имеют разный вес (мнение профильного онколога весомее мнения терапевта именно в вопросе онкологии) — взвешивают; голоса раскололись поровну и веса не решают спор — зовут более старшего врача, который смотрит именно спорный случай, а не пересматривает всё с нуля. Плохой консилиум — тот, где при первом же разногласии решение принимает случайно тот, кто высказался последним, или где протокола нет вообще.

Как называется по-настоящему (English). Majority voting (голосование большинством), weighted voting (взвешенное голосование — вес судьи зависит от специализации или измеренной точности в прошлом), meta-judge / arbiter (мета-судья — отдельный агент, вызывается ТОЛЬКО при разногласии панели), escalation (эскалация — передача решения человеку/более сильной модели), consensus threshold (порог согласия, например «минимум 2 из 3 голосов, иначе автоматическое решение не принимается»).

1.1 Четыре механизма разрешения спора — от дешёвого к дорогому

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

1. Majority voting (голосование большинством). Нечётное число судей (3, а не 2 или 4 — чтобы не было ничьей структурно), каждый выдаёт вердикт независимо (не видя вердиктов друг друга — иначе это не голосование, а один судья, повторённый эхом трижды), считается большинство. Дёшево, закрывает большинство решений на практике — но не решает ситуацию, где голоса реально расколоты поровну по содержательной причине, а не по случайному шуму модели.

2. Weighted voting (взвешенное голосование). Не все судьи равны в каждом конкретном вопросе: судья «по бюджету» должен иметь больший вес в вопросе стоимости инфраструктуры, судья «глазами клиента» — в вопросе юзабельности. Веса — не интуитивные, а откалиброванные по прошлым решениям: если рекомендации судьи-по-бюджету исторически оказывались точнее, его вес в этом критерии растёт со временем — тот же принцип, что промоушен правила в память только после count≥5 подтверждений (Модуль 3.2), применённый не к фактам, а к доверию судьям.

3. Meta-judge / arbiter (мета-судья, вызывается только при разногласии). Отдельный агент (лучше — на другой модели/семействе, чтобы не унаследовать те же слепые пятна, что и панель — принцип из orkestratsiya.md: «критик стоит держать на другом семействе модели») получает НЕ весь спор целиком, а только точку разногласия: конфликтующие вердикты + краткое обоснование каждого + сам артефакт. Ключевая экономия: мета-судья запускается только когда порог согласия (см. п.4) не достигнут — иначе это просто ещё один судья в панели, только дороже.

4. Escalation to human (эскалация человеку). Если даже мета-судья даёт низкую уверенность (confidence < 0.6, порог настраиваемый) или спор касается денежной траты/публикации под его именем — решение откладывается до утра, ровно как денежный гейт (Модуль 4.1). Это не костыль, а осознанная граница автономии: система обязана уметь сказать «я не уверена», а не правдоподобно, но произвольно разрешить спор.

1.2 Практическая схема: структурированный вердикт вместо текста

Чтобы голосование и веса вообще можно было посчитать программно (а не парсить текст LLM каждый раз — прямое нарушение mechanical-first, закон №3), КАЖДЫЙ судья обязан отдавать вердикт в фиксированной структуре, а не свободным текстом:

{
  "judge_id": "judge-budget",
  "candidate_id": "mvp-variant-B",
  "verdict": "reject",
  "score": 62,
  "confidence": 0.81,
  "criteria": {
    "solves_pain": 8,
    "usability": 6,
    "cost_to_build": 3
  },
  "reasoning_short": "архитектура требует платного стороннего API брони — не входит в бюджет клиента"
}

Порог согласия считается СКРИПТОМ (закон №3), а не следующим вызовом LLM:

def resolve(verdicts, weight_by_judge, tie_threshold=0.66):
    weighted = sum(v["score"] * weight_by_judge[v["judge_id"]] for v in verdicts)
    total_weight = sum(weight_by_judge[v["judge_id"]] for v in verdicts)
    agreement = len({v["verdict"] for v in verdicts}) == 1
    if agreement or (weighted / total_weight) / 100 >= tie_threshold:
        return "auto_decide", weighted / total_weight
    return "escalate_to_meta_judge", None

Для любопытных. Исследование "When AIs Judge AIs" (orkestratsiya.md) формулирует два наблюдения: (а) knockout-турнир (O(N log N)) практичнее полного перебора пар (O(N²)) при росте N; (б) панель из ОДНОРОДНЫХ судей (одна модель, один промпт, запущенный несколько раз) даёт менее надёжную оценку, чем панель из РАЗНЫХ ролей/моделей — однородные судьи склонны ошибаться синхронно, а голосование не отличит систематическую ошибку от согласия. 🟡 Точная методология этого исследования не перепроверена в verify/ — трактовать как качественный принцип («разнообразие судей важнее их числа»), не как измеренную цифру для презентации инвестору.

2. Слияние результатов: лучшее из каждого, а не победитель получает всё

По-человечески. Хороший консилиум редко говорит «слушайте только хирурга, забудьте терапевта» — чаще итоговый план лечения СОСТАВНОЙ: диагноз от одного специалиста, схема медикаментов от другого, диета от третьего. Отбросить два мнения целиком ради одного было бы расточительством. То же с вариантами MVP или сценария: вариант A может иметь лучшую архитектуру данных, вариант B — лучший UX брони, вариант C — самую дешёвую инфраструктуру. Забирать A целиком и выбрасывать сильные куски B и C — терять ценность, ради которой вообще запускался параллельный веер.

Как называется по-настоящему (English). Result merging / ensemble merging (слияние результатов) — в противоположность winner-take-all (победитель забирает всё). В простейшей форме иногда называют cherry-picking (буквально «сбор вишен» — выбор лучших частей из разных источников); неудачную, несовместимую сборку из кусков в индустрии иронично называют Frankenstein merge («сшили из частей труп, который не может ходить»).

2.1 Почему нельзя просто «взять лучшее по каждому критерию» бездумно

Слияние — не механическое копирование кусков-победителей построчно. Ловушка, из-за которой наивное слияние регулярно ломается: куски могут быть архитектурно несовместимы. Если вариант A использует одну модель данных (SQL-таблица бронирований), а вариант B — другую (событийный лог), взять «UI-компонент из B» и вставить его поверх «backend из A» без адаптации — получить код, который не собирается или не работает. Это зеркало предупреждения из avtonomnaya-razrabotka.md §5.6 про «не параллелить одну и ту же зону кода»: там опасность в параллельной записи в общий код, здесь — в слепом соединении независимо написанных частей.

Рабочая последовательность слияния — три шага, а не один:

1. Разложить критерии оценки ДО генерации вариантов (та же дисциплина, что checklist критика из Модуля 4.2 — «хук / визуал / звук / факты» для видео, «архитектура данных / UX брони / стоимость инфраструктуры» для MVP-варианта). Без заранее зафиксированного разложения судьи спорят о «в целом лучше», и слияние становится невозможным — сравнивать и комбинировать можно только то, что оценено по одинаковым осям.
2. Отдельный merge-агент выбирает победителя по КАЖДОМУ критерию отдельно (не по общему баллу), получая только релевантный фрагмент каждого варианта — не весь артефакт целиком, чтобы не тащить в контекст лишнее (токеномика, Модуль 5).
3. Отдельный интеграционный прогон проверяет совместимость собранного целого — тот же цикл PLAN→CODE→TEST→CRITIQUE→SCREENSHOT из Модуля 6, применённый к сшитому результату. Если интеграция не проходит тесты — сигнал вернуться к шагу 2 и выбрать менее «выигрышный», но более совместимый фрагмент, а не форсировать несовместимую сборку.

2.2 Применение к его двум заводам

Консультант-фабрика MVP (Модуль 9.3): вместо «клиент получает демо варианта B целиком», финальное демо — гибрид: модель данных из A (надёжнее для роста), UI брони из B (лучше протестирован на мобильном по скриншот-QC), схема цен из C (дешевле в поддержке). Судейская панель на финальном шаге оценивает не «какой из трёх исходных вариантов лучше», а «прошёл ли собранный гибрид те же тесты и скриншот-QC, что и любой одиночный вариант» — гибрид не освобождён от верификации только потому, что каждая часть уже проверялась отдельно.

Контент-мини-завод (сценарии/обложки): та же логика без кода — если thumbnail-studio сгенерировала 3 варианта обложки и критик оценивает хук/контраст/читаемость на мобильном по отдельности, слияние возможно (текст-хук из варианта 2, цветовая схема из варианта 1), но требует того же интеграционного шага — собранная обложка проходит vision-QC заново, а не по частям, потому что визуальная гармония — свойство целого кадра, а не суммы независимо хороших частей (два отдельно хороших цвета вместе могут давать плохой контраст).

3. Версионирование промптов и регрессионные тесты: не сломать качество при самообучении

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

Как называется по-настоящему (English). Prompt versioning (версионирование промптов — версия получает идентификатор, как коммит в git); regression testing (регрессионное тестирование — проверка, что новая версия не стала ХУЖЕ старой на известных случаях, а не только «лучше ли в среднем»); golden dataset / eval set (эталонный набор — размеченные примеры с известным правильным вердиктом, тот же набор из Модуля 4.2); canary rollout (канареечный запуск — новая версия сначала обкатывается на малой доле задач в теневом режиме).

3.1 Почему это не абстрактная предосторожность, а прямая опасность самообучения

Второй этап самообучения из его профиля — «система дописывает своих агентов» — означает буквально: промпт критика/генератора завтра будет НЕ ТЕМ ЖЕ, что сегодня, потому что система сама переписала его по итогам накопленных уроков (memory-bank). Это мощно, но опасно ровно тем же способом, каким опасна неконтролируемая мутация: новая версия промпта может улучшить один критерий и незаметно ухудшить другой, который реже проверяется человеком. Без регрессионного теста единственный способ узнать, что промпт стал хуже, — заметить падение качества постфактум, когда уже потрачены токены и, возможно, испорчено несколько видео/демо. Математика та же, что в Модуле 4.3 (0.95^10 ≈ 60% 🟡 иллюстративная арифметика, не эмпирика), только применена не к шагам одной задачи, а к последовательности версий промпта во времени: если каждая самостоятельная правка имеет 90% шанс не ухудшить качество, то после 10 правок подряд без проверки шанс, что качество не деградировало ни разу, — тоже около 35%. Регрессионный тест — тот же принцип «чекпойнт перезагружает вероятность», применённый к эволюции промптов, а не к шагам одного прогона.

3.2 Минимальная рабочая схема на существующем стеке

Ничего из этого не требует новой инфраструктуры — расширяется то же, что уже спроектировано для evals (Модуль 4.2) и memory-bank (Модуль 3.2, процедурный банк generators/*.json).

1. Промпт хранится с версией, не перезаписывается на месте.

{
  "agent_role": "critic-thumbnail",
  "version": "2026-07-12.3",
  "prompt_hash": "a91f3c...",
  "promoted_at": null,
  "eval_score": null,
  "parent_version": "2026-07-11.1",
  "changelog": "критик стал жёстче к контрасту текста после серии жалоб на нечитаемость превью"
}

Хранить промпты как файлы в git-репозитории (а не строкой в БД) даёт версионирование, diff и откат буквально бесплатно — прямое расширение Урока 3.3 («git-память для строителя», main/commit/log), только применённое не к прогрессу одной задачи, а к истории промптов агентов.

2. Golden set — тот же набор, что уже нужен для Модуля 4.2, не новый. 30-50 размеченных прошлых кейсов (видео с известным исходом / MVP-решений с известной реакцией клиента) — одноразовая инвестиция, которая окупается на каждой последующей смене промпта или модели, а не только один раз при калибровке критика.

3. Перед промоушеном новой версии — прогон против golden set, сравнение со старой версией, а не оценка «в вакууме».

def can_promote(new_score, old_score, per_criterion_new, per_criterion_old, max_regression=0.05):
    if new_score < old_score:
        return False, "общий балл ниже прошлой версии"
    for k in per_criterion_old:
        drop = per_criterion_old[k] - per_criterion_new.get(k, 0)
        if drop > max_regression * per_criterion_old[k]:
            return False, f"критерий '{k}' просел больше порога — общий рост не оправдывает частную деградацию"
    return True, "ок"

Важная деталь: недостаточно, чтобы СРЕДНИЙ балл вырос — новая версия обязана не проседать по ОТДЕЛЬНЫМ критериям больше заданного порога, иначе система рискует «выторговать» лёгкий общий прирост за счёт незаметной деградации в одном узком, но важном месте (например, промпт стал лучше находить хук, но перестал ловить фактические ошибки).

4. Canary rollout — новая версия сначала работает в теневом режиме. Первые N прогонов на реальных задачах генерируют результат, но НЕ публикуются автоматически — сравниваются судьёй/человеком с тем, что выдала бы старая версия. Только после устойчивого совпадения или превосходства на реальном потоке (не только на golden set, который со временем может устареть) — полная замена.

5. Автоматический откат при деградации в проде. Если структурированный лог решений (DD-nabludaemost.md, §1) показывает, что новая версия систематически даёт более низкие оценки панели, чем старая давала на сопоставимых задачах, — оркестратор откатывается на parent_version автоматически (смена указателя на файл в git, не пересборка), с уведомлением в Telegram, а не молчаливым продолжением работы на деградировавшем промпте до утра.

6. То же самое при смене МОДЕЛИ, не только промпта. Смена базовой модели критика — формально другое событие, но по риску идентична смене промпта: golden set прогоняется заново, регрессия по критериям проверяется тем же скриптом, canary-период обязателен. Частая ошибка — считать смену модели «улучшением по умолчанию»: новая модель может быть умнее в целом и хуже конкретно в узкой роли критика по одному критерию (например, менее консервативна к фактическим ошибкам) — узнать это можно только регрессионным прогоном, не бенчмарками производителя модели.

Чек-лист внедрения

• [ ] У каждого судьи вердикт — фиксированный JSON (verdict, score, confidence, criteria, reasoning_short), не свободный текст.
• [ ] Скрипт (не LLM-вызов) считает голосование/веса/порог согласия механически.
• [ ] Мета-судья вызывается ТОЛЬКО при недостигнутом пороге согласия, не на каждое решение.
• [ ] Определён порог confidence, ниже которого решение эскалируется человеку.
• [ ] Критерии оценки (checklist с весами) разложены ДО запуска веера вариантов, не постфактум.
• [ ] Есть отдельный merge-агент, выбирающий победителя ПО КАЖДОМУ критерию отдельно, с доступом только к релевантному фрагменту.
• [ ] Сшитый результат проходит тот же цикл верификации (тесты/скриншот/vision-QC), что и одиночный вариант.
• [ ] Каждый промпт/конфигурация агента хранится с версией (version, parent_version, changelog) в git.
• [ ] Есть golden set (30-50 размеченных кейсов, тот же, что для evals Модуля 4.2), переиспользуемый при каждой смене промпта/модели.
• [ ] Новая версия промотируется только если не просела ни по одному критерию сверх порога — рост среднего НЕ оправдывает частную деградацию.
• [ ] Есть теневой (canary) период на реальных задачах перед полной заменой версии.
• [ ] Настроен автоматический откат на parent_version при деградации в проде + уведомление.
• [ ] Смена базовой МОДЕЛИ проходит ту же регрессионную проверку, что и смена промпта.

Куда это в курсе

Прямой добор к Модулю 2 («Оркестрация и консилиум»), встаёт сразу после Урока 2.3 («Judge Panel и best-of-N») — там архитектура заканчивается на «панель → турнир → выбрано лучшее», здесь начинается с «а что если панель не сошлась» и «а что если лучшее — не один вариант целиком».

Прямые связи с остальным курсом: - Модуль 3, Урок 3.2-3.4 (память и самообучение) — версионирование промптов невозможно без процедурного банка памяти и порога count≥5; этот модуль показывает, ЧТО должно произойти перед тем, как новая версия из памяти попадает в прод. - Модуль 4, Урок 4.2 (критик-агент, evals) — golden set 30-50 кейсов и checklist критика с весами — тот же артефакт, переиспользуемый здесь для регрессионных тестов, не новая инвестиция. - Модуль 4, Урок 4.3 (Loop of Death) — математика чекпойнтов «перезагружает вероятность» применена здесь к последовательности версий промпта, а не к шагам одного прогона. - Модуль 6 (автономная ночная разработка) — интеграционная проверка сшитого MVP-результата — тот же цикл PLAN→CODE→TEST→CRITIQUE→SCREENSHOT, применённый к результату слияния. - DD-nabludaemost.md — структурированный лог решений судей и correlation ID нужны, чтобы заметить систематическую деградацию промпта в проде и понять, какое решение панели пошло не так. - Модуль 9, Урок 9.3 (консультант-фабрика MVP) — раздел 2.2 описывает, как гибридное демо (слияние) выглядит в его сценарии «боль клиента → ночь → утреннее демо».