# 数据研发功能优化方案

> 任务标题：数据研发功能优化  
> 文档状态：建议方案 / 待评审  
> 适用范围：DataOps 平台“数据研发”模块  
> 基线日期：2026-07-21

## 1. 方案摘要

本次升级建议把当前以“元数据、业务域、文件解析”为主的数据研发模块，升级为一个统一的**数据知识生产与治理工作台**：所有数据库结构、文件和图片先进入统一采集链路，形成带来源证据的候选数据元素；候选元素经过查重、映射、审核和版本管理后，进入业务域；多个业务域再共同服务于一个可版本化、可发布、可回滚的数据本体。

核心决策如下：

1. **不推倒现有模块**：复用现有数据源安全连接池、MinIO、Neo4j、元数据审核、版本历史、治理知识库和 RBAC。
2. **统一所有信息来源**：数据库直连、SQL/DDL、Excel、CSV、Word、PDF、扫描 PDF、图片都进入同一“采集任务—解析候选—证据—审核”流程。
3. **分离四层对象**：物理字段、数据元素、业务域、本体不能继续混为同一类元数据节点。
4. **本体是独立治理对象**：一个本体可关联多个业务域；业务域提供概念和数据元素，本体负责跨域语义、关系、约束和版本发布。
5. **规则优先、AI 辅助**：结构化来源先使用确定性解析；AI 只用于语义补全、同义词识别、概念/关系建议和低质量文档理解。AI 结果必须保留置信度和证据，不能直接发布。
6. **PostgreSQL 管控制面，Neo4j 管发布图**：审核、任务、版本、发布状态和不可变快照以 PostgreSQL 为准；Neo4j 保存当前生效的语义图和查询投影；MinIO 保存原始文件及解析中间产物。

## 2. 当前能力与主要缺口

以下结论来自当前主源码 `app/` 和 Vue 2 前端 `frontend/src/`，不把 `deployment/app/` 发布副本重复计算为另一套实现。

| 能力 | 当前实现 | 结论 |
| --- | --- | --- |
| 数据研发菜单 | 元数据、业务域、数据标准、数据流程、数据安全、数据标签、数据源 | 可保留导航体系，但缺少统一采集中心、本体中心和任务中心 |
| 文件采集 | 业务域支持上传 SQL、XLS/XLSX、DOC/DOCX、PDF、TXT 到 MinIO | 文件存储可复用；上传和解析规则不一致 |
| 文件解析 | `/api/bd/ddlparse` 支持 SQL、Excel、DOCX、文本型 PDF | CSV、图片、扫描 PDF 未解析；`.doc` 虽在允许清单中，但解析时实际拒绝 |
| DDL 解析 | 本地正则优先，复杂 DDL 回退 LLM | 可作为兜底，但缺少方言级解析、约束/索引/血缘和证据位置 |
| 数据库直连 | 有安全凭据、连接池、只读 `metadata_collection` 用途 | 当前只支持 PostgreSQL/MySQL，尚无目录采集器和结构快照任务 |
| 数据元素 | Neo4j `DataMeta` 节点，业务域通过 `INCLUDES` 关联 | 字段较少，物理字段与逻辑数据元素未分层 |
| 查重审核 | PostgreSQL `metadata_review_records` 支持候选、处置和审核 | 可复用，但来源类型、证据、置信度和批次信息不足 |
| 版本历史 | `metadata_version_history` 保存前后快照 | 可复用，但仍依赖 Neo4j 内部整数 ID；应全面切换稳定 UID |
| 业务域 | `BusinessDomain` 节点，可关联数据源、标签和 `DataMeta` | 已具备跨对象图关系基础 |
| 图谱 | Neo4j 已有通用节点、关系与图查询 | 当前 `Entity` 还不是完整本体模型，缺少类、属性、约束、版本和发布语义 |
| 治理知识库 | PostgreSQL 文档/分块/向量和同步任务基础 | 可用于索引已发布的数据元素和本体版本 |
| 权限 | 后端统一 RBAC，现有 `governance:read/edit`、`review:approve` 等 | 本体发布、来源采集、敏感文件下载需要更细粒度权限 |

### 2.1 根本问题

当前流程以“创建业务域时顺便上传并解析文件”为中心，导致来源、解析任务、候选项、审核结果和最终治理对象耦合在一个页面和同步请求中。随着来源类型增加，会出现以下问题：

