У компании меняются условия услуги, менеджер знает об этом, а ИИ-агент продолжает повторять старую формулировку. В такой ситуации недостаточно дописать «отвечай точно». Нужно проверить, из какого источника взят ответ, к какой версии он относится и что делать при отсутствии нужного факта.
Ниже - метод подготовки базы знаний для делового диалога. Он подходит для работы над инструкциями и сценариями, но не обещает, что конкретный сервис поддерживает загрузку документов, поиск по ним или автоматическую проверку цитат. Доступные функции нужно проверять отдельно.
Разделите факты, правила и разрешённые действия
В базе фактов храните сведения о продукте: состав услуги, ограничения, географию, условия оплаты и порядок поддержки. В правилах ответа - как действовать при неизвестном вопросе, конфликте источников или просьбе о персональном условии. Права на действия задавайте отдельно: знание порядка возврата ещё не даёт агенту разрешения проводить возврат.
Такое разделение помогает понять причину ошибки. Агент может получить устаревший факт, не найти актуальный документ либо выйти за пределы разрешённого действия. Добавление ещё одного абзаца в общий промпт не всегда исправляет нужный слой.
Если система использует RAG, она извлекает подходящие материалы и передаёт их модели перед ответом. Google Cloud рекомендует отдельно оценивать работу поиска и генерации на повторяемом наборе вопросов. Само наличие поиска по документам не подтверждает точность каждого ответа.
Сделайте карточку одного проверяемого факта
Вместо большого файла с презентациями начните с небольшой таблицы. Ниже предложен редакционный шаблон: поля можно адаптировать к своему продукту и способу хранения.
| Поле | Зачем нужно |
|---|---|
| Код факта | Постоянная ссылка на запись при разборе ошибки |
| Тема и вопрос | По каким формулировкам искать ответ |
| Утверждённый факт | Одна законченная мысль без рекламных обещаний |
| Условия применимости | Для какого продукта, региона или периода он верен |
| Источник | Документ и конкретный раздел, подтверждающий запись |
| Версия и дата проверки | Как отличить актуальную запись от старой |
| Ответственный | Кто имеет право подтвердить изменение |
| Действие при пробеле | Уточнить вопрос или передать сотруднику |
Одна запись не должна одновременно описывать все тарифы, исключения и будущие планы. Разбейте её по смыслу. Если важное ограничение отделить от соответствующей услуги, агент может извлечь цену без условия её применения.
Пример структуры записи, без вымышленных условий реальной компании:
Код: delivery.region
Вопрос: В какие города доступна услуга?
Факт: Утверждённый список из действующей страницы условий.
Граница: Не обещать обслуживание города, которого нет в списке.
Источник: Ссылка на страницу и название раздела.
При неизвестном городе: Уточнить у ответственного сотрудника.Подготовьте источник к использованию
Проверьте, что у документа есть название и понятная область действия. Страница «Условия для партнёров» не должна незаметно становиться источником правил для всех клиентов. Если действует несколько редакций договора, их нельзя складывать в один текст без обозначения различий.
Для таблиц сохраняйте названия колонок и единицы измерения. Число без валюты, срока или условия легко превращается в неверное обещание. Уберите дубли и черновые обсуждения из набора утверждённых материалов, но сохраните историю изменений отдельно.
Если документ сканированный, проверьте результат распознавания вручную: особенно суммы, отрицания, даты и сноски. Ошибка в слове «не» способна изменить смысл условия сильнее, чем потерянный абзац общего описания.
Проверяйте утверждение, а не наличие ссылки
Ссылка рядом с ответом ещё не означает, что источник подтверждает всю фразу. Агент может правильно назвать услугу и добавить отсутствующую гарантию. Такой ответ частично опирается на документ, но в деловом диалоге остаётся неверным.
В документации Google Cloud о проверке grounding различаются утверждения ответа и факты, которые их поддерживают. Для ручной редакторской проверки применим тот же вопрос: какой конкретный фрагмент подтверждает каждое существенное утверждение?
Составьте проверочную таблицу из четырёх колонок: вопрос клиента, ответ агента, подтверждающий фрагмент и решение проверяющего. Отдельно отмечайте неподтверждённые числа, условия и обещания. Если в документе написано «срок уточняется», ответ с точной датой не проходит проверку, даже когда рядом стоит правильная ссылка.
Соберите тесты на неудобные вопросы
Обычный FAQ проверяет только ожидаемый разговор. Добавьте вопросы с неоднозначным названием продукта, устаревшим условием, просьбой об исключении, отсутствующим фактом и конфликтующими данными.
Для каждого примера определите допустимое поведение. Иногда правильный ответ - уточняющий вопрос. Иногда - передача менеджеру. Нельзя оценивать качество только по тому, как часто агент даёт законченный ответ: уверенное выдумывание тоже выглядит законченно.
Начать можно с ограниченного рабочего набора и расширять его по реальным ошибкам. Количество вопросов в таком наборе - решение команды, а не универсальный порог качества. Сохраняйте эталонные ответы и отмечайте критичность ошибки: неверное приветствие и выдуманное финансовое условие требуют разной реакции.
После изменения источников прогоняйте тот же набор повторно. Если одновременно переписать вопросы, сменить модель и изменить документы, будет трудно понять, что именно повлияло на результат.
Не давайте внешнему тексту менять правила агента
Документ, веб-страница или сообщение клиента могут содержать фразу, похожую на команду: например, требование игнорировать прежние ограничения. Такой текст должен оставаться входными данными, а не получать права администратора.
OWASP описывает прямые и косвенные prompt injection и подчёркивает, что RAG не устраняет этот риск полностью. Для рабочего процесса это означает несколько отдельных мер: ограничить доступные действия, проверять формат результата и передавать существенные операции через контролируемые правила приложения.
Не помещайте в общую базу пароли, ключи API или чужую переписку только потому, что так проще собрать контекст. Разделяйте публичные ответы, внутренние инструкции и данные конкретного клиента. Право извлечь материал должно соответствовать правам текущего пользователя и задаче.
Кто и когда обновляет базу
Назначьте владельца каждой темы. При изменении условия он обновляет основной источник, связанные карточки и тестовые ответы. Старые версии отмечаются как недействующие для новых ответов, а не остаются рядом без пояснения.
В журнале ошибок полезно хранить время, вопрос, использованную версию источника, существенный неверный фрагмент и принятое исправление. Перед сохранением удаляйте ненужные персональные данные. После исправления повторите тест, который обнаружил проблему.
При подготовке сценария KUZKO этот материал можно использовать как чек-лист для описания бизнеса и утверждённых ответов. Возможности конкретного кабинета проверяйте по руководству настройки. Критерий готовности простой: сотрудник может открыть источник и объяснить, почему агенту разрешена именно эта формулировка и где проходит граница его полномочий.