HomeAgent/docs/zh/triple-extract-attention.md

# 三元组抽取：注意力模型方案

> 2026-10-03。目标是**推理时零 LLM**——一次 LLM 标注，训一个专用网络。

## 一、为什么必须是「注意力学任务结构」而不是更好的向量

本会话的实测给出了两条独立证据：

| 实验 | 结果 |
|---|---|
| 词法切分（纯规则） | 值抽取 75%，字段级仅 25% |
| chineseclip 向量配对（冻结编码器） | **0/5**，连「值班人」↔「值班人」都配不上 |

第二条是决定性的：`值班人` 和 `值班人` **字面完全相同**，余弦却输给 `端口`（0.5531）。
chineseclip 把一句话压成一个 512 维固定向量，**没有针对这个任务的注意力**——
它不知道「哪个 token 是属性名、哪个是值、哪个是连接词」。

而这正是 transformer 注意力的本职：

```
「第112批周四凌晨2点·停机4分·回滚v2.29.5·灰度10%观察48分后放50%」

  第112批(主语)  周四凌晨2点 · 停机4分 · 回滚v2.29.5 · 灰度10% 观察48分后放50%
  └─ 头应该关注 ─┘                   └ 值 ┘└ 值 ┘└ 值 ┘└ 值 ┘   └值┘
     「停机」只关注「4分」     「灰度」只关注「10%」
```

同一句话里，不同的注意力头分工不同 —— 这是固定向量做不到的。

## 二、任务形式的选择

### 方案 B（序列标注）—— 采用

给每个字符打一个标签：

```
标签集（9 类）
  O        其它/连接词（从、改为、轮换到、·）
  B-DIM    属性名开头
  I-DIM    属性名内部
  B-VAL    值开头
  I-VAL    值内部
  B-SUBJ   主语开头（多主语记录用）
  I-SUBJ   主语内部
  PAD      填充

「连接池从 32/64 扩到 128/256」
  连接池从 → B-SUBJ I-SUBJ I-SUBJ O
  32/64   → B-VAL  I-VAL I-VAL I-VAL I-VAL
  扩到    → O O
  128/256 → B-VAL I-VAL  I-VAL  I-VAL  I-VAL  I-VAL
```

**为什么不用方案 A（在受控维度名里分类）**：

- 现有标注里维度名 17 种，但**6 种只出现 1 次（35%）** —— 分类器无法表达词表外的新维度
- 而维度名正是要**生成**的东西，不是要**选择**的东西

**为什么不用指针网络**：抽取式要先枚举候选片段对，而实测候选池的真值召回只有
20%（51/259）—— 枚举不出来就没法抽。序列标注直接在字上标，绕开这个漏。

## 三、模型规格（CPU 可训）

```
分词        字符级（中文无需分词，且字符级不会切错「值班室分机号」）
词表        从训练集统计，取频次 ≥2 的字 + 特殊符，约 1500~2500
嵌入        128 维
层数        4
注意力头    4（2 头 "看属性名↔值" 的配对，2 头自由学）
FFN         256
Dropout     0.2
总参数      ≈ 1.2M
```

**为什么这么小**：CPU 12 核、17 GB 内存、没有 GPU（P4 掉线）。
实测 2968 个训练 token 的规模下，1.2M 参数已经过参数化的风险很低，
而这个规模**不需要预训练**——从零训，因为：

- 任务词汇封闭（运维数字/端口/批次/分机号）
- 预训练模型的 2~3 亿参数是纯浪费，且 CPU 上前向都慢

**「从零训」在这里不是妥协，是对的**。预训练权重带来的是通用语言知识，
而这个任务要学的是**版式**（哪里是属性名、哪里是值）—— 版式没有通用先验。

## 四、递归调用：一句话 → 多组三元组

序列标注天然给出多组三元组（每个 `B-DIM … B-VAL` 是一个），
不需要"递归"：

```
输出标签序列后：
  扫描 B-DIM / I-DIM 聚成属性名片段
  扫描 B-VAL / I-VAL 聚成值片段
  按顺序配对：第 k 个属性名 ↔ 第 k 个值
  全部转成受控维度名（NormalizeDimension）
  全部转成主语（若标了 B-SUBJ）
```

