 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 |
|
 wangjianlong_0626
|
8a0cbab636
|
fix(memory-projection): 订正 outbox 取值口径并接通画像投影链路
背景：memory_sync_outbox 这条链此前**完全没有消费者**，且生产端照 docs/00 §6.4.6
写成大写 MILVUS/NEO4J + 中文「待处理」，而消费端按 target_store 的**值**分派 handler、
且只领 status in {pending, failed} —— 两个条件都不满足，事件任何消费者都领不到、
永久滞留且不报错（唯一键 (event_uuid, target_store) 对大小写无约束，MySQL 也不报错）。
根因是代码与测试都硬编码字面量，所以测试跟着一起错、谁也没拦住。
订正
- profile_generation_service：取值改为全仓一致的小写（milvus/neo4j/upsert/pending）
- 测试改为引用常量并断言消费端契约，不再硬编码（硬编码是本次跑偏的直接原因）
- 新增契约回归测试：断言大写值分派不到 handler、会进死信，谁改回大写立刻红
- 新增 tools/normalize_memory_sync_outbox.py：订正历史脏行（默认 dry-run、幂等）
接通投影链路（此前零消费者）
- 新增 Milvus 集合 user_long_term_memory_v1 及建集合工具（幂等、不覆盖已有集合）
- 新增 MilvusProfileProjection / MilvusProfileVectorClient，并修掉移植带来的两处必炸点：
customer_id 由「必须 int」放宽为接受数字字符串（本仓所有生产者都写 str，
不放宽则每个事件必然失败）；不可投影的 memory_key 由「整批 raise」改为跳过留痕
（否则一条 constraint: 记忆毒死该客户整批，而受控词表 13 个键里有 7 个不满足前缀）
- 新增 MemorySyncOutboxWorker（领取/指数退避/死信骨架保留原样）并接入 WorkerRuntime
- milvus → 向量投影；neo4j → 复用主干 ProfileGraphProjectionService（方案 A，
不引入第二套投影，避免同一事实在图中两种说法、违反主干既有的只投影已确认事实的不变式）
- 生产端从 memory_unit(status=active) 组装 memory_sources，随事件带上确定快照
- 前置移植 conversation_privacy：写外部存储前脱敏手机号/证件号/银行卡等
验证
- 新增 17 个单测；全量 2 failed, 1307 passed, 2 skipped
（2 个失败为既有环境项：断言请求体中文原文而 httpx 序列化成 \uXXXX，非本次引入）
- mypy app → 0 错（227 文件）；audit_schema → 89 张业务表无缺失/意外，未改动表结构
- 真机：真实 embedding(1024 维) + 真实 Milvus 写入并回读通过
- 整合链路（测试记忆 → 生产端组装 → outbox → 消费端投递 → Milvus 回读）通过，
且 MySQL 已回滚、Milvus 无残留
文档
- 新增 docs/32-记忆投影链路实现说明.md：真实口径、根因、契约与验证证据（供接手）
- AGENTS.md：新增该易错点；新增 Windows 中文输出乱码的正确命令（-X utf8）；
校正测试基线与 mypy 文件数
未做：未改 docs/00 基线、未动数据库迁移、未改投顾线代码、未启动常驻 Worker。
遗留：投顾线两处生产者的 payload 缺 memory_sources，会被消费至死信，待架构师确认是否投影。
|
2026-09-12 10:45:40 +08:00 |
|