Базовый 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», а сложный конвейер с преобразованием запросов, многошаговой логикой, переранжированием и агентным подходом. Инвестиции в эти компоненты — это то, что превращает вашего ассистента из «иногда полезного» в надежного эксперта, способного отвечать на самые сложные, составные вопросы, используя всю корпоративную базу знаний.