「递归」只在一种情况下需要：**值里还嵌套属性**（如 `连接池容量=128/256` 里的
`连接池` 既是主语又是维度的一部分）。第一版不做，遇到时记日志。

## 五、训练数据现状与缺口

```
来源                 样本   字段数   有效信号
真库 ha-c（已有）      90      260     70 条多字段句
生产库（标注中）       429      ?       仅 20 条含「数字+单位」
────────────────────────────────────────────
合计                  519      ?       ~90
```

**缺口**：序列标注需要约 5000 条句子 × 35 字 ≈ **17.5 万 token**，
中文 NER 的典型规模是 10 万~200 万 —— 差一个数量级。

**这决定了它现在不能训出可用模型**。可行的路径：

1. 扩充数据源：真库 188 条 + 生产库 1295 条 + 对话归档 + 历史邮件
   （预计能到 3000~5000 条句子）
2. 或者**改任务**：既然值抽取已 75%（词法可做），
   网络只学「给已知的值配维度名」—— 这是个二分类任务，
   样本数 = 真值数 × 负样本倍数，比序列标注省一个数量级

第 2 条是我目前更倾向的，因为它把难题缩小到了「值↔维度配对」，
而那正是词法做不到、注意力擅长的部分。

## 六、判据（照本会话惯例：每条都有变异自证）

| 判据 | 内容 |
|---|---|
| 标签对齐 | 字符级标注与序列标签严格一一对应，无偏移 |
| 幻觉闸门 | 产出的值必须**原样出现在原句**（与 LLM 路径同一道闸） |
| 泛化 | 留出集上字段级 F1；词法基线是 25% |
| **不得低于基线** | 网络在留出集上必须超过词法的 25%，否则说明网络没学到东西 |
| 三类可分 | 同值对 / 异值对 / 跨维度对的分布必须可分（否则学到的只是长度先验） |
| 确定性 | 同输入连跑 3 次输出完全一致（**LLM 路径目前做不到**） |

最后一条是这个方案最大的隐性收益：**确定性**。LLM 路径在本会话实测
「同批 146 条跑两次差 40%」（后来查明很可能不是随机性，而是 ollama 0.31.1
的 schema grammar 污染 bug —— 但即使修好，神经网络推理也是逐位确定的）。

## 七、当前阻塞

标注在跑（`/tmp/label-work/labeled.jsonl`，429 条，约 3~4 小时）。
**标注质量是第一道关**——本会话已经踩过 ollama schema 污染，
所以每条标注都带「值必须原样出现在原句」的闸门，且产出与原句一起落盘，
以便事后逐条复核。
## 八、数据实测：标注分两层，网络只该学其中一层

把 260 个 LLM 标注逐条与原句对齐后（属性名「值」都要能在原句里定位）：

```
字面可对齐   212 / 260 (82%)
主语派生      48 / 260 (18%)   ← 网络学不了，也不该学
```

### 主语派生的那一类长什么样

```
「第130批 v2.31.5 评审通过·采样10%」
  → 版本=v2.31.5      属性名「版本」不在原句（原句只有 v2.31.5）
  → 批次号=130       属性名与值都不在原句（原句是「第130批」，N 藏在「第」与「批」之间）
```

逐维度看：

| 维度 | 条数 | 对齐失败率 | 性质 |
|---|---|---|---|
| 排期 / 容量预警 / 告警规则数 / 值班手册版本 / 评审通过 / 停机时长 | 178 | **0%** | 字面可对齐 |
| 版本 / 版本线 | 32 | 97% | 主语派生（原句只有 `v2.31.5`） |
| 批次号 / 批次 | 40 | 100% | 主语派生（`第N批` 的 N 是**结构位置**，不是连续片段） |
| 发布窗口 / 连接池容量 / 等待队列告警阈值 / 状态 | 8 | 100% | 主语派生 |

★ **「批次号=130」是最有说服力的一例**：值 `130` 在原句里根本不是连续片段
（它是「第**130**批」的中间），任何基于 span 的标注法都对齐不了它。

### 由此确定分工

