尝试用WorkBuddy搭建IMA知识库标签系统-3

老梁学AI

发布于 2026-07-20 21:14:52

490

问：今天继续，今天主攻自动打标流水线编码。

答：分叉机制完美生效：23 个强信号自动打标、13 个泛词进人工队列、s6 不再误打、岗位-管理(0.72) 正确降级到人工队列。铁律验证通过。

自动打标验证报告 · 2026-07-17 10:22

处理文档数: 7
自动标签数(≥0.85): 23
人工队列数(<0.85): 13
未命中(不误打): 0

s1_connector_terminal.txt

路径(仅日志): pipeline/samples/s1_connector_terminal.txt
文本长度: 84
✅ 自动标签: 部件-端子(=0.90,端子), 部件-连接器(=0.90,连接器), 工艺-压接(=0.90,压接), 主题-连接器端子(=0.90,连接器端子), 标准-USCAR(=0.90,USCAR)
⚠️ 人工队列: 品类-汽车(=0.72,汽车), 工艺-检测(=0.72,检测), 岗位-质量(=0.72,质量)

s2_nev_design.md

路径(仅日志): pipeline/samples/s2_nev_design.md
文本长度: 74
✅ 自动标签: 品类-新能源汽车(=0.90,新能源汽车), 部件-导线(=0.90,导线), 标准-GB(=0.90,GB)
⚠️ 人工队列: 品类-汽车(=0.72,汽车), 工艺-设计(=0.72,设计), 岗位-设计(=0.72,设计)

s3_quality.docx

路径(仅日志): pipeline/samples/s3_quality.docx
文本长度: 42
✅ 自动标签: 部件-端子(=0.90,端子), 工艺-压接(=0.90,压接), 主题-质量与检测(=0.90,质量与检测)
⚠️ 人工队列: 工艺-检测(=0.72,检测), 岗位-质量(=0.72,质量)

s4_standard.pptx

路径(仅日志): pipeline/samples/s4_standard.pptx
文本长度: 35
✅ 自动标签: 主题-标准规范(=0.90,标准规范), 标准-IEC(=0.90,IEC), 标准-UL(=0.90,UL), 标准-QC-T(=0.90,QC-T)
⚠️ 人工队列: 品类-汽车(=0.72,汽车)

s5_wechat.html

路径(仅日志): pipeline/samples/s5_wechat.html
文本长度: 39
✅ 自动标签: 工艺-裁线(=0.90,裁线), 工艺-剥皮(=0.90,剥皮), 工艺-压接(=0.90,压接), 工艺-焊接(=0.90,焊接), 工艺-装配(=0.90,装配), 主题-生产工艺(=0.90,生产工艺), 岗位-工艺(=0.90,工艺)

s6_no_hit.txt

路径(仅日志): pipeline/samples/s6_no_hit.txt
文本长度: 20
⚠️ 人工队列: 岗位-管理(=0.72,管理)

s7_terminal_trap.txt

路径(仅日志): pipeline/samples/s7_terminal_trap.txt
文本长度: 22
✅ 自动标签: 部件-导线(=0.90,导线)
⚠️ 人工队列: 品类-汽车(=0.72,汽车), 工艺-设计(=0.72,设计), 岗位-设计(=0.72,设计)

问：此次验证的人工队列部分，需要我怎么做。

工审阅回写闭环已建好并端到端验证通过。

新增了什么

pipeline/review.py —— 把人工队列从"待办清单"变成"可审阅、可回写"的链路：

extract_review_queue(batch_json) → 生成 review_queue.json + review_queue.md（可读清单，每条含文档/标签/置信度/命中词/系统建议）
apply_review() → 你填的决策落地：
- confirm → 写 confirmed_tags.json（待 IMA 批量写回）
- reject → 写 exclude_terms.json（label→[terms]，下次判标跳过 = 全局降权）
- pending → 跳过
- 有 confirm 项时自动调 batch_writeback 算写回 ETA（分日调度，占位不真实调用）

配套改动：config.py 加 3 个路径常量；tagger.py 加排除词机制（读 exclude_terms.json，跳过被排除的弱信号）。

你需要做的（极简操作）

打开 review_queue.md，看每条候选
把 decision 改成 confirm / reject / 保持 pending
跑 python -m pipeline.review apply —— 闭环完成

验证结论（PASS ✅）

13 条人工队列提取成功 → 模拟 s2「工艺-设计」confirm、其余 reject → 重跑验证 s6「岗位-管理」因全局排除不再出现。

一处语义务必分清（已钉死在代码注释 + 项目记忆）：

