309a051038
数据库与模型：新增多版迁移（章节证据快照、对话血缘、记忆事实/时间线 lineage 等），把「成稿 ↔ 对话/记忆」的溯源信息落到表结构里。 业务链路：会话与 WS、回忆录/故事流水线、记忆写入与 enrichment 等跟着接上线索与快照；新增章节证据快照与评测侧 EvalTraceService 等模块，方便组评审用的证据包。 内部评测：自动化 run 与手工 memoir 评审共用可追溯证据；rubric/ judge 相关脚本与文档有配套调整。 app-eval-web：Memoir/实验详情里能展开看证据摘要与 evidence_trace（含对话轮次 id）；Vite 代理与 development.sh 注入的 API 端口与当前默认内部评测端口一致，避免改端口后页面连错服务。 工程杂项：GitHub Actions / 仓库说明有更新；各适配器与支付/配额/plan 等多处为小改动或跟随主改动的收尾；新增/扩充了?
42 lines
4.2 KiB
Markdown
42 lines
4.2 KiB
Markdown
# 回忆录可追溯证据（产品与内评口径）
|
||
|
||
本文与 PM、标注、工程共用：**旧库数据不要求为评测专门 backfill**；新写入走统一闭包与快照表。口径不清会导致反复对齐成本，变更 tier 规则时请同步改 `EvalTraceService._chapter_closure_tier` / Story 侧等价逻辑与本文。
|
||
|
||
## lineage_tier：strict / partial / fallback
|
||
|
||
| 档位 | 含义（章节） | 含义（故事，概要） |
|
||
|------|----------------|-------------------|
|
||
| **strict** | 既有可解析的访谈 **segment**（可绑定 transcript），又有从对应会话闭包得到的 **结构化记忆**（chunk / fact / timeline / summary 等任一非空）。 | Story 上以 `StoryEvidenceLink` 等为主链解析出 segment + 结构化记忆均存在。 |
|
||
| **partial** | 有可解析的 **segment / transcript 链**，但只有结构化记忆为空，或仅有结构化记忆而 **无** 可绑定的 segment（**与 PM/标注对齐：仅有结构化、无 transcript = partial**）。 | 能从章节 `source_segments` 等推导出一侧证据但闭包不完整。 |
|
||
| **fallback** | 无法从 artifact 构建足够闭包（例如无 segment 且无法走库内链路），评测侧 **显式** 降级为「最近若干会话」等粗粒度 transcript；须在结果 `notes` / `evidence_trace` 中可见，避免静默当 strict 用。 |
|
||
|
||
**说明**：`partial` 不是「质量差」，而是「血缘不完整仍可评审」；`fallback` 是「链路断裂时的保守降级」，评审 prompt 与 gate 解读需区别对待。
|
||
|
||
## 自动化评测：synthetic memoir vs library artifact（分表心理模型）
|
||
|
||
同一次 `eval_run` 里可能同时存在两类「回忆录」分数，语义不同，**勿混为一谈**：
|
||
|
||
- **Synthetic（replay 合成短文）**：由 case 的 replay 对话现场拼出的短 markdown，证据闭包仅为 **重放 transcript**，不绑定用户库里的 memory chunk / fact / timeline / summary。`judge_meta.synthetic_memoir_lineage_tier` 等为 `replay_transcript_only` 一类标记。
|
||
- **Library（库内章节 / 故事）**：真实 `Chapter` / `Story` artifact，使用 `EvalTraceService` 组装的 evidence bundle（含 `lineage_tier`、`evidence_trace`）。
|
||
|
||
聚合规则见 `judge_bundle_json.judge_meta.memoir_aggregate_rule`（例如合成与 library 均有分时的加权方式）。对 PM 汇报时请分项展示，避免只报一个「回忆录分」。
|
||
|
||
## 内评 JSON：`evidence_trace` 是否够用？
|
||
|
||
当前 `evidence_trace` 为 `ChapterEvidenceBundle` / `StoryEvidenceBundle` 的 **完整序列化**：含 `segment_ids`、`conversation_ids`、各类 memory id、`lineage_tier`、`notes`、`augmented_with_chapter_context` 等。**一般内审计够**：可按 id 去 DB 或日志反查。
|
||
|
||
若需 **按 artifact 类型展开为可点击深链 / 批量导出**，属于体验增强，可单独排期（eval-web 已支持章节级折叠展示 id 列表）。
|
||
|
||
## Phase C：`chapter_evidence_snapshots` 与 `chapter_evidence_links`
|
||
|
||
- **快照表**：一行对应一次物化闭包（`version_no` 递增）；`chapters.current_evidence_snapshot_id` 指向当前生效行。
|
||
- **链接表**：与 `StoryEvidenceLink` 对称，按快照刷新时 **整批替换** 章节侧结构化记忆 id，便于审计与扩展。
|
||
- **评测消费顺序**：`current_evidence_snapshot`（表）→ `evidence_bundle_json`（JSON 镜像，兼容）→ 现场用 `source_segments` 计算（与 live 不一致时 `notes` 提示）。
|
||
- **旧数据**：可不迁；新流水线写入会同时更新表与 JSON 镜像。
|
||
|
||
## 技术债（backlog，不阻塞发版）
|
||
|
||
1. **统一闭包计算**：生产快照与 `EvalTraceService` 已共用 `build_chapter_evidence_closure_payload_sync`；Story / 其它路径若仍有重复推导，应收敛到同一入口，避免双份实现漂移。
|
||
2. **扩展 memory trace**：除当前访谈检索外，其它入口若向模型喂 memory，评估是否同样写入 `memory_retrieval_trace_json`（或等价 trace），以便 partial / strict 判定与事后审计一致。
|
||
3. **canonical 与 `source_segments` union 冲突**：若线上冲突案例增多，再评估独立快照表外的「版本级 link」或更强约束；当前 Phase C 已降低仅依赖单列 JSON 的风险。
|