- 同一文件重复上传会产生重复候选，无法稳定重放或对比解析结果。
- 长文档、OCR 和大库采集容易阻塞请求，失败后无法断点续跑。
- 无法回答“这个数据元素来自哪个文件、哪一页、哪个表格、哪次数据库快照”。
- 物理字段变更可能直接污染逻辑数据元素，无法区分结构漂移与业务语义变更。
- 业务域组合只是组合数据元素，不等于本体建模，无法表达跨域概念、关系和约束。

## 3. 建设目标与边界

### 3.1 建设目标

- 统一接入数据库和非结构化/半结构化文件，形成异步、可追踪、可重放的采集任务。
- 建立数据元素从发现、标准化、查重、审核、发布到退役的完整生命周期。
- 支持一个本体服务多个业务域，支持手工、模板、规则和 AI 辅助的动态本体构建。
- 所有发布对象都具备稳定 UID、版本、责任人、来源证据、变更审计和权限范围。
- 发布后的数据元素和本体可供数据目录、数据标准、数据服务、数据流、智能问答和 MCP 使用。

### 3.2 非目标

- 第一阶段不抓取业务数据库的真实业务数据，默认只读取系统目录、DDL 和必要的统计信息。
- 第一阶段不把 LLM 输出当作治理事实，也不允许 AI 自动发布本体。
- 不在本次升级中替换 Neo4j、PostgreSQL、MinIO 或现有工作流控制面。
- 不立即删除现有 `/api/meta`、`/api/bd` 和 `DataMeta`，采用兼容迁移。

## 4. 统一领域模型

必须明确以下对象边界：

| 层次 | 对象 | 示例 | 主要责任 |
| --- | --- | --- | --- |
| 物理层 | 数据资产、表、字段、文件片段 | `ods_order.order_id`、Excel 第 2 个 Sheet 第 5 行 | 记录真实来源结构和结构漂移 |
| 治理层 | 数据元素 | 订单编号、客户证件号码 | 统一名称、定义、数据类型、标准、敏感等级和质量规则 |
| 业务层 | 业务域 | 订单域、客户域、供应链域 | 组织数据元素、责任人和业务上下文 |
| 语义层 | 本体类、属性、关系、约束 | 客户、订单、客户下单、订单必须有订单编号 | 构建跨域一致的机器可理解语义 |

推荐关系模型：

```mermaid
graph LR
  S["来源 Source"] --> A["物理资产 PhysicalAsset"]
  A --> F["物理字段 PhysicalField"]
  F -->|REALIZES| E["数据元素 DataElement"]
  D1["业务域 A"] -->|OWNS_OR_USES| E
  D2["业务域 B"] -->|OWNS_OR_USES| E
  O["本体 Ontology"] -->|SERVES_DOMAIN| D1
  O -->|SERVES_DOMAIN| D2
  O --> C["本体类 OntologyClass"]
  C --> P["本体属性 OntologyProperty"]
  E -->|MAPS_TO| P
  C --> R["本体关系 OntologyRelation"]
```

业务域与本体是多对多关系。一个业务域可参与多个专题本体，一个本体也可整合多个业务域。`BusinessDomain-[:INCLUDES]->DataMeta` 在兼容期保留，但新模型应逐步迁移为稳定 UID 关系。

## 5. 目标架构

### 5.1 总体流程

```mermaid
flowchart LR
  subgraph Sources["信息来源"]
    DB["数据库直连"]
    DDL["SQL / DDL"]
    TAB["Excel / CSV"]
    DOC["Word / PDF"]
    IMG["扫描 PDF / 图片"]
  end

  Sources --> IN["统一采集服务"]
  IN --> RAW["MinIO 原始件与中间件"]
  IN --> JOB["异步采集任务"]
  JOB --> EX["确定性抽取 / OCR / 文档解析"]
  EX --> NORM["统一规范化与来源证据"]
  NORM --> AI["规则匹配 + AI 语义建议"]
  AI --> CAND["候选数据元素 / 候选本体变更"]
  CAND --> REVIEW["人工审核与差异处置"]
  REVIEW --> VER["版本化治理对象"]
  VER --> PG["PostgreSQL 控制面"]
  VER --> OUTBOX["Outbox 发布事件"]
  OUTBOX --> NEO["Neo4j 当前生效语义图"]
  OUTBOX --> KB["治理知识库 / 向量索引"]
```

### 5.2 存储职责

