Почему RAG путает похожие модели товаров и как мы исправили поиск

Для агента первой линии «почти правильный» ответ хуже, чем отсутствие ответа. Если клиент спрашивает про свою кофемашину, а получает уверенную инструкцию к соседней модели, он либо сделает что-то не так с техникой, либо перестанет доверять компании.

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

Почему агент отвечал по инструкции к другой модели

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

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

Как мы исправили поиск по базе знаний

Мы сделали два изменения.

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

Второе касается логики агента. Прежде чем искать ответ, агент определяет, о какой модели идёт речь. Если клиент её не назвал, агент уточняет. Поиск и генерация ответа идут только после этого и только по документации нужной модели.

По итогам точность ответов выросла на 15–20%.

Что делать, если в каталоге много похожих товаров

Главный вывод выходит за рамки поддержки. Когда документы почти одинаковы, одного совпадения по смыслу недостаточно. Различия между товарами нужно закладывать явно: в данных (модель, артикул, ключевые характеристики в метаданных) и в сценарии диалога (сначала установить, о каком товаре речь, потом отвечать).

В продажах задача немного другая: клиент может ещё не знать, какую модель выбрать. Если в каталоге 15 холодильников или 20 телевизоров, агент должен сначала выяснить его потребности и только затем искать среди подходящих товаров, а не выдавать первый похожий.

Попробовать NaimiAI

Создайте первого ИИ-агента на триале NaimiAI и проверьте, как агент работает с вашей базой знаний и каталогом. Актуальные условия доступны на странице «Тарифы».