Files
HomeAgent/docs/zh/recall-capability-tiers.md
JianFeeeee cf14b840ef docs: 补齐文档状态分类 + 校正两轮代码改动后的失真
## 背景

上一次文档校订(b9b5ac0)之后又有两次代码提交(5194a96 / 8293282),
把 future-plan §1.1 整节变成了错的 —— 它还写着「档位没有生效点」
和「在 prepareInputTask 里加一次 activateSecurityProfile 调用」,
而后者正是被后来的收敛**否定掉的方案**。

## 新增 docs/zh/README.md(文档索引)

32 篇文档此前混着三种时态(当时实测 / 历史推演 / 设计规划),外观相同。
索引给出**状态分类与可信度规则**:

| 状态 | 能不能当事实用 |
|---|---|
| 已实现并部署 | ✅ 直接信 |
| 部分实现 | ⚠️ 只信标了"生效"的部分 |
| 设计 / 未实现 | ❌ 只能当设计意图 |
| 归档说明 | ❌ 不要改、也不要信 |

并写死**判据名可信度规则**:文档里的 `TestXxx` 不保证还存在。
给了核对命令,以及当前基线(27 条缺失的分布 —— 18 条属"设计未实现"类
文档的规划名、7 条是 §2.7.3 有意保留的历史对照表左栏、2 条属视频能力
未纳入契约)。判定标准:**在"已实现"类文档正文里找不到才是缺陷**。

## 重写 future-plan §1.1(已结案)

原节写的是错的方案。改成记录**真正的缺陷分三层**:

```
第 3 层(表面):activateSecurityProfile 零调用方
第 2 层:agent/core 在替 security 做策略决策
         (自己抠 security_profile / 自己选判定链 /
           自己写 Kind:"resident" 声明主体类别 —— 提权口子)
第 1 层(根因):security 缺少「输入接入点」
```

并补上「每 agent 一个实例」的最终形态(共享注册表 + per-agent 执行视图,
sessionProfile / longtimeProfile 两层,优先级 session > longtime 本身是安全语义)。

§〇「机制 ≠ 接线」表格里档位那一条从 🔴 改为 ✅。

## 各文档状态行

此前 14 篇缺状态行(runbook / 实测报告 / 计划类)。逐篇补上**符合实际内容**
的声明,而不是统一套一句。特别地:

- `commondev-design.md` 标题本就写「设计 · 未实现」→ 归到"设计"类
- `live-run-evidence-2026-10-04.md` → 明确标注"历史证据快照,不要用它的
  结论覆盖现在的实现判断"
- `legacy-issues.md` → 写明它与 future-plan 的分工(前者收已知问题,
  后者收能力缺失与零调用方)

## 正文里两处判据名漂移

- `TestBootCtxCloseAllIsReverseOrder` → 实际是
  `TestKernelStateCloseAllIsReverseOrder`(`BootCtx` 改名时判据跟着改的)
- `TestNilTypedBusSafety` → 标注为"规划名,仓库中不存在"

## 新增 §2.7.5 模块产物的实例化粒度

依赖图保证"设施已就绪",但没说该有几个实例 —— 这是独立决策。
记下 security 的两个答案:全局基线共享(否则插件声明对部分 agent 不生效)、
轮次状态 per-agent。并给出给未来新模块的两条判断标准。

## 安全文档

状态头补「架构形态」段(防火墙定位、per-agent 视图、两层档位);
接线状态表里 `ActivateProfile` 从 🔴 改为 ✅(2026-10-31 接通)。

## README

文档列表加索引与 future-plan 入口 —— 此前从 README 找不到 docs/zh 的任何指引。

## 核对

- docs/zh 32 篇全部有状态行
- 索引里列的文档全部存在,无遗漏
- 分类与各文档自述一致(逐篇抽查)
- go build 仍通过(纯文档改动)
2026-10-31 07:50:58 +08:00

4.7 KiB
Raw Blame History

生产召回能力分层

状态:实测报告 + 待补清单。 能力分层与缺口来自生产实测。 文末「待补的能力」两个缺口仍开放,已索引到 future-plan.md §六。

单一分数(如「4/9」)会掩盖真实情况。真正有用的问题是: 什么形态的查询能用、什么不能用、为什么。

数据来源:生产库快照 /var/tmp/ha-probe/fresh.db (2026-10-03 .backup,1294 entities → 2686 块,chineseclip 512 维 + 中心化)

