“把 PDF 丢给模型”之前：向量化、分块、索引这些工程细节别忽略

在很多团队里，“让大模型读 PDF”往往被想象得非常简单：把合同、报告、论文的 PDF 丢给某个“智能助手”，然后一句自然语言就能问出答案。但只要你真的做过几次，就会发现现实远没有宣传视频里那么轻松：模型要么答非所问，要么只会“胡编”，要么一遇到几十页上百页的长文档就彻底迷失方向。真正落地一个“问 PDF 问得准”的系统，最后发现 80% 的工作都花在了“看起来很琐碎”的工程细节上——比如 PDF 解析、文本清洗、分块策略、向量化配置、索引结构以及查询时的重排流程等等。

从业务重要性上看，这些投入是值得的。Smallpdf 2025 年的统计显示，大约 78% 的数字协议是以 PDF 格式完成签署，且约 88% 的病人记录和超过 90% 的政府表单与公文都以 PDF 为载体。(Smallpdf) PDF Association 对 2011–2021 年网络上主流文档格式的长期监测也表明，在相关搜索字符串中，PDF 一直占到 70–90% 左右，远高于 DOCX、XLSX、PPTX 等格式。(PDF Association) FileCenter 汇总的文档管理统计进一步指出，近 85% 的企业依赖 PDF 作为对外共享信息的主要文件格式。(FileCenter) 这意味着，只要你在做知识管理、办公自动化、政企信息化，绕不过去的格式几乎一定是 PDF。

与此同时，传统的基于关键字搜索的文档系统越来越难满足使用者的期望——员工抱怨“想要的信息找不到”、知识沉淀成海量文档却难以真正被用起来。检索增强生成（Retrieval-Augmented Generation, RAG）因此成为当前的一个重要方向，它通过向量检索 + 大模型生成的组合，把“找得到”与“看得懂”这两件事打通。最近关于 RAG 的系统性综述指出，相比单纯依赖 LLM 参数记忆，RAG 能显著降低幻觉率、提升对企业私有知识的利用效率，因此被认为是企业级生成式 AI 落地的主流范式之一。(ResearchGate)

但在 PDF 这样复杂的载体上落地 RAG，挑战远大于在纯文本网页或 FAQ 数据集上。PDF 的版面结构复杂，文本常常被拆碎在不同的坐标块里；一份文档里既有章节标题、正文，又有表格、公式、脚注、跨页图表。如何把这些结构可靠地解析出来，如何在保持语义完整的前提下切分成适合检索的“块”，如何选择合适的嵌入模型并构建高性能的向量索引，这些问题如果处理不好，无论你接在后面的 LLM 多么强大，最终问答体验都很难令人满意。

本文以“把 PDF 丢给模型之前”为视角，从工程实践角度系统梳理构建 PDF RAG 系统时容易被忽略但又至关重要的几个环节：向量化、分块、索引以及相关的评估方法。我们将结合近期关于 RAG、动态分块、向量数据库以及 PDF 问答的学术论文和工程报告，给出一个尽量“可落地”的整体方案和实施细节。

本文的结构安排如下：第二章综述与 PDF RAG 相关的研究工作与工业实践；第三章介绍 PDF 解析、向量化、近似最近邻检索、RAG 等基础概念与原理；第四章给出一个面向 PDF 的端到端 RAG 系统架构；第五章深入讨论分块策略的工程实践，包括静态分块、语义分块与 Mix-of-Granularity 等最新方法；第六章聚焦于嵌入模型与向量化配置；第七章讨论向量数据库与索引策略；第八章则通过若干基于公开实验结果的对比，说明这些工程细节在实际效果上的影响，并在文末给出参考文献列表，方便进一步查阅。

2 相关工作综述

2.1 RAG 框架与应用综述

RAG 的概念最早由 Lewis 等人在 2020 年提出，其核心思想是将预训练语言模型与外部非参数知识库结合，通过检索相关文档片段作为生成条件，以提升知识密集型任务的表现。后续一系列工作在该框架上扩展了检索模型、重排序策略、答案置信度估计等方面。(Chroma Research)

2025 年，Klesel 与 Wittmann 在《Business & Information Systems Engineering》上发表了一篇面向信息系统领域的 RAG 综述文章，对 RAG 的体系结构、相较于微调的优势、典型应用场景及挑战进行了系统梳理。文章强调，RAG 通过把“参数记忆”（模型参数）与“非参数记忆”（向量数据库）解耦，使得组织可以在不重新训练大模型的前提下，持续更新知识库，并以较低成本将内部文档接入。(ResearchGate)

在教育场景方面，一篇 2025 年的系统性综述调研了 RAG 在辅助教学、自动作业反馈、课程问答等场景的应用，指出 RAG 能显著提升系统对课程 PDF、讲义等材料的理解能力，但同时也暴露出检索噪声、答案可信度难以解释等问题，进一步凸显了检索与分块策略的重要性。(ScienceDirect)

2.2 面向 PDF 的问答与结构化 RAG 研究

针对 PDF 这类包含多模态元素且结构复杂的文档，近年的研究开始从“结构化”和“多视图”的角度改造 RAG。NeuSym-RAG 提出在 PDF 问答中引入混合“神经 + 符号”的检索方式：一方面使用向量检索捕获语义相似度，另一方面显式利用基于版面结构、标题层级、表格单元格坐标等构建的图结构进行符号检索，从而更好地对付跨页表格、图注等场景。(ACL Anthology)

另一篇“PDF Retrieval Augmented Question Answering”的研究，从工程实践角度搭建了一个面向企业内部 PDF 的 RAG 系统。作者使用 GTE-large 等多语言嵌入模型为文本片段生成向量，将 PDF 中的图像和表格也纳入到检索流程里，并通过 Llama3-70B 进行答案生成。实验表明，在其构造的涵盖文本、图像、表格问答的测试集上，RAG 相比不检索的基线在答案相似度和任务完成率上都有显著提升。(arXiv)

这些工作都强调了一点：单纯把从 PDF 提取出的“纯文本”扔进向量数据库并不足够，必须结合版面结构和多模态信息构建更加丰富的索引。这为本文后续在分块与索引设计上的讨论提供了重要背景。