| 存储 | 权威数据 | 不应承担的职责 |
| --- | --- | --- |
| PostgreSQL | 采集任务、解析候选、证据索引、审核、版本快照、发布状态、权限范围、审计 | 不承担大文件内容和高频图遍历 |
| Neo4j | 当前生效的数据元素、业务域、本体类/属性/关系及映射图 | 不作为审核状态和不可变版本历史的唯一真相源 |
| MinIO | 原始上传件、OCR 结果、解析中间产物、导入/导出包 | 不保存治理状态 |
| 治理知识库 | 已发布版本的检索文档、分块、向量 | 不代替结构化治理对象和权限判断 |

跨存储发布使用现有 Outbox 思路：PostgreSQL 先提交版本与发布事件，消费者幂等更新 Neo4j 和知识索引，失败可重试和对账，避免接口内直接双写。

## 6. 多源采集与解析设计

### 6.1 统一采集对象

所有来源统一抽象为：

- `IngestionSource`：来源定义，如数据库数据源、上传文件、手工粘贴 DDL。
- `IngestionJob`：一次采集运行，记录状态、解析器版本、参数、发起人、统计和错误。
- `SourceArtifact`：原始文件或数据库结构快照，包含 SHA-256、MIME、大小、MinIO 地址和保留策略。
- `EvidenceFragment`：候选项的证据位置，如库/Schema/表/字段，或文件页码/Sheet/表格/单元格/图片框坐标。
- `ExtractionCandidate`：统一的候选表、字段、数据元素、概念或关系，包含置信度和建议来源。

同一来源、同一内容哈希、同一解析器版本应具备幂等键。用户可选择复用已有结果或强制以新解析器版本重跑。

### 6.2 数据库直连

复用 `DataSourceConnectionManager.connect(uid, "metadata_collection")`，新增数据库目录采集器：

1. 选择数据源、Schema、表/视图范围和排除规则。
2. 通过白名单系统目录查询采集表、视图、字段、类型、默认值、主外键、唯一约束、索引、注释。
3. 默认只读元数据；表行数、空值率等统计必须单独授权、限时和限量。
4. 生成结构快照，与上一次快照比较新增、删除、重命名和类型变化。
5. 把物理字段映射为候选数据元素，进入统一审核，不直接覆盖已发布元素。

第一阶段覆盖当前已实现的 PostgreSQL、MySQL；Oracle、SQL Server 需要先新增安全适配器、目录查询和测试矩阵，不能只在页面上增加类型选项。

### 6.3 文件与图片

| 来源 | 主解析器 | AI/OCR 作用 | 关键输出 |
| --- | --- | --- | --- |
| SQL/DDL | SQL 方言解析器；失败时使用现有本地/LLM 兜底 | 补充中文名、业务定义和同义词 | 表、字段、约束、注释、血缘引用 |
| XLS/XLSX | 工作簿、Sheet、表头和单元格确定性读取 | 识别非标准数据字典模板 | 字段行、单元格证据、模板映射 |
| CSV | 编码/分隔符探测和流式读取 | 推断业务含义，不替代原始值 | 列、推断类型、表头证据 |
| DOCX | 段落、标题和表格结构解析 | 识别散文中的字段定义 | 文档片段、表格坐标、候选元素 |
| 文本型 PDF | 页面文本和表格解析 | 版面语义合并 | 页码、表格、文本块 |
| 扫描 PDF/图片 | OCR + 版面分析 | 纠错、语义归一和关系建议 | 文字框坐标、页码、OCR 置信度 |

处理要求：

- 上传校验统一 MIME、扩展名、魔数、大小和页数限制，不再由“上传接口”和“解析接口”维护两套清单。
- `.doc` 明确为“不支持并要求转换”，或增加受控的服务端转换；不能继续出现接口文档声称支持、运行时拒绝的状态。
- 对 CSV、Excel 的值样本默认只在任务内存或受控临时区处理；进入证据库前做敏感信息识别和脱敏。
- 每个候选项必须能回到原始证据；用户在审核页可点击定位到具体字段、页码、Sheet 或图片区域。
- 解析器采用插件接口 `can_handle / extract / normalize / evidence`，便于后续增加 Markdown、JSON Schema、OpenAPI 等来源。

### 6.4 异步任务

文件解析、OCR、数据库全量采集必须异步执行，前端使用任务状态轮询或服务端事件获取进度。建议状态：

`created -> queued -> extracting -> normalizing -> matching -> awaiting_review -> published/partial/failed/cancelled`

