Разработка AI-системы конверсационного поиска с контекстным пониманием

Почему конверсационный поиск ломается на живых запросах

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

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

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

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

Эффект от контекстного понимания: метрики и классы отказов

Метрики считаем не по ощущениям, а на эталонном наборе диалогов: несколько сотен реальных обращений, размеченных по шагам — что спросили, что имели в виду и какой ответ считается верным. Прогон идёт на теневом трафике, поэтому доля неудачных ответов измеряется на тех же запросах, что приходят в продукт. Разметку и подсчёт держим на открытом наборе метрик оценки RAGAS — шкала до и после одинаковая, сравнение корректное.

Главный сдвиг виден в структуре отказов, а не в среднем. Класс, где система отвечает на последнюю реплику в отрыве от предыдущих (потерянный референт местоимения, подмена сущности, ответ из уже закрытой ветки разговора), при контекстном понимании сокращается в разы — именно он давал больше всего неудачных ответов в многошаговых диалогах. Отказы «не понял формулировку» остаются, но перестают маскировать потерю контекста и видны отдельно.

Время ответа растёт не линейно: сборка контекста — это отдельный шаг перед поиском. Чтобы удержать бюджет, ограничиваем глубину переранжирования, кэшируем связки «реплика + контекст» и не даём переформулировке разворачиваться в многократный проход. На выходе важнее не среднее, а хвост: разрыв между медианой и худшими ответами сокращается, потому что тяжёлые многошаговые диалоги больше не уходят в самый долгий путь.

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

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

Режимы конверсационного поиска и когда они уместны

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

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

Этапы внедрения: аудит диалогов, схема, настройка, передача

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

1. Аудит диалогов. Выгружаем журналы обращений и размечаем, где поиск теряет контекст: анафора, пропущенное подлежащее, смена темы внутри сессии. На выходе — доля реплик, которым не хватает предыдущей.
2. Схема контекста. Определяем, что живёт в сессии: последние реплики, выделенные сущности, выбранные фильтры. Отдельно — условие сброса, иначе уточнение «нет, не этот» тянет за собой неверный результат.
3. Настройка отбора. Ранжирование, пороги релевантности, приоритет свежей реплики над историей, правила слияния фильтров и разрешения конфликтов между ними.
4. Проверка на живых запросах. Прогон на отложенной выборке реальных диалогов, а не на тестовом наборе: доля попаданий в топ-3 и как часто пользователю хватает второй попытки.
5. Пилот на части трафика. Сравниваем с текущим поиском на одной и той же аудитории и разбираем диалоги, где стало хуже — обычно это смена намерения в середине сессии.
6. Передача регламентов. Схема контекста, инструкция по разметке новых диалогов, дашборд качества и порядок расширения правил силами вашей команды.

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

Что передаём на руки: конфигурации, схемы, регламенты

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

• Конфигурации системы — файлы настроек поиска и ранжирования: веса полей, пороги релевантности, глубина учитываемого контекста диалога, правила разбиения документов на фрагменты. Правятся без изменения кода, с понятным описанием каждого параметра и его влияния на выдачу.
• Схемы потоков данных — путь контента от источника до индекса: загрузка, нормализация, очистка, разметка; отдельная схема прохождения запроса — от формулировки пользователя через уточнение контекста до готового ответа со ссылкой на первоисточник.
• Политики доступа — разграничение ролей и коллекций: какие источники видит каждая группа пользователей, как проверяются права в момент выдачи ответа, как ограничивается цитирование закрытых документов.
• Документация — описание архитектуры и назначения узлов, форматы обмена между ними, инструкция по локальному запуску и типовые неисправности с признаками.
• Регламенты обновления — порядок выката новой ветки модели, перестроения индекса и правки сценариев: какие проверки запускаются до релиза, при каких отклонениях качества релиз откатывается.
• Набор проверочных вопросов с эталонными ответами — по нему после любой правки видно, не просело ли качество на ключевых темах, и в каких именно сценариях.
• Регламент наблюдения — какие метрики смотреть, что считать деградацией качества, кому сообщать о сбое и в каком порядке действовать.

Передача идёт не архивом, а разбором: показываем, где что лежит, вносим первые изменения вместе с вашими инженерами и отвечаем на вопросы по ходу. После этого развитие конверсационного поиска — добавление источников, переобучение ранжирования, новые каналы — не требует возвращаться к нам.

Кейс: как сократили долю неудачных ответов втрое

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

Ломалось на трёх участках. Поиск выдавал статью-«соседа» по теме, оператор уходил в ручной разбор или отвечал наугад — и клиент возвращался с тем же вопросом. В длинных диалогах терялась связь с предыдущими сообщениями, поэтому уточнения приходилось собирать заново.

Что изменили

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

Метрики до и после

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

Чем контекстное понимание отличается от подстановки истории

Подстановка истории диалога — это механическая склейка последних реплик в один запрос. На двух-трёх шагах приём работает, но в многошаговом диалоге даёт потеря контекста: ключевая ранняя реплика вытесняется свежей, и модель отвечает на последнюю фразу, а не на намерение пользователя. Окно растёт, а точность падает — потому что объём истории не равен структуре смысла.

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

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

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

Технические сомнения: терминология, данные, интеграции

Технические специалисты заказчика задают на приёмке одни и те же вопросы — и они справедливы: система работает с их документами и должна вписываться в их контур. Разбираем сомнения, которые звучат чаще всего.

Как ограничиваются домыслы и контролируются источники?

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

Не увидит ли сотрудник документы, к которым у него нет доступа?

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

Сможем ли мы дообучать систему своими силами?

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

Обсудим вашу задачу и вернёмся с планом работ

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

Что нужно от вас для оценки:

• 20-30 настоящих диалогов с ожидаемым ответом — на них проверяем, как система держит историю и уточнения.
• Где лежат данные и как часто меняются: выгрузка, доступ к поисковому индексу или запросы к вашей системе.
• Что нельзя показывать и хранить: правила обезличивания, срок хранения истории диалога.
• Требования к развёртыванию: ваш контур, изолированный сегмент сети или внешняя площадка.

Что вернём в ответ:

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

Опишите задачу в двух-трёх абзацах и приложите примеры запросов — вернёмся с оценкой и планом работ.

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