Сбои production AI: что ломается после демо

Большинство AI-демо ломаются слишком вежливо. Пример входных данных чистый. Данные актуальные. Инструмент работает. Пользователь задает нормальный вопрос. Модель дает хороший ответ. Все кивают.

Production менее вежлив. Пользователи вставляют messy inputs. Исходные документы устаревают. API дают timeout. Prompts drift. Модель следует неправильной инструкции. Клиент задает вопрос чуть за пределами корпуса. Tool call проходит успешно, но обновляет неправильную запись. Workflow выдает что-то достаточно гладкое, чтобы никто не заметил ошибку до более позднего момента.

Эта статья - failure-mode register для production AI systems. Используйте его до запуска, а не после первого инцидента.

Production AI review должен спрашивать "как это ломается?" до вопроса "насколько впечатляет happy path?" У каждого failure mode должны быть control, test, owner и stop condition.

Failure mode 1: правдоподобный ложный output

Система генерирует ответ, который звучит правильно, но не подтвержден или неверен.

Типичные triggers:

• Конкретные факты без source grounding.
• Юридические, медицинские, финансовые или policy-вопросы.
• Recent events.
• Low-quality retrieval.
• Summary длинных документов, где релевантное доказательство глубоко спрятано.

Controls:

• Требуйте citations или source snippets для factual claims.
• Отказывайтесь отвечать за пределами доступного source set.
• Добавьте eval cases для известных false-answer patterns.
• Направляйте high-impact outputs на human review.
• Логируйте source IDs, использованные в ответе.

Не контролируйте это фразой вроде "be accurate". Контролируйте sources, tests и review gates.

Failure mode 2: stale context

Ответ grounded, но grounded в старой информации.

Примеры:

• Старая pricing page.
• Superseded policy.
• Предыдущая версия договора.
• Устаревшая product documentation.
• Cached customer status.

Controls:

• Храните source date, version, owner и freshness rule.
• Предпочитайте authoritative sources вместо summaries.
• Помечайте stale sources в retrieval output.
• Добавьте freshness tests.
• Уведомляйте owner, когда key sources старше своего review window.

RAG systems могут уверенно отвечать из stale documents. Retrieval layer должен знать, что значит "current".

Failure mode 3: sycophancy и over-agreement

Модель зеркалит предположение пользователя вместо того, чтобы его проверять.

Это важно в strategy, analysis, planning и decision support. Пользователь спрашивает: "Этот launch plan выглядит надежно, верно?" и получает согласие вместо risk analysis.

Controls:

• Просите counterarguments и uncertainty.
• Используйте decision rubrics вместо open-ended approval.
• Требуйте "what would make this wrong?"
• Разделяйте idea generation и review.
• В evals включайте примеры, где premise пользователя ошибочен.

Система должна помогать пользователю думать лучше, а не просто полировать его текущую позицию.

Failure mode 4: prompt injection

Модель воспринимает untrusted content как instruction.

Примеры:

• Web page говорит "ignore previous instructions."
• Support email содержит malicious instructions.
• Документ в RAG corpus просит assistant раскрыть hidden data.
• Tool result содержит текст, который пытается изменить workflow.

Controls:

• Четко маркируйте untrusted content.
• Никогда не ставьте retrieved content на тот же authority level, что system/developer instructions.
• Ограничивайте tool permissions.
• Добавьте allowlists для outbound actions.
• Тестируйте injection examples в evals.
• Держите secrets вне prompt context.

Prompt injection не решается одним умным system prompt. Он уменьшается архитектурой: data boundaries, tool permissions и output validation.

Failure mode 5: unsafe tool use

Модель вызывает неправильный tool, вызывает правильный tool с неправильными arguments или действует до того, как контекста достаточно.

Примеры:

• Обновляет неправильный CRM contact.
• Отправляет email неправильному получателю.
• Создает duplicate records.
• Бронирует appointment без подтверждения timezone.
• Удаляет или перезаписывает данные.

Controls:

• Начинайте с read-only.
• Используйте narrow tools с explicit schemas.
• Валидируйте tool arguments вне модели.
• Требуйте confirmation для writes.
• Добавьте idempotency keys.
• Логируйте tool calls и results.
• Добавьте kill switch.

Tool use должен ограничиваться workflow, а не доверием к judgment модели.

Failure mode 6: schema и contract drift

Формат model output меняется, или downstream API меняется, и workflow тихо ломается.

Controls:

• Используйте structured outputs там, где возможно.
• Валидируйте каждый model output перед использованием.
• Считайте malformed output recoverable failure.
• Версионируйте prompts и schemas вместе.
• Добавьте contract tests для downstream APIs.
• Мониторьте parsing failures.

Если downstream node предполагает valid JSON, workflow должен доказать, что у него valid JSON.

Failure mode 7: weak fallback

Система замечает проблему, но не восстанавливается безопасно.

Плохие fallbacks:

• Empty answer.
• Silent failure.
• Generic apology без action.
• Repeated retry loop.
• Human escalation без context.

Хорошие fallbacks:

• Понятное user message.
• Human queue с input, source, error и attempted action.
• Retry with backoff только там, где retry безопасен.
• Manual path для urgent cases.
• Stop condition для repeated failures.

Fallback - часть продукта. Если его не спроектировать, failure experience будет импровизацией.

Failure mode 8: observability gap

Что-то ломается, и никто не может восстановить почему.

Controls:

• Логируйте prompt template и version.
• Логируйте model и settings.
• Логируйте source IDs, а не только answer text.
• Логируйте tool calls, arguments и results с redaction.
• Логируйте validation errors.
• Отслеживайте latency, cost и fallback rate.
• Держите retention коротким, если compliance не требует большего.

Не храните private chain-of-thought. Храните decision summaries, source references, tool inputs/results и validation outcomes.

Production failure-mode register

Создайте одну строку на каждый failure mode:

| Failure mode | Example | Control | Test | Metric | Owner | Stop condition | | --- | --- | --- | --- | --- | --- | --- | | Stale source | Вернулась старая цена | Source date check | Query old/new pricing | Stale-source answer rate | Docs owner | Любая stale price, видимая клиенту | | Unsafe tool use | Неверное CRM update | Argument validation + confirmation | Duplicate/wrong contact case | Wrong-action rate | RevOps | Одна неверная запись |

Связанный с этой статьей register дает шаблон.

Пока не делайте этого

Не запускайте customer-facing AI без failure-mode register.

Не позволяйте write-capable tools обходить validation.

Не полагайтесь только на manual spot checks после запуска.

Не измеряйте только average quality. Rare failures могут быть всем риском.

Не принимайте "we can roll back", если кто-то не может реально назвать rollback path.

Итог

Production AI systems ломаются повторяющимися способами. Hallucination, stale context, sycophancy, prompt injection, unsafe tool use, schema drift, weak fallback и observability gaps - не edge cases. Это нормальная работа при shipping AI.

Зрелый шаг - назвать failure modes, добавить controls, тестировать их, мониторить и назначить ownership. Демо показывает, что сработало один раз. Failure-mode register показывает, выдержит ли система реальное использование.