O、猎奇的文档
为了有效验证后续RAG系统的实际效果，我特意使用AI生成了一份约2700字的《不正经有限公司 正经管理办法》。这份文档内容充满各种奇特的规章制度，例如“员工必须使用左手接听电话”、“会议室严禁讨论任何正经事务”等条款。
为什么要采用这种特殊文档呢？原因非常明确。当你向搭建完成的知识库系统提问时，如果返回的答案是这些荒诞不经的条款内容，而非通用的公司制度说明，那就确凿证明——你的私有知识库确实成功运行了，它准确“记忆”并优先检索了你所输入的独特内容。
一、为什么需要文档切片
在上一节梳理RAG系统思路时，我们明确了两个关键技术要点：
- 句向量的核心优势在于语义检索。它能够根据用户提出的问题或关键词，快速找到语义层面最接近的相关句子。
- 但这些被检索到的句子片段，最终仍需封装进提示词模板，交由基于词向量架构的大语言模型进行理解并生成最终回答。
基于这个标准流程，一个核心的技术矛盾便显现出来：
- 句向量对应的文本片段不宜过长。如果每次对话交互都需嵌入数千字的文档内容，不仅会急剧消耗Token资源（意味着更高的API成本与更慢的响应速度），还会导致大语言模型难以聚焦关键信息，从而降低回答的准确性与相关性。
- 反之，文本片段也不能过短。过短的句子往往缺乏完整的上下文信息，容易产生断章取义的问题，检索出的内容可能意义模糊，无法为生成回答提供有效支撑。
因此，当前行业内的主流解决方案是：在将文本转换为句向量之前，先执行一道“文档切片”工序。其核心目标非常明确：
- 确保每个即将被向量化的文本块长度适中，符合模型处理要求。
- 确保每个文本块都是一个语义完整、意思明确的独立信息单元。
在动手编写代码之前，我们可以先访问一个可视化工具网站（chunkviz.com）进行实验，直观感受不同切片策略带来的效果差异，从而为我们的文档选择最合适的切分方案。
二、了解切分的基本概念
打开 chunkviz.com 网站，你会看到如下操作界面：
这里涉及四个核心的文档切分概念：
- text: 等待进行切分的原始文档文本内容。
- Splitter (切分器): 负责执行文本切割的工具模块。不同的Splitter针对不同文本类型进行了优化，例如有针对通用文本的、针对编程代码的、针对Markdown标题结构的等等。
- ChunkSize (块长度): 你期望每个文本块包含的字符数量或Token数量。这是控制文本块大小的核心参数。
- ChunkOverlap (块间重叠长度): 为了避免一个完整的句子被生硬地切割到两个不同的文本块中，可以设置一个重叠量。例如，后一个文本块的开头部分会包含前一个文本块的结尾部分，从而有效保证上下文的连贯性与语义完整性。
仅看概念可能略显抽象？没关系，这个网站最强大的功能就是提供了直观的可视化效果。我们保持上图中的默认配置，可以看到下面这张色彩分明的可视化图：
这张图清晰地展示了文本切分的具体过程。因为我们选择了“Token Splitter”，所以它基本上是按照 `ChunkSize = 500` 的设定，将文本分成了三个主要片段：
- 蓝色 + 绿色1 = 片段1
- 绿色1 + 黄色 + 绿色2 = 片段2
- 绿色2 + 粉色 + 绿色3 = 片段3
请注意那些绿色的部分，它们就是由 `ChunkOverlap` 参数控制的重叠片段。这种设计的核心优点是能有效防止一个完整的句子被拦腰截断，其代价是可能导致关键信息同时出现在相邻的两个块中。但综合权衡，这种设计绝对是利大于弊的。
三、选择适合你的Splitter
选择不同的 `Splitter` 切分器，对最终拆分结果的影响，远比单纯调整 `ChunkSize` 和 `ChunkOverlap` 的数值要显著得多。因为不同的拆分器内置了针对特定文本格式的智能解析逻辑。
我们将配置稍作调整，换成 `MarkdownHeaderSplitter`，再看一下效果：
效果立竿见影！它不再机械地按照固定长度进行切割，而是智能地识别出了文档的二级标题（##），并以此作为天然的分界点进行切分。这样一来，每个切片都对应一个完整的章节内容，语义完整性得到了极大提升。
针对不同的应用场景，例如切分Java代码，还有更多专用的Splitter可供选择。但就我们当前需要处理的Markdown格式文档而言，使用 `MarkdownHeaderTextSplitter` 无疑是最为合理和高效的选择。
在实际的工程项目中，更常见的做法是采用“两步走”策略，兼顾语义结构和长度限制：
保留灵魂 (MarkdownHeaderTextSplitter)：首先按照 #、##、### 等Markdown标题层级进行切分。这一步最精妙之处在于，它会将所属的标题信息作为元数据附加在每个文本块上。这就好比给每一段文本都戴上了精准的GPS定位器，未来大语言模型在处理这段话时，能立刻知晓它出自哪一章、哪一节，上下文关系清晰无比。
控制体型 (RecursiveCharacterTextSplitter)：如果某个标题下的内容依然过长（例如超过了底层向量模型如bge-small的512长度限制），我们就需要进行二次切分。这次按照段落、句子等自然语言单位来切分，并设置合理的块大小（如400字符）和重叠量（如50字符），完美适配向量模型的“输入胃口”。
四、在代码里切分
理论清晰之后，接下来就是实战编码环节。我们可以尝试编写如下Python代码来测试和验证整个文档切片流程：
from langchain_text_splitters import MarkdownHeaderTextSplitter, RecursiveCharacterTextSplitter
# 1. 模拟一篇真实的 Markdown 文档
markdown_text = """
# DeepSeek 使用指南
## 1. 简介
DeepSeek 是一家专注于大语言模型的初创公司。它的特点是性价比极高，且模型能力在开源界名列前茅。
## 2. API 调用
### 2.1 准备工作
你需要先去官网注册账号，并获取一个 API Key。请妥善保管这个 Key。
### 2.2 Python 代码示例
这里是一段如何用 Python 发起请求的代码...（假设这里有一万字）
"""
# --- 第一步：按 Markdown 标题切分 ---
# 告诉程序，我们要识别哪些级别的标题，并给它们起个名字
headers_to_split_on = [
("#", "主标题"), # 识别 #
("##", "二级标题"), # 识别 ##
("###", "三级标题"), # 识别 ###
]
# 初始化 Markdown 切分器
markdown_splitter = MarkdownHeaderTextSplitter(
headers_to_split_on=headers_to_split_on,
strip_headers=False # 保留文本里的 # 号（如果你不想要可以设为 True）
)
# 执行第一步切分
md_header_splits = markdown_splitter.split_text(markdown_text)
# --- 第二步：按字符长度二次切分 ---
# 如果某个标题下的内容特别长（比如超过了 bge-small 的 512 限制），需要再切碎
text_splitter = RecursiveCharacterTextSplitter(
chunk_size=400, # 限制每块最大 400 字符
chunk_overlap=50 # 重叠 50 字符防断句
)
# 执行第二步切分 (注意这里用的是 split_documents，因为它已经是结构化数据了)
final_splits = text_splitter.split_documents(md_header_splits)
# --- 查看结果 ---
print(f"一共切成了 {len(final_splits)} 块\n")
for i, doc in enumerate(final_splits):
print(f"--- 第 {i+1} 块 ---")
print(f"? 内容: {doc.page_content.strip()}")
# 除了切片，它还生成了非常关键的 metadata
print(f"?️ 标签(Metadata): {doc.metadata}\n")执行上面的Python脚本，你会看到类似下图的输出结果：
你可能已经注意到，除了生成切片内容，Markdown Splitter还自动生成了metadata（元数据）。这个功能有用吗？
非常有用！这简直是构建企业级RAG应用的“杀手锏”功能。未来你在进行向量相似度检索时，可以这样灵活地使用它：
results = collection.query(
query_texts=["怎么写 Python 代码？"],
n_results=2,
# 杀手锏：只在主标题是“DeepSeek 使用指南”的范围内进行向量搜索！
where={"主标题": "DeepSeek 使用指南"}
)这意味着你可以实现带过滤条件的精准向量检索。例如，你的企业知识库包含了公司制度、技术文档、产品手册等多种类型的资料，当用户咨询一个具体的技术问题时，你可以限定只在“技术文档”这个主标题下进行搜索，完全避开无关的公司制度条款，从而大幅提升RAG系统检索的准确性和响应效率。这对于构建复杂、多领域的大型企业知识库而言，是必不可少的关键功能。
到目前为止，文档切片的核心原理和基础用法你已经完全掌握了。这是构建高质量RAG检索增强生成系统的基石。下一步，我们就可以基于这些规整的文本块，来生成我们的【句向量】数据库了。
下一步预告
本节课我们详细讲解了文档切片——这是决定RAG系统检索质量最关键的预处理步骤。地基已经打好，接下来就可以开始浇筑主体结构了：将这些语义完整的文本切片转换成高维向量，并存入向量数据库，构建起真正可检索、可应用的私有知识库。
