Клиент спрашивает, можно ли перенести остаток лимита на следующий месяц. AI уверенно отвечает: «Да, перенос выполняется автоматически». Ответ звучит профессионально, но правило отменили две недели назад. В журнале видно, что модель нашла старую инструкцию, не заметила дату окончания и составила из неё убедительный текст.
Такой инцидент нельзя исправить просьбой «отвечай точнее». Ответ — результат цепочки: контекст клиента, поиск, выбор документа, проверка свежести, генерация, политика отправки и эскалация. Ошибка на любом этапе выглядит для клиента одинаково, но требует разного ремонта.
Коротко: почему AI отвечает уверенно, но неправильно
Языковая модель оптимизирует продолжение текста, а не истинность бизнес-факта. Если ей дали неподходящий фрагмент, конфликтующие инструкции или недостаточный контекст, она может оформить ошибку так же гладко, как правильный ответ.
Надёжная система не спрашивает модель, «уверена ли она». Она проверяет, есть ли разрешённый источник, относится ли он к вопросу, действует ли его версия, подтверждает ли фрагмент каждое существенное утверждение и допускает ли политика автоматическую отправку. Если доказательств недостаточно, ответ превращается в уточнение или передаётся оператору.
Сначала воспроизведите неправильный ответ
Без воспроизводимости команда спорит о формулировках и случайно меняет prompt. Для конкретного инцидента нужен evidence package:
- исходное сообщение и история диалога на момент ответа;
- идентификатор клиента, продукт, тариф и права, переданные системе;
- поисковый запрос и фильтры базы знаний;
- найденные документы, их версии, даты и оценки релевантности;
- фрагменты, реально переданные модели;
- системные инструкции и версия prompt;
- модель, параметры генерации и структурированный результат;
- сработавшая политика отправки или эскалации;
- финальный текст, который увидел клиент.
Если пакет нельзя собрать по одному trace ID, система не готова к управляемой поддержке. «Мы не смогли повторить» означает, что причина останется и появится в другом диалоге.
Шесть разных причин одного плохого ответа
1. Не хватило контекста клиента
Ответ верен для одного тарифа и неверен для другого. Вопрос относится к конкретному заказу, а система видит только текст. Исправление — не больше общих инструкций, а явная модель контекста: продукт, версия, регион, договор, роль пользователя и состояние операции.
2. Поиск выбрал не тот фрагмент
Документ существует, но retrieval поднял соседнюю статью из-за совпадения слов. Нужно оценивать не только наличие источника, но и соответствие вопросу. Отдельно тестируют запросы с одинаковыми терминами и разным бизнес-смыслом.
3. Источник устарел
В базе лежат две инструкции без дат действия. Модель не знает, какая главнее. У документа должны быть владелец, статус, версия, дата вступления, дата окончания и область применимости. Устаревшая страница исключается из production-поиска, а не снабжается примечанием внизу.
4. Инструкции конфликтуют
Регламент говорит одно, продуктовая заметка — другое, операторский скрипт — третье. Система должна иметь иерархию источников и обнаруживать конфликт. Склеивать противоречивые фрагменты в один ответ нельзя.
5. Модель исказила найденное
Фрагмент подходит, но генерация добавила неподтверждённое исключение или изменила условие. Ответ разбивают на проверяемые утверждения и сопоставляют с цитатами. Для критичных тем используют шаблон, который не позволяет выходить за доказанные поля.
6. Неправильно сработала маршрутизация
Система увидела низкую доказательность, но всё равно отправила ответ. Это уже не retrieval и не generation, а ошибка policy gate. Порог автоматической отправки должен учитывать тему, риск, наличие источника и полноту контекста.
Доказательность и уверенность — разные оси
| Источник | Соответствие вопросу | Режим |
|---|---|---|
| Актуальный и однозначный | Высокое | Ответ по утверждённому формату |
| Актуальный | Среднее | Уточнить продукт, ситуацию или параметр |
| Несколько конфликтующих | Любое | Не отвечать автоматически, передать владельцу знания |
| Устаревший или без владельца | Высокое по тексту | Исключить источник и эскалировать |
| Источника нет | Любое | Честно сообщить об отсутствии данных и передать оператору |
Высокая языковая уверенность не заменяет источник. И наоборот: наличие документа не доказывает, что найден нужный фрагмент. Эти сигналы хранят и измеряют раздельно.
База знаний должна быть production-системой
RAG не исправляет плохое управление знаниями. Документы проходят жизненный цикл: черновик, проверка, публикация, изменение, отзыв и архив. В production-индекс попадают только разрешённые версии. Для каждой страницы определены владелец и дата следующего пересмотра.
Метаданные не декоративны. По ним поиск фильтрует:
- продукт и версию;
- регион или юридическое лицо;
- роль читателя;
- дату действия;
- тип источника и приоритет;
- уровень доступа;
- статус публикации.
Документация Microsoft и Google Cloud описывает retrieval-augmented generation как отдельный контур извлечения и формирования ответа. Для поддержки это принципиально: retrieval, generation и routing должны иметь собственные метрики и владельцев.
Архитектура проверяемого ответа
Канал передаёт сообщение и идентификатор диалога. Контекстный сервис получает только разрешённые данные клиента. Query builder формирует поисковый запрос и фильтры. Retrieval возвращает фрагменты вместе с версиями и оценками. Evidence checker проверяет свежесть, конфликт и покрытие вопроса.
Генератор создаёт структурированный ответ: текст, список утверждений, ссылки на фрагменты, недостающие данные и рекомендуемый режим. Policy gate решает, можно ли отправить ответ, нужно ли уточнение или оператор. Отправляющий сервис не принимает свободный вызов модели — только разрешённый результат политики.
Журнал связывает весь путь. Концепция traces в OpenTelemetry помогает увидеть задержку и результат каждого шага. Для инцидента важны не только логи ошибок: неправильный ответ технически часто завершился со статусом 200.
Что даёт кейс Morgan Stanley
В опубликованном OpenAI материале Morgan Stanley описывает использование evals для развития AI-систем в финансовых сервисах. Для клиентской поддержки важен процесс: качество проверяется на наборах задач и переоценивается после изменений системы.
Это не означает, что банковские метрики или пороги подходят другой компании. Переносимая часть — дисциплина: фиксированные эталонные вопросы, критерии проверки, версии набора и обязательный regression test после изменения модели, prompt или базы знаний.
Почему обычный «процент правильных ответов» обманывает
Один общий показатель смешивает простые справочные вопросы и редкие критичные ситуации. Система может хорошо отвечать про часы работы и ошибаться в возвратах, доступах или договорных условиях. Оценку делят по теме и цене ошибки.
| Слой | Метрика | Что означает сбой |
|---|---|---|
| Контекст | Полнота обязательных полей | Система отвечает без продукта, тарифа или состояния |
| Retrieval | Recall@k и релевантность фрагмента | Нужный источник не найден или выбран соседний |
| Свежесть | Доля ответов по действующей версии | В индекс попали отозванные знания |
| Доказательность | Покрытие утверждений источниками | Текст содержит добавленные моделью факты |
| Routing | Точность автоответа и эскалации | Опасный случай прошёл без человека |
| Клиентский результат | Повторное обращение и исправление | Ответ не решил задачу или создал новую проблему |
Опасные способы «починить» ответы
Увеличить prompt. Длинная инструкция не исправит устаревший источник и может создать новые конфликты.
Добавить больше документов. Без владельцев и метаданных растёт шум, а не знание.
Попросить модель привести ссылку. Ссылка может быть нерелевантной. Проверяется фрагмент, версия и поддерживаемое утверждение.
Снизить температуру. Ответ станет стабильнее, но стабильно неверный контекст останется неверным.
Отключить эскалацию ради скорости. Среднее время ответа улучшится, а цена ошибок вырастет.
Учиться на каждом ответе оператора автоматически. Оператор тоже может ошибиться. Исправление проходит проверку владельца знания, прежде чем попадёт в production-индекс.
Передавать в prompt скрытые инструкции вместе с клиентским текстом. Пользовательский ввод считается недоверенным. Риск prompt injection описан в OWASP; права и policy gate не должны зависеть от свободного текста.
Набор метрик для еженедельного разбора
- доля автоответов с разрешённым источником;
- доля существенных утверждений, покрытых фрагментами;
- ответы по просроченным или отозванным документам;
- конфликты источников и время их разрешения;
- исправления оператором по типу причины;
- повторные обращения после ответа AI;
- ошибочные автоответы, которые должны были эскалироваться;
- лишние эскалации безопасных вопросов;
- регрессии после изменения модели, prompt и индекса;
- время воспроизведения конкретного инцидента.
Метрики связывают с владельцами. Команда базы знаний отвечает за свежесть и конфликты, ML/AI-команда — за retrieval и generation, владелец поддержки — за правила автоответа и клиентский результат.
Runbook: что делать после неверного ответа
- Остановите повторение ущерба. Отключите автоответ для конкретной темы или источника, не выключая всю систему без необходимости.
- Сохраните trace. Контекст, retrieval, версии, prompt, output и policy result.
- Классифицируйте причину. Контекст, поиск, свежесть, конфликт, генерация или routing.
- Исправьте слой-владелец. Не маскируйте retrieval-ошибку дополнительной фразой в prompt.
- Добавьте инцидент в regression set. Включите соседние формулировки и граничные случаи.
- Проверьте исправление на отложенной выборке. Убедитесь, что новый фильтр не ухудшил другие темы.
- Верните автоматизацию поэтапно. Сначала теневой режим, затем выборочная проверка, после — разрешённые классы.
Вопросы, которые возникают у команды
Можно ли полностью исключить галлюцинации?
Нельзя гарантировать идеальную генерацию, но можно не позволять неподтверждённому утверждению попасть клиенту. Для этого нужны источники, проверка покрытия и policy gate.
Достаточно ли показывать клиенту ссылки?
Нет. Ссылка должна вести к действующему источнику, а конкретный фрагмент — подтверждать конкретное утверждение. Список документов сам по себе не делает ответ верным.
Что делать, если источники конфликтуют?
Не просить модель выбрать «наиболее вероятный». Ответ блокируется, конфликт получает владельца, а клиенту сообщается, что вопрос уточняется.
Как часто запускать evals?
Перед релизом и после каждого значимого изменения модели, prompt, chunking, поисковых фильтров или базы знаний. Критичные наборы дополнительно запускают регулярно.
Нужен ли оператор для каждого ответа?
Нет. Оператор нужен там, где недостаточны доказательства, высока цена ошибки или требуется действие с полномочиями. Остальные классы можно автоматизировать после проверки.
Что помогает мне проверить ответ
Архитектура retrieval сверена с документацией Microsoft и Google Cloud, управление риском — с NIST AI RMF, безопасность пользовательского ввода — с OWASP, трассировка — с OpenTelemetry. Кейс Morgan Stanley используется как подтверждение практики evals, а не как обещание идентичных результатов в другом бизнесе.
Источники и методическая база
- Retrieval augmented generation (RAG) in Azure AI SearchMicrosoft Learn
- Vertex AI RAG Engine overviewGoogle Cloud
- Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence ProfileNIST
- AI Risk Management Framework (AI RMF 1.0)NIST
- LLM01: Prompt InjectionOWASP GenAI Security Project
- AI Agent Security Cheat SheetOWASP Cheat Sheet Series
- Telegram Bot APITelegram
- Webhooks API GuideHubSpot Developers
- OpenTelemetry tracesOpenTelemetry
- Morgan Stanley uses AI evals to shape the future of financial servicesOpenAI