relations 是否需要回指消解？ADR-0016 遗漏的写入目标（issue #137 实现期发现）

KumaAgent commented

2026-08-17 05:03:15 +00:00

Member

来源

issue #137（回指消解 resolved_subject 落地）实现期留痕（ADR-0016 更新节，2026-08-17）发现的一处范围裁定，工单侧核实属实后按用户指示开票，交评估侧判断。

Problem Statement

ADR-0016（回指消解）拍板「复用 Delta 压缩同一次 LLM 调用产出 resolved_subject」时，枚举的写入目标是 profile facts / 事件记忆 / Knowledge 三类——全文（背景/决策/拒绝了/取代/备注）从未提到 relations。而 RelationshipEdgeCandidate（relationship.py，issue #36 / ADR-0008）结构上与 facts/events 同属「sender_id 型主体判定」写入目标，且比 ADR-0016 更早存在。核实结论是：ADR-0016 当初枚举既有写入目标时漏掉了这一个，不是权衡后的有意排除。

也就是说，relations 目前完全没有回指消解能力——用户说「那两个人昨天吵架了」这类只用代词/模糊指代提到关系双方的表达，RelationshipEdgeCandidate 解析不出具体是谁，这条关系边写入候选会怎样处理，目前没有 ADR 给出答案。

需要评估侧判断的开放问题

relations 要不要补回指消解？ 若不补，理由是什么（影响面小？关系边通常伴随明确的人名提及，模糊指代场景本就罕见？），需要在 ADR-0016 追加一条明确的「经评估后排除」更新节，把「从未提及」变成「评估过、有意不做」，避免以后又被当成遗漏重新发现。
若要补，怎么处理双主体位？ relations 有 user_a_id/user_b_id 两个主体位，不能照搬 facts/events 那种「单一 resolved_subject 字段 + fallback」的模式——ADR-0016 现有形状（resolved_subject: string | null，二元判断、不设置信度）是为单主体场景设计的。需要重新设计：是两个独立的 resolved_subject_a/resolved_subject_b？只消解「不确定的那一个、另一个已经明确」的情形？还是两个都模糊时整条候选直接丢弃（类比画像更新「主体解析失败即整条丢弃」的先例）？

证据

原文（docs/adr/0016-reference-resolution.md「更新（2026-08-17，issue #137 实现期）」节，issue #137 落地时的核实记录）：

relations 排除，本片显式声明为一处范围裁定：relations.user_a_id/user_b_id 结构上与……（a）本 ADR 决策节「按写入目标区别处理失败情形」从背景到决策通篇没有一次提到 relations——核实过 RelationshipEdgeCandidate 早于本 ADR 存在（issue #36，ADR-0008），本 ADR 枚举既有写入目标时漏掉了这个更早的写入目标，不是权衡后的有意排除；（b）relations 有两个主体位（user_a_id/user_b_id），……需要独立设计。

代码现状（relationship.py）：

class RelationshipEdgeCandidate:
    # DeltaCompressor 产出的关系边写入候选（写入前，无 id）
    user_a_id: str
    user_b_id: str
    label: str

两个主体位均为直接字段，无回指消解相关字段。

不在本票范围

具体实现（若评估侧决定要做，应转交工单侧按 PRD/决策拆片，本票只提出问题不预先设计方案）
event_id 半的回指消解（已由 #137 明确留给独立后续 ticket，与本票是两件不同的事，不要合并）

