LlamaIndex on 酒中仙

向量数据库中的索引优化

Thu, 02 Apr 2026 23:14:25 -0800

向量数据库中的索引优化

在上一章的文本分块部分，已经简单介绍了一些索引优化的策略。本节将基于 LlamaIndex 的高性能生产级RAG构建方案¹，对索引优化进行更深入的探讨。

一、上下文扩展

在RAG系统中，常常面临一个权衡问题：使用小块文本进行检索可以获得更高的精确度，但小块文本缺乏足够的上下文，可能导致大语言模型（LLM）无法生成高质量的答案；而使用大块文本虽然上下文丰富，却容易引入噪音，降低检索的相关性。为了解决这一矛盾，LlamaIndex 提出了一种实用的索引策略——句子窗口检索（Sentence Window Retrieval）²。该技术巧妙地结合了两种方法的优点：它在检索时聚焦于高度精确的单个句子，在送入LLM生成答案前，又智能地将上下文扩展回一个更宽的“窗口”，从而同时保证检索的准确性和生成的质量。

1.1 主要思路

句子窗口检索的思想可以概括为：为检索精确性而索引小块，为上下文丰富性而检索大块。

其工作流程如下：

（1）索引阶段：在构建索引时，文档被分割成单个句子。每个句子都作为一个独立的“节点（Node）”存入向量数据库。同时，每个句子节点都会在元数据（metadata）中存储其上下文窗口，即该句子原文中的前N个和后N个句子。这个窗口内的文本不会被索引，仅仅是作为元数据存储。

（2）检索阶段：当用户发起查询时，系统会在所有单一句子节点上执行相似度搜索。因为句子是表达完整语义的最小单位，所以这种方式可以非常精确地定位到与用户问题最相关的核心信息。

（3）后处理阶段：在检索到最相关的句子节点后，系统会使用一个名为 MetadataReplacementPostProcessor 的后处理模块。该模块会读取到检索到的句子节点的元数据，并用元数据中存储的完整上下文窗口来替换节点中原来的单一句子内容。

（4）生成阶段：最后，这些被替换了内容的、包含丰富上下文的节点被传递给LLM，用于生成最终的答案。

1.2 代码实现

下面通过 LlamaIndex 官网的示例，来演示如何实现句子窗口检索，并与常规的检索方法进行对比。该示例将加载一份PDF格式的IPCC气候报告，并就其中的专业问题进行提问。

核心代码如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16


# 假设 Settings.llm 和 Settings.embed_model 已经预先配置好

# 1. 加载文档
documents = SimpleDirectoryReader(
 input_files=["../../data/C3/pdf/IPCC_AR6_WGII_Chapter03.pdf"]
).load_data()

# 2. 创建节点与构建索引
# 2.1 句子窗口索引
node_parser = SentenceWindowNodeParser.from_defaults(
 window_size=3,
 window_metadata_key="window",
 original_text_metadata_key="original_text",
)
sentence_nodes = node_parser.get_nodes_from_documents(documents)
sentence_index = VectorStoreIndex(sentence_nodes)

根据 LlamaIndex 的底层源码，SentenceWindowNodeParser 的核心逻辑位于 build_window_nodes_from_documents 方法中。其实现过程可以分解为以下几个关键步骤：

（1）句子切分 (sentence_splitter) ：解析器首先接收一个文档（Document），然后调用 self.sentence_splitter(doc.text) 方法。这个 sentence_splitter 是一个可配置的函数，默认为 split_by_sentence_tokenizer，它负责将文档的全部文本精确地切分成一个句子列表（text_splits）。

（2）创建基础节点 (build_nodes_from_splits) ：切分出的 text_splits 列表被传递给 build_nodes_from_splits 工具函数。这个函数会为列表中的每一个句子都创建一个独立的 TextNode。此时，每个 TextNode 的 text 属性就是这个句子的内容。

（3）构建窗口并填充元数据 (主要循环) ：接下来，解析器会遍历所有新创建的 TextNode。对于位于第 i 个位置的节点，它会执行以下操作：

定位窗口：通过列表切片 nodes[max(0, i - self.window_size) : min(i + self.window_size + 1, len(nodes))] 来获取一个包含中心句子及其前后 window_size（默认为3）个邻近节点的列表（window_nodes）。这个切片操作很巧妙地处理了文档开头和结尾的边界情况。
组合窗口文本：将 window_nodes 列表中所有节点的 text（即所有在窗口内的句子）用空格拼接成一个长字符串。
填充元数据：将上一步生成的长字符串（完整的上下文窗口）存入当前节点（第i个节点）的元数据中，键为 self.window_metadata_key（默认为 "window"）。同时，也会将节点自身的文本（原始句子）存入元数据，键为 self.original_text_metadata_key（默认为 "original_text"）。

设置元数据排除项：这是一个非常关键的细节。在填充完元数据后，代码会执行 node.excluded_embed_metadata_keys.extend(...) 和 node.excluded_llm_metadata_keys.extend(...)。这行代码的作用是告诉后续的嵌入模型和LLM，在处理这个节点时，应当忽略 "window" 和 "original_text" 这两个元数据字段。这确保了只有单个句子的纯净文本被用于生成向量嵌入，从而保证了检索的高精度。而 "window" 字段仅供后续的 MetadataReplacementPostProcessor 使用。

通过以上步骤，SentenceWindowNodeParser 最终返回一个 TextNode 列表。列表中的每个节点都代表一个独立的句子，其 text 属性用于精确检索，而其 metadata 中则“隐藏”了用于生成答案的丰富上下文窗口。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25


# 2.2 常规分块索引 (基准)
base_parser = SentenceSplitter(chunk_size=512)
base_nodes = base_parser.get_nodes_from_documents(documents)
base_index = VectorStoreIndex(base_nodes)

# 3. 构建查询引擎
sentence_query_engine = sentence_index.as_query_engine(
 similarity_top_k=2,
 node_postprocessors=[
 MetadataReplacementPostProcessor(target_metadata_key="window")
 ],
)
base_query_engine = base_index.as_query_engine(similarity_top_k=2)

# 4. 执行查询并对比结果
query = "What are the concerns surrounding the AMOC?"
print(f"查询: {query}\n")

print("--- 句子窗口检索结果 ---")
window_response = sentence_query_engine.query(query)
print(f"回答: {window_response}\n")

print("--- 常规检索结果 ---")
base_response = base_query_engine.query(query)
print(f"回答: {base_response}\n")

（1）构建句子窗口索引：这一步利用了 SentenceWindowNodeParser。它将文档解析为以单个句子为单位的 Node，同时将包含上下文的“窗口”文本（默认为前后各3个句子）存储在每个 Node 的元数据中。这一步是实现“为检索精确性而索引小块”思想的关键。

（2）构建查询引擎与后处理：查询引擎的构建是实现“为生成质量而扩展上下文”的关键。

在创建 sentence_query_engine 时，配置中加入了一个重要的后处理器 MetadataReplacementPostProcessor。
它的作用是：当检索器根据用户查询找到最相关的节点（也就是单个句子）后，这个后处理器会立即介入。
它会从该节点的元数据中读取出预先存储的完整“窗口”文本，并用它替换掉节点中原来的单个句子内容。
这样，最终传递给大语言模型的就不再是孤立的句子，而是包含丰富上下文的完整文本段落，从而确保了生成答案的质量和连贯性。

我们向两个引擎提出的问题是：“关于大西洋经向翻转环流（AMOC），人们主要担忧什么？” (What are the concerns surrounding the AMOC?)。

代码输出如下：

1
2
3
4
5
6
7


查询: What are the concerns surrounding the AMOC?

--- 句子窗口检索结果 ---
回答: The Atlantic Meridional Overturning Circulation (AMOC) is projected to decline over the 21st century with high confidence, though there is low confidence in quantitative projections of this decline. Observational records since the mid-2000s are too short to determine the relative contributions of internal variability, natural forcing, and anthropogenic forcing to AMOC changes. Additionally, there is low confidence in reconstructed and modeled AMOC changes for the 20th century due to limited agreement in quantitative trends. While an abrupt collapse before 2100 is not expected, the decline could have significant implications for global climate patterns.

