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

У команды был chatbot, пять агентов и еженедельная встреча по prompt engineering. Не было одного числа: сколько клиентских задач система решила без повторного обращения. Когда число наконец посчитали, оно оказалось хуже обычного поиска. Еженедельная встреча по prompt engineering при этом проходила исправно и была, по общему мнению, полезной.

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

Один огромный 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 ухудшается тихо. Для каждого технического показателя нужна связь с результатом и окно, в котором проявляется ущерб.

Быстрая диагностика за один вечер

Если нужно понять состояние чужой (или своей) LLM-фичи, хватает шести вопросов. Ответ «сейчас посмотрим» на любой из них уже диагноз.

1. Сколько задач система решила без повторного обращения за прошлую неделю?
2. Сколько стоил один такой решённый случай?
3. Какая версия промпта и модели обработала конкретный запрос вчера в 14:00?
4. Что происходит, когда провайдер отвечает 429 десять минут подряд?
5. Какой набор кейсов ломается при откате на предыдущую версию?
6. Кто и как узнает, что качество упало, если никто не пожалуется?

Шесть вопросов, десять минут, полная карта зрелости. Ни один из них не про архитектуру: они про способность отвечать за результат.

Правило главы

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

Чеклист главы

• Есть одна метрика результата, известная всей команде, и она измеряется еженедельно.
• Каждый технический показатель связан с результатом; оптимизация proxy отслеживается.
• Один огромный промпт разделён на стадии с контрактами.
• Выбор модели обоснован eval-набором, а не привычкой брать флагман.
• Дополнительные агенты приносят независимые данные или проверки, а не пересказ.
• Ретраи классифицированы по типам ошибок; необратимые действия защищены идемпотентностью.
• Human-in-the-loop измеряется: доля правок, доля отклонений, время на карточку.
• Регулярно проверяется, что сложность окупается: слой, который нельзя обосновать цифрой, удаляется.
• Есть окно наблюдения, в котором проявляется ущерб, и метрики смотрят на нём, а не на первом дне.

Практикум

Задача 55.1 — удалить один слой. ⭑⭑⭑

Разберите один production flow по трейсам за неделю и уберите то, что не окупается.

Критерии приёмки:

• Найдены повторные вызовы, роли с одинаковым контекстом, безусловные ретраи и ручные approvals без правок.
• Удалён один слой или заменён детерминированной проверкой.
• Сравнены стоимость успешного результата и ошибки на прежнем eval-наборе до и после.
• Показано, что качество не упало; если упало — изменение откачено и это описано.
• Результат оформлен как короткая заметка для команды с цифрами, а не как мнение.

Подсказки:

1. Начинайте с ролей, читающих один и тот же контекст: они удаляются безболезненно.
2. Ручные approvals без единой правки за неделю — почти всегда декорация. Замените их выборочным аудитом и измерьте.

Задача 55.2 — шесть вопросов вслух. ⭑

Проведите диагностику своей фичи по шести вопросам из главы.

Критерии приёмки:

• На каждый вопрос дан ответ числом или ссылкой на дашборд, либо честно записано «ответа нет».
• Для каждого отсутствующего ответа назван конкретный следующий шаг и владелец.
• Ответы собраны в одну страницу и показаны команде.
• Выбран один вопрос, ответ на который появится в течение недели, и он появился.
• Через месяц диагностика повторена; изменения зафиксированы.

Подсказки:

1. Не превращайте это в аудит с оценками: цель — список пробелов, а не обвинение.
2. Вопрос про версию промпта во вчерашние 14:00 самый болезненный. С него и начинайте.