企业官网建设流程全解析

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 搭 RAG，PDF 用 PyPDFLoader，Word 用 Docx2txtLoader，PPT 用 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( backend=PyPdfiumDocumentBackend ) } ) 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_size=800): """按文档结构切分，而不是按固定字数""" 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_workers=4): """批量处理文档""" 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_workers=max_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 页左右的普通 PDF，CPU 上大概需要 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_content=item.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_options=pipeline_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 或者增加并发。二是走了 OCR，OCR 本身就慢。三是表格密集，表格结构识别比较耗时。

优化思路：能不用 OCR 就不用，先检查 PDF 有没有文本层。批量处理时合理设置并发度，CPU 环境 4 到 8 个 worker，GPU 环境 2 到 4 个。对于特别大的文档，可以考虑先拆分再并行处理。

还有一个容易被忽略的点是模型加载。Docling 每次初始化转换器都会加载模型，如果你在处理循环里反复创建转换器，会浪费大量时间在模型加载上。正确的做法是创建一个转换器实例，复用它处理所有文档。

5.4 常见问题速查表

5.5 几个我踩过的坑

第一个坑是忽略页眉页脚。刚开始做的时候没注意，解析出来的文本里混入了大量页眉页脚，比如文档标题、页码、公司名。这些内容会污染检索结果，用户搜一个关键词，结果匹配到的全是页眉里的公司名。后来我在切分前加了一步过滤，把重复出现的短文本块识别为页眉页脚剔除掉，效果好了很多。

第二个坑是表格和正文混切。一开始我图省事，把解析出来的所有内容混在一起按字数切。结果表格被切得七零八落，检索出来的表格数据完全没法用。后来改成表格单独处理，转成 Markdown 或自然语言描述后单独建索引，检索质量明显提升。

第三个坑是没保留页码信息。早期版本我没在 metadata 里存页码，后来想做引用溯源的时候发现根本不知道答案来自哪一页。返工重新解析了一遍，浪费了不少时间。所以一开始就要把页码、章节这些元信息存好。

第四个坑是对 OCR 期望过高。有些扫描件质量很差，OCR 出来错误率很高。我一开始想着靠 OCR 全自动处理，后来发现对于关键文档，还是得人工校对。现在的做法是 OCR 先跑一遍，然后对关键字段做人工校验，兼顾效率和质量。

6. 从解析到检索：把结构化优势用起来

6.1 基于结构的切分策略

Docling 解析出来的结构化文档，最大的价值在于让你能做基于结构的切分，而不是无脑按字数切。这两种切分方式对检索质量的影响非常大。

按字数切的问题是语义不完整。一个完整的论述可能被从中间切断，前半段在一个块里，后半段在另一个块里。用户搜到前半段，得到的答案是不完整的。而按结构切，每个块是一个完整的语义单元——一个章节、一个段落、一个表格——检索出来的内容更聚焦，答案质量更高。

具体实现上，我通常按这样的优先级切分：先按一级标题切，如果某个一级标题下的内容太长，再按二级标题切，以此类推。如果到了最细粒度的标题内容还是太长，才按段落切。表格和图片单独处理，不参与文本切分。

def hierarchical_chunk(document, max_size=1000): """按层级结构切分文档""" 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 descriptions

6.3 元信息在检索中的应用

Docling 保留的元信息——页码、章节、元素类型——在检索阶段能发挥很大作用。

页码信息可以用来做引用溯源。用户问一个问题，你给出答案的同时告诉他"这个信息来自文档 X 的第 Y 页"，用户体验会好很多。

章节信息可以用来做上下文增强。检索到一个块之后，把它的章节标题也带上，让生成模型知道这段内容属于哪个主题，生成的答案会更准确。

元素类型可以用来做过滤。比如用户问的是表格数据，你可以只检索表格类型的块，排除正文块，减少干扰。

def retrieve_with_metadata(query, vector_store, filter_type=None): """带元信息过滤的检索""" filter_dict = {} if filter_type: filter_dict["type"] = filter_type results = vector_store.similarity_search( query, k=5, filter=filter_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 系统的效果会有质的提升。