四种形态

# 形态 例 能力 机制
1 带精确串 「本机 13010 端口」 ✅ 强 符号路精确串命中 → 布尔置顶 → 排第一
2 领域词 + 上下文 「从零开发 QQ 插件用什么工具链」 ✅ 可用 向量召回 + 中文符号滑窗
3 纯泛化描述 「公网地址是什么」 ❌ 弱 向量给不出区分(排名 389/2686)
4 库里没有 「grafana 监控面板的端口」 ⚠️ 会编造 纯中文查询拒答判据失效

各形态的实测依据

形态 1:精确串(强)

查询「本机 13010 端口对应什么」
  召回  13010/13011 而非 12011   [+符号 2: 精确2]
        http://127.0.0.1:13010
  基线  纯向量下这条连 top2000 都进不去

机制:SymbolScore 的 exactHit 是布尔信号,直接置顶 (Score = 1.0 + VectorHit*0.01),不参与加权和 —— 否则 满分会被 0.3 的符号权重稀释成 0.3,输给 0.33 符号分的噪声块。

形态 2:领域词(可用)

查询「脚本路径改到哪个目录了」        ✓ 命中 11 个含该词的块
查询「从零开发 QQ 插件用什么工具链」   ✓ 命中 plugindev 那条
查询「agentmail 公网访问地址是什么」  ✘ 命中的是「AgentMail地址格式」等

前两条靠中文符号滑窗(2~4 字窗口)+ 向量召回。

形态 3:纯泛化描述(弱)—— 主要瓶颈

查询「agentmail 公网访问地址是什么」  目标块排名 452
查询「公网地址」                     目标块排名 389
查询「对外的服务地址」                目标块排名 297
查询「101.201.37.155 是哪台机器」      目标块排名  58   ← 带 IP

★ 排名随查询的"可词法化程度"剧烈变化(452 → 58): 带上 IP 后降到 58,说明起作用的主要是词法信号,语义贡献极小。

根因:目标块是裸值,没有任何可供语义匹配的文本:

http://101.201.37.155:8083/     ← 无描述词

已试过并否定(见 vector-provider-decision.md): 给裸值块追加中性描述反而更差(排名 26 → 96,噪声稀释原值信号)。

形态 4:库里没有(会编造)

[abstention] grafana 监控面板的端口   ✘ 召回 CPU总线/MAR-MDR(0.84+)
[abstention] kafka broker 地址        ✘ 召回 read_thread/sdk站
[abstention] 数据库容灾演练          ✘ 召回 读写代码/追调用链

拒答判据只对含精确串的查询有效:

拒答 ⟺ 查询含精确串 ∧ 该精确串在全库零命中
豁免 ⟺ 含泛指词 ∨ 无可提取符号 ∨ 纯中文(判据不成立)

纯中文的零命中分不清「真没有」与「滑窗伪词提取失败」:

「grafana 监控面板的端口」 → [grafana 监控面板]   库里真没有
「本机服务监听哪些端口」   → [本机服务 监听哪些]   库里有 13010/8081

两者符号形态完全一样,库规模(3 块 vs 1391 块)也不是区分信号。

运维结论

能用:

  • 带 IP/端口/路径/版本号的查询(运维最常见)
  • 领域词 + 具体上下文

不能指望:

  • 「XX 是什么」这类泛化描述(除非用户已知道值)
  • 纯中文的「库里没有」检测(系统会编造,需人工/上游确认)

待补的能力

缺口 已排除的方案 可行方向
形态 3 统一追加中性描述(实测更差)、chineseclip(词法主导) ① 给每个值配真实上文(哪条命令/哪次排障产生)② 换 Qwen3-VL 测同义改写
形态 4 分数阈值(间隔 0.047,n=4 是运气)、纯中文符号判据(伪词不可分) 需能分词的中文提取(jieba 词边界与块文本对不齐,需新实验)

复现

PROD_SNAPSHOT=/var/tmp/ha-probe/prod.db \
  go test -tags onnxruntime ./internal/memory/ -run 'TestProbe_生产规模召回' -v

# ha-c(测试库,83% 可拆率)的对照
go test -tags onnxruntime ./internal/memory/ -run 'TestProbe_端到端召回' -v

⚠️ 两个库的可拆率差 7.5 倍(生产 11% vs 测试 83%), ha-c 上的分数不能推广到生产。