企业级智能体开源系统方案

主题

ifLabx

数据治理层（企业 AI 数据底座） ​

角色：企业结构化与非结构化数据面向 AI 的统一治理与供给层

目标：把企业原始数据变成可治理、可授权、可复用、可追溯的 AI 可消费数据服务

说明：本文讨论的是当前方案的数据治理链路，不新增新的组件候选。

相关文档：

一、为什么企业 AI 平台需要单独的数据治理层 ​

企业 AI 平台最常见的失败模式之一，是让每个应用直接从源系统临时取数，再自行做切片、权限和索引。

这样做会产生四个问题：

  • 数据源分散、质量不稳定
  • 权限模型不一致
  • 结构化与非结构化数据各自为政
  • 每个 AI 应用重复建设且不可复用

因此，企业智能体方案里必须单独存在一个数据治理层，位于源系统与 AI 消费层之间。

二、这层的定位 ​

可以把数据治理层理解为：

源系统 -> 数据治理层 -> AI 可消费数据服务 -> RAG / 搜索 / 查询 / Agent

它负责的不是“存一份数据”，而是把数据变成可以持续复用的受控资产。

三、治理范围 ​

1. 结构化数据 ​

  • ERP、CRM、HR、财务、供应链等业务系统
  • 工单、订单、客户、产品、组织、项目等业务对象
  • 数仓、湖仓、报表系统

2. 非结构化数据 ​

  • PDF、Word、Excel、PPT
  • Wiki、制度文档、产品说明、FAQ
  • 邮件、会议纪要、表单附件
  • 接口文档、运维文档、项目资料

3. 半结构化内容 ​

  • JSON、CSV、XML
  • OCR 后文本
  • 表格抽取和附件元数据

四、当前方案的数据治理链路 ​

1. 数据源登记 ​

每个数据源都应先登记，再接入。

最低要求：

  • 数据源名称
  • 系统 owner
  • 数据责任人
  • 接入方式
  • 更新频率
  • 数据分类分级
  • 可供哪些 AI 场景使用

目的：

  • 明确数据边界
  • 明确责任归属
  • 明确 AI 使用范围

2. 数据采集与进入原始层 ​

采集并不等于直接建索引。当前方案先把数据进入统一治理链路。

典型方式：

  • 批量同步
  • 增量同步
  • CDC
  • API 拉取
  • 文件接入

治理要求：

  • 采集过程可追踪
  • 失败可重试
  • 同步频率可配置
  • 不同源系统采用统一接入规范

当前方案落点：

  • SeaTunnel
  • MinIO

3. 分层存放与标准化 ​

当前方案建议至少区分三层：

  • Raw：保留原始数据和原始文件
  • Staged：清洗、解析和标准化中间层
  • Curated：治理后、可供 AI 使用的数据层

这样做的价值在于：

  • 可回溯
  • 可重建
  • 可比较治理前后差异
  • 便于审计和质量追踪

当前方案落点：

  • 原始文件与对象数据：MinIO
  • 治理中间结果与元数据配置：PostgreSQL

4. 解析、清洗与结构化处理 ​

数据进入治理层后，必须先做可消费化处理。

典型处理包括：

  • 非结构化内容解析
  • 文本抽取与格式清洗
  • 去重与去噪
  • 结构化字段标准化
  • 业务实体和标签对齐

当前方案落点：

  • Apache Tika 负责文档解析
  • dbt Core 负责结构化数据标准化与建模

5. 元数据、血缘与责任归属 ​

企业 AI 数据底座必须有统一元数据，不然知识与答案无法解释来源。

至少需要治理这些信息：

  • 数据来源
  • 更新时间
  • 数据 owner
  • 责任部门
  • 权限标签
  • 生命周期状态
  • 血缘关系

当前方案落点：

  • OpenMetadata
  • PostgreSQL

6. 权限标签与分类分级 ​

AI 平台不能只在检索时临时判断权限，权限标签应在数据治理阶段就成为资产的一部分。

