mirror of
https://gitcode.com/JianFeeeee/HomeAgent.git
synced 2026-11-06 17:27:31 +00:00
cf14b840ef
## 背景 上一次文档校订（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 仍通过（纯文档改动）
122 lines
4.7 KiB
Markdown
122 lines
4.7 KiB
Markdown
# 生产召回能力分层
|
||
|
||
> **状态：实测报告 + 待补清单。** 能力分层与缺口来自生产实测。
|
||
> 文末「待补的能力」两个缺口仍开放，已索引到 [`future-plan.md`](./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 词边界与块文本对不齐，需新实验） |
|
||
|
||
## 复现
|
||
|
||
```bash
|
||
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 上的分数不能推广到生产**。
|