--- 常规检索结果 ---
回答: The concerns surrounding the Atlantic Meridional Overturning Circulation (AMOC) primarily involve its projected decline over the 21st century across all Shared Socioeconomic Pathway (SSP) scenarios. While an abrupt collapse before 2100 is not expected, there is high confidence in this decline, though quantitative projections remain uncertain. Observational records since the mid-2000s are too short to clearly distinguish the contributions of internal variability, natural forcing, and anthropogenic forcing to these changes. This uncertainty highlights the need for further research to better understand and predict AMOC behavior and its broader climate impacts.

从输出结果中可以观察到：

两个答案都抓住了核心：两个引擎都正确地识别出，对AMOC的主要担忧是其在21世纪预计的衰退。
句子窗口检索的答案更详尽、更连贯：句子窗口检索的回答不仅指出了衰退的趋势，还补充了关于“定量预测的置信度低”、“观测记录时间过短”、“20世纪重建和模拟的变化置信度低”等多个维度的细节。这使得答案的信息量更大，上下文更完整，更像一个综述。
常规检索的答案相对宽泛：常规检索的回答虽然正确，但内容相对概括，最后以“需要进一步研究”这样较为笼同的结论收尾。

这种差异正是句子窗口检索策略优势的体现。它通过“精确检索小文本块（单个句子），再扩展上下文（句子窗口）”的方式，为大语言模型提供了高度相关且信息丰富的上下文，从而生成了质量更高的答案。

完整代码

二、结构化索引

随着知识库的规模不断扩大（例如，包含数百个PDF文件），传统的RAG方法（即对所有文本块进行top-k相似度搜索）会遇到瓶颈。当一个查询可能只与其中一两个文档相关时，在整个文档库中进行无差别的向量搜索，不仅效率低下，还容易被不相关的文本块干扰，导致检索结果不精确。

为了解决这个问题，一个有效的方法是利用结构化索引。其原理是在索引文本块的同时，为其附加结构化的元数据（Metadata）。这些元数据可以是任何有助于筛选和定位信息的标签，例如：

文件名
文档创建日期
章节标题
作者
任何自定义的分类标签

实际上，在第二章“文本分块”中介绍的基于文档结构的分块方法，就是实现结构化索引的一种前置步骤。例如，在使用 MarkdownHeaderTextSplitter 时，分块器会自动将Markdown文档的各级标题（如 Header 1, Header 2 等）提取并存入每个文本块的元数据中。这些标题信息就是非常有价值的结构化数据，可以直接用于后续的元数据过滤。

通过这种方式，可以在检索时实现“元数据过滤”和“向量搜索”的结合。例如，当用户查询“请总结一下2023年第二季度财报中关于AI的论述”时，系统可以：

（1）元数据预过滤：首先通过元数据筛选，只在 document_type == '财报'、year == 2023 且 quarter == 'Q2' 的文档子集中进行搜索。

（2）向量搜索：然后，在经过滤的、范围更小的文本块集合中，执行针对查询“关于AI的论述”的向量相似度搜索。

这种“先过滤，再搜索”的策略，能够极大地缩小检索范围，显著提升大规模知识库场景下RAG应用的检索效率和准确性。LlamaIndex 提供了包括“自动检索”（Auto-Retrieval）在内的多种工具来支持这种结构化的检索范式。

2.1 代码实现：基于多表格的递归检索

在更复杂的场景中，结构化数据可能分布在多个来源中，例如一个包含多个工作表（Sheet）的 Excel 文件，每个工作表都代表一个独立的表格。在这种情况下，需要一种更强大的策略：递归检索³。它能实现“路由”功能，先将查询引导至正确的知识来源（正确的表格），然后再在该来源内部执行精确查询。

下面使用一个包含多个工作表的电影数据 Excel 文件（movie.xlsx）来演示，其中每个工作表（如 年份_1994, 年份_2002 等）都存储了对应年份的电影信息。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39


# 1. 为每个工作表创建查询引擎和摘要节点
excel_file = '../../data/C3/excel/movie.xlsx'
xls = pd.ExcelFile(excel_file)

df_query_engines = {}
all_nodes = []

for sheet_name in xls.sheet_names:
 df = pd.read_excel(xls, sheet_name=sheet_name)
 # 为当前工作表创建一个 PandasQueryEngine
 query_engine = PandasQueryEngine(df=df, llm=Settings.llm, verbose=True)
 # 为当前工作表创建一个摘要节点（IndexNode）
 year = sheet_name.replace('年份_', '')
 summary = f"这个表格包含了年份为 {year} 的电影信息，可以用来回答关于这一年电影的具体问题。"
 node = IndexNode(text=summary, index_id=sheet_name)
 all_nodes.append(node)
 # 存储工作表名称到其查询引擎的映射
 df_query_engines[sheet_name] = query_engine

# 2. 创建顶层索引（只包含摘要节点）
vector_index = VectorStoreIndex(all_nodes)

# 3. 创建递归检索器
vector_retriever = vector_index.as_retriever(similarity_top_k=1)
recursive_retriever = RecursiveRetriever(
 "vector",
 retriever_dict={"vector": vector_retriever},
 query_engine_dict=df_query_engines,
 verbose=True,
)

# 4. 创建查询引擎
query_engine = RetrieverQueryEngine.from_args(recursive_retriever)

# 5. 执行查询
query = "1994年评分人数最多的电影是哪一部？"
print(f"查询: {query}")
response = query_engine.query(query)
print(f"回答: {response}")

创建 PandasQueryEngine ：遍历 Excel 中的每个工作表，为每个工作表（即一个独立的 DataFrame）都实例化一个 PandasQueryEngine。其强大之处在于，它能将关于表格的自然语言问题（如“评分人数最多的是哪个”）转换成实际的 Pandas 代码（如 df.sort_values('评分人数').iloc[-1]）来执行。
创建摘要节点 (IndexNode) ：对每个工作表，都创建一个 IndexNode，其内容是关于这个表格的一段摘要文本。这个节点将作为顶层检索的“指针”。
构建顶层索引 ：使用所有创建的 IndexNode 构建一个 VectorStoreIndex。这个索引不包含任何表格的详细数据，只包含指向各个表格的“指针”信息。
创建 RecursiveRetriever ：这是实现递归检索的核心。将其配置为：
- retriever_dict: 指定顶层的检索器，即在摘要节点中进行检索的 vector_retriever。
- query_engine_dict: 提供一个从节点 ID（即工作表名称）到其对应查询引擎的映射。当顶层检索器匹配到某个摘要节点后，递归检索器就知道该调用哪个 PandasQueryEngine 来处理后续查询。

运行结果：

1
2
3
4
5


查询: 1994年评分人数最少的电影是哪一部？
> Retrieving with query id None: 1994年评分人数最少的电影是哪一部？
> Retrieved node with id, entering: 年份_1994
> Retrieving with query id 年份_1994: 1994年评分人数最少的电影是哪一部？
> Pandas Instructions:

df[df[‘年份’] == 1994].nsmallest(1, ‘评分人数’)[‘电影名称’].iloc[0]

1
2


> Pandas Output: 燃情岁月
回答: 燃情岁月

从输出中可以清晰地看到递归检索的完整流程：

（1）顶层路由：Retrieving with query id None，系统首先在顶层的摘要索引中检索，根据问题“1994年…”匹配到了摘要节点 年份_1994。

（2）进入子层：Retrieved node with id, entering: 年份_1994，系统决定进入与“年份_1994”这个工作表关联的查询引擎。

（3）子层查询：Retrieving with query id 年份_1994，PandasQueryEngine 接管查询，并将问题发送给 LLM，让其生成 Pandas 代码。

（4）代码生成与执行：LLM 生成了 df[df['年份'] == 1994].nsmallest(1, '评分人数')['电影名称'].iloc[0]，引擎执行后得到输出 燃情岁月。

完整代码

⚠️ 重要安全警告：实际上在 LlamaIndex 的官网有提到，PandasQueryEngine 是一个实验性功能，具有潜在的安全风险。它的工作原理是让 LLM 生成 Python 代码，然后使用 eval() 函数在本地执行。这意味着，在没有严格沙箱隔离的环境下，理论上可能执行任意代码。因此，强烈不建议在生产环境中使用此工具。

2.2 另一种实现方式

鉴于 PandasQueryEngine 的安全风险，还可以采用一种更安全的方式来实现类似的多表格查询，思路是将路由和检索彻底分离。

这种改进方法的具体步骤如下：

（1）创建两个独立的向量索引：