reject = 全局降噪：该弱信号词（如"管理""汽车"）在所有文档都不再候选
confirm = 文档级保留：仅该文档打此标签，最终写回 = auto_tags ∪ confirmed_tags
若同一词被别处 reject 进了全局排除，你 confirm 的文档仍通过 confirmed 保留、只是重跑后 manual_queue 里不再显示——这是预期，不是丢失

当前状态

本地判标 + 人工复核闭环 ✅ 全通；IMA 真实写回 ⏸️ 预留
下一步可选：接 llm_tag 模型判标补 40% 召回 / 接 IMA MCP 真实写回试点（建议 11_连接器端子）/ 你给其余行业库名单+领域

问：review_queue.md确认接受你的建议。

已完成。你的决策已落地。

执行结果

review_queue.json 重置为纯建议版（全 13 条 = reject），apply_review 已应用：

确认项：无（你全按建议拒绝，没有 confirm）
排除项（全局降权）：写入 pipeline/exclude_terms.json
- 品类-汽车 ← 汽车
- 工艺-检测 ← 检测
- 岗位-质量 ← 质量
- 工艺-设计 ← 设计
- 岗位-设计 ← 设计
- 岗位-管理 ← 管理
IMA 写回：无（无确认项，不需要写回）

这意味着什么

从这刻起，这 6 个弱信号标签在所有文档判标时都不再作为候选出现（机器不再为"汽车""管理""设计"等泛词自动/候选打标）。这些文档的精确标签（如 品类-新能源汽车、主题-质量与检测）不受影响，照常自动打出。

⚠️ 一个持久性提醒：exclude_terms.json 是全局且落盘的。将来若某篇文档确实该打 品类-汽车 或 岗位-管理，不能再靠弱信号自动/候选——需你在 IMA 手动补标，或回 标签清单_线束知识库.md 把该词登记为强信号同义词后再清排除。

记忆已追加到今日日志（2026-07-17.md）。下一步可选：接 llm_tag 模型判标补召回、接 IMA 真实写回试点（建议 11_连接器端子），或你给其余行业库名单+领域。

问：复盘此次的验证过程，确认是否有改进的地方。

复盘：自动打标流水线验证过程

一、总体评价（先说好的）

验证目标基本达成：8 格式提取全通、扫描件 OCR 闭环打通、置信度分叉生效、"不读路径"铁律通过。但验证过程本身暴露了 6 个真实坑，其中 2 个是"契约/语义没提前钉死"导致的返工——这正是你最在意的"可执行性"隐患。

二、验证中真实踩到的 6 个坑

三、改进点（按优先级）

P0 — 直接提升判标准确率

最长匹配优先 / 词内抑制：汽车⊂新能源汽车 导致 品类-汽车 误作弱信号（最终靠你手动 reject 才压掉）。改成"长词命中即抑制其短子串词"，可自动消解这类上义词噪声，少占人工队列。顺带解决纯子串匹配的潜在误命中。

P0 — 可重复验证（防复踩）

常驻测试套件：把验证固化成 python -m pipeline.test（或 pytest），每次改码可跑，对齐你"方法必须可执行 / 方案体检"的纪律。
验证脚本幂等：verify_* 开头自动清掉上次产物（exclude_terms / review_queue / confirmed），或加 clean 子命令并断言无残留。
先钉 spec 再写 verify：跨 venv OCR 返回类型、confirm/reject/全局排除语义，先写成一页 spec，断言才不易写错（坑 5 的根治）。

P1 — 契约健壮性

跨 venv 契约显式化：在 ocr-extract Skill 和全局 OCR 模块注释里写死"入参/返回纯文本"，并加 pipeline 初始化 smoke test 调一次 OCR 验证契约（坑 4 的根治）。

P1 — 覆盖盲区

OCR 仅验了 1 个扫描 PDF；补 图片文件 + 多页 PDF + 空 OCR 处理。
铁律仅 1 个负例（文件名含端子、内容无）；补"文件位于某维度名文件夹但内容无关"的正向忽略测试。

P2 — 方法论（呼应"方案体检"）

把"验证充分性清单"（负例 / 契约钉死 / 黄金集断言 / 幂等）补进 方案体检 Skill，跨项目复用——别的项目也别"验证靠肉眼"。

四、一个值得你拍板的设计点

exclude_terms.json 是全局且落盘的：一旦 reject，该弱信号在所有文档都不再候选，即使某篇真需要也得手动补标。建议加"排除可复核 / 可重入"机制（排除项带原因 + 复查日期），避免永久沉默。

五、建议下一步