## 来源 issue #137（回指消解 `resolved_subject` 落地）实现期留痕（ADR-0016 更新节，2026-08-17）发现的一处范围裁定，工单侧核实属实后按用户指示开票，交评估侧判断。 ## Problem Statement ADR-0016（回指消解）拍板「复用 Delta 压缩同一次 LLM 调用产出 `resolved_subject`」时，枚举的写入目标是 profile facts / 事件记忆 / Knowledge 三类——**全文（背景/决策/拒绝了/取代/备注）从未提到 `relations`**。而 `RelationshipEdgeCandidate`（`relationship.py`，issue #36 / ADR-0008）结构上与 facts/events 同属「sender_id 型主体判定」写入目标，且**比 ADR-0016 更早存在**。核实结论是：ADR-0016 当初枚举既有写入目标时漏掉了这一个，**不是权衡后的有意排除**。也就是说，`relations` 目前完全没有回指消解能力——用户说「那两个人昨天吵架了」这类只用代词/模糊指代提到关系双方的表达，`RelationshipEdgeCandidate` 解析不出具体是谁，这条关系边写入候选会怎样处理，目前没有 ADR 给出答案。 ## 需要评估侧判断的开放问题 1. **`relations` 要不要补回指消解？** 若不补，理由是什么（影响面小？关系边通常伴随明确的人名提及，模糊指代场景本就罕见？），需要在 ADR-0016 追加一条明确的「经评估后排除」更新节，把「从未提及」变成「评估过、有意不做」，避免以后又被当成遗漏重新发现。 2. **若要补，怎么处理双主体位？** `relations` 有 `user_a_id`/`user_b_id` **两个**主体位，不能照搬 facts/events 那种「单一 `resolved_subject` 字段 + fallback」的模式——ADR-0016 现有形状（`resolved_subject: string | null`，二元判断、不设置信度）是为单主体场景设计的。需要重新设计：是两个独立的 `resolved_subject_a`/`resolved_subject_b`？只消解「不确定的那一个、另一个已经明确」的情形？还是两个都模糊时整条候选直接丢弃（类比画像更新「主体解析失败即整条丢弃」的先例）？ ## 证据原文（docs/adr/0016-reference-resolution.md「更新（2026-08-17，issue #137 实现期）」节，issue #137 落地时的核实记录）： > **`relations` 排除，本片显式声明为一处范围裁定**：`relations.user_a_id`/`user_b_id` 结构上与……（a）本 ADR 决策节「按写入目标区别处理失败情形」从背景到决策通篇没有一次提到 `relations`——核实过 `RelationshipEdgeCandidate` 早于本 ADR 存在（issue #36，ADR-0008），本 ADR 枚举既有写入目标时漏掉了这个更早的写入目标，不是权衡后的有意排除；（b）`relations` 有两个主体位（`user_a_id`/`user_b_id`），……需要独立设计。代码现状（`relationship.py`）： ```python class RelationshipEdgeCandidate: # DeltaCompressor 产出的关系边写入候选（写入前，无 id） user_a_id: str user_b_id: str label: str ``` 两个主体位均为直接字段，无回指消解相关字段。 ## 不在本票范围 - 具体实现（若评估侧决定要做，应转交工单侧按 PRD/决策拆片，本票只提出问题不预先设计方案） - event_id 半的回指消解（已由 #137 明确留给独立后续 ticket，与本票是两件不同的事，不要合并）

KumaAgent added the

状态：待评估

label

2026-08-17 05:03:59 +00:00

KumaAgent referenced this issue

2026-08-17 05:37:18 +00:00

relations 补回指消解——ADR-0016 遗漏的第四个写入目标（issue #144 拍板） #146

KumaAgent commented

2026-08-17 05:38:07 +00:00

Author

Member

2026-08-17（评估侧）：两个开放问题均已拍板。一、要补——现状 schema 里 user_a_id/user_b_id 都是必填非空字符串，模型遇到纯代词指代的关系陈述没有留待消解的余地，只能猜或不产出候选（还额外发现 prompt 里连 relations 都完全没提，比 facts/events 弱），这是真实的数据质量缺口，且复用同一次 LLM 调用成本很低。二、双主体位——两个独立 resolved_subject_a/b，任一未解析就整条候选丢弃（比照画像更新精神，不比照事件记忆的部分填：关系边没有半条边的概念）。决策已写入 ADR-0016「更新（2026-08-17，issue #144）」节，实现票见 #146。

KumaAgent closed this issue

2026-08-17 05:38:39 +00:00

KumaAgent referenced this issue

2026-08-17 08:40:17 +00:00

relations补回指消解——ADR-0016遗漏的第四个写入目标（issue #146） #148

Rows
Columns

relations 是否需要回指消解？ADR-0016 遗漏的写入目标（issue #137 实现期发现） #144

来源

Problem Statement

需要评估侧判断的开放问题

证据

不在本票范围