Naive RAG

explainer · report · domain: rag · 2026-05-28 · построено из 2 первоисточников + 3 концептов вики

В одном предложении. Naive RAG — простейшая парадигма Retrieval-Augmented Generation («Retrieve → Read»): к запросу подмешиваются top-K семантически похожих кусков внешних документов, и LLM отвечает, опираясь на них — чтобы перестать галлюцинировать, не зависеть от устаревших весов и давать ссылки на источник.

Содержание

  1. Какую проблему решает
  2. Ядро идеи: параметрическая vs непараметрическая память
  3. Как устроен: три фазы «Retrieve-Read»
  4. Почему именно этот подход
  5. Ограничения Naive RAG
  6. Эволюция парадигм: Naive → Advanced → Modular

1. Какую проблему решает

Survey Gao et al. (2023) называет три родовые болячки больших языковых моделей, ради которых и нужен RAG:

Проблема LLMВ чём сутьОтвет RAG
Галлюцинациимодель уверенно выдумывает факты, которых не знаетзаземление ответа на извлечённый текст
Устаревшее знаниепараметрическое знание заморожено на момент обучениявнешний индекс можно обновлять без переобучения
Непрослеживаемостьнепрозрачное рассуждение, нельзя проверить источникprovenance — конкретные документы-источники

Первоисточник (Lewis et al., 2020) формулирует ту же мотивацию через память: чисто параметрические модели «не могут легко расширять/ревизировать память, не дают insight в свои предсказания и галлюцинируют».

2. Ядро идеи: параметрическая vs непараметрическая память

RAG = гибрид двух видов памяти. Это центральная мысль статьи Lewis 2020.

Параметрическая памятьНепараметрическая память
Где знаниев весах моделиво внешнем индексе текста
Обновлениетребует переобучениязамена / правка индекса
Прозрачностьнепрозрачначеловекочитаема, инспектируема
Пример (Lewis 2020)генератор BART-large (400M)dense-индекс Википедии + retriever DPR
Эмпирическое доказательство ценности. В Lewis 2020 «hot-swap» индекса Википедии 2016↔2018 обновлял знания модели о мировых лидерах без какого-либо переобучения: 2016-индекс → 70% верных ответов про лидеров 2016, 2018-индекс → 68% про 2018. Знание живёт снаружи модели.

3. Как устроен: три фазы «Retrieve-Read»

Naive RAG — это линейный конвейер из трёх фаз. Первая выполняется заранее (offline), две другие — на каждый запрос.

ФАЗА 1 · INDEXING (offline) Документы PDF/HTML/MD Чанки + эмбеддинги нарезка → векторы Vector DB индекс векторов ФАЗА 2 · RETRIEVAL (на запрос) Запрос + embed той же моделью Similarity-поиск cosine / inner product top-K чанков самые похожие ФАЗА 3 · GENERATION Промпт запрос + top-K чанки LLM Ответ + ссылки на источник
Линейный путь Naive RAG: indexing готовит векторную базу заранее; на запрос — retrieval достаёт top-K, generation склеивает их с запросом в промпт для LLM. Никакой обработки запроса до retrieval и переработки после — отсюда «naive».
ФазаКогдаЧто происходит
1. Indexingofflineдокументы → чистка в plain text → нарезка на чанки (из-за лимита контекста) → embedding-модель кодирует чанки в векторы → vector DB
2. Retrievalна запросзапрос кодируется той же embedding-моделью → similarity-скоры запрос↔чанки → извлекаются top-K наиболее похожих
3. Generationна запросзапрос + top-K чанки «synthesized into a coherent prompt» → LLM генерирует ответ (опирается на контекст и/или свою параметрическую память)
Ключевой механизм retrieval — семантическое сходство векторов, а не совпадение слов. В Lewis 2020 это конкретно retriever DPR (bi-encoder на BERT) + top-K через Maximum Inner Product Search на индексе FAISS, генератор — BART.

4. Почему именно этот подход

«Почему так» = это минимальный жизнеспособный способ дать LLM свежее, проверяемое, доменное знание без переобучения. Разбор по альтернативам:

vs чистый LLM

Модель без retrieval не обновляется без переобучения, галлюцинирует и не даёт источников. RAG добавляет обновляемую внешнюю память + provenance.

vs fine-tuning

Дообучение зашивает знание в веса: дорого, медленно обновлять, нет traceability. RAG держит знание снаружи — дёшево обновлять, есть ссылки. Fine-tuning лучше для поведения/стиля, RAG — для фактического меняющегося знания.

vs Advanced / Modular

Naive RAG выигрывает простотой: минимум компонентов, понятный baseline, быстро поднять. Это отправная точка, от которой отталкиваются усложнения.

5. Ограничения Naive RAG

Survey разбирает недостатки по трём осям — это и есть причины, по которым появились более сложные парадигмы.

Retrieval

Низкие precision и recall → выбор нерелевантных / misaligned чанков и пропуск критичной информации.

Generation

Галлюцинации поверх контекста («content not supported by the retrieved context»), а также irrelevance, toxicity, bias.

Augmentation

Редундантность и повторы при дублях из разных источников; плохая интеграция → «disjointed outputs»; over-reliance (ответ просто «эхо» извлечённого без синтеза).

Структурный изъян №1. Дословно из survey: «a single retrieval based on the original query may not suffice to acquire adequate context information». Один проход retrieval по исходному запросу часто не добирает нужный контекст — отсюда идея итеративного и адаптивного retrieval в Modular RAG.

6. Эволюция парадигм: Naive → Advanced → Modular

«Naive» — не уничижительный термин, а базовый уровень, относительно которого определены усложнения. Каждая следующая парадигма устраняет недостатки предыдущей.

ПарадигмаЧто добавляетСтруктура
Naive RAGбазовый Retrieve-Readлинейная: indexing → retrieval → generation
Advanced RAGpre-retrieval (query rewriting/expansion) и post-retrieval (re-ranking, сжатие контекста) оптимизацията же последовательная, с обвязкой вокруг retrieval
Modular RAGконфигурируемые модули (search, memory, routing); итеративный/адаптивный retrievalгибкая: последовательная И итеративная
Практический вывод. Понимание этой лестницы помогает выбрать минимально достаточную сложность под задачу — не строить Modular RAG там, где хватает Naive.

Откуда это построено