我建议先实现 P0 三项（最长匹配抑制 + 常驻测试套件 + 验证幂等/契约 spec）——成本低、收益高、直接提升判标准确率与可维护性。要我现在动手吗？还是你先就"排除项可复核"那点做决定？

问：排除项可复核加"排除可复核 / 可重入"机制（排除项带原因 + 复查日期），避免永久沉默。

答："排除项可复核 / 可重入"机制已落地并端到端验证通过。

做了什么

把 exclude_terms.json 从「一旦拒绝就永久沉默」的扁平表，升级成带原因 + 复查日期 + 状态、可解除可续期的富格式：

格式升级（{label:[term]} → 每条带元数据）

json

"岗位-管理": [{
  "term": "管理",
  "reason": "明确误报：「项目管理方法」触发「管理」，非岗位标签…",
  "created": "2026-07-17",
  "review_by": "2026-10-15",   // 90天后到复查期
  "status": "active"           // active / lifted
}]

改动的 3 个文件

config.py：加 EXCLUDE_REVIEW_DAYS=90（默认复查周期）。
tagger.py：_load_exclude双格式兼容（旧扁平/新富），仅 status!='lifted' 生效——解除后的词自动重回候选池。
review.py：apply_review 写富格式并合并保留已有 created（防"刷新复查期逃避复核"）；新增 3 个复核入口：
- list_due_exclusions(as_of) → 到期项 surface 成 exclude_due.md
- lift_exclusion(label, term) → 解除，词重入候选池
- renew_exclusion(label, term, days) → 复查后确认仍是噪声则续期

CLI

python -m pipeline.review due [as_of]          # 列到期待复查项
python -m pipeline.review lift <label> <term>  # 解除→词重入
python -m pipeline.review renew <label> <term> [days]  # 续期

一处关键语义（已钉死）

到期只提醒、不自动放行：review_by 过期不会自动解除排除（避免噪声悄悄回归），而是由 due 列表把它推到你面前，让你决定 lift 还是 renew。这样既杜绝"永久沉默"，又不会"到期自动退化"。

验证结论（PASS ✅）

迁移：现有 6 条扁平排除 → 富格式，字段齐全。
到期提醒：模拟未来日期能 surface 全部 6 条，当日 0 条不误报。
解除重入：lift「汽车」后 tagger 不再排除它、且不再进到期列表。
续期：renew 顺延 review_by，词仍保持排除。

验证后已把 exclude_terms.json还原为你真实的决策（6 条全 active、复查期 2026-10-15，并补上规范化原因），exclude_due.md 重置为今日真实状态（0 条到期），临时验证脚本已清理。记忆已回写（今日日志 + 项目 MEMORY 的 pipeline 章节）。

下一步仍可选：复盘里的 P0（最长匹配抑制 + 常驻测试套件）、接 llm_tag、或接 IMA 真实写回试点。

问：复盘里的P0 — 直接提升判标准确率。

复盘 P0 里"直接提升判标准确率"那一项已落地并验证通过。

改了什么

pipeline/tagger.py 的 rule_tag 新增"词内抑制"pass：

原来按 label 取最佳匹配词后直接输出 → 品类-汽车(词汽车/0.72) 和 品类-新能源汽车(词新能源汽车/0.9) 是两个不同 label，都输出，上义词噪声进人工队列。
现在输出前排一层抑制：按 (权重降, 词长降) 排序，若某词 T_short 是已接受词 T_long 的子串且 T_long.weight ≥ T_short.weight，则抑制 T_short 对应标签。

权重门槛防止"弱长词误杀强短词"（如 新能源 之类短强词不会被某个弱长词吃掉）。

验证结论（PASS ✅ · `verify_suppress.py`，隔离排除表纯测机制）

无回归：重跑 run_samples.py，auto 标签与改动前完全一致，铁律（文件名含"端子"内容无→不打）仍 ✅。

效果与定位

未来受控词表新增上义词关系会自动消解，少占人工队列，不依赖你手动 reject。
与人工排除表互补不冲突：排除表是二次兜底（覆盖"独立泛词提及"这类抑制不触发的情形）。
保留 verify_suppress.py 作为回归用例。

问：复盘里的P0 — 可重复验证（防复踩）。

答：复盘 P0 的"可重复验证（防复踩）"已落地。

交付物（pipeline/ 下）

1. test_spec.md — 先钉契约，再写断言（根治坑 5：之前"契约没钉死就写断言"返工）把 8 条契约写死：受控词表加载、判标封闭词表+词内抑制、铁律（文件夹非来源）、分叉阈值、审阅闭环语义（confirm/reject/pending）、排除可复核（到期只提醒不自动放行）、OCR 返回 str、测试隔离幂等。

