做RAG知识库很多人一上来就忙着选向量模型、调Embedding参数、折腾向量数据库折腾半天召回来的内容乱七八糟。后来才发现问题根本不出在检索环节而是从文档进入系统的那一刻就已经埋下了隐患。文档处理这个看起来最不起眼的环节恰恰决定了整个知识库的上限。你喂给它的如果是垃圾它给你的一定是更精致的垃圾。这篇我主要聊聊文档处理那些容易被忽视、但极其影响RAG效果的实操细节。不聊那种一键脚本就能搞定所有场景的幻想有些文档确实可以无脑切但多数专业文档、扫描件、表格、异构排版都是需要区别对待的。这里说的每一件都是我实际处理过很多轮、踩过不少坑之后沉淀下来的经验。1. 文档处理为什么不能“一视同仁”RAG知识库的核心链路并不复杂文档进来解析成纯文本切成合适大小的块向量化后存入数据库用户提问时检索相关块交给大模型生成回答。如果最后回答不准大家习惯性去调提示词、换模型、调相似度阈值但其实根源大概率在解析和切分环节——信息已经丢了后面再怎么调检索都很难找回来。1.1 文档类型远比你想的复杂我们面对的真实文档远不止Word和PDF这么简单。拿一个中等规模的企业知识库来说常见文档至少包括制度类文档PDF、Word混合有各级标题、条款编号、页眉页脚、签批单。技术文档Markdown、HTML、PDF代码块、命令行、日志示例特别多。公告通知类可能是图片型PDF也就是扫描件也可能是一张长截图。合同协议表格、盖章扫描、手写批注混杂有些还是双栏排版。表格密集型Excel导出的PDF、财务对账单、配置清单关键信息都躺在单元格里。演示文稿PPT转出来的PDF大量文字其实是文本框还有批注和备注。如果把所有这些都丢进同一个解析器比如只用pdf库提取文本或只用Markdown解析那得到的文本质量会惨不忍睹这不是算法不够先进的问题。1.2 解析结果直接影响后续所有环节文档处理链路一旦出错问题会一路传导。比如扫描件用普通方式解析得到的是一堆乱码或空字符串向量化之后完全没法匹配。又比如表格被解析成纯文本流行和列的关系被打散LLM回答“哪个零件对应哪个供应商”时看到的是一串没有任何结构的字符根本无从对应。还有一个容易被忽视的细节切分。切分不是简单按固定字数截断。同一段文字句子中间被硬切语义就会断开表格中间被切行数据被拆到两个块里检索时只能召回其中一半代码块被拦腰截断整个示例变得不可用。这些问题是解析层和切分层的策略选错导致的和你选的Embedding模型没什么关系。所以在RAG项目里文档处理并不只是“预处理”它其实决定了整个系统的召回上限。后面所有环节的打磨只能在这个上限之下做文章。2. 第一步是分类给文档分型而不是一刀切与其试图用一套万能方案解析所有文档我建议先做文档分型把进来的文件根据形态特征归到合适的处理通道里。这个分类动作看起来多了一步实际是在节省后续排查问题的时间。2.1 快速分类的五个维度实际操作中我用五个特征来快速判断一份文档该怎么处理文本层是否存在用工具直接检测是否有可复制的文字层。如果没有基本可以判定为扫描件或图片型文档。版面结构复杂度看是否有多栏、复杂表格、公式、代码块、页眉页脚等。表格密度整页是表格还是只有零星几个表格决定要不要走专门的表格解析通道。语言与字符类型中英文混排、全角半角混用、专有名词大小写都会影响清洗策略。是否包含提取物盖章图片、签名、手写批注、二维码等这类元素是否需要保留或处理。这五个维度不需要人工逐个打开文件看可以写一个预检脚本读取文件元数据、扫描前几页内容、检测文本层和图像占比自动判一下类型。预检脚本跑完分类结果直接决定后续走的处理路径。2.2 分型之后对应不同的处理通道我一般分成几条通道文档类型典型特征处理策略主要工具/方法A类文本型PDF有文字层版面规整直接提取文本做结构化解析pdf解析库如pdfplumber、PyMuPDFB类扫描件无文字层纯图像OCR识别优先版面还原PaddleOCR、Tesseract、商用OCR接口C类表格密集有表格或图片表格表格结构识别转成Markdown/JSON表格解析模型、多模态OCRD类网页/笔记HTML、Markdown等做结构清洗剔除噪声BeautifulSoup、Jina Reader、自写解析器E类混合复杂版式多栏、公式、代码、批注混排版面分析分段提取版面分析模型、OpenCV辅助这五类不是严格的学术划分而是实践中很好用的经验分型。原本一个解析函数打天下的方案拆成这五条通道后每类文档的处理质量都能明显提升。2.3 分类之后清洗规则也要跟着变文档分型不只是选解析工具清洗策略同样要跟着变。比如A类文本型PDF页眉页脚要剔除但页脚的“第X页/共X页”和正文里的页码引用要区分开。B类扫描件OCR的置信度低于某个阈值的字符要标记出来不能直接进库否则会有一堆错别字干扰检索。C类表格清洗时更要注意保留行列结构不能简单拼成一行。清洗规则跟着文档类型走而不是一套规则用到黑这个思路是整个文档处理环节最核心的原则。3. 解析通道的选型与实操细节分类完成后最关键的实操部分就是针对不同通道选择合适的解析方案并把它们跑通。3.1 文本型PDF优先保结构而不是保速度对于A类文本型PDF核心目标是保留文档的结构信息。标题层级、段落边界、列表、加粗内容、表头这些信息对后续切分和检索非常关键。我习惯用具备版面分析能力的工具比如PyMuPDF和pdfplumber配合使用。PyMuPDF提取文本块坐标后可以根据字体大小判断标题层级pdfplumber对表格的定位更准适合抽取带位置的文本块。具体步骤大致是用PyMuPDF按页读取获取每个文本块的坐标、字号、字体信息。根据字号和加粗特征判断是否属于标题并推断标题层级。剔除页眉页脚区域可以按坐标范围过滤也可以按文本特征过滤。将文本块按坐标y轴排序合并成段落。输出成带Markdown标记的纯文本比如标题前加#号。这套流程最关键的是第2步标题层级判断。判断对了后续切分就能按标题边界来切切出来的块天然是语义完整的小节。判断错了等于把结构信息丢了后面的切分又回到盲切的老路上。3.2 扫描件与图片型PDFOCR不是万能药B类扫描件网络上有大量文字吹捧“OCR准确率99%”实际做过的人都知道干净印刷体确实可以但盖章、水印、倾斜、复杂背景下准确率下降很快。我的建议是优先选中文场景下训练充分的开源模型如PaddleOCR配合版面还原。如果预算充足对一些重要合同、图纸类文档可以调用商业OCR服务做一个双通道校验。实操几个要点先做图像预处理灰度化、二值化、倾斜矫正、去噪。很多人跳过这步直接OCR结果上来了不少奇怪的字符。OCR之后不要急着删掉坐标信息。每个文本块的位置坐标对后续表格重建、版面还原都很有用。设置置信度过滤。置信度低的字符不要硬留宁可丢一点也不要带乱码进知识库。识别完的稿子建议抽抽样人工快速过一遍。抽样比例可以控制在2%~5%发现批量性错字就要回头调预处理参数。3.3 表格类文档保留“关系”而不是保留“文字”表格类文档最容易翻车。如果只是把表格转成文本字符串那行、列、单元格之间的对应关系会全部丢失。比如一个库存表“物料编号”“库存量”“责任人”三个字段本来一一对应转成文本流后检索到“责任人”三个字却不知道它对应的是哪一行的哪一个值。比较可行的方法是把表格转成Markdown表格或JSON结构这样每一个单元格和它所在的行、列关系依然保留。LLM对Markdown表格的理解能力还可以喂给它这种格式回答问题时能够正确引用行列关系。如果表格是图片形式比如扫描的Excel截图则需要借助表格结构识别工具这类工具能识别表格线、单元格边界把图片转成结构化的表格数据。没有这类工具的话也可以用OCR先把文字提出来再按坐标聚类手动拼出表格结构但这非常费人工适合小批量场景不适合规模化处理。3.4 网页和笔记类结构清洗的价值大于解析网页转存、Notion导出、技术博客抓取这类内容最大的问题不是提取不到文字而是噪声太多。导航栏、广告、相关推荐、评论、Cookie弹窗全部会混进正文。用BeautifulSoup或Readability算法提取正文是最常见的选择。但更推荐的处理思路是先尽量保留内容自带的语义结构比如标题层级、代码块、列表、引用因为这些结构本身就是天然的分块边界。很多网页抓取工具只返回纯文本把代码块的高亮信息、列表的嵌套关系全部抹掉了这比较可惜。有一种做法是使用Jina Reader这类服务把网页转成干净的Markdown效果往往比自写解析器更好尤其对排版复杂的页面。不过这类服务有调用量限制建议搭配缓存。4. 分块策略这是文档处理中最需要动脑筋的环节解析得到干净的文本之后下一步是分块Chunking。这是我花了最多时间调优的地方也是很多人最忽略的地方。4.1 固定长度切分为什么不好用网络上很多示例代码喜欢按固定长度切块比如每500个字符切一块相邻块之间重叠100个字符。这种思路简单但实际用起来效果一般因为硬切的块经常横跨两个语义段落导致检索结果不准确。一个块应该是语义完整的单元。判断标准很简单你把一个块单独拿出来读完之后是否知道它在讲什么如果一个块是“这个方案的核心思路是左半段讲技术选型右半段开始讲费用”那这个块就是无效的。更合理的分块依据是文档自带的结构边界比如Markdown标题层级、PDF中的章节标题、HTML的标题标签。段落边界一个段落内部不要拆分尽量不要跨标题切。如果段落太长比如超过某个阈值再在段落内部按句子边界二次切分。我常用的分块流程是先按标题层级把文档拆成一棵目录树然后对叶子节点做长度检查。如果叶子节点长度在合理范围内直接用如果过长再在叶子节点内部按句子切分并尽量让块之间有少量重叠以保证上下文衔接。4.2 不同内容类型的切分阈值不同内容类型分块的大小和策略也完全不同内容类型推荐策略备注制度条款按条款编号切每条独立成块条款之间有强引用关系必要时保留条款编号技术文档按标题切代码块独立成块代码块不要和正文混在一起代码块内部尽量完整保留表格数据按表切每张表独立成块表头行保留在每块中否则检索时字段含义丢失FAQ/对话按问答对切一问一答为一块保持提问与回答的对应关系长篇章节按二级标题切必要时再按段落分不要试图把整章塞进一个块切分的核心原则就一句话优先保语义完整性其次才是控制块大小。向量模型通常对超过一定长度的文本处理效果会变差这个长度因模型而异我自己一般控制在300~800字之间具体阈值需要通过实验来定。4.3 分块时保留上下文信息分块时还容易踩一个坑切出来的块脱离上下文检索时不知道这块来自哪个文档、哪个章节。比如单纯切出来“预算审批不得超过三天”这样的句子回头检索到了模型并不知道这是哪个制度的哪一条。解决办法是给每个块附加父子元数据。块本身存向量但元数据里带上父文档的标题、所在章节路径、页码等。检索时既可以根据块内容匹配也可以利用这些元数据做过滤或追溯。这一步很不起眼但在实际使用中价值巨大。尤其是企业知识库中同类型文档很多来自不同部门、不同时间、不同地区的相似条款容易混淆有了元数据回答时能准确说清楚“依据是某某单位某某制度第几条”可信度高一大截。5. 踩坑实录文档处理常见问题和排查技巧这部分整理一些我实际踩过、别人也经常来问的坑每一件都对应一个具体场景你可以直接对照排查。5.1 扫描件OCR之后全是乱码怎么排查很多人遇到OCR结果全是乱码第一反应是换OCR引擎。其实大部分情况是图片预处理没做好。常见的原因包括原图分辨率太低OCR对低分辨率图几乎无解。建议先检查原图DPI低于200dpi的直接先做超分或提醒重新扫描。图片有底色或水印导致二值化后字符断裂或粘连。这时候要先做背景去噪再做二值化。倾斜角度过大OCR识别率断崖式下降。先用投影法或边缘检测做倾斜矫正再进OCR。排查顺序建议先查原图质量再查预处理流程最后再看OCR模型参数。不要一上来就盲目调参容易白费时间。5.2 表格解析后行列错位表格解析出现行列错位常见于合并单元格、跨行表头、同一格里换行等情况。遇到这种问题建议在解析后加一个验证步骤从表格中随机抽取几个单元格对比原文和解析结果确认对应关系正确。如果用的是坐标聚类方法拼表格行列错位通常是因为文本块坐标聚类的阈值设得不对行与行没分开或者列与列被合到一起。此时需要调整坐标容差尤其是合并单元格场景不能只按坐标一刀切要结合单元格坐标范围做二次判断。说实话表格解析没有一劳永逸的方案。我现在的做法是能转成结构化数据的尽量转转不了的保留“原样截图为图片OCR文字摘要”两条路并行检索时优先返回图片和结构化数据文字摘要作辅助。5.3 同一文档在不同解析器下结果差异极大同一个PDF用不同的库解析结果经常完全不同。有的库能保留表格结构有的库只能输出流式文本。这其实是正常的因为这些库背后的算法逻辑不一样有的基于规则有的基于版面分析模型。所以不建议在一个项目里混用多个解析器去解析同一份文档应该选定一套主解析链路并把其他解析方案作为补充验证或备份。混用多个解析器不仅会带来结果不一致的问题还会让后续的问题排查变得复杂因为你很难确定当前这一版结果来自哪个环节。5.4 切分后信息重复率高固定长度重叠切分时如果重叠区域太大检索时容易召回好几块内容高度相似的块导致最终回答冗余。可以这样优化重叠区控制在块长度的10%~20%或者干脆不重叠靠父子元数据实现上下文衔接这样信息重复率更低。如果发现检索结果总是好几块讲同一件事还有一个思路是查重在建库时对文本块做模糊去重。常见算法有MinHash、SimHash也可以直接用向量相似度去重。这个操作能显著降低索引体积提升检索质量。5.5 混合文档既有扫描页又有文本页不少合同文档是这样的前面几页是Word打印的文本层PDF中间夹了一份盖章扫描页后面又接入附件。这种情况如果整份文档走同一个通道要么扫描页被当作文本PDF处理导致空白要么整个文档被当成扫描件走OCR浪费时间和算力。建议在预检阶段就逐页检测文本层把每一页标记为text_page或image_page然后按页分流处理。文本页走文本解析扫描页走OCR最后在输出层按页顺序合并。这个处理方式在混合合同、标书、鉴定报告中非常常见值得提前留意。6. 索引质量与召回验证验证文档处理做得对不对文档处理做得是否正确最直接的验证方式就是看召回效果。不是在线测试那种肉眼感觉而是用一套标准问题集做离线评测。6.1 建立评测问题集我习惯在每个知识库上线初期建立一个评测问题集大概50~100个问题覆盖业务中的高频提问、复杂查询和边角案例。每个问题标注出应召回的文档标题、段落或关键词。评测问题集要边用边补充尤其当业务方反馈“明明有这个内容但AI说没有”的时候这类问题最有价值说明你的处理链路在某类文档上存在盲区值得针对性去补。6.2 召回测试判断处理链路问题召回测试我常用三个指标判断是哪一环出了问题完全没召回极可能是解析环节丢了文本而不是检索参数问题。去查原始文档是否成功解析、文本是否干净。召回了但位置不对很可能是切分逻辑问题目标内容被切进了一个语义混杂的块导致向量与该问题不匹配。召回了但信息不完整可能切分时把相关信息切到了相邻块而这两块之间没有建立足够的关联。这三类情况分别对应文档处理链路中的解析、切分、元数据问题。针对性地修比盲调Embedding模型更有效。6.3 常见文档处理质量检查项做完一批文档处理之后可以批量抽检几个点文本层抽取率有文本层的文档抽查是否有丢字、漏段。OCR抽样准确率扫描件抽几页把OCR结果与原图比看是否有批量错字。表格结构完整度抽查表格行列数量与原文是否一致。标题层级体系解析后的文档标题层级是否和原文档一致还是全部变成了一级标题。切分后的块内容随机抽查几个块看是否有半句、孤立代码、悬挂表头等情况。这五个项检查完基本能判断一条处理链路是否成熟。7. 一些工具选型和工程化的建议最后聊一下工具选型和工程化落地的经验这部分不会展开太多但每个点都是我实际对比过后的结论。7.1 开源优先商用作兜底在文档处理工具的选择上建议开源优先。开源方案的好处是可以本地化部署、方便调试、没有按量付费的压力。但是开源方案的坏处也很明显配置复杂、对复杂版面支持不稳定。所以在关键业务场景比如核心合同、图纸、行业特有的复杂表格商用OCR或文档解析服务作为兜底是值得的。我当时给某企业知识库做文档处理时策略就是“开源主链商用补充”常规文本型PDF和网页笔记走开源链路扫描件和复杂表格入库前用商用接口过一次。成本适中整体效果也能接受。7.2 流程编排串行还是并行文档处理流程涉及多个阶段格式识别、语言检测、文本提取、OCR、清洗、切分、元数据标注、向量化、入库。实际工程上不建议做一个超级函数一气呵成而是拆成几个独立服务或函数每个环节可配置、可重入、可观测。我的做法是统一入口把文件传到对象存储或本地目录生成任务ID。预检服务返回文档类型和推荐通道。按分类进入不同的解析通道。所有解析结果统一成标准格式Markdown或JSON。切分和元数据标注在标准格式基础上进行。最后向量化并入库。每个步骤独立记录日志出了问题直接看日志定位断点不需要从头重新开始。这条工程化思路让我在后续维护知识库时省了大量时间。7.3 需要保留原始文件虽然目标是提取文本但原始文件一定不能丢。原因很简单后续如果发现某一段文本解析错误需要回到原始文件重新处理如果某个问题用户需要追溯原文也需要保留原始文档供展示。所以不管处理链路多长都不要对原始文件原地修改。解析输出的是一个又一个版本原始文件永远保留在存储层。这条习惯帮我避免了不止一次重新扫描的麻烦。8. 最后分享一点心得做RAG知识库以来最大的体会是很多人把精力放在调模型、调提示词上却忽略了文档处理才是整个系统的地基。地基不牢上面的检索、生成再花哨也没用。文档处理不是跑一个脚本、统一解析、统一切分就完事的它需要你理解文档的多样性理解文档里哪些信息重要、哪些是噪声理解解析和切分之间的微妙配合。这些经验不是看几篇文档就能获得的需要结合自己的业务场景反复试错、反复验证效果。你现在如果正在做知识库建议花点时间梳理一下现有文档的类型分布看看当前处理链路是不是“一刀切”。如果是先把文档分类和分类型处理这件事做好回头你会发现检索质量提升的幅度比换一个更强的Embedding模型更明显。这条经验是我实际走完项目之后最想告诉你的一点。