group_fqcd_jr/docs/23-记忆分层与画像设计.md

记忆分层与画像设计

目的：讲清短期／中期／长期／画像四层各自存在哪里、谁写、什么条件下向上提升、是否进画像。 全部基于底座已有的真实表，不是另起一套；每节末尾标注实现现状。

0. 一句话

短期（会话上下文）→ 中期（候选事实）→ 长期（稳定事实）→ 画像（决策依据）

逐层提高门槛，是为了让"随口一说"永远变不成画像结论； 三条路径（问卷／行为／对话）在画像层汇合，但按字段划分所有权，不互相覆盖。

1. 总览

层	存在哪里	装什么	谁写	提升门槛	进画像
短期	Redis 会话列表（设计）；conversation_message 表（现状只有存档）	当前会话最近的对话轮次	每次 run 追加	—	❌ 不进
中期	memory_unit + memory_evidence	从对话抽出的候选事实，带证据链	Worker 记忆抽取	evidence_count ≥ 2 或 confidence ≥ 0.90	✅ 过门槛后提升
长期	user_facts（is_critical 标关键事实）	已确认的稳定事实	由中期提升	由 user_facts 判定	✅ 唯一用途就是喂画像
画像	fin_customer_profile（当前）+ profile_snapshots（版本化，带 generation_basis）	整合三路来源的客户视图	画像组装服务	—	它就是画像

2. 三条路径在画像汇合

这是整套设计的核心结构。只有对话路径需要累积证据，另外两条是权威／客观数据，直接写：

对话消息 ──→ [短期] 会话上下文 ──→ Agent 用它理解指代（"它""那个"）
                  │
                  └─(run 完成，发 memory.extraction_requested 事件)
                          ↓
                    [中期] memory_unit + memory_evidence
                          │ 证据累积过门槛
                          ↓
                    [长期] user_facts
                          │
                          │            ┌── 问卷测评（权威）────┐
                          └──组装──────┤                      ├──→ [画像]
                                       └── 行为／流水（客观）──┘
                                                                    │
                                                        投顾 / 风控 / 客服

为什么问卷和行为不需要走前三层：它们是权威（问卷由客户答题、系统评分）与客观（交易记录无法自称）数据，不需要"多次出现才可信"这层保护；对话自述才有"记错、修饰、被引导"的风险。

3. 各层细节

3.1 短期：会话上下文

• 装什么：当前会话最近若干轮对话，用于解析指代与保持连贯。
• 怎么工作：run 开始时按 session_id 读出历史 → 与当前消息一起交给意图分类与回答生成；run 结束时把本轮追加进去。
• 生命周期：会话结束或长时间无活动即失效（方案 §2.2 给的是 TTL 30min、最长 24h、超 4096 token 截断旧消息）。
• 为什么不进画像：会话上下文是"他刚才说了什么"，不是"他是什么样的人"。把临时对话当画像会造成画像抖动。
• 实现现状：❌ 未实现。conversation_message 表存了全部消息、svc_conversation_session.message_count 只在计数，但没有任何"加载最近 N 条"的代码，run 时只拿到当前这一条消息。后果是多轮指代无法解析（问"那它风险高吗"无法知道"它"指谁）。

3.2 中期：候选事实

• 装什么：从对话里抽出的事实（风险偏好自述、投资期限、家庭情况、资产类别偏好等），每条都带证据。
• 怎么工作：
  • 写入：run 完成 → 发布 memory.extraction_requested → Worker 消费事件 → 调模型抽取 → 写 memory_unit，同时写一条 memory_evidence（含原文摘录，可回溯"这句话从哪来"）。
  • 读取：run 开始时 recall_memory 自动召回，recall_count 累加。
  • 演进：同一事实再次出现 → evidence_count 增加；出现相反证据 → conflict_count 增加（不直接覆盖，留冲突待判）。
• 生命周期：valid_from / valid_until；过期或长期无新证据即降级／失效（memory_lifecycle_service 负责级联失效）。
• 进画像的条件：evidence_count ≥ 2 或 confidence ≥ 0.90 —— 这条门槛就是"一次性说法不该成为画像结论"的落地方式。
• 实现现状：✅ 已实现并可验证。实测：客户说"我的风险偏好是稳健型，平时只买债券基金" → 抽出 preference:risk_level = 稳健型（置信 0.95）+ 1 条证据。
• ⚠️ 运维前提：抽取依赖常驻 Worker 消费 Outbox 事件。只起 API 服务不起 Worker，事件会一直堆在 pending，记忆永远不产生。

3.3 长期：稳定事实

• 装什么：经过证据累积确认的稳定事实，is_critical 标记其中对决策关键的那些（如风险偏好、投资期限）。
• 怎么工作：只由中期提升而来（不直接从对话写）；source_portal 记录事实来自哪个入口，source_episode_id 记录来自哪个会话片段。
• 为什么不直接从对话写：长期层是画像的输入，必须保证"这条结论经过验证"，否则画像会被一次性说法污染。
• 进画像：✅ 它的存在意义就是喂画像。
• 实现现状：❌ 表在（9 列），无生成代码，当前 0 行。

3.4 画像：决策依据

• 装什么：整合三路来源后的客户视图，是投顾、风控、客服共同读取的唯一客户数据入口。

• 怎么工作：画像组装服务按字段所有权写入 → fin_customer_profile 保存当前值 → 每次重建写一条 profile_snapshots（带 version、generation_basis、snapshot_hash、is_current），从而每次变化都可追溯。

• 字段所有权（关键：按字段切开，避免互相覆盖）：

  字段	唯一写入方	性质
  investor_type（C1–C5）	只有问卷测评	权威、合规硬约束
  total_asset、trading_frequency、behavior_score	交易／流水侧	客观行为
  preferred_asset_class、investment_horizon、risk_tags	记忆系统（经长期层）	软信息、需累积
  real_name、birth_date、occupation、mobile_masked、opened_at	注册／账户流程	身份

• 客户自述风险偏好放哪：放 risk_tags 并标注"客户自述"，不得写入 investor_type。 保留它的价值在于：当出现「问卷 C4 / 自述稳健 / 行为买 R4」三方不一致时，这种矛盾本身就是风控信号。

• 实现现状：❌ 两张表都在，无组装代码，当前 0 行。

4. 红线（必须由代码保证，不能只靠约定）

1. 适当性判定只认问卷。investor_type 只能由问卷写入，记忆与对话在任何情况下都不得修改它。客户在对话里说"我是激进型"不能让他买到 R5。
2. 风控与投顾只读画像，不直接读 memory_unit。否则同一条记忆会被多处按各自口径解释。
3. 每条画像字段都要能回答"凭什么"。写入时通过 generation_basis 记录依据来源。
4. 画像变更留版本，不原地覆盖 —— 风控复盘时需要"当时看到的是什么"。
5. 内部资料不进入面向客户的知识库（已按此处理：反洗钱手册 visibility=internal）。

5. 现状与缺口一览

环节	状态
对话 → 中期记忆（抽取 + 证据 + 可回溯）	✅ 已实现（依赖常驻 Worker）
中期 → 长期（证据累积与门槛）	❌ 待实现
长期 → 画像（组装 + 版本快照）	❌ 待实现
问卷 → 画像	❌ 待实现（注册问卷流程未做）
行为 → 画像	❌ 待实现（交易模块未做）
短期会话上下文	❌ 待实现（影响多轮指代）
画像 → 投顾 / 风控	❌ 待实现

建议顺序：先做「中期 → 长期 → 画像」这一段（现在就有记忆数据可验证），再接问卷与行为两路，最后接下游消费者。