В понедельник помощник уверенно сообщил клиенту, что возврат придёт за три дня. В базе знаний было десять рабочих дней. Ответ звучал лучше ответа стажёра, поэтому ошибку заметили только после повторного обращения.
В этом и заключается неприятная особенность жанра: плохой ответ поддержки, написанный человеком, виден сразу — он путаный, с опечатками, с извинениями. Плохой ответ модели гладкий, структурный и вежливый. Его читают как правильный до тех пор, пока клиент не придёт через три дня с вопросом, где деньги.
Сначала режим черновика
Безопасный первый релиз не отвечает клиенту. Он классифицирует тикет, находит документы и готовит черновик оператору. Источники показываются рядом; принятие, правка и отклонение становятся разметкой. Автоответ включают позже для узких классов с низкой ценой ошибки.
тикет -> очистка PII -> классификация -> retrieval с ACL
-> генерация черновика с цитатами -> проверка фактов
-> оператор или автоответ -> outcome через 7 днейclass Draft(BaseModel):
answer: str
source_ids: list[str]
needs_human: bool
reason: str | None
async def prepare(ticket, actor) -> Draft:
docs = await search(ticket.text, tenant=actor.tenant_id, acl=actor.groups)
draft = await llm.structured(prompt="support-v12", ticket=ticket, docs=docs,
schema=Draft)
if not draft.source_ids or ticket.intent in HIGH_RISK_INTENTS:
draft.needs_human = True
return draftИсточники проверяются сервером: каждый source_id должен быть среди выданных retrieval документов. Модель не назначает компенсацию и не меняет заказ. Для таких действий она готовит предложение, а оператор подтверждает его через обычный backend с бизнес-валидацией.
Failure modes
Устаревшая статья ранжируется выше действующей. Клиент вставляет в тикет инструкцию игнорировать правила. Retrieval смешивает tenant. Оператор машинально нажимает «отправить». Метрика средней скорости улучшается, но повторные обращения растут. Поэтому нужны versioned knowledge base, ACL до retrieval, маркировка недоверенного текста, лимит автоматизации и outcome-метрика.
Как расширять автоматизацию
Переход от черновиков к автоответам делается не «когда команда почувствует уверенность», а по правилу, записанному заранее.
Рабочая схема: класс обращений получает право на автоответ, если на нём набралось достаточно черновиков, принятых оператором без правки, доля правок ниже порога, цена ошибки в этом классе мала, а путь эскалации существует и проверен. Каждое расширение — отдельный релиз с откатом (глава 53), а не изменение настроения.
Обратное движение тоже должно быть предусмотрено: рост повторных обращений в классе автоматически возвращает его в режим черновика. Автоматизация, которую нельзя откатить по метрике, держится на честном слове дежурного.
Правило главы
Помощник поддержки получает право отвечать только на тот класс обращений, где источники, цена ошибки и путь эскалации известны заранее.
Чеклист главы
Практикум
Задача 48.1 — draft-only помощник на реальных тикетах. ⭑⭑⭑
Соберите 100 обезличенных тикетов и постройте поток, который готовит черновики, но не отвечает клиенту.
Критерии приёмки:
Подсказки:
- Разметка «итог через семь дней» — самая ценная и самая скучная часть. Без неё вы будете оптимизировать скорость ответа вместо решённости вопроса.
- Время оператора мерьте до внедрения тоже, иначе сравнивать будет не с чем.
Задача 48.2 — первый класс на автоответ. ⭑⭑
Выберите один узкий класс обращений и переведите его в автоответ по заранее записанному правилу.
Критерии приёмки:
Подсказки:
- Лучший первый класс — тот, где правильный ответ короткий, источник один и цена ошибки измеряется минутами, а не рублями.
- Порог возврата в черновики выбирайте до запуска: после запуска любой рост будет казаться случайным.