Два клиента у одного ИИ-продавца: почему память модели не защищает от путаницы
Два клиента пишут почти одновременно. У одного имя совпадает с тем, кто уже был в базе, у другого телефон похож на номер из старой сделки. ИИ-продавец должен ответить каждому так, будто перед ним отдельная история: не перепутать, кто на каком этапе, что уже обещано, что менеджер поправил вручную. Звучит как задача на внимательность. На деле это задача на устройство данных.
Главная защита здесь — не хорошая память модели, а строгая идентичность каждого лида и история событий. Модель может складно продолжить разговор и при этом уверенно уехать не в ту сторону, если ей подсунули чужой контекст. Чем убедительнее ответ, тем неприятнее ошибка: клиент видит не сбой системы, а странную невнимательность.
Память модели не равна идентичности клиента
Контекст ИИ — это то, что подано модели в конкретный момент: сообщения, поля, прошлые реплики, результаты инструментов. OpenAI Responses API умеет хранить состояние диалога: в документации объект conversation описан как поток элементов, включая сообщения и результаты вызовов инструментов. Это удобный механизм, но он отвечает на вопрос «что модель видела», а не на вопрос «чей это клиент».
Разница принципиальная. Можно держать длинный, связный, насыщенный контекст и всё равно не знать, к какой записи в CRM он относится. Если в один контекст попадают обрывки двух историй, модель рискует выбрать более правдоподобную линию и достроить её. В художественном тексте это назвали бы воображением, в продажах — ошибкой адресации.
Поэтому в проектировании логичнее отталкиваться не от «пусть модель запомнит получше», а от «пусть система знает, чей это диалог, и не смешивает источники». Память — полезная надстройка, идентичность — несущая конструкция.
Лид, запись и событие — разные вещи
Здесь легко наделать путаницы из хороших побуждений. Человек, клиент, CRM-запись, лид, диалог и отдельное событие — разные сущности. Один человек может быть клиентом в двух сделках, один телефон — общим для семьи, один лид — иметь несколько диалогов. Если всё это слить в «карточку клиента», система рискует принимать решения по нечётким признакам.
Опора нужна устойчивая: идентификатор лида, к которому привязываются сообщения, решения и обновления. В проектной схеме его можно обозначить как lead_id. Это требование к системе, а не утверждение, что в Market-GPT он уже устроен именно так: реализацию нужно подтверждать отдельно, по схеме данных и фактическому процессу.
В HubSpot, например, у CRM-записи есть внутренний ID, и API позволяет читать её по этому ID или по уникальному пользовательскому свойству. Имя и телефон здесь — признаки для поиска, но не доказательство идентичности. Совпадение помогает найти кандидата. Оно не даёт права переносить на него старую историю.
Отдельная тонкость — идентификаторы событий. HubSpot предупреждал, что повторное использование ID для разных событий может создавать неоднозначность: события рискуют отобразиться не на тех CRM-записях. Урок простой: уникальность нужна не только у лида, но и у каждого события в его истории. Иначе журнал рискует превратиться в корзину, где вроде всё есть, но непонятно, что к чему относится.
Границы контекста
Собирать контекст под конкретный лид — это не бюрократия, а способ не дать модели лишнего. В ответ должны попадать сообщения этого диалога, актуальные поля и данные, которые подтвердил менеджер. Чужая переписка, старые выводы по другому лиду и общий «дух» предыдущего разговора — не материал для ответа.
Это и есть изоляция лидов на уровне данных: не «модель ничего не помнит», а «каждый диалог собирается из данных только одного лида». У контекста должен быть владелец: идентификатор лида, версия сборки и время, на которое эти данные актуальны. Если система не может уверенно определить, к какому лиду относится сообщение, лучше остановиться на уточнении, чем строить уверенный ответ на догадке. Это выглядит менее эффектно, зато не приводит к тому, что клиенту пересказывают чужую договорённость.
Практическая проверка здесь простая. Можно ли по логу ответа понять, какие именно данные были поданы модели и к какому лиду они привязаны? Если нет, разговор о «памяти» становится гаданием. Если да, появляется возможность разбирать ошибки не по ощущениям, а по цепочке событий.
Когда результат менеджера устарел
Отдельная проблема — устаревший вывод. Менеджер изменил статус, добавил комментарий или закрыл задачу, а ИИ-продавец отвечает по старой картине. Дело не в памяти модели, а в устаревших данных.
Нужен понятный триггер обновления: событие изменения, отметка времени, версия результата. В проектировании это требование, а не украшение. Но конкретный срок для Market-GPT нельзя называть, если он не подтверждён. «Сразу» — красивое слово, которое ничего не говорит о системе. Куда честнее назвать момент, в который результат пересобирается, и источник, из которого берутся данные.
Есть и неидеальные места, которые не стоит прятать. Обновление может запаздывать, ручная правка может конфликтовать с автоматикой, параллельные события могут создавать гонку: два изменения пришли почти одновременно, и порядок их применения важен. Это инженерная работа, а не магия. Свежесть результата — параметр системы, который нужно проверять, а не пожелание в презентации.
Почему старый исход нельзя переносить на новый диалог
Правило безопасности звучит скучно: даже если совпало имя, телефон или тема, старый исход не наследуется автоматически. Новый диалог — это новый лид или как минимум новая проверенная привязка. Скучным оно остаётся ровно до первого случая, когда клиенту приписывают старый отказ, старую квалификацию или чужую договорённость.
Со стороны это выглядит как невнимательность. По сути это ошибка идентичности: система приняла похожесть за доказательство. И чем аккуратнее она сформулировала ответ, тем труднее заметить подмену — ни сбоя, ни красной рамки, просто человеку пересказали не его историю.
Можно возразить, что правило избыточно и заставит лишний раз уточнять. Да, заставит. Но уточнение стоит одного вопроса, а тихая правдоподобная путаница — доверия к каналу. При сомнении лучше уточнить, а не перенести.
Что это значит на практике
Если собрать инженерные опоры в короткий список, получится примерно так:
- устойчивый идентификатор лида, к которому привязаны сообщения и решения;
- отдельная история событий с уникальными идентификаторами;
- версия и время контекста, поданного модели;
- явный триггер обновления результата менеджера;
- запрет на перенос старого исхода по нечётким признакам;
- логирование того, что именно было подано модели.
Это не аудит готового продукта. Часть пунктов может быть уже реализована, часть проектируется, часть остаётся гипотезой. В тексте о проектировании честнее держать такие маркеры, чем делать вид, что схема собрана и проверена на всех сценариях. Если подтверждения нет, формулировка меняется: не «в Market-GPT это работает так», а «в проектировании есть такое требование». Читатель должен видеть, где заканчивается принцип и начинается разговор о конкретном продукте.
Эта статья — не обзор готового продукта, а разбор проектных решений, важных для инженерной работы над Market-GPT. Если нужен практический контекст, а не только схема, можно посмотреть, как Market GPT подходит к работе с клиентами и точкам роста: market-gpt.ru. Без обещаний, что продукт уже закрывает описанную проблему целиком.
Вернусь к сцене. Два клиента, два потока сообщений, один ИИ-продавец. Хорошая модель может написать убедительный ответ, но убедительность не равна правильной адресации. Если система не знает, чей это диалог, лучше задать уточняющий вопрос, чем уверенно продолжить чужую историю. Доверять ИИ-продавцу можно не тогда, когда он складно говорит, а когда можно проверить, к какому лиду относится каждое его слово.
