多模态RAG结构感知解析：朴素切分为何破坏检索，如何构建替代Pipeline

朴素文本切分带来的问题

技术类 PDF 并不是因为内容太长而导致 RAG 失效，而是因为大多数文本切分系统破坏了赋予这些文档意义的结构关系。

一个被拆分到不同 chunk 中的表格，就不再是一个完整的表格；一个脱离原有布局的公式，会变成一堆没有意义的符号；一个没有图注的图表不再具有证据价值，它只是一个没有上下文的图片。

这就是朴素切分的弊端。传统文档解析器通常按照页数或者字符数量切割文档，然后按照从左到右、从上到下的顺序读取文本，即使这些文档原本并不是按照这种方式组织的。

最终得到的是一个建立在破碎信息片段之上的检索系统。向量数据库返回的不再是完整的表格行、相关联的图片或者连贯的章节，而是一堆碎片：半截图注、错误的表格列、脱离上下文的公式，以及顺序混乱的段落。

图1：如果按大小而非含义对文档进行切片，就会将表格和图表与其解释性文本分离。为了避免这种情况，解析器必须在提取内容之前，使用坐标边界框映射文档的空间布局。

图源：作者

解决方案并不是简单地调整 chunk 的大小，而是在进行任何向量嵌入或检索之前，采用能够保留文档布局、空间坐标以及多模态关联关系的结构感知解析方法。

从 PDF 到答案的 Pipeline 总览：四个阶段

为了解决朴素文本切分导致的布局破坏和内容分离问题，该 Pipeline 必须从一开始就保留表格、图片以及文档阅读顺序的空间坐标信息。它将工作负载分为四个连续阶段：解析（Parse）、增强（Enrich）、导入（Ingest）、检索（Retrieve）。每个步骤都依赖于本地模型来处理信息，并将结构化数据或向量记录传递到下一阶段。

解析阶段（Parse）：Pipeline 会在提取任何文本之前，先映射文档的物理布局结构。PP-DocLayout-V3 会识别文档中的表格、图片和段落，并为它们分配坐标边界框（bounding boxes）。当这些空间区域被确定后，GLM-OCR（一个光学字符识别模型）会严格地从这些坐标区域内部提取文本。这样可以避免侧边栏文本与正文段落混合在一起。该步骤最终输出一个结构化 JSON 文件，其中包含原始文本，以及每一个文档元素对应的精确边界框坐标。

图2：布局检测在读取文本之前，会绘制出不同文档元素的物理边界。PP-DocLayout-V3 模型会为表格、图表和段落分配坐标边界框，以防止它们在提取过程中被分割

图源：作者

增强阶段（Enrich）：将非文本内容转换为可以被搜索和检索的描述信息。它会从结构化 JSON 文件中提取已经定位好的图片、表格和公式区域，并将这些内容传递给 qwen2.5vl:7b（一个通过 Ollama 在本地运行的视觉语言模型）。模型为每个视觉元素写文本注释。输出是一个丰富的 JSON 文件，其中包含原始结构坐标、原始文本和新标题。

图3：四阶段的流水线架构。箭头显示了 JSON 文件和矢量记录在布局提取、图像描述、矢量嵌入和检索节点等本地模型之间的移动。

图源：作者

导入阶段（Ingest）：经过增强阶段的 JSON 文件会被处理并准备存储。qwen3-embedding:4b 模型会将文本和生成的描述信息转换为向量嵌入，用于相似性搜索的数字数组。这些数值向量连同原始文本块和边界框坐标，以记录的形式存储在 Qdrant（一个针对向量检索优化的本地数据库）。

检索阶段（Retrieve）：当用户提交问题时，检索阶段开始执行。系统首先将用户问题转换成向量，然后在 Qdrant 数据库中搜索相似度最高的内容。对于非视觉类查询，系统会使用 cross-encoder 对初步检索结果进行评估和重新排序，从而过滤掉相关性较低的结果。最终得分最高的文本、图片和表格块，会作为经过排序的上下文信息传递给下一阶段，为最终答案生成准备数据。

检索机制：模态增强和交叉编码器重排序

图4：完整的检索架构。该系统首先执行初始向量搜索，如果图像块中包含视觉关键词，则应用数学评分提升算法提升图像块的权重，最后使用交叉编码器对文本和表格候选结果进行重新排序。

