企业官网建设流程全解析

为什么 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 是否可信。