Большинство проблем в RAG начинаются с документов

Когда RAG-система отвечает плохо, виноватой обычно объявляют модель. Документы к этому моменту нередко успевают испортить дело заранее.

Плоский корпус

Документы почти без разбора отправляются в индекс.

• слабые заголовки
• механическая нарезка
• почти нет метаданных
• дубликаты и устаревшие версии проходят дальше

Подготовленный корпус

Корпус сохраняет структуру, идентичность и подсказки для поиска.

• фрагменты не забывают, из какого документа пришли
• заголовки несут реальный сигнал
• фильтры сокращают пространство поиска
• слабые источники ловятся ещё на этапе загрузки

1. Нарезка — не техническая мелочь

Многие до сих пор говорят о нарезке так, будто это вспомогательная операция перед настоящей работой. На деле это одно из главных решений во всей системе поиска.

Хороший фрагмент должен одновременно:

• точно матчиться к вопросу
• не терять смысл сам по себе
• сохранять достаточно контекста и идентичности, чтобы ему потом можно было доверять

Именно поэтому механическая нарезка по фиксированному размеру стареет плохо.

Здоровее начинать со структуры самого документа:

• Markdown — по заголовкам
• политики — по разделам
• договоры — по clauses и definitions
• судебные тексты — по facts, reasoning и holding
• документы с таблицами и схемами — по layout-aware извлечению, если оно доступно

Лимиты по токенам всё равно нужны. Но говорить первой должна структура.

2. Сильные заголовки тихо улучшают поиск

Один из самых простых апгрейдов — и один из самых недооценённых — это нормальные заголовки у фрагментов.

Фрагмент с названием Section 4 почти ничего не даёт поиску.

Фрагмент с названием Notice periods for termination in enterprise plans работает совсем иначе: и поиск, и потом генератор получают ясный сигнал, что перед ними.

Это не эффектный приём. Просто полезный.

Очень многое в поиске держится на мелких сигналах:

• заголовок документа
• путь по разделам
• название подраздела
• версия или effective date
• тип источника

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

3. Схема parent-child до сих пор даёт один из лучших компромиссов

Маленькие фрагменты ищутся лучше. Большие фрагменты удобнее читать модели.

Это противоречие никуда не делось.

Схема parent-child retrieval остаётся одним из самых чистых решений:

• индексируем маленькие дочерние фрагменты для поиска
• на чтение возвращаем более крупный родительский раздел
• не теряем связь между ними до самого ответа

Так система получает лучшую полноту, но не заставляет модель отвечать по набору оторванных фраз, которые хорошо эмбеддятся и плохо живут отдельно.

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

4. Метаданные сужают поиск до того, как модель начнёт разбирать мусор

RAG часто кажется умнее просто потому, что ищет в меньшем и более уместном пространстве.

Полезный набор метаданных обычно включает:

• источник или репозиторий
• тип документа
• дату версии или вступления в силу
• язык
• продуктовую или доменную область
• уровень чувствительности, если это важно

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

Без такого слоя модель тратит дорогие токены на проблемы, которые нужно было снять ещё на этапе подготовки корпуса.

5. Sentence-window retrieval помогает только после того, как корпус приведён в порядок

Sentence-window retrieval и похожие точные приёмы действительно помогают, когда важна маленькая фактическая деталь.

Но это работает в основном тогда, когда:

• корпус уже очищен
• идентичность фрагментов сохранена
• система умеет расширяться от найденного предложения к локальному контексту

Если же корпус дублированный, устаревший или поломан при парсинге, система просто начинает точнее вытаскивать неправильное место.

Это не улучшение.

6. Reranking — это второй этап поиска, а не первая магия

Reranker способен заметно поднять качество. Но плохой корпус он не спасёт.

Нормальный порядок такой:

1. сначала привести данные в порядок
2. потом получить широкий, но вменяемый top-k
3. потом сделать reranking
4. и только затем передавать модели самый маленький защищаемый набор источников

Если перепутать порядок, reranker будет с большим достоинством выбирать из мусора.

7. Контроль качества корпуса нужен отдельно от answer evals

У серьёзной RAG-системы должен быть свой corpus QA. Не всё сводится к тому, насколько красиво выглядит финальный ответ.

Я хочу отдельные проверки на:

• дубликаты документов
• устаревшие версии
• проваленный OCR или сломанный парсинг
• отсутствующие заголовки
• фрагменты без идентичности документа
• испорченные таблицы
• отсутствующие effective dates там, где они критичны

Работа скучная. Но она дешевле бесконечных попыток компенсировать плохой индекс промптом.

8. Большая часть проблем с поиском — это проблемы подготовки корпуса, только в более вежливой упаковке

Когда люди говорят:

• поиск нестабилен
• reranker странно себя ведёт
• модель не попадает в суть

очень часто имеется в виду другое:

• документы порезаны плохо
• заголовки слабые
• остались дубликаты
• метаданных почти нет
• потерялась идентичность документа

После этого система кажется загадочной. Она не загадочная. Она просто недоделана.

9. Полезнее спрашивать не «какой размер фрагмента?», а «что должно быть понятно само по себе?»

Вопрос про размер удобный, но не лучший.

Гораздо полезнее спросить так:

Какая единица документа должна оставаться понятной и полезной, если её вытащили отдельно?

Ответ зависит от домена.

Для технической документации это может быть section под heading. Для договора — clause вместе с локальными definitions. Для регуляторного текста — section path плюс метаданные о версии и дате.

Универсального размера фрагмента не существует. Есть только более удачное или менее удачное соответствие конкретному корпусу.

Что бы я правил первым

Если бы RAG ощущался шатким и у меня было только одно утро, я бы начал так:

1. убрал дубликаты и устаревшие версии
2. привёл в порядок заголовки и путь по разделам
3. сохранил связку parent-child
4. добавил фильтры по главным измерениям корпуса
5. посмотрел на сбои поиска до всяких правок в промпте

Модель может действительно требовать доработки. Но документы обычно идут первыми.

Что ещё почитать

• Какие преобразования запроса действительно помогают в RAG
• Как строить юридические QA-системы, которым можно доверять

Источники и ссылки

• Lost in the Middle: How Language Models Use Long Contexts
• Как строить юридические QA-системы, которым можно доверять