图源：作者

如果用户提交类似以下问题：“这个架构图展示了什么？”或是“描述一下流程图中的 encoder 和 decoder 模块。”传统的向量检索通常会寻找语义上相似的文本内容。然而，当用户明确要求获取图表、图片或者流程图时，这种方法经常会失效。在增强阶段（Enrich），为图片生成描述的视觉模型，可能会将目标图片描述为：“一个包含相互连接节点的系统架构。”这造成了一种语义错配：用户请求的是一种视觉形式的信息，但 caption 仅仅描述了图片的内容。为了弥补这一差距，该 pipeline 引入了模态增强机制。

模态增强会在检索阶段（Retrieve），对特定类型的数据增加目标性的评分提升。当 pipeline 检测到查询中包含视觉关键词，例如：diagram（图示）、figure（图）、flowchart（流程图），它会自动将数据库中所有图片类型 chunk 的检索分数提高 35%。在该项目的测试结果中，仅仅这一项调整，就使正确的图片 chunk 从原来的第 7 名提升到了第 1 名。

图5：模态增强会在搜索查询中出现视觉关键词时，对图像块应用特定的分数倍增器。这种调整可以弥补用户对图像的描述与视觉模型对图像的描述之间存在的词汇差异。

图源：作者

图6：模态调整前后的检索评分对比。通过对图片 chunk 应用 1.35 倍的评分乘数，其检索分数从 0.837 提升至 1.130，使其排名从第 7 位提升到第 1 位。

图源：作者

对于文本类和表格类查询，该 pipeline 通过交叉编码器重排序（cross-encoder reranking）机制来保证检索精度。初始的稠密向量搜索速度很快，但它会返回一个较宽泛的候选列表，通常包含排名最高的前 20 个 chunk。然后系统会将这些候选 chunk 输入到 ms-marco-MiniLM-L-12-v2 交叉编码器模型中。该模型会直接比较用户查询与每个 chunk 的文本内容，计算更加精细的相关性评分。

它重新对候选进行排名，并保留前四个 chunk。在 repo 的测试结果中，这个重新排序机制成功地评估了关于“模型复杂性”和“训练成本”的查询，一致地将原始 TABLE chunk 提升到比标准文本段落排名第一的位置。

该架构在设计上会针对视觉查询主动跳过 cross-encoder 这一步。Cross-encoder 模型主要是在评估密集文本段落的任务上进行训练的。在该 pipeline 的测试评估中，将 cross-encoder 应用于视觉查询中的短图片描述，实际上降低了排序质量。对于获取视觉内容，单独使用模态增强就能够获得更高的检索准确率。

评估结果

将该 pipeline 应用于测试查询后，实验结果表明：结构感知解析、模态增强以及重排序三者结合使用，能够成功地将用户真正需要的信息模态（如文本、图片或表格）排在上下文窗口的最前面。

在本地运行整个 Pipeline

对于许多多模态应用来说，调用云端 API 是默认选择，但这个 pipeline 完全运行在本地硬件环境中。这一点的重要性不仅体现在性能方面，更体现在隐私保护方面。敏感文档、生成的 embedding 向量以及用户查询，都可以保留在团队控制的基础设施内部，而不是经过第三方服务。本地运行还使系统更容易被检查和分析。开发者可以打开解析阶段（Parse）和增强阶段（Enrich）过程中生成的 JSON 文件，准确查看文档是如何被布局分析、切分以及生成描述的。最终得到的是一个更容易调试、更容易复现、也更值得信任的 pipeline。

整个 pipeline 的执行从一个中央入口文件 run_all.py 开始。解析和文本切分逻辑被拆分到不同阶段对应的模块中，这个调度脚本会按照顺序调用每个阶段，从 src/phase1_parse.py 一直到 src/phase4_retrieve.py。

for phase in phases:
    print(f"\nPHASE {phase}")
    if phase == 1: run_phase1(pdf_path)
    elif phase == 2: run_phase2()
    elif phase == 3: run_phase3()
    elif phase == 4: run_test_queries()

图7：该代码库将执行逻辑与配置设置分离。一个中央入口点引导数据流在各个独立的阶段模块之间流动，使开发人员能够在不更改管道其余部分的情况下调试或替换某个阶段。

