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 毫无价值反而会污染检索结果。需要专门的内容提取算法比如基于文本密度的正文识别来剥离。下面这张表是我总结的常见格式解析要点格式主要难点推荐处理策略需要保留的 metadataTXT编码问题统一转 UTF-8文件名、路径Markdown结构丢失保留标题层级标题路径、层级PDF文本型阅读顺序、表格按版面分析提取页码、章节PDF扫描型需要 OCROCR 后处理页码、置信度DOCX表格、文本框结构化提取样式、标题HTML噪声多正文密度提取标题、URL2.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_factorydict) 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( contentpage_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 在表格提取上表现较好pymupdffitz在纯文本提取速度和阅读顺序上更稳。扫描件则需要接 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_size300overlap 设 50 左右。重叠太大会导致冗余同一段内容出现在多个块里检索时重复召回太小则起不到保护作用。注意chunk_size 的单位要统一。有的工具按字符算有的按 token 算。中文里一个字符大约对应 1~2 个 token取决于分词器英文里一个单词大约 1.3 个 token。混用单位是常见错误会导致实际块大小和你预期差很多。我一般会做一个简单的实验来确定最优参数准备一批典型问题用不同参数组合跑检索看召回率和准确率。参数搜索空间不用太大chunk_size 试 3 个值比如 256/512/1024overlap 试 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_size500, chunk_overlap80): 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_size1000 字符overlap0纯递归切分。结果检索召回的内容经常包含多个不相关主题LLM 回答时容易跑题。分析发现块太大语义稀释严重。调整一chunk_size 降到 500overlap50。结果检索精度明显提升但出现了新问题——有些需要跨段理解的问题召回的块缺少上文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过大检查重叠比例降低overlap5.3 几条踩坑换来的经验第一条经验先小样本验证再全量处理。我见过有人直接对几万份文档跑完整管道跑完才发现解析有问题全部重来。正确做法是先拿 10~20 份有代表性的文档跑通全流程确认质量后再全量。第二条经验把 Loader 和 Splitter 的中间产物落盘。也就是把解析后的文本和切分后的块存成文件比如 JSONL这样调试时不用每次重新解析也能直观看到每一步的输出。这个习惯帮我省了大量时间。第三条经验为不同来源的文档设置不同的切分策略。技术文档适合按标题切聊天记录适合按时间窗口切代码适合按函数切。一刀切的策略在混合数据上效果一定不好。第四条经验定期重新评估切分质量。文档在更新查询模式在变化半年前的最优参数现在可能已经不是最优了。我一般每季度会重新跑一次检索测试看指标有没有退化。6. 进阶优化让 Loader 和 Splitter 协同工作6.1 结构化信息在两层之间的传递Loader 和 Splitter 不是孤立的两个步骤它们之间有一条信息传递的通道就是 metadata。Loader 提取出的结构信息标题层级、页码、表格标记如果能传递给 SplitterSplitter 就能做出更聪明的切分决策。举个具体例子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 优化才有意义。最后分享一个小技巧每次调整参数时只改一个变量其他保持不变这样你才能清楚地知道是哪个改动带来了效果变化——同时改多个参数即使效果变好了你也不知道该归功于谁。