PDF/PPT/网页 全搞定：RAG 文档解析的 5 个难点与解法

PDF/PPT/网页 全搞定：RAG 文档解析的 5 个难点与解法

搭建 RAG 系统时，文档解析是最容易被低估的环节。多少人精心调好了 Embedding 模型和检索策略，结果输入端就输了——表格错位、公式乱码、图片丢失、段落割裂……垃圾进，垃圾出，再好的检索也救不回来。本文整理了 RAG 文档解析中的 5 大核心难点，每个都附带实战解法，直接可用。

难点一：表格解析——从"一堆数字"到"结构化数据"

问题有多严重？

表格是 RAG 文档解析的头号杀手。看一下常见的翻车场景：

更头疼的是合并单元格。一份财报 PDF 里，「总营收」横跨 3 列，「其中」下面又有子分类，这种层级关系用简单的文本提取根本还原不了。

解法一：结构化表格提取工具链

方案：Camelot + pdfplumber 组合拳

importcamelotimportpdfplumber# 方案 A：Camelot —— 适合线框清晰的表格tables=camelot.read_pdf('report.pdf',pages='1-5',flavor='lattice')fori,tableinenumerate(tables):df=table.df# 直接拿到 DataFramedf.to_csv(f'table_{i}.csv',index=False)# 方案 B：pdfplumber —— 适合无边框表格（更通用）withpdfplumber.open('report.pdf')aspdf:forpageinpdf.pages:tables=page.extract_tables()fortableintables:# table 是二维列表，每行一个子列表print(table)

选型建议：

解法二：表格 → Markdown/HTML 序列化

解析出来只是第一步，怎么存进向量库才是关键。推荐将表格序列化为 Markdown 格式：

deftable_to_markdown(df):"""将 DataFrame 转为 Markdown 表格，保留完整结构"""header='| '+' | '.join(df.columns.astype(str))+' |'separator='| '+' | '.join(['---']*len(df.columns))+' |'rows=[]for_,rowindf.iterrows():rows.append('| '+' | '.join(row.astype(str))+' |')return'\n'.join([header,separator]+rows)# 输出效果：# | 指标 | 2024 Q1 | 2024 Q2 | 同比增长 |# | --- | --- | --- | --- |# | 总营收 | 100亿 | 120亿 | 20% |

为什么要转 Markdown？

1. Embedding 模型对 Markdown 表格的理解远优于纯文本拼接
2. LLM 生成回答时可以直接引用结构化数据
3. 检索时的语义匹配更准确（“Q2 营收” 可以匹配到对应单元格）

解法三：大模型辅助表格理解

对于特别复杂的表格（嵌套表头、跨页表格），可以用 LLM 做后处理：

TABLE_PARSE_PROMPT=""" 你是一个表格解析专家。下面是从 PDF 中提取的原始表格数据（可能有错位或缺失）， 请还原为正确的 Markdown 表格，并补充缺失的表头。 原始数据： {raw_table_text} 上下文信息（该表格前后的文字）： {context} 请输出完整的 Markdown 表格。 """

难点二：数学公式解析——LaTeX 的识别与还原

为什么公式这么难搞？

论文和技术文档中大量使用数学公式，但公式解析有 3 个核心难题：

1. PDF 中公式是图形不是文本：原生 PDF 提取公式时，得到的是乱码或空白
2. LaTeX 语法复杂：分数、矩阵、多行公式等嵌套结构，OCR 极易出错
3. 行内公式与行间公式混排：解析时需要区分两种公式并分别处理

期望输出: $\frac{\partial L}{\partial w} = \frac{1}{N}\sum_{i=1}^{N}x_i(w^Tx_i - y_i)$ 实际输出: ∂L/∂w = 1/N Σ x_i(w^T x_i - y_i) ← 语义对了，格式废了 更差输出: aL/aw = 1N Ex,(wTx, - y,) ← 完全乱码

解法一：Nougat——Meta 开源的公式 OCR

