Как разбивать документы на фрагменты для RAG?

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

Стратегии:

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

Что добавлять к фрагменту:

• заголовок документа и раздела — иначе кусок «Срок — 30 дней» непонятен;
• метаданные: источник, дата, версия, права доступа — для фильтров и ссылок;
• перекрытие с соседями, чтобы мысль на границе попала целиком.

Продвинутые приёмы: искать по маленьким фрагментам, а в контекст отдавать родительский раздел целиком; хранить для фрагмента сгенерированные вопросы или краткое описание.

Как выбирать — собрать набор вопросов с известными правильными фрагментами и сравнить варианты по полноте поиска (recall@k).