851 lines
50 KiB
Markdown
851 lines
50 KiB
Markdown
# 企业数字资产处理与治理方案
|
||
|
||
> 文档状态：目标方案与实施基线
|
||
>
|
||
> 更新时间：2026-08-02
|
||
>
|
||
> 适用范围：帮道 APP 的知识、案例、SOP、陪练、考试、评测及相关数据资产
|
||
>
|
||
> 当前实现证据：[data-quality-audit.md](data-quality-audit.md)
|
||
>
|
||
> 接口事实：[API_INTEGRATION.md](API_INTEGRATION.md)
|
||
>
|
||
> 生产运维：[KNOWLEDGE_PLATFORM_RUNBOOK.md](KNOWLEDGE_PLATFORM_RUNBOOK.md)
|
||
|
||
## 1. 方案结论
|
||
|
||
本项目需要建设的不是一个“上传后清洗文本”的工具，而是一条把各种数字材料转化为可用、可信、可追溯企业数字资产的生产线。核心目标有两个：
|
||
|
||
1. 任何进入生产问答、陪练、评分或评测的数据，都能证明来源、版本、适用范围、有效期、处理规则和批准责任人。
|
||
2. 人工只处理机器无法可靠决定的异常、冲突和高风险责任事项，并通过持续沉淀规则，让相同问题不再重复依赖人工。
|
||
|
||
总体采用五层架构：
|
||
|
||
1. **原始资产层**：不可变保存文件、图片、表格、录音、视频、对话和外部数据快照。
|
||
2. **规范化层**：版本化执行解析、OCR/ASR、编码修复、空白和版面噪声处理，不覆盖原件。
|
||
3. **结构化层**：拆解为制度条款、SOP 步骤、Q&A、案例、观点、术语、事实与证据等通用单元。
|
||
4. **治理审核层**：确定性规则、统计模型和 LLM 辅助检测后，自动放行低风险高置信数据、隔离硬风险、把灰区交给人工。
|
||
5. **发布消费层**：经批准的数据按用途进入生产知识、案例、陪练、考试或黄金评测集，并通过可撤回的索引投影供下游使用。
|
||
|
||
生产系统必须始终满足：
|
||
|
||
```text
|
||
未经批准的数据 != 生产知识
|
||
模型生成的数据 != 权威事实
|
||
用户交互记录 != 可自动回流的企业经验
|
||
解析成功 != 质量合格
|
||
有 embedding != 已批准发布
|
||
```
|
||
|
||
## 2. 目标、范围与非目标
|
||
|
||
### 2.1 目标
|
||
|
||
- 建立统一资产身份、不可变版本和全链路血缘。
|
||
- 让原始、候选、可信、合成、运行和评测数据明确分域。
|
||
- 用硬门禁、软规则和 reason code 取代单一 `is_clean` 或综合质量分。
|
||
- 建立自动检测、人工裁决、规则学习、影子验证、灰度执行和回滚闭环。
|
||
- 保证发布、撤回、过期和版本替代能同步影响全文检索、引用读取和向量索引。
|
||
- 让错误回答能够定位到具体 chunk、加工版本、原始文件和审核记录。
|
||
- 在不降低风险控制的前提下，持续提高自动处理率并降低人工审核量。
|
||
|
||
### 2.2 覆盖的数据来源
|
||
|
||
- 文件上传、批量导入、运维目录导入、API 导入和数据库同步。
|
||
- PDF、Word、Excel、PPT、文本、图片 OCR、录音 ASR 和视频关键帧/音轨。
|
||
- 企业制度、法规、SOP、专家经验、员工案例和业务术语。
|
||
- AI 生成的问题、答案、案例、评分、摘要和结构化草稿。
|
||
- 用户问答、陪练对话、评分结果、纠错反馈和成果投稿。
|
||
- 用于训练、验证、测试和回归评测的数据集。
|
||
|
||
### 2.3 非目标
|
||
|
||
- 不用一次性重写现有知识平台替代渐进治理。
|
||
- 不把所有历史数据一键判为可信，也不从旧片段反向伪造原始来源。
|
||
- 不让 LLM 成为唯一质量判断者、审核人或发布人。
|
||
- 不追求消灭所有人工；高风险责任确认、事实冲突和业务例外长期保留人工裁决。
|
||
- 不把提高召回率等同于提高答案可信度。HyDE、rerank 和 Prompt 优化只能在准入治理之后评估。
|
||
|
||
## 3. 不可妥协的设计原则
|
||
|
||
1. **原始不可变**：MinIO/OSS 原件、原始 hash 和采集上下文不可由清洗流程覆盖。
|
||
2. **加工即新版本**：重解析、重清洗、重切片和规则升级都产生新版本或新修订。
|
||
3. **默认不可信**：新上传、OCR/ASR、个人经验、AI 生成和运行交互默认不是生产知识。
|
||
4. **用途决定准入**：同一内容可能不适合权威知识，却可作为反例、陪练素材或仅供参考资料。
|
||
5. **硬风险不可被总分抵消**：敏感信息、跨租户、来源不明或提示词注入命中后，即使内容相关度很高也不能发布。
|
||
6. **LLM 只提供信号**：LLM 可提取、分类、提出纠错和冲突候选，无权批准、发布、撤回、删除或改变来源身份。
|
||
7. **人工决定可学习**：每次人工决定都必须形成结构化反馈，成为规则候选和黄金集样本。
|
||
8. **发布是显式动作**：只有授权人对确定内容 hash 做出批准后，系统才能建立生产数据集成员和索引投影。
|
||
9. **撤回先于异步删除**：先在 MySQL 事实源切断可见性，再通过 outbox 幂等删除向量。
|
||
10. **多租户失败关闭**：租户、知识空间、项目、岗位、区域或身份无法可靠确认时，拒绝猜测和跨域回退。
|
||
11. **可观测且可回滚**：规则、模型、索引 generation 和迁移批次均可对账、回退和追责。
|
||
12. **自动化以风险为约束**：减少人工不能通过放宽门禁实现，只能通过提高检测置信度、复用人工决策和缩小异常面实现。
|
||
|
||
## 4. 五层总体架构
|
||
|
||
```mermaid
|
||
flowchart TD
|
||
S["原始来源<br/>文件、图片、音视频、数据库、API、交互"] --> I["接入与固化<br/>身份、租户、来源、Hash、MinIO"]
|
||
I --> R["原始资产层<br/>RAW / 不可变原件"]
|
||
R --> P["规范化层<br/>解析、OCR/ASR、除噪、格式统一"]
|
||
P --> U["结构化层<br/>条款、步骤、Q&A、案例、观点、术语、证据"]
|
||
U --> G["治理审核层<br/>规则检测、质量评价、去重、隐私、冲突"]
|
||
G -->|"硬门禁"| Q["QUARANTINED<br/>隔离与修订"]
|
||
G -->|"灰区"| H["REVIEW_PENDING<br/>人工差异审核"]
|
||
G -->|"低风险高置信"| A["自动候选通过<br/>抽样复核"]
|
||
H --> A2["APPROVED<br/>人工责任确认"]
|
||
A --> A2
|
||
A2 --> D["用途路由<br/>knowledge/case/roleplay/assessment/eval"]
|
||
D --> O["发布消费层<br/>PUBLISHED + production membership"]
|
||
O --> X["全文检索 / Qdrant / RAG / 陪练 / 考试"]
|
||
X --> E["查询证据与用户反馈"]
|
||
E --> F["质量问题与人工裁决"]
|
||
F --> G
|
||
F --> L["规则演进<br/>影子运行、灰度、抽样、回滚"]
|
||
L --> G
|
||
O --> W["WITHDRAW / DEPRECATED"]
|
||
W --> Z["立即停止可见 + DELETE outbox"]
|
||
```
|
||
|
||
五层是职责分层，不要求五套完全独立的产品。现有架构应通过增量表、服务端门禁和发布投影逐步实现，避免大规模重写。
|
||
|
||
## 5. 数据域与资产身份
|
||
|
||
### 5.1 数据域
|
||
|
||
| 数据域 | 典型内容 | 默认信任 | 可否直接生产检索 | 主要去向 |
|
||
|---|---|---:|---:|---|
|
||
| `raw` | 上传原件、原始录音、视频、数据库快照 | 不可信 | 否 | 重处理与审计 |
|
||
| `candidate` | 解析、规范化、结构化后的候选版本 | 不可信 | 否 | 自动检测与审核 |
|
||
| `trusted_knowledge` | 已审批制度、法规、SOP、正式术语 | 受控可信 | 是 | 企业问答和学习 |
|
||
| `reviewed_cases` | 审核通过的正例、反例、场景案例 | 按用途可信 | 仅按用途 | 案例库与陪练 |
|
||
| `synthetic` | AI 生成问题、案例、答案、摘要、评分说明 | 不可信 | 默认否 | 草稿、测试、经审后专项使用 |
|
||
| `runtime_interactions` | 用户问题、模型回答、陪练对话、评分、反馈 | 不可信 | 否 | 运营分析与问题闭环 |
|
||
| `golden_eval` | 人工确认问题、标准答案、允许/禁止来源 | 高可信但只读 | 不参与回答 | 回归评测 |
|
||
|
||
数据域必须是服务端持久化属性，不能只靠文件夹名、前端标签或 Prompt 约定。`synthetic` 内容即使人工审核通过，也必须永久保留合成来源身份。
|
||
|
||
### 5.2 业务用途
|
||
|
||
| `usage_type` | 含义 | 关键准入要求 |
|
||
|---|---|---|
|
||
| `NORMATIVE_KNOWLEDGE` | 法规、制度、正式 SOP | 权威来源、版本、有效期、适用范围、责任人批准 |
|
||
| `POSITIVE_CASE` | 已验证的正面案例 | 场景、行动、依据、结果和专家评价完整 |
|
||
| `NEGATIVE_CASE` | 错误做法或失败案例 | 明确反例标签，禁止作为标准做法召回 |
|
||
| `ROLEPLAY_MATERIAL` | 陪练角色、对话和情境 | 去标识化、场景边界和训练目的明确 |
|
||
| `ASSESSMENT_ITEM` | 考题、标准答案、评分标准 | 来源依据、难度、适用岗位和人工签认 |
|
||
| `REFERENCE_ONLY` | 仅供辅助参考 | 不能包装成强制制度或标准答案 |
|
||
| `UNUSABLE` | 无法使用但需保留审计 | 不进入任何生产数据集 |
|
||
|
||
## 6. 生命周期状态机
|
||
|
||
```mermaid
|
||
stateDiagram-v2
|
||
[*] --> RAW
|
||
RAW --> PARSED
|
||
PARSED --> NORMALIZED
|
||
NORMALIZED --> CLASSIFIED
|
||
CLASSIFIED --> DEDUPLICATED
|
||
DEDUPLICATED --> PRIVACY_CHECKED
|
||
PRIVACY_CHECKED --> DOMAIN_VALIDATED
|
||
DOMAIN_VALIDATED --> QUALITY_EVALUATED
|
||
QUALITY_EVALUATED --> QUARANTINED: 硬门禁或来源不可用
|
||
QUALITY_EVALUATED --> REVIEW_PENDING: 软问题或需责任确认
|
||
QUARANTINED --> REVIEW_PENDING: 新版本修复并重新检测
|
||
REVIEW_PENDING --> APPROVED: 授权审核人批准
|
||
REVIEW_PENDING --> QUARANTINED: 拒绝或要求修订
|
||
APPROVED --> PUBLISHED: 创建生产投影和索引任务
|
||
PUBLISHED --> DEPRECATED: 撤回、过期或被替代
|
||
DEPRECATED --> REVIEW_PENDING: 以新版本重新进入流程
|
||
```
|
||
|
||
状态转换约束：
|
||
|
||
- 每个状态转换记录操作者、处理器版本、输入/输出 hash、时间和结果。
|
||
- `APPROVED` 绑定具体 `version_id + content_sha256`；内容变化后旧批准自动失效。
|
||
- `PUBLISHED` 不是“文件已解析”，而是已批准版本被显式路由到允许的数据集。
|
||
- `QUARANTINED` 不等于删除。隔离数据保留原件和证据，可修订后以新版本重跑。
|
||
- `DEPRECATED` 立即退出所有生产读取路径，但按保留策略保存审计链。
|
||
- 自动处理可以推进技术状态；高风险资产进入 `APPROVED` 必须有满足责任矩阵的人类决定。
|
||
|
||
## 7. 各层处理契约
|
||
|
||
### 7.1 第一层：原始资产保存
|
||
|
||
**输入**：浏览器上传、批量上传、运维导入、数据库/API 同步、录音、视频和用户提交。
|
||
|
||
**处理动作**：
|
||
|
||
- 在接入时确定 `tenant_id`、知识空间、来源类型、采集主体、时间和授权范围。
|
||
- 计算 SHA-256、探测 MIME/扩展名、记录大小，并把原件写入 MinIO/OSS。
|
||
- 生成稳定 `asset_id`，把上传任务、附件、OSS 对象和业务对象建立血缘。
|
||
- 精确重复可以复用只读 OSS 对象，但不能把两次业务接入合成同一个来源事件。
|
||
- 原件缺失、租户不明或来源无法验证时直接隔离。
|
||
|
||
**输出**：`RAW` 资产、原始对象引用、来源元数据和接入审计记录。
|
||
|
||
**不得执行**：覆盖同名文件、修改原始正文、直接切片入生产库、直接调用生产向量写入。
|
||
|
||
### 7.2 第二层：解析与规范化
|
||
|
||
规范化只处理确定性的技术噪声，不负责改写业务事实。
|
||
|
||
| 类型 | 解析 | 可自动规范化 | 必须保留的证据 |
|
||
|---|---|---|---|
|
||
| PDF | 文本层、页数、页码、图片/OCR | Unicode、换行、重复页眉页脚候选 | 页码、文本坐标、OCR 置信度、缺页判断 |
|
||
| Word/PPT | 标题、段落、表格、列表、备注 | 空白、控制字符、样式噪声 | 标题路径、页/段定位、表格结构 |
|
||
| Excel | sheet、表头、单元格、合并区 | 空行空列和类型标准化候选 | sheet/行列坐标、公式与显示值 |
|
||
| 图片 | OCR、版面区域、方向 | 旋转和确定性字符规范化 | 框坐标、置信度、原图引用 |
|
||
| 录音 | ASR、说话人分段、时间轴 | 标点和口头停顿候选 | 时间戳、声道/说话人、ASR 置信度 |
|
||
| 视频 | 音轨 ASR、关键帧、字幕、视觉结果 | 时间轴对齐 | 关键帧时间、字幕区间、视觉解析来源 |
|
||
| 文本/API | 编码、字段和 schema | NFKC、换行、控制字符、空白 | 原始 payload hash、接口版本 |
|
||
|
||
清洗结果生成新 `data_version`，至少记录：
|
||
|
||
- `parser_name/parser_version`
|
||
- `extractor_name/extractor_version`
|
||
- `cleaning_policy_version`
|
||
- `classification_policy_version`
|
||
- 页数、OCR/ASR 指标和结构画像
|
||
- 清洗前后 hash 及可查看的差异
|
||
|
||
以下行为只能生成候选，不得静默改写事实：OCR 错字纠正、表格语义重建、说话人归属、日期和金额纠正、行业黑话解释、缺失上下文补写。
|
||
|
||
#### 7.2.1 隐私脱敏派生层
|
||
|
||
解析正文和规范化正文继续作为不可变审计证据保存在受控数据版本中，不直接用于切片、语义分析、模型调用、发布或检索。系统使用版本化的确定性规则从规范化正文生成独立脱敏派生版本，并记录 `redacted_content`、`redacted_source_name`、派生内容 hash、`privacy_status`、`redaction_policy_version` 和分类计数；当前规则版本为 `privacy-redaction-v1`。
|
||
|
||
脱敏后必须再次扫描派生正文和全部派生 chunk：结果为 `CLEAN` 或 `REDACTED` 才能继续质量评估；仍命中敏感模式时标记为 `BLOCKED / PII_DETECTED` 并隔离。命中并已安全替换的类别记录 `PII_REDACTED` 软证据，不能用综合质量分覆盖残留 PII 硬门禁。审核界面默认只展示脱敏文件名、分类计数和脱敏正文预览；查看原件必须走单独鉴权、留痕的审计入口。
|
||
|
||
下游统一消费脱敏派生版本：结构化拆解和 chunk 从 `redacted_content` 生成，外部 embedding/LLM 只接收隐私状态为 `CLEAN/REDACTED` 的派生内容，生产引用标题优先使用 `redacted_source_name`。重复对象中遗留的摘要、标签和归类理由不能直接复用，必须经当前隐私规则重新脱敏；上传响应 snippet 也使用脱敏文件名。规则升级不覆盖旧派生版本，而是生成新版本、重新复扫、重新审核和重新发布。
|
||
|
||
### 7.3 第三层：结构化拆解
|
||
|
||
结构化目标不是强迫所有资料变成 Q&A，而是先保留文档结构，再映射为可复用业务单元。
|
||
|
||
统一信封建议：
|
||
|
||
```json
|
||
{
|
||
"unitId": "stable-id",
|
||
"assetId": 123,
|
||
"versionId": 2,
|
||
"tenantId": "000000",
|
||
"unitType": "SOP_STEP",
|
||
"title": "首次短信催费",
|
||
"content": "...",
|
||
"context": {
|
||
"scenario": "欠费首次提醒",
|
||
"role": ["生活顾问"],
|
||
"project": ["示例项目"],
|
||
"region": ["南京"]
|
||
},
|
||
"validity": {
|
||
"effectiveFrom": "2026-01-01",
|
||
"effectiveTo": null
|
||
},
|
||
"evidence": [
|
||
{"sourceLocator": {"page": 3, "paragraph": 7}}
|
||
],
|
||
"origin": "ENTERPRISE_SOURCE",
|
||
"synthetic": false
|
||
}
|
||
```
|
||
|
||
通用单元类型：
|
||
|
||
| 单元类型 | 关键字段 | 适用内容 |
|
||
|---|---|---|
|
||
| `POLICY_CLAUSE` | 条款号、义务/禁止、适用对象、有效期、上位依据 | 制度与法规 |
|
||
| `SOP_STEP` | 场景、前置条件、步骤号、动作、例外、完成标准 | 标准流程 |
|
||
| `QA_PAIR` | 问题、答案、依据、无答案条件 | 高频问答 |
|
||
| `CASE` | 背景、角色、诉求、行动、依据、结果、专家评价 | 正反案例 |
|
||
| `EXPERT_OPINION` | 观点、专家、适用条件、依据、冲突关系 | 经验和争议意见 |
|
||
| `GLOSSARY_TERM` | 术语、别名、定义、适用项目/岗位、版本 | 业务黑话 |
|
||
| `FACT_CLAIM` | 主体、谓词、对象、约束、证据位置 | 冲突和事实核验 |
|
||
| `ASSESSMENT_ITEM` | 题干、选项、标准答案、评分依据、难度 | 考试与评测 |
|
||
| `ROLEPLAY_SCENE` | 人设、背景、目标、红线、回合锚点 | 陪练素材 |
|
||
|
||
结构化后再进行语义切片：优先保持标题、段落、Q&A、SOP 步骤和表格行组完整；只有超长结构块才使用 overlap。不得把固定“500–800 字、重叠 100 字”当作所有文档的全局真理，参数应按文档类型在黄金集上标定。
|
||
|
||
### 7.4 第四层：治理与审核
|
||
|
||
治理阶段依次执行：
|
||
|
||
1. 技术完整性：空内容、解析失败、缺页、乱码、OCR/ASR 低置信度。
|
||
2. 结构质量：页眉页脚、水印、分页噪声、表格丢失、切片上下文断裂。
|
||
3. 来源与身份：来源、版本、租户、空间、项目、岗位和有效期。
|
||
4. 安全与隐私：PII、密钥、跨租户引用、提示词注入和外发边界。
|
||
5. 去重与版本：精确、近似和语义重复；制度替代和多版本冲突。
|
||
6. 领域与事实：领域相关性、上下文完整性、结论依据、标签和专家冲突。
|
||
7. 来源污染：未声明合成、运行数据回流、训练/评测泄漏。
|
||
8. 用途路由：确定是否可成为权威知识、案例、陪练、题目、评测或仅供参考。
|
||
|
||
每项问题单独生成 `quality_issue`，包含 reason code、严重级别、硬/软门禁、检测器和版本、证据位置、建议动作及处理状态。不得用一个总分掩盖具体风险。
|
||
|
||
### 7.5 第五层：发布与消费
|
||
|
||
发布前置条件：
|
||
|
||
- 当前版本已封存且内容 hash 未变化。
|
||
- 来源、版本、适用范围、有效期和数据用途完整。
|
||
- 无开放的硬门禁问题，所有软问题均被逐项接受、解决或判为误报。
|
||
- 语义重复/冲突分析已完成或明确不需要。
|
||
- 规范性知识的替代关系已经确认。
|
||
- 有符合责任矩阵的人工审核记录。
|
||
- 数据集路由和知识空间授权由服务端生成。
|
||
|
||
发布动作在同一事务中创建生产 fragment、`production` 数据集成员和 `UPSERT` outbox。向量索引只是 MySQL 事实源的可重建投影，不是独立事实源。
|
||
|
||
## 8. 数据模型
|
||
|
||
### 8.1 当前本地已具备的核心对象
|
||
|
||
| 对象 | 责任 |
|
||
|---|---|
|
||
| `aihr_data_asset` | 稳定资产身份、来源、租户、用途、信任、适用范围和生命周期 |
|
||
| `aihr_data_version` | 不可变解析/规范化版本、规则版本、结构画像和提取质量 |
|
||
| `aihr_chunk_revision` | 不可变候选切片、定位信息和发布 fragment 映射 |
|
||
| `aihr_quality_assessment` | 一次版本化、多维质量评估 |
|
||
| `aihr_quality_issue` | reason code、门禁、证据、检测器及解决状态 |
|
||
| `aihr_review_decision` | 只允许人工记录批准、拒绝、隔离、撤回和失效决定 |
|
||
| `aihr_dataset_membership` | 明确版本属于哪个数据集以及用途 |
|
||
| `aihr_lineage_edge` | 原件、版本、切片、发布片段之间的正反向血缘 |
|
||
| `aihr_index_outbox` | 向量 UPSERT/DELETE 的持久、幂等、可重试任务 |
|
||
| `aihr_query_evidence` | 每次检索的排名、通道、分数、使用情况和污染定位 |
|
||
| `aihr_duplicate_relation` | 精确、近似和语义重复候选关系 |
|
||
| `aihr_knowledge_claim` / `aihr_claim_conflict` | 事实/约束候选及人工冲突裁决 |
|
||
| `aihr_quality_alert` | 索引漂移、血缘缺口、开放问题和过期资产告警 |
|
||
| `aihr_knowledge_glossary_term` | 不可变术语修订、人工批准和适用范围 |
|
||
|
||
当前表结构是现有架构内的增量治理骨架。实际字段和迁移顺序以 `backend/script/sql/update/aihr_20260801...20260814` 及 [API_INTEGRATION.md](API_INTEGRATION.md) 为准。
|
||
|
||
### 8.2 建议补充的规则演进对象
|
||
|
||
现有表已保存 policy/detector version，但要系统性降低人工量，还应补充两类显式对象：
|
||
|
||
| 建议对象 | 关键字段 | 用途 |
|
||
|---|---|---|
|
||
| `aihr_processing_rule` | `rule_code, version, stage, scope_json, risk_class, action, implementation_type, config_json, status, owner, effective_at, rollback_version` | 管理规则草稿、影子、灰度、启用、停用和回滚 |
|
||
| `aihr_rule_evaluation` | `rule_version, sample_id, expected_decision, actual_decision, confidence, matched_reason_codes, false_allow, false_block, run_id, evaluated_at` | 对比人工/黄金集结论，证明规则可否自动执行 |
|
||
| `aihr_pipeline_run` | `run_id, asset_id, input_version, output_version, stage, processor_version, status, metrics_json, started_at, ended_at` | 记录重处理批次、耗时、错误和可重放性 |
|
||
| `aihr_review_sample` | `rule_version, asset_id, sampling_strategy, sampled_at, review_result` | 对已自动通过/隔离结果持续抽样复核 |
|
||
|
||
上述四类对象已在本地增量落地；它们当前只支撑影子评估、批次追溯和人工复核，不代表规则已经获得自动执法权限。
|
||
|
||
## 9. 自动化分流模型
|
||
|
||
### 9.1 三路分流
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
C["候选版本"] --> D["规则与模型检测"]
|
||
D --> B["BLOCK<br/>硬门禁自动隔离"]
|
||
D --> R["REVIEW<br/>灰区人工审核"]
|
||
D --> P["PASS<br/>低风险高置信候选"]
|
||
P --> S["按风险抽样复核"]
|
||
S -->|"发现误放行"| K["撤回 + 规则降级 + 回归"]
|
||
S -->|"稳定"| T["扩大自动化覆盖"]
|
||
```
|
||
|
||
- **自动隔离**：命中确定性硬风险，系统可阻止发布，但不得物理删除原件。
|
||
- **人工审核**：规则置信度不足、存在冲突、业务适用范围不明或需要责任确认。
|
||
- **自动候选通过**：只适用于低风险、确定性且已在黄金集/影子流量中证明可靠的规则；仍须满足抽样和可撤回要求。
|
||
|
||
### 9.2 风险与置信度矩阵
|
||
|
||
| 业务风险 | 高置信安全 | 中等/冲突置信 | 高置信风险 |
|
||
|---|---|---|---|
|
||
| 低风险参考资料 | 自动进入待发布队列，按比例抽样 | 人工差异审核 | 自动隔离/修订 |
|
||
| 中风险案例/SOP | 规则通过后仍需用途责任确认，可批量审核 | 人工审核 | 自动隔离 |
|
||
| 高风险制度/法规/标准答案 | 不自动最终批准，减少到差异审核 | 双人或指定责任人审核 | 自动隔离并告警 |
|
||
| PII/密钥/跨租户/注入 | 不存在自动放行通道 | 隔离并人工安全复核 | 自动隔离并告警 |
|
||
|
||
“高置信”必须来自版本化规则在代表性标注集上的数据，而不是 LLM 自报置信度。
|
||
|
||
## 10. Reason code 与门禁策略
|
||
|
||
### 10.1 当前核心 reason code
|
||
|
||
| 类别 | reason code | 默认动作 |
|
||
|---|---|---|
|
||
| 解析 | `PARSE_EMPTY`, `PARSE_FAILED`, `PAGE_COUNT_MISMATCH`, `SOURCE_UNAVAILABLE` | 硬隔离，修复来源后新版本重跑 |
|
||
| 来源 | `SOURCE_UNKNOWN`, `SOURCE_EVIDENCE_INSUFFICIENT`, `SOURCE_VERSION_MISSING` | 硬隔离或补齐来源与事实依据责任确认 |
|
||
| 隐私安全 | `PII_DETECTED`, `SECRET_DETECTED`, `CROSS_TENANT_REFERENCE`, `PROMPT_INJECTION_SUSPECTED` | 硬隔离，不外发语义分析 |
|
||
| 时效 | `POLICY_EXPIRED`, `VERSION_CONFLICT` | 停止发布，确认有效版本和替代关系 |
|
||
| 合成数据 | `SYNTHETIC_UNDECLARED`, `SYNTHETIC_UNVERIFIED` | 强制合成身份，未经人工不得生产使用 |
|
||
| 提取质量 | `OCR_LOW_CONFIDENCE`, `ASR_LOW_CONFIDENCE` | 隔离或差异复核 |
|
||
| 版面/结构 | `HEADER_FOOTER_NOISE`, `PAGINATION_NOISE`, `CHUNK_CONTEXT_BROKEN` | 软门禁，修订或逐项接受 |
|
||
| 业务质量 | `DOMAIN_IRRELEVANT`, `CONTEXT_INCOMPLETE` | 软/硬动作取决于用途 |
|
||
| 重复 | `EXACT_DUPLICATE`, `NEAR_DUPLICATE`, `SEMANTIC_DUPLICATE` | 建立候选关系，不自动删除或合并 |
|
||
| 语义分析 | `SEMANTIC_ANALYSIS_DEGRADED`, `SEMANTIC_ANALYSIS_FAILED` | 标明降级，未完成时拒绝发布 |
|
||
| 冲突 | `EXPERT_CONFLICT` | 人工确认、误报或解决 |
|
||
| 下游反馈 | `DOWNSTREAM_ANSWER_DISPUTED` | 创建复核任务，不自动撤回 |
|
||
| 责任门禁 | `HUMAN_REVIEW_REQUIRED` | 等待符合权限的人工决定 |
|
||
|
||
### 10.2 建议扩充的 reason code
|
||
|
||
- 解析：`PARSE_TRUNCATED`, `EMBEDDED_CONTENT_SKIPPED`, `TABLE_STRUCTURE_LOST`。
|
||
- 编码：`ENCODING_REPLACEMENT_CHAR`, `UNICODE_CONTROL_CHAR`, `OCR_PARTIAL`, `ASR_SPEAKER_UNCERTAIN`。
|
||
- 清洗：`TOC_NOISE`, `WATERMARK_NOISE`, `CHUNK_TOO_SHORT`。
|
||
- 业务：`UNSUPPORTED_CLAIM`, `LABEL_CONFLICT`, `APPLICABILITY_MISSING`。
|
||
- 污染：`RUNTIME_DATA_CONTAMINATION`, `TRAIN_EVAL_LEAKAGE`。
|
||
- 索引：`INDEX_UPSERT_FAILED`, `INDEX_DELETE_FAILED`, `INDEX_DRIFT`, `INDEX_PAYLOAD_INVALID`。
|
||
|
||
扩充 reason code 时必须同时定义检测器、证据结构、严重级别、门禁类型、推荐动作、可否接受、测试夹具和负责团队，禁止只增加枚举名称。
|
||
|
||
## 11. 如何持续减少人工工作
|
||
|
||
人工不是永久流水线，而是规则的教师、例外处理者和责任承担者。减少人工的正确路径如下：
|
||
|
||
### 11.1 优先减少审核操作，而不是减少控制
|
||
|
||
- **差异审核**：只展示原文与候选修订的变化、命中问题和影响范围，不要求审核人通读整份文档。
|
||
- **聚类审核**：精确重复自动归组；近重复和同模板资料批量展示共同问题，一次决定可形成受控批处理建议。
|
||
- **建议决策**：系统预填用途、适用范围、reason code 处理建议和相似历史决定，人工确认或修改。
|
||
- **异常审核**：稳定规则覆盖的数据不进入逐份队列，只对例外、冲突、低置信和高风险项审核。
|
||
- **抽样复核**：对自动通过按风险分层抽样；样本失败立即降低规则自动化级别。
|
||
- **增量审核**：新版本只审与已批准版本的差异、规则变化和影响的结构单元。
|
||
- **批量适用范围**：同来源、同项目、同版本批次可复用已确认元数据，但每个资产仍保留独立血缘和 hash。
|
||
|
||
### 11.2 人工决定必须结构化
|
||
|
||
每次审核至少记录：
|
||
|
||
- 决定：批准、拒绝、隔离、撤回、失效、误报或接受软问题。
|
||
- 对象：具体 `asset/version/chunk` 与内容 hash。
|
||
- 原因：reason code 及自由说明。
|
||
- 修改：人工改了哪些字段或正文差异。
|
||
- 依据：原文件位置、制度、业务责任人或适用条件。
|
||
- 复用条件：这个判断在什么来源、文档类型、项目、岗位或阈值下可以规则化。
|
||
- 风险等级和是否允许作为自动化训练/评测样本。
|
||
|
||
只保存“通过/不通过”的审核记录无法形成有效自动化。
|
||
|
||
### 11.3 规则演进闭环
|
||
|
||
```mermaid
|
||
flowchart LR
|
||
H["人工决定"] --> C["聚合高频原因与修订模式"]
|
||
C --> R["规则候选 + 版本 + 适用范围"]
|
||
R --> S["影子运行<br/>不改变生产决定"]
|
||
S --> M["与人工/黄金集比较指标"]
|
||
M -->|"不达标"| C
|
||
M -->|"达标"| G["小租户/小来源灰度"]
|
||
G --> A["自动执行 + 风险抽样"]
|
||
A --> O["监控误放行、误隔离与漂移"]
|
||
O -->|"稳定"| E["扩大覆盖"]
|
||
O -->|"异常"| B["一键回退旧规则并重审受影响版本"]
|
||
B --> C
|
||
```
|
||
|
||
规则晋级条件必须按风险等级设定：
|
||
|
||
- 安全硬门禁可自动隔离，但误伤率需受控且允许修订重跑。
|
||
- 低风险技术清洗可在 diff 可见、原文保留和指标达标后自动应用。
|
||
- 权威制度、标准答案、跨租户和敏感数据不能因规则表现良好而取消最终责任确认。
|
||
- LLM 分类器升级必须视为新 detector version，重新跑影子集，不得静默替换。
|
||
|
||
### 11.4 人工角色的最终形态
|
||
|
||
随着规则成熟，人工工作应从“逐份清洗和逐条检查”转为：
|
||
|
||
- 处理系统无法决定的少数异常和冲突。
|
||
- 确认制度权威性、适用范围、有效期和替代关系。
|
||
- 维护术语、黄金集、规则阈值和误报样本。
|
||
- 对高风险发布、撤回和安全例外承担责任。
|
||
- 定期评估规则漂移，而不是持续做重复机械操作。
|
||
|
||
## 12. LLM 的允许与禁止边界
|
||
|
||
### 12.1 可以做
|
||
|
||
- OCR/ASR 错字、断句和结构恢复建议。
|
||
- 候选 Q&A、SOP、案例、术语和 claim 提取。
|
||
- 领域相关性、上下文缺失和冲突候选提示。
|
||
- 对人工修改生成规则候选说明。
|
||
- 为审核人生成差异摘要，但必须链接原始证据。
|
||
- 在黄金集上参与分类器评测和影子运行。
|
||
|
||
### 12.2 不可以做
|
||
|
||
- 覆盖原始文件或把推断写成原始事实。
|
||
- 自己决定来源权威性、制度有效期、跨项目适用范围或专家冲突结论。
|
||
- 自行批准、发布、撤回、物理删除数据或修改审核记录。
|
||
- 把生成的案例、答案、评分或总结无标记地写回可信知识区。
|
||
- 将用户回答、运行日志或历史模型回答自动转为标准答案。
|
||
- 在 PII、密钥、提示词注入或隔离内容上调用未经批准的外部模型。
|
||
|
||
LLM 输出统一标记 `synthetic=true` 或 detector signal；人工审核不能消除其合成身份，只能批准其在特定用途下使用。
|
||
|
||
## 13. 发布、检索、撤回与追溯
|
||
|
||
### 13.1 生产检索条件
|
||
|
||
所有全文、关键词、向量、引用水合、相邻片段和原件下载路径都必须独立复核以下交集：
|
||
|
||
```text
|
||
当前认证租户
|
||
AND 调用应用绑定的知识空间
|
||
AND 主体授权的知识空间
|
||
AND 当前版本
|
||
AND lifecycle_status = PUBLISHED
|
||
AND trust_level = HUMAN_VERIFIED
|
||
AND dataset_code = production
|
||
AND membership_status = ACTIVE
|
||
AND 未过期
|
||
AND 项目/岗位/区域适用
|
||
```
|
||
|
||
客户端提交的租户、角色、项目、标签或 `toolCode` 不能作为可信过滤条件。Qdrant payload filter 是第一层过滤，MySQL hydrate 是最终事实复核。
|
||
|
||
### 13.2 向量索引
|
||
|
||
- 生产 Qdrant point 使用确定性 ID 和 generation，payload 带租户、asset、version、chunk revision、生命周期、数据集、有效期和 embedding 模型。
|
||
- 所有写入/删除先在数据库事务内写 `aihr_index_outbox`，worker 幂等执行并重试。
|
||
- 超过重试阈值进入 `DEAD_LETTER` 并告警，不能通过改回业务状态掩盖索引漂移。
|
||
- 定时 reconciler 对比 MySQL 的已发布集合与 Qdrant 点，缺失发 UPSERT，多余发 DELETE，hash 不一致重建并留痕。
|
||
- 候选、隔离、合成和运行数据原则上不进生产 collection。即使未来需要语义分析，也使用隔离索引或临时分析向量。
|
||
|
||
### 13.3 撤回与替代
|
||
|
||
1. 授权人提交撤回/失效决定和原因。
|
||
2. 同一事务把版本改为 `DEPRECATED`、停用数据集成员、移除生产 fragment、写 DELETE outbox。
|
||
3. 所有 MySQL 读取立即不可见，不等待 Qdrant 删除完成。
|
||
4. outbox 删除失败重试并告警；索引对账确认点为零。
|
||
5. 原件、版本、问题、审核和查询证据继续保留。
|
||
6. 新制度通过 `supersedes_asset_id` 显式替代旧制度，不使用同名覆盖。
|
||
|
||
### 13.4 错误回答追溯
|
||
|
||
```text
|
||
用户反馈 / requestId
|
||
→ aihr_query_evidence
|
||
→ published fragment
|
||
→ chunk revision
|
||
→ data version
|
||
→ data asset
|
||
→ attachment / MinIO 原件
|
||
→ parser、cleaner、chunker、detector 版本
|
||
→ quality issues 与 review decisions
|
||
```
|
||
|
||
用户“没解决”只创建 `DOWNSTREAM_ANSWER_DISPUTED`。人工确认 `KEEP` 或 `WITHDRAW`；模型和用户反馈都不能自动撤回可信资产。
|
||
|
||
## 14. 多租户、权限与安全隔离
|
||
|
||
- 所有治理主键关联和查询同时携带并校验 `tenant_id`，不接受只凭全局 ID 查询。
|
||
- 知识空间授权取“租户 + 调用应用绑定 + 当前主体授权”的交集。
|
||
- 项目、岗位、区域和有效期由已审核服务端 metadata 生成，不信任客户端标签。
|
||
- 跨租户重复分析默认只比较 hash，不暴露正文、文件名或来源；发现相同内容也不能自动共享授权。
|
||
- 生产 collection 至少按可信与非可信隔离；高合规租户可进一步使用独立 collection 或实例。
|
||
- PII、密钥、提示词注入和隔离内容先在本地确定性扫描，未通过前不得发送外部 embedding/LLM。
|
||
- 审核、发布、撤回、规则变更和数据集导出必须记录操作者、租户、对象 hash 和审计时间。
|
||
- 评测集与训练候选按内容 hash 防泄漏；同源近重复内容不能跨 train/test split。
|
||
|
||
## 15. 历史 1,046 份附件纳管方案
|
||
|
||
当前本地基线为：
|
||
|
||
- `aihr_data_asset = 0`
|
||
- 历史附件 `1,046`
|
||
- 历史片段 `8,607`
|
||
- 业务术语总数/活动术语 `0`
|
||
|
||
这表示治理骨架已存在，但历史资料尚未进入该生命周期。不能把现有片段或 embedding 视为已审核数字资产。
|
||
|
||
### 15.1 前置条件
|
||
|
||
1. 先部署并验证新数据 fail-closed，阻止继续产生 `RAW -> INDEXED`。
|
||
2. 在生产结构副本按顺序验证 `aihr_20260801` 至 `aihr_20260814` 迁移幂等性。
|
||
3. 备份数据库，导出仅含 ID/hash/状态的附件、OSS、片段和 Qdrant manifest。
|
||
4. 准备高频业务黄金问题和来源清单，不以当前答案作为标准答案。
|
||
5. 明确每个知识空间的业务责任人、审核人和允许用途。
|
||
|
||
### 15.2 批次策略
|
||
|
||
每批 20–50 份，按以下顺序处理：
|
||
|
||
1. 现行法规、公司制度、安全、消防、财务和人事资料。
|
||
2. 高频使用的正式 SOP 和标准话术。
|
||
3. 专家访谈、员工经验和正反案例。
|
||
4. OCR 噪声较大的扫描件、录音和视频。
|
||
5. 低频参考材料和来源不足材料。
|
||
|
||
每批执行：
|
||
|
||
```text
|
||
legacy preview（只读盘点）
|
||
→ 从当前租户 MinIO 原件重新解析
|
||
→ 自动检测和结构化
|
||
→ 人工差异审核
|
||
→ 小范围批准发布
|
||
→ 标准题回归与跨租户负例
|
||
→ 索引对账
|
||
→ 批次签认
|
||
```
|
||
|
||
- 原件存在：以 MinIO 原件为唯一重解析依据，建立新 asset/version/chunk revision。
|
||
- 原件缺失或不可读：创建 `QUARANTINED / SOURCE_UNAVAILABLE`，不得用旧 fragment 伪造来源。
|
||
- 旧 fragment 和旧向量在迁移完成前只作为未治理遗留数据统计，不参与新生产集合计数。
|
||
- 每批 manifest 记录游标、输入/输出 hash、成功/失败 ID、规则版本、审核人和索引 generation，不保存正文或 token。
|
||
- 任一失败 ID 不推进恢复游标；禁止全量自动批准。
|
||
|
||
### 15.3 批次验收与回滚
|
||
|
||
- 该批生产血缘完整率 100%。
|
||
- 未批准版本生产可检索数量为 0。
|
||
- 跨租户禁止片段泄漏数量为 0。
|
||
- 撤回后 MySQL 立即不可见，Qdrant 删除最终一致率 100%。
|
||
- 黄金问题达到该批预设 Recall/MRR/nDCG 和无答案阈值。
|
||
- 回滚只切换生产可见性/索引 generation，不删除原件、版本和审核证据。
|
||
|
||
## 16. 黄金集、测试与标定
|
||
|
||
### 16.1 黄金集设计
|
||
|
||
首批由业务专家标注 100–300 条，覆盖：
|
||
|
||
- 有唯一答案、多来源答案和明确无答案问题。
|
||
- 现行/过期/冲突制度。
|
||
- 不同租户、项目、岗位和区域的同名问题。
|
||
- OCR 乱码、缺页、表格、上下文断裂和业务黑话。
|
||
- 正面案例、反面案例、个人经验和 AI 合成内容。
|
||
- PII、密钥、提示词注入和跨租户数据。
|
||
- 精确、近似、语义重复及 train/eval 泄漏。
|
||
|
||
每条样本至少标注：
|
||
|
||
```json
|
||
{
|
||
"expectedStatus": "QUARANTINED",
|
||
"expectedReasonCodes": ["PII_DETECTED", "SOURCE_UNKNOWN"],
|
||
"allowedDatasets": [],
|
||
"allowedSourceIds": [],
|
||
"forbiddenSourceIds": [9981],
|
||
"answerable": false,
|
||
"reviewer": "business-owner",
|
||
"labelVersion": "golden-v1"
|
||
}
|
||
```
|
||
|
||
仓库中的示例 fixture 只验证代码契约，不等于真实业务黄金集，也不能据此宣称业务准确率达标。
|
||
|
||
### 16.2 测试分层
|
||
|
||
| 层级 | 重点 |
|
||
|---|---|
|
||
| 单元测试 | parser、normalizer、reason code、状态转换、hash、locator、租户 filter、outbox 幂等 |
|
||
| 组件测试 | 不同文件解析、OCR/ASR 证据、结构切片、重复关系、claim 冲突、规则版本 |
|
||
| 集成测试 | 上传到待审、批准发布、撤回删除、索引死信、反馈追溯、历史 stage 游标 |
|
||
| 安全测试 | 跨租户、越权审核、客户端 metadata 伪造、Prompt 注入、PII 外发阻断 |
|
||
| E2E | 管理端差异审核、批量决定、发布、检索引用、原文定位、撤回后不可见 |
|
||
| 离线评测 | Recall@K、MRR、nDCG、错误来源率、无答案误召回、跨租户泄漏 |
|
||
| 生产 canary | 合成禁止片段、已撤回片段和跨租户片段永不被召回 |
|
||
|
||
### 16.3 规则标定流程
|
||
|
||
1. 冻结黄金集版本，确保样本来源和标注责任人可追溯。
|
||
2. 现有规则跑基线，输出每个 reason code 的 precision/recall 和混淆矩阵。
|
||
3. 新规则只影子运行，不影响生产决定。
|
||
4. 按风险分别设阈值，不使用统一 `0.8`。
|
||
5. 达标后在小范围来源或租户灰度，自动结果持续抽样复核。
|
||
6. 监控分布漂移；parser、模型、Prompt 或规则升级均重跑基线。
|
||
|
||
## 17. 质量与自动化指标
|
||
|
||
| 指标 | 定义 | 初期验收目标 |
|
||
|---|---|---:|
|
||
| 生产来源可追溯率 | 可反查原件、版本、规则和审核的生产 chunk / 全部生产 chunk | 100% |
|
||
| 未审批入生产数 | 无有效人工批准却可检索的版本数 | 0 |
|
||
| 跨租户泄漏数 | 任一查询召回越权 tenant/space/project 的片段数 | 0 |
|
||
| 索引一致率 | MySQL 应有生产点与 Qdrant 实际点一致比例 | 100%，允许短暂 outbox 延迟 |
|
||
| 撤回同步成功率 | 撤回后最终完成向量删除的比例 | 100% |
|
||
| 自动处理率 | 无逐份人工操作完成技术处理和分流的资产数 / 总资产数 | 分类型逐月提升 |
|
||
| 人工审核率 | 进入人工队列的资产数 / 总候选资产数 | 逐月下降，不以放宽门禁换取 |
|
||
| 单份审核耗时 | 审核总时长 / 审核资产数 | 按文档类型持续下降 |
|
||
| 规则覆盖率 | 被已验证规则明确处理的问题数 / 全部质量问题数 | 按 reason code 统计 |
|
||
| 自动放行误判率 | 抽样中不应放行却自动放行的比例 | 高风险为 0；低风险按批准阈值 |
|
||
| 自动隔离误伤率 | 抽样中应通过却被自动隔离的比例 | 按风险和规则分别设阈值 |
|
||
| 规则转化率 | 高频人工模式转化为已上线规则的比例 | 每月跟踪 |
|
||
| 无答案误召回率 | 黄金集中无答案问题却返回事实性来源的比例 | 按业务门槛设定并持续降低 |
|
||
| 错误定位成功率 | 错误回答能定位具体 chunk 和原件的比例 | 100% |
|
||
|
||
自动化指标必须与风险指标并列展示。只报“自动处理率提高”而不报误放行和误隔离，是无效甚至危险的优化。
|
||
|
||
## 18. 实施路线
|
||
|
||
### 18.1 P0：阻止新增污染并形成可撤回主链
|
||
|
||
**目标**：任何新数据未经明确批准不得进入生产检索。
|
||
|
||
当前本地已实现：不可变 asset/version/chunk、质量门禁、人工发布、生产标签、查询证据、撤回 DELETE outbox、历史 stage、监控骨架和首批测试。该结论仅代表本地代码，不代表生产发布或历史完成治理。
|
||
|
||
剩余动作：
|
||
|
||
1. 在生产结构副本验证 `aihr_20260801` 至 `aihr_20260812` 迁移、回滚和幂等。
|
||
2. 完成生产部署前预检和空候选、批准、撤回、跨租户负例验证。
|
||
3. 接通 `DEAD_LETTER`、索引漂移、血缘缺口和过期资产外部告警。
|
||
4. 明确知识空间责任人和人工审核权限。
|
||
5. 开始按 20–50 份执行历史高风险资料纳管，禁止自动批准。
|
||
|
||
**P0 验收**：`RAW -> INDEXED = 0`、`MODEL_OUTPUT -> TRUSTED = 0`、跨租户泄漏为 0、生产血缘完整率 100%、撤回最终索引清除率 100%。
|
||
|
||
### 18.2 P1：结构质量、业务质量和人工减负
|
||
|
||
1. 建立正式术语表并由项目/岗位责任人审核。
|
||
2. 按制度、SOP、案例、访谈和多媒体分别标定切片与噪声规则。
|
||
3. 建设 100–300 条真实业务黄金集，标定 OCR、近重复、语义重复和领域阈值。
|
||
4. 扩充 claim、制度替代、多专家意见和场景完整性模型。
|
||
5. 实现差异审核、聚类审核、增量审核、批量 metadata 和风险抽样。
|
||
6. 落地 `processing_rule/rule_evaluation/pipeline_run/review_sample` 或等价对象。当前本地已完成规则版本、状态审计、只观察的影子评估、处理批次台账、风险自动抽样与管理端观察工作台；自动抽样只生成待人工复核任务，不改变资产。
|
||
7. 新规则经过影子运行和灰度后，逐类提高自动处理覆盖。
|
||
|
||
**P1 验收**：人工审核率和单份耗时连续下降，同时误放行不超过分级门槛；所有自动决定可解释、可抽样、可撤回。
|
||
|
||
### 18.3 P2：下游反馈和质量运营闭环
|
||
|
||
1. 将错误回答、引用、投诉和纠错统一关联到查询 evidence。
|
||
2. 形成“定位污染源 -> 撤回/修订 -> 重建索引 -> 回归评测”的标准工单。
|
||
3. 建立质量仪表板：生命周期、问题分布、审核积压、规则覆盖、索引一致和错误来源。
|
||
4. 对 parser、规则、模型和业务数据分布做漂移监控。
|
||
5. 在黄金集证明收益后再 A/B 混合召回、rerank、查询扩展和 HyDE。
|
||
6. 建立训练/验证/测试 snapshot、hash 去重和时间切分，防止评测泄漏。
|
||
|
||
**P2 验收**：所有错误答案可定位；高风险告警可送达、处置和关闭；规则退化能自动降级并触发受影响资产重审。
|
||
|
||
## 19. 职责分工
|
||
|
||
| 角色 | 主要责任 | 不应承担 |
|
||
|---|---|---|
|
||
| 数据资产负责人 | 数据域、准入标准、指标和跨团队裁决 | 逐份做机械清洗 |
|
||
| 业务责任人 | 来源权威、适用范围、有效期、制度替代 | 判断系统安全实现 |
|
||
| 业务审核人 | 处理灰区、冲突、案例用途和标准答案 | 修改原始证据 |
|
||
| 数据工程 | 解析、版本、血缘、规则执行、迁移和对账 | 代替业务批准事实 |
|
||
| AI/RAG 工程 | 结构提取、检索、评测、模型版本和降级 | 让 LLM 自行发布 |
|
||
| 安全/隐私 | PII、秘密、外发、跨租户和保留策略 | 用业务总分覆盖硬风险 |
|
||
| 运维 | MinIO、MySQL、Qdrant、outbox、告警和恢复 | 手工改状态掩盖漂移 |
|
||
| 产品/运营 | 审核体验、积压、效率和规则候选管理 | 将用户反馈直接回流为知识 |
|
||
|
||
高风险制度和标准答案至少需要明确的业务责任人。是否采用双人审核应按法规、安全、财务、人事等风险分类配置，而非一刀切要求所有资料双审。
|
||
|
||
## 20. 管理端最小工作台
|
||
|
||
为了真正降低人工成本，审核界面至少提供：
|
||
|
||
- 队列筛选：租户、知识空间、来源、类型、风险、reason code、批次和处理时长。
|
||
- 原文证据：受控预览、页码/时间轴/单元格定位，不暴露原始 OSS URL。
|
||
- 差异视图：解析文本、规范化文本、结构化单元和前一批准版本之间的差异。
|
||
- 问题面板：硬/软门禁、证据位置、检测器版本和建议动作。
|
||
- 相似组：精确/近似/语义重复及版本冲突并排对比。
|
||
- 适用范围：项目名称、岗位、区域、有效期和来源版本，内部编码由服务端复核。
|
||
- 决策动作：批准、拒绝、隔离、修订、误报、接受软问题、撤回和替代。
|
||
- 批量动作：只对同规则、同风险、同来源范围的低风险项开放，并显示预计影响。
|
||
- 审核抽样：自动通过/隔离结果的风险分层样本。
|
||
- 规则候选：按高频人工修改和 reason code 聚合，提交影子规则而非直接启用。
|
||
|
||
任何批量批准都必须在服务端逐个复核版本 hash、租户、开放问题和权限，不能只由前端勾选完成。
|
||
|
||
## 21. 运行节奏
|
||
|
||
### 每日
|
||
|
||
- 查看审核积压、硬门禁、outbox 重试/死信和索引漂移。
|
||
- 处理高风险新资产和已发布资产争议。
|
||
- 对自动处理结果按风险抽样。
|
||
|
||
### 每周
|
||
|
||
- 统计人工审核原因 Top N、重复修改模式和平均处理时长。
|
||
- 选取可规则化模式，建立规则候选和回归样本。
|
||
- 复核误放行、误隔离、无答案误召回和跨租户 canary。
|
||
- 对历史资料完成一个或多个小批次纳管和签认。
|
||
|
||
### 每月
|
||
|
||
- 审查规则覆盖、自动处理率、人工审核率和风险指标是否同时改善。
|
||
- 复核即将过期制度、来源责任人变更和项目/岗位适用范围。
|
||
- 重跑完整黄金集，评估 parser、模型、embedding、rerank 和规则漂移。
|
||
- 决定规则晋级、降级、停用和历史版本重处理范围。
|
||
|
||
## 22. 失败处理与回滚
|
||
|
||
| 故障 | 系统行为 | 回滚/恢复 |
|
||
|---|---|---|
|
||
| 解析器升级质量下降 | 新版本隔离，旧批准版本继续服务 | 回退 parser version，重跑受影响资产 |
|
||
| 规则误隔离 | 不影响原件，停止新规则自动执行 | 回退规则版本，批量重评但不自动发布 |
|
||
| 规则误放行 | 立即切断受影响版本可见性 | 撤回、DELETE outbox、回归和扩大抽检 |
|
||
| Qdrant UPSERT 失败 | MySQL 不把向量成功当发布前提的替代；记录失败 | outbox 重试，死信告警和重建 |
|
||
| Qdrant DELETE 失败 | MySQL 已不可检索 | 持续重试和 reconciler 清理 |
|
||
| MinIO 原件缺失 | 创建 `SOURCE_UNAVAILABLE` 隔离版本 | 从合规备份恢复；不能用旧片段伪造 |
|
||
| 模型/embedding 不可用 | 标记降级或失败，不静默换成等价质量 | 恢复后按 detector version 重跑 |
|
||
| 跨租户校验异常 | 失败关闭 | 修复身份/授权后重试，不做模糊回退 |
|
||
| 迁移批次失败 | 停止游标推进，旧 generation 不切换 | 按 manifest 重试，切回旧可见 generation |
|
||
|
||
原件和审计链不作为普通回滚对象物理删除。回滚主要切换可见性、规则版本和索引 generation。
|
||
|
||
## 23. 当前项目落地映射
|
||
|
||
截至 2026-08-02，本地代码已具备：
|
||
|
||
- 新上传和 AI 整理先进入不可变候选生命周期，生命周期服务不可用时 fail-closed。
|
||
- NFKC、控制字符、换行和空白规范化生成新版本，不覆盖原件。
|
||
- `privacy-redaction-v1` 从规范化正文生成独立的脱敏正文和脱敏文件名；解析正文与规范化正文继续作为受控审计证据保留。结构化切片、语义分析、模型调用和发布只消费 `CLEAN/REDACTED` 派生版本，脱敏后复扫仍命中敏感模式时以 `PII_DETECTED` 阻断发布。
|
||
- 标题、段落、Q&A 和 SOP 步骤结构切片，保存定位、结构画像和规则版本。
|
||
- 精确、近似、语义重复候选；制度版本冲突和基础 claim 冲突检测。
|
||
- PII、秘密、跨租户、提示词注入、合成身份和人工审核门禁。
|
||
- 人工发布后才建立生产 fragment、数据集成员和向量 outbox。
|
||
- 查询证据、差评复核、统一撤回和向量删除闭环。
|
||
- 历史 preview/stage、质量指标、告警表、Actuator 健康和评测脚本骨架。
|
||
- 不可变术语修订与 AI 案例 provenance。
|
||
- 规则版本、状态转换、人工/黄金标签影子评估、误放行/误隔离指标和风险抽样证据；当前只允许 `DRAFT/SHADOW/PAUSED/RETIRED`，不执行自动门禁。
|
||
- `pipeline_run` 记录处理阶段、处理器版本、输入输出版本、指标和错误；影子评估按风险自动生成待人工复核样本，管理端可查看规则指标、批次并提交人工抽样结论。调度前先筛选可抽样候选，没有命中风险桶的候选时返回空结果且不创建空处理批次。
|
||
- 黄金集和门槛基础设施已在本地落地：黄金集按编码和版本维护，人工样本携带风险、期望决定、reason code 与证据，冻结后生成内容哈希且不可修改；`GOLDEN` 影子评估必须引用冻结样本。规则门槛同样先草稿、后人工冻结，`readiness` 输出分项指标和未达标原因，但 `enforcementEnabled` 固定为 `false`，不开放 `CANARY/ACTIVE`。
|
||
|
||
仍未完成或不得宣称完成：
|
||
|
||
- 1,046 份历史附件和 8,607 个旧片段尚未逐份纳管、审核和发布。
|
||
- 2026-08-01 最后一次本地隐私链路验证后，治理表保留 2 个待审测试资产，生产 fragment、生产数据集成员、索引 outbox 和 Qdrant 生产点均为 0；这 2 个测试资产不代表历史资料已经纳管。
|
||
- 缺失 MinIO 原件的历史资料无法恢复真实来源。
|
||
- 业务术语尚未由责任人录入并审核。
|
||
- 真实业务 100–300 条黄金样本尚未由责任人录入和冻结；现已具备版本、样本、内容哈希、风险门槛和就绪原因码，但空表和开发样本不得冒充业务标定完成。
|
||
- 生产 Qdrant 一致性、外部告警送达、Recall/nDCG 和无答案误召回尚未验收。
|
||
- 规则自动执行安全门、差异/聚类审核、真实黄金集标定和更完整的自动化运营指标仍需按 P1 实施；当前工作台不提供 `CANARY/ACTIVE`。
|
||
- 本方案没有连接或修改 YCWY，也没有执行历史 staging、人工批准或生产发布。
|
||
|
||
上述数量是最后一次已记录的本地验证快照，不是实时监控值。2026-08-02 收尾检查时本地后端未运行，未重新查询数据库或 Actuator；再次启动、重置数据或执行历史纳管后必须重新取证。
|
||
|
||
更细的代码与行号证据以 [data-quality-audit.md](data-quality-audit.md) 第 19 节为准；接口和生产操作不得从本方案反推，分别以 [API_INTEGRATION.md](API_INTEGRATION.md) 和 [KNOWLEDGE_PLATFORM_RUNBOOK.md](KNOWLEDGE_PLATFORM_RUNBOOK.md) 为准。
|
||
|
||
## 24. 决策清单
|
||
|
||
开始实施前，项目负责人需要正式确认：
|
||
|
||
- [ ] 各知识空间的数据资产负责人和业务审核人。
|
||
- [ ] 哪些资产属于高风险制度、标准答案或敏感领域，是否双审。
|
||
- [ ] 原件保留期、撤回后的审计保留期和合法删除流程。
|
||
- [ ] 各数据用途的准入条件及禁止用途。
|
||
- [ ] 第一版 100–300 条黄金集的标注责任人和冻结日期。
|
||
- [ ] 自动通过、自动隔离和抽样比例的分风险阈值。
|
||
- [ ] 历史纳管优先知识空间与每批 20–50 份的执行窗口。
|
||
- [ ] 生产告警接收人、响应时间和死信处理流程。
|
||
- [ ] 规则晋级、降级和紧急回滚权限。
|
||
- [ ] P0 生产发布、历史治理和业务准确率验收分别签认，不互相冒充。
|
||
|
||
## 25. 最终验收定义
|
||
|
||
数字资产体系达到可用状态，不是看“上传成功”或“模型回答看起来不错”，而是同时满足：
|
||
|
||
1. 新数据不存在任何未经批准进入生产索引的路径。
|
||
2. 每个生产 chunk 均可反查原件、版本、处理规则、适用范围和人工批准。
|
||
3. 原始、候选、可信、合成、运行和评测数据的用途与索引隔离可被测试证明。
|
||
4. 过期、撤回或被替代数据立即停止 MySQL 可见，并最终从向量索引清除。
|
||
5. 跨租户、敏感信息、提示词注入和来源不明数据的误放行为 0。
|
||
6. 错误回答能通过 requestId 定位污染 chunk，并完成撤回、修订和回归。
|
||
7. 自动处理率逐步提高，同时误放行、误隔离和业务准确率有独立证据。
|
||
8. 人工审核由逐份机械处理转向异常、冲突、规则和高风险责任确认。
|
||
9. 历史批次、规则版本、模型版本和索引 generation 均可回滚且不破坏原始证据。
|
||
10. 本地实现、生产部署、历史纳管和业务验收四种状态在所有报告中清晰区分。
|
||
|
||
这套体系的长期价值不是“把资料洗得更像文本”，而是把企业经验加工成有身份、有证据、有责任、有用途、可持续演进的数字资产，并让自动化在可测量、可解释和可回退的边界内不断替代重复人工工作。
|