ИИ-бот теряет контекст длинного диалога: как проверить историю и краткое резюме

Найдите потерянный факт

Возьмите разговор, где клиент сначала написал «нужна доставка после 18:00», а через десять реплик бот предложил дневной интервал. Отметьте момент, когда условие впервые появилось, и запрос, на котором оно было нарушено. Посмотрите, какие сообщения передавались модели непосредственно перед ошибкой. Если ранней реплики там нет, проблема в формировании контекста. Если она есть, но бот её проигнорировал, проверьте инструкцию и проверку действия.

Не подавайте модели бесконечную сырую переписку: она содержит повторения, исправления и уже отменённые решения. Но и чрезмерно короткое резюме вроде «клиент интересуется доставкой» теряет важный интервал.

Разделите факты по надёжности

Резюме должно сохранять не только данные, но и статус: «клиент попросил», «менеджер подтвердил», «ожидает проверки». Иначе модель может превратить просьбу в обещание компании.

Проверьте связь разговоров

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

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

Тест на двадцати репликах

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

После обновления модели или способа суммаризации повторите этот тест. Руководство OpenAI по агентам рассматривает состояние и инструменты как часть агентной системы; для обслуживания клиентов к этому нужна история изменений фактов. Качество проверяется тем, что клиенту не приходится повторять важные условия.

Что включать в краткое резюме

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

Как обнаружить потерю контекста заранее

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

Что делать с противоречивыми сообщениями

Клиент сначала просит доставку в понедельник, затем пишет «лучше во вторник», а позже «оставим как договаривались». Последняя фраза двусмысленна: она может отсылать к понедельнику или ко вторнику. Резюме не должно молча выбирать дату. Бот уточняет: «Подтвердите, пожалуйста, вторник?» После подтверждения система сохраняет актуальное значение и помечает старые варианты как отменённые. Для важных условий — сумма, адрес, срок — явное подтверждение полезнее догадки по истории.

Такой случай покажет, насколько хорошо система различает сообщение клиента, обещание компании и последующее изменение.

Контекст после передачи оператору

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

Для сообщений с несколькими задачами проверьте также, как бот отвечает на каждый вопрос.