Branch-Solve-Merge

Суть в двух словах

BSM особенно полезен, когда:

• критерии независимы;
• нужен multi-aspect review;
• удобно параллелить работу;
• один общий prompt слишком размывает фокус.

Частые сценарии:

• code review;
• article review;
• vendor comparison;
• due diligence;
• multi-criteria scoring;
• synthesis из нескольких исследовательских веток.

Используй Branch-Solve-Merge.

Задача: оцени лендинг B2B SaaS-продукта по 4 независимым аспектам: позиционирование, доверие, UX ясность, SEO базового уровня. Сначала оцени каждый аспект отдельно, потом собери единый вердикт.

Что отличает BSM от других decomposition-подходов

BSM не про общий план и не про зависимую лестницу шагов. Он про independent branches.

Если задача разбивается на аспекты, которые:

• можно анализировать отдельно;
• не требуют жёсткой последовательности;
• потом надо привести к единому выводу,

то BSM обычно оказывается естественнее и качественнее, чем один длинный ответ.

Где техника особенно сильна

Лучшие прикладные кейсы

BSM особенно практичен для:

• code review по отдельным осям: correctness, security, performance, maintainability;
• контент-аудита по quality, clarity, SEO, audience fit;
• product/competitor comparison по pricing, UX, integrations, governance;
• screening кандидатов или vendor proposals по rubric criteria;
• аналитических мемо, где сначала идут независимые lenses, потом executive synthesis.

Когда технику лучше не брать

BSM не стоит использовать, если:

• шаги зависят друг от друга;
• данные для веток сильно пересекаются, а split искусственный;
• нужен один план действий, а не разбор по осям;
• merge не может надёжно разрешать конфликты между ветками.

В этих случаях лучше подходят:

• Least-to-Most;
• Plan-and-Solve;
• DECOMP.

Ключевая сложность — merge

Большинство проблем BSM происходят не в branch и не в solve, а в merge.

Плохой merge:

• просто склеивает outputs;
• не разрешает противоречия;
• не расставляет приоритеты;
• не даёт decision или ranked recommendation.

Хороший merge:

• нормализует шкалы и оценки;
• выделяет главное;
• разрешает конфликты между ветками;
• возвращает ясный итог для downstream use.

Практический workflow

Как выбрать хорошие branches

Хороший branch set обычно:

• покрывает разные decision dimensions;
• минимально пересекается по смыслу;
• даёт outputs одного уровня детализации;
• позволяет человеку быстро понять, почему итог получился именно таким.

Плохой branch set выглядит так:

• одна ветка про strategy, другая про опечатки, третья про всё остальное;
• критерии дублируются между ветками;
• часть веток требует tools, часть просто болтает свободным текстом без rubric;
• merge потом вынужден нормализовать несопоставимые куски.

Практически полезно сначала сформулировать один общий rubric, а уже потом разложить его по веткам. Тогда branching остаётся управляемым и не превращается в случайный набор prompt-ролей.

Чем BSM полезен в production

Он даёт очень удобные traces:

• видно, какая ветка привела к плохому итогу;
• можно selectively rerun only one branch;
• легко добавлять новые аспекты без переписывания всей системы;
• удобно делать human review only for risky branches.

Это делает BSM не просто prompt-техникой, а удобным evaluation workflow pattern.

Что измерять

Для BSM особенно полезны:

• branch disagreement rate;
• merge defect rate;
• доля случаев, где rerun одной ветки меняет финальный verdict;
• latency per branch;
• human agreement on final merge.

Если система стабильно ошибается в одной и той же ветке, это уже не проблема всей техники, а локальный дефект конкретного branch handler или rubric.

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

Частые ошибки

Ещё часто ломают BSM так:

• веток слишком много;
• ветки пересекаются по смыслу;
• merge не знает, как решать конфликты;
• в каждой ветке используется слишком свободный output без rubric.

Техническая реализация

Базовый паттерн

import asyncio


async def branch_solve_merge(task, branches, solve_fn, merge_fn):
    branch_outputs = await asyncio.gather(
        *[solve_fn(task=task, branch=branch) for branch in branches]
    )

    final = await merge_fn(task=task, branch_outputs=branch_outputs)
    return {"branches": branch_outputs, "final": final}

Когда BSM особенно хорош технически

Он очень хорошо ложится на:

• async execution;
• queue-based workflows;
• rubric scoring;
• evaluator pipelines;
• judge systems, где разные branches проверяют разные dimensions.

Что полезно логировать

• branch definition;
• branch latency;
• branch score/confidence;
• disagreement between branches;
• merge rationale;
• final recommendation.

Хорошая branch taxonomy для code review

• correctness
• security
• performance
• maintainability
• test quality

Именно такая структура обычно даёт больший signal, чем один общий "сделай code review".

Когда нужен second-pass merge

Иногда merge itself стоит проверять отдельно, если:

• branch outputs конфликтуют;
• итог идёт в executive decision;
• ошибки дорогие;
• система генерирует ranked recommendation, а не просто summary.

Тогда полезен ещё один lightweight verification step поверх merge.