问题级证据链应该包含哪些字段？一套可复核的数据结构

生成式AI推荐监测要做到可复核，证据链必须落到问题级。一个汇总指标只能告诉使用者“发生了什么”，问题级证据链还要回答：在什么范围内问了什么，哪个平台何时返回了什么，系统依据哪段原文识别品牌、判定候选或推荐，使用了哪套规则，最终报告引用了哪一版结果。

这套结构的核心是把原始事实、派生判断和交付快照分开保存。原始回答冻结，判断可以按版本重算，报告则引用一次确定的快照。三层混在一张宽表里，短期开发简单，后续审计、修订和跨期比较都会变得困难。

证据链从检测范围开始

同一道问题在不同品类、地区、对象层级和目标人群下，含义可能不同。证据链的第一环不是回答，而是scope_snapshot。它固定本次检测对象的规范名称、别名、实体层级、品类、地区、受众和业务场景，并记录版本与哈希。

scope_snapshot_id -> entity_id + entity_level + aliases + category + region + audience + scope_hash

范围被修改后，应生成新快照，旧任务继续指向旧快照。不要在项目主表上直接更新名称或品类后，让历史回答自动采用新含义。历史证据只有绑定当时的范围，才能解释当时的结论。

七组字段构成最小闭环

字段不必都放在同一张表中。上表描述的是逻辑闭环。实际实现可以按查询频率拆表，并通过稳定ID连接。最重要的是任何报告结论都能沿着ID返回问题、回答和判定片段。

问题记录必须版本化

question_id表示问题的稳定身份，question_version表示某一次不可变文本。修正一个标点可能不改变语义，但替换地区、对象层级或购买条件会改变候选集合。为了避免程序猜测哪些修改重要，最稳妥的方案是文本发生变化就创建新版本，并在上层通过semantic_group_id连接同一意图。

问题记录还应保存intent、decision_stage和constraints。它们帮助系统判断这道题是否适合计算候选或推荐，也支持按认知、比较、购买和风险等意图聚合。问题文字本身仍是事实源，结构化标签只是辅助。

执行记录要把失败与品牌表现分开

run_id对应一次具体调用。status至少区分queued、running、succeeded、empty_response、provider_failed和parse_failed，并保存开始时间、完成时间与可公开的错误分类。模型未返回有效回答时，系统没有观察到品牌表现，不能把它记成“未提及”或“未推荐”。

重试应创建新的attempt或run记录，并保留parent_run_id。直接覆盖失败记录会让成功率、耗时和重试成本失真，也无法解释同一道问题为什么出现多个回答。

原始回答应冻结并计算哈希

answer_text保存模型实际返回的完整正文。若响应还包含来源区、引用卡片或结构化字段，应按原始边界分别保存，并保留raw_payload的受控存档。进入判断流程前，对规范化后的回答计算answer_hash。

answer_hash = SHA256(canonical_answer_payload)

canonical_answer_payload必须有稳定规则，例如统一换行、固定JSON键顺序，但不能修改正文语义。后续展示可以清理格式，证据判断仍指向冻结原文。若回答需要修订，应生成新版本或补充记录，不应静默覆盖。

证据片段要保存位置而不是模型概括

系统判定品牌被提及、进入候选或得到推荐时，应保存原文跨度。span通常包含start_offset、end_offset、quote_hash和span_role。quote用于展示，offset用于程序校验，quote_hash用于防止正文改变后仍沿用旧证据。

EvidenceSpan = answer_id + start_offset + end_offset + quote_hash + role

模型重新概括的理由不能替代原文证据。概括适合帮助读者理解，却可能增加原文没有的因果或评价。判定记录可以另存reason_summary，但必须同时指向一个或多个原文跨度。

实体记录不能只靠品牌字符串

同一个名称可能指向公司、品牌、产品或服务。entity_id应连接规范实体，matched_alias只记录这次命中的表面文字，resolution_status区分resolved、ambiguous和conflict。上下级实体关系可以用于消歧，却不能自动传递能力或评价。

例如回答提到母公司，不代表旗下每个产品都被提及；提到某款产品，也不能自动算作公司全部业务得到推荐。证据链应保存实际出现的实体层级，并把任何聚合规则显式版本化。

判断结果需要独立版本

同一份回答可以随着解析器改进获得新的判断，因此judgment不应直接写回answer。判定记录需要parser_version、classifier_version和policy_version，并保存created_at与supersedes_id。旧判断保持只读，新判断通过版本关系声明替代范围。

后端在保存前要做闭包校验：entity_id必须存在；所有span必须位于同一answer_id的文本范围内；quote_hash必须与原文一致；推荐理由不能绑定到未进入候选的实体；条件推荐必须存在condition span或明确的结构化条件。

报告快照保证多个出口一致

报告生成时，应冻结scope_snapshot_id、question_version集合、有效run集合、judgment_version集合、指标公式版本和生成时间。线上详情、分享页面和导出文件都读取同一report_snapshot。这样可以避免页面实时重算后与已下载报告出现不同数字。

report_snapshot_hash = SHA256(scope + questions + runs + judgments + metric_policy)

修订报告时生成新快照，并记录修订原因。新快照可以成为当前版本，旧快照仍用于追溯。真正可复核的系统允许解释数字为什么变，而不是只保证页面现在看起来一致。

关系型结构与对象存储怎样配合

关系数据库适合保存ID、状态、版本、实体关系、证据跨度和聚合索引；完整回答与原始响应可以放在受控对象存储中，数据库保存object_key、hash、大小和内容类型。短回答也可以直接存数据库，但仍应保持answer与judgment分离。

· scope_snapshots保存不可变检测范围。

· question_versions保存问题文本和语义标签。

· generation_runs保存执行、重试与技术状态。

· answer_artifacts保存回答引用、哈希和存储位置。

· entity_judgments与evidence_spans保存可重算判断。

· report_snapshots与snapshot_items保存交付时采用的版本集合。

长文本不要在多个判断行中重复复制。通过answer_id引用原文，既能控制存储，也能保证所有判断面对同一事实源。查询页面可以按需加载完整回答，列表页只读取摘要和状态。

安全与隐私字段也属于证据链

系统应记录数据保留等级、访问组织、加密状态和删除计划。若问题或回答可能包含个人信息、商业秘密或受限制材料，应在进入模型前做范围控制，在存储后做权限隔离。日志只记录固定错误码和ID，不应重复打印完整问题、回答或上传资料。

删除请求也需要可审计。可以删除受保护正文，同时保留不可逆哈希、删除时间和执行状态，用于证明记录已处理。不能为了审计而无限期保留本应删除的敏感内容。

上线前做确定性完整性检查

这些检查应由程序执行，不依赖模型自报正确。模型负责语义判断，后端负责ID真实性、哈希、文本跨度、权限和版本闭包。职责分开后，语义能力可以升级，证据可靠性不会随模型输出格式一起波动。

结语

可复核的问题级证据链，应从冻结范围和问题版本开始，经过可追踪的执行记录与完整回答，再连接实体、候选、推荐、理由和条件的原文跨度，最后进入版本明确的报告快照。字段数量不是目标，闭环才是目标：任何对外结论都能回到事实源，任何算法升级都能重算，任何历史报告都不会被悄悄改写。