回指消解resolved_subject落地(仅user_id半,event_id半明确留后续) #137

Closed
opened 2026-08-14 05:24:49 +00:00 by KumaAgent · 1 comment
Member

Parent

#103 第四批清单:31 条实现类落差 + 9 条待拍板(条目 23)

What to build

ADR-0016 拍板 Delta 压缩那一次 LLM 调用要顺带产出 resolved_subject(具体 user_id/event_id 或 null),复用同一次调用零新增成本——origin/main 全仓 resolved_subject 零命中。当前 prompt 不但没让模型尝试消解代词,反而只写了"认不出是谁的填 null,不要瞎猜",永远停在 fail-closed 的退化态,代词一律降级为丢信息。

失败处理侧(按写入目标区别处理 null)已经实现,本片只补"让模型去尝试"这个出口,不要动已经对的那半。

Acceptance criteria

  • _EXTRACT_MEMORIES_TOOLresolved_subject 出口(二元产物:具体 id 或 null,不得做成 0-1 置信度
  • _build_prompt 的 instruction 改写(不是追加)——现有"不要瞎猜是哪个 sender_id"与新的"请尝试消解代词"直接冲突,必须重写成"先尝试消解代词所指;不确定才填 null"的两段式,否则新字段会被旧措辞直接压死

原文(docs/adr/0016-reference-resolution.md「决策」节第 2 条):

复用同一次 LLM 调用,零新增调用:与 sensitivity 打标(fail-closed)、importance 打分、Knowledge 候选判断(ADR-0015)同一次 Delta 压缩 LLM 调用顺带产出 resolved_subject(具体 user_id/event_id 或 null)。

原文(同 ADR「决策」节第 1 条——范围边界,挡住"顺手把召回侧也做了"):

范围钉死写入侧:只管 Delta 压缩抽取 profile/事件/Knowledge 时的代词/模糊指代解析,不管读取/召回时的指代理解……不为此新造读时机制。

原文(同 ADR「决策」节第 3 条——形状约束,挡住"加个置信度"):

二元判断,不设数值置信度/阈值……null 本身就是 fail-closed 的触发信号(红线2)……不进阈值三层分类表(ADR-0011)。

  • 保持既有失败处理不变,写成回归断言而非新建:事件记忆参与者可部分填(_parse_event 已过滤 null);画像更新主体解析失败整条候选丢弃(_parse_candidatereturn None);Knowledge 影响面小不特殊处理——这三条已落地,本片不重写

原文(同 ADR「决策」节第 4 条):

按写入目标区别处理失败(null)情形(同一 fail-closed 原则,应用粒度不同,非两套规则):事件记忆参与者可部分填;画像更新主体解析失败则整条候选丢弃;Knowledge 影响面小。

  • events.py::EventRecord docstring 当前宣称"participant_ids 只含回指消解成功的参与者"——这句话目前描述的是不存在的机制,本片落地后改真
  • 本片只做 user_id 半。ADR 原文写的是"具体 user_id/event_id 或 null",但 EventCandidate/EventRecord 都没有指向既有事件的引用字段、_build_prompt 也不喂既有事件列表——做 event_id 半需要新增引用字段 + 把候选事件列表喂进 prompt + 新增一条读,体量远大于 user_id 半。event_id 半明确不在本片范围,留给后续 ticket(不要让它无声消失)
  • 测试须防空转:现有"LLM 没给 id 就丢弃"的路径会让"消解失败也丢弃"的断言在新旧实现下都成立,必须构造"模型给出了 resolved_subject 且它与既有 participants 不一致"这类只有新逻辑才走得到的用例
  • 测试覆盖:tests/test_delta_compressor.py(解析层主战场)、tests/test_delta_compression_cycle.py

Blocked by

  • #134 — Knowledge差异化合并升级为同轮LLM融合——两片都要往同一个 _EXTRACT_MEMORIES_TOOL schema 与同一段 Delta 压缩 instruction 字符串加字段,并行改会冲突,需串行
## Parent #103 第四批清单:31 条实现类落差 + 9 条待拍板(条目 23) ## What to build ADR-0016 拍板 Delta 压缩那一次 LLM 调用要顺带产出 `resolved_subject`(具体 user_id/event_id 或 null),复用同一次调用零新增成本——origin/main 全仓 `resolved_subject` 零命中。当前 prompt 不但没让模型尝试消解代词,反而只写了"认不出是谁的填 null,不要瞎猜",永远停在 fail-closed 的退化态,代词一律降级为丢信息。 失败处理侧(按写入目标区别处理 null)**已经实现**,本片只补"让模型去尝试"这个出口,不要动已经对的那半。 ## Acceptance criteria - [ ] `_EXTRACT_MEMORIES_TOOL` 加 `resolved_subject` 出口(二元产物:具体 id 或 null,**不得做成 0-1 置信度**) - [ ] `_build_prompt` 的 instruction **改写**(不是追加)——现有"不要瞎猜是哪个 sender_id"与新的"请尝试消解代词"直接冲突,必须重写成"先尝试消解代词所指;不确定才填 null"的两段式,否则新字段会被旧措辞直接压死 原文(docs/adr/0016-reference-resolution.md「决策」节第 2 条): > **复用同一次 LLM 调用,零新增调用**:与 sensitivity 打标(fail-closed)、`importance` 打分、Knowledge 候选判断(ADR-0015)**同一次 Delta 压缩 LLM 调用**顺带产出 `resolved_subject`(具体 user_id/event_id 或 `null`)。 原文(同 ADR「决策」节第 1 条——范围边界,挡住"顺手把召回侧也做了"): > **范围钉死写入侧**:只管 Delta 压缩抽取 profile/事件/Knowledge 时的代词/模糊指代解析,**不管读取/召回时的指代理解**……不为此新造读时机制。 原文(同 ADR「决策」节第 3 条——形状约束,挡住"加个置信度"): > **二元判断,不设数值置信度/阈值**……`null` 本身就是 fail-closed 的触发信号(红线2)……**不进阈值三层分类表**(ADR-0011)。 - [ ] **保持既有失败处理不变,写成回归断言而非新建**:事件记忆参与者可部分填(`_parse_event` 已过滤 null);画像更新主体解析失败整条候选丢弃(`_parse_candidate` 已 `return None`);Knowledge 影响面小不特殊处理——这三条已落地,本片不重写 原文(同 ADR「决策」节第 4 条): > **按写入目标区别处理失败(`null`)情形**(同一 fail-closed 原则,应用粒度不同,非两套规则):事件记忆参与者可部分填;画像更新主体解析失败则整条候选丢弃;Knowledge 影响面小。 - [ ] `events.py::EventRecord` docstring 当前宣称"`participant_ids` 只含回指消解成功的参与者"——这句话目前描述的是不存在的机制,本片落地后改真 - [ ] **本片只做 user_id 半**。ADR 原文写的是"具体 user_id/**event_id** 或 null",但 `EventCandidate`/`EventRecord` 都没有指向既有事件的引用字段、`_build_prompt` 也不喂既有事件列表——做 event_id 半需要新增引用字段 + 把候选事件列表喂进 prompt + 新增一条读,体量远大于 user_id 半。**event_id 半明确不在本片范围**,留给后续 ticket(不要让它无声消失) - [ ] 测试须防空转:现有"LLM 没给 id 就丢弃"的路径会让"消解失败也丢弃"的断言在新旧实现下都成立,必须构造"模型给出了 `resolved_subject` 且它与既有 `participants` 不一致"这类只有新逻辑才走得到的用例 - [ ] 测试覆盖:`tests/test_delta_compressor.py`(解析层主战场)、`tests/test_delta_compression_cycle.py` ## Blocked by - #134 — Knowledge差异化合并升级为同轮LLM融合——两片都要往同一个 `_EXTRACT_MEMORIES_TOOL` schema 与同一段 Delta 压缩 instruction 字符串加字段,并行改会冲突,需串行
Author
Member

实现期留痕:本片只落地 resolved_subject 的 user_id 半(画像 scope_id / 事件 participant_ids),有两处范围裁定需要显式记录,供后续评估参考:

  1. relations 不在本片范围relations.user_a_id/user_b_id 结构上与 facts.scope_id/events.participants 同属 sender_id 型主体判定,理论上有同样的代词消解需求。但核实后发现 ADR-0016 全文(背景/决策/拒绝了/取代/备注)从未提到 relations——而 RelationshipEdgeCandidate 其实早于 ADR-0016 存在(issue #36,ADR-0008),本 ADR 枚举既有写入目标时漏掉了这个更早的写入目标,不是权衡后的有意排除。另外 relations 有两个主体位(user_a_id/user_b_id),直接照搬 facts 单字段 fallback 模式不成立,需要独立设计。本片不处理,留给后续单独评估。

  2. event_id 半留后续,已在 ADR-0016 补的更新节里留两条面包屑(不只是"延后"):

    • _build_prompt 目前只喂"已知画像"/"已知话题记忆"两类上下文,没有"已知事件"——做 event_id 半第一步要先补一条 current_events-style 参数。
    • EventCandidate/EventRecord 目前没有任何"关联到既有事件"的字段或合并语义(不像 Knowledge 的 target_id),event_id 消解出来后该怎么落库是独立于本片的设计问题。

另外 events 侧 resolved_subject 是标量、一次只能消解一个模糊指代——同一事件候选里如果有两个及以上不同的模糊指代都能分别消解到不同的人,只有一个会被捕获,其余仍随 null 略过。这是已知局限(fail-closed,漏报不误报),已记入 ADR-0016 更新节与 delta.py::_parse_event 的代码注释,不在本片修复范围。

详见 ADR-0016 更新节(2026-08-17,issue #137 实现期)。

实现期留痕:本片只落地 resolved_subject 的 user_id 半(画像 scope_id / 事件 participant_ids),有两处范围裁定需要显式记录,供后续评估参考: 1. **relations 不在本片范围**:`relations.user_a_id`/`user_b_id` 结构上与 `facts.scope_id`/`events.participants` 同属 sender_id 型主体判定,理论上有同样的代词消解需求。但核实后发现 ADR-0016 全文(背景/决策/拒绝了/取代/备注)从未提到 `relations`——而 `RelationshipEdgeCandidate` 其实早于 ADR-0016 存在(issue #36,ADR-0008),本 ADR 枚举既有写入目标时漏掉了这个更早的写入目标,不是权衡后的有意排除。另外 relations 有两个主体位(`user_a_id`/`user_b_id`),直接照搬 facts 单字段 fallback 模式不成立,需要独立设计。本片不处理,留给后续单独评估。 2. **event_id 半留后续**,已在 ADR-0016 补的更新节里留两条面包屑(不只是"延后"): - `_build_prompt` 目前只喂"已知画像"/"已知话题记忆"两类上下文,没有"已知事件"——做 event_id 半第一步要先补一条 `current_events`-style 参数。 - `EventCandidate`/`EventRecord` 目前没有任何"关联到既有事件"的字段或合并语义(不像 Knowledge 的 `target_id`),event_id 消解出来后该怎么落库是独立于本片的设计问题。 另外 events 侧 `resolved_subject` 是标量、一次只能消解一个模糊指代——同一事件候选里如果有两个及以上不同的模糊指代都能分别消解到不同的人,只有一个会被捕获,其余仍随 null 略过。这是已知局限(fail-closed,漏报不误报),已记入 ADR-0016 更新节与 `delta.py::_parse_event` 的代码注释,不在本片修复范围。 详见 ADR-0016 更新节(2026-08-17,issue #137 实现期)。
Yushu closed this issue 2026-08-17 05:26:29 +00:00
Sign in to join this conversation.
No milestone
No project
No assignees
1 participant
Notifications
Due date
The due date is invalid or out of range. Please use the format "yyyy-mm-dd".

No due date set.

Dependencies

No dependencies set.

Reference
ProjectKuma/arise#137
No description provided.