RAG по 11 000 файлов путал артикулы и выдавал данные чужого станка

Бот для отдела продаж, отвечающий по технической документации, ошибается дороже, чем чат поддержки интернет-магазина. Менеджер получает цифру, передаёт её клиенту, и клиент заказывает не тот станок. Именно такой кейс разобран на Хабре: 11 000 файлов техдокументации, больше 100 менеджеров по продажам и RAG-бот, который уверенно называл числа из паспорта соседней модели.

Что известно о кейсе

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

• Корпус: около 11 000 файлов техдокументации.
• Аудитория: более 100 менеджеров по продажам.
• Симптом: бот отвечает уверенно, но берёт параметры из паспорта другого станка.
• Класс проблемы: запросы по артикулу и точному обозначению модели.
• Заявленный результат: автор описывает, что в итоге заработало, с разбором причин.

Почему вектор путает артикулы

Плотные эмбеддинги сжимают фрагмент текста в вектор, который отражает смысл. Для вопроса «какая мощность шпинделя у обрабатывающего центра» это работает хорошо. Для запроса по артикулу вроде «XYZ-4200-B» картина другая. Токенизатор режет такую строку на подслова, а модель эмбеддингов не обязана считать различие между «4200-B» и «4200-D» существенным. В векторном пространстве такие обозначения оказываются соседями.

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

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

Что проверить в своём RAG

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

Первое: гибридный поиск. Лексический индекс вроде BM25 стоит рядом с векторным, а результаты объединяются через Reciprocal Rank Fusion или взвешивание. Точное совпадение строки артикула получает вес, которого у вектора нет.

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

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

Четвёртое: реранкер. Cross-encoder поверх топ-N кандидатов лучше сопоставляет запрос и фрагмент, чем сравнение двух независимых векторов.

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

Для тестирования соберите набор из реальных вопросов с артикулами, включая пары похожих моделей, и считайте долю случаев, когда нужный документ попал в топ-k. Эта метрика покажет проблему раньше, чем её заметит клиент.