AGIMA показала LLM production pipeline: модель предлагает, код исполняет

Андрей Непряхин, директор департамента разработки AGIMA, описал подход на примере типовой задачи: пользователь просит ИИ-помощника оформить возврат платежа. Модель разбирает текст, находит заказ, выбирает причину и вызывает API. Если ответ не пришёл за 30 секунд, возникает вопрос: повторять запрос, проверять статус или передавать человеку. Именно здесь архитектура, построенная как единый LLM production pipeline (конвейер от запроса пользователя до реального действия), рассыпается. Слепой повтор может создать второй возврат. Отказ от повтора оставит первый запрос в неопределённом состоянии. Разбор AGIMA показывает, как собрать конвейер так, чтобы каждый участок отвечал за своё.

Workflow или агент: четыре вопроса перед выбором

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

Перед выбором ветви автор предлагает ответить на четыре вопроса:

• Насколько неоднозначен вход? Свободный текст требует интерпретации, а проверка лимита или расчёт обычно имеют точные правила.
• Можно ли формально проверить результат? JSON-схема проверит типы и обязательные поля, но не уместность компенсации.
• Известен ли маршрут заранее? Если каждый запрос проходит classify → validate → approve → execute, маршрут уже существует.
• Какова цена ошибочного действия? Черновик можно удалить, а платёж, публикация или изменение доступа оставляют внешний след.

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

Proposal-паттерн: модель предлагает, код решает

Ключевая идея LLM production pipeline от AGIMA: модель возвращает объект-предложение (proposal), а не выполняет действие. Структура фиксирует, что именно модель «думает», но ничего ещё не меняет.

from dataclasses import dataclass
from decimal import Decimal
from typing import Literal

@dataclass(frozen=True)
class RefundProposal:
    order_id: str
    reason: Literal["duplicate", "quality", "delivery", "other"]
    amount: Decimal
    confidence: float
    evidence_ids: tuple[str, ...]

Поле confidence помогает маршрутизации, но не отменяет бизнес-правило. Автор подчёркивает: порог уверенности нельзя назначать «на глаз» или брать из документации. Его калибруют на размеченных данных (обучающие данные с проставленными правильными ответами) под нужный баланс точности и полноты. В детекторе AGIMA порог 0,2 по калибровке давал точность 1,0, тогда как 0,5 терял около половины полноты.

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

def handle_refund(command, actor, store, payments):
    proposal = llm.propose_refund(command.text, command.context)
    validate_schema(proposal)

    order = store.get_order(proposal.order_id)
    validate_business_rules(proposal, order)
    require_permission(actor, "refund", order.account_id)

    if needs_human_approval(proposal, order):
        return queue_for_review(command.id, proposal)

    operation_id = stable_operation_id(command.id, "refund")
    store.save_operation_id(command.id, operation_id)

    return execute_with_reconciliation(
        operation_id=operation_id,
        request=build_refund_request(proposal, order),
        client=payments,
    )

Комментарий автора: operation_id сохраняется до первого внешнего вызова. Иначе рестарт между вызовом API и записью разорвёт связь с операцией, и система потеряет возможность проверить, прошёл ли платёж.

Почему retry опасен для записи?

Правило «при ошибке повторить три раза» годится для чтения, но для записи оно создаёт именно тот баг, который proposal-паттерн призван исключить: двойной возврат, дублирование записи в CRM.

Автор делит тайм-аут на четыре исхода:

• Запрос не был отправлен: обычный повтор допустим.
• Удалённая система вернула подтверждённый отказ: повтор зависит от класса ошибки.
• Запрос отправлен, но ответ потерян: исход неизвестен, сначала нужна сверка.
• Частичный ответ уже отдан потребителю: автоматически повторять нельзя, даже если есть ключ идемпотентности (механизм, гарантирующий, что повторный вызов не создаст дубль).

Именно третий и четвёртый случаи превращают «умного агента» в источник финансовых ошибок, если весь конвейер спрятан в одном промпте (prompt) и одном цикле агента.

Что делать с этим прямо сейчас?

Автору Дзена и копирайтеру. Если вы подключаете ИИ к публикации (автопостинг, генерация черновиков), стройте по тому же принципу: модель готовит черновик, а скрипт или вы сами проверяете его перед отправкой. Автоматическая публикация без промежуточного «proposal» рано или поздно опубликует галлюцинацию.

Маркетологу. Proposal-паттерн напрямую применим к ИИ-агентам, которые управляют рекламными ставками или рассылками. Любое действие с деньгами или с аудиторией проходит через код-гейт, а не выполняется моделью напрямую.

Предпринимателю в РФ и СНГ. Подход не привязан к конкретному провайдеру. Его можно реализовать с YandexGPT, GigaChat или любой открытой моделью (open-source), развёрнутой на своём сервере. Главное: инференс (inference, процесс получения ответа от модели) отделён от побочных эффектов.

Если вы строите ИИ-агента, который делает что-то необратимое, пусть первым вопросом будет не «какую модель взять», а «где в моём конвейере модель перестаёт предлагать и начинает действовать», и кто стоит на этой границе.