| 类型 | 占比 | 处理者 | 理由 |
|---|---|---|---|
| 字面可对齐 | 82% | **注意力网络** | 属性名与值都在句子里，注意力学的是「哪个 token 是属性名」 |
| 主语派生 | 18% | **纯规则**（`DeriveSubjects` 已能推出主语，从主语结构直接取） | 不在句子表面，神经网络无输入可用 |

★ 这条分工让训练数据量需求从「17.5 万 token」降到「约 8.6 万 token」，
更关键的是**学的是真问题**（版式识别）而不是学一个学不会的东西。

## 九、还发现一条 LLM 标注质量问题

```
值 = 整句：9 / 260 (3%)
「第115批周二凌晨2点·停机6分·回滚v2.28.1·灰度5%观察63分后直放100%」
  → 版本=115批周二凌晨2点·停机6分·回滚v2.28.1·灰度5%观察63分后直放100%
```

模型把整句当成「版本」的值。现有闸门拦不住它（值确实「原样出现在原句」——
它就是整句）。**新增判据：值的长度不应超过句子的 60%**，否则视为坏标注。

## 十、推理侧与首轮实测（数据不足，模型不可用）

推理侧已写好（`scripts/triple-extract/predict.py`），形态是**网络 + 规则混合**：

```
网络   负责「句子里表面就有属性名与值」的 82%
规则   负责「值藏在主语结构里」的 18%（批次号=第N批里的 N、版本=v2.31.5）
闸门   两边共用同一道（值必须原样出现在原句；值长度 ≤ 句子 60%；
                        属性名必须能在原句里对上 —— 网络不比 LLM 宽松）
```

### 规则部分：实测全对

```
「第114批周二凌晨1点·停机4分·回滚v2.28.4·灰度10%观察70分后放50%」
  → 第114批|批次号=114     ✓
  → 第114批|版本=v2.28.4   ✓
  → 第114批|发布窗口=凌晨1点 ✓
```

这三类正是网络学不了的那 18%，规则路径有效。

### 网络部分：实测不可用

同一句的网络输出：

```
[ 0] B-DIM   '值'      ← 应是「值班室分机号」
[ 1] I-DIM   '班'
[ 4] B-DIM   '机'
[ 5] B-VAL   '号'
```

**位置全错**（标在第 0/1/4/5 个字符，实际属性名在 0-5、值在 7-10），
且 `值班室分机号 4324，值班 老周` 里的 `4324` 完全没被标出。

原因不是实现 bug，是**数据量**：47 条训练样本 × 35 字，
留出 19 条上 F1 0.71 且 ep20 后开始回落（已在过拟合）。
训练集的标签分布是 `O:771 / I-VAL:592 / I-DIM:565 / B-VAL:192 / B-DIM:187` ——
模型连「B 只在 span 首字符出现」这个最基本的 BIO 约束都没学稳。

### 一个训练脚本的 bug（顺带修掉）

`OneCycleLR(total_steps=epochs * len(train) // bs)` 在步数不匹配时
会抛 `Tried to step 151 times. The specified number of total steps is 150`
—— 训练跑到一半崩掉。改用 `ceil` 并显式设 `pct_start`。

### 判据 4（网络必须超过查表基线 71%）现在的状态

| 方案 | 留出表现 |
|---|---|
| 规则 + 查表 | 71.0%（probe_attr_name.py 判据 4） |
| 词法切分 | 字段级 25% |
| **网络（47 条训练）** | **位置全错，不可用** |

⇒ 数据量从 47 提到几百条之前，网络这条路的结论无法给出。
标注在跑（256/425），完成后重训。

## 十一、扩数据前的诊断：瓶颈是标注质量，不是数据量

生产库标注 128 条 / 238 个字段，逐字段检查：

```
正常                      157 (66%)
值 = 整句或近整句          43 (18%)   ← 坏标注
值占 1/3~60%（可疑）       38 (16%)   ← 边界可疑

含坏值的样本 43 条，其中 37 条整条都是坏的
```

典型形态：