2.3 分块与粒度优化研究

检索性能在很大程度上取决于分块策略。传统做法通常是以固定长度（如 512 或 1000 token）进行滑窗切分，并设置一定重叠。但实践中人们逐渐发现，这样的“均匀切分”容易破坏语义单元，导致模型检索到半句话、半个表格。

Chroma Research 在 2024 年发布的一篇评估报告中，系统比较了多种常见分块方法（如基于字符的递归切分、TokenTextSplitter、语义聚类分块 ClusterSemanticChunker 和基于 LLM 的语义分块 LLMSemanticChunker）在不同 chunk 大小和重叠设置下的表现，使用的指标包括召回率、精确率以及与标注相关片段的 IoU。报告发现，对于 all-MiniLM-L6-v2 这类主流嵌入模型，TokenTextSplitter 在 chunk 大小 250、重叠 125 时取得了最高召回（约 0.824），而 ClusterSemanticChunker 在 chunk 大小 200、无重叠设置下在 IoU 指标上表现最好。(Chroma Research)

进一步地，COLING 2025 上的 Mix-of-Granularity（MoG）工作提出，在检索阶段动态选择最合适的粒度，而不是事先固定一种 chunk 大小。作者把同一语料预先以多种粒度切分，再通过一个“路由器”根据查询自动选择在不同粒度层级上检索，实验显示，在多个医疗问答基准上，相比传统 MedRAG 和普通链式推理（CoT），MoG 在较小模型上平均能带来约 5% 和 8.7% 的准确率提升，同时额外存储开销约为原始语料的 2.7 倍。(ACL Anthology)

此外，针对动态分块与索引优化，一篇针对土耳其语数据集的研究提出，在 RAG 管线中使用语义驱动的动态分块、Sentence-Transformers 嵌入（all-mpnet-base-v2）以及 FAISS 的 HNSW 索引，在 RAGAS 框架下能显著提升检索召回和答案正确率，并在速度上优于传统的扁平索引和 IVF-Flat。(ResearchGate)

这些结果从不同侧面印证了一个事实：分块不是简单的“切多少 token”的问题，而是影响检索效果与系统资源利用的核心设计变量。

2.4 嵌入模型与向量数据库综述

在嵌入模型方面，MTEB（Massive Text Embedding Benchmark）提供了针对检索、聚类、分类等任务的系统评估标准，许多最新的开源与闭源嵌入模型都在该榜单上竞争。Chroma 和 BentoML 的文章指出，如 BGE-M3、gte-Qwen 系列、Nomic Embed v2 等模型在多语言检索任务上表现优异，尤其是在长文档与多功能场景中具有较好的性价比。(BentoML)

对于向量数据库，LiquidMetal AI 在 2025 年对 Pinecone、Weaviate、Qdrant、FAISS、Milvus、Chroma 等主流方案进行了对比评测。结果表明，Pinecone 在大规模托管场景中的可扩展性和企业级特性较强；Milvus 更适合自建大规模集群；Qdrant 在元数据过滤和高性能搜索方面表现出色；FAISS 则作为基础库提供了最丰富的 ANN 算法选择但需要额外的工程包装；而 Chroma 则以简洁易用、专为 RAG 设计而受到中小团队欢迎。(LiquidMetal AI)

这些综述与评测为我们在后文选择嵌入模型和向量数据库提供了经验依据。

2.5 代表性工作对比表

表 1 给出了若干与本文主题密切相关的代表性研究与工程报告的对比，方便在后文引用。

表1 代表性 RAG / 分块 / PDF 问答相关工作对比

工作类别	代表论文 / 报告	主要对象	核心贡献	与本文关系
RAG 总体框架综述	Klesel & Wittmann 2025（Business & Information Systems Engineering）(ResearchGate)	通用 RAG	系统梳理 RAG 架构、优势与挑战	为本文整体架构与研究问题提供宏观视角
PDF 问答系统	PDF Retrieval Augmented QA（2025，arXiv）(arXiv)	企业内部 PDF	构建支持文本+图像+表格的 PDF RAG 系统	证明 PDF RAG 的可行性与多模态需求
结构化 PDF RAG	NeuSym-RAG（ACL 2025）(ACL Anthology)	PDF 问答	引入多视图结构与混合检索	启发本文在索引设计中考虑版面结构
分块策略评估	Chroma Research 2024(Chroma Research)	多领域文本	系统评估多种 chunking 策略对召回/IoU 影响	为本文分块策略章节提供实验依据
动态粒度检索	Mix-of-Granularity (COLING 2025)(ACL Anthology)	医疗问答	通过多粒度路由提升 RAG 准确率	为本文的动态分块与粒度选择提供方法论
动态分块 + 向量搜索优化	动态分块与优化向量搜索（OPRD 2024）(ResearchGate)	土耳其语 RAG	在 FAISS 中比较 HNSW / IVF 等索引，结合动态分块	支撑本文在索引选型上的工程建议
向量数据库比较	LiquidMetal AI 2025(LiquidMetal AI)	多种向量库	性能、扩展性、易用性等多维评测	为本文向量数据库选型提供实证参考

3 基础知识与原理

3.1 PDF 内部结构与解析难点

PDF 本质上是一种面向页面呈现的描述性格式，其核心目标是“在任何设备上保持视觉一致”，而非“方便机器理解文本”。在 PDF 中，文本往往以“绘制指令 + 字形坐标”的形式存储，同一行文字可能被拆成多个文本块，甚至被打散在不同的绘制顺序里；多栏排版、页眉页脚、脚注、浮动图表、交叉引用等都会让简单的“按阅读顺序”的抽取变得困难。

更麻烦的是，PDF 并不强制包含结构化标记。部分“标签化 PDF”（tagged PDF）会为段落、标题、列表等提供语义标记，但大量现实世界的 PDF——比如扫描件、由 Office 导出的旧文档——仍然以纯视觉排版为主。对于这类文档，我们通常需要结合以下信息推断结构：

文本块的坐标与字体特征（字号、粗细、对齐方式）；
文本内容本身的模式（例如编号形如“1 引言”“3.2 方法”等）；
版面的几何布局（多栏、表格网格线、图注靠近图片等）。