摘要索引（用于路由）：为每个Excel工作表（例如，“1994年电影数据”）创建一个非常简短的摘要性Document，例如：“此文档包含1994年的电影信息”。然后，用所有这些摘要文档构建一个轻量级的向量索引。这个索引的唯一目的就是充当“路由器”。
内容索引（用于问答）：将每个工作表的实际数据（例如，整个表格）转换为一个大的文本Document，并为其附加一个关键的元数据标签，如 {"sheet_name": "年份_1994"}。然后，用所有这些包含真实内容的文档构建一个向量索引。

（2）执行两步查询：

第一步：路由。当用户提问（例如，“1994年评分人数最少的电影是哪一部？”）时，首先在“摘要索引”中进行检索。由于问题中的“1994年”与“此文档包含1994年的电影信息”这个摘要高度相关，检索器会快速返回其对应的元数据，告诉系统目标是 年份_1994 这个工作表。
第二步：检索。拿到 年份_1994 这个目标后，系统会在“内容索引”中进行检索，但这次会附加一个元数据过滤器（MetadataFilter），强制要求只在 sheet_name == "年份_1994" 的文档中进行搜索。这样，LLM就能在正确的、经过筛选的数据范围内找到问题的答案。

通过这种“先路由，后用元数据过滤检索”的方式，既实现了跨多个数据源的查询能力，又避免了执行代码的安全隐患。LlamaIndex 官方也提供了类似的结构化分层检索⁴可以参考。

完整代码

题外话：关于框架

有些人可能疑惑，为什么本教程不专注于一个框架（如 LlamaIndex 或 LangChain），而是混合使用，甚至造轮子？

框架是加速开发的强大工具，是帮助我们快速跨越技术鸿沟的“桥梁”。但任何桥梁都有其设计边界和局限性。我们的目标不是成为一个熟练的“过桥者”，而是成为一个懂得如何设计和建造桥梁的“工程师”。

因此，本教程选择的路径是：

（1）以原理为主：我们优先关心的是“它是如何工作的？”而不是“我该调用哪个函数？”。理解了底层的思想，你将能更快地掌握任何现有或未来的框架。

（2）拥抱灵活性：真实世界的业务需求往往比框架预设的场景更复杂。当框架无法满足需求，或者像本节使用的 PandasQueryEngine 那样存在安全隐患时，懂得原理的话，就有能力去修改它，或者像本节的示例一样，用更底层的模块组合出更安全、合适的解决方案。

（3）培养解决问题的能力：只学习使用框架，好比是照着菜谱做菜，虽然能快速复刻出指定的菜肴，但一旦缺少某个食材或遇到意外情况，就可能束手无策。而理解原理，则像是学会了烹饪的精髓。这让你不仅能轻松地做出各种美食，还能创造新菜式。

如果你希望深入某个框架的细节，它的官方文档永远是最好、最权威的学习资料。而本教程的使命，是帮助你建立起关于 RAG 的坚实知识体系，让你无论面对何种工具，都能游刃有余。

参考文献

RAG 中的数据准备

Tue, 31 Mar 2026 20:40:25 -0800

RAG 中的数据准备

第一节数据加载

虽然本节内容在实际应用中非常重要，但是由于各种文档加载器的迭代更新，以及各类 AI 应用的不同需求，具体选择需要根据实际情况。本节仅作简单引入，但请务必重视数据加载环节，“垃圾进，垃圾出 (Garbage In, Garbage Out)” ——高质量输入是高质量输出的前提。

一、文档加载器

1.1 主要功能

RAG 系统中，数据加载是整个流水线的第一步，也是不可或缺的一步。文档加载器负责将各种格式的非结构化文档（如PDF、Word、Markdown、HTML等）转换为程序可以处理的结构化数据。数据加载的质量会直接影响后续的索引构建、检索效果和最终的生成质量。

文档加载器在 RAG 的数据管道中一般需要完成三个核心任务，一是解析不同格式的原始文档，将 PDF、Word、Markdown 等内容提取为可处理的纯文本，二是在解析过程中同时抽取文档来源、页码、作者等关键信息作为元数据，三是把文本和元数据整理成统一的数据结构，方便后续进行切分、向量化和入库，其整体流程与传统数据工程中的抽取、转换、加载相似，目标都是把杂乱的原始文档清洗并对齐为适合检索和建模的标准化语料。

1.2 当前主流RAG文档加载器

表 2-1 当前主流 RAG 文档加载器

工具名称	特点	适用场景	性能表现
PyMuPDF4LLM	PDF→Markdown转换，OCR+表格识别	科研文献、技术手册	开源免费，GPU加速
TextLoader	基础文本文件加载	纯文本处理	轻量高效
DirectoryLoader	批量目录文件处理	混合格式文档库	支持多格式扩展
Unstructured	多格式文档解析	PDF、Word、HTML等	统一接口，智能解析
FireCrawlLoader	网页内容抓取	在线文档、新闻	实时内容获取
LlamaParse	深度PDF结构解析	法律合同、学术论文	解析精度高，商业API
Docling	模块化企业级解析	企业合同、报告	IBM生态兼容
Marker	PDF→Markdown，GPU加速	科研文献、书籍	专注PDF转换
MinerU	多模态集成解析	学术文献、财务报表	集成LayoutLMv3+YOLOv8

第二节文本分块

一、理解文本分块

文本分块（Text Chunking）是构建 RAG 流程的关键步骤。它的原理是将加载后的长篇文档，切分成更小、更易于处理的单元。这些被切分出的文本块，是后续向量检索和模型处理的基本单位。

二、文本分块重要性

2.1 满足模型上下文限制

将文本分块的首要原因，是为了适应 RAG 系统中两个核心组件的硬性限制：

嵌入模型 (Embedding Model): 负责将文本块转换为向量。这类模型有严格的输入长度上限。例如，许多常用的嵌入模型（如 bge-base-zh-v1.5）的上下文窗口为512个token。任何超出此限制的文本块在输入时都会被截断，导致信息丢失，生成的向量也无法完整代表原文的语义。因此，文本块的大小必须小于等于嵌入模型的上下文窗口。
大语言模型 (LLM): 负责根据检索到的上下文生成答案。LLM同样有上下文窗口限制（尽管通常比嵌入模型大得多，从几千到上百万token不等）。检索到的所有文本块，连同用户问题和提示词，都必须能被放入这个窗口中。如果单个块过大，可能会导致只能容纳少数几个相关的块，限制了LLM回答问题时可参考的信息广度。

因此，分块是确保文本能够被两个模型完整、有效处理的基础。

2.2 为何“块”不是越大越好

假设嵌入模型最多能处理 8192 个 token，是否应该把块切得尽可能大（比如8000个token）呢？答案是否定的。块的大小并非越大越好，过大的块会严重影响RAG系统的性能。

2.2.1 嵌入过程中的信息损失

大多数嵌入模型都基于 Transformer 编码器。其工作流程大致如下：

分词 (Tokenization): 将输入的文本块分解成一个个 token。
向量化 (Vectorization): Transformer 为每个 token 生成一个高维向量表示。
池化 (Pooling): 通过某种方法（如取 [CLS] 位的向量、对所有token向量求平均 mean pooling 等），将所有 token 的向量压缩成一个单一的向量，这个向量代表了整个文本块的语义。

[CLS] 是BERT等Transformer模型在输入文本开头添加的特殊标记，它通过自注意力机制动态聚合整个序列的上下文信息，其最终向量被训练用作代表全局语义的嵌入。

在这个压缩过程中，信息损失是不可避免的。一个768维的向量需要概括整个文本块的所有信息。文本块越长，包含的语义点越多，这个单一向量所承载的信息就越稀释，导致其表示变得笼统，关键细节被模糊化，从而降低了检索的精度。

2.2.2 生成过程的“大海捞针” (Lost in the Middle)

即使将检索到的多个大块文本都塞进LLM的长上下文窗口中，也会出现关键信息被“淹没”在大量无关内容里的问题。有研究表明 ¹，当LLM处理非常长的、充满大量信息的上下文时，它倾向于更好地记住开头和结尾的信息，而忽略中间部分的内容。

如果提供给LLM的上下文块又大又杂，充满了与问题无关的噪音，模型就很难从中提取出最关键的信息来形成答案，从而导致回答质量下降或产生幻觉。

2.2.3 主题稀释导致检索失败

一个好的文本块应该聚焦于一个明确、单一的主题。如果一个块包含太多不相关的主题，它的语义就会被稀释，导致在检索时无法被精确匹配。

举个栗子🌰：

假设有一个关于《王者荣耀》英雄鲁班七号的攻略文档。

