RAG 与知识系统 on Renxin's Blog

第一话｜大模型会聊天，但怎么让它知道你的退货政策？

Fri, 21 Aug 2026 00:00:00 +0000

“NovaTrail X2 支持 7 天无理由退货吗？”

把这个问题交给一个裸大模型，它大概率会给出一段很像客服的话：商品需要保持未使用、包装完整，并保留购买凭证。

听起来没什么问题。

但它不知道 NovaShop 的真实退货政策。它没有看过这份商品资料，不知道规则适用于哪个地区，也不知道政策是不是昨天刚刚改过。

它只是生成了一段听起来合理的文字。

这就是 RAG 系列要解决的起点：大模型虽然会聊天，但它不知道你的退货政策。

一、裸大模型：会生成答案，但没有企业知识

先不谈 RAG，看看最原始的系统是什么样：

用户问题 → Chat 模型 → 文本回答

这类模型可以翻译、总结、写代码，也能把客服话术写得很自然。但它的回答依赖两类输入：训练时学到的参数知识，以及本次请求中传入的上下文。

企业自己的商品政策、内部流程、最新价格和租户数据，通常不在它能够直接访问的上下文里。模型并不会因为“你是 NovaShop 客服”这句话，就自动获得 NovaShop 的资料。

所以裸模型的第一个边界很清楚：它可以生成企业知识问答的语言，却没有企业知识问答的证据。

二、第一种补救：把资料塞进 Prompt

最简单的办法，是把政策直接放进提示词：

你是 NovaShop 客服。
以下是退货政策：
NovaTrail X2 支持签收后 7 天内无理由退货，商品须未使用、包装完整，并保留配件和购买凭证。

请根据这段政策回答用户的问题。

这个办法确实有效。模型现在能看到资料，也能根据资料生成回答。

问题是，企业资料不会永远只有一段。商品规格、物流规则、保修政策、不同地区的退货政策和新旧版本都会继续增加。最后，Prompt 会变成一份越来越长、越来越难维护的知识文档。

当回答出错时，排查也很困难：资料没有放进去？放进去了但没有检索到？检索到了但模型没有使用？还是引用了已经过期的版本？

Prompt 方案解决的是“把资料放到模型眼前”，却没有解决“资料如何管理、如何查找、如何证明回答有依据”。

关键洞察： Prompt 可以临时装下知识，但不能替代一条可维护、可追溯的知识链路。

三、第二种补救：先检索，再生成

RAG 在 Prompt 方案前面增加了一步：模型回答之前，系统先去资料中找相关内容。

用户问题
 ↓
检索相关资料
 ↓
组装上下文
 ↓
Chat 模型生成回答
 ↓
返回引用或拒答

这条链路可以拆成五个动作：

动作	要回答的问题
文档准备	企业资料从哪里来？
检索	哪些片段和当前问题有关？
上下文组装	哪些内容真正交给模型？
生成	模型是否只根据这些内容回答？
引用与拒答	能否指出依据，证据不足时能否不回答？

RAG 原始论文把外部检索到的知识接入生成过程，用来缓解参数知识难以更新、访问和追溯的问题。Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks

这里还要先纠正一个常见误解：RAG 不等于向量数据库。 Retriever 可以使用关键词检索、Elasticsearch 的分词器和倒排索引、向量检索、结构化查询，也可以把几种方式组合成混合检索。本系列会在后续文章里分别比较这些方式；本篇只把“检索”当作一个黑盒步骤，不展开它的内部算法。Elasticsearch，Search approaches

四、从最小 RAG 到企业级知识助手

RAG 让模型“回答前先查资料”，但这还只是企业知识助手的中间一层。真正的系统需要沿着两条链路运行。

1. 文档入库链路

企业资料不是凭空出现在检索器里的，它要先经过入库：

文档上传
→ 解析与清洗
→ 分块
→ 建立索引
→ 保存版本和来源

这一条链路解决的是“系统手里到底有什么资料”。文档解析决定哪些内容能被看见，分块决定检索的最小单位，索引决定怎么找到它们，版本和来源决定答案能不能回溯。

2. 问答链路

用户提问时，系统再走另一条链路：

用户问题
→ 检索候选片段
→ 权限与版本过滤
→ 组装上下文
→ 模型回答
→ 引用、拒答与记录

两条链路合起来，才是企业级 RAG 的基本轮廓：

%%{init: {'theme':'neutral'}}%%
flowchart LR
 A["企业文档"] --> B["解析与索引"]
 B --> C["检索"]
 D["用户问题"] --> C
 C --> E["上下文与模型"]
 E --> F["回答与引用"]

这张图只画了主链路，没有画出所有生产组件。评测、权限、版本、任务恢复和观测会横向影响多个节点，后面分别展开。

五、跑一次全链路预览

