做RAG检索增强生成知识库的十有八九都在PDF上栽过跟头。明明用的是当前主流的框架喂进去的也是正经文档可一问细节就翻车不是答非所问就是一本正经地编。我做了几个企业的知识库项目之后发现问题往往出在最前面那一层——PDF文档解析。这篇把PDF解析拆成三层来讲第一层解决“抽文本”第二层解决“识结构”第三层解决“可检索”。不管你是正在做企业知识库、智能问答还是刚接触RAG准备搭第一个demo这套思路都值得花点时间看完。1. 为什么要把PDF解析拆成三层来做1.1 直接全文入库为什么会翻车先说一个最常见的现象不少人拿到PDF不管三七二十一把整篇文档转成字符串调一下切块参数就塞进向量库。跑起来看似没问题真正一问细节就露馅答案找不到、上下文对不上、表格数据全乱。本质原因是PDF本身就是“给人看的”不是“给模型用的”数据格式。PDF内部记录的是文字、图形和坐标它不保证段落之间有严格的逻辑关系也没有语义顺序甚至不保证你能按视觉阅读顺序把文字读出来。另外embedding模型对输入长度有上限文本越长向量语义表达越容易被稀释。把三五十页的文档整篇编码得到的向量就像一锅大杂烩谈不上精确定位。现在你应该明白了直接“全文进库”相当于把“文档理解”这件事完全甩给模型模型当然搞不定。1.2 三层各自的定位与分工我讲的“三层”不是网络里常说的三层交换机也不是MVC软件架构里的那三层而是按数据处理深度拆出来的三层L1 文本层Text Layer把PDF里的字符、内容完整提取出来做到“抽得准、抽得全”。L2 结构层Structure Layer识别文档的标题层级、段落边界、表格、列表等结构把纯文本变成有组织的文档。L3 应用层Application Layer根据语义和检索需求做切块、加元数据、向量化、召回让文档真正能被RAG系统使用。可以用一个生活化的类比来理解处理一栋楼先要把砖、水泥、钢筋这些材料准确拆出来L1再搞清楚哪些是承重墙、哪些是框架、哪些是隔断L2最后才能根据户型图去设计水路电路L3。少了任何一步后面的工作都会很被动。1.3 这个分层思路适合用到哪里我实际用下来的感受是凡是文档形式比较复杂、内容比较正式的RAG场景都需要这套思路。比如企业制度问答、产品手册问答、研究报告分析、技术文档智能客服。反过来如果是几十行的小文档、临时测试用的一段话直接用最简单的切块也能凑合没有必要套这么多层。所以这个分层不是为了炫技是为了让数据加工过程可控、可追踪、可优化。你遇到了问题能知道该去哪个环节排查而不是对着黑盒干瞪眼。2. 第一层实战把PDF变成干净的纯文本2.1 文本抽取工具选型PyMuPDF为什么是首选提取PDF文本的第一选择我强烈建议PyMuPDF也就是Python里的fitz。它支持的文件类型全运行速度快在普通笔记本上解析一份几十页的PDF通常只要一两秒。pdfplumber虽然也常用但速度慢一个量级更适合处理表格这类需要精细坐标信息的任务。pypdf的抽取能力比较弱遇到复杂版面容易乱。简单对比一下工具速度表格抽取坐标信息适用场景PyMuPDF很快支持新版有find_tables丰富大批量文本抽取、常规版面文档pdfplumber较慢强可精细控制精细表格抽取、版面精细分析pypdf中等弱弱简单PDF、临时脚本如果你处理的PDF很多批量任务跑一晚上PyMuPDF和pdfplumber的耗时差距会非常明显。所以我的默认选择是PyMuPDF遇到表格再单独用pdfplumber或专用表格解析工具。2.2 用PyMuPDF写一个最小文本抽取脚本代码非常简单核心就是fitz.open加page.get_textimport fitz doc fitz.open(example.pdf) for page_num in range(len(doc)): page doc.load_page(page_num) text page.get_text(text) print(f 第 {page_num 1} 页 ) print(text)如果你只需要纯文本用get_text(text)即可。这个方法抽取的是PDF内部的文字对象不是像素级的东西。绝大多数单栏、正常排版的PDF抽出来的文本顺序都没问题。这里有个小技巧如果你在做日志排查给每页文本前面加上页码标记后面定位问题会方便很多。2.3 双栏排版、页眉页脚、乱序文本这几个坑必须躲开双栏PDF是重灾区。学术论文、行业报告都喜欢双栏排版直接抽取时文字会按物理行交叉混排读起来完全不通。解决办法是用get_text(dict)拿到每个文本块的位置坐标按x坐标排序或者把页面在中间一分为二左右两半分别抽取再拼接。blocks page.get_text(dict)[blocks] # 每个block里有lines每个line里有spans # 按block[bbox][0]即左上角x坐标排序就能恢复左栏到右栏的顺序页眉页脚、页码这类噪声也很要命。不过滤的话后面切块时每个块都带着“第X页”“公司内部资料”这种垃圾信息检索时还会干扰向量排名。最简单的做法统计分析高频出现的短字符串做成一个stoplist抽取文本后直接把命中的内容删掉。另外一个常见的坑是换行符。PDF里的自动换行是排版行为不是语义结束。如果直接按换行符切文本一句话会被劈成好几段。后面做段落边界判断时需要把这些“行尾回行”合并回完整的段落。3. 第二层实战从纯文本到结构化文档3.1 为什么要做结构识别纯文本抽取完它还是一串扁平的文本流。如果拿这份文本直接切块切出来的块一定会跨标题、跨段落甚至把表格从中间劈成两半。问题就出在这RAG检索到一个“半句话”之后它自己都搞不清这条信息属于哪个章节、上下文是什么。结构层要做的事就是把标题、段落、表格这些边界识别出来。别小看这一步它决定了后面所有切块和检索的质量。3.2 标题层级识别用字体、字号和编号规则就够了对于绝大多数排版规范的PDF标题层级不需要上深度学习靠规则就够用。可以从这几个维度入手字号是否比正文大字体是否加粗是否带“1、1.1、一、一”这类编号前后是否有明显间距。我一般写一套简单规则先把文档所有文本行拆出来记录每行的字号、字体、缩进和页码再按阅读顺序排好用“字号大于正文 加粗 编号模式”这几个特征给行打标签。比如一个文本行字号比正文大2pt以上而且加粗编号匹配^\d\.\d基本可以判定是H2级别的标题。import re body_size 10.5 # 从文档正文抽样得到的字号 def identify_heading(line): if line[size] body_size 1.5 and line[bold]: if re.match(r^\d(\.\d)*, line[text].strip()): depth line[text].strip().split(.)[0].count(.) return fH{depth 1} return None这套规则在标准技术文档上命中率很高。但扫描版PDF就不一定了因为OCR拿到的字体信息不可靠这时候就得靠版面分析模型或者人工校准。这是后话后面在常见问题里展开。3.3 表格识别与表格转Markdown表格在PDF里是老大难因为PDF不保留表格的逻辑结构很多表格本质是一堆绝对定位的文本块。处理路径我一般分两步先识别表格区域再把识别出来的二维数组转成Markdown表格。Markdown表格是当前对RAG最友好的表格表达方式既保留行列关系又不带复杂样式。import pdfplumber with pdfplumber.open(sample.pdf) as pdf: page pdf.pages[0] table page.extract_table() if table: md [] for i, row in enumerate(table): cells [(c or ).replace(\n, ) for c in row] md.append(| | .join(cells) |) if i 0: md.append(| ---| * len(row)) print(\n.join(md))提醒一下不是所有表格都能被识别出来。无边框表格、表头跨行跨列、合并单元格都非常容易识别失败。所以工程上要加一道“校验 兜底”逻辑表格识别失败时按段落文本保留该区域内容并把表格前后的文本块关联起来至少别让信息丢失。你想想一份技术手册里的参数表问不出来用户就会觉得系统“不智能”。3.4 段落边界怎么按语义块而不是按字数切文本传统字符串切块本质是“数着字数切”。结构化方式应该是“按语义组织切”。最简单有效的做法先利用标题结构把文档切到章节级别再按段落做细切。段落边界以换行符、句号、缩进为判断依据但不能看到换行就断特别是PDF排版中的强制换行很容易造成误判。我处理时会把“换行”分成两类段内换行就是行尾自动回行特征是上一行末尾没有句号、下一行没有缩进段间换行特征是存在空行或明显段间距。合并段内换行、保留段间边界这一步做完文本结构就清楚多了。4. 第三层实战把结构化文档变成RAG可用的数据4.1 切块策略从“一刀切”到“结构感知切块”切块看起来简单实际是RAG效果的天花板之一。最死板的是按固定长度切比如512字符一段再叠加128字符重叠。面对规整的纯文本这种方式能跑但遇到带结构的文档就很吃亏经常把完整的一句话、一个列表项、一个表格行拦腰截断。我推荐的做法是结构感知切块基于第二层识别出来的标题层级先划分章节区间在每个章节内部以段落或表格为最小语义单元再根据embedding模型的最大token限制决定是把多个相邻段落拼成一个块还是把一个超长段落拆成几个子块。切的时候有一个原则宁可切大一点也不要让块的头部出现“标题断层”。什么是标题断层就是检索出来的片段没有章节信息模型不知道它属于哪一段内容。4.2 元数据是RAG检索的“隐形助攻”每个块入库之前除了文本本身一定要带上元数据。一套比较完整的最小元数据集合长这样doc_id文档唯一IDpage_num页码用于溯源chapter_path章节路径例如“2.3 环境配置”chunk_type块类型如“paragraph”“table”“title”token_size块的大致token数量方便后续过滤。有了这些字段你可以在检索时做过滤。比如用户问到“第二章提到的接口地址”你可以直接限定chapter_path LIKE 2.%再向量检索精度会提升一大截。后面做答案溯源时也能直接定位到源文件第几页这个体验对B端用户尤其重要。4.3 向量化与入库用pgvector跑通闭环向量数据库选择很多拿pgvector举例是因为它不需要引入额外基础设施在已有的PostgreSQL里加一个插件就能用。embedding模型方面中文场景我用的是BAAI/bge-large-zh-v1.5这类中文向量模型效果比通用英文模型好很多。编码时打开normalize_embeddingsTrue后续计算余弦距离可以直接用点积。建表和插入的简化流程如下CREATE EXTENSION IF NOT EXISTS vector; CREATE TABLE doc_chunks ( id BIGSERIAL PRIMARY KEY, content TEXT NOT NULL, meta JSONB, embedding vector(1024) );from sentence_transformers import SentenceTransformer import psycopg2, json model SentenceTransformer(BAAI/bge-large-zh-v1.5) chunks [...] # [(content, meta), ...] texts [c[0] for c in chunks] embeddings model.encode(texts, normalize_embeddingsTrue) conn psycopg2.connect(hostlocalhost dbnameragdb userpostgres passwordyour_password) cur conn.cursor() for (content, meta), emb in zip(chunks, embeddings): cur.execute( INSERT INTO doc_chunks (content, meta, embedding) VALUES (%s, %s, %s), (content, json.dumps(meta, ensure_asciiFalse), emb.tolist()) ) conn.commit()查询时用向量距离排序SELECT content, meta, 1 - (embedding %s::vector) AS similarity FROM doc_chunks WHERE (meta-doc_id) xxx ORDER BY embedding %s::vector LIMIT 5;就是余弦距离返回的是距离值越小越相似。用1 - distance换算成相似度更直观。注意生产环境记得给embedding列建IVFFlat或HNSW索引不然数据量一上来查询速度会明显拖后腿。4.4 检索不是终点有必要加一层Rerank很多刚入门的朋友以为向量检索排完就结束了实际生产环境中这个效果往往不够。我建议在向量召回Top 20之后再加一层重排序也就是Rerank。用跨编码器模型对“用户问题 召回文本”做精确打分再取Top 5喂给大模型。这一步对中文文档问答的提升非常明显尤其是术语多、问句长的场景能把原来排在后面的关键段落捞上来。预算有限的场景也可以用“关键词召回 向量召回”融合关键词负责精准匹配专有名词向量负责语义相似两边各取TopN去重后再合并。这个思路实现简单收益稳定。5. 常见问题与排查技巧实录5.1 问题速查表现象可能原因解决方法检索命中结果总是偏题切块太碎、语义被切断改用结构感知切块按章节包装表格数据问不出来表格没转Markdown或当成图片处理L2层做表格识别转成Markdown双栏PDF文本错乱坐标顺序没处理按坐标排序或做双栏拆分扫描件抽不到文字PDF本身没有文本层接入OCR后再走解析流程同一问题换一种问法就找不到向量召回能力有限加Rerank或关键词向量融合召回大文档检索速度很慢切块数量过多、没有索引按章节先过滤再向量检索建HNSW索引5.2 扫描版PDF怎么低成本接入OCR扫描版PDF是RAG最让人头疼的类型。低成本方案是把每页PDF转成图片然后用PaddleOCR之类的开源引擎识别。识别完的文字一定要保留每个词的坐标这样才能复用第二层的结构解析逻辑。坐标信息在处理扫描版表格时尤其重要纯OCR出来的文字流没有行列概念必须靠坐标聚类还原表格边框和行列关系。这里有个经验扫描版PDF别急着上先用page.get_text()试抽几页如果返回空字符串再走OCR能省不少时间。5.3 检索结果有上下文缺失怎么排查如果用户问一个问题你把它喂给大模型模型回答依赖某个上下文而这个上下文并没有包含在召回的Top N里模型就只能开始“编”。解决办法有两个方向一个是在切块阶段做“父子切块”小的子块负责精确检索命中后把包含它的父级块整体喂给模型另一个是扩充上文窗口把段落的前几句、章节标题一起拼进去让大模型能看到完整来龙去脉。我实测下来父子切块对长文档的效果提升最明显。不过代价是存储和检索的块数量会变多要提前规划好向量库的容量。6. 完整样例从PDF到RAG问答一次跑通6.1 样例目标假设我们有一份《设备运维手册》PDF大概80页包含文字章节、操作步骤列表、参数表格和几张架构图。我们要做一个内部问答系统能回答“设备启动失败应该检查什么”“某型号的额定功率是多少”这类实际问题。6.2 全流程走一遍整体流程是解析PDF为文本 → 识别标题和表格结构 → 生成结构化chunk → 向量化入库 → 查询时召回 Rerank → 交给LLM生成回答。doc parse_pdf(设备运维手册.pdf) pages extract_text_with_coordinates(doc) # L1 文本层 struct analyze_structure(pages) # L2 结构层标题、段落、表格 chunks build_chunks_from_struct(struct) # L3 应用层结构感知切块 元数据 embeddings encode(chunks) # 向量化 insert_to_pgvector(chunks, embeddings) # 入库 # 查询时 question 设备启动失败应该检查什么 candidates vector_search(question, top_k20) # 向量召回 ranked rerank(question, candidates, top_k5) # 精排 answer llm.generate(question, ranked) # 生成这只是一个核心流程骨架生产环境还要考虑增量更新、文档权限过滤、日志追踪等。但核心思想是一样的先把文档处理成“有结构的半成品”再去做检索不要指望直接拿原始PDF交给模型去读。6.3 效果对比同一份PDF两种方案的差距我在一个内部项目上做过对比同一份PDF、同一个问题集用“直接全文转字符串 固定长度切块”和“三层解析 结构感知切块”跑出来的效果差距很大。最典型的一组数据是方案召回Top5命中率问答可接受率固定长度切块不足50%40%左右结构感知切块80%左右75%左右结构感知 Rerank90%左右85%以上具体数值跟文档类型、问题难度都有关系但趋势是一致的解析做得好RAG整体效果才有保证。尤其是表格类和多级标题类问题三层解析的优势非常明显。6.4 这套思路的扩展方向如果你已经跑通了这套三层管道后面可以做很多扩展。比如在L2层接入版面分析模型自动识别扫描版PDF中的表格、图片、标题区域在L3层接入GraphRAG把实体关系和文档结构存入图数据库做结构化知识问答还可以把PDF解析做成异步任务接入消息队列让文档上传、解析、索引全流程自动化。这些方向都在我后续的实战计划里感兴趣的朋友可以先从这一篇的三层基础开始搭。最后说一句我个人最大的体会做RAG很多人把精力全花在选模型、调prompt、换框架上效果不好就再换一个框架换来换去问题还在。其实数据入口的质量决定了整个系统的上限。PDF解析这件事看起来只是整个链路前面那块垫脚石实际上是把“文档理解能力”前置到数据链路里最值得投入的一环。先把这三层跑通再去调那些花哨的组件你会发现很多以前查不出来的问题根本不需要换模型就能解决。