1. 为什么 RAG 的瓶颈从来不在模型而在文档解析做过 RAG 项目的人大概都有过这种体验向量库选型纠结了一周Embedding 模型换了三四个重排模型也调了又调结果上线之后用户问一句合同里第三页那个违约金比例是多少系统给出的答案驴唇不对马嘴。回头一查问题根本不在检索和生成环节而是最上游的文档解析就已经把内容搞烂了——PDF 里的表格被拆成了散落的文字碎片跨页的段落被硬生生截断页眉页脚混进了正文扫描件干脆整页丢失。这就是 RAG 管线里最痛的一环文档解析。它不像模型选型那样有话题度也不像 Prompt 工程那样能快速看到效果但它决定了整个知识库的地基质量。地基歪了上面盖什么都是危房。IBM 开源的Docling就是冲着这个痛点来的。它的定位很明确把 PDF、DOCX、PPTX、XLSX、HTML、图片等一堆格式的文档统一转换成结构化的、保留版面信息的、对 RAG 友好的中间表示。说人话就是——不管你丢进去什么格式的文件它都能吐出一份带页码、带章节层级、带表格结构、带阅读顺序的干净文本让下游的切分和检索少踩很多坑。这篇文章适合谁看如果你正在搭 RAG 知识库被 PDF 解析折磨过如果你手头有一堆合同、招标文件、实施方案需要结构化处理如果你用 LangChain 或 LlamaIndex 但发现默认的文档加载器不够用——那这篇内容应该能帮你省下不少试错时间。我会从整体设计思路讲起拆解 Docling 的核心机制然后给出可直接复现的实操流程最后把我踩过的坑和排查经验整理出来。2. Docling 的整体设计与核心思路拆解2.1 传统文档解析方案为什么不够用在 Docling 出现之前处理 PDF 的主流方案大概分三类每一类都有自己的硬伤。第一类是纯文本提取工具比如 PyPDF2、pdfminer 这类。它们的工作原理是按 PDF 内部的文本对象顺序把字符抠出来速度快、依赖少但完全不理解版面。一个双栏排版的学术论文它会把左栏和右栏的文字交错着输出一个带表格的财务报表它会把表格里的数字按坐标顺序打散成一行行莫名其妙的文本。对于结构简单的纯文字 PDF 还能凑合一旦遇到复杂版面就彻底歇菜。第二类是基于规则或模板的解析器针对特定格式做定制。比如你知道这批合同都是某个系统生成的版式固定那就写死规则去抽取。这种方式在单一场景下效果很好但换个文档来源就得重写规则扩展性极差。而且现实中的知识库往往来源五花八门根本不可能为每种版式都写一套规则。第三类是商业 OCR 和文档理解 API效果通常不错但按页收费大批量处理成本高而且数据要传到第三方很多企业场景下不可接受。更关键的是这三类方案大多只输出文本不输出结构。而 RAG 恰恰需要结构——你需要知道哪段文字属于哪个章节哪个表格的哪一行对应哪个表头哪句话是正文哪句话是页脚。没有这些信息切分策略就只能无脑按字数切检索质量自然上不去。2.2 Docling 的分层处理架构Docling 的设计思路是把文档解析拆成几个清晰的层次每层各司其职最终拼装出一份统一的文档对象。最底层是格式适配层。不同格式的文档走不同的后端解析器PDF 走 PDF 后端Office 文档走对应的解析库图片走 OCR 流程。这一层负责把各种格式统一降维成页面级的原始元素包括文字块、图片区域、表格区域及其坐标信息。中间是版面分析层。这是 Docling 的核心竞争力所在。它用视觉模型对每一页做版面识别判断哪些区域是正文、哪些是标题、哪些是表格、哪些是图片、哪些是页眉页脚。同时它会推断阅读顺序——对于多栏排版它能判断应该先读左栏再读右栏而不是按坐标从上到下乱读。表格区域还会进一步做结构识别把表格还原成行列结构而不是一堆散落的单元格文字。最上层是文档组装层。它把各页的解析结果按逻辑顺序拼成一份完整的文档树保留章节层级、页码映射、元素类型标记。最终输出的是一份结构化的文档对象可以导出成 Markdown、JSON 或者直接喂给下游的切分器。这种分层设计的好处是每一层都可以独立替换或升级。比如你觉得默认的 OCR 引擎不够好可以换成别的你觉得表格识别需要加强可以单独调这一层的模型。这种模块化对于实际项目来说非常重要因为不同场景对各个环节的要求差异很大。2.3 为什么选择统一中间表示这条路Docling 最聪明的地方在于它定义了一套统一的文档中间表示。所有格式的文档不管原来是 PDF 还是 Word 还是 PPT解析完之后都变成同一种结构。这意味着下游的切分逻辑、检索逻辑、展示逻辑只需要写一套不用为每种格式单独适配。这个思路其实借鉴了编译器领域的设计——前端负责把各种源语言转成统一的中间代码后端只针对中间代码做优化和生成。放到文档解析场景就是多种输入格式一种输出结构。对比一下就知道这个设计有多实用。假设你用 LangChain 搭 RAGPDF 用 PyPDFLoaderWord 用 Docx2txtLoaderPPT 用 UnstructuredPowerPointLoader每种 loader 输出的 Document 对象结构都不一样metadata 字段也各不相同。你的切分逻辑就得写一堆 if-else 来判断来源格式。而用 Docling 统一解析之后所有文档都是同一种结构切分和检索逻辑可以完全复用。提示统一中间表示的价值在处理混合格式知识库时尤其明显。当你的知识库同时包含 PDF 报告、Word 方案、PPT 汇报和 Excel 数据表时统一表示能让你的下游管线保持简洁。3. 核心细节解析与实操要点3.1 安装与环境准备Docling 是 Python 包安装本身不复杂但有几个依赖细节需要注意。pip install docling这是最基础的安装。但实际使用中你大概率需要额外的能力比如 OCR 支持、表格结构识别增强等。Docling 把这些做成了可选依赖按需安装。# 需要 OCR 能力时 pip install docling[ocr] # 需要全部可选能力时 pip install docling[all]环境方面Docling 对 Python 版本的要求是 3.9 以上推荐 3.10 或 3.11。我实测下来 3.11 的兼容性最好3.12 在某些依赖上偶尔会有编译问题。关于硬件纯 CPU 也能跑但如果你要处理大量扫描件或者复杂版面的 PDF建议有 GPU 加速。Docling 的版面分析模型和表格识别模型都是视觉模型GPU 能带来数倍的提速。不过对于日常几十上百页的文档处理CPU 也完全够用只是慢一些。注意Docling 首次运行时会自动下载模型权重这些模型有几个 GB确保你的网络环境能顺利下载。如果下载中断可以清理缓存目录后重试。3.2 基础解析从文档到结构化输出最简单的用法就几行代码from docling.document_converter import DocumentConverter converter DocumentConverter() result converter.convert(path/to/your/document.pdf) # 导出为 Markdown markdown_output result.document.export_to_markdown() print(markdown_output)这段代码背后发生的事情比看起来多得多。DocumentConverter会自动识别输入格式选择合适的后端解析器然后跑完整的版面分析和结构识别流程。最终得到的result.document是一个结构化的文档对象你可以导出成 Markdown也可以导出成字典格式做进一步处理。导出成字典格式特别有用因为你能拿到每个元素的详细元信息doc_dict result.document.export_to_dict() # 遍历所有文本元素查看它们的类型和位置 for item in doc_dict[texts]: print(f类型: {item[label]}) print(f内容: {item[text][:50]}...) print(f页码: {item.get(prov, [{}])[0].get(page_no, N/A)}) print(---)这里的label字段会告诉你这个元素是正文、标题、页脚还是其他类型。prov字段包含来源信息能追溯到具体页码和坐标。这些元信息对于后续的切分策略至关重要——你可以选择只保留正文过滤掉页眉页脚也可以按标题层级做语义切分而不是无脑按字数切。3.3 表格处理RAG 场景下的关键能力表格是文档解析里最难啃的骨头也是 RAG 场景下最容易出问题的地方。一份合同里的付款条款表、一份财报里的财务数据表、一份招标文件里的评分标准表这些表格里的信息如果解析错了检索出来的答案就是错的。Docling 的表格处理分两步。第一步是表格检测在版面分析阶段识别出哪些区域是表格。第二步是表格结构识别判断表格有多少行多少列哪些单元格是表头哪些单元格跨行跨列。# 查看解析出的表格 for table in result.document.tables: # 导出为 DataFrame 格式 df table.export_to_dataframe() print(df) print()导出成 DataFrame 之后表格就变成了结构化的数据你可以直接做后续处理。比如把表格转成自然语言描述再嵌入或者把表格的每一行作为一个独立的检索单元。我实测下来Docling 对规整表格的识别准确率相当高对合并单元格、嵌套表头这类复杂表格也能处理但偶尔会有偏差。如果表格结构特别复杂建议解析完之后人工抽查一下关键表格。提示对于表格密集的文档建议在切分时把表格单独处理不要和正文混在一起切。表格转成 Markdown 或自然语言描述后单独建立索引检索效果会好很多。3.4 阅读顺序与多栏排版处理多栏排版是另一个常见坑点。学术论文、报纸、杂志经常用双栏甚至三栏排版如果解析器按坐标从上到下读取会把不同栏的内容交错在一起语义完全乱套。Docling 在版面分析阶段会推断阅读顺序。它会识别出栏的边界然后按先读完第一栏再读第二栏的逻辑组织内容。这个能力对于处理学术论文和技术文档特别重要。# 导出时保持阅读顺序 markdown_output result.document.export_to_markdown( # 默认就会按推断的阅读顺序输出 )如果你发现输出的顺序不对可以在导出字典格式后检查每个元素的坐标和阅读顺序标记看看是不是版面分析出了问题。这种情况在版面特别复杂或者扫描质量差的时候偶尔会出现。3.5 页码与章节层级保留RAG 场景下答案的可追溯性很重要。用户问一个问题你不仅要给出答案最好还能告诉用户这个答案来自哪份文档的哪一页。Docling 在解析时会保留页码信息导出字典格式时每个元素都带有来源页码。章节层级同样重要。Docling 会识别标题层级在导出的文档结构中保留这种层级关系。这意味着你可以按章节做切分——每个章节作为一个独立的检索单元而不是把整份文档切成等长的文本块。按章节切分的好处是语义完整性更好检索出来的内容更聚焦。# 按章节遍历文档结构 for item in result.document.iterate_items(): if item.label section_header: print(f章节标题: {item.text}) elif item.label text: print(f正文: {item.text[:80]}...)这种按结构遍历的方式让你可以实现更精细的切分策略。比如标题单独作为一个元素正文按段落切分表格单独处理图片提取出来做多模态索引。4. 实操过程与核心环节实现4.1 搭建一个完整的文档解析管线光会调 API 还不够实际项目中你需要把 Docling 嵌入到一条完整的管线里。下面我给出一个可复现的管线实现从文档输入到结构化输出再到切分和索引。from docling.document_converter import DocumentConverter from docling.datamodel.base_models import InputFormat from docling.document_converter import PdfFormatOption from docling.backend.pypdfium2_backend import PyPdfiumDocumentBackend import json class DocumentPipeline: def __init__(self): # 配置转换器可以针对不同格式做定制 self.converter DocumentConverter( format_options{ InputFormat.PDF: PdfFormatOption( backendPyPdfiumDocumentBackend ) } ) def parse(self, file_path): 解析单个文档返回结构化结果 result self.converter.convert(file_path) return result.document def extract_structured_content(self, document): 提取结构化内容按元素类型分类 content { texts: [], tables: [], pictures: [], metadata: {} } for item in document.iterate_items(): if item.label section_header: content[texts].append({ type: heading, text: item.text, level: getattr(item, level, 1), page: self._get_page(item) }) elif item.label text: content[texts].append({ type: paragraph, text: item.text, page: self._get_page(item) }) elif item.label table: content[tables].append({ data: item.export_to_dataframe().to_dict(), page: self._get_page(item) }) return content def _get_page(self, item): 获取元素的来源页码 if hasattr(item, prov) and item.prov: return item.prov[0].page_no return None def chunk_by_structure(self, content, max_chunk_size800): 按文档结构切分而不是按固定字数 chunks [] current_chunk [] current_size 0 current_heading for item in content[texts]: if item[type] heading: # 遇到新标题先把当前块存起来 if current_chunk: chunks.append({ heading: current_heading, content: \n.join(current_chunk), page: current_chunk_page }) current_heading item[text] current_chunk [] current_size 0 current_chunk_page item[page] else: text item[text] if current_size len(text) max_chunk_size and current_chunk: chunks.append({ heading: current_heading, content: \n.join(current_chunk), page: current_chunk_page }) current_chunk [] current_size 0 current_chunk.append(text) current_size len(text) # 处理最后一块 if current_chunk: chunks.append({ heading: current_heading, content: \n.join(current_chunk), page: current_chunk_page }) return chunks这段代码的核心思路是先解析成结构化文档再按结构切分。注意chunk_by_structure方法它不是按固定字数切而是按标题层级切。每个标题下的内容作为一个语义单元如果内容太长再按段落细分。这样切出来的块语义完整性比无脑按字数切好得多。4.2 批量处理与性能优化实际项目中往往要处理成百上千份文档单份处理太慢。Docling 支持批量转换而且可以控制并发度。from docling.document_converter import DocumentConverter from pathlib import Path from concurrent.futures import ThreadPoolExecutor import time def batch_process(file_paths, max_workers4): 批量处理文档 converter DocumentConverter() results {} def process_one(path): try: start time.time() result converter.convert(path) elapsed time.time() - start return path, result.document, elapsed except Exception as e: return path, None, str(e) with ThreadPoolExecutor(max_workersmax_workers) as executor: futures [executor.submit(process_one, p) for p in file_paths] for future in futures: path, doc, info future.result() results[path] {document: doc, info: info} print(f处理完成: {path}, 耗时/错误: {info}) return results关于并发度我的经验是 CPU 环境下 4 到 8 个 worker 比较合适太多反而会因为内存和 CPU 争抢导致整体变慢。GPU 环境下建议控制在 2 到 4 个因为 GPU 显存有限并发太高会 OOM。性能方面一份 20 页左右的普通 PDFCPU 上大概需要 10 到 30 秒GPU 上能压到 3 到 8 秒。扫描件因为要走 OCR耗时会翻倍甚至更多。表格密集的文档也会慢一些因为表格结构识别比较吃算力。提示批量处理时建议加个断点续传机制。把已处理成功的文档路径记录下来下次跑的时候跳过。我吃过这个亏跑了几百份文档跑到一半崩了重头再来浪费了大量时间。4.3 与 LangChain 和 LlamaIndex 的集成Docling 解析出来的结构化文档可以直接转成 LangChain 的 Document 对象接入现有的 RAG 管线。from langchain_core.documents import Document as LCDocument def docling_to_langchain(docling_doc, source_path): 把 Docling 文档转成 LangChain Document 列表 lc_docs [] for item in docling_doc.iterate_items(): if item.label in [text, section_header]: page_no None if hasattr(item, prov) and item.prov: page_no item.prov[0].page_no lc_doc LCDocument( page_contentitem.text, metadata{ source: source_path, page: page_no, type: item.label } ) lc_docs.append(lc_doc) return lc_docs转成 LangChain Document 之后你就可以用 LangChain 的 TextSplitter 做进一步切分然后送进向量库。metadata 里的页码和类型信息会跟着一起存进去检索的时候可以用来做过滤或者展示引用来源。LlamaIndex 的集成思路类似把 Docling 的输出转成 LlamaIndex 的 Node 对象即可。核心是保留好 metadata特别是页码和章节信息。4.4 处理扫描件和图片型 PDF扫描件是文档解析里最麻烦的情况因为里面根本没有可提取的文本层必须走 OCR。Docling 内置了 OCR 能力但需要安装对应的可选依赖。from docling.document_converter import DocumentConverter, PdfFormatOption from docling.datamodel.pipeline_options import PdfPipelineOptions, EasyOcrOptions # 配置 OCR pipeline_options PdfPipelineOptions() pipeline_options.do_ocr True pipeline_options.ocr_options EasyOcrOptions(lang[ch_sim, en]) converter DocumentConverter( format_options{ pdf: PdfFormatOption(pipeline_optionspipeline_options) } ) result converter.convert(scanned_document.pdf)这里我配置了中英文混合的 OCR。ch_sim是简体中文en是英文。如果你的文档只有中文可以只留ch_sim速度会快一些。OCR 的质量直接影响后续所有环节。我实测下来对于印刷体、扫描质量较好的文档识别准确率能到 95% 以上。但如果是手写体、或者扫描歪斜、有污渍的文档准确率会明显下降。这种情况建议先做图像预处理——纠偏、去噪、二值化——再送进 OCR。注意OCR 很吃算力一份 50 页的扫描件在 CPU 上可能要跑好几分钟。如果扫描件量大强烈建议上 GPU。5. 常见问题与排查技巧实录5.1 解析结果乱序或内容缺失这是最常见的问题表现是输出的文本顺序混乱或者某些内容完全丢失。排查思路如下。先确认是不是版面分析出了问题。把文档导出成字典格式检查每个元素的坐标和阅读顺序标记。如果发现坐标明显异常比如同一栏的文字被标记成了不同栏那就是版面分析模型判断错了。这种情况在版面特别复杂或者扫描质量差的时候会出现。再确认是不是 PDF 本身的问题。有些 PDF 是图片型 PDF没有文本层必须走 OCR。你可以用pdfminer或者PyPDF2快速检查一下能不能提取出文本如果提取出来是空的那就是图片型 PDF。还有一种情况是 PDF 有文本层但编码有问题提取出来是乱码。这种比较少见但遇到了很头疼。可以尝试换一个 PDF 后端解析器Docling 支持多种后端换一个可能就好了。5.2 表格识别错误表格识别错误的表现是行列错位、表头识别错误、合并单元格处理不当。排查和解决思路如下。先看原始表格的复杂度。如果表格有大量合并单元格、嵌套表头、或者没有明显的表格线识别难度会大幅上升。这种情况可以考虑在解析后做人工校正或者用专门的表格识别工具做二次处理。再看 PDF 的质量。有些 PDF 的表格是用线条画的有些是用背景色区分的有些干脆就是文字排版模拟的表格。后两种识别难度更大。如果表格是用文字排版模拟的Docling 可能识别不出这是表格会当成普通文本处理。一个实用的技巧是对于关键表格解析完之后导出成 DataFrame人工抽查几行。如果发现错误可以针对性地调整解析参数或者对这份文档单独处理。5.3 处理速度太慢速度慢通常有几个原因。一是文档页数多这个没办法只能上 GPU 或者增加并发。二是走了 OCROCR 本身就慢。三是表格密集表格结构识别比较耗时。优化思路能不用 OCR 就不用先检查 PDF 有没有文本层。批量处理时合理设置并发度CPU 环境 4 到 8 个 workerGPU 环境 2 到 4 个。对于特别大的文档可以考虑先拆分再并行处理。还有一个容易被忽略的点是模型加载。Docling 每次初始化转换器都会加载模型如果你在处理循环里反复创建转换器会浪费大量时间在模型加载上。正确的做法是创建一个转换器实例复用它处理所有文档。5.4 常见问题速查表问题现象可能原因排查方法解决方案输出文本乱序版面分析错误检查元素坐标和阅读顺序换 PDF 后端或预处理图像内容缺失图片型 PDF 未走 OCR用 PyPDF2 检查文本层开启 OCR 选项表格行列错位表格结构复杂导出 DataFrame 抽查人工校正或二次处理处理速度慢OCR 或表格密集查看耗时分布上 GPU优化并发度中文乱码PDF 编码问题检查提取的原始文本换后端解析器内存溢出并发度过高监控内存使用降低 worker 数量5.5 几个我踩过的坑第一个坑是忽略页眉页脚。刚开始做的时候没注意解析出来的文本里混入了大量页眉页脚比如文档标题、页码、公司名。这些内容会污染检索结果用户搜一个关键词结果匹配到的全是页眉里的公司名。后来我在切分前加了一步过滤把重复出现的短文本块识别为页眉页脚剔除掉效果好了很多。第二个坑是表格和正文混切。一开始我图省事把解析出来的所有内容混在一起按字数切。结果表格被切得七零八落检索出来的表格数据完全没法用。后来改成表格单独处理转成 Markdown 或自然语言描述后单独建索引检索质量明显提升。第三个坑是没保留页码信息。早期版本我没在 metadata 里存页码后来想做引用溯源的时候发现根本不知道答案来自哪一页。返工重新解析了一遍浪费了不少时间。所以一开始就要把页码、章节这些元信息存好。第四个坑是对 OCR 期望过高。有些扫描件质量很差OCR 出来错误率很高。我一开始想着靠 OCR 全自动处理后来发现对于关键文档还是得人工校对。现在的做法是 OCR 先跑一遍然后对关键字段做人工校验兼顾效率和质量。6. 从解析到检索把结构化优势用起来6.1 基于结构的切分策略Docling 解析出来的结构化文档最大的价值在于让你能做基于结构的切分而不是无脑按字数切。这两种切分方式对检索质量的影响非常大。按字数切的问题是语义不完整。一个完整的论述可能被从中间切断前半段在一个块里后半段在另一个块里。用户搜到前半段得到的答案是不完整的。而按结构切每个块是一个完整的语义单元——一个章节、一个段落、一个表格——检索出来的内容更聚焦答案质量更高。具体实现上我通常按这样的优先级切分先按一级标题切如果某个一级标题下的内容太长再按二级标题切以此类推。如果到了最细粒度的标题内容还是太长才按段落切。表格和图片单独处理不参与文本切分。def hierarchical_chunk(document, max_size1000): 按层级结构切分文档 chunks [] current_heading_path [] current_content [] current_size 0 for item in document.iterate_items(): if item.label section_header: # 保存当前块 if current_content: chunks.append({ headings: .join(current_heading_path), content: \n.join(current_content), size: current_size }) # 更新标题路径 level getattr(item, level, 1) current_heading_path current_heading_path[:level-1] current_heading_path.append(item.text) current_content [] current_size 0 elif item.label text: if current_size len(item.text) max_size and current_content: chunks.append({ headings: .join(current_heading_path), content: \n.join(current_content), size: current_size }) current_content [] current_size 0 current_content.append(item.text) current_size len(item.text) if current_content: chunks.append({ headings: .join(current_heading_path), content: \n.join(current_content), size: current_size }) return chunks这样切出来的每个块都带有完整的标题路径检索的时候可以把标题路径也作为上下文一起嵌入提升检索准确率。6.2 表格的单独索引策略表格不适合和正文混在一起做文本嵌入因为表格的语义结构和自然语言差异很大。我的做法是把表格单独处理有两种策略。第一种是表格转自然语言描述。把表格的每一行转成一句自然语言比如产品 A 的价格是 100 元库存是 50 件。这样表格内容就变成了自然语言可以和正文一起做文本嵌入。这种策略适合表格结构简单、行数不多的情况。第二种是表格单独建索引。把表格转成 Markdown 格式单独存一个索引。检索的时候先判断用户的问题是不是表格相关如果是就查表格索引不是就查正文索引。这种策略适合表格密集、表格结构复杂的场景。def table_to_natural_language(df): 把表格转成自然语言描述 descriptions [] headers df.columns.tolist() for _, row in df.iterrows(): parts [] for header, value in zip(headers, row): parts.append(f{header}是{value}) descriptions.append(.join(parts)) return descriptions6.3 元信息在检索中的应用Docling 保留的元信息——页码、章节、元素类型——在检索阶段能发挥很大作用。页码信息可以用来做引用溯源。用户问一个问题你给出答案的同时告诉他这个信息来自文档 X 的第 Y 页用户体验会好很多。章节信息可以用来做上下文增强。检索到一个块之后把它的章节标题也带上让生成模型知道这段内容属于哪个主题生成的答案会更准确。元素类型可以用来做过滤。比如用户问的是表格数据你可以只检索表格类型的块排除正文块减少干扰。def retrieve_with_metadata(query, vector_store, filter_typeNone): 带元信息过滤的检索 filter_dict {} if filter_type: filter_dict[type] filter_type results vector_store.similarity_search( query, k5, filterfilter_dict if filter_dict else None ) # 组装带元信息的上下文 context_parts [] for doc in results: source doc.metadata.get(source, 未知) page doc.metadata.get(page, 未知) context_parts.append( f[来源: {source}, 第{page}页]\n{doc.page_content} ) return \n\n.join(context_parts)这种带元信息的检索生成的答案不仅准确还能给出引用来源可信度更高。7. 一些实际项目中的经验体会Docling 这个工具我用了有一段时间了从最初的尝鲜到后来在正式项目里落地中间踩了不少坑也积累了一些体会。最核心的一点是文档解析的质量决定了 RAG 系统的上限。很多人把精力花在模型选型和 Prompt 调优上却忽略了最上游的解析环节。实际上如果解析出来的文本本身就是错的、乱的、缺的后面再怎么优化都是白搭。Docling 的价值就在于它把解析这一环做扎实了让下游的优化真正能发挥作用。另一个体会是不要追求全自动。文档解析这件事尤其是涉及复杂版面、扫描件、表格的场景完全自动化很难做到 100% 准确。我的做法是自动化处理 90% 的常规文档剩下 10% 的疑难文档人工介入。这样既保证了效率又保证了质量。还有一点是元信息比文本本身更重要。刚开始做的时候我只关注文本内容后来发现页码、章节、元素类型这些元信息才是让 RAG 系统聪明起来的关键。有了这些信息你才能做精细化的切分、过滤和溯源。所以解析的时候一定要把元信息保留好不要图省事只存文本。最后分享一个小技巧如果你手头的文档格式特别杂建议先做一轮格式归一化。把 DOCX、PPTX 这些先转成 PDF再用 Docling 统一处理。这样能减少格式适配层的兼容性问题整体流程更稳定。当然如果你的文档本身就是 PDF 为主那就直接上 Docling省去转换步骤。这个方向后续还可以继续深挖比如结合多模态模型做图片内容的提取和索引或者针对特定领域法律、医疗、金融做解析规则的定制优化。文档解析这个环节看起来不起眼但做好了整个 RAG 系统的效果会有质的提升。