Вот частое заблуждение про RAG

Когда говорят про RAG, обычно думают так: проиндексировали док → потом достали этот же док.

Но индексация ≠ ретривал.

То есть данные, которые ты индексируешь, не обязаны совпадать с теми данными, которые ты потом скармливаешь LLM на этапе генерации.

Вот 4 умных способа индексировать данные:

1) Chunk Indexing

▪️Самый распространенный подход.
▪️Режешь документ на чанки, строишь эмбеддинги и кладешь их в векторную базу.
▪️Во время запроса просто достаешь ближайшие чанки.

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

2) Sub-chunk Indexing

▪️Берешь исходные чанки и дробишь их еще мельче на сабчанки.
▪️Индексируешь уже эти более мелкие куски.
▪️Но при выдаче все равно возвращаешь “большой” чанк для контекста.

Помогает, когда в одном абзаце/секции намешано несколько разных идей: шанс точно сматчиться с запросом выше.

3) Query Indexing

▪️Вместо сырого текста генеришь гипотетические вопросы, на которые, по мнению LLM, этот чанк может ответить.
▪️Эмбеддишь эти вопросы и сохраняешь.
▪️При ретривале реальные пользовательские запросы обычно лучше ложатся на такие “вопросные” представления.
▪️Похожая идея есть в HyDE, только там матчат гипотетический ответ с реальными чанками.

Кайфово для QA-систем, потому что уменьшает семантический разрыв между запросом пользователя и тем, что лежит в индексе.

4) Summary Indexing

▪️Просишь LLM кратко резюмировать каждый чанк в компактную семантическую форму.
▪️Индексируешь summary вместо исходного текста.
▪️А возвращаешь все равно полный чанк для контекста.

Особенно эффективно для плотных или структурированных данных (типа CSV/таблиц), где эмбеддинги сырого текста часто слабо что-то выражают

👉 @PythonPortal