每个阶段记录输入哈希、输出哈希、耗时、解析器版本和错误摘要，支持从失败阶段重试，不重复执行已成功且输入未变化的阶段。

## 7. 数据元素治理升级

### 7.1 数据元素主数据

在现有 `DataMeta` 基础上建立正式 `DataElement` 语义，至少包含：

- 稳定 `uid`、编码、中文名、英文名、简称、别名和定义。
- 逻辑数据类型、长度、精度、格式、值域、计量单位、是否可空。
- 数据标准、敏感等级、分级分类、质量规则、主数据标识。
- 所属/使用业务域、责任人、责任组织、状态和生效区间。
- 来源类型、来源 UID、证据 UID、置信度、创建方式。
- 当前版本、发布状态、替代元素和废止原因。

物理字段与数据元素是多对多映射：同一数据元素可由多套系统字段实现，一个物理字段也可能承载复合语义，但后者必须进入人工审核。

### 7.2 生命周期

`candidate -> draft -> in_review -> published -> deprecated -> retired`

- 候选：解析器或人工发现，尚未成为治理事实。
- 草稿：已认领并完成基础字段。
- 审核中：冻结本次变更集，计算与现有元素的差异和影响范围。
- 已发布：写入当前语义图并同步治理知识库。
- 已废止/退役：保留历史和替代关系，不做物理删除。

### 7.3 匹配与审核

匹配分为四级，均保留原因：

1. 确定性匹配：稳定 UID、来源路径、标准编码。
2. 规则匹配：中英文名、别名、类型、值域、业务域。
3. 语义匹配：向量相似度和 LLM 解释。
4. 人工判定：复用、合并、创建、映射、忽略、退役。

现有 `metadata_review_records` 可作为第一阶段审核底座，新增 `ingestion_job_uid`、`candidate_uid`、`evidence_uids`、`confidence`、`parser_version`、`business_domain_uid` 和影响分析字段。所有新逻辑使用稳定 UID，Neo4j 整数 ID 只用于旧接口兼容。

## 8. 本体定义与动态本体构建

### 8.1 本体对象

本体不是业务域的另一个名称，应包含：

- `Ontology`：名称、编码、目的、所有者、适用范围、状态。
- `OntologyVersion`：不可变版本、父版本、变更摘要、发布人和发布时间。
- `OntologyClass`：业务概念及层级，例如客户、订单、产品。
- `OntologyProperty`：概念的属性，可映射到一个或多个数据元素。
- `OntologyRelation`：概念间有方向、有基数的业务关系。
- `OntologyConstraint`：必填、唯一、值域、基数、互斥、依赖等约束。
- `OntologyMapping`：本体类/属性与业务域、数据元素、物理资产的映射。

内部使用平台图模型；对外提供 RDF/OWL 导入导出，并可用 SHACL 表达约束。外部标准是交换边界，不要求平台内部所有治理状态都存成 RDF 三元组。

### 8.2 多业务域服务一个本体

新增显式关系：

- `Ontology-[:SERVES_DOMAIN {role, scope, priority}]->BusinessDomain`
- `BusinessDomain-[:CONTRIBUTES]->OntologyClass`
- `DataElement-[:MAPS_TO {mapping_type, confidence, status}]->OntologyProperty`

`role` 可取 `owner/contributor/consumer`。本体发布前必须至少有一个 owner 业务域和责任人，避免跨域本体无人负责。

### 8.3 动态构建模式

支持四种模式并存：

1. **手工建模**：拖拽新增类、属性、关系和约束。
2. **模板构建**：从行业或企业模板复制一个草稿版本。
3. **来源驱动**：从已发布数据元素、业务域关系和数据库主外键生成候选图。
4. **AI 辅助**：基于定义、别名、样例和文档证据建议概念聚类、父子类、关系和约束。

动态构建只生成 `OntologyChangeSet`，不能直接修改已发布图。每个建议必须显示：建议类型、置信度、证据、影响对象、冲突和接受/拒绝原因。

### 8.4 版本与发布

- 草稿版本允许多人协作，但发布时生成不可变快照和内容哈希。
- 变更分为新增、修改、删除、重命名、合并、拆分和映射变化。
- 发布前执行命名唯一性、悬空关系、循环继承、基数冲突、必填属性映射和权限检查。
- 破坏性变更必须展示受影响的数据元素、数据流、数据产品和知识索引。
- 回滚不是覆盖历史，而是基于旧版本创建一个新的发布版本。
- Neo4j 只暴露当前生效版本；历史版本从 PostgreSQL 快照恢复或按需投影。

