Как проверять факты в персональном контенте от ИИ

Персональное письмо может звучать убедительно и при этом обещать скидку, которой у клиента нет. Для генеративного ИИ правдоподобное продолжение текста и правильное коммерческое условие — разные вещи. Чем больше вариантов сообщения выпускает команда, тем труднее проверить каждый вручную.

В CRM ошибка затрагивает не только репутацию текста. Клиент рассчитывает на указанную цену, срок доставки или бонус. Поэтому при генерации нужно отдельно управлять фактами, которые компания обязуется выполнить, и формулировками, которые помогают объяснить предложение.

Определите факты с последствиями

Составьте перечень утверждений, для которых недопустима свободная генерация: цена, размер скидки, остаток бонусов, срок, доступность товара, условия доставки и право на предложение. Для каждого назначьте источник, владельца и допустимую давность данных.

Например, цена берётся из расчёта предложения для конкретного рынка, а не из описания товара на старой странице. Срок доставки определяется адресом и действующими условиями. Имя клиента тоже требует осторожности: отсутствие имени лучше обработать нейтральным обращением, чем попытаться восстановить его по адресу почты.

Такой подход оставляет пространство для хорошего текста, но не поручает модели создавать условия бизнеса. Если факт недоступен, система использует заранее разрешённый вариант без этого обещания либо блокирует сообщение.

Не считайте поиск гарантией истины

RAG — подход, при котором перед ответом модель получает найденные документы или фрагменты данных. Он помогает опереться на сведения компании. Но найденная информация может быть устаревшей, относиться к другой стране или противоречить действующему предложению. Модель также способна неверно её пересказать.

Профиль рисков генеративного ИИ NIST рассматривает уверенное создание неверных сведений как отдельную проблему и рекомендует проверять результаты, источники и условия применения. Наличие ссылки в ответе само по себе не доказывает корректность утверждения.

Практическое применение CRM Lab — передавать в генерацию не произвольную подборку документов, а утверждённую карточку предложения. В ней нужны идентификатор, версия, рынок, применимость к клиенту и срок актуальности. Актуальность товарного каталога контролируется отдельно: даже правильный текст перестанет соответствовать действительности, если исходные данные запаздывают.

Проверяйте готовое сообщение

Проверка только черновика оставляет пробелы. Ошибка может возникнуть при подстановке валюты, форматировании числа, обрезке строки или сборке нескольких блоков. Проверять нужно результат после персонализации и подготовки к отправке.

Условный пример. В карточке акции разрешена скидка 10% на определённую категорию. Модель написала «минус 10% на всё», а шаблон добавил корректный срок. Наличие правильной цифры не делает сообщение верным: изменился охват предложения. Проверка должна сопоставлять и размер выгоды, и условия её получения.

Часть правил проверяется программно: допустимая валюта, срок, идентификатор предложения, наличие обязательной строки. Смысловые обещания сложнее. Для них полезны ограниченные шаблоны и редакторская проверка. Вторая модель может помогать искать расхождения, но не должна становиться единственным судьёй собственного процесса генерации.

Соберите набор трудных случаев

Проверяйте не только типичного клиента с заполненным профилем. Включите отсутствующее имя, несколько валют, завершившуюся акцию, нулевой бонусный баланс, товар без остатка и клиента, которому предложение недоступно. Добавьте длинные названия и неоднозначные описания товаров.

Отдельно проверьте границу срока. Сообщение подготовили до завершения акции, но очередь отправила его позднее. Если обещание уже нельзя выполнить, повторная проверка перед отправкой должна остановить или заменить такой вариант.

Используйте примеры на всех языках, с которыми работает команда. Удачная проверка русской версии не подтверждает, что другой язык сохранил ограничение «до» перед размером скидки. После изменения модели или инструкции набор повторяют, а обнаруженные ошибки превращают в новые проверочные случаи.

Назначьте правила выпуска

Не скрывайте критические ошибки за средней оценкой качества. Если из 200 проверенных сообщений два содержат неправильную цену, формулировка «99% текстов качественные» недостаточна для решения о запуске. Компания заранее определяет, какие ошибки блокируют выпуск и какой объём ручной проверки нужен для конкретного сценария.

Сохраняйте версию исходного предложения, инструкции и итогового текста, чтобы ошибку можно было воспроизвести. Проверка перед отправкой должна охватывать и содержание, и бизнес-условия. Экономию от генерации считайте после включения этих проверок в полный рабочий цикл.

Хороший результат — сообщение, в котором персональность не снижает надёжность обещания. Клиент может не заметить, как удачно система выбрала формулировку, но обязательно заметит скидку, которую ему отказались предоставить.

Источники

National Institute of Standards and Technology. Artificial Intelligence Risk Management Framework: Generative Artificial Intelligence Profile. NIST AI 600-1. July 2024. DOI: 10.6028/NIST.AI.600-1.