Decomposed Prompting (DECOMP)

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

DECOMP полезен, когда:

• одна задача состоит из разных типов операций;
• нужен контроль над каждым этапом;
• хочется переиспользовать готовые sub-prompts;
• ошибка должна быть локализуема по модулю.

На практике схема обычно такая:

• router/decomposer
• specialized handlers
• aggregator

Работай как модульная система.

Задача: подготовь вывод по квартальному отчёту.

[EXTRACT] Вытащи из текста выручку, рост, churn, CAC и margin.
[CALCULATE] Посчитай QoQ-изменения и 2 derived metrics.
[COMPARE] Сравни с прошлым кварталом.
[WRITE] Напиши короткий executive summary для CEO.

Чем DECOMP отличается от обычной декомпозиции

Plan-and-Solve и Least-to-Most обычно оставляют задачу внутри одной цепочки reasoning. DECOMP идёт дальше: он предполагает, что разные фрагменты работы требуют разных prompt behaviors, а иногда и разных моделей, инструментов или схем валидации.

То есть здесь главный выигрыш не в "красивом плане", а в modularity.

Когда DECOMP особенно силён

Где техника окупается

Хорошие кандидаты:

• report generation из таблиц и текста;
• contract / policy analysis;
• due diligence pipelines;
• customer support triage с извлечением фактов и подбором действия;
• multi-step research workflows;
• code review pipelines, где разные аспекты проверяются разными lanes.

Где она не нужна

Не стоит тащить DECOMP туда, где достаточно:

• обычного прямого ответа;
• одного Plan-and-Solve;
• Branch-Solve-Merge;
• простого tool call без orchestration.

Если задача не распадается на устойчивые повторяемые модули, DECOMP только усложнит систему.

Типовая архитектура

Хорошая mental model в 2026

DECOMP очень близок к тому, как сейчас строят:

• lightweight agents;
• workflow engines;
• prompt chains;
• tool routers;
• evaluation-ready production pipelines.

По сути это bridge между старым prompt engineering и новым workflow orchestration.

Практические design rules

Хороший модуль обычно:

• делает одну вещь;
• имеет чёткий input/output contract;
• возвращает структурированный output;
• допускает отдельную валидацию;
• может использоваться в нескольких сценариях.

Плохой модуль обычно:

• делает сразу три вещи;
• зависит от скрытого контекста;
• возвращает слишком свободный текст;
• неотделим от конкретной статьи или кейса.

Как выбрать правильную глубину декомпозиции

Главный practical question в DECOMP — не "можно ли разбить задачу ещё сильнее", а "где decomposition перестаёт давать signal".

Слишком крупные модули:

• скрывают источник ошибок;
• остаются почти такими же хрупкими, как один большой prompt;
• плохо переиспользуются.

Слишком мелкие модули:

• создают orchestration overhead;
• растят latency и стоимость;
• требуют слишком сложного router-а;
• усложняют debugging без реального качества.

Хорошее правило: декомпозиция окупается, когда модуль можно отдельно протестировать, переиспользовать и при необходимости заменить tool-backed реализацией.

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

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

Ещё часто ломают систему так:

• маршрутизатор придумывает слишком много модулей;
• один модуль дублирует функции другого;
• aggregator переписывает результаты, а не аккуратно собирает их;
• модуль, который должен был быть deterministic, оставлен полностью free-form.

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

Простейшая схема

class Handler:
    def __init__(self, name, run):
        self.name = name
        self.run = run


def decomp_pipeline(task, router, handlers, aggregator):
    plan = router(task)
    results = []

    for step in plan:
        handler = handlers[step["handler"]]
        output = handler.run(step["input"], context=results)
        results.append({
            "handler": handler.name,
            "input": step["input"],
            "output": output,
        })

    final = aggregator(task=task, module_outputs=results)
    return {"plan": plan, "results": results, "final": final}

Что особенно важно

Для production DECOMP почти всегда нужны:

• schema per module;
• logging per module;
• retry policy per module;
• selective human review for risky modules;
• evaluation not only for final output, but for each handler.

Полезная эволюция системы

На практике DECOMP редко строят сразу как сложный оркестратор. Более устойчивый путь:

1. сделать single-pass baseline;
2. выделить самый нестабильный subtask;
3. вынести его в отдельный handler;
4. только потом добавлять router и остальные модули.

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

Хорошие типы модулей

• EXTRACT
• CLASSIFY
• CALCULATE
• COMPARE
• VERIFY
• WRITE/SYNTHESIZE

Именно такие модули чаще всего дают реальное переиспользование.

Когда DECOMP стоит объединять с tools

Если подзадача может быть:

• вычислена кодом;
• проверена через search;
• вытащена из structured data;
• валидирована схемой,

лучше отправлять её не в "ещё один умный prompt", а в tool-backed lane. Тогда DECOMP становится заметно надёжнее.

Хороший operational KPI

В DECOMP полезно мерить:

• routing accuracy;
• per-handler failure rate;
• schema violation rate;
• latency by module;
• share of final defects caused by each handler.

Иначе вы видите только плохой финальный answer, но не понимаете, где именно умер pipeline.