## 9. 建议数据模型

### 9.1 PostgreSQL 控制面

| 表 | 作用 |
| --- | --- |
| `ingestion_sources` | 统一来源定义和权限范围 |
| `ingestion_jobs` | 异步任务状态、参数、统计、错误和幂等键 |
| `source_artifacts` | 原始件元数据、哈希、MIME、MinIO 地址和保留策略 |
| `evidence_fragments` | 页码、Sheet、单元格、字段路径、图片框坐标等证据 |
| `extraction_candidates` | 标准化候选对象、置信度、解析器和处置状态 |
| `data_element_versions` | 数据元素不可变版本快照 |
| `ontologies` | 本体主记录、所有者和状态 |
| `ontology_versions` | 本体不可变版本及内容哈希 |
| `ontology_change_sets` | 动态构建建议、审核和发布变更集 |
| `ontology_publish_runs` | 发布、投影、知识索引同步和对账结果 |

已有 `metadata_review_records`、`metadata_version_history`、`governance_documents/chunks` 和 Outbox 先扩展复用，不重复造同类表。

### 9.2 Neo4j 发布图

建议节点标签：

`Source`、`PhysicalAsset`、`PhysicalField`、`DataElement`、`BusinessDomain`、`Ontology`、`OntologyClass`、`OntologyProperty`、`OntologyRelation`、`DataStandard`、`DataLabel`。

所有节点必须有唯一稳定 `uid`；关键关系也应有 `uid` 或由版本快照中的稳定键唯一标识。至少建立 UID 唯一约束和名称/编码查询索引。

## 10. API 设计

为降低旧接口耦合，建议新增编排边界 `/api/development/v1`，旧的 `/api/meta`、`/api/bd`、`/api/datasource` 保持兼容，由新服务复用底层能力。

### 10.1 采集与任务

- `POST /sources/files`：上传原始件并返回 `artifact_uid`。
- `POST /ingestion-jobs`：创建文件、DDL 或数据库采集任务。
- `GET /ingestion-jobs`、`GET /ingestion-jobs/{uid}`：列表、进度和错误。
- `POST /ingestion-jobs/{uid}/retry|cancel`：重试或取消。
- `GET /ingestion-jobs/{uid}/candidates`：候选项和证据。
- `GET /evidence/{uid}`：按权限预览原始证据定位。

### 10.2 数据元素

- `GET/POST /data-elements`
- `GET/PATCH /data-elements/{uid}`
- `POST /data-elements/{uid}/submit-review`
- `POST /data-elements/{uid}/publish|deprecate`
- `GET /data-elements/{uid}/versions|lineage|mappings`
- `POST /candidate-decisions/batch`：批量复用、创建、映射或忽略。

### 10.3 本体

- `GET/POST /ontologies`
- `POST /ontologies/{uid}/versions`：创建草稿版本。
- `GET/PATCH /ontology-versions/{uid}/graph`
- `POST /ontology-versions/{uid}/generate`：从业务域/元素生成变更集。
- `POST /ontology-change-sets/{uid}/decisions`：审核建议。
- `POST /ontology-versions/{uid}/validate|publish`
- `POST /ontologies/{uid}/rollback`
- `GET /ontologies/{uid}/diff?from=&to=`
- `GET/POST /ontologies/{uid}/export|import`：RDF/OWL/JSON 包。

列表接口统一分页、排序、过滤和错误结构；写接口接受幂等键；并发编辑使用版本号或 ETag，避免后提交覆盖先提交。

## 11. 前端信息架构

“数据研发”建议调整为以下二级菜单：

1. **研发总览**：来源数、任务成功率、待审核、元素质量、本体版本和结构漂移。
2. **数据采集**：数据库直连、文件上传、DDL 粘贴、采集配置和历史任务。
3. **数据元素**：由现“元数据”升级，增加来源、映射、版本、质量和影响分析。
4. **业务域**：保留现有页面，改为从已审核元素中编排，不再承担文件解析主流程。
5. **本体中心**：本体列表、业务域服务关系、版本、发布和差异比较。
6. **本体工作台**：图编辑、候选建议、冲突、约束校验和映射覆盖率。
7. **审核中心**：统一处理数据元素、本体变更和结构漂移。
8. **任务中心**：采集、解析、OCR、发布、索引同步的运行记录。