糟糕的分块策略：将“技能介绍”、“推荐出装”和“背景故事”这三个完全不同主题的内容，全部放在一个巨大的文本块里。
- 当玩家查询“鲁班七号怎么出装？”时，这个大块虽然包含了出装信息，但由于被技能说明和英雄故事等无关主题严重稀释，其整体的检索相关性得分可能会很低，导致无法被召回。
优秀的分块策略：将“技能”、“出装”和“故事”分别切分为三个独立的、主题聚焦的块。
- 当玩家再次查询时，“推荐出装”这个块会因为与查询高度相关而获得极高的分数，从而被精准地检索出来。

通过合理分块，可以有效提升检索的信噪比，确保了后续生成环节能得到最优质、最相关的上下文。

三、基础分块策略

LangChain 提供了丰富且易于使用的文本分割器（Text Splitters），下面将介绍几种最核心的策略。

3.1 固定大小分块

这是最简单直接的分块方法。根据LangChain源码，这种方法的工作原理分为两个主要阶段：

（1）按段落分割：CharacterTextSplitter 采用默认分隔符 "\n\n"，使用正则表达式将文本按段落进行分割，通过 _split_text_with_regex 函数处理。

（2）智能合并：调用继承自父类的 _merge_splits 方法，将分割后的段落依次合并。该方法会监控累积长度，当超过 chunk_size 时形成新块，并通过重叠机制（chunk_overlap）保持上下文连续性，同时在必要时发出超长块的警告。

需要注意，CharacterTextSplitter 实际实现的并非严格的固定大小分块。根据 _merge_splits 源码逻辑，这种方法会：

优先保持段落完整性：只有当添加新段落会导致总长度超过 chunk_size 时，才会结束当前块
处理超长段落：如果单个段落超过 chunk_size，系统会发出警告但仍将其作为完整块保留
应用重叠机制：通过 chunk_overlap 参数在块之间保持内容重叠，确保上下文连续性

所以，LangChain 的实现更准确地应该称为"段落感知的自适应分块"，块大小会根据段落边界动态调整。

下面的代码展示了如何配置一个固定大小分块器：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23


from langchain_text_splitters import CharacterTextSplitter
from langchain_community.document_loaders import TextLoader

# 1. 文档加载
loader = TextLoader("./txt/蜂医.txt", encoding="utf-8")
docs = loader.load()

# 2. 初始化固定大小分块器
text_splitter = CharacterTextSplitter(
 chunk_size=200, # 每个块的大小
 chunk_overlap=10 # 块之间的重叠大小
)

# 3. 执行分块
chunks = text_splitter.split_documents(docs)

# 4. 打印结果
print(f"文本被切分为 {len(chunks)} 个块。\n")
print("--- 前5个块内容示例 ---")
for i, chunk in enumerate(chunks[:5]):
 print("=" * 60)
 # chunk 是一个 Document 对象，需要访问它的 .page_content 属性来获取文本
 print(f'块 {i+1} (长度: {len(chunk.page_content)}): "{chunk.page_content}"')

这种方法的主要优势在于实现简单、处理速度快且计算开销小。劣势在于可能会在语义边界处切断文本，影响内容的完整性和连贯性。实际的固定大小分块实现（如LangChain的 CharacterTextSplitter）通常会结合分隔符来减少这种问题，在段落边界处优先切分，只有在必要时才会强制按大小切断。因此，这种方法在日志分析、数据预处理等场景中仍有其应用价值。

3.2 递归字符分块

在前面的章节中，已经尝试了使用 RecursiveCharacterTextSplitter 的默认配置来处理文档分块。现在让我们深入了解 RecursiveCharacterTextSplitter 的实现。这种分块器通过分隔符层级递归处理，相对与固定大小分块，改善了超长文本的处理效果。

算法流程：（1）寻找有效分隔符: 从分隔符列表中从前到后遍历，找到第一个在当前文本中存在的分隔符。如果都不存在，使用最后一个分隔符（通常是空字符串 ""）。

（2）切分与分类处理: 使用选定的分隔符切分文本，然后遍历所有片段：

如果片段不超过块大小: 暂存到 _good_splits 中，准备合并
如果片段超过块大小:
- 首先，将暂存的合格片段通过 _merge_splits 合并成块
- 然后，检查是否还有剩余分隔符：
  - 有剩余分隔符: 递归调用 _split_text 继续分割
  - 无剩余分隔符: 直接保留为超长块

（3）最终处理: 将剩余的暂存片段合并成最后的块

实现细节：

批处理机制: 先收集所有合格片段（_good_splits），遇到超长片段时才触发合并操作。
递归终止条件: 关键在于 if not new_separators 判断。当分隔符用尽时（new_separators 为空），停止递归，直接保留超长片段。确保算法不会无限递归。

与固定大小分块的关键差异：

固定大小分块遇到超长段落时只能发出警告并保留。
递归分块会继续使用更细粒度的分隔符（句子→单词→字符）直到满足大小要求。

具体示例如下：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13


from langchain.text_splitter import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import TextLoader

loader = TextLoader("../../data/C2/txt/蜂医.txt")
docs = loader.load()

text_splitter = RecursiveCharacterTextSplitter(
 separators=["\n\n", "\n", "。", "，", " ", ""], # 分隔符优先级
 chunk_size=200,
 chunk_overlap=10,
)

chunks = text_splitter.split_text(docs)

分隔符配置：

默认分隔符：["\n\n", "\n", " ", ""]

多语言支持：对于无词边界语言（中文、日文、泰文），可添加：

1
2
3
4
5
6
7


separators=[
 "\n\n", "\n", " ",
 ".", ",", "\u200b", # 零宽空格(泰文、日文)
 "\uff0c", "\u3001", # 全角逗号、表意逗号
 "\uff0e", "\u3002", # 全角句号、表意句号
 ""
]

编程语言特化支持：

RecursiveCharacterTextSplitter 能够针对特定的编程语言（如Python, Java等）使用预设的、更符合代码结构的分隔符。它们通常包含语言的顶级语法结构（如类、函数定义）和次级结构（如控制流语句），以实现更符合代码逻辑的分割。

1
2
3
4
5
6


# 针对代码文档的优化分隔符
splitter = RecursiveCharacterTextSplitter.from_language(
 language=Language.PYTHON, # 支持Python、Java、C++等
 chunk_size=500,
 chunk_overlap=50
)

递归字符分块的原理是采用一组有层次结构的分隔符（如段落、句子、单词）进行递归分割，旨在有效平衡语义完整性与块大小控制。在 RecursiveCharacterTextSplitter 的实现中，该分块器首先尝试使用最高优先级的分隔符（如段落标记）来切分文本。如果切分后的块仍然过大，会继续对这个大块应用下一优先级分隔符（如句号），如此循环往复，直到块满足大小限制。这种分层处理的机制，能够在尽可能保持高级语义结构完整性的同时，有效控制块大小。

完整代码如下所示：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31


from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_community.document_loaders import TextLoader

loader = TextLoader("./txt/蜂医.txt", encoding="utf-8")
docs = loader.load()

old_separators=["\n\n", "\n", "。", "，", " ", ""], # 按顺序尝试分割

new_separators=[
 "\n\n", "\n", " ",
 ".", ",", "\u200b", # 零宽空格(泰文、日文)
 "\uff0c", "\u3001", # 全角逗号、表意逗号
 "\uff0e", "\u3002", # 全角句号、表意句号
 ""
]


text_splitter = RecursiveCharacterTextSplitter(
 # 针对中英文混合文本，定义一个更全面的分隔符列表
 separators=new_separators,
 chunk_size=200,
 chunk_overlap=10
)

chunks = text_splitter.split_documents(docs)

print(f"文本被切分为 {len(chunks)} 个块。\n")
print("--- 前5个块内容示例 ---")
for i, chunk in enumerate(chunks[:5]):
 print("=" * 60)
 print(f'块 {i+1} (长度: {len(chunk.page_content)}): "{chunk.page_content}"')

3.3 语义分块

语义分块（Semantic Chunking）是一种更智能的方法，这种方法不依赖于固定的字符数或预设的分隔符，而是尝试根据文本的语义内涵来切分。其核心是：在语义主题发生显著变化的地方进行切分。这使得每个分块都具有高度的内部语义一致性。LangChain 提供了 langchain_experimental.text_splitter.SemanticChunker 来实现这一功能。

实现原理

SemanticChunker 的工作流程可以概括为以下几个步骤：

