为什么 doc_id 不够：version 与 checksum 才是企业 AI 证据链的硬地基
为什么 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-10：Agent 基于这份文档建议人工确认后回滚 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 没变，但内容已经被重写。
如果没有checksum，citation 仍然能指向同一路径，但 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 是否可信。