这也是为什么许多 PDF RAG 系统会采用诸如 pdfplumber、pdfminer.six、GROBID、LayoutParser 等工具，先将 PDF 转为带有布局信息的中间表示（如“页面 → 文本块 → 行 → 词”），再在这一层上做分块与向量化。PDF 问答相关研究也普遍采用“多视图”表示，将文本、版面、表格单元格、图像区域等共同纳入检索。(ACL Anthology)

3.2 向量化与嵌入表示

向量化的目标，是把自然语言文本映射到一个高维连续空间，使得语义相似的文本在该空间中“距离更近”。现代嵌入模型一般基于 Transformer 编码器，通过对比学习等目标进行训练，常见维度在 256 到 4096 之间。MTEB 的研究表明，不同模型在检索、聚类等任务上表现差异显著，因此选择嵌入模型通常要结合任务类型、数据语种和部署约束综合考虑。(Chroma Research)

从 PDF RAG 的角度看，我们主要关心以下几个属性：

语义检索能力：对长文档片段能够捕获核心主题而非浅层关键字；
多语言能力：很多企业文档中混有中文、英文甚至更多语种；
输入长度上限：是否支持上千 token 的输入，以便对较长 chunk 编码；
模式支持：是否支持 dense + sparse / multi-vector 等多种表示，便于后续做混合检索。

以 BGE-M3 为例，BentoML 的分析指出，该模型支持稠密向量、稀疏向量以及多向量表示，能处理多达 8192 token 的输入，并支持上百种语言，适合多语言 RAG 场景。(BentoML) 而像 Jina Embeddings v4 则在多模态检索（文本 + 图像 + PDF 视觉区域）上提供了统一的嵌入空间，适合对 PDF 中的图表和截图内容一起建索引。(BentoML)

3.3 相似度度量与近似最近邻索引

在向量空间中，我们一般使用余弦相似度或内积距离来衡量文本片段与查询之间的相似性。在数据规模较小时，可以直接使用暴力搜索（brute-force），对所有向量逐一计算相似度；但当 PDF 库规模达到数十万乃至上亿个 chunk 时，这种做法变得不可行，于是近似最近邻（Approximate Nearest Neighbor, ANN）索引应运而生。

FAISS、HNSW、IVF-Flat、PQ 等索引结构分别在速度、内存占用与召回率之间提供不同折中。例如，上面提到的针对土耳其语 RAG 的研究，在 FAISS 中实现并对比了 IndexIVFFlat 和 IndexHNSWFlat，实验显示在保持较高语义召回的前提下，HNSW 索引在检索速度上优于 IVF-Flat，尤其适合对精度要求较高的语义检索任务。(ResearchGate)

对于采用 Milvus、Qdrant、Weaviate 等向量数据库的工程实践者来说，这些索引结构通常已经被封装为可配置选项——比如 Milvus 支持 HNSW、IVF-Flat、IVF-PQ 等多种索引，而 Qdrant 内置了 HNSW 并对过滤查询进行了优化。LiquidMetal 的比较文章也指出，选择合适的索引类型往往比“换一个向量数据库”更能立竿见影地改善检索性能。(LiquidMetal AI)

3.4 分块原理与指标

分块的目标，是把长文档切分成若干适合检索的语义单元。过小的 chunk 往往导致语义被切碎，查询需要拼接多个片段才能回答，增加 LLM 提示长度；过大的 chunk 则会降低检索粒度，使得不相关内容被一并带入提示，引发“干扰性上下文”问题，这一点在“LLM 容易被无关上下文分散注意力”的研究中有系统论证。(Chroma Research)

Chroma 的评估引入了 IoU（Intersection over Union）指标，用来衡量检索到的 chunk 与“真实相关区域”在 token 级别的重叠程度。直观理解，如果相关内容在文档中占 100 个 token，而我们检索到的 chunk 中有 80 个 token 来自这个区域，同时 chunk 总长度为 200，那么 IoU 就是 80 / (100 + 200 − 80) ≈ 0.36，这比单纯看召回或精确率更能反映“信息密度”。(Chroma Research)

从 MoG 和动态分块的研究可以看出，不同任务、不同模型对粒度需求差异很大，因此“固定一个最佳 chunk 大小”往往行不通，更好的方式是：

在离线阶段，根据任务设计一套评估基准（如基于 RAGAS 的问题-片段对）；
系统地扫一遍 chunk 大小、重叠、分块算法（语义 / 结构 / 规则）；
观察召回、IoU、延迟等指标，选出符合业务约束的 Pareto 最优解。(Chroma Research)

3.5 RAG 基本流程回顾

综合上述，典型的 RAG 流程可以概括为：

文档收集与清洗：将 PDF 拉入系统，去重、分类、打标签；
解析与分块：解析 PDF 布局，识别标题、段落、表格、图注等，按某种策略切分为 chunk，并附上丰富元数据；
向量化与索引构建：为每个 chunk 生成向量，写入向量数据库并创建 ANN 索引；
查询与检索：把用户问题向量化，在向量库中检索 top-k chunk，并结合元数据过滤与重排序；
生成与后处理：把检索结果与用户问题拼接成提示交给 LLM，生成答案，并可在 UI 中展示来源片段、页码和高亮。

Klesel 与 Wittmann 的综述文章将其解释为“将参数记忆（LLM）与非参数记忆（向量数据库）组合起来的新型信息系统架构”，其优势在于方便更新知识库、抑制幻觉、支持可追溯引用。(ResearchGate)

接下来，我们将在此基础上，给出一个更聚焦于 PDF 场景的系统架构，并深入讨论其中最容易“踩坑”的分块、向量化和索引环节。

4 面向 PDF 的 RAG 系统整体架构

4.1 整体框架结构

在 PDF 场景下，一个可落地的 RAG 系统大致可以拆成几个子系统：文档接入与解析、结构化抽取与分块、向量化与索引、查询路由与重排序、答案生成与反馈收集等。

图1 PDF RAG 系统总体架构示意图

在部署形态上，这一架构既可以作为企业内部知识助手的后端，也可以作为某种“智能 PDF 阅读器”的服务内核。无论界面如何变化，其关键路径基本围绕上述几个模块展开。