（1）句子分割 (Sentence Splitting)：首先，使用标准的句子分割规则（例如，基于句号、问号、感叹号）将输入文本拆分成一个句子列表。

（2）上下文感知嵌入 (Context-Aware Embedding)：这是 SemanticChunker 的一个关键设计。该分块器不是对每个句子独立进行嵌入，而是通过 buffer_size 参数（默认为1）来捕捉上下文信息。对于列表中的每一个句子，这种方法会将其与前后各 buffer_size 个句子组合起来，然后对这个临时的、更长的组合文本进行嵌入。这样，每个句子最终得到的嵌入向量就融入了其上下文的语义。

（3）计算语义距离 (Distance Calculation)：计算每对相邻句子的嵌入向量之间的余弦距离。这个距离值量化了两个句子之间的语义差异——距离越大，表示语义关联越弱，跳跃越明显。

（4）识别断点 (Breakpoint Identification)：SemanticChunker 会分析所有计算出的距离值，并根据一个统计方法（默认为 percentile）来确定一个动态阈值。例如，它可能会将所有距离中第95百分位的值作为切分阈值。所有距离大于此阈值的点，都被识别为语义上的“断点”。

（5）合并成块 (Merging into Chunks)：最后，根据识别出的所有断点位置，将原始的句子序列进行切分，并将每个切分后的部分内的所有句子合并起来，形成一个最终的、语义连贯的文本块。

断点识别方法 (breakpoint_threshold_type)

如何定义“显著的语义跳跃”是语义分块的关键。SemanticChunker 提供了几种基于统计的方法来识别断点：

percentile (百分位法 - 默认方法):
- 逻辑: 计算所有相邻句子的语义差异值，并将这些差异值进行排序。当一个差异值超过某个百分位阈值时，就认为该差异值是一个断点。
- 参数: breakpoint_threshold_amount (默认为 95)，表示使用第95个百分位作为阈值。这意味着，只有最显著的5%的语义差异点会被选为切分点。
standard_deviation (标准差法):
- 逻辑: 计算所有差异值的平均值和标准差。当一个差异值超过“平均值 + N * 标准差”时，被视为异常高的跳跃，即断点。
- 参数: breakpoint_threshold_amount (默认为 3)，表示使用3倍标准差作为阈值。
interquartile (四分位距法):
- 逻辑: 使用统计学中的四分位距（IQR）来识别异常值。当一个差异值超过 Q3 + N * IQR 时，被视为断点。
- 参数: breakpoint_threshold_amount (默认为 1.5)，表示使用1.5倍的IQR。
gradient (梯度法):
- 逻辑: 这是一种更复杂的方法。它首先计算差异值的变化率（梯度），然后对梯度应用百分位法。对于那些句子间语义联系紧密、差异值普遍较低的文本（如法律、医疗文档）特别有效，因为这种方法能更好地捕捉到语义变化的“拐点”。
- 参数: breakpoint_threshold_amount (默认为 95)。

具体示例如下

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26


from langchain_experimental.text_splitter import SemanticChunker
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_community.document_loaders import TextLoader

embeddings = HuggingFaceEmbeddings(
 model_name="BAAI/bge-small-zh-v1.5",
 model_kwargs={'device': 'cpu'},
 encode_kwargs={'normalize_embeddings': True}
)

# 初始化 SemanticChunker
text_splitter = SemanticChunker(
 embeddings,
 breakpoint_threshold_type="percentile" # 也可以是 "standard_deviation", "interquartile", "gradient"
)

loader = TextLoader("./txt/蜂医.txt", encoding="utf-8")
documents = loader.load()

docs = text_splitter.split_documents(documents)

print(f"文本被切分为 {len(docs)} 个块。\n")
print("--- 前2个块内容示例 ---")
for i, chunk in enumerate(docs[:2]):
 print("=" * 60)
 print(f'块 {i+1} (长度: {len(chunk.page_content)}):\n"{chunk.page_content}"')

3.4 基于文档结构的分块

对于具有明确结构标记的文档格式（如Markdown、HTML、LaTex），可以利用这些标记来实现更智能、更符合逻辑的分割。

以 Markdown 结构分块为例

针对结构清晰的 Markdown 文档，利用其标题层级进行分块是一种高效且保留了丰富语义的方法。LangChain 提供了 MarkdownHeaderTextSplitter 来处理。

实现原理: 该分块器的主要逻辑是“先按标题分组，再按需细分”。
1. 定义分割规则: 用户首先需要提供一个标题层级的映射关系，例如 [ ("#", "Header 1"), ("##", "Header 2") ]，告诉分块器 # 是一级标题，## 是二级标题。
2. 内容聚合: 分块器会遍历整个文档，将每个标题下的所有内容（直到下一个同级或更高级别的标题出现前）聚合在一起。每个聚合后的内容块都会被赋予一个包含其完整标题路径的元数据。
元数据注入的优势: 这是此方法的主要特点。例如，对于一篇关于机器学习的文章，某个段落可能位于“第三章：模型评估”下的“3.2节：评估指标”中。经过分割后，这个段落形成的文本块，其元数据就会是 {"Header 1": "第三章：模型评估", "Header 2": "3.2节：评估指标"}。这种元数据为每个块提供了精确的“地址”，极大地增强了上下文的准确性，让大模型能更好地理解信息片段的来源和背景。
局限性与组合使用: 单纯按标题分割可能会导致一个问题：某个章节下的内容可能非常长，远超模型能处理的上下文窗口。为了解决这个问题，MarkdownHeaderTextSplitter 可以与其它分块器（如 RecursiveCharacterTextSplitter）组合使用。具体流程是：
- 第一步，使用 MarkdownHeaderTextSplitter 将文档按标题分割成若干个大的、带有元数据的逻辑块。
- 第二步，对这些逻辑块再应用 RecursiveCharacterTextSplitter，将其进一步切分为符合 chunk_size 要求的小块。由于这个过程是在第一步之后进行的，所有最终生成的小块都会继承来自第一步的标题元数据。
RAG应用优势: 这种两阶段的分块方法，既保留了文档的宏观逻辑结构（通过元数据），又确保了每个块的大小适中，是处理结构化文档进行RAG的理想方案。

四、其他开源框架中的分块策略

4.1 Unstructured：基于文档元素的智能分块

Unstructured是一个强大的文档处理工具，同样提供了实用的分块功能。

（1）分区 (Partitioning): 这是一个重要功能，负责将原始文档（如PDF、HTML）解析成一系列结构化的“元素”（Elements）。每个元素都带有语义标签，如 Title (标题)、NarrativeText (叙述文本)、ListItem (列表项) 等。这个过程本身就完成了对文档的深度理解和结构化。

（2）分块 (Chunking): 该功能建立在分区的结果之上。分块功能不是对纯文本进行操作，而是将分区产生的“元素”列表作为输入，进行智能组合。Unstructured 提供了两种主要的分块方法：

basic: 这是默认方法。这种方法会连续地组合文档元素（如段落、列表项），直到达到 max_characters 上限，尽可能地填满每个块。如果单个元素超过上限，则会对其进行文本分割。
by_title: 该方法在 basic 方法的基础上，增加了对“章节”的感知。该方法将 Title 元素视为一个新章节的开始，并强制在此处开始一个新的块，确保同一个块内不会包含来自不同章节的内容。这在处理报告、书籍等结构化文档时非常有用，效果类似于 LangChain 的 MarkdownHeaderTextSplitter，但适用范围更广。

Unstructured 允许将分块作为分区的一个参数在单次调用中完成，也支持在分区之后作为一个独立的步骤来执行分块。这种“先理解、后分割”的策略，使得 Unstructured 能在最大程度上保留文档的原始语义结构，特别是在处理版式复杂的文档时，优势尤为明显。

4.2 LlamaIndex：面向节点的解析与转换

LlamaIndex 将数据处理流程抽象为对“节点（Node）”的操作。文档被加载后，首先会被解析成一系列的“节点”，分块只是节点转换（Transformation）中的一环。

LlamaIndex 的分块体系有以下特点：

（1）丰富的节点解析器 (Node Parser): LlamaIndex 提供了大量针对特定数据格式和方法的节点解析器，可以大致分为几类：