# 安装pipinstallnougat-ocr# 使用（支持批量处理）nougat--model0.1.0-base pdfs/paper.pdf-ooutput/--markdown# 输出直接是带 LaTeX 的 Markdown

Nougat 的优势在于：

• 专门为学术论文训练，公式识别准确率 > 95%
• 输出直接包含 LaTeX 行内/行间公式
• 保留文档的章节结构和引用关系

解法二：Mathpix——商业方案的天花板

如果预算允许，Mathpix 是目前公式识别效果最好的方案：

importrequests# Mathpix API 调用response=requests.post("https://api.mathpix.com/v3/text",data={"file":open("formula.png","rb").read()},headers={"app_id":"YOUR_APP_ID","app_key":"YOUR_APP_KEY"})# 返回 LaTeX 格式latex=response.json()["text"]# 例如: \\frac{\\partial L}{\\partial w}=\\frac{1}{N}\\sum_{i=1}^{N}

选型对比：

解法三：公式 → 语义描述补充

不管用哪种工具，公式 OCR 都不可能 100% 准确。实战中的最佳实践是为关键公式添加语义描述：

FORMULA_DESC_PROMPT=""" 请用自然语言描述以下数学公式的含义，使其在语义检索时能被匹配到： 公式: {latex_formula} 上下文: {surrounding_text} 输出格式： 1. 一句话概述公式的含义 2. 公式中各变量的含义 3. 该公式在文中的作用 """

这样，即使用户搜索"梯度下降的损失函数求导公式"，也能检索到对应的公式段落。

难点三：多模态文档处理——图文混排的"切割"与"关联"

图文分离是信息杀手

一份典型的技术文档包含：

• 正文段落
• 代码块
• 图片/图表
• 图片说明（Caption）
• 脚注

传统解析按页或固定长度切片，会导致：

❌ 错误切片示例： Chunk 1: "...如图所示，模型的注意力分布呈现明显的" Chunk 2: "[图片：注意力热力图]" Chunk 3: "集中在主语位置，这解释了为什么..." 问题：三个 Chunk 语义割裂，检索时可能只命中其中一个

解法一：按语义单元切片

fromunstructured.partition.autoimportpartitionfromunstructured.staging.baseimportconvert_to_dict# Unstructured 自动识别文档元素类型elements=partition(filename="tech_doc.pdf")forelementinelements:print(f"类型:{element.category}, 内容:{element.text[:50]}...")# 输出示例：# 类型: Title, 内容: 3.2 注意力机制分析...# 类型: NarrativeText, 内容: 如图所示，模型的注意力分布...# 类型: Image, 内容: [图片内容或描述]...# 类型: FigureCaption, 内容: 图 3-2：注意力热力图...

核心原则：每个 Chunk 必须是一个完整的语义单元，不能把图片和它的说明文字拆开。

解法二：图片描述生成（Image Captioning）

图片本身无法被 Embedding 检索（除非用多模态 Embedding），所以需要生成文字描述：

fromPILimportImageimportbase64importjsondefdescribe_image(image_path,llm_client):"""用多模态 LLM 生成图片描述"""withopen(image_path,"rb")asf:img_b64=base64.b64encode(f.read()).decode()response=llm_client.chat.completions.create(model="gpt-4o",messages=[{"role":"user","content":[{"type":"text","text":"请详细描述这张图片的内容，包括数据和趋势。"},{"type":"image_url","image_url":{"url":f"data:image/png;base64,{img_b64}"}}]}])returnresponse.choices[0].message.content# 生成描述后，和图片的 Caption 一起存入向量库chunk_metadata={"type":"image_with_caption","caption":"图 3-2：注意力热力图","description":"该热力图显示了模型在处理'银行'一词时...","page":15,"section":"3.2 注意力机制分析"}

解法三：多模态 Embedding 直接索引

2026 年，多模态 Embedding 已经成熟，可以直接用图片+文本联合索引：

