Детерминированные пайплайны против LLM-агентов

Один и тот же процесс — «разобрать входящий счёт, сверить с заказом, завести в учётную систему» — можно собрать двумя способами. Первый: фиксированная цепочка шагов, где LLM вызывается ровно там, где нужно извлечь текст из PDF, а всё остальное делает обычный код. Второй: агент, которому вы даёте инструменты и цель, а он сам решает, что и в каком порядке вызывать. Первый вариант отработает за один вызов модели и будет падать предсказуемо. Второй может уйти на 30–50 вызовов, стоить в десятки раз дороже за прогон и на одном и том же входе вести себя по-разному. Выбор между ними — не вопрос моды, а вопрос того, готовы ли вы отлаживать недетерминированную систему в проде.

Что именно противопоставляется

Термины размыты, поэтому договоримся о рамках. Под детерминированным пайплайном здесь понимается система, где граф шагов задан заранее в коде: последовательность фиксирована, ветвления описаны условиями, а модель используется как функция — на вход текст, на выход структура. Порядок вызовов не зависит от того, что модель «решила».

Под LLM-агентом — система, где модель на каждом шаге сама выбирает следующее действие из набора инструментов¹, опираясь на историю диалога и результаты предыдущих вызовов. Управляющая логика вынесена внутрь модели, а не в ваш код.

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

Почему разница не косметическая

Детерминированный пайплайн вы отлаживаете как обычную программу: есть вход, есть ожидаемый выход, регрессия ловится тестом. Агент вы отлаживаете как процесс с внутренним состоянием, которое меняется от прогона к прогону. Один и тот же тикет он может закрыть за три шага, а может зациклиться, дважды дёрнуть один инструмент и упереться в лимит итераций. Воспроизвести сбой сложнее, потому что температура, порядок токенов и мелкие правки промпта смещают поведение.

Агент не делает вашу систему умнее — он переносит управляющую логику из кода, который вы можете прочитать, в веса модели, которые прочитать нельзя.

Сравнение по осям, которые видны в проде

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

Где брать пайплайн

Есть признаки, по которым детерминированная цепочка почти всегда лучше:

• Шаги известны заранее. «Извлечь — валидировать — записать» не требует, чтобы модель импровизировала с порядком.
• Цена ошибки высокая. Финансовые операции, изменение данных, всё, что нельзя молча откатить. Вам нужна точка, где вы гарантируете проверку.
• Нужен аудит. Если по каждому решению придётся объяснять регулятору или клиенту, почему система поступила так, читаемый граф в коде бьёт трейс из рассуждений модели.
• Высокий поток и низкая маржа на прогон. Разница между одним вызовом и сорока в проде на миллионах запросов — это счёт, который заметят в финансах.

Где агент оправдан

• Пространство задач открытое. Пользователь формулирует цель свободным текстом, и заранее перечислить сценарии нельзя.
• Каждый шаг проверяем. Если у агента есть инструмент, который даёт однозначную обратную связь — компилятор, тестовый прогон, поисковый индекс — он может итеративно приближаться к результату и сам замечать ошибку.
• Цена ошибки низкая и обратимая. Черновик текста, план исследования, вариант кода на ревью человеку — здесь лишняя итерация дешевле, чем недостающая гибкость.
• Человек в контуре. Агент готовит, человек утверждает. Тогда недетерминированность становится вашей проблемой удобства, а не проблемой корректности.

Как ограничить агента, если он всё-таки нужен

Полностью свободный агент — редко хорошая идея. Практичный компромисс — обвесить его теми же гарантиями, что даёт пайплайн:

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

Минимальный каркас управляемого шага

Идея гибрида в том, что решение модели проходит через ваш код прежде, чем что-то произойдёт. Схематично цикл одного шага агента с валидацией выглядит так:

def run_step(state, tools, max_calls=8):
    for _ in range(max_calls):
        action = model.decide(state)          # модель предлагает действие
        tool = tools.get(action.name)
        if tool is None:
            state.append(error("unknown tool"))
            continue
        if not tool.is_allowed(action.args):    # ваша проверка, не модели
            state.append(error("action rejected"))
            continue
        result = tool.run(action.args)           # исполняем только разрешённое
        state.append(result)
        if action.name == "finish":
            return state
    raise StepLimitExceeded(state)               # предсказуемый отказ

Ключевое здесь — строки с is_allowed и StepLimitExceeded. Именно они возвращают в недетерминированную систему две вещи, которые вы теряете вместе с жёстким графом: контроль над тем, что реально исполнится, и гарантию, что прогон не будет крутиться бесконечно.

Как выбирать на практике

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

¹ Инструмент (tool) — функция с описанным интерфейсом, которую модель может вызвать: поиск, запрос к базе, HTTP-вызов, запуск кода. Модель формирует аргументы, исполнение всегда происходит в вашем коде.