2026 CVPR

当前RAG（检索增强生成）系统的文本分块环节，长期陷入“重长度、轻结构”的技术误区：不少开发者仍习惯按固定字数硬切长文本，或是直接调用LangChain等工具的递归字符分块器，仅按预设的换行、句号等分隔符拆分，虽然比硬切稍好，但仍容易把属于同一逻辑单元的文档内容拆散，遇到多级标题、跨页段落时更是频繁出现关键信息被拦腰截断的问题，直接拉低后续检索的准确率。

传统分块逻辑总把结构化文档撕得零散

目前业界常用的递归切分策略，虽然预设了chunk_size=512、chunk_overlap=128的适配多数Embedding模型的参数，也针对中文场景优化了\n\n、句号、问号等分隔符，先按大结构切再按段落细化，但本质仍是“长度优先”的逻辑：遇到Word文档里的多级标题、PDF里的嵌套小节、技术文档里的层级内容时，完全无法识别内容所属的语义单元，经常出现同一个技术概念的说明被拆分到两个独立块里的情况，检索时要么召回不全，要么把不相关的同章节内容误判为相关。

M3DocDep首创文档家谱预解析机制

M3DocDep的核心突破是跳出“先切块再补元数据”的常规思路，先给文档建立完整的“家谱”：提前提取全文档的结构元素，包括H1/H2/H3等多级标题层级、段落/表格/列表等内容单元、页眉页脚/分页/目录等页面结构，还能适配不同文档格式的特征：Word文档抓取段落样式和大纲级别，PDF文档通过字体大小、粗细、缩进等视觉特征识别层级，HTML文档直接解析DOM节点层级，把整份文档的逻辑关系梳理得一清二楚，相当于给每个内容块都标好了“归属”，明确它属于哪个父级章节、哪个子小节。

按家谱切块还自带结构上下文buff

基于梳理好的家谱，M3DocDep不再按字数硬切，而是优先以每一个小节（比如1.1、1.2.1这类逻辑单元）作为基础块，如果单个小节内容过长超出模型处理上限，再结合递归切分、语义切分等策略二次拆分，完全避免把同一个小节的内容拆到不同块里。拆分后的每个块还会自动保留结构标识，比如生成{"chunk":"本系统支持7层安全防护措施……","section":"2.3 安全架构设计"}这样的带标签的块，不仅检索时可以结合结构权重做重排，还能直接给后续大模型提供结构上下文提示，无需额外调用大模型生成块的上下文说明，省去了额外的提示缓存成本，也比手动添加元数据高效得多。

结构化文档场景检索效果提升显著

在论文、企业技术报告、产品手册这类结构化文档的测试中，M3DocDep的检索准确率比传统按字数硬切、普通递归切分的方案提升了20%以上，完全避免了“同一个概念被拆成两个块导致回答不全”的问题。同时该方案可以和现有分块工具灵活组合：比如先用文档家谱解析出基础结构块，再对过长的块用递归字符分块器按512token、128重叠的参数二次切分，兼顾结构完整性和块大小适配性，不需要对现有RAG pipelines做大规模改造就能接入。目前该方案已开源，后续团队还在探索结合语义分块、自适应分块等策略，进一步适配非结构化文档的检索需求。