128 lines
4.8 KiB
Markdown
128 lines
4.8 KiB
Markdown
# 文档类型与评查组关联 — 老项目分析 & 新方案
|
||
|
||
## 一、老项目模型(docauditai)
|
||
|
||
### 三层间接绑定
|
||
|
||
```
|
||
DocumentType → TopLevelGroup(s) → ChildGroups → EvaluationPoints
|
||
│ │ │ │
|
||
│ evaluation_ │ pid=0 │ pid={top} │ evaluation_
|
||
│ point_groups │ │ │ point_groups_id
|
||
│ _ids (JSONB) │ │ │
|
||
```
|
||
|
||
- `document_types.evaluation_point_groups_ids` — JSONB 数组,存顶层组 ID,如 `[3]` 或 `[1,5]`
|
||
- `evaluation_point_groups` — 两级树:`pid=0` 是顶层组,"pid>0" 是子组
|
||
- `evaluation_points` — 属于子组,含 `extraction_config`(提取规则)和 `evaluation_config`(评查规则),按 `area` + `document_attribute_type` 过滤
|
||
|
||
### 运行时解析流程
|
||
|
||
```
|
||
doc_type_code
|
||
→ 查 document_types.evaluation_point_groups_ids[0]
|
||
→ 查 evaluation_point_groups WHERE pid = {top_group_id}
|
||
→ 查 evaluation_points WHERE evaluation_point_groups_id = {child_id}
|
||
→ 按 area + attribute_type 过滤
|
||
→ 返回最终评查点列表
|
||
```
|
||
|
||
---
|
||
|
||
## 二、新平台模型(leaudit-platform)
|
||
|
||
### 直接绑定
|
||
|
||
```
|
||
DocumentType ──→ RuleTypeBinding ──→ RuleSet ──→ RuleVersions
|
||
```
|
||
|
||
**`leaudit_rule_type_bindings`**:
|
||
| 字段 | 说明 |
|
||
|------|------|
|
||
| `doc_type_id` | FK → leaudit_document_types.id |
|
||
| `rule_set_id` | FK → leaudit_rule_sets.id |
|
||
| `binding_mode` | "explicit"(一对一)/ "inherit"(继承) |
|
||
| `region` | 地区隔离 |
|
||
| `priority` | 同一 doc_type 多个 rule_set 时的优先级 |
|
||
|
||
**运行时**(已在 auditServiceImpl.py 实现):
|
||
```sql
|
||
SELECT b.rule_set_id, rs.current_version_id
|
||
FROM leaudit_rule_type_bindings b
|
||
JOIN leaudit_rule_sets rs ON rs.id = b.rule_set_id
|
||
WHERE b.doc_type_id = :doc_type_id
|
||
AND b.region = :region
|
||
AND b.is_active = true
|
||
ORDER BY b.priority DESC
|
||
```
|
||
|
||
### 与老模型的关键差异
|
||
|
||
| | 老 | 新 |
|
||
|---|---|---|
|
||
| 绑定粒度 | 文档类型 → 顶层组(间接) | 文档类型 → 规则集(直接) |
|
||
| 评查点层级 | 三级(类型→组→子组→点) | 两级(类型→规则集→版本) |
|
||
| 地区隔离 | evaluation_points.area | rule_type_bindings.region |
|
||
| 规则版本 | 无版本概念 | 规则集 + 版本管理 |
|
||
|
||
实际上新模型更简洁:老系统里的"顶层组"≈新系统的"规则集",老系统里的"子组+评查点"≈新系统的"规则版本内容"。新系统去掉了中间的子组层级。
|
||
|
||
---
|
||
|
||
## 三、已落地 vs 待落地
|
||
|
||
### ✅ 已落地
|
||
|
||
| 项 | 说明 |
|
||
|----|------|
|
||
| `leaudit_document_types` 表 | 有 20 条种子数据,含 code/name/entry_module_id/prompt_config |
|
||
| `leaudit_rule_sets` 表 | 规则集 + 版本管理 |
|
||
| `leaudit_rule_type_bindings` 表 | 20 条绑定记录,已全部配对 |
|
||
| 运行时绑定解析 | auditServiceImpl.Run() 中查 bindings → 找 rule_set + version |
|
||
| `GET /api/document-types` | 刚加的,返回 id/name/code |
|
||
|
||
### ❌ 待落地
|
||
|
||
| 优先 | 项 | 说明 |
|
||
|------|----|------|
|
||
| 高 | 文档类型 CRUD 后端 | POST/PUT/DELETE /api/document-types |
|
||
| 高 | 规则绑定 CRUD 后端 | 在文档类型编辑中配 rule_set_id(s) |
|
||
| 高 | 前端文档类型管理页 | 对应旧 `document-types._index.tsx` |
|
||
| 中 | 规则绑定前端 UI | 文档类型编辑页中选规则集的控件 |
|
||
| 中 | 前端规则集选择器 | 对接 `/api/rule-sets` 或现有规则接口 |
|
||
| 低 | prompt_config 编辑 | 每个文档类型的提示词模板配置 |
|
||
|
||
---
|
||
|
||
## 四、推荐接入方案
|
||
|
||
### 第 1 步:文档类型 CRUD 后端
|
||
|
||
```
|
||
GET /api/document-types ← 已实现
|
||
POST /api/document-types ← 新增
|
||
PUT /api/document-types/{id} ← 新增
|
||
DELETE /api/document-types/{id} ← 新增
|
||
```
|
||
|
||
字段:`code`, `name`, `description`, `entry_module_id`, `prompt_config`, `rule_set_ids`(一次性处理绑定)
|
||
|
||
### 第 2 步:规则绑定 CRUD
|
||
|
||
两种方案:
|
||
- **方案 A**(推荐):绑定内嵌到文档类型接口。创建/更新文档类型时传 `rule_set_ids: [21, 31]`,后端自动维护 `leaudit_rule_type_bindings`。
|
||
- **方案 B**:独立绑定接口 `POST/DELETE /api/rule-type-bindings`。
|
||
|
||
推荐方案 A,因为绑定是文档类型的属性,一起管理更自然。
|
||
|
||
### 第 3 步:前端文档类型管理页
|
||
|
||
参考旧前端 `document-types._index.tsx` / `document-types.new.tsx`,用新 API 重写:
|
||
- 列表页:表格展示 code/name/entry_module/规则集数量
|
||
- 新建/编辑页:表单填 code/name/entry_module,多选规则集
|
||
|
||
### 第 4 步:上传页关联
|
||
|
||
上传时将 `typeCode` 写入 `leaudit_documents.type_id` → 运行时自动找绑定 → 加载规则集 → 执行评查。整个链路已通,只需确保文档类型数据存在。
|