典型操作流：

`选择来源 -> 配置范围 -> 启动任务 -> 查看解析预览 -> 批量处置候选 -> 提交审核 -> 发布数据元素 -> 选择多个业务域 -> 生成本体草稿 -> 校验/评审 -> 发布本体`

## 12. 权限、安全与合规

在现有 RBAC 上新增权限：

- `ingestion:run`：启动采集和解析任务。
- `ingestion:admin`：配置解析器、重试和取消他人任务。
- `evidence:download`：下载原始文件；普通读取者仅可预览脱敏片段。
- `data-elements:edit`、`data-elements:publish`。
- `ontologies:edit`、`ontologies:publish`。

建议角色映射：viewer 只读；editor 可采集和编辑草稿；reviewer 可审核；ontology_admin 可发布本体；admin 管理平台配置。后端必须逐接口强制权限，前端菜单隐藏只改善体验。

安全要求：

- 数据源凭据继续密文保存且不回传页面；目录采集使用现有只读连接目的和超时限制。
- 数据库查询必须由适配器生成并按数据库类型白名单化，不接受用户任意 SQL 作为“元数据采集”。
- 上传文件执行类型/大小校验、恶意文件检测、压缩炸弹防护和租户/权限隔离。
- 原始件、OCR 文本、模型请求和日志都要脱敏；禁止把凭据、连接串和敏感样例发送给 LLM。
- 模型、提示词、解析器和 OCR 版本进入任务审计，保证结果可复现。

## 13. 分阶段实施路线图

以下按两周一个迭代估算，可由前后端、数据工程和测试并行推进。

### V60：统一模型与采集底座（1 个迭代）

- 确认四层领域模型、稳定 UID 和存储权威边界。
- 建立采集任务、原始件、证据、候选项表和新 `/api/development/v1` 蓝图。
- 把业务域现有上传入口适配到统一任务，保留旧接口兼容。
- 增加任务列表、状态机、幂等、重试和基础指标。

### V61：数据库直连与结构化文件（2 个迭代）

- PostgreSQL/MySQL 目录采集、范围选择、结构快照和差异。
- SQL 方言解析、CSV、Excel 确定性解析和证据定位。
- 数据元素候选批量审核，扩展现有审核与版本表。
- 业务域改为引用已审核数据元素。

### V62：文档、PDF 与图片解析（2 个迭代）

- DOCX、文本 PDF 结构抽取标准化。
- 扫描 PDF/PNG/JPG OCR、版面定位、置信度和人工纠错。
- 统一文件校验、敏感样例脱敏和 MinIO 保留策略。
- 解析器质量评测集和回归基线。

### V63：本体 MVP（2 个迭代）

- 本体、版本、类、属性、关系、约束和多业务域关系。
- 本体列表、图工作台、数据元素映射和完整性校验。
- 手工与来源驱动构建、版本差异、发布和回滚。
- PostgreSQL 到 Neo4j 的 Outbox 投影与对账。

### V64：动态本体与知识服务（2 个迭代）

- AI 概念聚类、关系/约束建议和可解释证据。
- 候选变更集审核、冲突处理和影响分析。
- RDF/OWL/JSON 导入导出，已发布本体同步治理知识库。
- 为数据目录、数据流、数据产品、智能问答和 MCP 提供只读语义查询。

### V65：生产加固（1 个迭代）

- 大文件/大库压测、断点续跑、任务限流和容量规划。
- 权限矩阵、审计、备份恢复、灾难演练和运营看板。
- 旧接口双读对账、灰度切换和兼容清理清单。

## 14. 验收标准

### 14.1 功能验收

- 数据库直连、SQL、XLS/XLSX、CSV、DOCX、文本 PDF、扫描 PDF、PNG/JPG 均可创建统一采集任务。
- 每个候选数据元素至少关联一个可回溯证据；文件证据定位到页/Sheet/单元格/区域，数据库证据定位到数据源/Schema/表/字段/快照。
- 同一文件哈希和解析器版本重复提交不会重复创建治理对象。
- 数据库结构变化生成差异任务，不直接覆盖已发布数据元素。
- 一个本体可关联至少两个业务域，并可区分 owner、contributor、consumer。
- 本体支持草稿、校验、审核、发布、版本差异和基于旧版创建回滚版。
- AI 建议未经人工接受无法进入已发布数据元素或本体。