fromFlagEmbeddingimportFlagModel# 使用支持图文的 Embedding 模型model=FlagModel('BAAI/bge-visualized-base',query_instruction_for_retrieval="")# 图片直接编码img_embedding=model.encode_image("chart.png")# 文本编码txt_embedding=model.encode_queries(["注意力机制的热力图分析"])# 统一向量空间检索，图片和文本可以互搜

难点四：网页内容解析——动态渲染与噪音过滤

网页解析的 3 个坑

坑 1：动态渲染内容

<!-- 源码只有这个 --><divid="content"></div><!-- 实际页面渲染出完整文章 --><!-- 需要执行 JavaScript 才能拿到内容 -->

坑 2：噪音太多

一个网页的 DOM 里，真正有用的内容可能只占 20%，剩下 80% 是导航栏、广告、推荐链接、评论区……

坑 3：分页与懒加载

长文章分 3 页展示，或者「点击加载更多」，简单爬取只能拿到第一页。

解法一：Trafilatura——干净的网页正文提取

importtrafilatura# 一行代码提取正文downloaded=trafilatura.fetch_url('https://example.com/article')text=trafilatura.extract(downloaded,include_comments=False,# 不要评论include_tables=True,# 保留表格favor_precision=True# 宁可少提取，也要准确)# 输出：干净的纯文本正文，自动去除了导航栏、广告、侧边栏

Trafilatura 的核心优势：

• 基于算法判断「正文区域」，不依赖 CSS 选择器（换个网站不用改代码）
• 支持元数据提取（作者、日期、标题）
• 3000+ 网站实测，正文提取准确率 > 97%

解法二：Playwright 处理动态渲染

fromplaywright.sync_apiimportsync_playwrightdefrender_and_extract(url):"""用浏览器渲染页面后提取内容"""withsync_playwright()asp:browser=p.chromium.launch(headless=True)page=browser.new_page()page.goto(url,wait_until='networkidle')# 等待动态内容加载page.wait_for_selector('.article-content')# 提取正文区域content=page.locator('.article-content').inner_text()# 处理懒加载：滚动到底部page.evaluate('window.scrollTo(0, document.body.scrollHeight)')page.wait_for_timeout(1000)# 提取新加载的内容more_content=page.locator('.article-content').inner_text()browser.close()returnmore_content

解法三：Readability 算法 + 自定义清洗

fromreadabilityimportDocumentfrombs4importBeautifulSoupdefclean_webpage(html_content):"""Readability + BeautifulSoup 双重清洗"""# Step 1: Readability 提取正文 DOMdoc=Document(html_content)summary_html=doc.summary()# Step 2: BeautifulSoup 精细清洗soup=BeautifulSoup(summary_html,'html.parser')# 移除无用标签fortaginsoup.find_all(['script','style','nav','footer','aside']):tag.decompose()# 移除广告容器（常见 class 名）fortaginsoup.find_all(class_=lambdac:candany(kwinstr(c).lower()forkwin['ad','promo','sponsor','recommend'])):tag.decompose()returnsoup.get_text(separator='\n',strip=True)

难点五：文档切片策略——Chunk 大小与语义完整性的博弈

切片不当，检索全废

这是 RAG 系统中最关键的隐性问题。同样的文档，不同的切片策略可以导致检索准确率差 3 倍以上。

常见错误：

解法一：递归字符切片 + 标题感知

fromlangchain.text_splitterimportRecursiveCharacterTextSplitter,MarkdownHeaderTextSplitter# Step 1: 先按 Markdown 标题切分（保留层级信息）md_splitter=MarkdownHeaderTextSplitter(headers_to_split_on=[("#","chapter"),("##","section"),("###","subsection"),])md_chunks=md_splitter.split_text(markdown_content)# Step 2: 对过长的章节再递归切分text_splitter=RecursiveCharacterTextSplitter(chunk_size=500,chunk_overlap=50,# 重叠 50 token，避免截断丢失上下文separators=["\n\n","\n","。","！","？","."," ",""])final_chunks=[]forchunkinmd_chunks:iflen(chunk.page_content)>500:sub_chunks=text_splitter.split_text(chunk.page_content)forsubinsub_chunks:# 保留父级标题作为上下文final_chunks.append({"content":sub,"metadata":{**chunk.metadata,"parent_headers":" > ".join(chunk.metadata.values())}})else:final_chunks.append({"content":chunk.page_content,"metadata":chunk.metadata})

