Files
bid-doctor/docs/architecture/extract-status.md
YANG JIANKUAN ad34b0cb23
Some checks are pending
ci / server (push) Waiting to run
ci / web (push) Waiting to run
ci / contract (push) Waiting to run
docs: 读标抽取现状、遗留问题和下一步;改正「三项目标全部达标」的说法
- 新增 docs/architecture/extract-status.md:指标两种读法(报告值 / 只按人工标注)、
  已确认的进展、泛化风险(Fable 过拟合评估)、P0–P3 遗留问题、找样本和建留出集的流程
- extract-eval.md、AGENTS.md、架构 SK13、evals/README.md 改正达标说法并指向新文档
- 读标召回率优化暂停,后续专项优化从 extract-status.md 接着做

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
2026-11-03 23:37:52 +08:00

156 lines
13 KiB
Markdown
Raw Blame History

This file contains ambiguous Unicode characters

This file contains Unicode characters that might be confused with other characters. If you think that this is intentional, you can safely ignore this warning. Use the Escape button to reveal them.

# 读标抽取:现状、遗留问题和下一步(2026-11-03)
> 用途:读标抽取的召回率优化先暂停,后续做专项优化时从这份文件接着做。
> 评测过程和数字见 `extract-eval.md`;本文件的结论以这里为准。§7 里「三项目标全部达标」的说法要按本文 §2 的口径重新理解。
> 依据:S01–S10 标注集评测(修复前 base、修复后 fix3),以及 Fable 顾问的两次审读(修复审读、过拟合评估),关键数字已复核。
## 1. 现状一句话
修掉了几个确定的缺陷,搭起了结构识别的框架。但现在的分数是在同一批 10 份样本上调出来、又用同一批样本评的,**泛化能力还没有被测过**。
## 2. 指标怎么读
| 指标 | 目标 | 报告值(fix3) | 只按人工标注算 | 说明 |
|---|---|---|---|---|
| 标注类实质性条款召回(含待确认区) | ≥ 99% | 99.4% | **98.9%**(356/360) | 看过输出后,S02 的 11 条 ★ 按口径 Q2 改成了可选;按原标注算不达标 |
| 写明无效类召回(含待确认区) | ≥ 90% | 98.1% | 98.1% | 正式清单只有 84.7%。新增召回主要来自两处:江苏范本的「上述……否则无效」句(33 条),以及 Q4 把资格条件定义成无效 |
| 实质性条款准确率(正式清单) | ≥ 95% | 98.4% | **72.4%**(含补标)/ 71.5%(不含) | 1,232 条里明确判错 20 条;另有 320 条靠评分脚本「按定义算对」:★ 节内 234 条(S10 占 225),资格条件法规无效 86 条。这 320 条没有人逐条核对过,真实准确率在 72%~98% 之间 |
| 资格条件准确率 | — | 90.0% | 71.5% | 两轮 AI 裁定补了可选单元;裁定理由里有不少「拿不准」,真值在两数之间 |
| 日期递交准确率 | — | 99.3% | 81.8% | 同上 |
| 评分项准确率 | — | 100% | 95.4% | 同上 |
| 技术参数准确率 | — | 98.8% | 98.3% | 同上 |
「只按人工标注算」指两点:不含两轮裁定补的 117 个可选单元;评分脚本里的两条「按定义算对」规则不生效。按这个口径,可以确认达标的只有**写明无效类召回(含待确认区)**。
## 3. 已经确认的进展(换任何文件都成立)
| 改动 | 修掉的缺陷 |
|---|---|
| 合并时待确认条目不再借正式条目进清单(`pending_categories`) | S07 一份有 93 条普通技术参数被标成「致命」 |
| 输出用到上限的 92% 按截断处理,拆到底时采用已有输出 | 模型临近上限自己收尾,S03 两页参数整段静默丢失 |
| WPS 旧版 DOC 直接修正字体表字符集 | S07 正文全是「第第第第」,产品里根本没法用 |
| 表格按单元格切句(s3-v4) | 多行单元格串行、竖排窄列一字一句,评分表和参数表的证据对不上 |
| 是 / 否字段的否定词补「非」「不专门」 | 「非专门面向中小企业」8/10 份核对不通过 |
| 「视为串通投标」算无效依据(87 号令第三十七条) | 串通情形依据校验不过 |
| 格式范本正文(「我单位……」)不收 | 资格任务把声明函逐句抽成资格条件 |
| 评分、标注工具:按「页码 + 片段」定位,切句变了能自动改写;有留出集就能直接用 | 以前没有可重复的评测 |
## 4. 泛化风险:哪些规则是照着样本调的
Fable 用样本外的写法逐条验证过,标「已验证」的是复现过的。
### 4.1 道理通用、写法和阈值照样本定(换文件可能失效或误判)
| 规则 | 样本外的失效写法 | 失效后果 |
|---|---|---|
| 章识别 `structure.chapters` | 「第1章」「第一部分」、章号和标题拆成两句、采购需求或附件放在最后(已验证:全部返回空) | 静默不跳章:召回不掉,但资格准确率退回、成本 +27%、合同章「拒绝接受」的排除失效 |
| 资格任务跳过采购需求章 `SKIP_CHAPTERS` | 磋商文件把「供应商资格要求」写在采购需求章 | **静默漏抽,没有兜底**。10 份样本里没有一条资格标注落在被跳过的章,这条规则在样本上没付过代价 |
| 表后说明 `trailing_notes` | 只认句首「上述 / 以上」;「注:第1~5项缺任一项投标无效」覆盖 0 行(已验证) | 漏抽 |
| 同上,后果词含「不合格 / 拒绝」、不看章 | 需求章「以上人员须经考核,不合格的拒绝进场」(已验证) | 上方参数行全被当成无效依据,进待确认 |
| `INVALID` 新增「不得参加 / 被拒绝 / 拒绝接受」 | 「评标委员会成员不得参加评审」「不得参加后续培训」「甲方有权拒绝接受不合格货物」(已验证) | 一般要求冒充写明无效;只排除了合同章,而且前提是章识别成功 |
| 概括句过滤 `BLANKET` / leads | 「上述证书原件须在开标时携带,否则投标无效」本身是一条要求(已验证) | 被当成引导句丢掉,兜底也不补 |
| ★ 节 `star_sections` | 「★1 核心交换机」被当成节标题(已验证);后面没有同级编号时,范围最多延伸 800 句 | S10 一个标题覆盖 381 句、产出 225 条致命,没有人逐条核对 |
| ★ 降级 `star_scored`(Q2) | 后果写在不带 ★ 的句子里(「重要技术参数负偏离超过三项的,投标无效」)(已验证) | 真正的废标 ★ 被显示成「重要」 |
| 评标方法 `EVAL_METHOD` | 招标投标体系的「综合评估法」「经评审的最低投标价法」 | 项目信息答不出 |
| 阈值 | 表后往回 40 句、行长 ≤ 60 字、★ 节范围 800 句、最后一章不超过一半、92% | 都是看样本定的,没有样本外依据 |
### 4.2 照着答案改的
- **提示词例子取自测试文件**:substantive v5、qualification v4、schedule v4、tech_param v4 的新例子,逐字来自这 10 份(如「须统一部署于市级政务云平台」「上述资格证明文件 1~6 项」「提供公安部检测报告」「5 分钟内提出疑义」)。这些条目在 10 份上的得分不能当证据,换文件前要换成虚构或别处的例子。
- **评分脚本镜像了抽取规则**:`score.py` 里「★ 节范围内一律算对」「法规无效且碰到资格标注就算对」两条,等于用抽取规则去证明抽取规则(§2 的 320 条)。
- **看过输出后改了标注集**:S02 的 ★ 改成可选;两轮 AI 裁定补了 117 个可选单元;标注员和裁定员是同一类模型,都没有人工复核。
### 4.3 换文件后的预计(Fable 的推测,未验证)
| 新文件 | 标注类召回 | 写明无效类召回 | 实质性条款准确率 |
|---|---|---|---|
| 同样是江苏政府采购 IT 类 | 大概率 ≥ 98%,到不到 99% 五五开(★ / 斜体下划线的兜底是通用的) | 能守住 90%(范本句一致) | **最先掉**,按人工逐条口径估 85%~90% |
| 外省、招标投标体系 | 基本不受影响 | 掉到 80% 左右(「作废标处理」「否决投标」写法不全,章识别失效) | 掉得更多;资格准确率退到 60%~70% |
| 扫描件 | 可能掉到 80%~90%:斜体下划线和单元格都依赖矢量信息,★ 经 OCR 常变成 * 或 ☆ | 依赖 OCR 质量 | — |
## 5. 遗留问题清单
按优先级排。P0 不做,后面的分数都不可信。
### P0 评估体系
1. **建留出集**:至少 10 份,**改代码之前选好、不看**,组成见 §6.1。代码冻结后只跑一次、出一份报告,不裁定;裁定中「标注漏了」的只记录,计为错误。
2. **人工标注**:实质性条款和资格条件必须人工标(两项目标指标都在这里,两轮 AI 裁定已经证明偏宽)。评分、日期可以 AI 标注,再人工抽查 20%。标注员不能和裁定用同一类模型。
3. **评分脚本拆列**:准确率分两列报:「对上人工标注」和「按定义算对」(★ 节、法规无效)。标注类召回按 S02 两种口径都报。裁定补标的单元单独计数。
4. **10 份现有样本的标注集人工复核**:先复核实质性条款(S03、S06 最难),再把 `reviewed` 改成 true。
### P1 规则改保守(防样本外误判)
1. **★ 节继承来的条目**:先进 `pending_categories`,由人确认,不直接标致命。S10 一份 250 条致命,和口径 Q3「清单失去意义」的理由自相矛盾,Q1 的落地方式要重新定。
2. **表后说明**:只在公告、须知、资格、格式这几章生效;后果词去掉「不合格」「拒绝」;支持「注:第1~5项……」这类不以「上述」开头的写法。
3. **`INVALID`**:
- 「不得参加」要求同一句里带「投标」或「采购活动」;
- 「拒绝接受」只认主语是采购人或代理机构、对象是投标文件的写法;
- 按法律体系补「作废标处理」「予以废标」(招标投标体系里等于否决投标;政府采购里「废标」多指整个采购终止,不能混用)。
4. **概括句过滤**:只在上下确实有编号列表时生效,句子本身写着具体要求的不过滤。
5. **★ 降级**:带后果的句子里没有 ★,但提到了 ★ 的定义词(「核心技术参数」「重要技术参数」),也不降级。
6. **章识别**:
- 支持「第1章」「第一部分」、章号和标题拆成两句;
- 认不出时计数 `chapters_unreliable`,写进解析结果;
- 资格任务不跳过采购需求章,或者跳过之后对采购需求章补一遍关键词扫描(「资格要求」「供应商须具备」)。
7. **评标方法**:补「综合评估法」「经评审的最低投标价法」等招标投标体系的写法。
8. **提示词例子**:换成虚构的,或取自留出集以外的文件。
9. **回归测试**:把 §4.1 里每条「已验证」的反例写成单元测试。
### P2 覆盖面
1. **招标投标体系**:术语(招标人、否决投标)、无效写法、评标方法都没有样本,规则基本没覆盖。
2. **扫描件**:OCR(技术验证 S5)还没做。斜体下划线、表格单元格这两条规则在扫描件上不成立,要另想办法,例如用版面分析认表格、用多模态模型认标注。
3. **外省范本**:江苏范本的「上述……否则无效」「苏采云」写法不能当通用规则。
4. **补遗、更正公告**:没有样本。
### P3 质量细节(`extract-eval.md` §7.4)
- **写明无效类在正式清单里的召回只有 84.7%**:主要卡在符合性审查表(表头在上方)和串通情形上。
- **待确认区里只有 62% 是好结果**:噪音偏多,要结合查标阶段的处理体验再定。
- **资格误抽**:「本项目不接受进口产品 / 分包」被当成资格条件。
- **项目信息**:`accept_imported`、`sme_only` 各 7/10。
- **重复条目**:同一要求在公告、须知、审查表各抽一条,查标阶段要按语义合并。
## 6. 下一步建议(专项优化时)
### 6.1 找样本
收集时按下面的组成来,**先全部放进留出集,再从中划出一部分作为开发集**,不要反过来:
| 类别 | 份数 | 要点 |
|---|---|---|
| 江苏政府采购 IT 类 | 4 | 含 1 份非苏采云平台、1 份竞争性磋商、1 份竞争性谈判或询价 |
| 外省政府采购 IT 类 | 3~4 | 不同范本的省份(例如浙江「政采云」、广东、北京),优先选章节写法不同的 |
| 招标投标体系 | 2 | 国企或工程类信息化项目(江苏省公共资源交易网「工程建设」栏目等) |
| 扫描件 PDF | 1~2 | 盖章扫描的招标文件,用于 OCR(S5)和标注识别 |
| 补遗 / 更正公告 | 1 | 带原文件和更正内容 |
获取方式和版权处理沿用 `samples/tenders/README.md`:原文件和抽取文本不进 git,只提交清单和 `fetch.sh`。
### 6.2 优化的流程
1. **划分**:样本分开发集和留出集(留出集至少 10 份,§6.1 每类至少 1 份);
2. **标注**:留出集人工标注实质性条款和资格条件;标注规范沿用 `evals/gold/GUIDELINES.md`,先补上招标投标体系和扫描件的口径;
3. **改代码**:只看开发集;每条新规则都配一个样本外的反例测试;提示词例子不取自留出集;
4. **评分**:冻结代码后在留出集上只跑一次,按 §5 P0 第 3 条拆列报告,不裁定;
5. **决定**:留出集分数没达标的,回到开发集找原因,不在留出集上改。
### 6.3 先做哪几件
1. P0:评分脚本拆列、10 份现有样本的实质性条款人工复核(工作量最小、能立刻看清真实水平);
2. P1 第 1、3、6 条:★ 节改待确认、`INVALID` 收紧、章识别补写法(误判代价最高的三条);
3. 收集样本、建留出集(§6.1),再开始下一轮优化。
## 7. 相关文件
| 文件 | 内容 |
|---|---|
| `docs/architecture/extract-eval.md` | 评测方法、修复前后的结果、改动清单(§7) |
| `docs/decisions.md` | M1(只用 Flash)、Q1–Q4(实质性条款的口径) |
| `evals/README.md`、`evals/gold/GUIDELINES.md` | 评测工具用法、标注规范 |
| `server/src/bid_doctor/checklist/extract.py` | 抽取、校验、合并、兜底 |
| `server/src/bid_doctor/document/pipeline/structure.py` | 章、表后说明、★ 节、上级条款 |
| `server/src/bid_doctor/document/pipeline/text_layer.py` | 切句(按单元格) |
| `evals/score.py` | 评分;`ok()` 里两条「按定义算对」的规则见 §4.2 |