数据研发功能优化方案

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

1. 方案摘要

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

核心决策如下：

不推倒现有模块：复用现有数据源安全连接池、MinIO、Neo4j、元数据审核、版本历史、治理知识库和 RBAC。
统一所有信息来源：数据库直连、SQL/DDL、Excel、CSV、Word、PDF、扫描 PDF、图片都进入同一“采集任务—解析候选—证据—审核”流程。
分离四层对象：物理字段、数据元素、业务域、本体不能继续混为同一类元数据节点。
本体是独立治理对象：一个本体可关联多个业务域；业务域提供概念和数据元素，本体负责跨域语义、关系、约束和版本发布。
规则优先、AI 辅助：结构化来源先使用确定性解析；AI 只用于语义补全、同义词识别、概念/关系建议和低质量文档理解。AI 结果必须保留置信度和证据，不能直接发布。
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 行	记录真实来源结构和结构漂移
治理层	数据元素	订单编号、客户证件号码	统一名称、定义、数据类型、标准、敏感等级和质量规则
业务层	业务域	订单域、客户域、供应链域	组织数据元素、责任人和业务上下文
语义层	本体类、属性、关系、约束	客户、订单、客户下单、订单必须有订单编号	构建跨域一致的机器可理解语义

推荐关系模型：

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 总体流程

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")，新增数据库目录采集器：

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

第一阶段覆盖当前已实现的 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 匹配与审核

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

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

现有 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 动态构建模式

支持四种模式并存：

手工建模：拖拽新增类、属性、关系和约束。
模板构建：从行业或企业模板复制一个草稿版本。
来源驱动：从已发布数据元素、业务域关系和数据库主外键生成候选图。
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. 前端信息架构

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

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

为现有 BusinessDomain、DataMeta、DataSource 补齐并对账稳定 UID。
保留 DataMeta 标签和旧 API，新增 DataElement 语义及 UID 查询；兼容期双写关系但不双写版本真相。
将旧业务域上传记录按可获得信息回填为 SourceArtifact；无法恢复原始证据的对象标记 legacy_no_evidence，不得伪造证据。
新采集结果只进入候选和审核，不直接调用旧的业务域保存逻辑批量创建元数据。
先让新页面读取旧+新聚合视图，对账稳定后切换为新控制面读取。
旧接口下线必须有调用清单、灰度期和回滚开关；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. 评审时需要确认的业务决策

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

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

DATA_RESEARCH_GOVERNANCE_ONTOLOGY_OPTIMIZATION.md 29 KB Histórico Raw