 lzf_0626
|
0c642133d4
|
修复长期记忆向量链路：投影入队 + 集合名三侧同源 + 召回按客户过滤
语义召回"恒空"的根因分四层，本提交修掉投递层与读取层（另两层——重试计数
门禁、episode 不投 rebuild 事件——已在前两个提交修复）。
R2 投递层：dispatch_profile_rebuild 只做图投影，没有任何 Milvus 投递，
长期记忆的向量从未被写入过（实测客户 9001 在 memory_sync_outbox 里 0 行）。
新增 _enqueue_memory_vector_projection()，在画像重建后投
MemorySyncOutbox(target_store="milvus")。走事件而不是同步写，是为了拿
Outbox 的重试/退避/死信，且不把 embedding 的网络等待拖进事务。
⚠️ payload 必须带 version（正整数）：适配器 _coerce_profile_version 缺它
直接抛 ValueError（实测踩到，事件立刻 failed）。
R4 读取层：写的集合与读的集合不是同一个 ——
写（MilvusProfileProjection）用 "user_long_term_memory_v1"，
读（bootstrap.get_vector_memory_adapter）与删（projection_cleanup_service）
却用 settings.milvus_collection = "jr_memory"，而该集合从未被创建。
⇒ 召回：MilvusClient 构造不校验集合存在，适配器"构造成功"但每次 search
抛异常被 VectorMemoryAdapter 吞成 degraded → 召回恒
degraded_reasons=('milvus_unavailable',)、向量命中恒 0 条；
⇒ 清理：jr_memory 不在集合列表 → 走 vector_collection_absent 分支 →
报清理成功但一个向量都没删，陈旧向量永久留存。
修法：PROFILE_COLLECTION 成为唯一常量，读/删两侧直接引用它；
并删除 Settings.milvus_collection 配置项、清掉 .env.example 的
MILVUS_COLLECTION —— 写侧从来没读过它，一个只在契约一侧生效的配置项
比没有配置项更危险（Settings 的 extra="ignore" 会让其他环境残留的该
变量被安全忽略）。
顺带：
- 语义检索把客户过滤下推到 Milvus（filter="customer_id == N"）。此前不带
过滤，别家客户的命中会白占 limit 名额，稀释本客户的召回条数。
- upsert 在 sources 为空时先返回，不再无条件 load_collection ——
"本来就没有可写内容"不该被记成投递失败（10001/10002 那两条事件即如此
重试 5 次进死信）。
回归守卫：tests/unit/infrastructure/test_memory_vector_collection_consistency.py
断言读侧与删侧用的都是 PROFILE_COLLECTION，且被删掉的配置项不得回归。
这个缺陷能活下来，正是因为两侧单测全绿而接缝无人守。
验证（走生产装配、进程内调用，未重启你正在跑的 API 窗口）：
读侧集合打印 user_long_term_memory_v1（修前为 jr_memory）；
召回 degraded=False / reasons=() / sources 含 milvus，且排序随 query 语义
变化（投资期限→horizon 0.288 > risk_level 0.201；风险偏好→risk_level 0.287）；
query="进取型" 双通道合并且 vector_score=0.9987；query=None 走 mysql 全量。
pytest tests/unit tests/contract → 1432 passed, 2 skipped, 1 failed
（唯一失败是同事正在改的投顾页面，与记忆链路无关）。
文档：docs/演示用/记忆召回恒空-根因与修复-2026-09-14.md（新增，四层根因+证据）、
docs/37-记忆投影链路实现说明.md（补集合名三侧契约）。
|
2026-09-14 21:26:03 +08:00 |
|
|
lzf_0626
|
d4836ed4df
|
feat: 装配投影删除客户端（记忆失效/销户清理图与向量），并修复画像字段残留
一、装配 projection_cleaner
新增 app/service/projection_cleanup_service.py，并在**组装层**（app/worker/__main__.py）
注入。此前该客户端一直未装配，清理链路只记录降级（skipped_no_client），实际后果是
**销户后图里仍留着偏好关系**——投顾仍能通过关系网络看到这个人。
清理策略是"以画像为准"而不是按标识直接删边：先删掉该记忆对应的长期事实，再重建画像，
最后用对账修复让图跟着画像收敛。这样即使一条记忆影响多条派生边也能删干净，不依赖
"记得它当初投影成了什么"。Milvus 侧按 memory_uuid 删除；集合不存在（语义召回未启用）
时视为无需清理，客户端不可用则如实报告未清理，绝不伪造成功。
放在组装层而不是 runtime 内部兜底：组件内部给默认实现会把"尚未装配"这一事实悄悄盖住，
而"未注入即显式降级并留痕"是 runtime 刻意保留的语义。最初的改法写成内部兜底，被 5 个
既有单测拦下——那些测试是对的，因此改为在入口处注入。
二、顺带修复：事实消失后画像字段残留
实测：让 preference:horizon 记忆失效并清理后，user_facts 与图边都正确清除，但
fin_customer_profile.investment_horizon 仍是"长期（5年以上）"。根因是 rebuild_profile
只写"本轮有新值"的字段；事实被删后该字段没有新值，旧值就留在画像里——于是记忆已经作废，
投顾还能看到一个客户从未授权继续生效的投资期限。
改为：本轮没有对应事实时**清空**该字段；investor_type 例外——问卷是唯一权威，本轮没有
问卷记录时保持原值（该列 NOT NULL，且清空会在重测空档抹掉开户时的等级）。
三、实测
· 让 preference:horizon 失效后清理：cleaned=True，
detail=profile_rebuilt; graph_cleaned; vector_collection_absent；
· user_facts 2→1；图边由 ['HAS_GOAL','PREFERS'] 变为 ['PREFERS']；
· 画像 investment_horizon 由"长期（5年以上）"变为 None；investor_type 保持 C2、
risk_tags 不受影响（与 horizon 无关）；
· 恢复记忆状态后重建，画像与图边均正确复原；
· ruff 通过、mypy 113 文件无错、unit+contract 447 passed、integration 29 passed。
|
2026-09-10 21:58:42 +08:00 |
|