AI 生成内容怎样保留来源和引用链

AI 回答上线后，最容易丢掉的不是正文，而是“这句话从哪里来”。如果只保存最终文本，后续很难回答它引用了哪份资料、经过哪次检索、由哪个模型生成，以及人工改过哪些地方。实用做法是把内容生产拆成来源实体、处理活动和责任主体，再用稳定 ID 把它们连起来。

官方资料：https://www.w3.org/TR/prov-o/

W3C PROV 的核心正好适合这个问题：Entity 表示资料或生成物，Activity 表示检索、切片、生成、审核等活动，Agent 表示模型、服务或人工角色。本文不要求把业务系统改造成完整 RDF，而是先用一份可落地的 JSON 保留同样的关系。

一、先把来源、动作和责任主体拆开

先看一条最小链路：网页资料是来源实体，检索是活动，模型是代理，生成的草稿是新实体，人工编辑又是另一个活动。这样“草稿引用了来源”和“模型参与生成草稿”是两条不同关系，不能把所有信息塞进一个 source_url 字段。

在 PROV 语义里，wasDerivedFrom 表示一个实体由另一个实体派生，used 表示活动使用了某个实体，wasGeneratedBy 表示实体由某个活动产生，wasAttributedTo 则用于标记责任主体。它们组合起来，才能形成从原文到最终文章的引用链。

二、给每个节点稳定 ID，再保存派生关系

稳定 ID 不等于标题，也不等于数据库自增数字。来源可以用规范化 URL 加内容摘要生成，活动用一次任务的 request_id，生成物用版本号加内容哈希。这样同一来源被多次检索时可以复用实体，而同一篇文章重新生成时会产生新的生成物。

下面这份 JSON 是应用层记录，不是严格的 PROV-N 或 RDF 文档。字段名采用容易查询的写法，但关系含义与 PROV 的派生、使用、生成和归属关系对应。

{
  "entities": [
    {
      "id": "source:w3c-prov-o:sha256:ab12",
      "kind": "source",
      "url": "https://www.w3.org/TR/prov-o/",
      "captured_at": "2026-10-14T01:40:00+08:00",
      "content_sha256": "ab12..."
    },
    {
      "id": "draft:answer-001:v3",
      "kind": "generated_text",
      "content_sha256": "91ef...",
      "derived_from": ["source:w3c-prov-o:sha256:ab12"]
    }
  ],
  "activities": [
    {
      "id": "activity:retrieve-and-draft:8f31",
      "kind": "retrieval_generation",
      "used": ["source:w3c-prov-o:sha256:ab12"],
      "generated": ["draft:answer-001:v3"],
      "agent": "agent:model-service:answer-v2"
    }
  ]
}

注意两点：第一，captured_at 是系统保存来源的时间，不代表网页内容永远不变；第二，content_sha256 只用于识别版本，不能替代人工判断，也不能证明生成内容本身正确。

三、把检索和生成记录成一次可追踪活动

实际接入时，最容易漏掉的是“中间动作”。只保存最终 prompt 和答案，无法说明模型实际使用了哪些检索片段。建议每次生成都落一条 activity，至少包括输入实体 ID、输出实体 ID、模型标识、提示词模板版本、时间、操作者和错误状态。

package provenance

import (
    "crypto/sha256"
    "encoding/hex"
    "time"
)

type Activity struct {
    ID             string    `json:"id"`
    Kind           string    `json:"kind"`
    Used           []string  `json:"used"`
    Generated      []string  `json:"generated"`
    Agent          string    `json:"agent"`
    PromptVersion  string    `json:"prompt_version"`
    StartedAt      time.Time `json:"started_at"`
    FinishedAt     time.Time `json:"finished_at"`
    Status         string    `json:"status"`
}

func EntityID(prefix string, content []byte) string {
    // 用内容摘要区分同一来源的不同版本，避免把标题当成唯一键。
    sum := sha256.Sum256(content)
    return prefix + ":sha256:" + hex.EncodeToString(sum[:])
}

func NewActivity(id, agent, promptVersion string, used []string) Activity {
    // 创建活动时记录输入实体和代理；生成物在模型返回后再补入。
    return Activity{
        ID:            id,
        Kind:          "retrieval_generation",
        Used:          append([]string(nil), used...),
        Agent:         agent,
        PromptVersion: promptVersion,
        StartedAt:     time.Now().UTC(),
        Status:        "running",
    }
}

生产环境里不要把完整 prompt、用户原文或访问令牌无条件写进公共溯源表。可以保存模板版本、参数摘要和脱敏后的输入实体 ID；敏感原文放在受控存储中，通过权限和保留期限管理。

四、修订和断链状态要显式保存

人工修改后不要覆盖旧的生成物。新增一个 revision 实体，用 wasRevisionOf 或业务字段记录它与上一版本的关系；如果来源无法再次访问，也不要删除整条链，可以把实体状态标成 unavailable，保留 URL、抓取时间和摘要。

还要把“有引用链”和“内容正确”分开。溯源记录只能说明某段文字使用过哪些材料、经过哪些动作，不能自动证明引用没有断章取义。审核系统仍应单独保存事实核对结果、人工结论和拒绝原因。

可以用下面的最小清单做落地检查：

• 来源实体是否有稳定 ID、规范化地址、保存时间和内容摘要？
• 每次检索、生成、编辑是否都有独立 activity 和状态？
• 输出版本能否回指输入实体、模型代理和提示词版本？
• 失效来源、删除请求和脱敏动作是否有可查询记录？

常见问题

只保存引用 URL 够不够？

通常不够。URL 只能说明可能访问过哪个入口，还需要保存抓取时间、内容摘要、被使用的片段标识和生成活动 ID，才能定位“哪一版资料影响了哪一版输出”。

一定要引入 RDF 或图数据库吗？

不一定。先把 Entity、Activity、Agent 和关系落在 JSON 或关系表里，等到需要跨系统交换、复杂查询或与外部 PROV 数据互操作时，再映射到 PROV-O。

总结

AI 生成内容的来源和引用链，核心是把最终文本拆回“来源实体—检索/生成活动—模型或人工代理—新版本实体”。稳定 ID 负责连接，哈希负责识别版本，状态和修订记录负责面对现实中的失效来源与人工改写。先把这条链保存下来，后续再扩展到 RDF、图查询或审计系统，成本会小得多。