docs(evals): S01–S10 标注集 v1、评测工具和评测报告

- evals/gold：1,887 个标注单元（AI 标注、逐条裁定，未经人工复核），规范见 GUIDELINES.md
- prepare / run_all / score / gold：导出文字层、批量抽取、打分、标注定位
- docs/architecture/extract-eval.md：修复前后的结果（三项目标全部达标）和剩余问题
- decisions.md 记 M1（只用 Flash）和 Q1–Q4；架构 §13 SK13；AGENTS.md 进度

Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>

docs/architecture/architecture.md

@@ -860,9 +860,10 @@ S1–S4 风险最高，建议先做；S8（桌面外壳 PoC）等桌面版立项
 | SK10 | 文字层 v2 与结构识别 | 页眉页脚带（页码、各页重复的行）单独成句，不并进正文；标记写到页尾的句子，和下一页首句接续成一条要求（出处两页各一条）；最小结构识别：十进制分级编号和冒号引出的列表找上级条款，上级条款写明无效情形的，下面的条目照样认定。文字层 v1、v2 的句子编号不同，规范化 PDF 不变 | 已实现 |
 | SK11 | 待确认审计后的修正（2026-11-03） | 国动样本 73 条待确认里多数是好结果被校验误拦，逐条审计后按「规则只修真正的缺陷、不迁就模型的错误输出；模型输出不合理的改提示词」处理。**文字层 v3**：两端接竖线的横线是表格框线，不算下划线（功能表整格被误认成斜体下划线条款）；句号后紧跟的右括号、右引号并进同一句（切句 s3-v3，句子编号和 v2 不同）。**结构识别**：中文编号小节（「三、……否则投标无效」）下的 1. 2.，以冒号结尾的编号条目下的句子；依据核对沿上级链往上找。**校验**：比对引文前去掉我们自己加进输入的格式标记和〔…〕附注；不足 8 个字的短句整句复制时句末标点可省；取值核对认带量词的中文数字、同一行的单元格和评分因素标题；补「投标（响应）无效」「不能通过资格审查」「没有实质性响应」「拒收」等写法。引文最短 8 个字、编号必须对、证据要全部通过，这些不放宽。**提示词**：substantive v3、qualification / scoring / schedule / tech_param v2，统一证据规则（引文复制整句、并列多项不拆、跨页只引上一行、数字写阿拉伯数字），除实质性条款外输入改成纯文本；资格不收附件范本和价格扣除条件，日期不收合同条款，技术参数一句一条。**模型路由**：`BD_AI_MODELS` 按提示词声明的能力选模型，没配的用 `BD_AI_MODEL`。离线评测工具 `evals/run_extract.py` | 已实现 |
 | SK12 | 参考 BidEngine 的五项改进（2026-11-03） | 见 `ref-bid-engine-analysis.md` §5。**原因码**：没通过校验的结果记具体原因（`extract.FAILURES`，存在清单项 `ai_values.failures`），解析结果按原因计数（`verify_failures`），提示词规则和原因码的对照表在 `prompts/README.md`。**分块**：相邻分块重叠约 800 字；模型输出被截断（`finish_reason=length`）或不是合法 JSON 时，把分块对半重跑，最多 3 层，拆到底仍不完整的记 `output_incomplete`（以前当成「这一块没有结果」，审计发现 deepseek-flash 有输出正好停在 8192 token、整块条目悄悄丢掉的情况）。**项目基本信息**：提示词 v2，12 个字段每个都要表态 found / ambiguous / not_found，跨分块合并后分 found / absent（文件本身没写）/ needs_review（抽取有问题），记在解析结果 `info_fields`。**占位符**：「____元」「××」「（ ）」「待填」不算取值。**提示词**：substantive v4，qualification / scoring / schedule / tech_param v3，每条禁止事项对应一个原因码。三份样本的待确认：国动 4 → 2，S02 13 → 3，S06 57 → 55（S06 有 4 次对半重跑，截断的分块都救回来了） | 已实现 |