4.2 文档导入与解析模块

文档导入模块负责从各种来源收集 PDF，包括本地上传、对象存储、企业网盘甚至邮件附件。在这一层，工程上需要考虑：

文件去重（基于哈希或内容指纹），避免重复向量化浪费算力与存储；
元数据抽取：文件名、上传人、所属项目、时间戳、访问权限等，这些信息会在后续检索中过滤使用；
转换预处理：对扫描件执行 OCR，对加密 PDF 做解密或提示用户。

解析模块则承担将 PDF 转为具有一定结构的中间格式的任务，例如：

以页面为单位，抽取所有文本块及其坐标、字体属性；
利用启发式或模型识别章节标题（字体更大、加粗、编号模式等）；
识别页眉页脚、页码，避免它们混入正文 chunk；
对表格区域进行检测与单元格重构，提取为结构化表格对象；
对图像与图注进行绑定，记录图像所在页与对应说明文字。

这些信息不一定全部进入最终的文本向量化流程，但会形成后续“结构化索引”的基础。例如 Neusym-RAG 中就分别为文本块、表格、图像区域建立了不同的视图，并通过图结构连接起来，以支持更复杂的查询。(ACL Anthology)

4.3 预处理与标注

在拿到布局级别的信息后，我们通常会进行一轮预处理与标注：

文本清洗：去除多余空白、重复页眉、页脚、页码、扫描噪声等；
正文合并：将属于同一段落的行、属于同一单元格的文本块合并；
结构标记：为每段文本附加“章节编号、标题层级、所在页码、源文件 ID”等标记；
跨页对象处理：对于跨页表格、图表，构建统一的逻辑实体，避免被误拆成多个无关 chunk。

这一步做得越仔细，后续的分块策略就越有操作空间。例如，对于“3.2 模型结构”这类段落，你可以在元数据中记录“section_path=3>3.2”，从而在检索时可以限定“只从第 3 章相关内容中检索”，降低噪声。

4.4 分块与元数据设计

在 PDF 场景中，我们可以把分块对象分成至少三类：

纯文本块：章、节、小节的正文段落；
表格块：结构化表格的文本表示（可以是 Markdown，也可以是“单元格串联”的线性文本）；
图像/图注块：图注文字 + 图像的 OCR 或图像嵌入。

不同类型的块在检索阶段可能走不同的通道。例如，当用户问“表 3 的第三列表示什么？”时，我们希望优先命中表格块；当用户问“图 2 展示了哪几个流程的关系？”时，则需要回到图像或图注块。

因此，在元数据中除了常规的文件 ID、页码、章节信息外，建议额外记录：

block_type：text / table / figure；
logical_id：如“表3”“图2”“公式(5)”等，便于处理引用；
layout_box：块在页面上的坐标，方便 UI 高亮；
semantic_tags：可选，如“定义”“定理”“风险提示”等，通过简单规则或分类模型打标。

这些元数据将参与后续的过滤、重排序、答案聚合。

4.5 向量化与索引模块

在向量化阶段，我们需要针对不同 block_type 选择合适的嵌入模型和输入格式。实际工程中常见的做法是：

对文本块使用通用文本嵌入模型（如 BGE-M3、gte-multilingual、OpenAI text-embedding-3-large 等）；(BentoML)
对表格块先将其线性化为带表头的描述性文本（例如“表 2：列 A 为…，列 B 为…”），再用文本嵌入模型编码；
对图像块则可以使用 CLIP、SigLIP 或 Jina Embeddings v4 这类多模态嵌入模型，并在元数据中记录图注文本以便混合检索。(BentoML)

向量数据库的选择上，可以参考 LiquidMetal 的比较结论：

如果团队希望完全托管、快速上线，可考虑 Pinecone 一类的云服务；
如果希望开源自建且支持大规模集群，可考虑 Milvus；
如果非常重视元数据过滤与高性能检索，可选择 Qdrant；
如果项目以 RAG 为主且数据量中等，Chroma 也能提供足够能力。(LiquidMetal AI)

在索引配置上，一般会针对不同集合（如“合同库”“技术文档库”“政策法规库”）分别创建索引，且为不同相似度度量（余弦 / 内积）与索引类型（HNSW、IVF-Flat 等）分别调优参数，以在召回率与延迟之间达成平衡。

4.6 查询与重排序流程

查询流程通常包含以下几个步骤：

查询理解：对用户问题进行意图识别与类型分类（如是否为“寻址某个图表”“问整体概念”“问某个具体数值”等），并据此选择不同的检索策略；
向量检索：将问题向量化，在对应集合中检索 top-k chunk，并结合元数据过滤（如限定文档类型、时间范围、部门等）；
重排序：可使用 cross-encoder 或 reranker 模型，对初步检索到的 chunk 进行更精细的相关性排序，同时考虑 chunk 与问题的匹配度、chunk 的信息密度、以及与同一文档内其他 chunk 的互补性；(ResearchGate)
上下文组装：根据模型上下文长度限制，将若干高分块组装为提示；
生成与引用：让 LLM 在答案中引用来源（如“见文档 A 第 3 页表 2”），并在 UI 中高亮对应内容。

图2 PDF RAG 查询与检索重排序流程图

5 PDF 文档分块策略的工程实践

5.1 静态分块：规则与经验

最基础的分块策略可以基于字符数或 token 数进行切分，如“每 500 字一段”“每 512 token 一块”，并设置一定的重叠。这种方法实现简单，在早期 PoC 中非常常见。但 Chroma 的评估表明，单纯改变 chunk 大小与重叠就会对检索指标造成显著影响：以 all-MiniLM-L6-v2 为例，当 chunk 大小为 250、重叠 125 时，TokenTextSplitter 的召回率约为 0.824，而在重叠为 0 时召回从 0.824 降至约 0.771。(Chroma Research)

在 PDF 场景中，静态分块的合理做法通常是结合结构信息做“分层分块”：

以章节为边界，避免跨章节拼接；
在章节内部，以段落为最小单元，尽量保持语义完整；
对于特别长的段落，再进行字符 / token 级切分，并设置 10–20% 的重叠。

