一家企业的法务岗让助手查一份采购合同里的付款条件，助手回答得很利索，末尾还附了一行出处，写着某份合同的第几条。同事照着提示去翻，那一页通篇没有付款条件的表述。换个问法再问一次，出处变成了另一份文件，内容依然对不上。

面对这种情况，常见的处理是要求助手必须标注来源，或者在提示词里叮嘱不要编造。要求本身没有错，效果却有限。来源如果由生成环节自行书写，它与答案之间就没有强制的对应关系。模型能够写出格式规整、看上去很像的出处，却未必指向真实存在的段落，句子越流畅，这种偏差越不容易被察觉。

出处对不上通常有四种成因。生成阶段把出处当成文本的一部分，由模型自己补全标题与条款编号；检索命中不足时，模型为了让回答显得完整，会拼出一个听起来合理的来源；片段与原文脱节，标注指向的是被切出的短句，脱离上下文之后语义已经变形；还有一种是版本错位，答案依据的是新版本，出处指向的却是几个月前的旧文件。四种成因的处理方式并不相同，混在一起就只能靠反复叮嘱。

出处改由检索结果携带

一种可行的做法是让出处由检索结果携带，而不是由生成环节书写。检索返回的每个片段带上结构化字段，包含文档ID、不可变版本ID、页码或章节位置、稳定的chunk ID或锚点，以及所引原文片段，生成阶段只能在这些候选之间做选择，不能新增。字符区间可以作为辅助定位保留，但不宜作为唯一依据，因为PDF解析、OCR识别或重新切片之后，字符偏移都可能发生变化，单独依赖它会产生定位漂移。候选用不上时，回答应当明确写出没有找到对应依据，而不是补一条看起来像的。这条限制看似削弱了回答的完整性，实际是把可核查性保住了。

答案与依据逐条对应

答案与依据的对应关系要逐条建立。一段回答里包含几个判断，就应当能对应到几条依据，而不是整段挂一个总的来源。个别结论如果找不到支撑片段，这部分内容应当被拆出来单独说明，或者干脆不给结论。逐条绑定会让回答变长，换来的是每个判断都能被复核，复核者不必再从整段文字里猜哪句话出自哪里。

逐条绑定之后还要校验支撑关系。出处真实存在，不代表它足以支持答案里的判断。系统应把回答拆成可核查的关键结论，逐条检查引用片段是否直接支持该结论；只能证明部分内容的，就不能把结论扩大，没有足够支撑的部分应降级为不确定或不回答。合同、制度等高风险场景还可以同时返回关键原文片段，方便人工复核。例如原文只写“付款方式另行协商”，回答却写成“合同规定三十天内付款”，出处确实指向那条条款，推论却仍然是假的。引用真实与引用支撑，是两件事。

引用要能对上版本

引用还需要做版本一致性校验。回答所依据的文档版本与标注出来的版本必须一致，并判断该版本是已被替代还是仍在生效。要识别失效，回答生成时应保存所引用的文档ID与版本ID；历史回答再次展示、复用或进入后续流程时，对照当前版本状态判断引用是否已经被替代，而不是只写一句原则。所引文档在回答之后被更新或下架的，历史回答应当标注依据已经变更，避免一个已经失效的出处被长期沿用。多个来源给出不同结论时，还要先判断来源的效力、版本与适用范围：一份已经废止、一份当前生效，二者并不是真正的并列冲突，只有多个同时有效且确实冲突的来源，才作为冲突呈现并转人工判断。把冲突摊开，比给出一个干净却经不起追问的答案更有用。

需要说明的是，通用模型或Agent平台通常都能返回引用片段与位置信息，但出处由谁校验、版本如何比对、没有依据时如何降级，仍需结合企业自身的文档管理规范来确定。

在青山不语AI工作室的企业AI Agent定制方案中，出处作为检索结果的结构化字段随片段返回，生成阶段只能在候选中选择，答案与依据逐条对应并校验引用片段是否直接支撑结论，引用版本与依据版本做一致性校验且记录文档ID与版本ID，文档更新之后历史引用会被标注为失效。

还需要说清的是，这套机制管的是可追溯，管不了内容对错。文档本身写错了，或者业务上对同一份文件的解释存在分歧，再准确的出处也只是把读者引向一份有争议的材料。文件效力与解释权属于业务部门与法务，助手这一侧负责不编造、能定位、标注冲突与时效。

验收可以用三个动作。挑一个知识库里确定没有对应材料的问题，看回答是老老实实说找不到，还是编出一条依据；挑一份长文档，让助手回答后按出处逐字核对，看位置是否精确到段落；再更新其中一份被引用过的文件，看历史回答有没有标注依据变更。三个动作不复杂，足以把可追溯性从一句话变成可检验的结果。

在我看来，可追溯性是一个容易被高估也容易被低估的指标。看上去标了出处就算完成，实际上从片段携带、逐条绑定到版本校验，每一环都可能断。企业在选AI定制服务时，可以问一个很具体的问题：答错的时候，能不能顺着引用一路找到原文。能找到，这套系统就有被纠正的机会；找不到，再流利的回答也无法进入正式流程。