最低要求：

  • 数据分级分类
  • 部门 / 项目 / 租户标签
  • 敏感字段标识
  • 生命周期和可见范围

结果要求：

  • 权限标签能进入索引元数据
  • 权限标签能被检索和查询链路消费
  • 不同 AI 应用复用同一套治理后的可见范围

7. 知识与索引发布 ​

数据治理层的终点不是“存好了”，而是“发布为 AI 可消费服务”。

当前方案需要支持四类供给：

  1. RAG 数据服务
  2. 搜索数据服务
  3. 结构化查询数据服务
  4. Agent 上下文数据服务

当前方案落点：

  • 知识工程与索引编排：LlamaIndex
  • 默认向量检索底座：Weaviate
  • 数据规模和隔离要求明显上升时，条件演进到 Milvus
  • 全文 / 混合检索兼容项：Elasticsearch

8. 生命周期与失效治理 ​

数据治理层必须负责数据资产的全生命周期。

至少应覆盖：

  • 新增
  • 更新
  • 失效
  • 归档
  • 重建索引
  • 下线

否则会出现：

  • 文档删除后索引仍保留
  • 权限变更后旧索引继续可见
  • 失效内容继续被回答引用

五、面向 AI 系统的供给方式 ​

1. 给知识问答与 RAG ​

  • 提供治理后的文档片段
  • 提供来源元数据
  • 提供 ACL 标签
  • 提供检索、重排和引用所需字段

2. 给搜索 ​

  • 提供全文索引
  • 提供关键词、标签和结构化过滤条件
  • 提供混合检索所需向量和元数据

3. 给查询型 Agent ​

  • 提供受控查询视图
  • 提供指标口径和字段释义
  • 提供可审计的查询入口

4. 给多 Agent 和业务应用 ​

  • 提供统一实体和主数据
  • 提供跨系统上下文
  • 提供可信来源引用

六、建议的模块拆分 ​

模块主要职责当前方案落点
Source Registry数据源登记、owner、分级、接入配置OpenMetadata
Ingestion Service批量、增量、CDC、API、文件采集SeaTunnel
Processing Pipeline文档解析、清洗、标准化、建模Apache Tika、dbt Core
Metadata Catalog元数据、标签、血缘、责任人OpenMetadata
Policy TaggingACL、数据域、敏感级别、生命周期标签数据治理流程 + 元数据体系
Indexing Service向量索引、检索编排、引用构建LlamaIndex + Weaviate
Data Product ServiceRAG、搜索、查询、Agent 上下文服务发布门户 / BFF / 编排层消费

七、当前正式组合 ​

针对当前方案目标，即同时满足 RAG / 搜索 / 查询 / Agent 的数据需求，又保持公开清单收敛，当前正式组合为：

  • OpenMetadata
  • SeaTunnel
  • dbt Core
  • Apache Tika
  • MinIO
  • PostgreSQL
  • LlamaIndex
  • Weaviate

补充说明：

  • Milvus 是数据规模、隔离要求或性能要求显著上升后的条件演进项。
  • Elasticsearch 是全文 / 混合检索兼容项，不作为默认长期并行底座。

八、与当前方案的关系 ​

当前方案中，这一层与其他页面的关系如下：

  • 与 总体架构 的关系：对应数据治理层和知识与检索层之间的桥梁。
  • 与 技术选型 的关系：约束当前正式数据组合和检索底座口径。
  • 与 组件 的关系：说明这些组件为什么存在、怎么分工。
  • 与 安全与治理 的关系：权限标签、分类分级、生命周期都属于治理链路。

九、最关键的原则 ​

这一层真正要解决的，不是“数据有没有接进来”，而是四件事：

  1. 企业数据能否先治理，再给 AI 使用。
  2. 不同 AI 系统能否复用同一套治理后的数据资产。
  3. 权限、标签、版本和生命周期能否贯穿到索引和查询层。
  4. AI 应用消费的是受控数据服务，而不是原始系统直连。

参考资料 ​

Open-source first, enterprise-ready.

Copyright © 2026