这种分层策略的好处在于，既可以利用结构信息保持语义连续，又能控制单块长度，使其适应嵌入模型和向量库的性能限制。

为了更直观地说明不同静态分块配置对检索指标的影响，我们根据 Chroma 的评估结果整理了表 2（仅列出其中几组代表性配置的指标，原文中包含更大规模的实验表）。(Chroma Research)

表2 不同静态分块策略的检索指标（节选自 Chroma Research）

分块方法	chunk 大小 / 重叠（token）	召回 Recall（%）	IoU（%）	说明
TokenTextSplitter	250 / 125	82.4	3.5 左右	召回最高，但单块信息密度一般
Recursive splitter	250 / 0	78.5	5.4 左右	无重叠下 IoU 较高，chunk 较长
ClusterSemanticChunker	250 / 0	77.3	6.0 左右	语义聚类分块，IoU 表现较好
ClusterSemanticChunker	200 / 0	75.2	7.2 左右	chunk 更短但信息密度更高，IoU 最佳之一

注：表中数值根据 Chroma Research 公开表格中的结果整理，保留 1 位小数，原文使用 ± 标注标准差，这里省略。(Chroma Research)

从这张表可以看到，单纯的“均匀分块”在召回上并不逊色，但在 IoU 这类更能反映“相关信息密度”的指标上，语义感知的分块方法更有优势。

5.2 语义分块与动态分块

语义分块的核心思想，是不再机械地按长度切分，而是试图找到“语义边界”，例如自然段、话题切换点、标题等。具体实现方式包括：

基于 Embedding 的聚类分块（如 Chroma 的 ClusterSemanticChunker）：先将文本按较细粒度切片，再根据 embedding 之间的相似度聚类成更大的单元；(Chroma Research)
基于 LLM 的分块：让 LLM 直接读取较长文本，自行决定如何划分为多个“语义段”；
基于布局/结构的分块：利用 PDF 的标题、列表、表格等结构自然划分。

Chroma 的评估结果显示，在固定 chunk 大小的条件下，ClusterSemanticChunker 和 LLMSemanticChunker 在 IoU 指标上普遍优于基于字符或 token 的切分策略，说明语义边界在保障信息密度方面确有帮助。(Chroma Research)

而 MoG 以及前文提到的动态分块研究则进一步指出，不同任务甚至不同查询在粒度上的最优点并不相同。MoG 通过为同一语料预先准备多个粒度的切分，并训练一个 router 根据用户查询预测出各粒度的权重，再在检索阶段按加权分数选择 chunk，实现在保证召回的同时减少噪声。实验表明，在多个医疗问答数据集上，MoG 在小模型上相对于 MedRAG 和 CoT 平均带来 5% 和 8.7% 的准确率提升，而在大模型（如 GPT-3.5）上也能取得约 2–4 个百分点的改进。(ACL Anthology)

动态分块 + 向量搜索优化的研究则从工程角度给出一条完整路径：使用语义驱动的动态切分、Sentence-Transformers 嵌入、FAISS HNSW 索引，加上 cross-encoder 重排序，并采用 RAGAS 指标评估系统的 faithfulness、answer relevancy、correctness、context recall 与 context precision。作者在土耳其语 WikiRAG-TR 数据集上的实验证明，这种组合能在保证回答正确性的同时显著提升检索模块的效率。(ResearchGate)

图3 分块粒度与 RAG 准确率关系示意图

5.3 表格与图像的分块策略

在 PDF 中，表格与图像往往承载着高度浓缩的信息。如果只按文本顺序切分，很容易把“表头 + 上半部分行”分到一块、“下半部分行”分到另一块，从而在检索时找不到完整的表格语义。因此，针对表格与图像的分块，需要更多定制化处理：

对表格，通常先检测 table 区域，再将其转为结构化数据（如 HTML 表格或 pandas DataFrame），并将整张表作为一个逻辑 chunk，同时在元数据中记录“表名”“所在章节”“列名列表”等；
在向量化时，可以将表头、列名和若干示例行拼成描述性文本（例如“表 3 描述了不同 chunk 策略的召回率和 IoU，包含列：方法、chunk 大小、召回、IoU…”），再交给文本嵌入模型；
对图像，则需要将图注文字与图像 embedding 绑定，既支持仅凭文字检索，又支持多模态检索。PDF RAG 和 NeuSym-RAG 中都采用了类似策略，将图像 ID 嵌入到答案中，以便系统在 UI 上回溯到对应图片。(arXiv)

在 PDF RAG 的论文中，作者还额外处理了“表格生成的 markdown 回显问题”：如果 LLM 在答案中以字典形式输出表格，系统会将其转换回 markdown 或 HTML，以便用户查看。(arXiv)

图4 表格与图像分块示意图

5.4 分块策略对性能与成本的综合影响

在工程实践中，我们需要综合考虑以下几个维度：

检索质量：召回率、IoU、问题回答正确率等；
存储与索引成本：chunk 越小、重叠越大，向量数量越多，向量库体积越大；
向量化与索引构建时间：语义分块、LLM 分块往往需要大量计算；
查询延迟：chunk 越多，同样的 k 值检索到的信息越分散，上下文拼接越复杂。

Mix-of-Granularity 的实验表明，为了支持多粒度检索，需要额外存储多套粒度对应的嵌入，整体存储约为原始语料的 2.7 倍，但这在医疗问答等高价值场景中是可以接受的。(ACL Anthology) 使用更省算力的语义分块（如基于聚类的 chunker）则可以在不显著增加嵌入数量的前提下提升 IoU，非常适合预算有限但对回答精度有较高要求的业务。(Chroma Research)

图5 分块策略对向量数量与检索延迟的影响柱状图

6 嵌入模型与向量化配置

6.1 常用嵌入模型对比

在 PDF RAG 场景下，我们需要同时考虑多语言能力、长上下文支持、性能与许可证等因素。根据 BentoML、Greennode、ZenML 等近期综述，下面几类模型在 RAG 中使用较多：(BentoML)

表3 常见嵌入模型在 RAG 场景下的特性对比

