为什么 doc_id 不够version 与 checksum 才是企业 AI 证据链的硬地基在 RAG 或企业知识库系统里我们很容易把doc_id当成引用来源。比如 Agent 给出一个建议依据发布文档建议按回滚步骤恢复 Redis timeout 配置。然后系统附上doc_id release-payment这看起来已经有 citation 了但在企业 AI 场景里这还不够。doc_id只能说明“来自哪份文档”。它不能说明这段内容来自哪个版本、哪个标题、哪一页、哪一段也不能证明后来复核时看到的内容和 Agent 当时看到的是同一份。这就是 Day 12 里真正重要的点version 解决时间一致性问题。 checksum 解决内容一致性问题。citation 和 trace 不是一回事citation面向读者和审核人。它要解决的问题是我能不能回到原文看到 Agent 引用的是哪句话、哪一段、哪个章节。trace面向系统审计。它要解决的问题是这次检索、过滤、证据使用和判断过程是否可以复盘当时使用的文档是否正确证据是否越界后来文档变化后能不能解释当时为什么这样判断。所以一条可审计的 evidence 不能只存content和doc_id还需要保存来源追溯字段。source_path证明来自哪里source_path说明 chunk 来自哪个文件或文档路径。在 citation 里它让人知道去哪里找原文。在 trace 里它让系统判断这次召回是否来自正确的知识域、项目、服务或资料目录。例如用户问的是支付回调超时trace 里却出现source_path resumes/candidate-a.pdf这说明发生了错召回。语义上“支付系统经验”可能和“支付回调”相关但业务上下文完全不同。heading_path证明在什么语义位置同一句话出现在不同章节下证据含义会不同。例如恢复 Redis timeout 到 5s如果它位于heading_path Rollback Plan Redis Config它可能是可执行前的回滚参考。如果它位于heading_path Historical Incident 2025 Review它更可能只是历史复盘里的经验不应该直接变成当前操作建议。heading_path的价值在于它不只定位文本还补充了文本所在的语义语境。page / offset证明具体引用了哪里page_number、paragraph_index、start_offset、end_offset解决的是精确定位问题。PDF 文档可以用页码和段落索引。Markdown 或纯文本可以用标题路径、段落索引、字符 offset。没有这些字段citation 只能说“这份文档里有相关内容”但不能说明具体是哪一段。审核人复核时需要重新搜索整份文档成本高也容易误读。对 trace 来说offset 还有另一个作用证明当时进入模型上下文的 chunk 不是被随意拼接、改写或截断后的内容。它让系统能够回放“当时使用的是原文中的哪个范围”。version解决时间一致性企业文档会更新。发布文档、需求文档、事故复盘、权限规则、SOP 都可能在事后被修改。如果 trace 里没有version复盘时就会出现一个严重问题你不知道 Agent 当时引用的是哪一版规则、哪一版发布文档、哪一版需求。例如2026-06-01发布文档 v1.3.0 写着 Redis timeout 可以回滚到 5s 2026-06-10Agent 基于这份文档建议人工确认后回滚 2026-06-20文档更新为 v1.3.1回滚策略被改掉 2026-06-25事故复盘时追问 Agent 当时为什么建议回滚如果 trace 只有source_path release/payment.md就解释不清。如果 trace 有doc_version v1.3.0 retrieved_at 2026-06-10 14:21就能说明Agent 当时基于 v1.3.0 的文档状态做判断。后来文档变更不能反过来证明当时的判断一定错误。所以version解决的是时间一致性问题。它回答的是Agent 当时依据的是哪一个历史状态checksum解决内容一致性checksum解决的是另一类问题同一个路径、同一个版本名下内容有没有被改过。很多团队的文档版本管理并不严格。有人可能直接修改原文件但没有更新版本号。也可能一个页面 URL 没变但内容已经被重写。如果没有checksumcitation 仍然能指向同一路径但 trace 无法证明“现在复核看到的内容”和“Agent 当时看到的内容”是同一份。更可靠的 trace 应该保存content_checksum sha256:abc...复盘时如果 checksum 对不上系统就应该提示证据源内容已变化需要重新评估当时结论。所以checksum解决的是内容一致性问题。它回答的是Agent 当时看到的那份内容后来有没有被换掉一个可用的 chunk schema v0.1企业 AI 里的 chunk 不应该只是文本片段。它至少应该包含四组字段content: - chunk_id - doc_id - content - summary provenance: - source_uri - source_path - heading_path - page_number - paragraph_index - start_offset - end_offset - doc_version - retrieved_at - content_checksum governance: - domain - role - visibility - lifecycle_status - updated_at - effective_from - effective_to evidence_relation: - evidence_relation: primary_evidence | supporting_evidence | weak_reference - target_judgment - supported_judgment - unsupported_judgment - expansion_reason这里的关键不是字段多而是职责清楚。content负责进入模型上下文。provenance负责回到原文。governance负责权限、时效和生命周期控制。evidence_relation负责说明这段 chunk 在某次判断里到底扮演什么证据角色。citation 让人找到原文trace 让系统解释判断可以把最终结论压成一句话citation 让人找到原文trace 让系统解释为什么这段原文能参与这次判断。因此doc_id只是开始。如果没有source_path不知道来自哪个具体来源。如果没有heading_path不知道处于什么语义章节。如果没有page / offset无法精确定位原文。如果没有version无法解释历史判断。如果没有checksum无法证明内容没有被换掉。普通问答系统可以满足于“看起来有引用”。企业 AI 不行。企业 AI 的证据链必须能经得起复盘、追责、审计和重新评估。这就是为什么一个看起来很小的字段设计问题实际上会决定整个 Role Copilot 是否可信。