feat(qualification): 资质库和资质匹配（查标第 4 步，规则集 2026.11-r4）
- 资质库（FR-M6-08）：增删改、证书扫描件（PDF/JPG/PNG，企业级密钥加密、签名下载）、 late_for 按进行中项目的投标截止日提醒、审计；前端资质库页和对话框，侧栏入口 - 资质匹配（FR-M3-05）：证书类别词表（16 类，产品证书、人员证书不进匹配）， QUAL.EXPIRED / LEVEL_LOW / NOT_COVERED；投标文字层按清单项定级，只有资质库记录的降一级， 出处显示「依据：资质库记录」（查标页、报告模板 v2）；一类证书一个问题；评分项不逐条找响应的也查 - 响应错位规则不再把资质表的证书名称格当成照抄的要求 - 评测：qual_defects.py 派生资质情况表，D12 3/3、D18 2/2、规矩的资质表 0 误报；开发集不退化 - 决策 QL1–QL7；方案和落地记录 docs/architecture/qualification-plan.md，评测 check-eval.md §13 Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
This commit is contained in:
YANG JIANKUAN
@@ -192,7 +192,7 @@
|
||||
| 上传与文档 | 分片上传全套、挂到项目、文档列表和详情、逐页摘要、一页的句子、签名下载、发起解析、解析进度、取消、人工建出处 | 删除文档 |
|
||||
| 清单 | 清单概况（含确认人、删除数、按类别计数）、清单项列表（按区域、类别筛选，可含已删除）、清单项详情（ETag）、修改（If-Match 选填）、采纳、删除恢复、人工新增、替换出处、修改记录、确认清单、版本 | 补遗更新确认（等补遗解析）；列表的 `lot_scope`（等选包） |
|
||||
| 检查 | 检查预览、发起、进度、取消、检查记录、问题列表（含本次已解决）、每条清单项的检查结论（C9，2026-11-04 新增）、处理、撤销、批量处理（只限提示级）；投标分册类型和版本、电子投标平台加密格式识别 | 需人工核对（第 2 步） |
|
||||
| 报告、资质 | — | 全部（查标第 4、5 步） |
|
||||
| 报告、资质 | 报告：导出、生成进度、历次报告、签名下载（第 5 步）；资质库：增删改、按类型 / 关键词筛选、附件（上传后挂上、签名下载、删除）、`late_for` 到期提醒（第 4 步） | — |
|
||||
| 通知与事件 | 事件流（含检查进度）、通知列表、反馈 | 标为已读 |
|
||||
|
||||
读标修改类接口的实现约定（2026-11-03）：
|
||||
|
||||
@@ -276,7 +276,40 @@
|
||||
|
||||
留出集的正式成绩仍以 §11（冻结代码）为准：修的时候看过留出集的漏报，修后的数字有过拟合成分。
|
||||
|
||||
## 13. 下一步
|
||||
## 13. 资质匹配（查标第 4 步，2026-11-04）
|
||||
|
||||
规则集 `2026.11-r4`，方案 `qualification-plan.md`（决策 QL1–QL7）。只改规则，开发集上的模型结论全部走缓存。
|
||||
|
||||
**1. 开发集不退化**：17 份投标文件（空资质库）的全部指标和 §12 修后一致：召回 112 / 149（75%）、致命级 25 / 32、规矩的投标文件报出问题 239、规则问题 57 / 57。资质问题 0 个：开发集的证书全在扫描件页上，空资质库什么都不报（QL3）。
|
||||
|
||||
**2. 类别识别**（S01–S10 读标结果里资格条件、评分项中带「证书 / 资质 / 认证」的条目）：认出类别 14 条，产品证书、人员证书排除 9 条（节能 / 环境标志产品认证、项目经理和技术人员资质），没认出 2 条（S03「认证证书（3 分）」、S05「数据库兼容证书」，都是产品类，正确地不判）。营业执照、法人证书、联合体规则不算资质要求。读标留出集的 S03、S06、S09 里没有可核对有效期和等级的企业资质。
|
||||
|
||||
**3. 模拟资质库的噪音**（开发集 17 份，`run_check.py --library`）：
|
||||
|
||||
| 资质库 | 资质问题 | 说明 |
|
||||
|---|---|---|
|
||||
| 空 | 0 | |
|
||||
| 每类一条、有效、等级最高 | 4 个提示 | 都是 S01 的「CCRC 服务类别」：要求写了「安全集成」，模拟记录的名称里没写 |
|
||||
| 只有 ISO 9001 | 16 个重要 | S01 两份的资格条件和评分项「资质库里没有这类资质」，每份 8 个（含同一要求抽成两条的重复，一条评分项里两类证书各一个） |
|
||||
| 每类一条、2020 年过期 | 29 个重要 | S01（每份 8）、S04（每份 3 类 ISO）、S07（每份 ITSS、CS 两类）「按资质库记录已过期」 |
|
||||
|
||||
真实用户的资质库介于「全有效」和「缺几类」之间：规矩的投标文件上，资质库录全了几乎不出问题；录了一部分时，没录的那几类在扫描件条目上会出「未覆盖」（重要）。
|
||||
|
||||
**4. 派生的资质情况表**（`evals/check/qual_defects.py`）：在 S01-B、S04-B、S07-B 的资格证明一章开头插一张文字的「企业资质情况表」（虚构证书，写法故意和词表别名不完全一样），q00 全部有效、q01 注入 D12（有效期早于截止日）和 D18（等级低一级）。
|
||||
|
||||
| 指标 | 结果 |
|
||||
|---|---|
|
||||
| D12 有效期早于截止日 | 3 / 3（S01 资格条件致命，S04、S07 评分项重要） |
|
||||
| D18 等级低于要求 | 2 / 2 |
|
||||
| q00 规矩的资质表上的资质问题 | 0（空资质库、全有效资质库都是 0） |
|
||||
|
||||
调试中修的两处：一条评分项写了两类证书时合成一个问题，规则编号只能取一个（S07 的 CS2 被 ITSS 过期吞掉）→ 改为一类证书一个问题；证书编号「CS3-3201-…」排在等级栏前面，整行读成了 CS3 → 先看短的等级格。同一要求在清单里抽成两条时各报一个，评分按「同规则 + 同出处」算一个。
|
||||
|
||||
插表以后，响应匹配的候选句变了，13 + 8 + 12 次模型调用没有命中缓存：S01 有 5 条扫描件兜底的「请人工核对」因为文字表里能找到而消失（应当如此）；S07 有 3 条条目的结论变了（1 条新的「请人工核对」、1 条从「请人工核对」变成「疑似不满足」、1 条新的「疑似不满足」），是模型看到资质表后的判断，没有逐条复核。
|
||||
|
||||
**局限**：资质情况表和词表是同一个人对着同一批样本写的，分数说明不了泛化；真实投标文件的资质表写法、扫描件比例都没测。国动真实投标文件到了以后，请用户按公司的真实证书录资质库再跑一次（`qualification-plan.md` §5）。
|
||||
|
||||
## 14. 下一步
|
||||
|
||||
1. 分项报价表和采购需求清单逐项对照（P13）**暂缓**：在开发集 7 份招标文件上试读「名称 + 数量」的采购清单表，S02、S08（服务类）没有这种表；S04 把「是否进口」一栏读成了名称；S10 采购包 2 的表跨页、第二页没有表头，漏了大半；S01 9 行里能和投标文件的分项对上名称的只有 7 行。P13 是致命级，按这个抽取质量在真实文件上会大量误报「缺项」，评测集里也没有注入过，先不上，覆盖范围里照写「还没有上线」。散文写法的单价上限同样暂缓。
|
||||
2. 第 3 步冻结前：确认各项改动的单元测试都有开发集以外的反例；冻结后跑留出集（S03、S06、S09，风格 B + C）和国动真实投标文件，各一次。
|
||||
|
||||
@@ -12,7 +12,7 @@
|
||||
| 第 1 步 链路打通 | ✅ 2026-11-04 | 见下方「第 1 步落地记录」 |
|
||||
| 第 2 步 规则 | 基本完成 | 响应方式（C12）、文件要在、扫描件兜底、规则检查 `rules.py`（报价形式、形式要件、响应表）、需人工核对（`manual.py`、`manual-checks` 接口）、「报价」类清单项和分项上限（C7）。还差分项和采购需求逐项对照（P13）、散文写法的单价上限。见 `check-eval.md` §4–§7 |
|
||||
| 第 3 步 AI 响应匹配 | 进行中 | 整行上下文、提示词 v2、偏离栏直读、响应错位、复查复用、硬预算；送给模型的同一行按单元格、重复条目只合并显示（C5 修订）；致命项重问按数据暂不做。见 `check-eval.md` §8–§9 |
|
||||
| 第 4 步 资质库 | 未开始 | |
|
||||
| 第 4 步 资质库 | ✅ 2026-11-04 | 方案和落地记录见 `qualification-plan.md`（决策 QL1–QL7）。`qualification` 模块（增删改、附件按企业级密钥加密、`late_for` 到期提醒、审计）和前端资质库页；`check/qualification.py`：证书类别词表（16 类）、规则 `QUAL.EXPIRED / LEVEL_LOW / NOT_COVERED`，投标文字层按清单项定级、只有资质库记录的降一级，规则集 2026.11-r4。评测见 `check-eval.md` §13 |
|
||||
| 第 5 步 检查报告 | ✅ 2026-11-04 | `report` 模块：导出 → worker 用 Gotenberg（Chromium）把 HTML 转成 A4 PDF → 按项目数据密钥加密存对象存储 → `report`（不可改，存哈希）；`report_job` 记生成过程（迁移 0009），完成推 `report.ready`、发通知。首页有项目信息、投标文件版本、检查依据、规则版本、导出人、检查覆盖范围、汇总、免责声明；问题明细带两侧出处和处理人；附录是需人工核对的勾选结果；页眉 logo、页脚「本报告为辅助检查结果，仅供投标前自查参考」+ 页码；测试检查模板文字不出现「通过 / 合格 / 保证」。前端「报告」标签页：选项、导出、内嵌预览、历次报告下载。「证据索引」页没有单独做（出处已在问题明细里逐条列出）。同时补了项目状态流转（递交 / 撤销递交 / 归档 / 撤销归档，FR-M6-02）：致命问题未处理也能递交，确认框说明；递交后只读，撤销归档回到归档前的状态，都写审计 |
|
||||
| 第 6 步 前端补齐 | 部分 | 需人工核对、重复问题折叠、报告页已做；键盘操作、批量处理提示、判断有误反馈还没做 |
|
||||
|
||||
|
||||
@@ -624,7 +624,7 @@ paths:
|
||||
filename: { type: string, maxLength: 255 }
|
||||
size_bytes: { type: integer, minimum: 1 }
|
||||
sha256: { type: string, pattern: '^[0-9a-f]{64}$', description: 选填；提供时完成上传时校验 }
|
||||
purpose: { type: string, enum: [project_document, qualification_file] }
|
||||
purpose: { type: string, enum: [project_document, qualification_file], description: '资质附件只收 PDF、JPG、PNG，单个不超过 20MB' }
|
||||
responses:
|
||||
'201':
|
||||
description: OK
|
||||
@@ -1593,10 +1593,15 @@ paths:
|
||||
tags: [qualifications]
|
||||
operationId: listQualifications
|
||||
summary: 资质库
|
||||
description: 按「有效期至」从近到远排，长期有效的在最后。
|
||||
parameters:
|
||||
- name: kind
|
||||
in: query
|
||||
schema: { $ref: '#/components/schemas/QualificationKind' }
|
||||
- name: q
|
||||
in: query
|
||||
description: 按名称、证书编号、发证机构搜索
|
||||
schema: { type: string, maxLength: 100 }
|
||||
responses:
|
||||
'200':
|
||||
description: OK
|
||||
@@ -1944,7 +1949,7 @@ components:
|
||||
ProjectStatus: { type: string, enum: [tracking, drafting, checked, submitted, archived] }
|
||||
LegalRegime: { type: string, enum: [gov_procurement, tendering, unknown] }
|
||||
DocumentRole: { type: string, enum: [tender, addendum, clarification, bid_volume] }
|
||||
DetectedFormat: { type: string, enum: [pdf, docx, doc, wps, ofd, encrypted_bid, unknown] }
|
||||
DetectedFormat: { type: string, enum: [pdf, docx, doc, wps, ofd, encrypted_bid, jpeg, png, unknown], description: jpeg、png 只出现在资质附件（purpose = qualification_file）上 }
|
||||
JobStatus: { type: string, enum: [queued, running, succeeded, failed, cancelled] }
|
||||
Category: { type: string, enum: [qualification, invalidity, scoring, schedule, tech_param, format_doc, price] }
|
||||
Importance:
|
||||
@@ -2866,12 +2871,13 @@ components:
|
||||
items: { $ref: '#/components/schemas/Category' }
|
||||
rule:
|
||||
type: [object, 'null']
|
||||
description: 规则问题的规则编号和说明（detector = rule 时有）；资质匹配的问题同时挂清单项
|
||||
properties:
|
||||
code: { type: string, examples: [PRICE.CAPITAL_MISMATCH] }
|
||||
description: { type: string }
|
||||
detail:
|
||||
type: object
|
||||
description: 按类型的补充信息：参数的要求值和响应值、资质预警种类（expired / insufficient_level / not_covered）、从投标文件读到的金额
|
||||
description: 按类型的补充信息：参数的要求值和响应值、从投标文件读到的金额；资质问题（type = qualification）有 kind（expired / level_low / not_covered）、source（bid_text / library）、deadline，issues[] 里 source = library 的带 library（资质库记录的快照：id、name、kind、level、cert_no、valid_to），界面显示为「依据：资质库记录」
|
||||
tender_citations:
|
||||
type: array
|
||||
items: { $ref: '#/components/schemas/Citation' }
|
||||
@@ -3016,16 +3022,16 @@ components:
|
||||
properties:
|
||||
name: { type: string, minLength: 1, maxLength: 200 }
|
||||
kind: { $ref: '#/components/schemas/QualificationKind' }
|
||||
level: { type: [string, 'null'] }
|
||||
cert_no: { type: [string, 'null'] }
|
||||
issuer: { type: [string, 'null'] }
|
||||
level: { type: [string, 'null'], maxLength: 40 }
|
||||
cert_no: { type: [string, 'null'], maxLength: 80, description: 界面上必填（查标时用它核对附件），接口可空，以后批量导入时不一定读得全 }
|
||||
issuer: { type: [string, 'null'], maxLength: 120 }
|
||||
valid_from: { type: [string, 'null'], format: date }
|
||||
valid_to: { type: [string, 'null'], format: date, description: 空表示长期有效 }
|
||||
valid_to: { type: [string, 'null'], format: date, description: 空表示长期有效；要晚于 valid_from }
|
||||
Qualification:
|
||||
allOf:
|
||||
- $ref: '#/components/schemas/QualificationInput'
|
||||
- type: object
|
||||
required: [id, files, created_at, updated_at]
|
||||
required: [id, files, late_for, created_at, updated_at]
|
||||
properties:
|
||||
id: { $ref: '#/components/schemas/Id' }
|
||||
files:
|
||||
@@ -3037,6 +3043,16 @@ components:
|
||||
id: { $ref: '#/components/schemas/Id' }
|
||||
filename: { type: string }
|
||||
size_bytes: { type: integer }
|
||||
late_for:
|
||||
type: array
|
||||
description: 进行中的项目（跟进中、编制中、已检查，截止日不早于今天）里，投标截止日晚于「有效期至」的项目。到期按每个项目的截止日判断，不按今天
|
||||
items:
|
||||
type: object
|
||||
required: [project_id, name, deadline]
|
||||
properties:
|
||||
project_id: { $ref: '#/components/schemas/Id' }
|
||||
name: { type: string }
|
||||
deadline: { type: string, format: date }
|
||||
created_at: { $ref: '#/components/schemas/Timestamp' }
|
||||
updated_at: { $ref: '#/components/schemas/Timestamp' }
|
||||
|
||||
|
||||
189
docs/architecture/qualification-plan.md
Normal file
189
docs/architecture/qualification-plan.md
Normal file
@@ -0,0 +1,189 @@
|
||||
# 资质库和资质匹配实现方案 v0.1（2026-11-04）
|
||||
|
||||
> 范围：查标实现计划（`m3-plan.md`）第 4 步，即 FR-M6-08 最小资质库 + FR-M3-05 资质匹配检查。
|
||||
> 依据：`03-functional-requirements.md`、`05-it-integration-domain.md` R07 / R08、决策 G4 / C10 / DM4、`data-model.md`（`qualification` `qualification_file`）、`openapi.yaml`（`/qualifications`）、原型 `qualifications.html` 和 `results.html` 的 f6、评测规范 `evals/check/GUIDELINES.md` D11 / D12 / D14 / D15。
|
||||
> 状态：QL1–QL7 已全部按建议确认（2026-11-04，`docs/decisions.md`）。
|
||||
|
||||
## 0. 结论速览
|
||||
|
||||
- **表、接口、原型都已经有了**。基线迁移里已建 `qualification` 和 `qualification_file` 两张表；`openapi.yaml` 里已定义 7 个操作；原型资质库页的交互也已定稿。资质库本身是一个普通的增删改模块，工作量主要在前端页面和附件。
|
||||
- **难点在匹配，不在资质库**。从样本看（§1），企业资质在政府采购项目里多数是**评分项**，不是资格条件；而且大量「证书」要求是**产品证书**（节能认证、CCC、商用密码）或**人员证书**，资质库管不了，必须先排除。
|
||||
- **匹配不调模型**：按 IT 集成常见证书建一张类别词表，招标侧的要求、投标文字层、资质库三方都映射到类别再比较。认不出类别的，不做判断，写进检查覆盖范围。
|
||||
- **证据有两个来源，可信度不同**：投标文字层（比如投标文件里的「资质情况表」）上读到的有效期和等级，有原文出处，按清单项定级；只有资质库记录、投标文件那边是扫描件或没写日期时，**降一级**，说明里写明「按资质库记录」。
|
||||
- **资质库是空的就不做资质库核对**，只在覆盖范围里写一句。不能因为用户没录，就报一片「未覆盖」。
|
||||
|
||||
## 1. 样本里的资质要求长什么样
|
||||
|
||||
在 S01–S10 读标结果里筛出和证书有关的清单项（`evals/out/runs/fix3`），分成四种：
|
||||
|
||||
| 种类 | 例子 | 清单类别 | 资质库能不能管 |
|
||||
|---|---|---|---|
|
||||
| 企业资质（资格条件） | 电子与智能化工程专业承包资质、《安全生产许可证》（S01） | 资格条件 + 无效 | **能**，致命 |
|
||||
| 企业资质（评分项） | ISO 27001 / 9001 / 20000（S09）、CCRC 信息安全服务资质一级、CCIA 一级（S01） | 评分 | **能**，重要 |
|
||||
| 软件著作权（评分项） | 「虚拟化云平台软件计算机软件著作权登记证书（1 分）」、「软件著作权证书（3 分）」 | 评分 | 部分：软著长期有效、没有等级，只能看有没有 |
|
||||
| 产品证书 | 节能产品认证、CCC、商用密码产品认证、IPv6 Ready、网络安全专用产品检测证书 | 技术参数 / 无效 | **不能**：证书是厂商的、跟着产品走 |
|
||||
| 人员证书 | 「虚拟化维护人员具有虚拟化认证证书」 | 技术参数 | **不能**：人员库是 V1 |
|
||||
|
||||
结论：
|
||||
|
||||
1. 政府采购项目不能把和项目无关的资质设为资格条件，所以企业资质出现在资格条件里的少（10 份里只有 S01），多数在评分项里。这样一来，资质问题大多是「重要」，不是「致命」。
|
||||
2. 产品证书和人员证书必须先排除，否则资质库会对它们报「未覆盖」，造成大量误报。
|
||||
3. 真实投标文件里的证书基本都是盖章扫描件。不少 IT 投标文件另附一张文字的「企业资质情况表」，列出证书名称、编号和有效期，这是投标文字层上唯一能读到有效期的地方。
|
||||
|
||||
## 2. 资质库（FR-M6-08）
|
||||
|
||||
### 2.1 数据
|
||||
|
||||
用基线里已有的两张表，**不加列、不加迁移**：
|
||||
|
||||
- `qualification`：名称、类型（资质证书 / 体系认证 / 软件著作权 / 其他）、等级、证书编号、发证机构、有效期起止（「有效期至」为空表示长期有效）。
|
||||
- `qualification_file`：附件。对象键 `t/<tenant>/q/<qualification>/<file>`，用**企业级数据密钥**加密（DM4）。
|
||||
|
||||
证书类别（§3.1）在用到时从名称和类型算出来，不存库。词表改了以后，旧记录不用迁移。
|
||||
|
||||
### 2.2 接口
|
||||
|
||||
按 `openapi.yaml` 现有的 7 个操作实现：列表（可按类型筛）、新增、修改、删除（连同附件）、挂附件（走现有的分片上传，`purpose = qualification_file`）、附件下载地址、删除附件。只加两处：
|
||||
|
||||
- `Qualification` 响应加一个字段 `late_for`：进行中的项目里，投标截止日晚于这张证书「有效期至」的项目（项目编号、名称、截止日）。原型里的「N 张证书会在进行中项目的投标截止前到期」提醒就靠这个字段。「进行中」指状态是跟进中、编制中、已检查，且截止日不早于今天。
|
||||
- 列表接口加关键词参数 `q`，按名称、编号、发证机构搜索。
|
||||
|
||||
权限点用已有的 `qualification.edit`。增删改和附件操作都写审计：`qualification.create / update / delete`、`qualification_file.attach / delete`，修改记录前后的值。不扣额度。
|
||||
|
||||
### 2.3 校验
|
||||
|
||||
- 名称必填；「有效期至」必须晚于「有效期起」。
|
||||
- 证书编号、「有效期至」：原型要求必填（长期有效的打开开关），**界面按原型必填，接口保持可空**，因为以后从投标文件批量导入时不一定读得全。
|
||||
- 附件：PDF / JPG / PNG，单个不超过 20 MB，一条资质可以挂多个附件。
|
||||
|
||||
### 2.4 删除
|
||||
|
||||
删除是硬删：同时删行、删对象、写审计。原型在确认框之外还有「撤销」提示，**这一步不做撤销**（QL6）：要撤销就得软删除，而软删除和「彻底删除」（G10）冲突；确认框已经够了。已导出的报告不受影响，因为报告里存的是生成时的快照。
|
||||
|
||||
企业注销时按 `data-model.md` §6.1 的顺序删资质库，企业级密钥一并销毁。
|
||||
|
||||
### 2.5 前端
|
||||
|
||||
照原型 `qualifications.html` 实现：侧栏「资质库」（图标 `award`）、类型分段筛选、关键词搜索、按「有效期至」排序（长期有效的排最后）、到期提醒条、新增 / 编辑对话框（日期选择器上标出进行中项目的截止日）、附件上传和预览、删除确认。页面底部注明「业绩、人员、历史标书等资产库在 V1 提供」。
|
||||
|
||||
## 3. 资质匹配（FR-M3-05）
|
||||
|
||||
### 3.1 证书类别词表
|
||||
|
||||
`check/qualification.py` 里放一张词表，规则集版本跟着升（2026.11-r4）。每个类别包括：别名（含国标等同写法）、等级写法，以及等级怎么比（数字越大越高，还是「一级」最高）。初版覆盖 IT 集成常见的企业资质：
|
||||
|
||||
| 类别 | 别名例子 | 等级 |
|
||||
|---|---|---|
|
||||
| ISO 9001 质量 | GB/T 19001 | 无 |
|
||||
| ISO 14001 环境 | GB/T 24001 | 无 |
|
||||
| ISO 45001 职业健康安全 | OHSAS 18001、GB/T 45001、GB/T 28001 | 无 |
|
||||
| ISO 27001 信息安全 | GB/T 22080 | 无 |
|
||||
| ISO 20000 IT 服务 | GB/T 24405 | 无 |
|
||||
| ISO 22301 业务连续性 | GB/T 30146 | 无 |
|
||||
| CMMI | 能力成熟度模型集成 | 1–5，大为高 |
|
||||
| 信息系统建设和服务能力 | CS、CS1–CS5 | 1–5，大为高 |
|
||||
| ITSS 运维 | 信息技术服务标准、运行维护 | 一级最高 |
|
||||
| CCRC 信息安全服务资质 | 中国网络安全审查技术与认证中心；子类：安全集成、风险评估、应急处理、软件安全开发等 | 一级最高 |
|
||||
| CCIA 信息系统业务安全服务资质 | 中国网络安全产业联盟 | 一级最高 |
|
||||
| 电子与智能化工程专业承包 | 建筑业企业资质 | 一级 > 二级 |
|
||||
| 建筑智能化系统设计专项 | 工程设计资质 | 甲 > 乙 |
|
||||
| 涉密信息系统集成 | 涉密资质 | 甲 > 乙 |
|
||||
| 安全生产许可证 | | 无 |
|
||||
| 软件著作权 | 计算机软件著作权登记证书、软著 | 无，长期有效 |
|
||||
|
||||
**排除词**：要求里出现「产品」「设备」「所投」「厂商」「制造商」「节能」「环境标志」「CCC」「3C」「商用密码产品」「人员」「工程师」「项目经理」这类主体时，判定为产品证书或人员证书，不进资质匹配，仍按现在的流程处理（找响应、扫描件兜底）。
|
||||
|
||||
认不出类别、但清单类别是资格条件或评分项、文字里又有「证书 / 资质 / 认证」字样的，计入覆盖范围：「N 条资质要求没认出是哪类证书，有效期和等级没有核对」。
|
||||
|
||||
### 3.2 三方怎么对上
|
||||
|
||||
对每条进入资质匹配的清单项（类别是资格条件或评分项，且认出了证书类别）：
|
||||
|
||||
1. **招标侧**：类别、要求的等级（「CS3 级及以上」「一级」）、子类（CCRC 的「安全集成」）。要求原文就是招标侧出处。
|
||||
2. **投标文字层**：在响应匹配找到的证据句附近，以及投标文件里写着同一类别的表格行中，读证书编号、等级、有效期（「有效期至」「有效期：A 至 B」「截止日期」）。日期解析复用 `rules.py` 里的写法。只取**和这个类别同一行、或同一段落里只有这一张证书**的日期；附近出现两张以上证书、日期归属不清时不读。
|
||||
3. **资质库**：同一类别的记录。同类有几条（旧证书和换发后的新证书）时取最有利的一条：有效期最晚、等级最高。
|
||||
|
||||
有效期比较用项目基本信息里的**投标截止日**（人工改过的为准），不用今天。「有效期至」当天仍算有效，即 `有效期至 < 截止日` 才算过期。项目没有截止日时，不比有效期，写进覆盖范围。
|
||||
|
||||
### 3.3 规则和定级
|
||||
|
||||
「按清单项定级」：资格条件 → 致命，评分项 → 重要（沿用 `findings.severity`）。
|
||||
|
||||
| 规则 | 什么时候报 | 证据来源 | 级别 |
|
||||
|---|---|---|---|
|
||||
| `QUAL.EXPIRED` | 证书在投标截止日已过期 | 投标文字层 | 按清单项 |
|
||||
| | | 只有资质库 | 降一级（致命 → 重要，重要不变） |
|
||||
| `QUAL.LEVEL_LOW` | 等级能比较，且低于要求 | 投标文字层 | 按清单项 |
|
||||
| | | 只有资质库 | 降一级 |
|
||||
| `QUAL.NOT_COVERED` | 投标文字层没找到（结论是「未找到」或「扫描件」），而且资质库**有记录但没有这一类** | 资质库 | 重要（不给致命：资质库可能没录全） |
|
||||
| （不报问题） | 资质库里有、而且有效、等级够 | | 扫描件兜底那条「请人工核对」保留，说明里补一句：资质库里有《X》（编号…，有效期至…），请核对扫描件里附的是这一张 |
|
||||
|
||||
规定：
|
||||
|
||||
- **投标文字层和资质库冲突时，以投标文件为准**。投标文件里的日期已过期、资质库里有换发后的新证书时，仍按投标文字层报 `QUAL.EXPIRED`，说明里写「资质库里有有效期至 … 的新证书，投标文件附的可能是旧证书」。评审看的是投标文件。
|
||||
- **一条清单项只出一个资质问题**。资质问题比扫描件兜底的「请人工核对」更具体，有资质问题时代替那一条；投标文件是文字版且确实没找到（「未找到响应」，致命）时，保留原问题，只在说明里补资质库的情况（「资质库里有这张证书，可能忘了附」）。
|
||||
- **软件著作权**不查有效期和等级，只在扫描件兜底说明里补「资质库里有 N 件软件著作权」。要求里写了具体软件名的，也不按名称硬配：软件名的写法太散。
|
||||
- **CCRC 子类**：要求写了子类（安全集成），资质库记录的名称里没有这个子类，按 `QUAL.NOT_COVERED` 报，说明写「资质库里的 CCRC 证书没写服务类别，请核对是不是『安全集成』」，级别是提示。
|
||||
- **资质库是空的**：所有资质库规则都不跑，覆盖范围写「资质库还没有录入资质，有效期和等级没有按资质库核对」。查标页在覆盖范围旁边放一个去资质库的链接。
|
||||
- 说明只写事实，不写整改建议。原型 f6 里「请上传换发后的证书」这一句去掉，改成「按资质库记录，有效期至 2026年11月15日，早于投标截止日 11月20日」。
|
||||
|
||||
### 3.4 问题的存法和出处
|
||||
|
||||
- `finding.type = qualification`，`detector = rule`，`rule_code` 是上面的编号，`checklist_item_id` 填对应清单项，`match_key = rule:QUAL.EXPIRED:<清单项>`，复查沿用按现有机制走。
|
||||
- `detail` 里存：`kind`（过期 / 等级不足 / 未覆盖）、`source`（`bid_text` / `library`）、截止日、要求的等级，以及用到的资质库记录的**快照**（编号、名称、等级、有效期、记录 id）。资质库记录以后改了、删了，旧检查的问题和报告不变。
|
||||
- 出处：招标侧照常挂清单项的原文出处；投标文字层来源的挂投标侧句子；资质库来源的**没有投标侧出处**，界面和报告显示「依据：资质库记录」块（名称、编号、有效期，能点开那条记录和附件）。这一点要你确认（QL2）。
|
||||
- 覆盖范围加一节「资质核对」：资质库有几条、本次核对了几条资质要求、几条按资质库判断、几条没认出类别、产品证书和人员证书各排除了几条。
|
||||
|
||||
### 3.5 在流水线里的位置
|
||||
|
||||
放在 `runner.py` 的响应匹配和扫描件兜底之后、`rules.run` 之前，读一次本企业的资质库，不调模型、不计费。复查时重新算：资质库可能改过，结果不复用。
|
||||
|
||||
## 4. 不在这一步做的
|
||||
|
||||
| 不做 | 原因 |
|
||||
|---|---|
|
||||
| D14 证书主体和投标人不一致（子公司、曾用名） | 不在 FR-M3-05 的三种预警里；证书主体只在扫描件上；资质库挂在企业主体下，主体本来就一致。等 OCR（S5）后再看 |
|
||||
| D15 业绩 / 人员证明的时间窗口 | 业绩库、人员库是 V1 |
|
||||
| 产品证书核对 | 厂商的证书，不是用户的资质（红线 5：不从外部补数据） |
|
||||
| 从投标文件或附件里自动识别、批量导入资质 | 要 OCR / 多模态；MVP 只手工录入（01-scope-roles：「手工录入 + 有效期」） |
|
||||
| 读标清单上显示「资质库：ISO 9001 有效期至 …」 | 并入第 6 步前端补齐 |
|
||||
| 软著按软件名称配对、按件数核对评分 | 写法太散，认不准的不报 |
|
||||
|
||||
## 5. 评测
|
||||
|
||||
- **类别识别**：把 S01–S10 读标结果里和证书有关的清单项全部人工标注（企业资质 / 软著 / 产品证书 / 人员证书 / 无关，再加类别和等级），约几十条，作为词表的单元测试。读标留出集的 S03、S06、S09 不在开发里看，词表写完后跑一次，只用来报数字。
|
||||
- **规则**：每条规则配正例和反例单元测试：截止日当天到期不报；同类有新证书也有旧证书取新的；等级写法认不出时不比较；产品证书不进匹配；资质库空不报。
|
||||
- **评测集**：生成器现在不生成证书文字。给风格 A / B 的规矩投标文件加一张「企业资质情况表」（虚构的证书、编号、有效期），注入 D12（有效期早于截止日；整张表的证书都过期）和「等级不足」两类问题，按 GUIDELINES 的流程请 Fable 复核、你抽查。资质库那一侧在评测里用虚构的资质库模拟，分「空 / 全 / 缺一类 / 有过期」四档。
|
||||
- **局限**：评测集里的证书表是看着词表生成的，分数说明不了泛化。国动的真实投标文件到了以后，请你按自己公司的真实证书录资质库，再跑一次，这才是这一步真正的检验。
|
||||
|
||||
## 6. 工作量和顺序
|
||||
|
||||
1. 后端 `qualification` 模块：增删改、附件、`late_for`、审计，集成测试（含行级安全、企业级密钥）。约半天。
|
||||
2. 前端资质库页。约半天。
|
||||
3. 类别词表、标注样本、`check/qualification.py`、接入流水线、覆盖范围、问题渲染和报告。约 1 天。
|
||||
4. 评测集加证书表和注入，复核。约半天。
|
||||
|
||||
## 7. 待确认事项
|
||||
|
||||
| 编号 | 事项 | 建议 |
|
||||
|---|---|---|
|
||||
| QL1 | 匹配方式 | **规则 + 证书类别词表，不调模型**。认不出的不判断、写进覆盖范围。理由：资质名称是有限集合，规则可解释，不花钱 |
|
||||
| QL2 | 只有资质库记录、没有投标侧出处时能不能出问题 | **能出，降一级**，出处显示「依据：资质库记录」。资质库是用户自己录的数据，不是 AI 结论，和红线 2「AI 结论要能回溯原文」不冲突；如果不出，扫描件为主的真实投标文件就基本查不出过期 |
|
||||
| QL3 | 「未覆盖」怎么报 | 资质库**有记录但没有这一类**时报「重要」；资质库是空的不报，只写覆盖范围 |
|
||||
| QL4 | 投标文件和资质库冲突时 | **以投标文件为准**，说明里提一句资质库里有新证书 |
|
||||
| QL5 | 免费版能不能用资质库 | **能用**。01-scope-roles 把资质库写在专业版下，但它不花额度、没有成本；免费版只有 1 个项目，用来试用完整的查标链路，缺了资质库体验就不完整 |
|
||||
| QL6 | 删除要不要撤销 | **不要**，只留确认框；撤销需要软删除，和「彻底删除」冲突 |
|
||||
| QL7 | D14（主体不一致）、D15（时间窗口） | **不在这一步做**，评测规范里这两类的实现阶段改为「OCR 之后 / V1」 |
|
||||
|
||||
## 8. 落地记录（2026-11-04）
|
||||
|
||||
和上文设计不一致、或实现时补的，记在这里：
|
||||
|
||||
- **一类证书一个问题**（改 §3.3「一条清单项只出一个资质问题」）：一条评分项常写几类证书（S07「ITSS 三级得 1 分；CS3 及以上得 2 分」），一张过期、一张等级不够是两件事，合成一条时规则编号只能取一个。改为每条清单项里每类证书出一个问题，标题写证书名（「证书等级低于要求：信息系统建设和服务能力等级」），`match_key = rule:QUAL.*:<清单项>:<证书类别>`。
|
||||
- **评分项不逐条找响应的也查**：applicability 把没写「提供……证书」的评分项跳过了（「评分标准本身」），而企业资质多数就在评分项里。资质匹配改为看所投包里的全部清单项；这类条目没有响应结论，投标文字层和资质库的过期、等级照常提示，「未覆盖」不报（不知道投标人报不报这一项分）。
|
||||
- **等级按证书各读各的**：要求里属于这一类证书的那一段（从它的名称到下一类证书的名称）里读等级；投标侧先看短的格子（等级栏），证书编号里常带等级字样（「CS3-3201-…」）；大写数字（「贰级」）也认。
|
||||
- **响应错位规则收窄**（`check/deviation.py`）：资质情况表的名称格（「安全生产许可证」，比要求短、以证书名结尾）不算「照抄的要求格」，右边的编号、有效期不算「响应对不上」。端到端测试里发现的。
|
||||
- **营业执照、法人证书、联合体的资质认定规则**不算「没认出类别的资质要求」，不进覆盖范围的计数。
|
||||
- **出处**：资质问题挂清单项自己的招标侧出处（`Hit.tender_refs`）；问题接口的 `rule` 改为规则问题都带（原来挂了清单项就不带）；报告模板 v2 在问题明细里写「依据：资质库记录《…》」。
|
||||
- **前端**：资质库页和对话框（日期可直接键入，接受 2026/11/20、2026年11月20日等写法；日历弹层留到第 6 步）；查标页资质问题显示「依据：资质库记录」块，墨色（用户录入的数据，不用 AI 出处的蓝铅笔色）。
|
||||
- 评测见 `check-eval.md` §13。
|
||||
@@ -4,6 +4,22 @@
|
||||
|
||||
---
|
||||
|
||||
## QL1–QL7 · 2026-11-04 · 资质库和资质匹配：全部按建议
|
||||
|
||||
依据 `docs/architecture/qualification-plan.md` §7。
|
||||
|
||||
| # | 决策 | 理由 |
|
||||
|---|---|---|
|
||||
| QL1 | 资质匹配用规则 + 证书类别词表，不调模型；认不出类别的不判断，写进检查覆盖范围 | 资质名称是有限集合，规则可解释、不花钱 |
|
||||
| QL2 | 投标侧没有出处、只有资质库记录时也出问题，级别降一级，出处显示「依据：资质库记录」 | 资质库是用户自己录的数据，不是 AI 结论，不违反红线 2；真实投标的证书多是扫描件，不出就基本查不出过期 |
|
||||
| QL3 | 「未覆盖」只在资质库有记录、但没有这一类时报，级别「重要」；资质库是空的不报，只写覆盖范围 | 用户没录不等于没有；空库报一片未覆盖是误报 |
|
||||
| QL4 | 投标文字层和资质库冲突时以投标文件为准，说明里提资质库里有新证书 | 评审看的是投标文件 |
|
||||
| QL5 | 免费版也能用资质库 | 不花额度、没有成本；免费版用来试用完整的查标链路 |
|
||||
| QL6 | 删除资质不做撤销，只留确认框 | 撤销要软删除，和「彻底删除」（G10）冲突 |
|
||||
| QL7 | D14（证书主体不一致）、D15（业绩 / 人员时间窗口）不在第 4 步做 | 不在 FR-M3-05 的三种预警里；证书主体只在扫描件上；业绩、人员库是 V1 |
|
||||
|
||||
- **影响**：资质库不加迁移；`Qualification` 响应加 `late_for`、列表加 `q`；规则集升到 2026.11-r4；评测规范 D14、D15 的实现阶段改为「OCR 之后 / V1」；原型 f6 的「请上传换发后的证书」不进产品（说明不写整改建议）。
|
||||
|
||||
## E2 · 2026-11-04 · 先修留出集暴露的 5 处，国动真实投标文件之后再跑
|
||||
|
||||
- **决策**：留出集跑完后（`check-eval.md` §11），先修暴露的 5 处（响应方式识别过度触发、偏离栏只认开发集写法、附加条件 / 另报价按措辞枚举、「精确到年月日」误报、PDF 异体字），国动真实投标文件用修好以后的代码跑，而不是冻结代码。
|
||||
|
||||
Reference in New Issue
Block a user