SIGNAL ARCHIVE

NEO Blog

Deep Read

Naive RAG 讲解

#AI#RAG#LLM
目录+

RAG，全称 Retrieval-Augmented Generation（检索增强生成），是过去两年大模型应用落地里最重要的工程方案之一。 如果把大模型比作一个"很聪明但记忆固定的学生"，那么 RAG 做的事情就是：先去外部资料里找答案，再带着资料回答问题。

而 Naive RAG，可以理解为最基础、最原始、也是最容易落地的一代 RAG 方案。它的结构并不复杂，但已经足够解决很多实际问题，比如企业知识库问答、内部文档检索、客服机器人、私有数据接入大模型等。

一、为什么需要 RAG

大语言模型能力很强，但存在三类核心局限。

1. 时效性有限

模型知识来自训练数据，而训练数据有截止时间。最新政策、财报、内部 SOP、个人知识库文档——这些如果没被放进训练数据，模型就无法直接回答。

2. 知识覆盖不完整

即使训练了海量语料，也不可能覆盖所有垂直领域和每家企业的内部资料。医疗、法律、金融等高门槛领域，以及内部文档、合同、产品手册、私有接口说明——模型可能"懂一点"，但不够深、不够准。

3. 幻觉问题

大模型在不知道答案时，仍可能生成一个看起来很像答案的内容——语气自信，内容却可能是错的。其根本原因是生成模型在概率分布下会"补全最像答案的文本"。

image.png

一句话概括：当问题依赖最新知识、外部知识或私有知识时，仅靠模型参数往往不够。

二、什么是 RAG：微调 vs RAG

面对"知识更新慢"和"容易幻觉"的问题，常见有两条路：微调（Fine-Tuning） 和 RAG。

微调

在通用大模型基础上用特定领域数据继续训练，让模型更适应某类任务或领域。它擅长解决语气风格统一、输出格式稳定、特定任务能力增强等问题。

image.png

但代价也很明显：数据准备成本高、训练和迭代成本高、知识更新不灵活，不适合频繁变动的知识库场景。

RAG

RAG 不把新知识塞进模型参数，而是给模型外挂一个"可检索知识库"：先从外部知识库找相关内容，拼进提示词，再让 LLM 基于上下文生成答案。

image.png

拆成三个词来理解：

  • Retrieval（检索）：用户提问后，去外部知识源（企业文档、产品手册、FAQ、论文等）找到相关片段。Naive RAG 的常见做法是把文档切分后向量化，存入向量数据库，再通过向量检索匹配。
  • Augmented（增强）：增强的对象不是模型，而是 Prompt——把检索到的相关片段和用户问题拼在一起，让模型在"带资料"的前提下回答。
  • Generation（生成）：把增强后的提示词喂给 LLM，输出答案。

本质一句话：RAG = LLM + 外部知识检索，也就是"让模型先翻书，再回答"。

image.png

image.png

和微调相比，RAG 成本更低、上线更快、知识更新更方便，更适合企业文档和私有数据接入。在多数知识库问答场景里，RAG 往往是第一选择。两者也并非互斥：微调调"模型怎么说话"，RAG 补"模型该知道什么"，必要时可以叠加使用。

三、Naive RAG 的核心流程

Naive RAG 虽然叫"Naive"，但流程已经很完整。工程上分为两个阶段：离线阶段（建库）和在线阶段（问答）。后续所有进阶 RAG 的变化，本质上都是在这两个阶段上做增强——索引更好、检索更准、生成更稳。

1. 离线阶段：构建知识库

在系统正式服务之前，把原始文档加工成"可检索"的知识库。

a. 数据清洗

原始文档常有 HTML 标签、页眉页脚、空白字符、重复内容、敏感信息等噪音。清洗的目标是想清楚：哪些内容值得进知识库，哪些应该被丢掉。企业场景还可能涉及权限对齐、归属关系梳理、业务字段补全等。

b. 文档分块（Chunking）

RAG 不会把整篇文档直接塞给模型或向量库，而是先拆成小块。原因有三：

  • 模型上下文窗口和向量模型输入长度都有限；
  • 整篇文档过长会稀释语义，噪音太多会拉低检索精度；
  • 很多问题只对应文档中的一小段，分块越合理，命中正确答案的概率越高。

分块的目标不是机械切开，而是切成既足够短、又尽量保留语义完整的小单元。它是 Naive RAG 最关键的一环，详见第五节。

c. 向量化（Embedding）

每个文本块通过 Embedding（嵌入）模型转成向量，让"语义相近"的内容在向量空间里靠得更近，从而支持相似度计算。这一层的原理与选型见 Embeddings向量化Embeddings 向量化Embeddings 是 RAG 的基础设施之一。它解决的核心问题很简单：如何把人类语言转换成机器可以计算“语义距离”的数字表示。 它对应 [[Naive RAG 概述]] 离线流程里的"向量化"一步——文档被 [[RAG的分块策略详解|分块]]之后，正是靠 Embedding 转成向量才得以检索。 一、Embeddings 向量化是什么 在数学里，向量（Vector）是一个由多个数值组成的有序数组，可以理解为一个点在高维空间中的坐标。 在 RAG 场景中，向量化就是把一句话、一个段落，甚至一个文档切片，转换成一个固定维度的数值数组。一个文本块对应一个向量，例如： - [0.8, -0.3, 0.5, 0.34, 0.12, 1.78, 9.12, 2.34, -0.23, 0.5]（10 维） - [5, 9, ..., -0.23, 0.5]（1024 维） 维度越高，通常能表达更丰富的语义特征，但也意味着更高的存储和计算成本。 image.png 这些向量由 Embedding 模型（嵌入模型） 生成。它和大语言模型一样，底层通常基于 Transformer 架构。