结构感知型: 如 MarkdownNodeParser, JSONNodeParser, CodeSplitter 等，能理解并根据源文件的结构（如Markdown标题、代码函数）进行切分。
语义感知型:
- SemanticSplitterNodeParser: 与 LangChain 的 SemanticChunker 类似，这种解析器使用嵌入模型来检测句子之间的语义“断点”，在语义连续性明显减弱的地方切开，从而让每个 chunk 内部尽量连贯。
- SentenceWindowNodeParser: 这是一种巧妙的方法。该方法将文档切分成单个的句子，但在每个句子节点（Node）的元数据中，会存储其前后相邻的N个句子（即“窗口”）。这使得在检索时，可以先用单个句子的嵌入进行精确匹配，然后将包含上下文“窗口”的完整文本送给LLM，极大地提升了上下文的质量。
常规型: 如 TokenTextSplitter, SentenceSplitter 等，提供基于Token数量或句子边界的常规切分方法。

（2）灵活的转换流水线: 用户可以构建一个灵活的流水线，例如先用 MarkdownNodeParser 按章节切分文档，再对每个章节节点应用 SentenceSplitter 进行更细粒度的句子级切分。每个节点都携带丰富的元数据，记录着其来源和上下文关系。

（3）良好的互操作性: LlamaIndex 提供了 LangchainNodeParser，可以方便地将任何 LangChain 的 TextSplitter 封装成 LlamaIndex 的节点解析器，无缝集成到其处理流程中。

4.3 ChunkViz：简易的可视化分块工具

在本文开头部分展示的分块图就是通过 ChunkViz 生成的。可以将你的文档、分块配置作为输入，用不同的颜色块展示每个 chunk 的边界和重叠部分，方便快速理解分块逻辑。

参考文献

Nelson F. Liu, et al. (2023). Lost in the Middle: How Language Models Use Long Contexts. ↩︎

RAG 简介及其简单实现

Sat, 28 Mar 2026 20:40:25 -0800

RAG 简介及其简单实现

一、什么是 RAG？

1.1 核心定义

从本质上讲，RAG（Retrieval-Augmented Generation）是一种旨在解决大语言模型（LLM）“知其然不知其所以然”问题的技术范式。它的核心是将模型内部学到的“参数化知识”（模型权重中固化的、模糊的“记忆”），与来自外部知识库的“非参数化知识”（精准、可随时更新的外部数据）相结合。其运作逻辑就是在 LLM 生成文本前，先通过检索机制从外部知识库中动态获取相关信息，并将这些“参考资料”融入生成过程，从而提升输出的准确性和时效性 ¹ ² ³。

💡 一句话总结：RAG 就是让 LLM 学会了“开卷考试”，它既能利用自己学到的知识，也能随时查阅外部资料。

1.2 技术原理

那么，RAG 系统是如何实现“参数化知识”与“非参数化知识”的结合呢？如图 1-1 所示，其架构主要通过两个阶段来完成这一过程：

（1）检索阶段：寻找“非参数化知识”

知识向量化：嵌入模型（Embedding Model） 充当了“连接器”的角色。它将外部知识库编码为向量索引（Index），存入向量数据库。
语义召回：当用户发起查询时，检索模块利用同样的嵌入模型将问题向量化，并通过相似度搜索（Similarity Search），从海量数据中精准锁定与问题最相关的文档片段。

（2）生成阶段：融合两种知识

上下文整合：生成模块接收检索阶段送来的相关文档片段以及用户的原始问题。
指令引导生成：该模块会遵循预设的 Prompt 指令，将上下文与问题有效整合，并引导 LLM（如 DeepSeek）进行可控的、有理有据的文本生成。

图 1-1 RAG 双阶段架构示意图

1.3 技术演进分类

RAG 的技术架构经历了从简单到复杂的演进，如图 1-2 大致可分为三个阶段 ⁴。

图 1-2 RAG 技术演进分类

这三个阶段的具体对比如表 1-1 所示。

	初级 RAG（Naive RAG）	高级 RAG（Advanced RAG）	模块化 RAG（Modular RAG）
流程	离线: `索引` 在线: `检索 → 生成`	离线: `索引` 在线: `...→ 检索前 → ... → 检索后 → ...`	积木式可编排流程
特点	基础线性流程	增加检索前后的优化步骤	模块化、可组合、可动态调整
关键技术	基础向量检索	查询重写（Query Rewrite）结果重排（Rerank）	动态路由（Routing）查询转换（Query Transformation）多路融合（Fusion）
局限性	效果不稳定，难以优化	流程相对固定，优化点有限	系统复杂性高

表 1-1 RAG 技术演进分类对比

“离线”指提前完成的数据预处理工作（如索引构建）；“在线”指用户发起请求后的实时处理流程。

二、为什么要使用 RAG？

2.1 技术选型：RAG vs. 微调

在选择具体的技术路径时，一个重要的考量是成本与效益的平衡。通常，我们应优先选择对模型改动最小、成本最低的方案，所以技术选型路径往往遵循的顺序是提示词工程（Prompt Engineering） -> 检索增强生成 -> 微调（Fine-tuning）。

我们可以从两个维度来理解这些技术的区别。如图 1-3 所示，横轴代表“LLM 优化”，即对模型本身进行多大程度的修改。从左到右，优化的程度越来越深，其中提示工程和 RAG 完全不改变模型权重，而微调则直接修改模型参数。纵轴代表“上下文优化”，是对输入给模型的信息进行多大程度的增强。从下到上，增强的程度越来越高，其中提示工程只是优化提问方式，而 RAG 则通过引入外部知识库，极大地丰富了上下文信息。

图 1-3 选型路径图

基于此，我们的选择路径就清晰了：

先尝试提示工程：通过精心设计提示词来引导模型，适用于任务简单、模型已有相关知识的场景。
再选择 RAG：如果模型缺乏特定或实时知识而无法回答，则使用 RAG，通过外挂知识库为其提供上下文信息。
最后考虑微调：当目标是改变模型“如何做”（行为/风格/格式）而不是“知道什么”（知识）时，微调是最终且最合适的选择。例如，让模型学会严格遵循某种独特的输出格式、模仿特定人物的对话风格，或者将极其复杂的指令“蒸馏”进模型权重中。

RAG 的出现填补了通用模型与专业领域之间的鸿沟，它在解决如表 1-2 所示 LLM 局限时尤其有效：

问题	RAG的解决方案
静态知识局限	实时检索外部知识库，支持动态更新
幻觉（Hallucination）	基于检索内容生成，错误率降低
领域专业性不足	引入领域特定知识库（如医疗/法律）
数据隐私风险	本地化部署知识库，避免敏感数据泄露

表 1-2 RAG 对 LLM 局限的解决方案

2.2 关键优势

（1）准确性与可信度的双重提升

RAG 最核心的价值在于突破了模型预训练知识的限制。它不仅能补充专业领域的知识盲区，还能通过提供具体的参考材料，有效抑制“一本正经胡说八道”的幻觉现象。论文研究还表明，RAG 生成的内容在具体性和多样性上也显著优于纯 LLM。更重要的是，RAG 具备可溯源性——每一条回答都能找到对应的原始文档出处，这种“有据可查”的特性极大提高了内容在法律、医疗等严肃场景下的可信度。

（2）时效性保障

在知识更新方面，RAG 解决了 LLM 固有的知识时滞问题（即模型不知道训练截止日期之后发生的事）。RAG 允许知识库独立于模型进行动态更新——新政策或新数据一旦入库，立刻就能被检索到。这种能力在论文中被称为**“索引热拔插”（Index Hot-swapping）**——就像给机器人换一张存储卡一样，瞬间切换其世界知识库，而无需重新训练模型，实现了知识的实时在线。

（3）显著的综合成本效益

从经济角度看，RAG 是一种高性价比的方案。首先，它避免了高频微调带来的巨额算力成本；其次，由于有了外部知识的强力辅助，我们在处理特定领域问题时，往往可以使用参数量更小的基础模型来达到类似的效果，从而直接降低了推理成本。这种架构也减少了试图将海量知识强行“塞入”模型权重中所需的计算资源消耗。

（4）灵活的模块化可扩展性

RAG 的架构具备极强的包容性，支持多源集成，无论是 PDF、Word 还是网页数据，都能统一构建进知识库中。同时，其模块化设计实现了检索与生成的解耦，这意味着我们可以独立优化检索组件（比如更换更好的 Embedding 模型），而不会影响到生成组件的稳定性，便于系统的长期迭代。

2.3 适用场景风险分级

表 1-3 展示了 RAG 技术在不同风险等级场景中的适用性。

