RAG без хайпа: когда он нужен и как не испортить поиск

RAG звучит как отдельная технология, а по сути это две вещи подряд: сначала найти в твоих документах куски, которые относятся к вопросу, потом отдать их модели вместе с вопросом и попросить ответить по ним. Модель при этом ничего нового не «выучивает» — она читает то, что ты ей подложил.

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

Когда RAG помогает

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

Когда он не нужен

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

Нарезка: скучно, но решает

Документы режутся на фрагменты, и каждый фрагмент ищется отдельно. Типичные ошибки:

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

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

Поиск: проверяй его отдельно от модели

Самая частая ошибка — оценивать систему целиком по ответам. Ответ плохой, и непонятно почему: не нашлось, нашлось не то или модель не так прочитала.

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

Что обычно помогает:

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

Ссылки на источник

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

И договорись о поведении на случай, когда ответа в документах нет. «В базе об этом ничего не нашлось» — нормальный ответ. Уверенный пересказ того, чего нет в базе, — нет.

Итог

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

SUBXCAT может проверить качество поиска в твоём RAG и найти, на каком шаге теряются правильные ответы.