Ваш RAG работает плохо из-за нарезки

Когда поисковая система выдаёт неверный ответ, первый порыв — сменить модель эмбеддингов. Это самый заметный компонент, и всегда есть более новая версия. И это, как правило, не проблема.

Проблема обычно в том, что текст неудачно разрезали ещё до того, как векторизовали.

Что делает плохой разрыв

Возьмём пункт договора:

Поставщик обязуется осуществить поставку в течение 30 рабочих дней с даты заказа. Если объём заказа превышает 500 единиц, срок увеличивается до 45 рабочих дней.

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

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

Правила, которые у нас работают

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

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

Заголовок держать при содержимом. Фрагмент, начинающийся словами «продлевается ежегодно», бесполезен. Добавление заголовка раздела к каждому фрагменту из него — правка на две строки, измеримо улучшающая поиск.

Таблицы не резать. Строка таблицы без строки заголовков — это шум. Либо храните таблицу целиком, либо сериализуйте каждую строку вместе с заголовками.

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

Как понять, ваш ли это случай

Возьмите двадцать вопросов, которые реально задают пользователи, и известные правильные ответы. Для каждого проверьте, содержится ли ответ в найденных фрагментах — независимо от того, что потом написала модель.

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

Неприятная часть

Нарезка — работа неблагодарная. Это обработка строк. Она не улучшается от новой модели и не бывает ничьим любимым занятием.

И раз за разом именно в ней пряталось качество.