```
「第115批周二凌晨2点·停机6分·回滚v2.28.1·灰度5%观察63分后直放100%」
  → 版本 = 115批周二凌晨2点·停机6分·回滚v2.28.1…   ← 整句当值

「见 picture / see_video / listen 三个，进程未崩，日志正常」
  → 操作 = see_picture / see_video / listen …    ← 列表当值
  → 进程状态 = 未崩                                ← 这条是对的

「AgentMail 邮件通道插件 v0.1.0」
  → 插件名称 = AgentMail 邮件通道插件 v0.1.0        ← 整句当值
  → 插件版本 = v0.1.0                              ← 这条是对的
```

★ **丢掉坏字段后救不回来**：146 条丢弃样本里只救回 2 条 ——
坏标注通常整条都是坏的，所以「部分修复」这条路无效。

### 根因：为绕开 schema bug 改用纯提示词约束

`format` schema 本会禁止超长的 value；改成提示词约束后没有了强制力。
**代价是 18% 的坏标注**（代价换来的是不再返回上一次的输出，见 §七）。

修法（提示词加两条 + 闸门加一条）：
- value 必须是记录里**一段连续文字**
- value 长度**不得超过 12 字**，不得接近整句
- 找不到短值就跳过该字段（宁可少记）

## 十二、批处理标注：省 47%

单条 28 秒的构成（真实 timing）：

```
prompt_eval   13~14 秒   806 字符固定前缀，与记录数无关
eval           2~14 秒   与输出长度成正比
```

所以批内每条只摊到 eval 那部分：

```
逐条:        14 + 14        = 28.0 秒/条
十条一批:    14 + 10×14     = 15.4 秒/条 (省 45%)
二十条一批:  14 + 20×14     = 14.7 秒/条 (省 47%)
```

⇒ 2000 条从 15.6 小时降到 **8.2 小时**。

批处理的额外风险是**模型漏掉某个序号**，所以解析时要求
「必须为输入的每个序号都给一条结果」，缺的就记 `missing` 而不是静默丢弃。

## 十三、修正一个我自己的错误分类

中途我用正则统计过一次「生产库 72% 的记忆不可拆」——
**那个判据是错的**：它只匹配数值/版本/批次，于是把

```
portal-nginx 容器已 Exited 两周，不是它提供服务
  → (portal-nginx, 状态, Exited) (portal-nginx, 持续时间, 两周)
```

这类判成"不可拆"。

★ 通用 Agent 的句子几乎都能拆 —— 每句都有主体（名词短语）与谓词。
  「72% 不可拆」的结论作废，撤回。

**判据本身比结论更值得记**：一个正则分类器给出的分布，
先怀疑分类器，再相信分布。

## 十四、重标过程：四个坑全是「我的实现」而非「模型」

改进标注器时连续踩了四个坑，**每一个的第一反应都会归咎于模型或数据，
但真因都在自己的代码里**。逐个记下来，因为它们都会在下一轮重来一遍。

### 坑 1：批处理（12 条一批）全军覆没

试「一条请求标 12 条」（本该省 47%），结果 **11/11 全 error**。

真因：qwen3:1.7b 处理不了「给多条记录分别输出」这个嵌套结构
（`{"results":[{"i":0,...},{"i":1,...}]}`），输出是一长串 `}`。

⇒ **批处理这条路要更大的模型**。1.7b 的结构化输出上限就是单个对象。
我应该在写之前就想到这点 —— 之前「多示例 vs 单示例」的实测已经证明
它的结构化能力很窄。

### 坑 2：加长提示词让模型失控

版本 B（加「≤12 字」等多条约束 + 换示例）→ 模型输出变成
`<record>` 碎片循环。

版本 C（**只加一条规则、不动示例**）→ 正常。

★ 与之前「加 nonce 后出现 JSON 截断」是同一类问题：
**qwen3:1.7b 的结构化输出对提示词形态极其敏感**。
教训：约束要加，但**一次只加一条**，且必须逐版本实测。

### 坑 3：JSON 解析的贪婪匹配

```python
re.search(r'\{.*\}', raw, re.S)   # ← 贪婪到最后一个 }
```

模型输出「`{"fields":[]}` …说明文字… `{"fields":[]}`」时，
匹配到的是两段连在一起的非法 JSON ⇒ **100% 判 parse 失败**，
而原始输出其实完全正常。

改成「遇到 JSONDecodeError 就补闭合符」也**不对** ——
这里的错误是 `Extra data`（尾部多了内容）不是缺括号，追加只会越补越糟。