模型	维度	多语言支持	上下文长度（大致）	许可证 / 商用	典型优势
BGE-M3	1024	>100 语言	~8192 token	Apache 2.0	支持稠密 + 稀疏 + 多向量，适合多功能、多语言 RAG (BentoML)
all-mpnet-base-v2	768	以英文为主	~384 wordpiece	Apache 2.0	Sentence-Transformers 中经典模型，工程生态成熟 (BentoML)
EmbeddingGemma-300M	768（可裁剪）	100+ 语言	2048 token	适用于商用（遵循 Gemma 许可）	体积小，可在边缘设备运行，支持 Matryoshka 表示(BentoML)
Jina Embeddings v4	2048（多向量）	30+ 语言	数千 token（视配置）	CC-BY-NC-4.0（源码开放，商用需 API）	统一文本 + 图像 + PDF 等多模态检索 (BentoML)
gte-multilingual-base	768	70+ 语言	~4096 token	Apache 2.0	多语言检索表现强，推理速度快 (BentoML)
Nomic Embed Text v2	768（可裁剪）	~100 语言	~512 token	开源	采用 MoE 架构，支持 Matryoshka 表示，在 BEIR、MIRACL 等基准上表现突出 (BentoML)

从这张表可以看到，开源模型在性能与灵活性上已经足够支撑大多数 PDF RAG 场景。对于强调成本控制或需要离线部署的项目，BGE-M3、gte-multilingual、Nomic Embed v2 等都是不错的候选；而对极端精度要求或已有 OpenAI 等闭源 API 生态的团队，则可以使用 text-embedding-3-large 等闭源模型，结合 MTEB 榜单上的性能表现进行评估。(Chroma Research)

6.2 维度、存储与检索延迟的权衡

向量维度直接影响存储占用与检索速度。假设我们有 100 万个 chunk，使用 768 维向量、每个维度 4 字节（float32），仅存储向量就需要约 768 * 4 * 1e6 ≈ 3GB；如果使用 1024 维，则接近 4GB。如果使用 Matryoshka 表示（例如从 1024 维截断到 256 维），在轻微牺牲精度的情况下可以显著节省存储和加速检索。(BentoML)

在资源有限的情况下，我们可以采取分级策略：

对“长尾文档”使用较低维度的嵌入；
对“热点文档”或关键业务文档使用高维嵌入，并可能为其建立额外索引；
对于跨语种场景，优先采用多语言嵌入模型，以避免为不同语种维护多套索引。

图6 向量维度与检索延迟关系示意图

6.3 稀疏 + 稠密混合检索

单纯的 dense embedding 在处理数字、代号、法律条款编号等“稀疏特征”时可能不够敏感，这在 PDF 文档中尤其常见。例如，一个合同条款编号“3.2.1”或某个型号“XJ-2025-B”，如果只依赖纯语义向量，很可能被“看作噪声”。因此，许多工作开始采用“稀疏 + 稠密”混合检索：

稀疏向量部分可以采用 BM25 或 SPLADE 等方法，将文本投射到高维稀疏空间；
稠密向量部分用于捕捉语义相似度；
在检索阶段综合这两部分的相似度得分，或者先用稀疏检索缩小候选集，再用稠密向量排序。

BGE-M3 等模型本身就支持稠疏一体的表示，为实现这类混合检索提供了便利。(BentoML) 对于 PDF RAG，建议在“找编号 / 找关键字”的场景中显式保留一个 BM25 或 Elasticsearch/pgvector 通道，而不是完全依赖 dense embedding。

6.4 嵌入更新与版本管理

在企业环境中，文档库是不断变化的：合同会签订、作废，制度会更新，技术文档会迭代。因此，嵌入向量也需要定期更新。Klesel 与 Wittmann 指出，RAG 之所以被认为优于微调，其中一大优势就在于“更新成本低”，只需要重新处理新增或变更文档，并更新向量库即可。(ResearchGate)

在工程上，可以采用以下策略：

对新增 PDF，采用增量管道：定期扫描存储桶，检测新增 / 修改文件，只对这些文件执行解析、分块与向量化；
对嵌入模型版本升级时（例如从 BGE-base 切换到 BGE-M3），增设一套新的向量集合，逐步迁移，也可以在查询时对重要问题双写检索两套集合并对比答案；
通过向量库中的“版本字段”区分不同嵌入版本，保留一定历史以便回溯。

图7 嵌入更新流程时序图

7 向量数据库与索引策略

7.1 向量数据库选型

LiquidMetal 的对比文章从性能、可扩展性、易用性、元数据过滤、部署选项等多个维度，对 Pinecone、Weaviate、Qdrant、FAISS、Milvus、Chroma 进行了一次系统评估。(LiquidMetal AI) 结合该文以及工程经验，我们在表 4 中总结了这些方案在 PDF RAG 场景下的适配性。

表4 常见向量数据库在 PDF RAG 场景下的特性对比

方案	类型	部署形态	优势	局限	适合场景
Pinecone	托管向量数据库	云端托管	大规模时性能稳定，企业级安全与监控完备，RAG 支持完善	成本相对较高，云端锁定	大型企业、对运维敏感、需要快速上线
Weaviate	开源 + 托管	自建 / 托管	GraphQL 接口，支持知识图谱与向量检索结合	上手曲线略陡，配置较多	需要丰富关系建模与语义检索结合的场景
Qdrant	开源向量引擎	自建 / 云端	Rust 实现，性能高；元数据过滤能力强；ACID 事务支持	生态相对较新，分析工具较少	高吞吐检索、需要复杂过滤的搜索引擎与 RAG
FAISS	库（非完整 DB）	嵌入应用	提供最丰富的 ANN 算法，GPU 加速优秀	不负责持久化与元数据管理，需自行封装	有强工程能力、需最大化控制索引细节的团队
Milvus	开源向量数据库	自建 / Zilliz Cloud	云原生架构，支持超大规模，索引类型丰富，支持混合检索	分布式部署复杂，对资源要求较高	大规模 PDF 知识库、需要高可用和横向扩展
Chroma	轻量级开源库	自建	API 简单，与 LangChain 等集成良好，专为 RAG 场景设计	企业特性较少，不适合超大规模	原型开发、中小规模文档库、快速迭代的项目

(LiquidMetal AI)

