Запись эфира по RAGу без эмбеддингов (ссылка внизу поста) Выписал самое важное и дополнил Главные проблемы поиска на эмбеддингах: 1

Запись эфира по RAGу без эмбеддингов (ссылка внизу поста) Выписал самое важное и дополнил Главные проблемы поиска на эмбеддингах:

1. Семантическая схожесть ≠ фактическая релевантность (слова те же, смысл другой)

2. Не учитывает "логические операции" в запросе ("и", "не")

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

4. Ломается на агрегации "вот тебе посты из канала, проанализируй слабые и сильные места автора" → найдет посты, где я автор сам что-то пишет про посты/канал и сильные/слабые места. Например, обзор чужого канала. 5. Короткие пользовательские запросы отличаются от длинных чанков документации. И по длине, и по формулировкам

6. Плохо работает с таблицами

———

Запрос пользователя:

"Какие отделы нашей компании, кроме отдела продаж, не выполнили KPI в последнем квартале?"

Догадаетесь, в чем будет проблема с эмбеддингами?

"Отчет по итогам квартала: Отдел продаж блестяще выполнил KPI, показав рекордный рост!"
"План на следующий квартал: всем отделам компании, включая отдел маркетинга, поставлена задача выполнить KPI."
"В последнем квартале отдел разработки успешно выполнил все поставленные KPI."

———

Лечим симптомы (все еще эмбеддинги):

1. query rewriting/expansion и/или Instruction Awareness

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

3. Можно делать не просто саммари чанков, а генерировать возможные вопросы по ним и искать уже по вопросам

4. Добавлять текст соседних чанков на этапе Generation

5. reranking

6. Препроцессинг документов с сохранением структуры (marker-pdf, docling, unstructured)

———

Лечим причину:

1. Не используем эмбеддинги

2. В качестве search engine берем легковесную LLM. Прогоняем по страницам документа и выдаем им true/false в зависимости от релевантности вопросу (запросы к разным страницам идут в параллель => работает быстро)

3. Вместо 2 совсем наглеем и передаем в запросе сразу сотни страниц – просим выписать только номера релевантных (держим до 200-300к токенов на запрос, даже если окно 1м)

4. gemini-2.5-flesh круто с этим справляется, а главное – нативно кушает pdf без препроцессинга. Понимает таблицы и картинки 🔥

5. Релевантные страницы передаем в ризонинг модель для Generation как в "классическом RAG"

6. Не забываем делать Structured Output c промежуточными шагами размышлений

———

Альтернативы (Для более структурированного поиска)

Для примера возьмем книгу рецептов и вопрос "что приготовить на ужин, если у меня есть лапша, фарш и 20 минут времени"

1. Сначала для каждого рецепта вычленить структурированные поля (ингредиенты, время приготовления, тип блюда – первое, второе, десерт и т.д.)

2. Сложить в SQL все извлеченные данные и исходный текст рецепта

3. Использовать text2sql, чтобы по запросу пользователя создавать search query

4. В Generation идут исходные текста рецептов

В реальности обычно создаем разные таблички в бд, потому что данные бывают разных типов с разными параметрами

В более простой версии этого подхода, тупо назначаем LLMкой "теги" разным кусочками текста и фильтруем по ним, а потом делаем классический RAG или сразу передаем в LLM

———

Общие мысли и ответы на вопросы

Data preparation is a king
Промежуточный вызов LLM – хороший reranker, даже для embedding-based подхода
Всегда пытаемся передать ссылки на исходные блоки инфы. Увеличивает надежность и тестируемость. Высший пилотаж – показывать не только страницы, но и конкретные строчки, на которые опиралась модель
Иногда нужно вообще убрать этап Generation и просто показывать найденные куски информации
LLM retrieval стоит сильно дороже, чем эмбеддинги, но для большого числа кейсов это ок. 1 доллар – все дешевле, чем пару часов сотрудника с зп в десятки баксов в час

Доп материалы: Ссылка на сам эфир от @r77_ai (больше деталей, примеров и интересных вопросов от слушателей. сначала разгоняюсь, но потом жара начинается)