图源：作者

为了支持快速实验和迭代，该架构将“配置”与“执行逻辑”进行了分离。所有共享配置都保存在 src/config.yaml 文件中。将这些配置变量集中管理意味着，开发者在将该项目迁移到自己的数据集时，只需要修改一个配置文件，就可以更换 Embedding 模型，或者指定新的本地数据库目录，而无需修改程序代码。

models:
   embedding: "qwen3-embedding:4b"
   llm: "qwen2.5vl:7b"
   vlm: "qwen2.5vl:7b"
   cross_encoder: "cross-encoder/ms-marco-MiniLM-L-12-v2"

通过将不同的功能操作拆分到独立的文件中，这个项目使开发者能够更容易地修改 pipeline 中的某个特定功能，而不会对其他部分产生意外的影响。例如，整个检索阶段（Retrieval）逻辑都集中放在该阶段对应的模块中。在处理用户查询时，该模块会首先检查查询中是否包含视觉相关关键词，然后以数学方式对图片类型的检索结果应用模态增强。

is_vis = bool(set(query.lower().split()) & visual_kw)
      if is_vis:
             print('   Visual query - boosting image 35%')
             for hit in results.points:
if hit.payload.get('modality') == 'image':
             hit.score *= 1.35

将这些核心逻辑直接暴露在普通 Python 代码中，可以让检索行为更加容易被检查和修改。开发者可以调整视觉关键词列表、修改 35% 的评分提升权重，或者尝试新的检索阈值，使系统更好地适应特定文档集合中的语言表达方式和结构特点。

结论

简单粗暴的 PDF 提取方式带来的问题，不只是丢失格式，而是破坏了原本赋予表格、图像、公式和段落意义的结构关系。结构感知 pipeline 会在检索开始之前，重新恢复这些关系。当这种结构感知方法进一步结合视觉描述生成、模态增强以及重排序后，它能够为答案生成阶段提供更加准确的上下文信息。将整个系统部署在本地运行，还带来了额外优势：系统更加容易检查、更容易复现，并且更加适合处理敏感文档。

自己动手尝试

该 pipeline 的完整代码已经开源并发布在 GitHub 上。开发者可以克隆这个 GitHub 仓库，查看整个 pipeline 的执行流程，或者根据自己的数据集调整模态增强的权重。

💻 在 GitHub 上探索 Pipeline：

https://github.com/mohitagr18/multimodal_rag_article

参考文献

1. Sun, X., et al., PP-DocLayout: A Unified Document Layout Detection Model to Accelerate Large Document Understanding (2025), arXiv. (https://arxiv.org/abs/2503.17213)
2. Zheng, X., et al., GLM-OCR Technical Report (2026), arXiv. (https://arxiv.org/abs/2603.10910)
3. Bai, S., et al., Qwen2.5-VL Technical Report (2025), arXiv. (https://arxiv.org/abs/2502.13923)
4. Qwen Team, Qwen3-Embedding: A Text Embedding and Ranking Model Series (2025), GitHub. (https://github.com/QwenLM/Qwen3-Embedding)
5. Qdrant Team, Qdrant: High-performance, massive-scale Vector Database (2024), Documentation. (https://qdrant.tech/)
6. Nogueira, R., and Cho, K., Passage Re-ranking with BERT (2019), arXiv. (https://arxiv.org/abs/1901.04085)
7. Karpukhin, V., et al., Dense Passage Retrieval for Open-Domain Question Answering (2020), arXiv. (https://arxiv.org/abs/2004.04906)
8. Lewis, P., et al., Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks (2020), arXiv. (https://arxiv.org/abs/2005.11401)
9. Ollama Team, Ollama: Run Large Language Models Locally (2024), Documentation. (https://ollama.com/)
10. PaddlePaddle Team, PP-DocLayoutV3: Layout Analysis for Non-Planar Document Images (2026), Hugging Face. (https://huggingface.co/PaddlePaddle/PP-DocLayoutV3)

原文标题：Why Naive Chunking Breaks RAG, and What to Build Instead

原文链接：https://ai.gopubby.com/why-naive-chunking-breaks-rag-and-what-to-build-instead-f1cc12e60ecf?gi=3f53f9299d63