夜雨聆风其实，这个问题非常考验候选人的实践能力，如果一上来就聊向量数据库选型，然后直接说我调用API做解析和切片，那就属于没有理解面试官的意思了。
因为，他们想考察的不是demo的环境，而是工业级 RAG 落地场景下的一些实践环节。在实践环节中，上游版面还原的偏差会一路传导到检索结果——解析时表格结构识别偏了一行。面试官真正想看的，不是你会不会调API，而是你有没有亲手看过切片结果、能不能识别出文档解析与切片这条链路上每个环节的失效模式。
我们先讲下背景，再详细讲下PDF做RAG的流程以及可能遇到的问题。
1. 背景
当一份PDF报告里嵌着密密麻麻的数据表格，或者一张跨页的架构图横亘其中，RAG系统该如何"读懂"它？这不是一个可以用通用策略一揽子解决的问题——事实上，许多团队在构建知识库时踩的坑，恰恰出现在这个最早、最底层的环节：文档解析。
要理解挑战的根源，先得认清一个分类。构建RAG知识库所涉及的文档，从解析难度上大致分为两类。其一是带结构标记的文档，如标准的Word文件、HTML页面等，内部已编码了层级与语义信息，可以相对直接地提取。其二是无标记文档、PDF、扫描件、图片均属于弱语义结构文档。尤其是PDF，其内部虽然包含文字坐标、字体与版面布局信息，但缺少类似HTML DOM那样稳定、显式的语义层级，因此机器往往只能先看到字符位置与视觉布局，而非“这是标题”“这是表格第三列”这样的逻辑关系。北京大学与上海人工智能实验室的一项调研也指出：基础OCR只是提取字词，真正的文档解析器需要进一步理解标题就是标题、表格有行有列、多栏版面有特定阅读顺序，缺少这一层结构识别，送入大模型的将是一堆杂乱无章的文字堆砌，而非它能够有效推理的结构化内容。
这也意味着，"针对不同格式制定专属解析策略"不是锦上添花，而是整个RAG管线的先决条件。
2. PDF文档解析怎么做
以PDF为例，完整的解析流程可以拆解为四个环节，缺一不可。
第一步，文档分页。将PDF按单页拆分，为后续逐页处理奠定基础。这一步虽看似简单，却是所有识别任务的前提单元。
第二步，版本识别。需要区分电子版PDF与扫描版PDF这两条截然不同的路径。电子版内嵌了可提取的文字层，相对好处理；而扫描版本质上是图片，图像精度直接决定了后续OCR的天花板——一份300dpi以下的扫描件，往往就是识别质量滑坡的起点。
第三步，元素切割与结构化识别。PDF页面中往往混杂着段落文字、嵌入图片、数据表格等异质内容，需要先经过版面检测将其拆分为不同的语义模块，再分别交给对应的工具处理。对于电子版PDF，通常优先直接提取其内嵌文字层；而扫描版PDF由于本质上是图像，则需要进入OCR流程完成文字识别。说起表格则需要专门的表格结构识别（TSR）工具进行精细化处理。这里值得停下来做一个横向对比：一项针对Docling、Unstructured和LlamaParse三款主流PDF解析工具的基准测评显示，Unstructured在简单表格上可达100%识别准确率，但面对复杂结构时下滑至75%；Docling则在复杂表格提取上表现最为稳健，准确率接近98%。而LlamaParse被部分评测者列为首选，但也有观点认为它擅长让内容"看起来像表格"，数据内部仍需清洗。没有哪一款工具全场通吃——对于构建严肃数据基础设施的团队，业界逐渐摸索出一种组合策略：当一个工具失效时，另一个往往能成功，这让"集成多工具"的表格提取方案越来越有实际价值。
第四步，版面分析与结构还原。PDF存在单栏、双栏、跨页等多种版面形态，OCR识别之后拿到的往往是散点式的文字碎片。版面检测中的细微偏差会引发连锁失误——错误地识别阅读顺序，意味着本来前后呼应的两段内容在知识库里被割裂开来存储，而这种错误在后续检索阶段几乎无法修复。因此，将散点文字还原为贴近原文逻辑的结构，才是提升后续切片质量的真正关键，而不是依赖更大的语言模型去"猜"原文想表达什么。
3. 智能切片咋做
完成解析之后，才轮到切片策略登场。许多开发者在这一步陷入了一个常见误区：把固定长度切片当作"够用就好"的临时方案，然后永远停在了临时阶段。固定尺寸与滑动窗口方法在处理复杂PDF时面临几个根本性局限：跨越切分边界的内容会被割裂，跨页表格、分步骤流程和交叉引用关系全部断开，而纯文本提取又完全忽略了图表、图示和版面结构这些往往承载关键信息的视觉元素。
不过，将固定切片批评得一无是处，也失之武断。Vectara在NAACL 2025发表的同行评审研究对25种切片配置结合48个嵌入模型进行了系统评测，结果显示切片配置对检索质量的影响与嵌入模型的选择旗鼓相当——在某些真实文档集上，固定尺寸切片的综合表现甚至不逊于语义切片。这提醒我们：切片策略没有银弹，选择必须以实际场景和下游任务为准，而不是盲目追随技术时髦。
那么，如何设计一套更贴合实际的智能切片流程？
首先是文档结构识别。不同文档类型的内在逻辑结构差异显著——技术手册、法律合同、财报附注各有各的组织方式。理想的切片流程应与最终检索需求协同设计：切片粒度的粗细、语义增强的类型、索引结构的复杂程度，都取决于上层应用（问答、摘要、分析）对精度、速度和成本的具体要求。这意味着"为文档类型配置对应切片策略"并非一劳永逸的模板工作，而是一种需要持续调优的工程判断。
其次是语义切片，即借助模型预测句间语义关联，在意义转换处而非任意字符数处划定边界。一项发表于MDPI Bioengineering的同行评审临床决策支持研究发现，与固定尺寸基线相比，语义切片在准确率上高出近74个百分点（87% vs 13%），差异具有统计显著性。然而，语义切片并非没有代价：FloTorch 2026年的基准测评发现，语义切片产生的碎片平均仅有43个token，这些超短碎片虽然检索召回率可观，却给语言模型留下了过少的上下文来生成正确答案——召回率高，答案错，两者并不矛盾。
第三步是设置重叠度。在相邻文档块之间保留一定比例的重叠内容，是对抗语义割裂的常用手段。实践中的经验起点通常是10%到20%的重叠区间，对于512 token的切片块而言，大约对应50到100个token的重叠量。
第四步也是最容易被忽视的一环：图表的特殊处理。表格与图示不是文字的附属装饰，往往才是文档信息密度最高的部分。如果将图表标题和对应内容剥离成两个独立切片，检索时极可能只找到标题而失去数据，或只拿到数据而没有语境。正确的做法是将二者合并为同一个切片单元，保持图表信息的完整闭环。RAGFlow的DeepDoc模块正是沿着这个思路设计的：通过OCR、表格结构识别与文档版面识别的协同，目标是将多模态、多格式的原始文档转化为保留原始逻辑结构（标题、列表、表格）和元数据的结构化文本表示。
4. 总结下
走完解析与切片的全部流程，才算真正进入向量化阶段的入口。整个链条的隐含逻辑是：向量数据库和嵌入模型的精心选型，很可能被上游一个粗糙的版面还原步骤悄悄抵消。
RAG工程的难点不在于某个环节的技术突破，而在于每个环节都有自己"失效"的方式，且相互叠加。解析出错，切片再好也是无根之木；切片割裂了上下文，检索召回率再高也换不来正确答案。在实际落地中，我的建议是：先用小规模文档集跑通全链路并人工抽检切片质量，再批量处理，而不是在工具选型和参数配置上花太多时间，却从未正视过那些被切坏的内容。技术选型固然重要，但亲手看一眼切片结果长什么样，往往比阅读十篇基准测评更能帮你做出正确判断。
Best Chunking Strategies for RAG (and LLMs) in 2026,Bex Tuychiev