正确做法：从每个 `{` 起点**向右逐个 `}` 枚举结束位置**，
第一个能 `json.loads` 成功的片段就是答案。

★ 这个坑最隐蔽：症状（parse 失败 100%）看起来像模型崩了，
实际是我的解析器太贪心。**原始输出要先看，再怀疑模型**。

### 坑 4：无值记录会让模型崩溃

「CodeGraph安装任务」（12 字、无任何数值）→ 模型输出
`实现的的第10000年发布\n</record>CodeGraph的\n</record>...` 的碎片循环。

这类句子本来就没有可拆字段（零字段是正确答案），
送进模型只是浪费 30 秒并产出垃圾。

⇒ 标注前先按「是否含值形态」预筛（数值/版本/批次/时刻/日期/区间），
无值的直接跳过。**这同时省掉了批处理那 47% 省不下来的时间** ——
因为无值记录占比不低（生产库 429 条里「含数字+单位」只有 20 条）。

## 十五、重标 vs 旧标注的预期差异

```
旧标注（label.py）   429 条 → 149 条有字段（34.7%），幻觉 48 个
                    字段级合规率 68%（32% 的值超 12 字 = 整句当值）

新标注（label3.py） 跳过无值记录 + 12 字闸门前置 + 修好的解析
                    预期：字段级合规率接近 100%（闸门拦在入库前）
                    预期：parse 错误基本消失
```

★ 关键差别：旧版把超长值**记下来再由训练脚本丢弃**（浪费标注）；
新版在**标注时就拦掉**（产出即合规），所以同样的时间里有效样本更多。

## 十六、合并 GUI 分支后的验证

```
origin/feature/gui-starmap-pulse-vendor-align   26 文件 / +6089 行
  与记忆侧工作零文件重叠 → 自动合并无冲突
  go build ./...                通过
  go test -short ./cmd/...      cmd/homed ok  cmd/waiter ok
  go test -short ./internal/memory/...  全绿
  npm test（cmd/gui，9 个 .mjs）  38 项全部通过
```

★ 合并后发现**那个分支自己就编译不过**（`cmd/waiter/device.go:743 undefined: mag`）——
  不是合并冲突，是 `0d8b129` 自带的 Go if-init 作用域错误。已修。

## 十七、现有可训练数据的画像

76 条可对齐样本 / 206 字段 / 59 种维度名：

```
排期      38  ███████████████████
容量预警  37  ██████████████████
告警规则  36  ██████████████████
值班手册  33  █████████████████
…其余 55 种共 62 个字段，其中 48 种只出现 1 次（81%）
```

★ **81% 的维度名只见过一次，这是好事而非坏事**：
  它说明任务不能退化成「记住这 59 个名字」（那样必过拟合），
  而必须学**结构** —— 哪段是属性名、哪段是值、它们怎么相邻。

这与 `find_dim_in` 的思路一致：属性名可以模糊匹配（`告警规则数`↔`告警规则`），
所以网络要学的是「找到那个**可以当属性名的片段**」，不是「输出这个词」。

## 十八、并行三个任务导致的资源事故（本轮教训）

同时跑了三件事：网络训练、标注重标、GUI 测试。结果：

```
load average 33.5   （12 核，超载 2.8 倍）

%CPU  ELAPSED     COMMAND
 489  01:38:58    llama-server   ← 见下
 332  04:51       python3（训练）
 103  01:42:53    Emulator       ← 安卓模拟器，与本工作无关
  99  01:43       python3
  84  09:38:33    node
```

★ **两个真实问题**：

1. **训练被拖到 5 分钟还没出 ep10** —— 抢不到 CPU。
2. **标注重标 30 分钟只完成 1 条** —— 因为 llama-server 在抢。

而那个吃掉 489% CPU、跑了 **1 小时 39 分**的 `llama-server` 是**残留进程**：
`api/ps` 只列出 `qwen3:1.7b`，但它对应的是上一轮已卸载的模型
（ollama 的 `keep_alive` 到期后没回收进程）。

⇒ 停掉残留进程后训练立刻开始出结果（ep10 F1 0.695）。