对于大多数刚起步做 PDF RAG 的团队来说，如果对延迟要求不是极端苛刻、数据规模在百万级 chunk 以内，使用 Chroma 或 Qdrant + 自建服务往往能在“能力”和“复杂度”之间取得良好平衡；当业务发展到数亿级 chunk、跨多地域部署时，再考虑 Milvus 或 Pinecone 等方案进行迁移。

7.2 索引结构与参数调优

在具体索引选型上，可以参考前文提到的动态分块 + FAISS 优化研究结果。该研究在 Metin/WikiRAG-TR 数据集上比较了 IndexIVFFlat 与 IndexHNSWFlat，并结合 RAGAS 指标评估了不同配置下的表现，实验结果显示 HNSW 在检索精度和延迟之间取得更优折中，尤其适合对语义相似度要求较高的 RAG 系统。(ResearchGate)

Milvus、Qdrant 等系统通常为 HNSW 提供可配置参数，如 M（每个节点的邻居数）、efConstruction（索引构建时的探索宽度）、efSearch（检索时探索宽度）。经验上：

增大 efSearch 会显著提升召回率，但同时增加查询延迟；
对于百万级向量，efSearch 在 64–128 左右通常能取得不错平衡；
如果 chunk 数量极大，可以考虑先按文档层面粗选，再在局部向量集合中执行 HNSW 检索。

在 IVF 系列索引（如 IVF-Flat、IVF-PQ）中，关键参数是聚类中心数 nlist 与每次探查的簇数 nprobe。nlist 越大、nprobe 越多，召回越高、延迟越大。实际调优时，可在验证集上扫描一系列 nlist/nprobe 组合，以找到满足业务 SLA 的最优点。

图8 不同索引配置下召回与延迟的折衷曲线

7.3 元数据过滤与多视图索引

在 PDF RAG 中，向量检索往往只是“粗召回”阶段，真正让结果可用的往往是元数据过滤与多视图索引设计。例如，当用户问：“根据 2024 年最新版员工手册，远程办公的审批流程是什么？”

一个鲁棒的系统应该：

在向量检索前，根据关键词“2024 年最新版”“员工手册”在元数据中限定文档集合与版本号；
在检索结果中偏向 block_type=text 且位于“远程办公相关章节”的 chunk；
如有多个版本冲突，通过元数据中的“生效日期”或“版本号”进行排序。

NeuSym-RAG 的多视图设计则更进一步：它把 PDF 中的文本、布局、结构化单元以图的形式组织起来，在检索时不仅考虑单个 chunk 的向量相似度，还考虑图结构上的连接关系，例如从标题节点扩展到下属段落、从表头扩展到整张表格等。(ACL Anthology)

对于工程实现者来说，不一定要一开始就实现完整的“图索引”，但至少可以在向量库之外维护一份结构化的“文档 → 章节 → 段落 / 表格 / 图像”层次结构，并在检索后对结果进行结构聚合，如“如果一个段落命中得分很高，则将同一节中的其他段落一起加入上下文”。

7.4 混合存储与降级策略

在实际系统中，为了提升鲁棒性和成本效率，常见做法是引入混合存储与降级策略：

在数据量较小的部门级知识库中，直接使用 pgvector + PostgreSQL，在现有数据库中内嵌向量检索；(LiquidMetal AI)
在核心文档库中使用专门的向量数据库（如 Qdrant、Milvus）；
在离线批处理任务中采用 FAISS standalone 版本（无需网络通信，便于快速试验各种索引）。

同时，当向量库暂时不可用或负载过高时，可以降级为基于关键字的全文搜索，并在答案中明确提示“当前使用的是关键字搜索结果”，以避免误导用户。这种“可退化”设计在 Klesel 与 Wittmann 的 RAG 架构讨论中也被强调，作为提升系统可靠性的关键设计。(ResearchGate)

8 性能评估与案例分析（基于公开数据的综合讨论）

8.1 综合评测指标：从检索到答案

前文提到的多篇研究为我们提供了评估 PDF RAG 系统的丰富指标：

Chroma 的评估提出：召回、精确率、IoU 是衡量 chunk 检索表现的核心指标；(Chroma Research)
动态分块 + 向量搜索的研究采用了 RAGAS 框架，包括 faithfulness（忠实度）、answer relevancy（相关性）、answer correctness（正确性）、context recall 与 context precision 等指标；(ResearchGate)
MoG 工作则聚焦于最终任务的准确率（如医疗问答），并对不同粒度策略下的执行时间和存储开销进行评估。(ACL Anthology)

综合这些工作，我们可以为 PDF RAG 建议如下三层评估体系：

检索层：使用合成或人工标注的“问题-相关片段”对，评估召回、IoU、context recall / precision；
答案层：使用 RAGAS 或人工评估，衡量答案是否忠实于上下文、是否回答了问题；
系统层：评估端到端延迟、吞吐量、资源消耗，以及在真实用户日志中的问题解决率。

表 5 给出一个基于公开实验结果整理的“不同分块与索引策略对指标影响”的综合示例（数值为不同来源中具代表性结果的抽象化示例，用于说明趋势而非精确复现）。

表5 不同策略组合对 RAG 指标的影响（基于公开结果的趋势整理）

策略组合	检索召回 / IoU	RAGAS 忠实度 / 正确性	端到端延迟	存储开销	来源
固定长度分块（250/0）+ IVF-Flat	召回中等，IoU 偏低	忠实度一般，答案易受噪声影响	延迟较低	存储较低	Chroma + 动态分块研究(Chroma Research)
TokenTextSplitter（250/125）+ HNSW	召回最高，IoU 中等	忠实度较好，答案覆盖度高	延迟中等偏高	存储中等偏高	Chroma + FAISS HNSW 比较(Chroma Research)
语义分块（Cluster/LLM）+ HNSW	召回略低但 IoU 高	忠实度和正确性最佳，干扰少	延迟高（分块/重排耗时）	存储中等	Chroma + 动态分块研究(Chroma Research)
多粒度分块（MoG/MoGG）+ HNSW	召回与 IoU 综合最好	小模型上准确率提升 5–8.7%，大模型提升 2–4 个百分点	延迟略增但可接受	存储约为原始语料 2.7 倍	MoG / MoGG 论文(ACL Anthology)