理论地图有了，接着跑最小实现。配套代码目前保存在私有工作区的 code/agent-tutorial/c01-rag-overview/，尚未作为公开代码仓库发布；实验只依赖 Python 3.10+ 标准库。云端运行需要百炼兼容模式的 DASHSCOPE_API_KEY。

cd code/agent-tutorial/c01-rag-overview
export DASHSCOPE_API_KEY=你的Key
python3 main.py

本次预览实验使用阿里云百炼：

角色	模型
Chat	`deepseek-v4-flash-0731`
Embedding	`qwen3.7-text-embedding`

没有 Key 时，可以先验证本地链路：

python3 main.py --offline
python3 -m unittest discover -s tests -v

离线模式只验证这条链路的数据结构、上下文组装和引用格式，不代表云端模型的回答效果。云端跑通的判定标准是：看到模型配置、命中的来源、上下文字符数、回答，以及形如 [source:returns-cn#chunk-001] 的引用。至于系统为什么会把某些片段排在前面，下一篇再拆开解释。

2026-08-21 的一次真实运行结果如下：

{"mode":"dashscope","provider":"aliyun-bailian","chunks":3,"chat_model":"deepseek-v4-flash-0731","embedding_model":"qwen3.7-text-embedding"}
{"question":"NovaTrail X2 是否支持 7 天无理由退货？","sources":["returns-cn#chunk-001","novatrail-x2#chunk-001"],"context_chars":215,"answer":"支持。根据退货政策，NovaTrail X2 可在签收后 7 天内无理由退货，但需满足商品未使用、包装完整、保留配件和购买凭证等条件。 [source:returns-cn#chunk-001]"}
{"question":"NovaShop 是否提供月球基地配送？","sources":["returns-cn#chunk-001","novatrail-x2#chunk-001"],"context_chars":215,"answer":"无法确认。现有资料中未提及月球基地配送服务。"}

上面是从真实输出中保留本篇关心字段后的结果。第一个问题走通了完整链路：系统返回了相关来源，模型根据上下文回答，并附上了来源标记。至于这些来源如何被计算和排序，本篇先不展开。

第二个问题暴露了当前 Demo 的边界。资料里没有月球基地配送，但系统还是返回了两个候选片段，因为程序现在固定返回若干候选。模型这次回答“无法确认”，但无关片段已经进入上下文；换一个问题，模型可能会被这些噪声影响。

这说明“能检索、能生成”还不等于“知识助手可靠”。我们还需要阈值、评测、引用校验和拒答策略。

如果运行失败，先看错误发生在哪一层：DASHSCOPE_API_KEY is not set 表示当前 Shell 没有读到 Key；401 或 403 通常是 Key 无效、过期或没有权限；404 model not found 则要检查模型名、地域和百炼工作空间。代码默认使用 aliyun-bailian、deepseek-v4-flash-0731 和 qwen3.7-text-embedding，也可以通过 README 中的环境变量覆盖。

关键洞察： 这个 Demo 的价值不是证明 RAG 已经可靠，而是把“资料从哪里来、系统找了什么、模型看到了什么、回答引用了什么”第一次暴露出来。下一篇，我们再追问“系统为什么找到了这些片段”。

六、GYR 系列接下来会补齐什么

现在可以回头看整个系列的路线。每一篇不是凭空增加一个组件，而是在解决上一层暴露出来的具体问题：

阶段	要解决的问题	主题
第一话	整条链路到底是什么	RAG 全景与演进路线
第二话	问题和文本为什么可以比较	Embedding、余弦相似度、Top-K
第三话	一篇长文应该如何检索	文档分块与 Chunk 设计
第四话	找到资料后如何可靠回答	上下文、引用与拒答
第五话–第六话	如何保存和评价检索结果	PGVector、版本与评测基线
第七话–第八话	关键词和向量如何配合	检索优化与混合检索
第九话–第十二话	企业资料如何进入系统并保持边界	解析、租户权限、任务恢复与观测
第十三话–第十四话	如何收敛为可运行的服务	API、模块化原型与框架对照

这条路线有一个刻意的约束：先手写最小机制，再引入数据库、服务和框架。否则读者很容易得到一个“能启动的 RAG”，却不知道每个组件为什么存在。

下一篇：Embedding 到底做了什么

现在我们知道 RAG 的整体链路，也看到一个最小版本确实可以把问题和资料交给模型。但“检索”仍然像一个黑盒：为什么退货政策排在前面？相似度分数是什么？SKU 这种精确编号也适合这样检索吗？

下一篇只回答一个问题：一句用户问题，为什么可以和一段商品政策计算相似度？

我们会检查 Embedding 的真实输出，手写余弦相似度和 Top-K 排序，把第一话图里的“检索”拆开来看。

第一篇只需要记住一句话：

RAG 是裸大模型走向企业知识助手的第一条外部知识链路，但它远没有替企业完成评测、权限和数据治理。

参考资料

Patrick Lewis 等，Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks，2020。
Alibaba Cloud Model Studio，List models。
Alibaba Cloud Model Studio，DeepSeek API。
Elasticsearch，Search approaches。

RAG 分块策略：为什么你的知识库答非所问，问题多半出在这里

Thu, 13 Aug 2026 00:00:00 +0000

你搭了一个知识库问答系统：上传文档、建好索引、跑通 demo——然后 LLM 开始答非所问。

你以为是模型不够聪明。换更强的模型，还是不对。

问题很可能出在一个不起眼的环节：文档入库时的分块。LLM 根本没读到该读的内容，模型再强也白搭。

这篇文章把分块这件事讲透：为什么要分块、五种分块策略分别解决什么问题、生产环境到底怎么选。

为什么要分块？三个绕不过去的原因

先把结论摆出来：解析完的文档，不能整篇扔进检索。

原因有三个，每一个都独立成立。

原因一：上下文窗口是有限的

LLM 的上下文窗口再大也有上限。就算现在有 128K、1M 上下文的模型，检索也不是把整个文档库塞进 Prompt——那样成本直接爆炸。

更重要的是，窗口越大，模型越难从中找到准确的那一段。这就是著名的"大海捞针"问题：上下文拉长，检索精度反而下降。

原因二：检索信噪比

用户问的是文档里的一个小问题，但整篇文档有几千字。

整篇匹配会发生什么？不相关的内容把相关内容的信号稀释了。向量检索返回的 Top-K 结果里，噪音占了大多数，相关的那一小段被埋没。

块太大 → 无关信息稀释信号。这是信噪比的第一面。

原因三：Embedding 对长文本的"平均化"

Embedding 模型擅长表示短文本——一两句话的语义最清晰。

文本一长，向量就被"平均"了：整段的语义混在一起，变成一个模糊的方向。检索时，这个模糊向量既匹配不上问题，也匹配不上文档里的任何精确信息。

Embedding 模型对短文本的语义表示最好，长文本会被"平均"成模糊向量。

三个原因叠加，结论只有一个：必须把文档切成合适大小的块。

graph LR
 A["① 上下文窗口有限"] --> D["必须分块"]
 B["② 检索信噪比"] --> D
 C["③ Embedding 平均化"] --> D
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style D fill:#d1fae5,stroke:#059669,color:#064e3b

但怎么切，才是真正的问题。切小了语境不够，切大了检索不精——这就是分块的核心矛盾：检索精度 vs 上下文完整性。

分块的两个基础参数

在讨论策略之前，先理解所有分块策略都绕不开的两个参数。

参数	含义	经验值（中文场景）
chunk_size	每块的大小	300-800 字（约 500-1200 tokens）
chunk_overlap	相邻块之间的重叠量	chunk_size 的 10%-20%

为什么需要 overlap？看一个例子。

graph LR
 A["文档
AAAABBBBCCCCDDDD"] --> B["chunk_size=8, overlap=2
块1: AAAABBBB
块2: BBCCCCDD
BB 被两块共享"]
 A --> C["chunk_size=8, overlap=0
块1: AAAABBBB
块2: CCCCDD
BB-CC 之间语义断裂"]
 B --> D["✅ 跨块内容仍可检索"]
 C --> E["❌ 关键句恰好被切断时丢失"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#d1fae5,stroke:#059669,color:#064e3b
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style D fill:#d1fae5,stroke:#059669,color:#064e3b
 style E fill:#fee2e2,stroke:#dc2626,color:#7f1d1d

overlap=0 时，如果"BBCC"恰好是完整语义（比如一个概念的完整描述），它被拦腰切断，两块都不完整。检索时哪块都匹配不精准，LLM 拿到的都是残句。

overlap 就是给跨块语义留的缓冲带。

五种分块策略，逐个拆解

理解了参数，进入正题。分块策略从简单到复杂，正好是一条问题驱动的问题链。

策略一：固定大小分块——最简单，也最粗暴

做法：按预设的字符数或 token 数直接切。

# LangChain
text_splitter = CharacterTextSplitter(
 chunk_size=500,
 chunk_overlap=50,
)

优点只有一个：实现最简单、速度最快。

缺点却很致命：完全无视语义边界。可能在句子中间、甚至词语中间切断。

切出来的块，很多是"半个意思"。检索时匹配到半句话，LLM 看着上下文猜——这正是答非所问的来源。

适合日志、代码等结构弱、语义依赖不强的文本。自然语言文档用它，基本等于摆烂。

策略二：递归分块——默认策略，性价比之王

做法：按优先级尝试分隔符，从大到小逐级切。

# LangChain
text_splitter = RecursiveCharacterTextSplitter(
 chunk_size=500,
 chunk_overlap=50,
 separators=["\n\n", "\n", "。", "，", " ", ""]
)

graph LR
 A["超长段落"] --> B{"按优先级逐级切分
段落 → 换行 → 句子 → 词"}
 B -->|"每块 ≤ 上限"| C["✅ 在语义边界成块"]
 B -->|"仍超限"| D["降级到更细的分隔符"]
 D --> B
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style C fill:#d1fae5,stroke:#059669,color:#064e3b
 style D fill:#fef9c3,stroke:#ca8a04,color:#713f12

思路：优先在语义最完整的边界（段落、换行、句号）切断，实在超限才降级到更细的分隔符。

优点：在保持语义边界和控制块大小之间取得最佳平衡，通用场景的默认选择。

缺点：分隔符优先级需要按文档类型微调；对复杂结构文档（表格、代码）力不从心。

策略三：语义分块——让 Embedding 参与决策

递归分块是按"形式"切（分隔符）。语义分块按"意思"切。

做法：

把文本拆成句子
计算每个句子的 Embedding 向量
计算相邻句子的语义相似度
在相似度"断崖"处切分

graph LR
 A["句子1: 聚类算法把样本分组"] --> B["句子2: K-Means 是经典算法"]
 B --> C["句子3: 明天北京多云转晴"]
 C --> D["语义断崖
句子2→3 相似度骤降
在这里切"]
 A -.->|"高相似"| B
 B -.->|"低相似"| C
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#fee2e2,stroke:#dc2626,color:#7f1d1d
 style D fill:#fef9c3,stroke:#ca8a04,color:#713f12

核心算法是新颖度检测：

novelty(s_i) = 1 - cosine_sim(embed(s_i), embed(context_window))
当 novelty > 均值 + 0.8 * 标准差 → 切分

优点：语义连贯性最好，检索精度最高。这也是为什么生产环境在"疑难块"上会启用它。

缺点：每个句子都要算一次 Embedding，计算成本翻倍。全量用不划算，适合作为精修手段。

工具：semchunk、LlamaIndex SemanticSplitterNodeParser。官方 benchmark 里，semchunk 的 AI 分块模式在 Legal RAG QA 上正确率 37.7%，比 LangChain 递归分块的 34.8% 高约 2.9 个百分点。

策略四：结构感知分块——利用文档自身的结构

如果文档本身有结构，为什么不直接用？

做法：按文档的固有边界切——Markdown 按标题层级、HTML 按标签、代码按函数类定义、对话按轮次。

关键技巧是注入结构元数据：每个 chunk 附带它在文档中的位置路径。

{
 "content": "聚类算法的核心思想是...",
 "metadata": {
 "header_path": "第三章 > 3.2 无监督学习 > 3.2.1 K-Means",
 "section_level": 3
 }
}

好处很实在：

逻辑清晰，切块天然语义完整
检索结果自带上下文——LLM 不光看到这段内容，还知道它来自哪一章哪一节

graph LR
 A["第三章 无监督学习"] --> B["3.2 无监督学习"]
 B --> C["3.2.1 K-Means
chunk 携带 header_path"]
 C --> D["检索命中 3.2.1 时
LLM 知道完整上下文位置"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#d1fae5,stroke:#059669,color:#064e3b
 style D fill:#d1fae5,stroke:#059669,color:#064e3b

缺点：依赖文档格式规范。纯文本、扫描件这类无结构文档，它无从下手。

策略五：父子分块——生产环境的首选

前面的策略都在解决一个问题：块大还是块小。父子分块跳出这个取舍——大小都要。

做法：

父块：段落/小节级别（500-1000 tokens），提供完整上下文
子块：句子级别（100-200 tokens），负责精确检索

检索流程：用小的找，用大的答。

graph LR
 A["用户提问"] --> B["在子块中检索
句子级别，高精度"]
 B --> C["命中子块：
K-Means 是经典算法"]
 C --> D["通过 parent_id 找到父块"]
 D --> E["返回父块完整内容
上下文完整，LLM 能理解"]
 style A fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style B fill:#d1fae5,stroke:#059669,color:#064e3b
 style C fill:#d1fae5,stroke:#059669,color:#064e3b
 style D fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style E fill:#d1fae5,stroke:#059669,color:#064e3b

graph LR
 subgraph P["父块：3.2.1 完整小节"]
 C1["子块1: 算法定义"]
 C2["子块2: 参数说明"]
 C3["子块3: 适用场景"]
 end
 Q["问题命中子块2"] --> C2
 C2 --> P
 P --> LLM["LLM 收到父块全文"]
 style P fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C1 fill:#d1fae5,stroke:#059669,color:#064e3b
 style C2 fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style C3 fill:#d1fae5,stroke:#059669,color:#064e3b
 style Q fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style LLM fill:#d1fae5,stroke:#059669,color:#064e3b

优点：检索精度与上下文完整性兼得——化解了分块最核心的矛盾。小粒度保证命中精准，大粒度保证 LLM 拿到完整语境，避免"找到了关键句但缺前因后果"。

缺点：存储开销翻倍（父子块都要存向量）、实现复杂度较高。

工具：LlamaIndex 的 auto-merging retriever / recursive retriever 就是这种思路的官方实现。

生产环境怎么选

五种策略各有适用场景，先看总对比。

策略	原理	优点	缺点	适用场景
固定大小	按字符/token 数硬切	最简单、最快	无视语义，可能在句中切断	日志、代码等弱语义文本
递归分块	按分隔符优先级切	语义边界与块大小平衡，通用	需调分隔符；复杂结构无力	通用默认
语义分块	用 Embedding 找语义断崖	语义最连贯、精度最高	计算成本翻倍	高质量问答、疑难块精修
结构感知	按文档标题/标签/轮次切	语义完整、自带上下文	依赖文档格式规范	Markdown/HTML/代码文档
父子分块	子块检索、父块作答	精度与上下文兼得	存储翻倍、实现复杂	生产环境首选

单看这张表，你可能会问：到底用哪个？

答案是：生产环境用混合分块。单一策略覆盖不了所有文档类型——你的知识库里既有 Markdown 规范文档，也有扫描 PDF，还有代码片段。

graph LR
 B["① 结构感知粗切
按标题/章节"] --> C{"块大小判断"}
 C -->|"过小"| D["合并相邻块"]
 C -->|"合适"| E["直接使用"]
 C -->|"过大"| F["递归/语义细分"]
 D --> G["② 父子分块映射
+ 元数据注入"]
 E --> G
 F --> G
 style B fill:#dbeafe,stroke:#2563eb,color:#1e3a5f
 style C fill:#fef9c3,stroke:#ca8a04,color:#713f12
 style D fill:#d1fae5,stroke:#059669,color:#064e3b
 style E fill:#d1fae5,stroke:#059669,color:#064e3b
 style F fill:#d1fae5,stroke:#059669,color:#064e3b
 style G fill:#dbeafe,stroke:#2563eb,color:#1e3a5f

混合分块的思路：结构感知先粗切出框架，块大小判断决定后续处理（过小合并、合适直接用、过大递归/语义细分），最后用父子分块建立层级，注入元数据。

落地建议

回到开头的场景——知识库答非所问，怎么排查？

按这个顺序自查，90% 的问题能定位：

先看分块：打开一个 chunk 看看，句子是不是被拦腰切断？上下文是不是残缺？
默认从递归分块起步：chunk_size 500-800、overlap 10%-20%，把基线跑通
结构化文档换结构感知：你的文档有标题层级，就别浪费这个信息
检索精度不够再上父子分块：让子块找、父块答，通常能显著提升
疑难块用语义分块精修：只对检索差的高频问题块启用，控制成本

分块不是一个"选一次就完事"的环节。文档类型变了、检索效果变了，分块策略就要跟着调。这是 RAG 系统里最值得花时间的调优点之一——因为它是整个检索质量的起点，也是你最能控制的一环。

本文基于个人对 RAG 工程实践的梳理与官方文档验证（MinerU OmniDocBench v1.6 得分 95.39 来自其官方 README；semchunk 基准数据来自其官方 README 及 isaacus.com 博客）。

RAG 是什么？从一条文档的完整旅程说起

Fri, 10 Jul 2026 00:00:00 +0000

你有没有想过一个问题——

LLM 训练时读了几万亿字的互联网数据，几乎什么都知道。但它不知道你的业务数据——你的产品手册、售后政策、内部文档、客服对话记录。这些它没读过。

怎么让它知道该知道的？

这就是 RAG 要解决的问题。这篇文章从为什么需要 RAG 开始，一直讲到它的完整架构和最容易翻车的地方。

LLM 什么都知道，但不知道你的业务

LLM 有两个先天缺陷，在实际落地中很难绕过去。

缺陷	表现	影响
知识截止	训练数据停在某个时间点	问最新政策、实时数据，它不知道
不知道私有数据	没读过你的内部文档、产品手册、客服记录	业务场景下基本不可用

怎么解决？目前有三条路可以走。

方案一：微调（Fine-tuning）

拿业务数据继续训练模型，让它把新知识学进去。

听起来最直接，但实际操作成本很高。你需要准备高质量的训练数据、处理算力资源，而且每次业务文档更新了，又得重新训一遍。更麻烦的是，微调可能会破坏模型原有的通用能力——模型学会了你的业务术语，但写邮件的能力反而变差了。

方案二：塞长上下文（Long Context）

把所有资料都塞进 Prompt 里，让模型自己翻。

实现最简单，不用动模型。现在有些模型支持 128K、1M 甚至更长的上下文，看起来够用。但实际效果没那么理想：一是 Token 成本会随着内容量线性增长；二是内容太多之后，模型很难从海量信息中找到准确的那一段——这就是著名的"大海捞针"问题。上下文再长，检索精度是会下降的。

方案三：RAG（检索增强生成）

每次提问的时候，先去知识库里检索相关内容，拼到 Prompt 里，再让 LLM 基于这些材料回答。

RAG 是目前最主流的方案。原因很实在：

成本低：不需要重新训练模型，省了算力
更新快：知识库加个文档就行，不需要重训
可追溯：LLM 是看着你给的资料回答的，能知道它引用的是哪份文档
幻觉少：基于具体材料生成，比凭空回答可靠得多

当然，RAG 也有自己的问题——它依赖检索质量。如果检索到的内容不对或者不完整，LLM 材料再好也回答不对。后面会详细讲这个。

RAG 不是搜索引擎——它和搜索引擎的区别

很多人第一次接触 RAG 的反应是：这不就是搜索引擎吗？用户搜关键词，系统返回匹配的文档——有什么新鲜的？

这个理解对了一半，错的一半恰好是 RAG 的核心。

搜索引擎（ES/BM25）怎么工作

你搜一个关键词，搜索引擎在你的文档库里找到包含这个词的所有文档，按匹配度排序返回。它做的是关键词精确匹配。

比如说你搜"2025年Q3营收"，它能找到包含这几个词的那份财报。但如果你问"去年第三季度营收怎么样？"，它可能找不到——因为文档里写的是"2025年Q3营收同比增长15.3%"，关键词对不上。

%%{init: {'theme':'neutral'}}%%
graph LR
 A["搜：去年第三季度营收怎么样？"] --> B[ES 关键词匹配]
 B --> C["找到「去年」「第三」「季度」「营收」"]
 C --> D[❌ 文档写的是「Q3营收同比增长15.3%」
关键词对不上，找不到]

这是一直以来搜索引擎的运作方式。在"搜文档、找文件"的场景下非常好用，但在"回答问题"的场景下就显得力不从心。

RAG（向量检索）怎么工作

RAG 不一样。它先把你的文档库转成一组向量（可以理解成一组数字坐标），用户提问时也把问题转成向量，然后计算问题向量和文档向量之间的距离。距离越近，说明内容越相关。

%%{init: {'theme':'neutral'}}%%
graph LR
 A["同样的问题：去年第三季度营收怎么样？"] --> B[RAG 向量检索]
 B --> C[把问题和文档都转成向量
计算语义距离]
 C --> D[✅ 匹配到「Q3营收同比增长15.3%」
语义相近，找到了]

“去年第三季度营收怎么样？“和"2025年Q3营收同比增长15.3%“在字面上没有共同的关键词，但在语义上是同一件事。向量检索能捕捉到这种语义上的相近。

维度	搜索引擎（ES/BM25）	RAG（向量检索）
匹配方式	关键词精确匹配	语义匹配
搜"苹果”	返回含"苹果"二字的所有文档	能区分你在问水果还是手机品牌
输出	文档列表	相关内容 + LLM 生成的自然语言回答
适合场景	搜文档、找文件	回答问题、知识问答
局限性	同义词、近义词不识别	对数字/专有名词匹配不如精确搜索

所以搜索引擎和 RAG 不是替代关系，而是互补关系。生产环境最常用的方案是混合检索：向量检索负责语义匹配，BM25 负责精确匹配，两者互补。

但语义检索有一个前提条件：内容必须被正确地理解和切分。这就引出了下一个问题。

一条文档在 RAG 系统中的完整旅程

语义匹配的效果，很大程度上取决于文档在入库时被处理成了什么样子。一条文档从上传到最终被 LLM 用来回答问题，中间经历了一整套加工管道。

RAG 系统完整管道：入库阶段 → 检索阶段（点击图片查看大图）

入库阶段：让机器能"读懂"文档

环节	做什么	为什么重要
文档解析	把 PDF、Word、HTML 等格式转成纯文本	PDF 看着是文字，实际是一堆坐标指令。解析不好，后面的所有环节都白费
文本清洗	去噪、去重、格式归一化	把乱码、多余的空格、无关的页眉页脚清掉
分块	把长文本切成语义完整的片段	不能整篇检索——太大了检索不准，太小了语境不够
向量化	用 Embedding 模型把文本片段转成向量	向量是语义匹配的基础
存入向量库	把向量和原文存入向量数据库	供后续检索使用

检索阶段：找到相关内容并让 LLM 回答

环节	做什么
问题向量化	把用户提问也转成向量
向量检索	在向量库里找距离最近的文档片段
重排序	对检索结果重新精排，提升 Top 结果的准确率
拼入 Prompt	把检索到的内容拼到 Prompt 里，加上指令让 LLM 基于材料回答

为什么检索质量是关键

整个管道里，最核心的瓶颈不是 LLM 本身，而是检索质量。

Andrew Ng 在一个分享里提过一个数据：优化 RAG 系统时，检索质量的提升对最终答案准确率的影响远大于模型本身的升级。换句话说，用更强的模型不能弥补检索结果差的问题——模型再聪明，材料给错了也答不对。

而检索质量又依赖于前面的入库环节：文档解析是否正确、分块是否合理、向量化是否准确。这是一个完整的链路，短板出在任何一环都会影响最终效果。

最容易在哪里翻车？

把各个环节按翻车概率排序，前三个是：

1. 文档解析——最大的坑

你传上去的文档是 PDF。PDF 看着是文本，但本质上是一堆坐标指令的集合——“在坐标 (x,y) 处渲染字符 A，在 (x+5,y) 处渲染字符 B”。它并不知道什么是段落、什么是表格、什么是页眉。

遇到以下几种 PDF，解析很容易翻车：

PDF 类型	难度	翻车方式
数字原生 PDF	⭐ 简单	基本没问题
扫描件 PDF（图片）	⭐⭐⭐ 中等	需要 OCR，识别率取决于清晰度
双栏/多栏排版	⭐⭐⭐⭐ 困难	阅读顺序恢复错误，左右栏混在一起
含表格 PDF	⭐⭐⭐⭐⭐ 极难	无线框表格、合并单元格、跨页表格，很容易解析错位
含公式 PDF	⭐⭐⭐⭐⭐ 极难	LaTeX 公式、化学结构式，专用模型才能处理好

2. 分块——切得不合适

解析完的文本不能整篇扔进去检索。整篇检索的问题：一篇文档可能几千字，但用户问的只是其中一小段。整篇匹配会让不相关的内容稀释相关内容的信号。

但切得太细也不行。比如只切一两句话——检索时可能命中了，但上下文缺失，LLM 看了也不知道前因后果。

这就是分块的核心矛盾：检索精度 vs 上下文完整性。切小了检索精准但语境不足，切大了语境完整但检索不精准。

实际生产中有好几种分块策略来解决这个矛盾——按固定大小切、按语义边界切、按文档结构切、父子分块等等。每种策略各有优缺点，选型取决于你的文档类型和场景。

3. 检索——精确匹配 vs 语义匹配的盲区

即使解析和分块都做好了，检索环节仍然可能翻车。典型场景：

找不到相关内容：你的文档里确实有答案，但向量检索没把它排到前面
找到太多噪音：检索返回了大量不太相关的内容，稀释了有效信号
数字/专有名词匹配弱：向量检索对"Q3-2025营收同比增长率15.3%“这种精确表达不如关键词搜索

这也是为什么生产环境通常用混合检索——语义 + 关键词组合，取长补短。

回头看看

把整篇文章的问题串起来：

LLM 不知道你的业务数据
 → 三种方案对比，RAG 最实用（成本低、更新快、可追溯）
 → RAG 不是搜索引擎，是语义匹配
 → 但语义匹配的前提是内容被正确加工
 → 入库阶段：解析 → 清洗 → 分块 → 向量化 → 存储
 → 检索阶段：检索 → 重排序 → 拼入 Prompt → 生成
 → 最容易翻车的地方：解析、分块、检索

RAG 看起来简单——“查资料再回答”——但做了才发现，每一步都有坑。理解了这个全貌，后续不管是选型还是排查问题，都知道问题可能出在哪一环。

参考资料

Andrew Ng, Building RAG Agents with LLMs, DeepLearning.AI, 2025 — 检索质量对 RAG 效果影响的分享
Lewis et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks, arXiv:2005.11401, 2020 — RAG 论文原文

向量化原理——为什么向量能算语义相似度

Fri, 10 Jul 2026 00:00:00 +0000

你有没有想过一个问题——

RAG 的核心是「语义匹配」：你说「去年第三季度营收怎么样」，它能找到文档里写的「Q3 营收同比增长 15.3%」。字面不一样，但意思一样。

这到底是怎么做到的？一段文字怎么变成一个「向量」？为什么两个向量离得近就代表意思相近？

这篇文章从最基础的概念讲起，不涉及复杂的数学公式。

人能判断语义相似度，机器也能

先想一个简单的问题：人和人之间怎么判断两句话意思差不多？

「今天天气真好」和「今天阳光明媚」——你一看就知道它们说的是一回事。

背后的过程很复杂（你用了多年的语言经验、对词汇的理解、对语境的把握），但直觉上很简单：你在大脑里给这两句话各自建立了一个「语义位置」，发现它们靠得很近。

机器做同样的事，只是用的方法不一样——它用向量来表示语义位置。

向量是什么？一组数字而已

向量听起来很高深，其实就是一组数字。

[0.52, -0.13, 0.87, -0.42, 0.11, ...]

你可以把向量想象成语义空间中的一个坐标点。

比如我们想象一个二维的语义空间，每一段话都对应一个坐标点：

「今天天气真好」→ 坐标 (0.9, 0.3)
「今天阳光明媚」→ 坐标 (0.8, 0.4)
「苹果很好吃」 → 坐标 (0.1, 0.2)

在语义空间里，「今天天气真好」和「今天阳光明媚」靠得近（意思相近），和「苹果很好吃」离得远（不相关）。

二维语义空间示意：意思相近的文本在空间中靠得近

当然，现实中的语义向量不是两维，而是几百甚至几千维——但原理一样。两个向量在空间中的距离越近，代表它们的意思越相近。

语义从哪来：Embedding 模型怎么训练的

刚才的水果例子是我手动编的维度（甜度、大小）。但在真实场景中，不可能有人来给每个词标注「甜度 = 0.9」这种数据。

那向量的数值从哪来？答案是 Embedding 模型自己学出来的。

训练方法的核心思路很简单：出现在相似语境中的词，应该有相似的向量。

一个经典的例子：

「国王」和「女王」经常出现在类似的句子里（「__ 统治着国家」「__ 戴着一顶王冠」）。所以它们的向量应该离得近。

「国王」和「苹果」很少出现在同一个语境里。所以它们的向量应该离得远。

训练时，模型会读海量的文本，对每个词做一个调整：如果两个词经常出现在相似的上下文里，就把它们的向量拉近一点；如果很少同时出现，就把它们推远一点。

经过无数次这样的调整，模型最终学会了一个语义空间——意思相近的词，在空间里靠得近；意思不相关的词，离得远。

这一步就是 Embedding 模型做的事。你给它输入一段文本，它返回一组向量。

%%{init: {'theme':'neutral'}}%%
graph LR
 A["输入文本
去年第三季度赚了多少"] --> B[Embedding 模型]
 B --> C["输出向量
[0.23, -0.56, 0.91, ...]"]

 style A fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style B fill:#d1fae5,stroke:#10b981,color:#064e3b
 style C fill:#fce7f3,stroke:#ec4899,color:#831843

如何判断两个向量离得近

有了向量之后，怎么计算两段文字的相似度？

最常用的方法叫余弦相似度（Cosine Similarity）。你不需要记住公式，只要理解它的直觉：

两个向量在空间中有一个夹角。夹角越小，说明方向越一致，内容越相似。

完全相同的文本 → 夹角 0°，相似度 = 1
完全不相关的文本 → 夹角 90°，相似度 ≈ 0
意思相反的文本 → 夹角 180°，相似度 = -1

%%{init: {'theme':'neutral'}}%%
graph LR
 A["文本A: 今天天气真好"] --> C[Embedding 模型]
 B["文本B: 今天阳光明媚"] --> C
 C --> D["向量A: [0.8, 0.5, ...]
向量B: [0.7, 0.6, ...]"]
 D --> E["余弦相似度 = 0.92
✅ 意思相近"]

 style A fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style B fill:#dbeafe,stroke:#3b82f6,color:#1e3a5f
 style C fill:#d1fae5,stroke:#10b981,color:#064e3b
 style D fill:#fce7f3,stroke:#ec4899,color:#831843
 style E fill:#d1fae5,stroke:#10b981,color:#064e3b

回到 RAG：向量检索就是这样工作的

RAG 的检索过程，就是把上面的逻辑倒过来：

入库时：把每篇文档的每个片段都通过 Embedding 模型转成向量，存进向量数据库
查询时：把用户的问题也转成向量
匹配时：计算问题向量和所有文档向量的余弦相似度，找出最接近的那几个片段

用户问题：去年第三季度我们赚了多少钱？
 │
 ▼ Embedding 模型
 │
[0.23, -0.56, 0.91, ...]
 │
 ▼ 跟库里所有文档向量算相似度
 │
文档中匹配到的内容：Q3营收同比增长15.3%（相似度 0.87）
 去年全年营收1.2亿元（相似度 0.45）
 公司成立于2018年（相似度 0.12）
 │
 ▼ 取 Top-K，拼入 Prompt
 │
LLM 基于这些内容生成回答

向量检索不只是「找到包含关键词的文档」，而是「找到意思最相近的内容」。这也解释了为什么在 RAG 中，分块和向量化的质量决定了检索的天花板——如果文档切得不好、向量化得不准确，后面用多好的 LLM 也弥补不了。

参考资料

Mikolov et al., Efficient Estimation of Word Representations in Vector Space, arXiv:1301.3781, 2013 — Word2Vec，向量化技术的奠基论文
Reimers & Gurevych, Sentence-BERT: Sentence Embeddings using Siamese BERT-Networks, EMNLP 2019 — 现代 Embedding 模型的基础架构
Datawhale, hello-agents, 第八章记忆与检索, https://github.com/datawhalechina/hello-agents — 从认知科学到向量检索的实践教程