风险等级	案例	RAG适用性
低风险	翻译/语法检查	高可靠性
中风险	合同起草/法律咨询	需结合人工审核
高风险	证据分析/签证决策	需严格质量控制机制

表 1-3 RAG 适用场景风险分级

三、如何上手 RAG？

3.1 基础工具链选择

构建 RAG 系统通常涉及几个关键环节的选型。在开发模式上，我们可以利用 LangChain 或 LlamaIndex 等成熟框架快速集成，也可以选择不依赖框架的原生开发，以获得对系统流程更精细的控制力（在 AI 编程辅助下这并非难事）。而在记忆载体（向量数据库）方面，既有 Milvus、Pinecone 等适合大规模数据的方案，也有 FAISS、Chroma 等轻量级或本地化的选择，需根据具体业务规模灵活决定。后期为了量化效果，还可以引入 RAGAS 或 TruLens 等自动化评估工具。

3.2 四步构建最小可行系统（MVP）

（1）数据准备与清洗：这是系统的地基。我们需要将 PDF、Word 等多源异构数据标准化，并采用合理的分块策略（如按语义段落切分而非固定字符数），避免信息在切割中支离破碎。

（2）索引构建：将切分好的文本通过嵌入模型转化为向量，并存入数据库。可以在此阶段关联元数据（如来源、页码），这对后续的精确引用很有帮助。

（3）检索策略优化：不要依赖单一的向量搜索。可以采用混合检索（向量+关键词）等方式来提升召回率，并引入重排序模型对检索结果进行二次精选，确保 LLM 看到的都是精华。

（4）生成与提示工程：最后，设计一套清晰的 Prompt 模板，引导 LLM 基于检索到的上下文回答用户问题，并明确要求模型“不知道就说不知道”，防止幻觉。

3.3 新手友好方案

如果希望快速验证想法而非深耕代码，可以尝试 FastGPT 或 Dify 这样的可视化知识库平台，它们封装了复杂的 RAG 流程，仅需上传文档即可使用。对于开发者，利用 LangChain4j Easy RAG 或 GitHub 上的 TinyRAG ⁵等开源模板，也是高效的起手方式。

3.4 进阶与挑战

当基础的 RAG 系统搭建完成后，下一步的进阶之路便聚焦于如何评估、诊断并突破其固有的瓶颈。

（1）评估维度与挑战

一套 RAG 系统的好坏，并不能仅凭感觉。业界通常会从几个维度进行量化评估，首先是检索相关性（找到的内容是否包含答案），其次是生成质量，这又可以细分为语义准确性（回答的意思是否正确）和词汇匹配度（专业术语是否使用得当）。

这些评估维度也直接对应了 RAG 当前面临的主要挑战。比如，检索依赖性问题——如果检索系统召回了错误信息，再强的 LLM 也会“一本正经地胡说八道”。此外，对于需要跨多个文档进行综合分析的多跳推理问题，常见的 RAG 架构也普遍感到吃力。

（2）优化方向与架构演进

针对上述挑战，社区探索出了多种优化路径。在性能层面，可以通过索引分层（对高频数据启用缓存）和多模态扩展（支持图像/表格检索）来提升效率和能力边界。而在架构层面，简单的线性流程正在被更复杂的设计模式所取代。例如，系统可以通过分支模式并行处理多路检索，或通过循环模式进行自我修正，这些灵活的架构是通往更智能 RAG 的必由之路。

四、RAG 已死？

随着大模型长上下文窗口能力的提升，社区中开始出现“RAG 已死”的声音。这一论调主要来自两个方面，一是认为长上下文已经能暴力“消化”海量文本，不再需要复杂的检索系统；二是批评 RAG 这个术语本身就过于宽泛，模糊了太多技术细节，反而阻碍了理解与优化。

这些观点忽略了一个技术概念在演进过程中的普遍规律。正如我们可以轻易地为现代复杂的 RAG 系统起一个更精确、更唬人的名字，比如 “大模型知识管理专家系统”（Large Language Model Knowledge Management Expert System，LKE）。因为它早已超出了最初“检索-增强-生成”的简单范畴。但这种“换名游戏”，恰恰说明了“RAG 已死”论的表面化——这无异于在用一个新瓶子去装 RAG 这个不断陈化的老酒。

笔者在此并非要创造一个新词，不过为什么要起 LKE 这个名字？它代表了三个核心要素：

L（Large Language Model）：强调系统的驱动力是大语言模型。

K（Knowledge Management）：寓意着系统就像一个知识管理员，精准地为我们找到（检索）所需要的知识，辅助我们后续利用大模型进行更高阶应用。

E（Expert）：说明系统能像专家一样，通过路由、分析、融合、修正等一系列步骤，最终给出答案（生成）、解决问题。

可以类比 Transformer。今天无论是以 GPT 为代表的 Decoder-only 还是以 BERT 为代表的 Encoder-only，我们都习惯称之为“基于 Transformer 架构”，尽管它们与最初论文中的完整形态差异巨大。但是 Transformer 这个标签抓住了一次技术范式的核心飞跃，并成为了一个技术时代的象征。同理，RAG 的核心在于“将 LLM 的内在参数化知识与外部非参数化知识相结合”。只要这个思想或需求不变，无论我们为其增加多少模块——查询转换、多路召回或者自我修正等等，它本质上依然是在这个框架下的演进。

所以，“RAG 已死”是一个伪命题。相反，RAG 作为一个概念活得很好，它正在像 Transformer 一样，成为一个不断吸收新技术、不断进化的基础架构范式。它的生命力，正在于它的“面目全非”和“包罗万象”。而本教程的目标，就是绘制出这张描绘 RAG 全貌的清晰地图，当我们可以解构它的每一个模块、理解它的每一种可能性时，RAG 也好，LKE 也罢，这些都无关紧要。我们要做的就是通过 RAG 这道经典例题来学习和拓展（将 LLM 的内在参数化知识与外部非参数化知识相结合）这类题型的解题思路。

RAG 技术仍在快速发展中，可以持续关注学术和工业界的最新进展！

五、基于 LangChain 框架的 RAG 实现

在第一节中，我们提到四步构建最小可行系统分别是数据准备、索引构建、检索优化和生成集成。下面将围绕这四个方面来实现一个基于 LangChain 框架的 RAG 应用。

本节完整代码（改造后）

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65


import os
# hugging face镜像设置，如果国内环境无法使用启用该设置
# os.environ['HF_ENDPOINT'] = 'https://hf-mirror.com'
from dotenv import load_dotenv
from langchain_community.document_loaders import UnstructuredMarkdownLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_core.prompts import ChatPromptTemplate
from langchain_openai import ChatOpenAI

load_dotenv()

markdown_path = "./markdown/easy-rl-chapter1.md"

# 加载本地markdown文件
loader = UnstructuredMarkdownLoader(markdown_path)
docs = loader.load()

# 文本分块
text_splitter = RecursiveCharacterTextSplitter()
chunks = text_splitter.split_documents(docs)

# 中文嵌入模型
embeddings = HuggingFaceEmbeddings(
 model_name="BAAI/bge-small-zh-v1.5",
 model_kwargs={'device': 'cpu'},
 encode_kwargs={'normalize_embeddings': True}
)

# 构建向量存储
vectorstore = InMemoryVectorStore(embeddings)
vectorstore.add_documents(chunks)

# 提示词模板
prompt = ChatPromptTemplate.from_template("""请根据下面提供的上下文信息来回答问题。
请确保你的回答完全基于这些上下文。
如果上下文中没有足够的信息来回答问题，请直接告知：“抱歉，我无法根据提供的上下文找到相关信息来回答此问题。”

上下文:
{context}

问题: {question}

回答:"""
 )

# 配置大语言模型
llm = ChatOpenAI(
 model="gpt-4o",
 temperature=0.7,
 max_tokens=4096,
 api_key=os.getenv("LLM_API_KEY"),
 base_url=os.getenv("LLM_BASE_URL"),
)

# 用户查询
question = "文中举了哪些例子？"

# 在向量存储中查询相关文档
retrieved_docs = vectorstore.similarity_search(question, k=3)
docs_content = "\n\n".join(doc.page_content for doc in retrieved_docs)

answer = llm.invoke(prompt.format(question=question, context=docs_content))
print(answer)

3.1 初始化设置

首先进行基础配置，包括导入必要的库、加载环境变量以及下载嵌入模型。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12