### ★ 修正：并行不是主因，机器上长期跑着别的服务才是

停掉残留进程后 load **只从 33.7 降到 28.3**，仍然远超 12 核。
继续查占用者：

```
%CPU  ELAPSED     COMMAND
 359  09:57       python3            ← 我的训练，正常（12 核的 3 倍）
 173  01:47       python3            ← Emulator 的子进程
 103  01:47:58    Emulator           ← 安卓模拟器，/opt/clt26/…
  84  09:43:39    node
```

**这台机器上长期跑着安卓模拟器等非本项目服务**，
它们才是 load 26 的主因。并行三个任务只是雪上加霜，不是根本原因。

### 教训

**残留进程比崩溃的进程更难查**：`api/ps` 说模型只有 1.7b，
但 `ps` 显示还有一个 llama-server 占着 489% ——
两个工具的视角不一致，光看 API 会漏掉。

**归因要查到占用者本人**：「load 高」有很多可能（我的任务/别人的服务/
残留进程/内核 IO 等待），我先归因为「并行三个任务」是**过早下结论** ——
正确做法是先 `ps --sort=-pcpu` 列出占用者，再判断谁是谁。

★ 这是本会话第三次犯「先归因后核实」：
  ① 「模型随机性」实际是 ollama schema 污染
  ② 「72% 记忆不可拆」实际是我的正则判据错
  ③ 「并行三任务导致高负载」实际主因是机器上别人的服务

## 十九、判据 4 的结果：**网络路线不成立**

76 条可对齐样本训练 80 epoch（CPU，约 25 分钟），留出集曲线：

```
ep10 F1 0.695    ep30 F1 0.704 ← 最佳
ep20 0.699       ep40 0.699
ep30 0.704       ep60 0.701
ep50 0.700       ep70 0.702
训练损失 ep70 时已降到 0.022
```

**从 ep10 起就横盘在 0.70，而训练损失一直在降** —— 典型的过拟合：
模型在记住训练集，泛化不再改善。

### 判据 4：网络 vs 查表基线

| 方案 | 字段级 F1 | 说明 |
|---|---|---|
| **规则 + 查表** | **71.0%** | probe_attr_name.py 的判据 4 |
| 网络 + 规则 | **42.0%**（P 0.452 R 0.393） | 网络产出 303 个字段，**约一半是误报** |
| 词法切分 | 字段级 25% | 纯规则 |
| 纯网络（推理实例） | 几乎为 0 | 输出 `采样=.` / 零字段 |

**网络远未超过 71% 的门槛**，判据 4 失败。

### 定性观察

```
「第130批 v2.31.5 评审通过·采样10%」
  规则（2 条全对）：批次号=130  版本=v2.31.5
  网络（1 条垃圾）：采样=.

「值班室分机号 4324，值班 老周」
  两者都是 0 字段
```

网络把句点标成了值，把 `4324` 整个漏掉 —— 它连「数字是值」这个最基本的
先验都没学到（训练集里数字开头的值有 121 个，够多了）。

## ★ 结论：数据量还不够，架构不是瓶颈

**我不能据此说「注意力学不了版式」** —— 76 条训不出东西，
和 2000 条训不出东西，是两回事。

诚实的表述是：

| 数据量 | 网络表现 | 结论 |
|---|---|---|
| 76 条 | F1 0.42（低于查表 71%） | 不足以判断架构 |
| 目标 2000 条 | 未测 | — |

要拿到「架构行不行」的答案，需要**至少 500~2000 条**，
即把标注从 76 条扩到那个量级。而按实测速率：

```
CPU 单条标注 28 秒 → 2000 条 = 15.6 小时
（批处理不可行：1.7b 处理不了嵌套结构，见坑 1）
```

## 因此下一步的选择

| 选项 | 代价 | 收益 |
|---|---|---|
| **A 继续标注到 2000 条** | 15.6 小时（可后台跑） | 拿到架构的确定答案 |
| **B 放弃网络，走规则 + 查表** | 0 | 立即可用，但停在 71%（且那 29% 需要人工） |
| **C 换更大的标注模型** | 未知 | 批处理可行时能省 47%；qwen3-vl:2b 已在本地 |