2. test.py — 依赖零、幂等、不污染用户数据

运行：python -m pipeline.test（全跑）/ clean（仅清理）/ <用例名>（单跑）
关键纪律：运行前快照+清空真实产物（review_queue/confirmed/exclude + output/*），运行后原样恢复——绝不碰你真实的 exclude_terms.json。
6 用例全 PASS ✅：

已验证的"防复踩"三件事

幂等：连跑两次 exit=0，无 .test_bak 残留。
不污染：你真实的 exclude_terms.json（6 条决策：汽车/检测/质量/设计×2/管理）运行后字节级原样保留。
契约先行：任何改码动到契约，流程是"先改 spec → 再改实现 → 跑 python -m pipeline.test"，不会再造裸脚本、不会裸眼验证。

问：复盘里的P1 — 契约健壮性，P1 — 覆盖盲区。

答：复盘 P1 两块已全部落地并验证通过（9/9 用例 PASS、真实排除表字节级原样、python -m pipeline smoke 独立可用）。交付的 3 个文件已呈上：

pipeline/smoke.py — OCR 契约初始化 smoke（根治坑 4）
pipeline/__main__.py — python -m pipeline [test|smoke] 入口
pipeline/test_spec.md — 更新后的契约 spec（OCR 覆盖 + 铁律正例已钉死）

问： P2（把"验证充分性清单"补进方案体检 Skill，跨项目防复踩）

答：复盘 P2 已落地：把"验证充分性清单"沉淀为方案体检的第 6 个体检维度，跨项目防复踩。

改了什么

1. 方案体检 Skill（~/.workbuddy/skills/方案体检/SKILL.md）升级 v1→v2（5→6 步）

新增 第 6 项「验证充分性」（仅当方案落地为代码/接口/自动流程时适用），含 4 个核查要点：
- 负例 — 是否含"不应命中"的反例（如文件名含词内容无→不打）
- 契约钉死 — 外部/跨进程调用是否先钉 spec 再实现（根治坑 4 契约漂移）
- 黄金集断言 — 是否有已知正确输出集、断言完全一致（不靠肉眼）
- 幂等/隔离 — 测试能否连跑不报错、运行前清残留、不污染用户真实数据（根治坑 6）
报告模板加第 6 行；「进化候选池」记录来源（本项目复盘涌现、已晋升）；「反例→正例」补验证充分性一则（裸验证 vs 常驻套件+test_spec+隔离恢复）。

2. 全局记忆双向同步（防复踩关键）

「交付纪律：方法必须可执行」的交付前自检清单补第 6 条「验证充分性」（负例/契约钉死/黄金集/幂等；纯文档方案可免）。
「工具化」引用由「5 步」改为「6 步（含第 6 项验证充分性）」——与 Skill 保持一致。

闭环意义

这正是你最在意的"可执行性/防纸面陷阱"纪律的延伸：以前方案体检只查"概念有无载体、读写有无节点"，现在补上**"验证是否可重复、不靠肉眼"**——因为 P0/P1 的坑 4/5/6 全是验证不充分返工，是比纸面更隐蔽的陷阱。今后任何项目跑「体检/自检/检查」会自动核查这 4 点，从源头杜绝"肉眼看报告就算验证过"。

今日复盘全收口

P0：词内抑制（消解上义词噪声）+ 常驻测试套件 python -m pipeline.test + 验证幂等/契约 spec ✅
P1：契约健壮性（全局 OCR 钉死 + smoke）+ 覆盖盲区（图片/多页/空白空 OCR + 铁律正例）✅
P2：验证充分性清单入方案体检 Skill ✅

问：到目前为止，此项目进行到什么状态了，完成率有多少。

答：基于项目长期记忆与今日日志，给出完整盘点。

项目状态盘点（截至 2026-07-17 13:48）

完成率怎么算

项目总目标是"N 套独立标签体系 + 1 份通用方法"，但 N 取决于你提供的行业库名单（目前只给了 1 套《线束》）。因此分两个口径：

第一闭环（方法 + 工具链 + 首套可投产 MVP）= ≈ 90% 技术骨架全通，只差 IMA 真实写回 + 专家审核实际填写 两个收尾动作即真投产。
全项目口径（含 N-1 套 + 真实写回 + 审核）= ≈ 55% 但其中约 40%+ 是"待你输入/拍板"的阻塞性待办，并非技术未完成——引擎、方法、首库都已就绪，剩余库是"套模板复制"。