import os
# os.environ['HF_ENDPOINT'] = 'https://hf-mirror.com'
from dotenv import load_dotenv
from langchain_community.document_loaders import TextLoader
from langchain_text_splitters import RecursiveCharacterTextSplitter
from langchain_huggingface import HuggingFaceEmbeddings
from langchain_core.vectorstores import InMemoryVectorStore
from langchain_core.prompts import ChatPromptTemplate
from langchain_deepseek import ChatDeepSeek

# 加载环境变量
load_dotenv()

3.2 数据准备

加载原始文档: 先定义Markdown文件的路径，然后使用TextLoader加载该文件作为知识源。

1
2
3


markdown_path = "../../data/C1/markdown/easy-rl-chapter1.md"
loader = TextLoader(markdown_path)
docs = loader.load()

文本分块 (Chunking): 为了便于后续的嵌入和检索，长文档被分割成较小的、可管理的文本块（chunks）。这里采用了递归字符分割策略，使用其默认参数进行分块。当不指定参数初始化 RecursiveCharacterTextSplitter() 时，其默认行为旨在最大程度保留文本的语义结构：
- 默认分隔符与语义保留: 按顺序尝试使用一系列预设的分隔符 ["\n\n" (段落), "\n" (行), " " (空格), "" (字符)] 来递归分割文本。这种策略的目的是尽可能保持段落、句子和单词的完整性，因为它们通常是语义上最相关的文本单元，直到文本块达到目标大小。
- 保留分隔符: 默认情况下 (keep_separator=True)，分隔符本身会被保留在分割后的文本块中。
- 默认块大小与重叠: 使用其基类 TextSplitter 中定义的默认参数 chunk_size=4000（块大小）和 chunk_overlap=200（块重叠）。这些参数确保文本块符合预定的大小限制，并通过重叠来减少上下文信息的丢失。
1 2

text_splitter = RecursiveCharacterTextSplitter() texts = text_splitter.split_documents(docs)

3.3 索引构建

数据准备完成后，接下来构建向量索引：

初始化中文嵌入模型: 使用HuggingFaceEmbeddings加载之前在初始化设置中下载的中文嵌入模型。配置模型在CPU上运行，并启用嵌入归一化 (normalize_embeddings: True)。
1 2 3 4 5

embeddings = HuggingFaceEmbeddings( model_name="BAAI/bge-small-zh-v1.5", model_kwargs={'device': 'cpu'}, encode_kwargs={'normalize_embeddings': True} )
构建向量存储: 将分割后的文本块 (texts) 通过初始化好的嵌入模型转换为向量表示，然后使用InMemoryVectorStore将这些向量及其对应的原始文本内容添加进去，从而在内存中构建出一个向量索引。
1 2

vectorstore = InMemoryVectorStore(embeddings) vectorstore.add_documents(texts)
这个过程完成后，便构建了一个可供查询的知识索引。

3.4 查询与检索

索引构建完毕后，便可以针对用户问题进行查询与检索：

定义用户查询: 设置一个具体的用户问题字符串。
1

question = "文中举了哪些例子？"
在向量存储中查询相关文档: 使用向量存储的similarity_search方法，根据用户问题在索引中查找最相关的 k (此处示例中 k=3) 个文本块。
1

retrieved_docs = vectorstore.similarity_search(question, k=3)
准备上下文: 将检索到的多个文本块的页面内容 (doc.page_content) 合并成一个单一的字符串，并使用双换行符 ("\n\n") 分隔各个块，形成最终的上下文信息 (docs_content) 供大语言模型参考。
1

docs_content = "\n\n".join(doc.page_content for doc in retrieved_docs)
使用 "\n\n" (双换行符) 而不是 "\n" (单换行符) 来连接不同的检索文档块，主要是为了在传递给大型语言模型（LLM）时，能够更清晰地在语义上区分这些独立的文本片段。双换行符通常代表段落的结束和新段落的开始，这种格式有助于LLM将每个块视为一个独立的上下文来源，从而更好地理解和利用这些信息来生成回答。

3.5 生成集成

最后一步是将检索到的上下文与用户问题结合，利用大语言模型（LLM）生成答案：

构建提示词模板: 使用ChatPromptTemplate.from_template创建一个结构化的提示模板。此模板指导LLM根据提供的上下文 (context) 回答用户的问题 (question)，并明确指出在信息不足时应如何回应。

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11


prompt = ChatPromptTemplate.from_template("""请根据下面提供的上下文信息来回答问题。
请确保你的回答完全基于这些上下文。
如果上下文中没有足够的信息来回答问题，请直接告知：“抱歉，我无法根据提供的上下文找到相关信息来回答此问题。”

上下文:
{context}

问题: {question}

回答:"""
 )

配置大语言模型: 初始化ChatDeepSeek客户端，配置所用模型 (deepseek-chat)、生成答案的温度参数 (temperature=0.7)、最大Token数 (max_tokens=2048) 以及API密钥 (从环境变量加载)。
1 2 3 4 5 6

llm = ChatDeepSeek( model="deepseek-chat", temperature=0.7, max_tokens=2048, api_key=os.getenv("DEEPSEEK_API_KEY") )
调用LLM生成答案并输出: 将用户问题 (question) 和先前准备好的上下文 (docs_content) 格式化到提示模板中，然后调用ChatDeepSeek的invoke方法获取生成的答案。
1 2

answer = llm.invoke(prompt.format(question=question, context=docs_content)) print(answer)

老湿老湿，Langchain 很强大但还是太吃操作了，有没有更加简单又好用的框架推荐呢？

有的兄弟，有的！像这样好用的框架还有LlamaIndex😉

六、低代码（基于LlamaIndex）

在 RAG 方面，LlamaIndex 提供了更多封装好的 API 接口，这无疑降低了上手门槛，下面是一个简单实现：

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21


import os
# os.environ['HF_ENDPOINT']='https://hf-mirror.com'
from dotenv import load_dotenv
from llama_index.core import VectorStoreIndex, SimpleDirectoryReader, Settings
from llama_index.llms.ollama import Ollama
from llama_index.embeddings.huggingface import HuggingFaceEmbedding

load_dotenv()

Settings.llm = Ollama(model="deepseek-chat", request_timeout=60.0)
Settings.embed_model = HuggingFaceEmbedding("BAAI/bge-small-zh-v1.5")

docs = SimpleDirectoryReader(input_files=["./markdown/easy-rl-chapter1.md"]).load_data()

index = VectorStoreIndex.from_documents(docs)

query_engine = index.as_query_engine()

print(query_engine.get_prompts())

print(query_engine.query("文中举了哪些例子?"))

LlamaIndex on 酒中仙

向量数据库中的索引优化

向量数据库中的索引优化

一、上下文扩展

1.1 主要思路

1.2 代码实现

二、结构化索引

2.1 代码实现：基于多表格的递归检索

2.2 另一种实现方式

题外话：关于框架

参考文献

RAG 中的数据准备

RAG 中的数据准备

第一节 数据加载

一、文档加载器

1.1 主要功能

1.2 当前主流RAG文档加载器

第二节 文本分块

一、理解文本分块

二、文本分块重要性

2.1 满足模型上下文限制

2.2 为何“块”不是越大越好

2.2.1 嵌入过程中的信息损失

2.2.2 生成过程的“大海捞针” (Lost in the Middle)

2.2.3 主题稀释导致检索失败

三、基础分块策略

3.1 固定大小分块

3.2 递归字符分块

3.3 语义分块

3.4 基于文档结构的分块

以 Markdown 结构分块为例

四、其他开源框架中的分块策略

4.1 Unstructured：基于文档元素的智能分块

4.2 LlamaIndex：面向节点的解析与转换

4.3 ChunkViz：简易的可视化分块工具

参考文献

RAG 简介及其简单实现

RAG 简介及其简单实现

一、什么是 RAG？

1.1 核心定义

1.2 技术原理

1.3 技术演进分类

二、为什么要使用 RAG？

2.1 技术选型：RAG vs. 微调

2.2 关键优势

2.3 适用场景风险分级

三、如何上手 RAG？

3.1 基础工具链选择

3.2 四步构建最小可行系统（MVP）

3.3 新手友好方案

3.4 进阶与挑战

四、RAG 已死？

五、基于 LangChain 框架的 RAG 实现

本节完整代码（改造后）

3.1 初始化设置

3.2 数据准备

3.3 索引构建

3.4 查询与检索

3.5 生成集成

六、低代码（基于LlamaIndex）

参考文献

第一节数据加载

第二节文本分块