一份采购合同里写着，付款节点与违约责任详见附件三。员工向助手提问违约金的计算方式，得到的回答是资料中没有找到相关说明。打开合同原件可以看到，附件三确实随合同一并上传，内容里也写清了比例，只是助手没有把正文里的这句指向当成一条线索。
常见的处理方式是加大切片长度，或者换一个检索效果更好的嵌入模型，希望把附件内容拉进召回范围。排查之后却发现，附件本身能够被检索到，问题在于正文那一句详见附件与附件里的条款之间没有任何联系，系统不知道两者说的是同一件事。从表面看，这像是召回没有覆盖到，实际情况往往是文档在入库时就被拆成了互不相认的几块。
文档切片通常按长度或段落边界进行，正文与附件在被切分之后各自成为独立片段，指向关系随之消失。检索按语义相似度返回片段，一句详见附件三与用户问的违约金比例并不相似，自然排不进结果里。切片的本意是让片段更容易被检索，代价是文档的整体结构被拆散，指向关系恰好在拆散的过程中最容易丢失，把指向关系当成元数据保留下来，比单纯调大切片更接近问题本身。
附件在入库时往往被当成另一份文件处理，与正文各自拥有独立的标识。两者没有共同的文档标识与版本号时，即便附件被召回，系统也无法确认它是不是这一版合同的附件，更难把它与那句指向对应起来。版本信息缺失时，一句指向可能对应到好几个附件，系统只能凭相似度去猜，而这恰恰是最不该猜的地方。
章节编号在切片之后同样会失去层级。附件三第2条这样的位置信息，如果没有作为字段保存在片段上，引用就只剩下文字，无法定位到具体位置。反过来，如果把文档标识、附件编号与章节层级都作为可检索的字段随片段保存，指向关系就有了可以被还原的基础。层级不只要保存章节号，还要保留它在文档中的路径，附件三第2条与正文里的同类编号在文字上很难区分，路径才能说明它们各自的位置。
一种可行的做法是在解析阶段抽取正文里的引用表达，识别出详见、参见、依据这一类的词之后，关系记录应同时保存来源位置、关系类型与可唯一定位的目标位置；能够解析到具体章节时，不只绑定附件文件，还应进一步绑定目标章节或条款。检索命中带引用的片段时，系统按这条关系回查目标片段，一并放入上下文，而不是把引用句单独交给模型；关系回查不能绕过目标文档自身的访问控制，每次沿引用关系展开时都要重新检查当前用户对目标附件或章节的读取权限，无权访问时只返回“存在引用但当前不可访问”，不能把内容带入生成上下文。多层引用需要限制展开深度，并检测循环引用，避免 A→B→A 反复展开把整册附录都拉进上下文。
关系解析并不总能成功，指向模糊或者根本不存在的引用应被标注为待确认。当附件缺失或版本不一致时，系统更合适的做法是提示用户核对，而不是给出一个看上去完整的答案。
通用模型与文档处理平台通常具备较完整的解析与抽取能力，也能处理常见的附件结构，但引用关系的抽取粒度、附件与正文的绑定方式，以及多层引用的展开深度，仍需结合企业自身的文档习惯确定。
在青山不语AI工作室的AI定制方案中，文档按结构保真的方式解析，正文里的引用表达被抽取成关系记录；关系记录同时保存来源位置、关系类型与可唯一定位的目标锚点，能够解析到具体章节时进一步绑定目标条款，正文与附件则分别保留独立内容标识，同时绑定同一份合同或文件包标识，并记录附件编号、版本及引用关系，系统不依赖文件名或语义相似度猜测两者是否属于同一版本；章节层级作为片段字段保存，检索命中引用时按关系回查并入上下文，回查过程重新校验目标文档的读取权限，无权访问时仅返回引用存在提示而不带入内容，无法解析的引用进入待确认清单，由文档运营负责维护。
这套机制能还原文档内部写明的指向，却无法判断被指向的条款是否仍然有效，条款有没有被后续补充协议改过，仍然取决于企业自己的版本管理。
验收可以挑一份带附件的合同，先用正文里的原词提问，再用附件里的说法提问，观察两种问法是否都能定位到同一条款，随后删除一个附件，看系统是提示缺失还是继续作答。
在我看来，很多跨章节、跨附件检索问题，瓶颈首先出现在入库时是否保住了结构，而不只是模型或嵌入能力。