+| SK13 | S01–S10 标注集评测后的修正（2026-11-03） | 见 `extract-eval.md` §7。规则：合并时待确认条目不再「借道」正式条目（`pending_categories`），表后说明、章识别、★ 节标题、输出接近上限按截断处理、格式范本和整表概括句不收；提示词 substantive v5、qualification v4、schedule v4、tech_param v4；WPS 旧版 DOC 直接修正字体表字符集；表格按单元格切句（切句 s3-v4）。口径 Q1–Q4 见 decisions.md。三项目标（标注类召回 ≥ 99%、写明无效类召回 ≥ 90%、实质性条款准确率 ≥ 95%）全部达标 | 已实现 |
 
 SK11 修正前后（同一模型 deepseek-chat，即 deepseek-flash 不思考模式）的待确认数：国动 46 → 4，S02 17 → 13，S06 174 → 57；同一句被拆成多条的情况没有了。剩下的待确认多数是表格两栏或竖排文字串行（要按单元格切句才能解决）。实质性条款任务上比较了 flash 不思考、flash 思考（deepseek-reasoner）、deepseek-v4-pro：抽到的条款大体一致、互有多少，后两者慢 15～45 倍、输出 token 多 7～12 倍，没有看出明显更准；选型等标注集评测出结果再定。
 
 用国动便民小程序（71 页）、S02、S06 三份文件实测（真实模型 DeepSeek）：单份 33～87 秒，清单 216～1348 条，正式清单里的条目都带页码和原句。发现并已修复：标注规则说明的碎片被当成条款、页码混进正文、跨页拆成两条、「做无效响应处理」等写法漏认、上级标题下列出的无效情形被合成一条或漏掉、「无效质疑」被误当成投标无效、「是否接受联合体」取错证据。
 
-还没做、留了 TODO 的：转换镜像的字体包和 WPS 旧版 DOC 预处理（S1）、表格按单元格切句（S3）、OCR（S5）、章节层级和分包对应到清单项、模型路由的候选列表、降级和限流、在 S01–S10 上的标注集评测（召回率）、查标全部。
+还没做、留了 TODO 的：转换镜像的字体包（S1）、OCR（S5）、分包对应到清单项、模型路由的候选列表、降级和限流、查标全部。S01–S10 标注集评测和修复见 `extract-eval.md`。

docs/architecture/extract-eval.md

@@ -0,0 +1,219 @@
+# 读标抽取评测：S01–S10 标注集 v1（2026-11-03）
+
+> **修复后的结果见 §7**：F1–F8 和四个口径问题已经处理，三项目标全部达标。§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），改了它指出的问题，再跑两轮。
+
+### 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。

docs/decisions.md

@@ -4,6 +4,25 @@
 
 ---
 
+## Q1–Q4 · 2026-11-03 · 实质性条款的四个口径：全部按建议
+
+依据 `docs/architecture/extract-eval.md` §5（S01–S10 标注时遇到、规范里没定的情形）。
+
+| # | 决策 | 理由 |
+|---|---|---|
+| Q1 | ★ 标在节标题上（「三、★商务要求」「★（一）技术要求」），节里的条款都是实质性要求 | 文件自己这样声明（S01 还写明商务条款负偏离即无效）；节的范围到下一个同级编号为止 |
+| Q2 | 文件把 ★ 定义成计分项（「加★为核心技术参数」、不满足只扣分），而且没有任何地方说 ★ 是实质性要求或写明无效后果，★ 降为「重要」，标注规则记 meaning = important | 否则用户会把扣分项当成废标项（S02）。条件从严：要有计分证据、全文没有带 ★ 的后果写法，拿不准就按实质性 |
+| Q3 | 文件声明「必须」「应」字样的要求都是实质性要求时（S07），只在文件层面记一条标注规则（marker = keyword），不逐句抽 | 逐句抽会把几百条一般要求都标成致命，清单失去意义 |
+| Q4 | 政府采购项目的资格条件一律带「无效」类别，重要性依据记 statute | 87 号令第六十三条：不具备招标文件规定的资格要求的，投标无效；磋商同理。这是现行规定，不是草案层 |
+
+- **影响**：`extract.build_doc`、`structure.star_sections`；界面上 statute 来源的「无效」要和「文件写明」分开展示（查标阶段做）。
+
+## M1 · 2026-11-03 · 抽取模型只用 Flash，靠规则和提示词优化
+
+- **决策**：读标的全部抽取任务都用 DeepSeek Flash 不思考模式（`deepseek-chat`，接口返回 `deepseek-flash`），不再对比 Pro 和思考模式。提升效果只在规则（校验、兜底、文字层、结构识别）和提示词之间做。
+- **理由**：SK11 在实质性条款任务上比较过 Flash 不思考、Flash 思考（`deepseek-reasoner`）和 `deepseek-v4-pro`，抽到的条款大体一致、互有多少，后两者慢 15～45 倍，输出 token 多 7～12 倍，看不出更准。
+- **影响**：S01–S10 标注集评测只跑 Flash 基线，用来找规则和提示词的问题；按能力路由（`BD_AI_MODELS`）的机制保留，不配置。tech-validation §4.3 里「D2 定价前补测 Pro 或思考模式」不再做。
+
 ## API1–API5 · 2026-11-03 · 接口契约的取舍：全部按建议
 
 依据 `docs/architecture/api-design.md` §9；契约文件 `openapi.yaml`。