Конспект. Глава 55. Антипаттерны: где команды сжигают деньги и доверие

Как распознать проблему по следу

Один огромный prompt заметен по тому, что любое изменение чинит один кейс и ломает соседний. Лечится разделением стадий и контрактами.

«Флагманская модель везде» видна в счёте и ровном качестве простых задач. Лечится eval-набором и routing, а не требованием экономить токены вручную.

Multi-agent theatre оставляет длинные диалоги между ролями, но не добавляет независимых данных или проверок. Если второй агент читает тот же контекст и вызывает ту же модель, это часто дорогой пересказ.

Retry без классификации ошибок превращает timeout в нагрузочный тест провайдера и дублирует действия. Нужны bounded exponential backoff, idempotency и отдельная обработка 4xx, 429 и 5xx.

Human in the loop может быть декорацией: оператор видит сотни гладких ответов и нажимает approve. Выборочная слепая проверка и измерение правок полезнее обязательной кнопки.

async def call_with_policy(request):
    for attempt in range(3):
        try:
            return await provider.call(request)
        except RateLimitError:
            await sleep(jittered_backoff(attempt))
        except InvalidRequestError:
            raise
    raise TemporaryFailure("retry budget exhausted")

Главный failure mode

Команда оптимизирует proxy: acceptance черновика, latency первого токена, accuracy на удобной выборке. Клиентский outcome ухудшается тихо. Для каждого технического показателя нужна связь с результатом и окно, в котором проявляется ущерб.

Правило: антипаттерн начинается не со странной архитектуры, а с отсутствующего способа доказать, что сложность окупается.

Практикум 55.1

Разберите один production flow по trace за неделю. Найдите повторные вызовы, роли с одинаковым контекстом, безусловные retries и ручные approvals без правок. Удалите один слой или замените его детерминированной проверкой. Сравните стоимость успешного результата и ошибки на прежнем eval-наборе.