1. 从一堆乱码到可用知识Loader 到底在解决什么问题很多人第一次搭 RAG 系统注意力全放在向量库选型、Embedding 模型对比、重排策略调参上结果跑起来效果一塌糊涂回头查半天才发现——问题出在最不起眼的入口环节文档根本没被正确读进来。我见过太多案例PDF 里的表格读出来是一串乱码Word 里的多级标题全被拍平成一坨网页抓下来的正文混着导航栏和广告。你后面用再贵的模型、再精细的检索策略都是在垃圾上做精加工。Loader 的职责说起来简单把各种格式的原始文件转成一段段纯文本同时尽量保留结构信息。但尽量保留结构这五个字才是真正拉开差距的地方。一个合格的 Loader 不只是做格式转换它要回答几个关键问题这段文字来自文档的哪个位置它属于标题还是正文表格的行列关系还在不在多个文件之间有没有顺序和层级1.1 为什么读进来比检出来更值得花时间我做过一个粗略统计在效果不理想的 RAG 项目里大约六成的问题可以追溯到数据摄入阶段。检索环节的优化空间其实有限因为向量检索的本质是语义相似度匹配它只能在你喂进去的文本块里找最像的。如果文本块本身就是残缺的、错位的、丢失上下文的检索再准也是错的。举个具体场景。一份产品需求文档里面有功能模块 A 支持三种模式这样的句子紧接着下面是一个三行的表格列出三种模式的名称。如果 Loader 把表格拍平成模式一 模式二 模式三这样一行那么当用户问功能模块 A 支持哪几种模式时检索到的文本块里可能只有支持三种模式这句话而具体的模式名称被切到了另一个块里。模型拿到这个块只能回答支持三种具体是哪三种它不知道。这就是 Loader 的核心价值它决定了后续所有环节的信息天花板。你在 Loader 阶段丢掉的信息后面任何环节都补不回来。1.2 不同格式的文档Loader 的处理逻辑差异有多大不同文件格式的内部结构天差地别Loader 的处理策略也必须因格式而异。我按实际项目中的踩坑经验把常见格式分了个类格式类型结构复杂度主要难点推荐处理思路纯文本 / Markdown低编码问题、换行符差异直接读取按标题层级切分Word 文档中样式与内容分离、多级标题解析样式信息保留标题层级PDF文本型高分栏、页眉页脚、表格按版面分析过滤噪声区域PDF扫描型极高需要 OCR识别精度不稳定OCR 后人工抽检关键文档人工校对网页 HTML高导航、广告、评论区混入正文提取算法按 DOM 结构过滤演示文稿中图文混排、备注信息提取文本框和备注忽略装饰元素这个表格不是让你照搬而是提醒你不要指望一个通用 Loader 搞定所有格式。实际项目中我通常按格式分组处理每组用不同的解析策略最后统一输出成带元数据的文本块。1.3 元数据Loader 最容易被忽视的产出大多数人只关心 Loader 输出的文本内容却忽略了元数据。元数据是后面检索和生成阶段的重要线索。我一般会在 Loader 阶段就采集这几类信息来源信息文件名、文件路径、文件类型、最后修改时间位置信息页码、段落序号、在原文中的字符偏移量结构信息所属标题层级、是否为表格、是否为列表项业务信息文档分类、所属项目、版本号这些通常需要额外配置为什么位置信息这么重要因为当模型生成答案时你可以把来源位置一并返回给用户让用户能快速定位到原文。这在企业知识库场景里是刚需——用户不信任一个没有出处的答案。提示元数据的字段设计要在项目初期就定好后期再补会非常痛苦因为已经入库的向量需要全部重新生成。2. Splitter 的切分逻辑为什么你的检索总是差一口气文本切分看起来是个体力活实际上是个技术活。切得太碎每个块信息不完整模型回答时缺上下文切得太大一个块里混了好几个主题向量表示被稀释检索时匹配不准。这个平衡点怎么找是 Splitter 要解决的核心问题。我见过最粗暴的做法是按固定字符数切比如每 500 字一刀。这种做法在 demo 阶段能跑通但一上真实文档就露馅——它会把一个完整的句子拦腰截断会把表格从中间切开会把标题和它下面的正文分到两个块里。2.1 固定长度切分的三个致命伤先说说为什么固定长度切分不可取这样你才能理解后面那些更复杂策略的价值所在。第一个问题是语义断裂。假设原文是该功能支持三种模式自动模式、手动模式和混合模式。如果切分点刚好落在手动模式后面那么第一个块以自动模式、手动模式结尾第二个块以混合模式开头。检索支持哪些模式时可能只召回第一个块答案就漏了混合模式。第二个问题是结构破坏。Markdown 文档里一个二级标题下面跟着三段正文。如果按固定长度切很可能标题单独成一个块三段正文被切成两个块。检索时标题块因为没有实质内容而匹配度低正文块又缺少标题提供的主题信息。第三个问题是块大小不均。同样按 500 字切有的块是完整段落有的块是半句话加半句话。这种不一致性会让 Embedding 模型的表现不稳定因为模型训练时见过的文本通常是完整语义单元。2.2 递归切分目前最稳妥的通用方案递归切分Recursive Splitting是我在大多数项目里的默认选择。它的思路是准备一组分隔符从大到小依次尝试。先按段落切如果某个段落还是太大再按句子切如果句子还大再按逗号切最后才按字符切。这个策略的好处是优先保持大粒度语义单元的完整性。段落是作者已经组织好的语义单元能按段落切就按段落切。只有当段落超长时才退而求其次按句子切。具体参数怎么定我的一般经验是块大小chunk_size中文文档 300-500 字英文文档 500-1000 字符。这个范围是基于 Embedding 模型的有效上下文长度和检索精度的平衡点。重叠大小chunk_overlap块大小的 10%-20%。重叠的作用是防止关键信息刚好落在切分边界上被切断。分隔符优先级段落分隔 换行 句号/问号/感叹号 分号 逗号 空格 字符为什么重叠不能太大因为重叠部分会在多个块里重复出现检索时可能召回多个内容高度相似的块浪费上下文窗口。10%-20% 是个比较安全的范围。2.3 按结构切分当文档本身就有清晰层级时如果文档本身有清晰的标题层级比如 Markdown、Word 的多级标题、HTML 的 heading 标签那最好的切分策略是按结构切分而不是按长度切分。具体做法是以标题为锚点把每个标题及其下属内容作为一个块。如果某个标题下的内容太长再在这个块内部用递归切分。这样每个块都自带主题信息检索时匹配度会高很多。我处理过一份技术规范文档有三级标题。按结构切分后每个三级标题下的内容作为一个块块的第一行就是标题文本。用户问XX 功能的参数配置有哪些时检索直接命中对应标题的块因为标题文本本身就包含了XX 功能和参数配置这些关键词。这种策略的代价是块大小可能不均匀。有的标题下只有一句话有的标题下有上千字。对于太小的块可以考虑和相邻块合并对于太大的块在内部继续递归切分。2.4 表格和代码块的特殊处理表格和代码块是两类特殊内容用常规切分策略很容易出问题。表格的核心是行列关系。如果按行切表头会丢失如果按列切行之间的关系会断裂。我的做法是小表格整体作为一个块并在块开头加上表头信息大表格按行分组每组都带上表头。代码块的核心是完整性和上下文。一个函数被从中间切开后半段单独看毫无意义。我的做法是按函数或类为单元切分如果函数太长按逻辑段落切并在每个块开头注明所属函数名。注意表格和代码块的切分策略没有通用方案必须结合你的具体文档类型和检索需求来定。建议在项目初期就准备一批典型文档做切分效果测试。3. 从原始文件到向量入库一条完整的处理链路前面两章分别讲了 Loader 和 Splitter但实际项目中它们是串在一起的中间还有清洗、增强、元数据注入等环节。这一章我把整条链路拆开逐步说明每个环节在做什么、为什么这么做。3.1 第一步格式识别与路由分发拿到一批文件后第一件事不是直接读而是先识别格式然后路由到对应的处理管道。这个判断逻辑看似简单但有几个坑扩展名不可信有的文件扩展名是 .pdf实际内容是纯文本有的 .doc 其实是 .docx。稳妥的做法是读取文件头部的魔数magic number来判断真实格式。编码问题中文文档常见 GBK、GB2312、UTF-8 三种编码。如果编码判断错了读出来全是乱码。我的做法是先尝试 UTF-8失败后尝试 GBK再失败就用 chardet 之类的库做检测。加密文件有些 PDF 和 Word 有密码保护直接读会报错。需要在路由阶段就识别出来单独处理或跳过。路由分发的意义在于不同格式用不同的解析器避免用一个通用解析器硬扛所有格式导致效果打折。3.2 第二步内容提取与噪声过滤解析器读出原始内容后通常夹杂着大量噪声。以 PDF 为例常见的噪声包括页眉页脚每页重复出现的文字页码水印文字扫描件的 OCR 错误分栏导致的文字顺序错乱过滤策略我一般分两步走。第一步是规则过滤统计每页都出现的短文本大概率是页眉页脚直接删掉纯数字且长度小于 5 的大概率是页码删掉。第二步是位置过滤PDF 解析后每个文本片段都有坐标信息页面顶部和底部固定区域的文字大概率是页眉页脚。网页的噪声过滤更复杂因为导航栏、侧边栏、广告、评论区的位置不固定。我通常用正文提取算法基于文本密度和 DOM 结构提取出主体内容区域其余部分丢弃。3.3 第三步文本清洗与规范化提取出来的文本还需要清洗主要处理这几类问题多余空白连续多个空格、制表符、换行符统一压缩特殊字符零宽字符、软连字符、不换行空格替换或删除乱码修复常见的编码错误导致的乱码字符尝试修复全半角统一中文文档里混用的全角半角标点统一处理清洗的度要把握好。过度清洗可能把有意义的格式信息也删掉比如代码块里的缩进。我的原则是只处理明确无意义的噪声对有语义的格式保持原样。3.4 第四步切分与元数据注入清洗后的文本进入 Splitter按前面讲的策略切分成块。每个块生成后立即注入元数据。元数据的来源有三个从 Loader 继承来源文件、页码、位置等从切分过程生成块序号、所属标题、块内字符数等从外部配置注入业务分类、版本号、权限标签等元数据注入的时机很关键。必须在块生成的同时注入不能等入库后再补因为入库后块和原始位置的对应关系就丢了。3.5 第五步质量抽检与入库在正式入库前我强烈建议加一道质量抽检环节。具体做法是随机抽取 5%-10% 的块人工检查以下几项块内容是否完整没有被拦腰截断元数据是否准确页码、标题对应关系是否有明显的噪声残留块大小分布是否合理这一步看起来费时间但能避免大量脏数据入库。一旦脏数据进了向量库清理起来非常麻烦因为你需要重新走一遍全流程。抽检通过后块进入 Embedding 环节生成向量后连同元数据一起写入向量库。至此一条完整的处理链路才算走完。4. 实战中那些文档不会告诉你的坑理论讲完了这一章全是实战中踩出来的经验。有些坑我踩过不止一次每次都觉得这次应该不会了吧结果还是中招。4.1 PDF 解析的玄学同一份文件两次解析结果不一样这个坑我第一次遇到时完全懵了。同一份 PDF用同一个解析库两次运行读出来的文本居然有细微差异。后来查了半天才明白有些 PDF 解析库内部用了多线程文本片段的输出顺序受线程调度影响导致每次结果略有不同。解决办法是在解析后加一步排序按文本片段的坐标先纵后横重新排列。这样无论解析顺序如何最终输出都是稳定的。另一个 PDF 的坑是分栏。学术论文常见双栏排版如果解析器不识别分栏会把左右两栏的文字交错读出来读出来就是左栏第一行 右栏第一行 左栏第二行 右栏第二行这种鬼东西。解决办法是用支持版面分析的解析器或者按坐标把文本片段分到左右两个区域分别读取后再拼接。4.2 中文分词的隐性影响做中文 RAG 时Splitter 按句子切分需要先做分句。中文分句看似简单——按句号、问号、感叹号切就行了。但实际上中文里句号的使用很灵活省略号、引号内的句号、小数点、网址里的点都会干扰分句。我遇到过一份文档里面大量使用。作为列表项的分隔符结果按句号切分后每个列表项都被切成了独立的块而列表项之间其实是有逻辑关系的。后来我调整了策略先识别列表结构列表项之间不切分整个列表作为一个块。4.3 块重叠导致的重复召回前面说重叠大小建议 10%-20%但实际项目中我发现如果文档本身重复内容就多比如合同模板、产品说明书重叠会加剧重复召回的问题。用户问一个问题检索回来五个块其中三个内容高度相似只是因为重叠区域不同。解决办法有两个一是降低重叠比例二是加一步去重。去重可以在检索后做对召回结果按内容相似度聚类每类只保留一个代表块。我一般用简单的文本相似度比如 Jaccard 相似度做粗去重效果已经够用。4.4 元数据字段膨胀元数据是好东西但容易失控。项目初期可能只采集了五六个字段随着需求增加慢慢膨胀到二三十个。字段多了之后向量库的存储压力增大检索时的过滤条件也变复杂。我的经验是元数据字段分两类一类是检索必需的比如来源、分类、时间这类字段要建索引另一类是展示用的比如页码、标题这类字段不建索引只随结果返回。定期审查元数据字段把不再使用的字段清理掉。4.5 增量更新时的块对齐问题文档更新后需要重新处理并更新向量库。如果文档只是小改重新切分后块的边界可能和之前不一致导致新旧块无法对齐。简单粗暴的做法是全量重建但文档量大时耗时太长。我的做法是在块元数据里记录内容哈希。更新时先对比新旧文档的内容哈希只处理变化的段落。对于变化的段落重新切分并替换对应的旧块。这样能把更新范围控制到最小。提示增量更新的前提是块元数据里有足够的信息来定位旧块。如果初期没设计好后期做增量更新会非常痛苦。5. 不同场景下的 Loader 与 Splitter 选型思路没有万能的 Loader 和 Splitter只有适合具体场景的组合。这一章我按几种典型场景说说选型思路和配置要点。5.1 企业知识库重结构、重元数据企业知识库的文档通常有规范的格式和分类比如产品手册、规章制度、技术文档。这类场景的特点是文档结构清晰、更新频率中等、检索需求明确。Loader 选型上优先选支持结构解析的。Word 文档用能读样式信息的解析器PDF 用支持版面分析的解析器。元数据要采集全特别是文档分类、版本号、生效日期这些业务字段。Splitter 选型上优先按结构切分。以标题为锚点每个标题下的内容作为一个块。块大小控制在 300-500 字超长的在内部递归切分。重叠比例可以低一些10% 左右即可因为结构切分本身已经保证了语义完整性。5.2 客服问答库重语义、重召回客服问答库的文档通常是问答对、FAQ、产品说明。这类场景的特点是文档短小、语义密集、检索频率高。Loader 选型上重点是准确提取问答对。如果原始文档是表格形式的 FAQ要确保问题和答案的对应关系不丢失。如果是对话记录要区分用户提问和客服回答。Splitter 选型上问答对天然就是完整的语义单元不需要再切分。如果答案太长可以在答案内部按句子切分但问题和答案的关联关系要保留在元数据里。块大小可以小一些200-300 字因为问答对的语义密度高。5.3 长文档摘要与检索重覆盖、重层次长文档比如研究报告、学术论文、书籍的 RAG 需求通常是两类一是全文摘要二是精准检索某个细节。这两类需求对切分策略的要求不同。摘要需求希望块能覆盖全文所以块可以大一些500-800 字重叠比例高一些20% 左右确保没有信息盲区。检索需求希望块精准所以块要小一些300 字左右并且要保留层级信息让检索结果能追溯到章节。我的做法是双粒度切分同时生成大块和小块大块用于摘要小块用于检索。检索时先召回小块再根据小块的元数据找到对应的大块把大块作为上下文喂给模型。这样兼顾了检索精度和上下文完整性。5.4 多语言混合文档重编码、重分句多语言混合文档比如中英文混排的技术文档的难点在于分句和分词。中文按字英文按词混在一起时简单的按空格或按标点切分都会出问题。Loader 选型上重点是编码处理。中英文混排文档常见 UTF-8 编码但偶尔也有 GBK 混入英文的情况需要做编码检测和转换。Splitter 选型上分句逻辑要能识别中英文标点。中文句号、问号、感叹号英文句号、问号、感叹号都要作为分句依据。同时要注意英文缩写里的点比如 et al.、e.g.不能误判为句号。块大小按字符数算中英文混排时同样字符数下中文信息量更大所以块可以适当小一些。6. 怎么判断你的 Loader 和 Splitter 配好了配好了没有不能靠感觉要有可验证的标准。这一章我分享几个我在项目中实际使用的检验方法。6.1 用检索命中率做量化评估准备一批测试问题每个问题都有明确的标准答案和对应的原文位置。然后跑检索看检索结果里是否包含标准答案所在的块。命中率低于 80%说明 Loader 或 Splitter 有问题。这个评估要分场景做。事实型问题XX 是什么和推理型问题为什么 XX的命中率可能差异很大。如果事实型问题命中率高但推理型低可能是块切得太碎缺少推理所需的上下文。6.2 人工抽检看块的内容是否自洽随机抽一批块人工读一遍问自己如果我只看到这个块能不能理解它在说什么如果块的开头是因此该方案...但你不知道该方案指什么说明这个块缺少上下文切分有问题。自洽的块应该满足有明确的主题、有完整的论述、不依赖其他块就能理解大意。如果大量块不自洽说明切分粒度太细或切分点选得不好。6.3 边界检查看切分点是否落在语义边界上专门检查块的边界。好的切分点应该落在段落之间、句子之间而不是句子中间、词语中间。如果发现大量块以半句话结尾、半句话开头说明分隔符优先级设置有问题。我一般会写个小脚本统计所有块的结尾字符和开头字符。如果结尾字符大量是逗号、分号说明切分点太靠内如果结尾字符大量是句号、问号说明切分点比较合理。6.4 元数据完整性检查检查每个块的元数据字段是否齐全、值是否合理。常见的元数据问题包括页码为空、标题层级错误、来源文件路径不对。这些问题在检索时可能不会立即暴露但会在结果展示和溯源时出问题。我通常会在入库前跑一个校验脚本检查元数据的必填字段是否都有值、值是否在合理范围内。校验不通过的块打回重处理不进入向量库。注意这些检验方法要在项目初期就建立不要等系统上线后再补。初期建立的成本低后期补的成本高而且后期往往因为数据量大而难以全面检查。7. 一些可以立刻用上的配置参考最后分享几组我在实际项目中用过的配置你可以直接参考或在此基础上调整。这些配置不是标准答案但能帮你少走一些弯路。7.1 通用中文文档的递归切分配置# 递归切分参数参考 chunk_size 400 # 中文文档 300-500 字比较稳妥 chunk_overlap 60 # 约 15% 重叠 separators [ \n\n, # 段落分隔 \n, # 换行 。, , , # 中文句末标点 , # 中文分号 , # 中文逗号 , # 空格 # 字符级兜底 ]这个配置适合大多数结构清晰的中文文档。如果你的文档段落特别长可以把 chunk_size 调大到 500-600如果文档段落短小密集可以调到 300。7.2 带层级结构的 Markdown 切分配置# 按标题层级切分的思路 # 一级标题作为大块边界 # 二级标题作为中块边界 # 三级标题作为小块边界 # 块内超长时用递归切分兜底 max_chunk_size 600 # 结构切分的块可以稍大 min_chunk_size 100 # 太小的块考虑与相邻块合并 overlap 0 # 结构切分通常不需要重叠结构切分的关键是正确识别标题层级。Markdown 用 # 的数量表示层级Word 用样式名表示层级HTML 用 h1-h6 标签表示。识别准确后按层级组织块每个块的第一行是标题文本。7.3 PDF 解析后的清洗规则参考# 常见噪声过滤规则 noise_patterns [ r^\d$, # 纯数字页码 r^第\s*\d\s*页$, # 第 X 页 r^-\s*\d\s*-$, # - X - 形式的页码 r^\s*$, # 空行 ] # 页眉页脚检测统计每页都出现的短文本 # 位置过滤页面顶部 5% 和底部 5% 区域的文字清洗规则要根据具体文档调整。建议先跑一批文档统计高频噪声模式再针对性写规则。7.4 元数据字段设计参考字段名类型是否索引说明source_filestring是来源文件名source_pathstring否完整路径page_numberint否页码PDF 类chunk_indexint否块序号headingstring是所属标题content_hashstring是内容哈希用于增量更新categorystring是业务分类versionstring是文档版本created_atdatetime是入库时间这个字段设计覆盖了大多数场景的需求。category 和 version 是业务字段需要根据你的具体业务调整。content_hash 用于增量更新建议保留。7.5 质量抽检的检查清单块内容是否完整没有被拦腰截断块开头是否有足够上下文不依赖前一个块元数据字段是否齐全值是否合理块大小分布是否集中在目标范围附近是否有明显的噪声残留页眉页脚、乱码表格和代码块是否保持完整重叠区域是否过大导致重复内容过多这份清单可以做成脚本自动检查一部分比如块大小分布、元数据完整性另一部分需要人工抽检比如内容自洽性、噪声残留。我在实际项目中的体会是Loader 和 Splitter 的调优是个迭代过程。第一版配置跑通后用真实数据做检索测试根据命中率和人工抽检结果调整参数反复几轮才能达到比较理想的状态。不要指望一次配置就完美也不要等到系统上线后才开始调优。把这两个环节做扎实后面的检索和生成环节会省很多力气。