ad34b0cb23
- 新增 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>
222 lines
18 KiB
Markdown
222 lines
18 KiB
Markdown
# 读标抽取评测：S01–S10 标注集 v1（2026-11-03）
|
||
|
||
> **修复后的结果见 §7**：F1–F8 和四个口径问题已经处理。§7 的分数是在同一批 10 份样本上调出来、又用这批样本评的，评分脚本里还有两条「按定义算对」的规则，**不能当作达标的证据**。只按人工标注算的分数、泛化风险和下一步见 `extract-status.md`。§1–§6 是修复前（base）的评测，保留作对照。
|
||
|
||
> 范围：读标（M2）的五类清单抽取和项目基本信息，在 S01–S10 上的召回率和准确率。
|
||
> 模型：DeepSeek Flash 不思考模式（决策 M1，不再对比 Pro 和思考模式）；提示词 substantive v4、qualification / scoring / schedule / tech_param v3、project_info v2；代码版本 f99bb8b。
|
||
> 工具和复现方法见 `evals/README.md`；标注规范见 `evals/gold/GUIDELINES.md`。
|
||
|
||
## 1. 结论
|
||
|
||
| 指标 | 目标（TV1） | 结果 | |
|
||
|---|---|---|---|
|
||
| 标注类实质性条款召回（★ / * / 斜体下划线） | ≥ 99% | 正式清单 99.4%，含待确认区 **99.7%**（346/347） | ✓ |
|
||
| 写明无效类召回 | ≥ 90% | 正式清单 77.0%，含待确认区 **85.4%**（223/261） | ✗ |
|
||
| 进入正式清单的实质性条款准确率 | ≥ 95% | **87.8%**（811/924） | ✗ |
|
||
|
||
- **标注类达标**：规则兜底起了作用。唯一漏掉的一条，是 S07 那句既说明标注方式、又带 * 号的长句。
|
||
- **另外两项不达标，原因都在规则，不在模型**：
|
||
- 写明无效类：表格项靠表后的说明定性，「拒绝接收」这类写法没认出来。
|
||
- 准确率：合并清单项时，没通过校验的条目被并进了正式条目。
|
||
- **其他四类**：
|
||
|
||
| 类别 | 召回 | 准确率 | 主要问题 |
|
||
|---|---|---|---|
|
||
| 资格条件 | 98.9% | **38.4%** | 模型多抽 |
|
||
| 评分项 | 93.8%（含待确认 99.5%） | 100% | |
|
||
| 日期与递交 | 100% | 73.7% | |
|
||
| 技术参数（抽样页） | 91.1% | 98.6% | 召回差在一种静默丢失：分块输出接近上限时，模型提前收尾 |
|
||
|
||
- **项目信息**：12 个字段里 8 个全对。`eval_method` 只对 3/10，`sme_only` 只对 1/10，都是规则问题（§3.6）。
|
||
- **成本**：10 份文件全部任务，输入 386 万 token，输出 76 万 token，约 13.8 元（高峰价，未计缓存命中），**平均每份约 1.4 元**。tech-validation §4.3 推算的是 0.6～1.0 元，实测偏高，主要多在 S03、S06 这两份长文件的技术参数输出。D2 定额度时按实测值算。
|
||
|
||
## 2. 方法
|
||
|
||
- **标注集**：`evals/gold/S01.json`～`S10.json`，共 1,829 个单元（其中 76 个是裁定后补的，见下文）。
|
||
- 每份文件由一个子代理按 `GUIDELINES.md` 标注。子代理只看文字层（`sentences.txt`），不看模型输出。
|
||
- 定位用「页码 + 原文片段」，切句规则变了也能用。
|
||
- 五类清单和项目信息全文标注。技术参数量太大，每份在技术要求章里等距抽 6 页，这 6 页上全标。
|
||
- **目前是 AI 标注、AI 复核，没有人工复核**（`reviewed: false`）。
|
||
- **口径统一**：标完后发现各份的处理不一致，统一了三条：句子本身带标注的一律必标；章节标题带 ★ 的继承暂记可选；`sme_only` 原文没写明的改为 null（GUIDELINES §4）。
|
||
- **打分**（`evals/score.py`）：
|
||
- 召回：有对应类别的清单项，出处句子和标注的句子有交集，就算召回。正式清单算一遍，加上待确认区再算一遍。
|
||
- 准确率：正式清单里这一类的条目，出处和这一类的某条标注有交集，就算准确。
|
||
- `optional` 的标注不进召回的分母，抽到了算对。
|
||
- **裁定**：正式清单里对不上标注的 543 条，逐条判断是标注漏了还是模型抽错了。
|
||
- 实质性条款、资格条件、日期递交由三个子代理裁定，评分和技术参数我自己裁定。
|
||
- 标注漏了的有 76 条，补成 `optional` + `added_in_review`：只修正准确率，不抬高召回率。
|
||
- 抽错的按原因分类，结果在 §3。
|
||
- **S07 的预处理**：S07 是 WPS 旧版 DOC，产品现在的转换流程直接转，正文全是「第第第第」（S1 §1.3 记录过，转换流程还没做这一步）。评测时在 `prepare.py` 里先转 DOCX、修正字符集。**这是产品缺陷，要在转换流程里补上。**
|
||
|
||
## 3. 问题和原因
|
||
|
||
按「改规则能解决」和「要改提示词」分开。规则只修真正的缺陷，不迁就模型的错误输出（SK11 的原则）。
|
||
|
||
### 3.1 合并清单项时，没通过校验的条目被并进正式条目（规则缺陷，影响最大）
|
||
|
||
- **现象**：`merge_items` 按首句合并各任务的结果，只跳过「同一任务」的待确认条目。别的任务的待确认条目照样把类别、重要性和出处并进正式条目。
|
||
- **后果**：实质性条款任务里依据校验没通过的条目，借技术参数、资格条件的正式条目进了正式清单，还被标成实质性。
|
||
- 实质性条款多出来的 113 条里，89 条原文根本没写无效后果，大部分是这样来的。
|
||
- S07 一份就有 93 条：普通技术参数被标成了「致命」。
|
||
- **修复**：合并时，待确认条目不给正式条目加类别、不提高重要性。它单独留在待确认区，或作为待确认的依据附在正式条目上。
|
||
|
||
### 3.2 写明无效类的漏抽（规则为主）
|
||
|
||
| 原因 | 条数 | 修复 |
|
||
|---|---|---|
|
||
| 表格项靠表后的说明定性：「上述第 1～6 项必须全部提供，否则投标无效」写在资格证明表、符合性审查表**下面**。结构识别只往上找上级条款，看不到它 | 33（S03、S05、S07、S08） | 结构识别加一种：以「上述」开头、写明无效后果的说明，覆盖它上方同一张表的各项 |
|
||
| 后果写在另一条里：「有下列情形之一的，视为串通投标」下的各项，「串通投标的投标无效」写在别处 | 7 | 「视为串通投标」作为无效的上级标题。依据：87 号令，串通投标的投标无效 |
|
||
| 无效写法没认全：「其投标将被拒绝」「拒绝接收」「拒绝接受」「无资格参加」 | 7 | `INVALID` 补这几种写法 |
|
||
| 符合性审查表各项只在表头写了「不通过的投标无效」，上级关系没识别出来 | 13 | 和第一行一起做：表格结构识别 |
|
||
|
||
### 3.3 资格条件多抽（提示词为主）
|
||
|
||
正式清单里 466 条资格条件，裁定后 287 条不是资格条件：
|
||
|
||
| 抽错的内容 | 条数 |
|
||
|---|---|
|
||
| 技术参数，尤其是写着「提供认证证书 / 检测报告」的参数行 | 112 |
|
||
| 投标文件的组成、编制、递交、签章、授权书 | 54 |
|
||
| 无效情形、串通情形 | 34 |
|
||
| 第六章格式范本里的声明函、承诺函正文（提示词已经禁止，模型照样抽） | 27 |
|
||
| 价格扣除、联合体组成规则 | 18 |
|
||
| 合同履约、服务要求 | 11 |
|
||
| 程序说明 | 5 |
|
||
| 其他 | 26 |
|
||
|
||
- **规律**：句子里带「资格」「证明材料」「须提供」就收。
|
||
- **修复**：
|
||
- **规则**：结构识别补上章节层级（架构 §3.5 的 TODO）。第六章格式范本和第四章技术参数，不交给资格任务。这一项能去掉一半以上的错。
|
||
- **提示词**：qualification v4 把「技术参数里的证书要求」「投标文件组成和签章」「无效情形」写进「不要输出」，各给一个例子。
|
||
|
||
### 3.4 日期与递交多抽（提示词）
|
||
|
||
88 条对不上标注，裁定后 29 条是标注漏了（同一要求在另一处换了说法），59 条是模型抽错了：
|
||
|
||
- 质疑投诉的程序和形式 23 条；
|
||
- 运维服务时限、驻场人数 11 条，主要在 S09，模型看到时限、人数就当成了日期；
|
||
- 开标记录 5 分钟内提疑义 7 条；
|
||
- 中标后事项 5 条；
|
||
- 其他 13 条。
|
||
|
||
**修复**：schedule v4 的「不要输出」补这几类。
|
||
|
||
### 3.5 技术参数漏抽（规则 + 提示词）
|
||
|
||
- **静默丢失（规则）**：S03 一个分块有 259 句密集参数表。模型输出 97 条、7,757 个 token（上限 8,192）就自己收了尾，JSON 完整，没被判成截断，后面两页多的参数整段丢了（抽样页上 17 条）。
|
||
- **修复**：输出 token 超过上限的 90%，且最后一条证据离分块末尾还远，按截断处理、对半重跑。技术参数任务的分块也可以改小。
|
||
- **描述性的实施、服务要求被当成背景（提示词）**：S05、S06、S08、S09、S10 共约 30 条，例如「须统一部署于市级政务云」「试运行不少于 1 个月」。
|
||
- **修复**：tech_param v4 写明：带「须」「不少于」「不得」的实施、服务要求要抽，项目背景和建设目标才不抽。
|
||
|
||
### 3.6 项目信息（规则）
|
||
|
||
- **`eval_method` 7/10 没答出来**：「本项目采用综合评分法」写在第五章评标办法里，项目信息只看前 3 个分块。
|
||
- **修复**：项目信息任务再加一个分块，就是评标办法一章的开头。
|
||
- **`sme_only` 8/10、`accept_imported` 2/10 核对不通过**：是 / 否字段的否定词表没有「非」「不专门」，「非专门面向中小企业」被判成证据和取值对不上。
|
||
- **修复**：否定词表补上。
|
||
|
||
### 3.7 其他
|
||
|
||
- **评分项待确认区里 68% 是好结果**（17/25）：被拦下的原因是引文不是原文、分值找不到，都出在评分表被切碎的地方。这正好是已经排好的「表格按单元格切句」。
|
||
- **重复条目**：
|
||
- 同一条标注被两条以上正式条目命中：实质性条款 115、资格条件 41、日期递交 35。
|
||
- 主要原因是同一要求在公告、前附表、审查表里各出现一次，各抽一条。
|
||
- 这本身不算错，但清单会显得重复。查标阶段要考虑按语义合并。
|
||
|
||
## 4. 修复清单（按收益排序）
|
||
|
||
| # | 改什么 | 类型 | 预计影响 |
|
||
|---|---|---|---|
|
||
| F1 | 合并时待确认条目不给正式条目加类别、提重要性（§3.1） | 规则 | 实质性条款准确率 87.8% → 95% 以上 |
|
||
| F2 | 结构识别：「上述……否则无效」往上覆盖表格各项；「视为串通投标」算无效标题；`INVALID` 补写法（§3.2） | 规则 | 写明无效类召回 85% → 95% 左右 |
|
||
| F3 | 静默提前收尾按截断处理、对半重跑（§3.5） | 规则 | 技术参数召回，S03 这类长表 |
|
||
| F4 | 章节层级：第六章格式、第四章参数不交给资格任务（§3.3） | 规则 | 资格条件准确率 |
|
||
| F5 | qualification v4、schedule v4、tech_param v4 的「只找 / 不要输出」（§3.3–3.5） | 提示词 | 资格、日期准确率，技术参数召回 |
|
||
| F6 | 项目信息加评标办法分块；是 / 否字段否定词补「非」（§3.6） | 规则 | `eval_method`、`sme_only` |
|
||
| F7 | 转换流程补 WPS 旧版 DOC 预处理（§2） | 规则 | S07 这类文件能用 |
|
||
| F8 | 表格按单元格切句（已排期） | 规则 | 评分项、技术参数的待确认 |
|
||
|
||
## 5. 口径问题（已定，见 decisions.md Q1–Q4）
|
||
|
||
标注时遇到、规范里没定的，影响产品行为，需要拍板：
|
||
|
||
1. **★ 标在整节标题上**（S01「三、★商务要求」并写明商务条款全部是实质性、负偏离无效；S07「★售后」；S10「★（一）技术要求」「★（二）商务要求」）：节里不带 ★ 的各句算不算实质性条款？
|
||
- 现在的流水线只认标题这一句，标注集暂把节里的句子记为可选。
|
||
2. **★ 没写无效后果**（S02）：文件只说「★ 为核心技术参数」，评分表里 ★ 不满足只扣 4 分。
|
||
- 现在一律按实质性处理，用户会看到「致命」，实际只是扣分。
|
||
3. **「必须 / 应」都是实质性要求**（S07 第 18 页的声明）：逐句标出不现实。
|
||
- 建议只在文件层面提示「本文件声明含『必须』『应』字样的要求均为实质性要求」，不逐句抽。
|
||
4. **资格条件是否一律带「无效」类别**：政府采购里资格审查不合格就是投标无效，87 号令第六十三条有规定。
|
||
- 一律带上的话，§3.2 第一行那 33 条漏抽自然解决。
|
||
- 但写明无效类的口径会从「文件写明」变成「法规规定」，要和「双层口径」一并考虑。
|
||
|
||
## 6. 没覆盖的
|
||
|
||
- 标注集没有人工复核。
|
||
- 1,829 个单元是 AI 标的；裁定时发现，各份文件之间对「授权书算不算资格」「质疑截止算不算日期」的处理仍有差异。
|
||
- 建议先人工抽查实质性条款（S03、S06 最难），再把 `reviewed` 改成 true。
|
||
- 样本缺口没变：扫描件、补遗、招标投标体系、配套投标文件。
|
||
- 原句高亮准确率（FR-M2-06）不在本次范围，等表格按单元格切句后再验。
|
||
|
||
## 7. 修复后（fix3，2026-11-03）
|
||
|
||
F1–F8 全部实现，四个口径按建议执行（决策 Q1–Q4）。改完先请 Fable 当顾问审读（§7.3），改了它指出的问题，再跑两轮。
|
||
|
||
> **注意（同日复核）**：下表「修复后」一列，实质性条款准确率里有 320 条是评分脚本按定义算对的（★ 节、法规无效），只按人工标注算是 72.4%；标注类召回按 S02 的原标注算是 98.9%；资格、日期的准确率含 AI 裁定补标。详见 `extract-status.md` §2。
|
||
|
||
### 7.1 结果
|
||
|
||
| 指标 | 目标 | 修复前（base） | 修复后（fix3） |
|
||
|---|---|---|---|
|
||
| 标注类实质性条款召回（含待确认区） | ≥ 99% | 99.7% | **99.4%** ✓ |
|
||
| 写明无效类召回（含待确认区） | ≥ 90% | 85.4% | **98.1%** ✓（正式清单 84.7%） |
|
||
| 实质性条款准确率（正式清单） | ≥ 95% | 87.8% | **98.4%** ✓ |
|
||
| 资格条件 召回 / 准确率 | | 98.9% / 38.4% | 97.7% / **90.0%** |
|
||
| 评分项 召回 / 准确率 | | 93.8% / 100% | **97.4%** / 100% |
|
||
| 日期与递交 召回 / 准确率 | | 100% / 73.7% | 95.6% / **99.3%** |
|
||
| 技术参数（抽样页） 召回 / 准确率 | | 91.1% / 98.6% | **98.4%** / 98.8% |
|
||
| 项目信息：评标方法 / 最高限价 / 是否专门面向中小企业 | | 3 / 9 / 1（共 10 份） | **9** / **10** / **7** |
|
||
| 每份文件的成本（Flash 高峰价） | | 约 1.4 元 | **约 1.2 元**（按章跳过，输入少了 27%） |
|
||
|
||
- **口径**：两次的标注集不完全相同。修复后按 Q1、Q2 改了口径（S01 节内 12 条改必标，S02 的 11 条 ★ 改可选），技术参数的 S07、S09 在新分页上重标，两轮裁定共补了 117 个可选单元。召回率的分母基本没变（597 → 610）。
|
||
- **裁定**：准确率都是裁定过的，正式清单里对不上标注的条目逐条判断过，方法同 §2。
|
||
|
||
### 7.2 改了什么
|
||
|
||
| # | 改动 | 位置 |
|
||
|---|---|---|
|
||
| F1 | 合并时，待确认条目不再给正式条目加类别、提重要性；没通过的类别记在正式条目的 `ai_values.pending_categories` 里，不丢 | `extract.merge_items`、`add_pending_categories` |
|
||
| F2 | 表后往回指的说明（「上述……否则投标无效」）覆盖上方的编号条目和表格行；「视为串通投标」算无效依据；`INVALID` 补「被拒绝」「拒绝接收」「投标文件无效」「不实质性响应」等写法；规则兜底也认表后说明 | `structure.trailing_notes`、`extract.INVALID` |
|
||
| F3 | 输出用到上限的 92% 以上按截断处理、对半重跑；拆到底时采用已有输出 | `ai/providers/base.near_limit` |
|
||
| F4 | 章识别（公告、须知、合同、采购需求、评审、格式……），资格、日期、参数、评分任务跳过不相干的章；章认不可靠时不跳过 | `structure.chapters`、`extract.SKIP_CHAPTERS` |
|
||
| F5 | 提示词 substantive v5、qualification v4、schedule v4、tech_param v4；规则兜底：格式范本正文（「我单位……」）、列表引导句和整表概括句不收 | `prompts/`、`extract.TEMPLATE`、`BLANKET` |
|
||
| F6 | 项目信息多看写着「本项目采用综合评分法」的那一块；是 / 否字段否定词补「非」「不专门」 | `extract.EVAL_METHOD`、`NEGATIVE` |
|
||
| F7 | WPS 旧版 DOC：直接修正 DOC 字体表里中文字体的字符集，不用先转 DOCX | `convert.fix_wps_doc_charset` |
|
||
| F8 | 有框线的表格按单元格切句（切句 s3-v4），竖排窄列、两栏表格不再串行 | `text_layer._fragments` |
|
||
| Q1 | ★ 节标题下的条款继承实质性 | `structure.star_sections` |
|
||
| Q2 | ★ 被定义成计分项时降为「重要」，条件从严 | `extract.star_scored` |
|
||
| Q3 | 「必须 / 应」声明记成 keyword 标注规则 | `extract.marking_notes`、`checklist.service.merge` |
|
||
| Q4 | 政府采购项目的资格条件带「无效」类别，依据记 statute | `extract._qualification` |
|
||
|
||
### 7.3 顾问审读（Fable）
|
||
|
||
请 Fable 只读审了第一版修复，确定的问题 7 条，都已改正：
|
||
1. ★ 定义句的降级会误伤真正的废标 ★：改成要有计分证据，而且全文没有带 ★ 的后果写法；
|
||
2. 章识别会被目录、正文里的引用带偏：排除编号条目，同样长取靠后的序列，不可靠时不跳过；
|
||
3. F1 第一版把待确认条目直接丢了：改成记在 `pending_categories`；
|
||
4. Q2 文件里实质性任务仍标致命：改为按重要性规则定级；
|
||
5. 表后说明会把标注说明、否定句当成无效依据：排除这两种写法；
|
||
6. 参数行带 ★ 编号被当成节标题：要求 ★ 紧挨编号，标题短、不带标点和数字；
|
||
7. 接近上限拆到底时丢弃完整输出：改为采用已有输出。
|
||
|
||
推测性的几条也采纳了：合同章里的「拒绝接受」不算无效依据，引导句过滤只针对冒号结尾或很短的句子，F7 收紧字体记录长度的检查。
|
||
|
||
### 7.4 还剩的问题
|
||
|
||
- **写明无效类正式清单召回只有 84.7%**：大部分在待确认区（规则兜底或依据校验没过），用户能看到，但要多点一下。主要是符合性审查表各项（表头写「任何一项不符合即无效」，在表格上方），以及串通情形。
|
||
- **待确认区里只有 62% 是好结果**（127/205）：规则兜底和 `pending_categories` 带进来的噪音偏多。查标阶段要看待确认区的处理体验再定要不要收紧。
|
||
- **资格条件准确率 90%**：剩下的错误主要是「本项目不接受进口产品 / 分包」被当成资格条件，以及联合体、中小企业政策条款。
|
||
- **项目信息**：`accept_imported`、`sme_only` 各 7/10，多数是模型答「有歧义」或没核对通过。
|
||
- **★ 节里的商务条款**（S01 付款方式、履约保证金）：规则兜底不对继承来的句子逐句生成待确认，模型没抽到就漏了。
|
||
- **标注集没有人工复核**，口径同 §6。
|