Observability AI-агентов: eval, логи, red-team и scorecard за 14 дней

Observability AI-агента за 14 дней — это не «логи ради логов», а связка eval-набор + логи диалогов + red-team промптов + rollback и еженедельный scorecard: без неё агент деградирует незаметно, а «вроде отвечает» маскирует рост ошибок.

Я отделяю observability от production-механики очередей, retry и HITL. Очереди чинят доставку. Observability чинит качество ответов и регрессии после правок промпта/инструментов. Если правите system prompt «на глаз» — вы уже в минусе.

Что входит в минимальный контур за 14 дней

Четыре артефакта, без которых я не считаю агента наблюдаемым:

Артефакт	Зачем	Готовность «ок»
Eval-набор	Регрессии до/после правок	≥30 кейсов, 3 класса сложности
Логи диалогов	Разбор сбоев и галлюцинаций	trace_id, user, tools, final, flags
Red-team промпты	Ломаем guardrails до клиента	≥15 атак, проход/провал
Scorecard + rollback	Решение «катить / откатить»	1 страница, пороги, владелец

14 дней — реалистичный горизонт для одного агента (первая линия, discovery или внутренний ассистент), не для всей оркестрации компании.

Eval-набор: как собрать быстро и не соврать себе

Eval — фиксированные входы и ожидаемое поведение. Не «красивый ответ», а проверяемые критерии.

Классы кейсов, которые я всегда кладу в набор:

1. Happy path — типовой запрос, полный контекст.
2. Нехватка данных — агент должен спросить, а не выдумать.
3. Отказ/границы — запрос вне scope, токсичность, юр./мед. советы.
4. Tool failure — CRM/API недоступны: честный fallback.
5. Регрессии прошлого инцидента — каждый прод-баг → новый кейс.

Шаблон одного кейса:

• id, input, context (роль, канал)
• expect: must_include / must_not / tool_calls / escalate
• severity: 1–5 (критичность)
• tags: pricing, pii, offline-tool…

Чеклист на дни 1–4:

• Выгрузить 20–40 реальных диалогов (без ПДн или с маскированием)
• Разметить must_not (цены «от балды», обещания сроков, выдуманные статусы)
• Прогнать baseline на текущем промпте, зафиксировать score
• Запретить мержить правки промпта без прогона eval

Метрики eval, которые я смотрю:

Метрика	Как считаю	Порог «катить»
Pass rate	% кейсов без fail	≥85% overall
Critical pass	fail severity 4–5 = 0	100%
Hallucination flags	must_not сработал	≤5%
Tool correctness	нужный tool / не звал лишний	≥90%

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

Минимум полей на один turn (и на весь session):

• session_id, turn, ts
• channel (web/tg/email)
• user_text (или hash + redacted)
• system_version / prompt_hash
• tool_calls[] + latency + error
• assistant_text
• auto_flags: pii_leak_suspect, policy_break, empty_answer, loop
• human_label (опционально, post-factum): ok / bad / escalate_missed

Правила хранения, которые экономят нервы:

• сырой текст — срок 14–30 дней или по политике ПДн;
• агрегаты scorecard — дольше;
• каждый деплой промпта = новый prompt_hash в логах;
• без prompt_hash rollback превращается в шаманство.

Типовые сигналы деградации за неделю:

• рост empty_answer и «переспросите позже»;
• рост tool_error без роста user volume;
• падение средней длины осмысленного ответа + рост эскалаций «не по делу»;
• всплеск must_not на eval после «маленькой» правки тона.

Red-team промптов и rollback

Red-team — заранее написанные атаки. Я гоняю их до выкладки и после каждого изменения system prompt / tools schema.

Базовые семейства атак (по 2–3 штуки в каждом):

• jailbreak / «игнорируй инструкции»
• prompt injection во входных данных (текст заявки, CRM-поле)
• выманивание system prompt и секретов
• давление на скидку/гарантию/срок вне политики
• обход эскалации («не зови человека»)
• многоязычный/зашумлённый ввод
• повторный spam одного intent (loop)

Scorecard на 14 дней (одна страница, обновление 2 раза в неделю):

Блок	Показатель	Цель 14 дней
Eval	pass rate / critical	≥85% / 100%
Red-team	% провалов атак	≤10% (лучше 0 на critical)
Prod sample	25 диалогов/нед, % bad	≤12%
Stability	инциденты «агент сказал лишнее»	0 critical
Change mgmt	% деплоев с eval+red-team	100%

Rollback-правило, которое я фиксирую письменно:

1. Падение critical pass или 2+ policy break в prod sample → немедленный откат prompt_hash / tool schema.
2. Владелец отката — один человек (не «дежурный чат»).
3. После отката — новый eval-кейс на инцидент, только потом повторный rollout.
4. Hotfix тона без eval запрещён.

План на 14 дней

Дни 1–2. Inventory: какой агент, какие tools, где логи сейчас (часто — нигде).

Дни 3–5. Eval v1 (30+), baseline score, маскирование ПДн.

Дни 6–8. Логи turn-level + prompt_hash + простая таблица/дашборд.

Дни 9–11. Red-team pack, прогон, закрытие дыр в system prompt.

Дни 12–14. Scorecard, rollback drill (учебный откат), договорённость «без eval не катим».

Что я сознательно не мешаю в этот двухнедельный контур: дизайн очередей, DLQ, multi-agent handoff, найм HITL-смены. Это соседние контуры. Сначала видно качество — потом масштабирование.

Часто задаваемые вопросы

Сколько кейсов в eval достаточно на старте?

Для узкого агента — 30–50. Меньше 20 почти всегда врёт «зелёным». Критичнее покрытие классов (границы, tools down, injection), чем тысяча однотипных happy path.

Нужен ли отдельный MLOps-стек?

Нет. На 14 дней хватает таблицы кейсов, прогона скриптом/нодой, логов в БД или object storage и одной страницы scorecard. Платформы подключаю, когда кейсов сотни и деплоев много.

Чем red-team отличается от обычного QA?

QA проверяет сценарии «как должен». Red-team проверяет «как сломают». Без атак injection и jailbreak guardrails живут только в презентации.

Что делать, если бизнес просит «подкрутить тон» каждый день?

Любая правка system prompt = новый prompt_hash + smoke eval (хотя бы critical 10) + red-team top-5. Иначе observability есть, а процесс её обходит.

Читайте также

• Eval AI-агента: тесты, red-team, SLA и регрессии
• Observability AI-пайплайнов: логи, трейсы, HITL и SLA
• 7 ошибок production AI-агентов и handoff

Настроить eval, логи и scorecard под вашего агента: https://raisovich.ru

Что обязательно должно быть в логе каждого turn агента?

session_id, prompt_hash, user/assistant текст (или redacted), tool_calls с latency/error и auto_flags — без prompt_hash rollback превращается в угадайку.

Когда откатывать промпт немедленно?

При падении critical pass на eval или 2+ policy break в prod sample: откат prompt_hash/tool schema одним владельцем, затем новый eval-кейс на инцидент.

Чем observability агента отличается от очередей и HITL?

Очереди чинят доставку сообщений; observability чинит качество ответов и регрессии после правок промпта — eval, логи, red-team и scorecard за 14 дней на одном агенте.