解法二：语义切片——让模型决定切哪

fromsemantic_text_splitterimportTextSplitter# 基于语义相似度自动切片splitter=TextSplitter(max_chunk_size=500)chunks=splitter.split_text(long_text)# 原理：计算相邻句子的 Embedding 相似度，# 相似度骤降的位置 = 话题切换点 = 最佳切割位置

解法三：父子 Chunk 双索引

这是 2026 年 RAG 最佳实践中最推荐的高级策略：

# 构建 Parent-Child 双层索引# Parent Chunk: 1000 token（提供完整上下文）# Child Chunk: 200 token（精确检索）parent_chunks=text_splitter.create_documents(docs,chunk_size=1000,chunk_overlap=100)child_chunks=[]forparent_id,parentinenumerate(parent_chunks):children=text_splitter.create_documents([parent.page_content],chunk_size=200,chunk_overlap=20)forchildinchildren:child.metadata["parent_id"]=parent_id child_chunks.append(child)# 检索流程：# 1. 用 Child Chunk 做精确检索（命中率高）# 2. 通过 parent_id 找到 Parent Chunk（上下文完整）# 3. 把 Parent Chunk 喂给 LLM 生成回答

效果对比（在 3 个真实数据集上的测试）：

完整文档解析 Pipeline

把上面 5 个难点的解法组合起来，一个生产级的 RAG 文档解析 Pipeline 长这样：

┌─────────────┐ ┌──────────────┐ ┌──────────────┐ │ PDF 文档 │────▶│ 文件类型识别 │────▶│ 解析引擎选择 │ │ PPT 文档 │ │ (MIME 检测) │ │ │ │ 网页 URL │ └──────────────┘ └──────┬───────┘ └─────────────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │ PDF 解析引擎 │ │ PPT 解析引擎 │ │ 网页解析引擎 │ │ pdfplumber │ │ python-pptx │ │ trafilatura │ │ Camelot │ │ │ │ Playwright │ │ Nougat │ │ │ │ │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ └────────────────┼────────────────┘ │ ┌───────▼───────┐ │ 元素分类器 │ │ 标题/段落/表格 │ │ 图片/公式/代码 │ └───────┬───────┘ │ ┌────────────────┼────────────────┐ │ │ │ ┌──────▼──────┐ ┌──────▼──────┐ ┌──────▼──────┐ │ 表格→Markdown│ │ 图片→Caption │ │ 公式→LaTeX │ │ + LLM 校验 │ │ + 语义描述 │ │ + 文字说明 │ └──────┬──────┘ └──────┬──────┘ └──────┬──────┘ │ │ │ └────────────────┼────────────────┘ │ ┌───────▼───────┐ │ 语义切片引擎 │ │ 标题感知 + │ │ 父子双索引 │ └───────┬───────┘ │ ┌───────▼───────┐ │ 向量数据库 │ │ Milvus / │ │ Qdrant │ └───────────────┘

开源工具速查表

踩坑总结

写在最后

RAG 系统的效果，70% 取决于输入数据的质量。文档解析不是"调个 API 就完事"的前置步骤，而是整个 RAG 链路中最需要打磨的环节。

核心原则就一条：让每个 Chunk 都是一个完整的、可被独立理解的语义单元。

如果你正在搭建 RAG 系统，建议按照这个顺序优化：

1. 先把文档解析做对（表格、公式、图片一个都不能丢）
2. 再把切片策略调好（标题感知 + 父子双索引）
3. 最后才去调 Embedding 模型和检索参数

顺序反了，就是在沙子上盖楼。

本文是「30 天 AI & 大模型技术文章」系列第 11 篇，后续将带来 Reranker 模型实战、混合检索等主题，欢迎关注。