### 14.2 质量与性能验收

- 预置金标样本集覆盖所有来源类型，并分别统计表识别、字段识别、类型识别、证据定位和语义匹配准确率。
- 结构化来源字段识别准确率目标不低于 99%；文档/OCR 以金标集确定分层门槛，低置信度自动进入人工复核。
- 1 万字段规模的数据库目录采集支持分页、超时、取消和重试；具体时延指标在 V60 用基准环境固化。
- 发布任务具备幂等性；Neo4j 投影或知识索引失败时，PostgreSQL 已发布版本不丢失，可重试并对账。
- viewer 对写接口返回 403；无效令牌返回 401；敏感原始件下载必须单独授权。

### 14.3 运维验收

- 可查看任务成功率、平均耗时、失败阶段、候选接受率、人工审核时长、本体映射覆盖率和投影延迟。
- 原始件、版本快照、Neo4j 投影和知识索引均有备份/恢复与一致性检查方案。
- 日志和接口响应不出现数据库密码、完整连接串、访问令牌或未经授权的敏感样例。

## 15. 兼容迁移策略

1. 为现有 `BusinessDomain`、`DataMeta`、`DataSource` 补齐并对账稳定 UID。
2. 保留 `DataMeta` 标签和旧 API，新增 `DataElement` 语义及 UID 查询；兼容期双写关系但不双写版本真相。
3. 将旧业务域上传记录按可获得信息回填为 `SourceArtifact`；无法恢复原始证据的对象标记 `legacy_no_evidence`，不得伪造证据。
4. 新采集结果只进入候选和审核，不直接调用旧的业务域保存逻辑批量创建元数据。
5. 先让新页面读取旧+新聚合视图，对账稳定后切换为新控制面读取。
6. 旧接口下线必须有调用清单、灰度期和回滚开关；`deployment/app/` 通过发布同步脚本更新，不直接作为主源码开发。

## 16. 主要风险与控制措施

| 风险 | 控制措施 |
| --- | --- |
| 把物理字段直接当业务概念 | 强制四层模型和显式映射，禁止采集任务直接发布 |
| LLM 幻觉或结果漂移 | 规则优先、金标评测、版本记录、证据展示、人工发布门禁 |
| OCR 低质量造成错误治理 | 置信度门槛、区域纠错、原图对照和人工复核 |
| Neo4j 与 PostgreSQL 不一致 | 单一控制面、Outbox、幂等投影、周期对账和可重放 |
| 大库/大文件拖垮服务 | 异步任务、分页、限流、超时、取消、资源配额和独立 Worker |
| 敏感数据进入日志或模型 | 最小采样、脱敏、模型请求审计、文件权限和凭据零暴露 |
| 本体范围过大难以落地 | 先选 2 个业务域和 1 个核心场景做 MVP，再扩域 |
| 旧接口兼容期长期不结束 | 建立调用清单、迁移看板和明确下线版本 |

## 17. 建议的 MVP 范围

首个可验证 MVP 建议选择“客户域 + 订单域”或平台现有数据最完整的两个业务域，完成：

- PostgreSQL/MySQL 直连、SQL、Excel、CSV、DOCX/PDF 中至少各一个真实样本。
- 100—300 个候选字段经过审核形成数据元素。
- 构建一个跨两个业务域的本体，包含 10—20 个类、30—60 个属性和 10—20 条关系。
- 演示结构变更发现、候选差异审核、本体版本发布、回滚和知识检索。

MVP 成功标准不是“图画出来”，而是能从任一本体属性回溯到数据元素、物理字段和来源证据，并能从一次来源变化看到对已发布语义的影响。

## 18. 评审时需要确认的业务决策

1. 首个 MVP 选哪两个业务域，以及各自的 owner、数据管理员和本体审核人。
2. 本体发布采用双人复核还是单人发布；破坏性变更是否必须平台管理员确认。
3. 是否允许采集字段统计和少量脱敏样例，还是严格限定只读系统目录。
4. OCR/LLM 使用本地模型还是外部服务，以及哪些数据等级禁止外发。
5. 原始文件、OCR 文本、候选结果和历史版本的保留期限。
6. Oracle、SQL Server 是 V61 必选范围还是后续扩展。

在这些业务决策未确认前，可以先实施 V60 的统一模型、任务、证据和兼容底座；这些工作不会锁死后续数据库、OCR 或模型选型。