折腾了两周RAG，我差点以为是LLM太蠢……

折腾了两周RAG，我差点以为是LLM太蠢……直到我看了文档解析的结果——好家伙，PDF中的表格被拆成了三块碎片

事情是这样的。上周，leader丢给我一个任务：用公司内部的技术文档和产品手册，搭一个RAG问答系统。

“很简单嘛，”我想，“LangChain + 向量库 + 开源PDF解析，两天搞定。”

结果两周过去了，系统倒是能跑，问“表3-2里华东区Q2的故障率是多少”，它回答“抱歉，未找到相关信息”。

我一度怀疑是Embedding模型不行，换了好几个；后来，又怀疑是分块策略不对，调了半天chunk_size。最后实在没招，我把解析出来的中间结果打印出来看了一眼——

好家伙。

一个跨了三页的表格，被开源PDF解析库拆成了三个独立的文本块。表头只出现在第一块，后面两块只有光秃秃的数字，连哪列是哪列都看不出来。

这TM不是LLM蠢，是我喂给它的数据垃圾。

一、程序员眼中的文档解析，远比你想象的复杂

我以前认为“文档解析”就是把PDF中的文字抠出来。但当我开始处理真实业务文档时，才发现事情没那么简单。

Case 1：跨页表格

我们产品手册里有一个“API错误码对照表”，横跨了4页。传统OCR/PDF解析库（比如PyPDF2、pdfplumber）按页处理，把一张完整的表格硬生生拆成了4段。

你问“错误码10086是什么意思”，RAG检索到的可能只是第三页那段数字，根本没有表头信息，LLM只能瞎猜。

Case 2：多栏排版

很多技术白皮书是双栏布局的。解析库如果按“从上到下”的顺序读取，会把左栏第一段读一半，跳到右栏第一段，再跳回来……阅读顺序全乱。最终喂给LLM的文本，语义逻辑完全断裂。

Case 3：表格→纯文本

更离谱的是，有些库会把表格直接转成纯文本：

看着还行？但你问“P002的价格”，LLM需要靠正则去猜哪段文字对应哪列。如果表格里有合并单元格、嵌套表格，纯文本方案直接崩。

真实的生产环境里，文档的“脏”程度远超你的想象。

• 扫描件歪斜、有阴影
• 表格无线框、有合并单元格
• 页眉页脚、水印、手写批注
• 图文混排、公式、图表

开源方案应付一下个人小项目还行，到了生产阶段，坑是一个接一个。

二、调研了一圈，我决定试试商业方案

作为一个程序员，我的第一反应永远是：找开源库，自己撸。

我试过：

• PyPDF2 —— 基础提取，表格支持约等于零
• paddleocr —— 效果不错，但依赖重、速度慢、跨页表格依然会断裂
• marker / surya —— 新兴开源项目，复杂文档处理仍有bug

最后在技术群里看到有人推荐 TextIn xParse，合合信息出的商用文档解析引擎。说实话，一开始我是抗拒的。“商业产品？要钱？我们程序员嘛，能用开源的就绝不用商业的。”

但群友甩了一张对比图：同一个跨页复杂表格，开源库输出的是4段残缺文本，TextIn输出的是一个完整的Markdown表格，行列对齐，合并单元格原样保留。 我立刻去官网（https://cc.co/16YSdb）看了一眼——有免费额度。行，先试试。

三、TextIn xParse 到底做了什么不一样的事？

从技术角度，我总结了一下它的核心能力：

1. 跨页表格智能拼接

这是我遇到的痛点。TextIn能识别“这是一个跨页的表格”，自动把分散在多页的表格片段拼回一张完整表，表头自动对齐，数据行合并。输出格式可以是Markdown或JSON，直接喂给下游。

2. 复杂表格结构还原

无线表、嵌套表、合并单元格——这些在真实业务文档里太常见了。TextIn不是简单地“按行输出”，而是真正理解表格的二维结构。

3. 文档预处理矫正

对于扫描件、手机拍摄的歪斜文档，TextIn会自动做图像矫正（去歪斜、去阴影、去噪），然后再进行OCR识别。这一点对非标准PDF非常友好。

4. 手写体 & 公式识别

有些技术文档上有手写批注（比如评审意见），或者数学公式。TextIn在这些边缘场景的表现明显优于开源方案。

5. 标准化输出，即插即用

TextIn支持输出Markdown、JSON、HTML等格式。我直接选了Markdown——保留标题层级、表格语法、列表结构，零清洗就能接入LangChain或RAGFlow。

四、代码实战：TextIn + LangChain 搭建RAG

下面是我实际集成的代码，非常简单。

