В новом препринте исследователи проверили, как совместный выбор парсера, способа нарезки документов и модели эмбеддингов влияет на поиск в retrieval-augmented generation, или RAG. Эксперимент охватывает четыре структурно различающихся документа центральных органов власти Индии, 800 вопросов и 54 конфигурации ритривера.
По заявлению авторов, ни одно семейство поисковых моделей не оказалось лучшим для всех документов. Более того, эффект парсера зависел от выбранной стратегии чанкинга. Это ставит под сомнение практику, при которой компоненты RAG-пайплайна выбирают и тестируют независимо друг от друга.
Работа опубликована как препринт на arXiv 29 сентября 2026 года. Результаты пока следует считать авторскими: в доступных материалах нет сведений о независимом воспроизведении эксперимента или прохождении рецензирования.
Как был устроен эксперимент
Авторы собрали факторный тест из трёх парсеров, трёх стратегий чанкинга и пяти плотных моделей эмбеддингов. Для сравнения использовался также разреженный алгоритм BM25, не требующий нейросетических векторных представлений.
Всего получилось 54 уникальные комбинации: девять пар «парсер — чанкер» были проверены с шестью вариантами поиска, включая пять плотных моделей и BM25. Упомянутые в работе 72 000 — это число строк в итоговом наборе результатов, а не количество конфигураций.
Тестовый набор состоял из 800 вопросов. Для каждого вопроса было задано одно или несколько обязательных свидетельств — строк или фрагментов, которые система должна была найти в исходном документе. Наличие этих свидетельств авторы автоматически сверяли с текстами, после чего вручную проверили случайную выборку размером 10%.
Для статистического анализа использовались линейные модели со смешанными эффектами и случайными пересечениями на уровне пары «документ — запрос». Сопоставимые плотные и разреженные конфигурации сравнивались с поправкой Холма на множественные проверки. Для всех 54 вариантов авторы также рассчитали кластеризованные бутстреп-интервалы.
Карточка препринта доступна на arXiv, полный текст — в PDF-версии работы, а библиографическую запись можно проверить через API arXiv.
Парсер и чанкинг нельзя оценивать по отдельности
Основной результат исследования — отсутствие конфигурации, которая стабильно превосходила бы остальные на всех четырёх документах. По данным авторов, выбор парсера и чанкера статистически значимо взаимодействовал: результат одного компонента менялся в зависимости от того, с каким другим компонентом он использовался.
Для разработчиков это означает, что тест «лучшего парсера» при фиксированном размере фрагмента может дать ложное ощущение универсальности. Та же система после перехода на семантическую нарезку, другой размер чанка или иное перекрытие способна изменить порядок лидеров.
Такой эффект особенно существенен для регуляторных документов. В них одновременно встречаются обычные абзацы, заголовки нескольких уровней, списки, таблицы, сноски и ссылки на другие положения. Парсер определяет, какая структура попадёт в индекс, а чанкер — какие элементы останутся рядом. Поэтому качество поиска зависит не только от способности модели сопоставить запрос и текст, но и от того, в каком виде ей передали документ.
При этом исследование охватывает только четыре документа одного институционального и языкового контекста. Его результаты нельзя автоматически переносить на договоры, техническую документацию, медицинские публикации или корпоративные базы знаний. Для таких корпусов взаимодействие компонентов предстоит проверять отдельно.
MPNet-base столкнулся с проблемами на таблицах
Среди протестированных моделей выделяется MPNet-base: по описанию авторов, она последовательно отставала от других плотных эмбеддингов. Особенно серьёзный провал наблюдался на вопросах, для ответа на которые требовались данные из таблиц.
Препринт не даёт оснований объявлять MPNet-base непригодной для любого RAG-проекта. Вывод ограничен выбранными документами, реализацией пайплайна, параметрами чанкинга и конкретным набором вопросов. Однако результат показывает, что усреднённой метрики по всему тесту недостаточно: она может скрыть отказ на отдельном типе контента.
Командам, работающим с таблицами, стоит выделять такие запросы в отдельный тестовый срез. Минимальная проверка должна включать вопросы к значениям в ячейках, сопоставлению строк и столбцов, единицам измерения, примечаниям и многостраничным таблицам. Полезно также сохранить результаты до и после преобразования таблицы в линейный текст: так можно понять, возникает ли ошибка при парсинге или уже на этапе ранжирования.
Сравнение с BM25 здесь также имеет практический смысл. Совпадение точных терминов, кодов, номеров пунктов и названий полей иногда лучше обрабатывается разреженным поиском, чем семантическими эмбеддингами. Исследование не подтверждает превосходство BM25 во всех случаях, но показывает, что исключать его из тестов только из-за возраста метода не следует.
Информация сохранялась, но не всегда поднималась наверх
Авторы сообщают о потолке сохранения свидетельств выше 98%. Иными словами, почти все необходимые фрагменты присутствовали в подготовленном для поиска корпусе хотя бы в одном чанке. Основные расхождения между конфигурациями возникали после индексации — при определении релевантности и позиции нужного фрагмента в выдаче.
Это различие важно при диагностике RAG. Если доказательный фрагмент вообще не попал в индекс, нужно исправлять извлечение текста, обработку таблиц, размер чанков или перекрытие. Если фрагмент присутствует, но находится слишком низко, проблема ближе к эмбеддингам, формулировке запроса, метрике сходства, гибридному поиску или переранжированию.
Показатель выше 98% относится к исследованному корпусу, а не к RAG-системам в целом. В проектах со сканами, распознаванием текста, сложной вёрсткой или большим количеством изображений потери на этапе загрузки могут быть существенно выше. Поэтому высокий потолок из препринта нельзя использовать как готовый норматив для другого набора документов.
Что проверить перед заменой эмбеддингов
Помимо основного факторного сравнения, авторы провели абляции размерности эмбеддингов, размера чанка и перекрытия между соседними фрагментами. В работе также заявлен анализ Парето по качеству и эффективности, позволяющий искать конфигурации, где рост точности оправдывает дополнительные вычислительные затраты.
Практический порядок проверки для собственной RAG-системы может быть следующим:
Собрать репрезентативные вопросы отдельно для обычного текста, списков и таблиц.
Для каждого вопроса заранее отметить обязательные фрагменты-доказательства.
3. Проверить, сохранились ли они после парсинга и нарезки.
4. Сравнить несколько пар «парсер — чанкер» с неизменным ритривером.
5. Затем протестировать плотный поиск, BM25 и гибридную схему на одинаковых чанках.
6. Анализировать не только средний результат, но и провалы по типам документов и запросов.
Авторы заявляют, что выпустили оценочный инструментарий, манифест корпуса и бенчмарк из 800 вопросов. Перед применением этих материалов стоит проверить связанные с препринтом репозитории, версии зависимостей и условия использования документов. До независимого воспроизведения выводы работы разумнее воспринимать как основание для собственного факторного теста, а не как готовый рейтинг парсеров или моделей эмбеддингов.
