1. 为什么 Loader 和 Splitter 是 RAG 系统的命门
做 RAG 应用的人都有一个共识：模型选得再好，检索环节拉胯，整个系统就是花架子。而检索质量的上限，在文档进入向量库之前就已经被决定了。说得再直白一点，Loader 决定了你“能拿到什么料”，Splitter 决定了你“把料切成什么形状”，这两步做砸了，后面 embedding 再强、rerank 再精细，都是在垃圾堆里找金子。
我接触过不少团队，前期把大量精力砸在 prompt 调优和模型对比上，结果上线后回答质量忽高忽低，最后回头一查，问题出在 PDF 解析丢了一半表格、切块把一句完整的话拦腰截断。这类问题不解决，调 prompt 就是缘木求鱼。
这篇文章面向的是正在搭建或优化 RAG 管道的开发者，不管你用的是 LangChain、LlamaIndex 还是自己手搓流程，Loader 和 Splitter 这两层的设计思路是通用的。我会把这两个组件的核心原理、选型逻辑、参数计算、实操踩坑全部拆开讲，尽量做到你读完就能对照自己的项目改。
先给一个整体认知：一个典型的 RAG 数据摄入管道是这样的——
原始文档 → Loader（解析/提取）→ 清洗 → Splitter（切块）→ Embedding → 向量库Loader 负责把各种格式（PDF、Word、HTML、Markdown、数据库记录）统一转成纯文本或结构化文本；Splitter 负责把这些长文本切成适合 embedding 模型处理的片段。两个环节各有各的坑，而且互相影响——Loader 输出的格式直接决定了 Splitter 能怎么切。
一个常见的误区：很多人觉得 Loader 就是“读文件”，随便调个库就行。实际上，文档解析的质量差异可以大到让你怀疑人生，同一份 PDF 用不同工具解析，出来的文本可能一个能用一个完全没法用。
2. Loader 深度拆解：从各种格式里把文本“捞干净”
2.1 Loader 的本质任务与常见格式的解析难点
Loader 的核心任务听起来很简单：把文件变成文本。但“变成文本”这四个字背后，藏着大量格式相关的细节。不同格式的信息密度、结构复杂度、解析难度完全不一样，我按实际项目中的踩坑经验，把常见格式分个类。
纯文本类（TXT、Markdown）是最省心的，基本直接读取就行。但 Markdown 有个细节：标题层级（H1/H2/H3）其实携带了很强的语义信息，如果 Loader 直接把 Markdown 拍平成纯文本，这些层级信息就丢了，后面 Splitter 就没法利用标题来做语义切分。所以好的 Markdown Loader 应该保留结构信息，比如输出带 metadata 的文档对象。
PDF 是重灾区。PDF 本质上是一种“排版描述语言”，它记录的是“在坐标 (x, y) 画这个字符”，而不是“这段话是一个段落”。所以从 PDF 提取文本，本质上是一个逆向工程问题。常见的难点包括：多栏排版导致阅读顺序错乱、表格被拆成散落的字符、扫描件需要 OCR、页眉页脚混入正文。我见过最离谱的情况是一份双栏学术论文，解析出来左右栏文字交错在一起，读起来像天书。
Word 文档（DOCX）相对好一些，因为它内部有段落、样式等结构信息，python-docx 这类库能比较好地提取。但表格、文本框、批注这些元素的处理需要额外注意。
HTML 的核心难点是“去噪”——导航栏、广告、页脚这些内容对 RAG 毫无价值，反而会污染检索结果。需要专门的内容提取算法（比如基于文本密度的正文识别）来剥离。
下面这张表是我总结的常见格式解析要点：
| 格式 | 主要难点 | 推荐处理策略 | 需要保留的 metadata |
|---|---|---|---|
| TXT | 编码问题 | 统一转 UTF-8 | 文件名、路径 |
| Markdown | 结构丢失 | 保留标题层级 | 标题路径、层级 |
| PDF（文本型） | 阅读顺序、表格 | 按版面分析提取 | 页码、章节 |
| PDF（扫描型） | 需要 OCR | OCR + 后处理 | 页码、置信度 |
| DOCX | 表格、文本框 | 结构化提取 | 样式、标题 |
| HTML | 噪声多 | 正文密度提取 | 标题、URL |
2.2 Loader 选型的核心考量：不只是“能读就行”
选 Loader 的时候，很多人只看“支持不支持这个格式”，但真正影响 RAG 效果的是另外几个维度。
第一是结构保留能力。好的 Loader 不只是输出一串文本，而是输出带有层级和语义标记的文档对象。比如一个 PDF 有章节标题，Loader 应该能识别出“这是 H2 级别的标题”，这样 Splitter 就能按章节切分，而不是机械地按字数切。LangChain 的 Document 对象就是为此设计的，它把 page_content 和 metadata 分开存，metadata 里可以放页码、标题路径、来源等信息。
第二是表格处理能力。表格在 RAG 里是个特殊存在——它信息密度极高，但线性化之后语义会丢失。比如一个 3x5 的表格，转成文本后变成一串用空格分隔的词，embedding 模型根本理解不了行列关系。好的做法是把表格转成 Markdown 格式或自然语言描述，比如“产品A的价格是100元，库存是50件”。有些 Loader 支持输出表格的 HTML 或 Markdown 表示，这对后续处理更友好。
第三是性能与批处理。如果你要处理上万份文档，Loader 的解析速度就成了瓶颈。PDF 解析尤其慢，一个几十页的 PDF 可能要几秒。这时候需要考虑并行处理、增量加载（只处理新增或修改的文档）、缓存机制。
第四是错误处理。实际项目中一定会遇到解析失败的文件——加密 PDF、损坏文件、特殊编码。Loader 需要有健壮的错误处理，记录哪些文件失败了、失败原因是什么，而不是整个批处理任务崩掉。
实操心得：我习惯在 Loader 阶段就给每个文档打上丰富的 metadata，包括来源、页码、解析时间、解析工具版本。这些信息在后续排查问题时非常有用——当用户反馈某条回答不对时，你能快速定位到是哪个文档的哪个片段出了问题。
2.3 一个可复用的 Loader 实现思路
下面给一个我常用的 Loader 设计思路，不依赖特定框架，你可以按这个结构自己实现或对照现有工具检查。
核心是一个分发器加一组格式处理器：
from dataclasses import dataclass, field from typing import List, Dict, Any @dataclass class Document: content: str metadata: Dict[str, Any] = field(default_factory=dict) class BaseLoader: def load(self, path: str) -> List[Document]: raise NotImplementedError class PDFLoader(BaseLoader): def load(self, path: str) -> List[Document]: docs = [] # 逐页解析，保留页码 for page_num, page_text in self._extract_pages(path): docs.append(Document( content=page_text, metadata={"source": path, "page": page_num, "type": "pdf"} )) return docs def _extract_pages(self, path: str): # 具体解析逻辑，可用 pdfplumber / pymupdf 等 ...这个结构的关键点在于：每个 Document 都携带完整的 metadata，而不是把所有文本拼成一个大字符串。这样后续 Splitter 可以基于 metadata 做更智能的切分，比如“不跨页切分”“按章节切分”。
对于 PDF，我实测下来 pdfplumber 在表格提取上表现较好，pymupdf（fitz）在纯文本提取速度和阅读顺序上更稳。扫描件则需要接 OCR 引擎，这一步的准确率直接决定了后续所有环节的上限，值得单独花时间调优。
3. Splitter 核心机制：切块策略决定检索精度
3.1 为什么不能简单按字数切
新手最容易犯的错误就是“按固定字数切，比如每 500 字一块”。这种做法的问题在于，它完全无视文本的语义边界。想象一下，一句话被从中间切开，前半句在块 A，后半句在块 B，那么无论用户问什么，块 A 和块 B 单独看都是语义不完整的，检索出来的结果自然驴唇不对马嘴。
更隐蔽的问题是语义稀释。如果一个块里混了三个不同主题的内容，embedding 之后这个向量就成了三个主题的“平均值”，它跟任何一个具体问题的相似度都不高。这就是为什么很多 RAG 系统检索出来的内容“好像相关但又不太对”——块太大了，语义被稀释了。
反过来，块切得太小也有问题。一个块只有一句话，可能缺少必要的上下文，embedding 模型无法判断它在讲什么。比如“它的价格是 100 元”，这个“它”指代什么？单独拿出来完全没法理解。
所以 Splitter 的核心矛盾是：块要足够小以保证语义聚焦，又要足够大以保留上下文完整性。这个平衡点没有万能答案，取决于你的文档类型和查询特点。
3.2 主流切块策略对比与适用场景
我把常见的切块策略整理成下表，方便你对照选择：
| 策略 | 原理 | 优点 | 缺点 | 适用场景 |
|---|---|---|---|---|
| 固定长度 | 按字符/token数切 | 实现简单、块大小均匀 | 破坏语义边界 | 结构松散的纯文本 |
| 递归字符切分 | 按分隔符优先级递归切 | 尽量在自然边界切 | 仍需设阈值 | 通用场景 |
| 语义切分 | 基于句子embedding相似度 | 语义边界准确 | 计算成本高 | 高质量要求场景 |
| 结构化切分 | 按标题/章节切 | 保留文档结构 | 依赖Loader质量 | 有层级的文档 |
| 父子切分 | 小块检索、大块返回 | 兼顾精度与上下文 | 实现复杂 | 长文档问答 |
递归字符切分是目前最常用的默认策略，LangChain 的 RecursiveCharacterTextSplitter 就是典型代表。它的思路是：先尝试用段落分隔符（\n\n）切，如果某块还是太大，再用换行符（\n）切，再不行用句号、逗号，最后才硬切。这样能最大程度保证在自然边界切分。
语义切分是进阶方案。它的做法是先把文本拆成句子，然后计算相邻句子的 embedding 相似度，在相似度骤降的地方切一刀——因为相似度骤降意味着话题变了。这种方法切出来的块语义非常聚焦，但需要对每个句子做 embedding，成本较高。适合对检索质量要求极高的场景。
父子切分是我个人很推荐的一种模式。它的核心思想是：用小块（比如 200 字）做检索，因为小块语义聚焦、检索精度高；但返回给 LLM 的时候，返回这个小块所属的大块（比如 1000 字），保证上下文完整。这样既解决了检索精度问题，又解决了上下文缺失问题。实现上需要维护小块到大块的映射关系。
3.3 块大小与重叠参数的量化计算
块大小（chunk_size）和重叠（chunk_overlap）是两个必须调的参数。很多人凭感觉设，其实可以用一个简单的计算来指导。
首先要明确一个约束：块大小不能超过 embedding 模型的最大输入长度。比如某常见 embedding 模型最大输入是 512 token，那你的块（以 token 计）就不能超过 512，否则会被截断。一般建议留 20% 余量，即块大小控制在 400 token 左右。
其次要考虑检索粒度。块越大，单个块包含的信息越多，但语义越分散；块越小，语义越聚焦，但可能丢失上下文。一个经验公式是：
chunk_size ≈ 平均段落长度 × 1.5比如你的文档平均段落是 200 字，那 chunk_size 设在 300 字左右比较合适。
重叠（overlap）的作用是防止关键信息正好落在切分点上被割裂。一般设成 chunk_size 的 10%~20%。比如 chunk_size=300，overlap 设 50 左右。重叠太大会导致冗余（同一段内容出现在多个块里，检索时重复召回），太小则起不到保护作用。
注意：chunk_size 的单位要统一。有的工具按字符算，有的按 token 算。中文里一个字符大约对应 1~2 个 token（取决于分词器），英文里一个单词大约 1.3 个 token。混用单位是常见错误，会导致实际块大小和你预期差很多。
我一般会做一个简单的实验来确定最优参数：准备一批典型问题，用不同参数组合跑检索，看召回率和准确率。参数搜索空间不用太大，chunk_size 试 3 个值（比如 256/512/1024），overlap 试 2 个值（比如 10%/20%），6 组组合跑一遍，基本就能找到适合你数据的配置。
4. 实操全流程：从原始文档到可检索块
4.1 完整管道的搭建步骤
这一节我把整个流程串起来，给一个可以直接参考的实现骨架。假设我们要处理一批混合格式的文档（PDF + Markdown + HTML），目标是产出带 metadata 的文本块。
第一步是文档发现与分类。遍历目标目录，按扩展名分类，为每类文档分配对应的 Loader。这一步要注意跳过临时文件、隐藏文件，以及记录处理日志。
import os from pathlib import Path def discover_documents(root_dir: str): supported = {".pdf", ".md", ".txt", ".html", ".docx"} docs = [] for path in Path(root_dir).rglob("*"): if path.suffix.lower() in supported and not path.name.startswith("."): docs.append(str(path)) return docs第二步是加载与清洗。对每个文档调用对应的 Loader，得到 Document 列表。清洗环节要做几件事：去除多余空白、统一标点、剔除页眉页脚（PDF 常见）、过滤空文档。清洗规则要根据你的数据特点定制，没有通用方案。
第三步是切分。这里我推荐用“结构化优先 + 递归兜底”的混合策略：如果文档有明确的标题层级（Markdown、带书签的 PDF），优先按标题切分；如果没有，用递归字符切分兜底。
def split_documents(docs, chunk_size=500, chunk_overlap=80): chunks = [] for doc in docs: # 优先按标题切分 if has_heading_structure(doc): sections = split_by_heading(doc) else: sections = [doc] # 对每个 section 再做递归切分 for section in sections: sub_chunks = recursive_split(section, chunk_size, chunk_overlap) chunks.extend(sub_chunks) return chunks第四步是 metadata 继承。切分出来的每个小块，都要继承原文档的 metadata（来源、页码、标题路径），并补充块自身的 metadata（块序号、字符数）。这一步很关键，因为检索时你需要靠 metadata 来过滤和溯源。
4.2 关键参数的现场调试记录
我拿一份约 50 页的技术文档做过一轮参数调试，记录如下，供你参考。
初始配置：chunk_size=1000 字符，overlap=0，纯递归切分。结果：检索召回的内容经常包含多个不相关主题，LLM 回答时容易跑题。分析发现块太大，语义稀释严重。
调整一：chunk_size 降到 500，overlap=50。结果：检索精度明显提升，但出现了新问题——有些需要跨段理解的问题，召回的块缺少上文，LLM 回答不完整。
调整二：引入父子切分。检索用 300 字的小块，返回时带上所属的 800 字大块。结果：检索精度和回答完整性都改善了。这是最终采用的方案。
调整三：在切分前先按标题切分，保证不跨章节。结果：进一步减少了跨主题污染，因为同一章节内主题相对一致。
这轮调试让我确认了一个观点：没有一劳永逸的参数，只有针对你的数据和查询特点调出来的参数。别人的最优配置搬到你的数据上大概率不是最优。
4.3 切分质量的验证方法
切完之后怎么知道切得好不好？我常用两个方法。
方法一是人工抽检。随机抽 20 个块，逐个读一遍，看是否语义完整、是否混入无关内容、metadata 是否正确。这个方法虽然土，但最直接有效。
方法二是检索测试。准备 30~50 个典型问题，每个问题都有标准答案所在的文档位置。跑一遍检索，看正确答案所在的块是否被召回（召回率），以及召回的块里有多少是相关的（准确率）。召回率低说明切分太碎或块太小，准确率低说明块太大或混入了噪声。
这两个指标要一起看。只追求召回率会导致返回大量无关内容，只追求准确率会导致漏掉关键信息。一般召回率优先，因为漏掉信息的代价比多返回几条更大——LLM 有一定的抗噪能力，但没法处理它没看到的信息。
5. 常见问题与排查技巧实录
5.1 Loader 环节的典型故障
问题一：PDF 解析出来是乱码或空白。最常见的原因是 PDF 是扫描件（图片型），需要 OCR。判断方法很简单：用文本提取工具提取，如果提取出的字符数远小于预期，基本就是扫描件。另一个原因是 PDF 使用了特殊字体编码，需要换解析库试试。
问题二：表格内容错乱。表格被解析成散落的字符，行列关系丢失。解决思路是换用支持表格识别的解析工具，或者对表格区域单独做 OCR + 结构重建。如果表格不多，也可以人工整理成 Markdown 表格。
问题三：页眉页脚混入正文。每页都出现的重复文本（页码、文档标题、公司名）会污染检索。解决方法是在 Loader 后加一个去重步骤：统计所有页中高频出现的短文本行，如果某行在超过 80% 的页面出现，就判定为页眉页脚并剔除。
5.2 Splitter 环节的典型故障
问题一：关键信息被切断。表现为检索到的块内容不完整，答案缺一半。解决方法是增大 overlap，或者改用语义切分。如果某个特定位置经常被切断（比如代码块、表格），可以加自定义分隔符保护。
问题二：块太大导致检索不准。表现为召回的块里只有一小部分相关。解决方法是减小 chunk_size，或改用父子切分。
问题三：块太小导致上下文缺失。表现为召回的块单独看不知所云。解决方法是增大 chunk_size，或改用父子切分（检索小块、返回大块）。
问题四：metadata 丢失。表现为检索到内容但不知道来源。解决方法是确保切分时 metadata 正确继承，并在向量库中把 metadata 一起存储。
下面这张速查表可以帮你快速定位问题：
| 现象 | 可能原因 | 排查方向 | 解决手段 |
|---|---|---|---|
| 检索结果不相关 | 块太大/语义稀释 | 检查块平均长度 | 减小chunk_size |
| 答案不完整 | 块太小/信息被切 | 检查overlap设置 | 增大overlap或父子切分 |
| 来源无法追溯 | metadata丢失 | 检查块metadata | 修复继承逻辑 |
| 解析内容为空 | 扫描件/编码问题 | 检查提取字符数 | 接OCR或换解析库 |
| 重复召回 | overlap过大 | 检查重叠比例 | 降低overlap |
5.3 几条踩坑换来的经验
第一条经验：先小样本验证，再全量处理。我见过有人直接对几万份文档跑完整管道，跑完才发现解析有问题，全部重来。正确做法是先拿 10~20 份有代表性的文档跑通全流程，确认质量后再全量。
第二条经验：把 Loader 和 Splitter 的中间产物落盘。也就是把解析后的文本和切分后的块存成文件（比如 JSONL），这样调试时不用每次重新解析，也能直观看到每一步的输出。这个习惯帮我省了大量时间。
第三条经验：为不同来源的文档设置不同的切分策略。技术文档适合按标题切，聊天记录适合按时间窗口切，代码适合按函数切。一刀切的策略在混合数据上效果一定不好。
第四条经验：定期重新评估切分质量。文档在更新，查询模式在变化，半年前的最优参数现在可能已经不是最优了。我一般每季度会重新跑一次检索测试，看指标有没有退化。
6. 进阶优化：让 Loader 和 Splitter 协同工作
6.1 结构化信息在两层之间的传递
Loader 和 Splitter 不是孤立的两个步骤，它们之间有一条信息传递的通道，就是 metadata。Loader 提取出的结构信息（标题层级、页码、表格标记）如果能传递给 Splitter，Splitter 就能做出更聪明的切分决策。
举个具体例子：Loader 在解析 Markdown 时，可以给每个段落打上“所属标题路径”的 metadata，比如{"heading_path": "第三章 > 3.2 参数配置"}。Splitter 拿到这个信息后，就可以保证不跨标题切分，并且把 heading_path 继续传给每个块。这样检索出来的块，不仅内容相关，还带着清晰的上下文路径，LLM 理解起来更准确。
再比如表格：Loader 识别出表格后，可以给表格内容打上{"type": "table"}的标记。Splitter 看到这个标记，就知道不能按普通文本切，而要整表保留或按行切分。这种协同能显著提升表格类问题的回答质量。
6.2 面向检索效果的切分微调
如果你的检索效果还不理想，可以尝试几个进阶技巧。
技巧一：给块加“上下文前缀”。在切分后，给每个块的内容前面拼接一段上下文说明，比如“本文档是关于XX的，当前段落属于XX章节”。这样即使块本身内容简短，embedding 时也能带上上下文信息，检索更准。这个技巧对小块特别有效。
技巧二：重叠区域做去重。如果 overlap 设得较大，检索时可能召回多个高度重叠的块，浪费上下文窗口。可以在检索后做一次去重，把内容重叠度超过阈值的块合并或剔除。
技巧三：按查询类型准备多套切分。有些系统会同时维护“小块索引”和“大块索引”，简单事实类查询走小块，需要推理的复杂查询走大块。这种双索引策略实现成本高一些，但效果提升明显。
6.3 效果评估的闭环
优化不能凭感觉，要建立评估闭环。我的做法是维护一个测试集，包含问题和标准答案所在的文档位置。每次调整 Loader 或 Splitter 参数后，跑一遍测试集，记录召回率、准确率、平均响应时间。只有指标提升了，才认为这次调整是有效的。
这个测试集不用很大，30~50 个问题就够，但要有代表性，覆盖你的主要文档类型和查询类型。随着系统迭代，测试集也要不断补充新出现的查询模式。
我个人在实际操作中的体会是，Loader 和 Splitter 的优化是一个持续迭代的过程，不存在“一次调好就完事”的情况。文档在变、用户在变、模型在变，唯一不变的是“垃圾进垃圾出”这个铁律。把这两个基础环节做扎实，后面的模型和 prompt 优化才有意义。最后分享一个小技巧：每次调整参数时，只改一个变量，其他保持不变，这样你才能清楚地知道是哪个改动带来了效果变化——同时改多个参数，即使效果变好了，你也不知道该归功于谁。