from langchain_xparse import XParseLoader
loader = XParseLoader(
    file_path="technical_manual.pdf",
    api_key="your_api_key"
)
docs = loader.load()  # 直接得到结构化Markdown
# 然后正常做RAG问答...

接入向量库后，RAG 准确率从不足 30% 飙升到 95% 以上。

不是LLM变聪明了，是我喂给它的数据变干净了。

五、高阶 RAG 实战技巧（干货）

文档解析只是第一步。要想让 RAG 在生产环境中真正“能打”，下面这几个高阶技巧你一定会用到。

技巧1：元数据过滤 – 让检索“带上条件”

不要把文档内容全部混在一起检索。在解析时保留元数据（来源文件、章节、页码、表格编号），检索时用过滤器缩小范# TextIn 输出自带页码信息，可以提取为 metadata

for doc in docs:
    doc.metadata["source"] = "2026_Q2_report.pdf"
    doc.metadata["table_id"] = "table_3_2"
# 检索时只查某个表格
retriever = vectorstore.as_retriever(
    search_kwargs={"filter": {"table_id": "table_3_2"}}
)

效果：问“华东区Q2故障率”时，系统只去表3-2里找，不会被其他表格干扰。

技巧2：多级路由检索 – 先摘要后详情

对于超长文档（比如几百页的技术手册），直接检索全文效率低。可以设计两层检索：

• 第一层：用文档的章节摘要或标题向量快速定位相关章节
• 第二层：只在该章节内进行细粒度检索

实现方式：使用 ParentDocumentRetriever 或自己维护两个向量库（摘要库 + 块库）。

技巧3：表格数据的结构化检索 – 让 LLM 生成 SQL

表格数据被 TextIn 解析成 Markdown 后，仍然是以文本形式存储的。如果要对表格做聚合查询（如“华东区Q2平均故障率”），可以这样做：

1. 将表格内容以 CSV 或 JSON 格式存入数据库（SQLite / DuckDB）
2. 让 LLM 根据用户问题生成 SQL 语句
3. 执行 SQL 返回精确结果

技巧4：重排序（Rerank） – 提升 Top-K 精准度

向量检索返回的 Top-K 块里，前几个可能并不相关。接入一个 Rerank 模型（如 Cohere Rerank、BGE-reranker）对候选块重新打分，能显著提升答案质量。

六、开源 vs 商业：程序员的真实选择

我知道很多开发者会纠结这个问题。我的看法很实在： 开源方案适合：

• 个人学习/实验项目
• 文档形态非常规整（标准PDF、无复杂表格）
• 你有大量时间折腾和调试

商业方案（如TextIn）适合：

• 生产环境/业务项目
• 文档类型多样、格式复杂（跨页表格、扫描件、手写批注）
• 你不想把时间花在“修数据”上，只想专注业务逻辑

开源不是免费的。你省下的许可证费用，最终会以调试时间、维护成本、解析错误带来的业务损失等形式还回去。

以TextIn为例，它对个人开发者有免费额度，先用起来。如果免费额度不够用，付费价格也不算贵（对比你花两周去调一个开源库的人力成本）。

六、一些给程序员同行的建议

如果你也在折腾RAG知识库，这几条踩坑经验送给你：

• 先dump出解析结果看一眼。 别盲目相信任何解析库。把解析后的文本打印出来，检查表格是否完整、阅读顺序是否正确。
• 优先选输出Markdown的解析工具。 Markdown保留结构信息，比纯文本对LLM友好得多。
• 表格数据一定要保留二维结构。 如果解析输出是纯文本，RAG基本没法精准回答“某行某列”的问题。
• 分块策略要和文档结构对齐。 按标题层级切分，比固定长度chunk效果好很多。TextIn输出的Markdown天然保留了标题层级，配合MarkdownHeaderTextSplitter非常丝滑。
• 生产环境不要自己造轮子。 文档解析这个领域水很深，专业的事情交给专业的工具。你把精力放在业务逻辑上，ROI更高。

写在最后

现在我的RAG系统终于能正常工作了。leader问“表3-2的华东区Q2故障率”，它秒回“3.2%”，还附带引用来源。而这一切的改变，只是因为我换了一个文档解析引擎。 如果你的RAG知识库也在“装傻”，不妨先检查一下：你喂给它的数据，真的被“读对”了吗？

福利：

TextIn为个人开发者准备了免费解析额度。扫描下方二维码，填写表单即可领取：

• 产品官网：https://cc.co/16YSdb（api key 即领即用）
• LangChain插件：https://pypi.org/project/langchain-xparse/
• 产品手册：https://docs.textin.com/xparse/overview