记忆
精准检索
深入解析 Mopheus 记忆系统的多维作用域设计（资产/技术栈/项目/标签）、原生多语言全文检索引擎架构与优先级排序机制。
当企业知识库沉淀了成百上千条运维经验、故障排障手册与架构规约时，如何避免将无关记忆倾倒给智能体造成上下文污染，同时确保与当前任务强相关的先验经验准确召回？
Mopheus 记忆系统摒弃了单一维度的扁平文本搜索，设计了以多维实体作用域（Scoping）为强隔离边界、结合原生多语言加权全文检索（Full-Text Search）与两阶段渐进匹配的检索体系，实现确定性与高相关度的经验匹配。
作用域设计哲学：边界先于检索
在大模型上下文管理中，“少即是多，准优于全”。一个关于 MySQL 参数调优的卡片注入到 Oracle 数据库迁移任务中不仅是 Token 浪费，更可能诱导智能体给出错误的语法命令。
因此，Mopheus 遵循边界先于检索的原则：
- 正交隔离：不同实体（Asset、Project、Stack）之间构建确定性过滤墙，不相关实体的专有规格绝不串扰。
- 渐进匹配：从强约束实体逐步扩展到通用规约，形成有梯度的知识视界。
- 防幻觉保底：当特定作用域无匹配记录时，优雅退化至全局底座，绝不强行匹配相似但非同一系统的经验。
┌─────────────────────────────────────────────────────────────┐
│ 多维作用域与检索过滤漏斗 │
├─────────────────────────────────────────────────────────────┤
│ │
│ 任务触发 / 查询请求 (带 asset_id, db_type, project_id) │
│ │ │
│ ▼ │
│ [第一层: 强实体隔离] 筛选专属资产与指定项目卡片 │
│ │ │
│ ▼ │
│ [第二层: 技术栈对齐] 匹配对应 db_type, profile_id 环境 │
│ │ │
│ ▼ │
│ [第三层: 加权全文检索] 多语言 GIN 索引 + 两阶段分词匹配 │
│ │ │
│ ▼ │
│ [第四层: 优先级重排] 人类纠偏优先 > 作用域加权 > 置信度 │
│ │ │
│ ▼ │
│ 输出精确记忆候选集合 (用于构建 MEMORY.md 或 API 返回) │
│ │
└─────────────────────────────────────────────────────────────┘多维作用域维度分解
每条记忆在创建与蒸馏时，均支持绑定以下多维元数据属性：
| 作用域维度 | 字段名称 | 典型示例 | 作用与隔离策略 |
|---|---|---|---|
| 目标资产 | asset_id | uuid-prod-db-01 | 强隔离。该资产专属的 IP、端口、高危规约只对挂载该资产的任务生效，杜绝跨资产渗透。 |
| 所属项目 | project_id | uuid-proj-billing | 项目边界。限定在特定业务系统架构规范、依赖服务与业务逻辑范围。 |
| 技术栈类型 | db_type | oracle, postgresql, mysql, dm | 技术栈对齐。防止不同数据库引擎或框架之间的参数与语法冲突。 |
| 环境档案 | profile_id | prod, staging, dev | 环境分级。生产环境与测试环境采用不同的加锁限制与变更确认要求。 |
| 提单人/发起人 | user_id | uuid-user-dba-lead | 个性化偏好。沉淀针对特定工程师的工作习惯、输出格式与交互要求。 |
| 扩展标签 | context_tags | {"cloud": "aliyun", "arch": "arm64"} | 动态微标签。支持利用 JSONB 包含语法（@>）进行任意灵活维度的精细筛选。 |
资产专属事实 vs 全局通用事实
这是理解记忆下发与匹配的关键分水岭：
- 全局底座（L0: Global Baseline）：
context_tags->>'asset_id' IS NULL且context_tags->>'user_id' IS NULL。适用于整个工作区通用遵守的全局规约（如“容器内代码目录为只读挂载”、“API 错误码必须使用 errx 定义”）。 - 资产专属事实（Asset-specific Facts）：
context_tags->>'asset_id' = '<target_id>'。仅包含特定资产的专有配置（如某台 Oracle RAC 实例的SGA_MAX_SIZE=64G、某台主机的特定 SSH Jump 端口）。无论类型是environment_fact还是error_resolution，只要绑定了asset_id，非该资产相关的任务绝对不会召回。
检索引擎架构与三层执行计划
Mopheus 彻底剥离了外部向量模型与向量数据库插件依赖，采用PostgreSQL 原生多语言加权全文检索 + 作用域加权打分架构，实现亚毫秒级、免外部分词/嵌入服务的纯关系型检索链路。
┌───────────────────────────────┐
│ 检索输入 Query (报错信息/任务)│
└───────────────┬───────────────┘
│
┌───────────────┴───────────────┐
│ normalizeMemoryRetrievalPlan │
│ (提取错误码、作用域与检索词) │
└───────────────┬───────────────┘
│
┌──────────────────────┼──────────────────────┐
▼ ▼ ▼
[Layer 1: Global] [Layer 2: Exact] [Layer 3: Ranked]
全局环境事实/偏好 错误码精确包含匹配 原生多语言全文检索 (GIN)
(Zero Scope Binding) (context_tags 包含) (zhparser / english)
│ │ │
└──────────────────────┼──────────────────────┘
│
▼
[两阶段降级与作用域加权]
Phase 1 (严格 AND) ──► Phase 2 (降级 OR)
Score = ts_rank * scope_weight
│
▼
[最终去重排序 Top-K 结果]1. 三层执行计划（Execution Layers）
- Layer 1：全局底座层（Global）
若查询未显式限制类型，自动拉取未绑定任何资产与用户的environment_fact与preference作为兜底底座。 - Layer 2：精准错误码层（Exact）
从 Query 文本中通过正则自动提取标准化错误码（如ORA-01555、42P01、PLS-00302等）。若存在特异性错误码，直接通过 JSONB 包含语法匹配error_resolution卡片，精准秒级命中历史排查方案。 - Layer 3：加权全文检索层（Ranked）
针对自然语言描述、报错日志与技术方案，依托底层 GIN 倒排索引执行多语言全文相关度匹配。
2. 多语言加权与两阶段渐进式匹配
- 字段加权与分词（Field Weights）：
底表content_tsv字段通过数据库触发器维护：- A 权（标题 Title）：权重最高（1.0），确保标题中包含检索核心词的卡片优先浮现。
- B 权（正文 Content）：权重次之（0.4），兼顾详细技术步骤与日志关键词。
- 双分词解析器：同时支持中文词法解析器（
zhparser）与英文分词器（english），统一由plainto_tsquery生成查询语法。
- 两阶段渐进式匹配（Two-Phase Progressive Search）：
- Phase 1：严格 AND 模式（Strict AND）
要求检索词分词后的所有关键词必须全部出现在content_tsv中，使用ts_rank精确评分。 - Phase 2：阈值 OR 降级模式（Ranked OR Fallback）
若严格 AND 模式未能填满top-k配额，系统将检索短语切分为词组，以||拼接执行宽松匹配，并通过minRankedSimilarityThreshold >= 0.10硬性阈值截断无关弱匹配，防止低质量噪声涌入。
- Phase 1：严格 AND 模式（Strict AND）
- 三元组相似度兜底（Trigram Fallback）：
在未开启完整分词词典或全文检索不可用时，系统自动降级到基于pg_bigm或pg_trgm的模糊相似度扫描，确保系统高可用。
3. 动态作用域权重体系（Scope Weighting）
检索评分不仅取决于文本相关度（ts_rank），还受作用域契合度加权约束：
$$\text{Final Score} = \text{Text Similarity} \times \text{scope_weight}$$
其中 scope_weight 计算规则如下：
- 若卡片的
context_tags->>'profile_id'与当前查询环境完全匹配：加权系数为1.0（最高置信度）； - 若卡片的
context_tags->>'db_type'与当前技术栈完全匹配：加权系数为0.6； - 若卡片未绑定特定作用域（属于通用知识）：加权系数为
0.3。
该机制确保了与当前资产环境强相关的排障经验始终压过其他环境的相似记录。
优先级决断规则（Precedence Rules）
在打分排序的基础上，Mopheus 施加了严格的工程优先级调整规则：
- 人类专家纠偏（
human_correction）优先保证
在默认检索类型集合中，系统将human_correction与error_resolution、failure_scenario并列前置。人类工程师纠正后的知识享有最高呈现优先级，杜绝已被纠偏的错误思路重复出现。 - 专属资产优先于通用模板
针对具体asset_id的卡片，通过作用域强过滤与高权重系数直接压制通用模板。 - 验证次数与召回热度加权
occurrence_count（被工单验证确认的次数）与recall_hit_count（被智能体任务调用的热度）作为卡片可信度的长期考量指标。 - 版本取代淘汰
被新卡片通过--supersedes标记为已取代的旧版本卡片，或者被人工置为enabled = false的卡片，在常规检索中自动物理排除，防止过时指令误导执行。
动态检索 CLI 与运行时按需查询
除了在工单创建时自动构建 MEMORY.md 之外，智能体或人类工程师在任务执行过程中，如遇到未预料到的新异常，可随时使用 mop memory retrieve 命令进行动态检索：
# 1. 针对当前资产与数据库类型检索特定报错经验
mop memory retrieve "ORA-01555 snapshot too old" \
--asset-id "9b2c34a1-0000-0000-0000-000000000001" \
--db-type "oracle" \
--top-k 5
# 2. 检索当前项目中关于代码格式化与提交规范的约定
mop memory retrieve "Conventional Commits" \
--project-id "d3e4f5a6-0000-0000-0000-000000000002" \
--type "preference"
# 3. 基于扩展标签检索阿里云生产环境特有规约
mop memory retrieve "SLB 探针超时排查" \
--context-tags '{"env":"prod","cloud":"aliyun"}'该命令将输出匹配卡片的 ID、类型、标题、相对 OKF 路径、命中频次与最近出现时间。智能体可据此直接调阅对应的物理卡片内容。
零匹配安全兜底（Zero-Match Fallback）
在面对全新项目、冷启动资产或从未发生过的未知故障时，检索系统可能出现候选积分为零或完全无匹配记录的情况。
此时系统执行优雅兜底策略：
- 不拼凑、不产生语义幻觉：严禁为了“填满上下文”而拉取低相似度的无关知识。
- 保留工作区全局底座：仅向智能体下发 L0 全局通用规约，并在
MEMORY.md中清晰呈现通用知识基线。 - 引导探索与事后沉淀：提示智能体当前为未知探索场景，严格遵循通用排障原则逐步求证，并在任务完结后主动发起记忆蒸馏，为团队填补该领域的知识空白。