d. 存储

向量及其原始文本、元数据一起存入向量数据库。向量数据库的核心价值是高效检索：提供相似度搜索、Top-K 返回、元数据过滤和高并发能力。

2. 在线阶段：回答用户问题

流程很直观：

用户提问 → 问题向量化 → 向量检索 → 拼接提示词 → LLM 生成答案

这里有个关键认知：检索结果的质量直接决定最终回答质量。检索回来的若是"像但不对"的片段，再强的模型也救不回来——这也是后文"优点与局限"里反复出现的主线。

image.png

四、检索取多少：Top-K 与 Top-P

检索出一批候选片段后，要决定"取多少条"喂给模型，常见两种策略。

Top-K

把检索结果按相似度排序后，取前 K 条（如 Top-3 取最相关的 3 条）。这是最直观、最常用的做法。

Top-P

不固定条数，而是按累计相似度阈值来取。例如相似度依次为 0.9、0.5、0.4、0.3、0.2，阈值设为 2，则累加至 0.9+0.5+0.4+0.3=2.1 时停下，取前 4 条。它更灵活，但业务中 Top-K 仍更常用——更稳定、更容易调试。

五、分块：Naive RAG 最关键的一环

分块做差了，向量化、检索、生成都会跟着一起变差，因此它几乎决定了 RAG 效果的上限。最常见的几种基础切法如下：

策略思路优点局限
固定长度按固定字符 / Token 数切简单、快、存储检索效率高容易把完整语义硬切断
固定长度 + 重叠窗口相邻块保留 10%~20% 重叠（overlap）减少跨块语义断裂数据冗余、存储成本变高
按句子以句子为最小语义单元（中文尤其适用）语义自然、可读性好块可能过短、缺上下文
递归按"粗→细"分隔符递归切，再合并到目标长度兼顾语义与块大小，贴合真实文档对表格 / 代码等强格式效果一般

实践中常以递归分块 + 适度 overlap 作为默认起点。

这里只做概览。每种策略的可运行代码、参数建议，以及结构感知、语义、主题、混合等进阶切法，见 RAG 分块策略详解RAG 分块策略详解分块（Chunking）是 RAG 离线建库的核心一步：把长文档切成大小合适、语义完整的小块，再去向量化、入库、检索。它看似简单，却几乎决定了整个系统的效果上限——本篇专门把"怎么分"讲透。 RAG 的整体流程、为什么要分块等背景，见 [[Naive RAG 概述]]；这里默认你已了解基本范式，直接聚焦分块策略本身。 一、为什么分块质量决定 RAG 上限 即使用最强的大模型、最精心的 Prompt，分块不当依然会让问答系统出现： - 上下文缺失、关键信息被切散； - 事实性错误、拼接不连贯； - 检索到无关片段，进而诱发幻觉或错误引用。 根因往往是同一个误区：按固定长度硬切，无视标题、段落、列表、表格等语义边界。一个定义、一个条件、一段因果，被拦腰截断后，向量化和检索都会失真。 因此，高质量分块要同时照顾三件事： 贴合自然语义 / 结构边界**，不在句子或语义中间硬切； 设置适度重叠（overlap）**，缓解块与块之间的断裂； 保留元数据（metadata）**，如章节路径、块类型，以支持可追溯性与重排。 一句话目标：在"上下文完整性"与"信息密度"之间取得动态平衡—。

六、优点与局限

优点

  • 成本低、上线快：不需要训练模型，适合快速验证业务。
  • 知识更新方便：文档更新后重新索引即可，无需重新训练。
  • 易于接入私有数据：企业内部资料、产品手册、客服文档可直接接入。
  • 可解释性更强：回答来自哪些检索片段可以展示给用户，更容易追溯依据。

局限

  • 检索未必精准：向量相似不等于业务相关，有时检索到的是"像"而不是"对"。
  • 分块质量高度影响效果：块太大噪音多，块太小上下文不够。
  • 缺少复杂推理：擅长"找到相关资料"，但跨文档整合、多跳检索等复杂场景容易吃力。
  • 噪声干扰：检索结果带噪音时，模型可能被误导生成不准确的答案。

正因如此，后来出现了 Hybrid Search、Re-ranking、Query Rewrite、Multi-hop RAG、Graph RAG、Agentic RAG 等进阶方案，本质都是在修补 Naive RAG 的这些短板。

七、总结

Naive RAG 的本质，是把外部知识切碎、编码、存储，在用户提问时取回最相关的碎片，交给大模型组织成答案。

它不是让模型"学会了新知识"，而是让模型在回答时"临时查到了新知识"。这个差别非常关键：

  • 微调：把知识写进脑子里；
  • RAG：给模型配一个随时能翻的资料库。

它对所有 RAG 系统定义了一个今天仍然成立的基本范式——先检索，再生成，可浓缩成三步：

  1. 索引（离线）：文档 → 分块 → 向量化 → 存储；
  2. 检索：用户提问 → 向量化 → 检索向量库 → 得到 Top-K 个相关文档块；
  3. 增强生成：原始问题 + 相关文档块拼成提示词 → LLM → 生成答案。

对于绝大多数企业知识库、私有问答、文档助手场景来说，Naive RAG 往往就是第一步，也是最值得先跑通的一步。