В чем разница между Naive RAG, Adaptive RAG и Agentic RAG?

Краткий тезис

RAG|Naive RAG — это базовый пайплайн: всегда извлекаем документы и генерируем ответ. RAG|Adaptive RAG добавляет решатель (classifier), который определяет, нужен ли поиск вообще, снижая latency для простых запросов. RAG|Agentic RAG — это полноценный агент с планированием, мультишаговым поиском, переписыванием запросов и выбором между несколькими инструментами. Разница — в степени автономности и сложности логики принятия решений.

1. Термины: Naive RAG, Adaptive RAG, Agentic RAG

Naive RAG (RAG|наивный RAG) — простейшая реализация: запрос → retrieval из векторной БД → конкатенация чанков → генерация ответа LLM. Никакой адаптации под запрос.

Adaptive RAG (RAG|адаптивный RAG) — система, которая перед retrieval оценивает, нужен ли внешний контекст. Используется классификатор (обычно небольшая модель или LLM с промптом), который относит запрос к одному из классов: «требует поиска», «не требует» или «требует уточнения». Это позволяет для простых фактологических вопросов отвечать из знаний LLM, экономя время и ресурсы.

Agentic RAG (RAG|агентный RAG) — архитектура, где агент (LLM с доступом к инструментам) самостоятельно планирует последовательность действий: может переписать запрос, сделать несколько параллельных или последовательных поисков, вызвать калькулятор, API, прочитать документ целиком, а затем синтезировать ответ. Агент использует цикл наблюдения-действия (ReAct, Plan-and-Solve и т.п.).

2. Эволюция RAG: от простого к сложному

RAG прошёл несколько этапов:

1. Naive RAG (2020–2021) — «всегда retrieve». Проблемы: лишние затраты на простые вопросы, шум в контексте, невозможность уточнить запрос.
2. Adaptive RAG (2023) — «retrieve только когда нужно». Появился классификатор необходимости поиска. Примеры: Self-RAG, FLARE.
3. Agentic RAG (2024) — «агент решает как и когда искать». Полноценное управление потоком: мультишаговость, выбор инструментов, память о предыдущих шагах.

3. Naive RAG: всегда ищем → отвечаем

Как работает

• Пользовательский запрос → эмбеддинг → поиск top-k чанков в векторной БД.
• Чанки + запрос → промпт → LLM генерирует ответ.

Плюсы

• Простота реализации.
• Гарантированное использование внешних знаний.

Минусы

• Для вопросов, на которые LLM знает ответ (например, «Столица Франции?») — лишний поиск, увеличивающий latency.
• Если retrieval вернул мусор, LLM может «галлюцинировать» или противоречить себе.
• Нет возможности уточнить запрос, если он нечёткий.

Пример кода (псевдо):

def naive_rag(query):
    docs = vector_store.similarity_search(query, k=5)
    context = "\n".join([d.page_content for d in docs])
    prompt = f"Ответь на вопрос, используя контекст:\n{context}\nВопрос: {query}"
    return llm.invoke(prompt)

4. Adaptive RAG: динамическое решение о поиске

Как работает

1. Классификатор (например, fine-tuned BERT или LLM с промптом) определяет тип запроса:
   • no_retrieval — ответ из знаний LLM (например, «2+2?»).
   • single_retrieval — нужен один поиск.
   • multi_retrieval — нужны несколько уточняющих поисков (редко).
2. Если no_retrieval — сразу генерация без контекста.
3. Если single_retrieval — обычный retrieval + генерация.
4. Если multi_retrieval — агентный режим (переход к Agentic RAG).

Плюсы

• Снижение latency для простых запросов.
• Меньше шума в контексте (когда поиск не нужен).

Минусы

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

Пример классификатора (промпт):

Определи, нужен ли поиск в базе знаний для ответа на вопрос.
Ответь только "search" или "no_search".
Вопрос: {query}

5. Agentic RAG: агент с инструментами и планированием

Как работает Агент (LLM, обёрнутый в цикл) получает запрос и набор инструментов:

• vector_search(query) — поиск по документам.
• web_search(query) — поиск в интернете.
• calculator(expression) — вычисления.
• rewrite_query(query) — переформулировка.
• read_document(doc_id) — чтение полного документа.

Агент строит план (например, в формате ReAct: Thought → Action → Observation → ...). Он может:

• Переписать запрос, если исходный нечёткий.
• Сделать несколько поисков (параллельно или последовательно).
• Объединить результаты из разных источников.
• Вызвать калькулятор для численных данных.
• Вернуть ответ, когда считает, что информации достаточно.

Плюсы

• Гибкость: решает сложные многошаговые задачи.
• Устойчивость к нечётким запросам (переписывание).
• Может использовать внешние API и код.

Минусы

• Сложность реализации (нужен оркестратор, управление состоянием).
• Высокое потребление токенов (много шагов).
• Риск зацикливания или бесконечных вызовов.

Пример (псевдо на LangGraph):

from langgraph.graph import StateGraph

class AgentState(TypedDict):
    messages: list
    next_action: str

def router(state):
    if state["next_action"] == "search":
        return "retrieve"
    elif state["next_action"] == "calculate":
        return "calculator"
    else:
        return "generate"

graph = StateGraph(AgentState)
graph.add_node("retrieve", retrieve_docs)
graph.add_node("calculator", calculate)
graph.add_node("generate", generate_answer)
graph.set_conditional_entry_point(router)

6. Сравнительная таблица: когда что выбирать

7. Плюсы и минусы каждого подхода

Naive RAG

• Плюсы: простота, предсказуемость.
• Минусы: неадаптивен, лишние затраты на простые запросы.

Adaptive RAG

• Плюсы: экономия ресурсов, снижение latency.
• Минусы: зависимость от качества классификатора, ограниченный набор действий.

Agentic RAG

• Плюсы: максимальная гибкость, решение сложных задач.
• Минусы: сложность, стоимость, риск ошибок в планировании.

8. Связь с другими концепциями

• Self-RAG — частный случай Adaptive RAG, где LLM сама решает, нужен ли поиск, и генерирует рефлексию.
• Corrective RAG — улучшение Agentic RAG: агент может перепроверить релевантность найденных документов и повторить поиск.
• ReAct — паттерн для агентов: Reasoning + Acting.
• Plan-and-Solve — агент сначала строит план, потом выполняет.

Пет-проект для закрепления

Задача Реализовать три варианта RAG для чат-бота по документации Python и сравнить их на наборе тестовых вопросов (простые факты, сложные сравнения, нечёткие запросы).

Инструменты

• Python, LangChain, LangGraph (для Agentic RAG).
• FAISS или Chroma как векторная БД.
• OpenAI API или локальная LLM (например, Llama 3).
• Датасет: документация Python (можно взять из официального сайта).

Шаги:

1. Собрать и разбить документацию на чанки (500–1000 токенов).
2. Реализовать Naive RAG: RetrievalQA из LangChain.
3. Реализовать Adaptive RAG: добавить классификатор (LLM с промптом «search/no_search»). Если no_search — генерация без контекста.
4. Реализовать Agentic RAG с помощью LangGraph: агент с инструментами vector_search, web_search (опционально), rewrite_query. Использовать ReAct.
5. Подготовить тестовый набор: 10 простых вопросов («Что такое list comprehension?»), 10 сложных («Сравни asyncio и threading»), 10 нечётких («расскажи про исключения»).
6. Замерить latency, количество токенов, точность ответов (субъективно или с помощью LLM-as-judge).

Ожидаемый результат

• Naive RAG покажет высокую latency на всех вопросах, но хорошую точность на сложных.
• Adaptive RAG снизит latency на простых вопросах в 2–3 раза.
• Agentic RAG справится с нечёткими запросами (перепишет их) и многошаговыми сравнениями, но будет самым медленным и дорогим.

Связь с другими вопросами

Навигация

• Предыдущий: 140
• Следующий: 142
• Индекс: 00. Индекс разборов