docs: add govdoc migration analysis and implementation notes
This commit is contained in:
wren
@@ -0,0 +1,411 @@
|
||||
# 内部公文规则补齐实施清单
|
||||
|
||||
## 1. 文档目的
|
||||
|
||||
本文档只回答一个实施问题：
|
||||
|
||||
- 在**不改变旧项目内部公文业务语义**的前提下，如何把旧项目 `31` 条规则按当前 `leaudit-platform` 的 `govdoc` 规范补齐回来
|
||||
|
||||
本文档不讨论“是否需要重新设计一套公文规则引擎”，因为当前结论已经明确：
|
||||
|
||||
- 旧项目和当前平台使用的是同一套 `govdoc DSL`
|
||||
- 当前平台 `govdoc_engine` 已具备承接旧规则的大部分执行能力
|
||||
- 当前缺的主要不是引擎能力，而是**规则内容尚未完整迁入**
|
||||
|
||||
---
|
||||
|
||||
## 2. 结论先行
|
||||
|
||||
当前内部公文规则补齐工作，应按下面这个判断推进：
|
||||
|
||||
1. **规则 DSL 不需要重做**
|
||||
2. **现有执行器不需要先推翻重写**
|
||||
3. **第一优先级是把旧项目规则语义按当前平台 YAML 补齐**
|
||||
4. **只有在迁入后验证发现误报/漏报时，才对角色识别、提示词、个别 check 实现做小范围修正**
|
||||
|
||||
换句话说：
|
||||
|
||||
- 当前不是“先开发引擎，再迁规则”
|
||||
- 而是“先补规则，再基于验证结果修实现细节”
|
||||
|
||||
---
|
||||
|
||||
## 3. 当前平台承接能力盘点
|
||||
|
||||
## 3.1 DSL 结构已对齐
|
||||
|
||||
当前平台规则文件：
|
||||
|
||||
- `rules/govdoc/govdoc_general/rules.yaml`
|
||||
|
||||
旧项目规则文件：
|
||||
|
||||
- `/home/wren-dev/Porject/govdoc-audit/rules/govdoc_general/rules.yaml`
|
||||
|
||||
两边都是：
|
||||
|
||||
- `metadata`
|
||||
- `extract`
|
||||
- `rules`
|
||||
|
||||
因此补齐规则时，不需要把规则改写成合同模块那套 DSL。
|
||||
|
||||
---
|
||||
|
||||
## 3.2 当前平台已支持的 check 类型
|
||||
|
||||
旧项目规则实际用到的 check 类型如下：
|
||||
|
||||
- `ai`
|
||||
- `attachment_marker_style`
|
||||
- `confused_pair`
|
||||
- `cross_role`
|
||||
- `font`
|
||||
- `forbid_chars`
|
||||
- `forbid_phrase`
|
||||
- `hierarchy`
|
||||
- `punctuation`
|
||||
- `regex_forbid`
|
||||
- `wenzhong_whitelist`
|
||||
|
||||
这些 check 类型当前平台都已经存在于 `govdoc_engine` 中。
|
||||
|
||||
因此从实施角度判断：
|
||||
|
||||
- **绝大多数旧规则可以直接按 YAML 迁入**
|
||||
|
||||
---
|
||||
|
||||
## 3.3 当前平台已具备的 role 识别前提
|
||||
|
||||
当前 `role_tagger_rule.py` 已可识别：
|
||||
|
||||
- `title`
|
||||
- `doc_number`
|
||||
- `date`
|
||||
- `recipient`
|
||||
- `signature`
|
||||
- `attachment_marker`
|
||||
- `attachment_title`
|
||||
- `heading_1`
|
||||
- `heading_2`
|
||||
- `heading_3`
|
||||
- `heading_4`
|
||||
- `body`
|
||||
|
||||
这意味着旧项目规则里依赖以下 role 的规则已有运行前提：
|
||||
|
||||
- `heading_1`
|
||||
- `heading_2`
|
||||
- `heading_3`
|
||||
- `heading_4`
|
||||
- `body`
|
||||
- `attachment_marker`
|
||||
- `any`
|
||||
|
||||
结论是：
|
||||
|
||||
- **旧项目规则在“选段目标”这一层，没有明显的结构性阻塞**
|
||||
|
||||
---
|
||||
|
||||
## 3.4 当前平台现状不是“没规则”，而是“规则过少”
|
||||
|
||||
当前平台内部公文规则现状：
|
||||
|
||||
- `2` 个规则组
|
||||
- `6` 条规则
|
||||
|
||||
当前保留的规则主要是：
|
||||
|
||||
- 标题必填
|
||||
- 发文字号必填
|
||||
- 署名必填
|
||||
- 日期必填
|
||||
- 文种白名单
|
||||
- 附件标记样式
|
||||
|
||||
这属于：
|
||||
|
||||
- **最小可运行规则集**
|
||||
|
||||
不属于：
|
||||
|
||||
- **旧项目完整规则语义**
|
||||
|
||||
---
|
||||
|
||||
## 4. 旧项目 31 条规则迁移分类
|
||||
|
||||
为避免后续实施发散，旧规则应先按“迁移方式”分组，而不是按代码文件分组。
|
||||
|
||||
## 4.1 A 类：可直接迁入的确定性规则
|
||||
|
||||
这类规则特点是：
|
||||
|
||||
- 不依赖 LLM 推理
|
||||
- 主要依赖正则、字体、标点、层级、固定短语等确定性判断
|
||||
- 迁移成本最低
|
||||
- 最适合作为第一批补齐内容
|
||||
|
||||
包含如下规则：
|
||||
|
||||
### 标题类
|
||||
|
||||
- `GW-T-002` 标题不可有“请求+请示”重复
|
||||
- `GW-T-003` 标题不可有“上报+报告”重复
|
||||
- `GW-T-004` 标题介词连用
|
||||
- `GW-T-005` 标题文种白名单
|
||||
|
||||
### 发文字号类
|
||||
|
||||
- `GW-N-001` 发文字号必须用六角括号
|
||||
- `GW-N-002` 发文字号不可加“第”字
|
||||
- `GW-N-003` 发文字号顺序号不编虚位
|
||||
|
||||
### 格式类
|
||||
|
||||
- `GW-F-001` 主标题用方正小标宋简体二号
|
||||
- `GW-F-002` 一级标题用黑体三号
|
||||
- `GW-F-003` 二级标题用楷体三号
|
||||
- `GW-F-004` 正文用仿宋三号
|
||||
- `GW-F-005` 附件后不加冒号
|
||||
- `GW-F-006` 不使用“此页无正文”
|
||||
- `GW-F-007` 附件项末尾不加标点
|
||||
- `GW-F-008` 三级标题用仿宋三号
|
||||
- `GW-F-009` 四级标题用仿宋三号
|
||||
- `GW-F-010` 附件标记用黑体三号不加粗
|
||||
|
||||
### 层级类
|
||||
|
||||
- `GW-H-001` 层级序号格式
|
||||
- `GW-H-002` 二级标题换行不带句号
|
||||
|
||||
### 标点类
|
||||
|
||||
- `GW-P-001` 多书名号/引号并列不加顿号
|
||||
- `GW-P-002` 句内括号末尾不加标点
|
||||
- `GW-P-003` 引号嵌套不规范
|
||||
|
||||
### 文字提法类
|
||||
|
||||
- `GW-W-001` 易混淆词使用
|
||||
- `GW-W-003` 成文日期用阿拉伯数字
|
||||
- `GW-W-004` 成文日期不编虚位
|
||||
|
||||
这批规则的实施结论：
|
||||
|
||||
- **优先补**
|
||||
- **优先恢复旧 rule_id**
|
||||
- **优先保持旧 messages / severity / category 语义**
|
||||
|
||||
---
|
||||
|
||||
## 4.2 B 类：可迁入，但依赖 LLM 提示词稳定性的语义规则
|
||||
|
||||
这类规则当前平台格式和引擎都支持，但它们的稳定性更依赖：
|
||||
|
||||
- 提示词是否原样保留
|
||||
- 实体抽取结果是否稳定
|
||||
- role 识别和上下文拼接是否足够
|
||||
|
||||
包含如下规则：
|
||||
|
||||
### 标题类
|
||||
|
||||
- `GW-T-001` 标题文种合规性
|
||||
- `GW-T-006` 标题回行词意完整
|
||||
- `GW-T-008` 标题字体（语义实体通道示例）
|
||||
|
||||
### 文字表述类
|
||||
|
||||
- `GW-W-002` 简称使用规范
|
||||
|
||||
### 发文机关类
|
||||
|
||||
- `GW-S-001` 发文机关署名不能用简称
|
||||
- `GW-S-002` 发文机关确定严谨性
|
||||
|
||||
这批规则的实施结论：
|
||||
|
||||
- **可以按 YAML 直接迁入**
|
||||
- **不需要先开发新 check**
|
||||
- **但迁入后必须做专项样本验证**
|
||||
|
||||
这里的重点不是“能不能跑”，而是：
|
||||
|
||||
- **误报率是否可接受**
|
||||
- **fail 条件是否与旧项目提示词语义一致**
|
||||
|
||||
---
|
||||
|
||||
## 4.3 C 类：当前已有最小替代规则，但语义仍未完全恢复
|
||||
|
||||
当前平台已有的 6 条规则中，有一部分与旧语义有关联，但并不等价。
|
||||
|
||||
例如：
|
||||
|
||||
- `govdoc_wenzhong_whitelist`
|
||||
- `govdoc_attachment_marker_style`
|
||||
|
||||
问题不在于它们“错了”，而在于：
|
||||
|
||||
- 它们使用的是新命名
|
||||
- 它们只覆盖了旧规则中的一个点
|
||||
- 它们没有连带恢复同组其它规则
|
||||
|
||||
因此这类规则后续要按一个明确原则处理：
|
||||
|
||||
- **不是继续叠加 bootstrap 规则**
|
||||
- **而是回到旧项目规则语义集合，统一整理成正式规则集**
|
||||
|
||||
否则后面会出现：
|
||||
|
||||
- bootstrap 规则一套命名
|
||||
- 旧项目规则一套命名
|
||||
- 语义重叠但口径不同
|
||||
|
||||
这会直接破坏规则可追溯性和前端规则展示一致性。
|
||||
|
||||
---
|
||||
|
||||
## 5. 建议的实施顺序
|
||||
|
||||
## 5.1 第一阶段：规则集语义回正
|
||||
|
||||
这一阶段只做一件事：
|
||||
|
||||
- 把当前 `govdoc_general` 规则文件从“最小运行版”恢复到“旧项目正式规则版”
|
||||
|
||||
建议动作：
|
||||
|
||||
1. 以旧项目 `31` 条规则为基准
|
||||
2. 保留当前平台 `govdoc DSL` 结构不变
|
||||
3. 优先恢复旧 `rule_id / name / severity / category / messages`
|
||||
4. 把当前 6 条 bootstrap 规则合并回正式规则语义，而不是长期并存
|
||||
|
||||
这一阶段的目标不是调优，而是：
|
||||
|
||||
- **先把规则集语义补齐**
|
||||
|
||||
---
|
||||
|
||||
## 5.2 第二阶段：确定性规则验证
|
||||
|
||||
这一阶段重点验证 A 类规则：
|
||||
|
||||
- 正则规则是否命中正确
|
||||
- 字体规则是否受样式解析影响
|
||||
- 标点/层级规则是否存在明显误报
|
||||
|
||||
建议验证方式：
|
||||
|
||||
1. 选取一批旧项目正例/反例文档
|
||||
2. 对比迁移前后 `checked_rules / findings`
|
||||
3. 重点看是否出现“旧项目 fail，当前 pass”或“旧项目 pass，当前 fail”
|
||||
|
||||
这一阶段的验收重点是：
|
||||
|
||||
- **确定性规则尽量做到与旧项目结论一致**
|
||||
|
||||
---
|
||||
|
||||
## 5.3 第三阶段：语义规则验证
|
||||
|
||||
这一阶段只关注 B 类规则。
|
||||
|
||||
建议验证项：
|
||||
|
||||
1. 提示词是否与旧项目一致
|
||||
2. 上下文变量是否完整可用
|
||||
3. LLM 返回 `pass / warn / fail` 时，当前平台展示是否保持旧语义
|
||||
4. 是否出现明显漂移，例如该 pass 的规则被大量误报为 fail
|
||||
|
||||
这一阶段允许的改动是：
|
||||
|
||||
- 小范围调整 prompt
|
||||
- 小范围补上下文字段
|
||||
- 小范围修正实体输入
|
||||
|
||||
这一阶段不应做的事情是：
|
||||
|
||||
- 重新定义业务判定标准
|
||||
- 为了追求“看起来更智能”而改变旧规则语义
|
||||
|
||||
---
|
||||
|
||||
## 5.4 第四阶段：规则集治理接轨平台
|
||||
|
||||
当规则内容补齐并验证后，再处理平台治理问题：
|
||||
|
||||
- `type_id` 命名是否回归 `govdoc.general`
|
||||
- 规则版本记录如何写入平台规则治理链路
|
||||
- 规则列表、规则详情接口如何展示完整 metadata
|
||||
|
||||
这一步的重点是：
|
||||
|
||||
- **把已经恢复的旧业务规则集，真正纳入当前平台的规则版本治理**
|
||||
|
||||
而不是继续长期依赖固定文件路径硬编码。
|
||||
|
||||
---
|
||||
|
||||
## 6. 实施边界
|
||||
|
||||
## 6.1 可以做的事情
|
||||
|
||||
- 按当前 `govdoc DSL` 补旧规则 YAML
|
||||
- 复用当前 `govdoc_engine` 已有 check
|
||||
- 复用当前 role tagger
|
||||
- 对少量提示词或 role 识别做兼容性修正
|
||||
- 按当前平台规范接入规则列表、规则详情、版本记录
|
||||
|
||||
---
|
||||
|
||||
## 6.2 不应做的事情
|
||||
|
||||
- 把内部公文规则改写成合同 DSL
|
||||
- 因为当前有 6 条 bootstrap 规则，就以它们为最终标准
|
||||
- 在没有业务确认的情况下重命名旧规则语义
|
||||
- 为了迁移方便删除 `skipped`、`warning`、`pass` 三分态
|
||||
- 用“新平台习惯”替代旧项目正式审查语义
|
||||
|
||||
---
|
||||
|
||||
## 7. 当前建议的优先级
|
||||
|
||||
## P0：必须先补
|
||||
|
||||
- A 类确定性规则整体迁入
|
||||
- 旧规则 metadata 语义恢复
|
||||
- 旧 rule_id 体系恢复
|
||||
- 规则列表 / 规则详情能看到正式规则集
|
||||
|
||||
## P1：紧随其后
|
||||
|
||||
- B 类 LLM 语义规则迁入
|
||||
- 样本文档专项验证
|
||||
- 报告页中规则结果与旧项目口径对齐
|
||||
|
||||
## P2：最后收口
|
||||
|
||||
- `type_id` 命名统一
|
||||
- 规则版本治理正式接轨平台
|
||||
- 后台规则管理入口与平台其它文档类型规则治理一致
|
||||
|
||||
---
|
||||
|
||||
## 8. 最终结论
|
||||
|
||||
内部公文规则补齐这件事，现在不该再停留在“有没有 YAML”“格式支不支持”这个层面。
|
||||
|
||||
当前真实状态是：
|
||||
|
||||
- 平台格式已具备
|
||||
- 运行链路已具备
|
||||
- 承接 check 已具备
|
||||
- 缺的是**旧项目正式规则内容没有完整迁回**
|
||||
|
||||
因此下一步实施应按下面的最小原则推进：
|
||||
|
||||
> **不改业务语义，不重造引擎，先把旧项目 31 条规则按当前平台 `govdoc DSL` 补齐回来，再用样本文档验证执行效果。**
|
||||
Reference in New Issue
Block a user