Клиент спрашивает, сколько стоит товар и есть ли он в наличии. ИИ-продавец отвечает быстро, вежливо и с той степенью уверенности, которая обычно убеждает лучше любого менеджера. Вскоре выясняется: цена в товарной системе уже другая, остаток обнулился, а клиент сохранил скриншот с прошлой суммой. Дальше начинается не техническая проблема, а коммерческая: обещание придётся отменять, согласовывать или закрывать скидкой.
Это собирательная сцена, а не подтверждённый кейс конкретной компании. Но она легко воспроизводится: достаточно, чтобы агент один раз взял цену из вчерашнего контекста, старой памяти или кэша и не перепроверил её перед фразой «итого столько-то». По-моему, главная опасность здесь не в том, что модель ошиблась в формулировке, а в том, что она смешала разные типы данных и выдала уверенный ответ там, где требовалась скучная проверка.
Три слоя, которые нельзя смешивать
У ИИ-продавца есть как минимум три разные области, и они живут по разным правилам. Первая — долговременные знания и инструкции: как разговаривать с клиентом, что можно обещать, что нельзя, как маршрутизировать запросы, какой тон использовать. Это относительно стабильная часть, и её действительно можно хранить в памяти агента или в системной инструкции. Вторая — живые бизнес-данные: цена, остаток, скидка, срок доставки, регион, валюта, налоги, условия акции. Здесь всё может меняться без участия агента. Третья — финальная проверка перед обещанием клиенту. Не «когда-то при обучении», не «вчера в кэше», а непосредственно перед сообщением: «итого столько, есть в наличии, доставим тогда-то».
Если эти слои не разделены, агент начинает говорить о цене так, будто это устойчивое знание вроде правил вежливости. Он может быть убедителен, логичен и последователен, но цифра уже устарела. Уверенность в голосе ничего не говорит о свежести данных. Она говорит только о том, что модель хорошо собрала предложение.
Полезно отдельно развести четыре вещи, которые часто называют одним словом «память». Контекст диалога — это то, что клиент уже сказал, какой товар выбрал, какие условия обсуждал. Память агента — устойчивые инструкции, стиль, правила маршрутизации, редко меняющиеся сведения. Кэш — ускоренная копия данных с ограниченным сроком жизни; она может быть полезной, но по определению не гарантирует свежесть. Оперативная база — текущее состояние: цена, остаток, скидка, срок доставки. Проблема начинается там, где цену берут из памяти или кэша без повторной проверки, а потом называют её клиенту как факт.
Технически тут нет ничего нового. Языковая модель не получает автоматически сведения об изменениях после своего обучающего периода: для актуальной информации нужны внешние инструменты, поиск или подключённая база. Цены и наличие товара относятся к данным, для которых кэш может быть неприемлем из-за риска устаревшей информации. Любой кэш считается свежим только в течение заданного срока жизни, после чего ответ требует повторной проверки у исходного сервера. Для часто меняющихся данных предусмотрена повторная валидация: клиент снова обращается к источнику и проверяет, не изменилась ли версия. Всё это не экзотика, а базовая гигиена работы с меняющимися данными. Просто в разговоре про ИИ-продавца её легко потерять за красивым интерфейсом.
Где именно ломается логика
Типовая цепочка выглядит почти безобидно. Клиент спрашивает цену или наличие, агент находит в контексте или памяти недавнее значение, оно выглядит правдоподобно — и отдельный запрос в товарную систему не делается. А там цена уже изменена, остаток обнулён или изменились условия доставки. Агент же формулирует коммерческое обещание, которое компания не готова выполнять.
Ошибка становится дорогой не в момент ответа, а позже. Менеджеру приходится отменять обещанную цену, объяснять расхождение или давать скидку, чтобы сохранить клиента. Иногда добавляется коммерческий и потенциально юридический риск: если агент назвал условия, а компания их не выполнила, спор уже не выглядит как небольшая техническая неточность. Поэтому проверять нужно не только цену, но и связку «цена плюс доступность», а в зависимости от сценария — ещё скидку, регион, валюту, налоги, срок доставки и условия акции. Свежая цена при нулевом остатке всё равно не даёт права обещать продажу.
Здесь есть ещё одна тонкость. Подключение базы само по себе не делает ответ актуальным. Важны частота обновления, срок жизни кэша и момент последней проверки. Если агент обращается к базе, но берёт из неё кэшированную копию недельной давности, формально он «подключён к данным», а фактически торгует воспоминанием. По-моему, именно на этом месте многие настройки выглядят убедительнее, чем работают. В презентации есть интеграция, в реальном диалоге — вчерашняя цифра.
Четыре минимальных правила
Срок актуальности
Для каждого типа данных должен быть понятен допустимый срок жизни. Для справочной страницы каталога может хватить короткого кэша, а перед фиксацией заказа или обещанием скидки нужна проверка непосредственно перед ответом. Универсального срока нет: он зависит от скорости изменения цены, оборота товара, стоимости ошибки и сценария — консультация, корзина или оформление заказа. Ошибка в справочной цене и ошибка в подтверждённом заказе — это разные риски, и правила у них должны быть разные.
Источник истины
Нужно заранее назначить систему, которая считается главной для конкретных сведений. Если цена хранится в товарной системе, агент не должен брать её из старой заметки, памяти или случайного кэша. Если источников несколько, нужно правило, какой из них главный при расхождении. В распределённых системах разные сервисы могут владеть разными частями данных, поэтому «источник истины» — это не бюрократическая формулировка, а конкретный адрес, к которому агент обязан обратиться перед обещанием. Без такого адреса он будет выбирать то, что выглядит правдоподобнее, а не то, что подтверждено.
Журнал ответа
Фиксировать стоит не только финальный текст сообщения, но и то, на каких данных он построен: идентификатор товара, полученные цена и остаток, источник, время запроса, версия ответа, было ли коммерческое обещание и чем закончился сценарий — ответом агента или передачей человеку. Это нужно не для бюрократии, а чтобы потом можно было восстановить причину ошибки. OpenAI Agents SDK поддерживает трассировку генераций, вызовов инструментов и передач между агентами; вопрос не в отсутствии технической возможности, а в том, настроена ли она в конкретной системе. Если в журнале нет источника и времени проверки, разбирательство превращается в гадание.
Эскалация
Если источник недоступен, данные старше допустимого срока или два источника расходятся, агент не должен угадывать. В таком случае он передаёт диалог сотруднику вместе с причиной: «цена не подтверждена», «остаток не получен», «условия скидки требуют проверки». Человек нужен не при каждой мелочи, а при неустранённой неопределённости, конфликте источников, нестандартной скидке или юридически значимом обещании. Это и есть контролируемый handoff: не «агент сломался», а «агент дошёл до границы своих полномочий и передал дальше». В OpenAI Agents SDK handoff описан как передача диалога другому агенту; чтобы он означал передачу сотруднику, нужна отдельная интеграция с рабочей системой. NIST в рамках риск-менеджмента ИИ прямо указывает на необходимость мониторинга и человеческого вмешательства там, где система не способна обнаружить или исправить ошибку. Звучит сухо, но на практике это значит одно: у агента должна быть кнопка «стоп, это решает человек».
Как проверить своего ИИ-продавца
Проверка не требует большого стенда. Возьмите товар, у которого цена и остаток реально меняются в товарной системе, и пройдите короткий сценарий.
- Спросите агента о цене и наличии в обычном диалоге.
- Сразу измените цену или остаток в системе-источнике.
- Повторите тот же вопрос в новом диалоге и в продолжении старого.
- Сравните ответ агента с актуальными данными.
- Посмотрите, сохранился ли в журнале источник, время проверки и сам ответ.
- Отдельно проверьте сценарий, где источник недоступен: агент должен не выдумывать, а эскалировать.
Смысл теста — увидеть, где агент берёт данные: из памяти, из кэша, из товарной системы или из контекста разговора. Если после изменения цены агент продолжает уверенно называть старое значение, проблема не в формулировке ответа, а в отсутствии обязательной проверки перед обещанием. Если он начинает путаться и терять контекст, это другая проблема, но она не отменяет первую. Хороший результат выглядит скучно: агент либо называет подтверждённую цифру, либо честно говорит, что не может подтвердить условия, и передаёт вопрос менеджеру.
Где здесь место подключённым данным
Если агент отвечает клиенту, ему нужны не только хорошие формулировки, но и доступ к актуальным данным, а также понятный сценарий передачи человеку. Здесь и становится видна ценность подключённых данных и контролируемого handoff — не как модных слов, а как конкретных механизмов, которые не дают уверенному ответу превратиться в коммерческую ошибку.
Как возможный пример подхода можно посмотреть на Market-GPT. Речь именно о подходе — о работе с данными и передаче спорного случая человеку, а не о гарантии, что любая подключённая система автоматически проверяет цены и остатки. Если внутри нет источника истины, журнала и правила эскалации, одно подключение ничего не исправит. Но если эти вещи есть, разговор с клиентом перестаёт быть лотереей: он либо получает подтверждённую цену, либо внятное «сейчас уточню».
Память агента полезна для устойчивых правил и стиля общения, но не заменяет живые бизнес-данные. Цена, остаток и условия сделки должны проверяться перед обещанием клиенту, а спорный случай — передаваться человеку. Если бизнес не знает, откуда агент взял цену и когда он её последний раз проверял, значит, процесс ещё не настроен. И никакая убедительная формулировка это не компенсирует.
