Idempotency и Retries для AI-систем: как не дублировать side effects

Короткая версия

Для AI-систем полезно различать:

1. Safe retries - read-only steps, generation, retrieval, ranking
2. Risky retries - любые действия с внешним side effect

Надёжный workflow обычно включает:

• idempotency key;
• retry policy с backoff и jitter;
• commit boundary;
• dedupe storage;
• ясную модель статусов pending / committed / failed.

Почему retry полезен для retrieval, но опасен для payment-like action?

1. Где retries в AI-стеке действительно нужны

Retry полезен почти везде, где есть transient failure:

• rate limit;
• network timeout;
• flaky downstream API;
• временно недоступный tool;
• queue redelivery;
• webhook delivery retry.

Но этим же retry-path-ом нельзя одинаково пользоваться для всех шагов. Production-команда должна явно разделять:

2. Commit boundary - ключевая идея

Самый важный вопрос не "что ответил API", а произошёл ли внешний commit.

Например:

• email уже ушёл, но клиент не получил response;
• refund создался, но webhook потерялся;
• CRM-запись обновилась, а agent loop считает, что action failed;
• tool успел сделать write, а timeout случился на response path.

Если система этого не понимает, любой retry становится лотереей.

3. Idempotency key нужен не только платежам

Команды часто связывают idempotency только с payment APIs. Для agent systems это слишком узко.

Idempotency key полезен в:

• create ticket;
• send message;
• issue refund;
• create order;
• schedule job;
• trigger workflow;
• update record через API gateway.

Ключевая идея:

• одинаковое намерение клиента или агента получает один stable key;
• повторный запрос с тем же key не создаёт новый side effect;
• система возвращает already-known result или статус.

4. Retries без backoff тоже ломают систему

Даже safe retry-path может быть вредным, если он:

• мгновенно штурмует упавший dependency;
• делает synchronized retry storms;
• съедает token budget внутри agent loop;
• маскирует реальную деградацию под шум повторных попыток.

Поэтому production retry обычно включает:

• exponential backoff;
• jitter;
• upper bound на attempts;
• circuit breaker или graceful fallback.

Это особенно важно для LLM-heavy workflows, где каждый лишний retry - это ещё и деньги, latency и downstream pressure.

5. Webhooks и duplicate delivery

AI-продукты всё чаще живут не только в request/response, но и в webhook-driven flows:

• long-running jobs;
• human approvals;
• external SaaS callbacks;
• background agent tasks.

Webhook delivery по своей природе может дублироваться. Поэтому обработчик должен быть idempotent even if upstream behaves correctly most of the time.

Минимальная защита:

• event ID;
• dedupe store;
• processed status;
• safe re-run semantics;
• observability по duplicate events.

6. Где AI-системы особенно уязвимы

Agent retries after tool ambiguity

Модель не уверена, выполнился ли tool, и предлагает повторить действие.

Human-in-the-loop resume

После approval workflow случайно переигрывает уже committed step.

Queue redelivery

Worker падает после commit, но до acknowledge.

Side effect hidden behind "generation"

Команда думает, что это "просто LLM step", хотя за ним стоит tool executor с write semantics.

7. Что полезно хранить в status model

Чтобы retries были безопаснее, workflow обычно хранит:

• intent_received
• execution_started
• commit_unknown
• committed
• failed_retryable
• failed_terminal

Особенно важен commit_unknown. Это неприятное, но честное состояние. Оно лучше, чем симулировать определённость там, где её нет.

8. Что полезно мерить

Минимальный reliability dashboard:

• retry count per step type;
• duplicate suppression hits;
• idempotency key reuse rate;
• stuck commit_unknown count;
• post-retry incident rate;
• average attempts before success;
• cost of retries in token and latency terms.

Пример idempotent tool wrapper

def execute_write_tool(intent_id, tool_name, args):
    existing = load_by_idempotency_key(intent_id)
    if existing:
        return existing.result

    mark_started(intent_id, tool_name, args)
    result = call_external_tool(tool_name, args)
    store_committed(intent_id, result)
    return result

Пример bounded retry

def retryable_call(fn, attempts=3):
    delay = 0.5
    for i in range(attempts):
        try:
            return fn()
        except TransientError:
            if i == attempts - 1:
                raise
            sleep(with_jitter(delay))
            delay *= 2

Практический совет: логируйте original_intent_id, attempt_number и commit_state отдельно. Тогда при инциденте видно, у вас правда был duplicate side effect или просто noisy transport around one committed action.