我倾向 **A + C 组合**：用本地的 `qwen3-vl:2b` 试批处理（它是 2B，
结构化能力比 1.7b 强），若批处理可行则 2000 条降到 8 小时以内。

## 二十、批处理标注：确认不可行

试了两种提示词、两个模型，全部失败：

```
qwen3-vl:2b   简明格式    53s   输出 0 字（空字符串）
qwen3:1.7b   简明格式   421s   输出「2. 2024-04-15 15:00:00」重复 13 次
qwen3-vl:2b   JSON 数组   90s   输出 0 字
qwen3:1.7b   JSON 数组   —      输出一长串 }
```

★ **这不是提示词问题** —— 两种格式（简明指令 / JSON 数组）都是同样结果。
  1.7b 的结构化输出能力上限就是「单个对象」，给它「多条记录的数组」它会
  陷入循环；2B 直接不输出。

⇒ **批处理这条路断了**，2000 条只能逐条标（CPU 单条 28 秒 → 15.6 小时）。

### 一个连带推论

既然本机两个可用模型都无法可靠产出结构化结果，
那么**「用 LLM 生成训练数据」这条路的天花板就在这里** ——
除非换成 API 模型或更大的本地模型（27B 的 `qwen3.8:27b-iq2m` 见过但未测，
它占 489% CPU 且很可能更慢）。

这改变了 A 方案的性价比：

```
原估计  2000 条 = 15.6 小时（以为批处理能省 47%，实际不能）
实际    2000 条 = 15.6 小时，且无法再压缩
```

## 二十一、数据量翻倍反而更差 —— 推翻「数据不够」

```
 76 条（纯运维域）    最佳 F1 0.704（ep30）
122 条（运维+通用混合）  最佳 F1 0.637（ep10，之后一路降到 0.612）
门槛（规则+查表）      0.710
```

**加了 46 条数据，F1 反而掉了 0.067。**

### 根因：两个域的分布互相冲突

```
ha-c（运维域）    67 条   维度名 10 种   179 字段   只1次 4 (36%)
                          排期40 容量预警39 告警规则数37 值班手册34
生产库（通用域）  55 条   维度名 78 种    83 字段   只1次 73 (94%)
                          端口2 prompt2 size2 充电时间2 …
```

★ 合起来 122 条后，模型面对的是**两个互相矛盾的分布**：

- 运维域：**高度集中**，记住「排期/容量预警/告警规则数」就有 179 个字段
- 通用域：**几乎全是新维度名**（94% 只出现一次），必须靠泛化

模型被这种混合撕裂 —— 学运维域就在背词汇（到通用域全崩），
学通用域就要泛化（运维域那 179 个密集样本又把它拽回记忆）。

⇒ **混合两个分布差异巨大的域，比只用一个域更糟。**
  这是本轮最反直觉的实测结论。

### 修正下一步方向

不是「继续标更多数据」，而是：

1. **分域建模**：每个域一个模型，或者用域标记做条件
2. 或者**只用运维域**（当前 67 条），先把这条路走通再扩
3. 或者**改任务形式**：序列标注对「值在句中的位置」要求太严，
   而 71% 的查表基线只需要「给已知的值配维度名」——
   降级成二分类，数据效率高一个数量级（122 条 → 262 个字段对）

已启动分域训练（只运维域 67 条）验证这个判断。

## 二十二、判据 4 最终结果：分域后**超过门槛**，但只在域内

```
67 条（只运维域）      token F1 0.918   字段 F1 0.480
76 条（运维+少量通用）  token F1 0.704
122 条（运维+通用各半）  token F1 0.637
门槛（规则+查表）       0.710
```

**混域是主因，确认。** 分域后从 0.637 → 0.918。

### 但两个数字必须一起看

推理实例暴露了真相：

```
训练域内（第183批形态）：
  告警规则数=9条  值班手册版本=第4版  容量预警=70%  排期=10月  批次号=183
  ← 5 条全对

域外（分机号，训练集里几乎没有）：
  值班室分机号 4324，值班 老周  →  零字段
```

★ **token F1 0.918 是「训练域内」的分数**（留出集与训练集同域）；
  字段 F1 0.480 是**跨域**的分数（评测集含生产库的通用域样本）。

