Базовый RAG хорошо справляется с вопросом: «Какая у меня комиссия за перевод?» — находит чанк с тарифами. Но что делать с вопросом: «Сравни комиссию за перевод в евро у нас и у нашего основного конкурента “Альфа-Банк”»? Это многошаговый (multi-hop) вопрос, требующий поиска в нескольких документах и их сопоставления. Базовый RAG даст сбой. Современный RAG — это уже не просто поиск, а целая экосистема умных компонентов.

Проблемы базового RAG, которые нужно решать:

1. Проклятие «точного совпадения»: Пользователь спрашивает «про сбои в работе», а в документации написано «инциденты доступности сервиса». Лексического совпадения нет, смысловое — есть.

2. Multi-Hop Queries: Вопросы, требующие поиска и объединения информации из нескольких источников. «Какие проекты Иван Иванов вел в прошлом квартале и какова их текущая стадия?» (Нужно найти сотрудника, его проекты, затем статусы проектов).

3. Контекстуализация запроса: Один и тот же вопрос от пользователя из отдела продаж и из техподдержки требует разных документов.

Продвинутые архитектурные паттерны:

1. Query Transformations (Преобразование запросов)

• HyDE (Hypothetical Document Embeddings): Система сначала просит LLM сгенерировать гипотетический идеальный ответ на вопрос. Затем ищет в векторной БД не по самому вопросу, а по эмбеддингу этого гипотетического ответа. Резко повышает смысловую релевантность.

• Step-Back Prompting: LLM получает задачу «отступить» от конкретного вопроса к более общему, концептуальному. Вопрос: «Какая температура плавления вольфрама?» -> Step-Back вопрос: «Физические свойства вольфрама». По нему находятся общие статьи, где, вероятно, есть нужный факт.

2. Многошаговое и агентное извлечение (Multi-Hop & Agentic RAG)  
Здесь LLM выступает как менеджер по поиску.

• Планирование: LLM разбивает сложный вопрос на подзапросы. *«1. Найти тарифы нашей компании на переводы в EUR. 2. Найти публичные тарифы “Альфа-Банка” на переводы в EUR.» *

• Параллельный/последовательный поиск: Система выполняет эти запросы к векторной БД (возможно, даже к разным коллекциям документов).

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

• Инструменты RAG-агента: Вместо одного поиска, у агента есть инструменты: search_internal_knowledge_base(), search_public_website(url), lookup_in_sql_database(query).

3. Reranking (Переранжирование) — последний штрих точности  
После того как векторный поиск вернул 10 возможных чанков, их пропускают через маленькую, но точную модель для re-ранжирования (например, Cohere Rerank, или cross-encoder от sentence-transformers). Эта модель глубже понимает, какой чанк на самом деле лучше всего отвечает на вопрос, и меняет их порядок. Первые 3 чанка после reranking имеют гораздо более высокое качество.

4. Контролируемое извлечение и цитирование  
Продвинутые системы не просто «используют» чанки, а явно указывают, на какой фрагмент какого документа опирается каждый тезис ответа. Это критично для доверия и аудита.

Вывод для архитектора RAG-систем:  
Современный RAG — это не «векторный поиск + LLM», а сложный конвейер с преобразованием запросов, многошаговой логикой, переранжированием и агентным подходом. Инвестиции в эти компоненты — это то, что превращает вашего ассистента из «иногда полезного» в надежного эксперта, способного отвечать на самые сложные, составные вопросы, используя всю корпоративную базу знаний.