可以看出，在不同资源约束与业务优先级下，最优的策略组合并不相同：如果你非常在意成本和速度，固定长度 + 简单索引也许就够；如果你在做医疗、法律等高风险场景，那么多粒度语义分块 + 高质量索引 + 重排序则更值得投入。

8.2 PDF RAG 的端到端案例抽象

综合前文的研究与工程实践，我们可以抽象出一个“端到端 PDF RAG 系统”在现实企业中的落地路径：

初期 PoC 阶段，团队往往使用 LangChain + Chroma + BGE-base 或 all-MiniLM-L6-v2，通过简单的字符分块和 HNSW 索引，在少量文档上实现“能用”的问答；(Chroma Research)
当用户需求增多、文档规模扩大，系统逐渐引入更精细的 PDF 解析（如 GROBID 或 layout 解析）、段落级分块以及元数据过滤，解决“答非所问”“跨版本文档混淆”等问题；
进一步优化阶段，开始在生产数据上构建评估基准，系统地比较不同分块策略、索引配置和嵌入模型，并依据 RAGAS 等指标迭代；(ResearchGate)
在高价值场景（如合规审查、医疗问答）中引入多粒度或动态粒度分块，通过路由器或任务分类器智能选择粒度，以在不显著增加延迟的前提下提升准确率；(ACL Anthology)
最终，在权限、审计、监控、反馈闭环方面逐步完善，将系统演化为企业级“文档智能中心”。

图9 PDF RAG 系统演进路线图

9 结语：在“把 PDF 丢给模型”之前

回到本文标题，“把 PDF 丢给模型”听上去轻松，但要在现实复杂的企业环境中让模型真正“看懂 PDF 并给出可靠答案”，必须正视一系列工程问题：

PDF 本身是为显示而非理解设计的格式，其解析需要综合版面、字体、结构等信息；
分块策略直接决定了检索的“信息颗粒度”，从 Chroma 的评估到 MoG 的多粒度检索，都充分说明了粒度选择对 RAG 效果的巨大影响；(Chroma Research)
嵌入模型的选择既关系到语义表达能力，也关系到多语言支持、长文本处理与部署成本；(BentoML)
向量数据库与索引结构则是支撑系统可扩展性与性能的基础设施，其选型需要结合业务规模与团队能力，不能一味追求“最潮架构”；(LiquidMetal AI)
最后，一套合理的评估体系（包括检索层、答案层与系统层的指标）是持续迭代的前提，没有评估就难以在工程实践中做出正确权衡。(ResearchGate)

如果用一句话总结本文的核心观点，那就是：在 PDF RAG 项目中，真正决定成败的，往往不是你选了哪一个“大模型”，而是你如何设计并打磨“向量化、分块与索引”这一整条链路。

在实际写代码之前，不妨先拿出纸笔，把你的文档类型、查询类型、可用资源和业务约束一一写清楚，对照本文所述的研究与工程实践，设计出一套适配自己场景的方案——而不是盲目照搬某个 Demo 中“把 PDF 丢给模型”的一键式魔法。

参考资料

下列参考资料基于文中引用的公开论文与工程报告整理，供进一步深入阅读。

[1] Michael Klesel, H. F. Wittmann. Retrieval-Augmented Generation (RAG). Business & Information Systems Engineering, 67(4):551–561, 2025. (ResearchGate)

[2] Patrick Lewis et al. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks. 2021. （最初提出 RAG 框架，Chroma Research 与多篇综述均引用）(Chroma Research)

[3] Chroma Research. Evaluating Chunking Strategies for Retrieval. 2024. （系统评估多种分块方法对召回与 IoU 的影响）(Chroma Research)

[4] Mix-of-Granularity: Optimize the Chunking Granularity for Retrieval-Augmented Generation. COLING 2025. （提出 MoG / MoGG 多粒度检索机制并在医疗问答任务上验证）(ACL Anthology)

[5] Enhancing Retrieval-Augmented Generation Accuracy with Dynamic Chunking and Optimized Vector Search. OPRD, 2024. （在土耳其语 WikiRAG-TR 数据集上比较动态分块与 FAISS 索引）(ResearchGate)

[6] PDF Retrieval Augmented Question Answering. arXiv:2506.18027, 2025. （构建支持文本、图像、表格的 PDF RAG 系统）(arXiv)

[7] NeuSym-RAG: Hybrid Neural Symbolic Retrieval with Multiview Structuring for PDF Question Answering. ACL 2025. （多视图结构与混合检索在 PDF 问答中的应用）(ACL Anthology)

[8] A Guide to Open-Source Embedding Models. BentoML Blog, 2024. （介绍 BGE-M3、EmbeddingGemma-300M、Jina v4、gte-multilingual 等开源嵌入模型的特性）(BentoML)

[9] 5 Best Embedding Models for RAG: How to Choose the Right One. Greennode AI Blog, 2024. （从成本与性能角度讨论 OpenAI Embedding 3-Large、Cohere、BGE 等模型）(greennode.ai)

[10] Vector Database Comparison: Pinecone vs Weaviate vs Qdrant vs FAISS vs Milvus vs Chroma. LiquidMetal AI, 2025. （对主流向量数据库的特性与适用场景进行对比）(LiquidMetal AI)

[11] PDF Statistics & Usage in 2025: Tools and Trends Shaping Digital Documents. Smallpdf, 2025. （统计 PDF 在协议、医疗记录、政府表单等场景中的使用比例）(Smallpdf)

[12] PDF’s Popularity Online. PDF Association, 2021–2025. （通过搜索结果统计 PDF 相对其他文档格式的在线普及度）(PDF Association)

[13] 100 Document Management Statistics to Make You Rethink Your Processes in 2025. FileCenter Blog, 2025. （统计约 85% 企业依赖 PDF 格式进行信息共享等数据）(FileCenter)

[14] Retrieval-Augmented Generation for Educational Application: A Systematic Survey. 2025. （系统性梳理 RAG 在教育场景的应用）(ScienceDirect)

[15] MTEB: Massive Text Embedding Benchmark. 2022 及后续更新. （大规模文本嵌入模型评测基准，为嵌入模型选择提供参考）(Chroma Research)