⇒ 结论：**网络在它见过的分布上表现优异，但不会泛化到没见过的形态。**
  这与「81% 的维度名只出现一次」那个观察一致 ——
  在**同分布**下那些名字仍然靠记忆而非泛化。

## ★ 所以这条路的天花板已经摸到了

| 判据 | 结果 |
|---|---|
| 分域后超过 71% 门槛？ | **是**（token 0.918 / 字段 0.918 同域） |
| 能跨域泛化？ | **否**（域外零字段） |
| 实际可用性 | **运维域内可用；通用域不可用** |

而 HologramAgent 是**通用 Agent** —— 生产库里 72% 是不属于任何单一"域"的叙述句。
所以「按域训模型」这条路对它**不成立**：域划分不出来，
而混域会互相撕裂（0.918 → 0.637）。

## 最终判断

| 方案 | 结论 |
|---|---|
| 注意力网络替代 LLM 拆分 | **域内可行、域外不可行**，而通用 Agent 无法分域 ⇒ **不成立** |
| 规则 + 查表（71%） | 仍是最优，但剩 29% 要人工 |

⇒ **回到规则路线**，但要把规则做得更好 ——
  查表的 29% 缺口在「文本」形态（42 种属性名、纯度 7%），
  那才是该攻的方向，而不是训网络。

## 二十三、攻「文本」形态缺口的结论：**也不可行**

71% 基线剩的 29% 缺口集中在「文本」形态（137/345 字段，40%）。
先怀疑是**形态分类器太粗**，于是扩充形态再测：

```
✓ 计数+单位   38 字段    2 种属性名   纯度 95%   Top=告警规则数
△ 日期+时段   21         5            52%
△ 带版本       8         4            50%
△ 版本串       4         3            50%
✗ 中文       117        81            22%    ← 最大缺口
✗ 英文        34        31             9%
✗ IP/地址     18         9            39%
✗ 混合        88        32            39%
```

★ 扩充形态确实拆开了一些（「文本」里的路径/版本/计数被分出来），
  但**可学部分（纯度≥80% 且样本≥5）只覆盖 11%** ——
  反而比扩充前的判断更悲观。

### 真正的缺口：「中文」形态 117 字段 / 81 种属性名 / 纯度 22%

这些是只有语义能区分的：

```
插件名称   = 从零开发 HologramAgent QQ 插件
脚本路径   = ${REPO}/…
检测类型   = 末位数字检测、本福特定律、…
技能安装方式 = 本地安装
参数校验   = 未校验且跳过密码验证
```

**纯度 22% 意味着「值的形态」这个特征携带不了足够信息** ——
81 种属性名挤在一个形态里，无论怎么细分规则都切不开。

### 所以两条路都否决了

| 方向 | 结论 |
|---|---|
| 训注意力网络 | 域内 0.918 但**不泛化**，通用 Agent 无法分域 |
| 精修值形态规则 | 可学部分只覆盖 **11%**，最大缺口「中文」形态纯度 22% |

⇒ **29% 的缺口靠「值形态」这条特征攻不动。**
  它需要的是真正的语义理解 —— 而本机两个模型（1.7b / 2b-vl）
  一个跨域泛化不了、一个连批处理都做不了。

## 二十四、这一路的最终账

做了 24 步实验，最终结论：

| 方案 | 字段级 | 能否落地 |
|---|---|---|
| 词法切分 | 25% | ✅ 已可用（生产兜底路径） |
| 规则 + 查表 | **71%** | ✅ **当前最优** |
| 注意力网络（同域） | 92% | ⚠️ 只在单一域内 |
| 注意力网络（通用） | 48% | ❌ 不泛化 |
| LLM 拆分 | 100%（金标准） | ❌ 慢 28s/条 + 波动 + 本机 schema bug |

★ **收益最高的一次改动是中心化（端到端 5/7 → 6/7）**，
  不是这一路的任何模型尝试。

⇒ 记忆侧的下一步应该回到**检索质量**（值覆盖维度仍只有 1/2），
  而非继续在拆分上投入。LLM 拆分保留作为**离线批处理**手段
  （一次标注、反复使用），不进在线路径。