前言

随着大模型在企业中的应用越来越广，一个新的问题逐渐出现：企业的数据、文档、日志、知识库，如何被 AI 理解？

很多同学第一反应是：

• 建一个向量数据库
• 把文档做 Embedding
• 然后做 RAG 问答

但实际落地时会发现很多问题：

• 企业数据来源复杂（数据库 / 文档 / 日志）
• 数据持续更新
• 向量库无法管理数据版本
• embedding 重建成本高
• 数据治理与权限体系缺失

因此越来越多公司开始构建 AI 数据平台。

一种非常典型的架构就是：Paimon + Embedding + RAG（湖仓存储 + 语义向量化 + 检索增强生成）

AI 数据平台整体架构

暂时无法在飞书文档外展示此内容

数据接入

企业的数据来源非常多，例如：

• 业务数据库（MySQL / PostgreSQL）
• 文档知识库（PDF / Markdown / Wiki）
• Kafka 日志
• OSS / S3 文件

这些数据通过 Flink CDC、Kafka Stream、Batch ETL等 统一进入湖仓。

Paimon 湖仓

Paimon 在架构中的角色是：AI 数据底座

• 数据统一存储
• 流批一体
• 主键更新
• 历史版本管理
• 增量数据读取

在 AI 场景中，Paimon 中通常会存储：

但这里有一个关键问题：embedding 向量通常非常大。

如果直接存储在普通列中，会导致：

• 查询 IO 激增
• compaction 成本增加
• 表扫描变慢

因此 Paimon 引入了 Blob 存储结构。

Paimon Blob 存储：AI 数据湖的关键设计

存储结构如下：

暂时无法在飞书文档外展示此内容

核心思想是：将大字段从主表中分离出来

LSM主表

Blob文件

blob001 → embedding vector1
blob002 → embedding vector2

这样设计有三个非常重要的好处：

• 减少主表 IO：查询 metadata 时，只扫描 LSM 文件，不需要加载 embedding
• 降低 Compaction 成本：LSM compaction 只处理小字段，而 embedding 不需要重复搬运。
• 天然适合 AI 数据：Blob 结构非常适合存储embedding、图片、PDF、多媒体数据

这也是为什么 Paimon 非常适合作为 AI 数据湖底座

Embedding + 向量检索

数据进入湖仓之后，下一步就是：语义向量化。

流程如下：

暂时无法在飞书文档外展示此内容

总结

传统数据平台解决的是：

• 数据存储
• 指标计算
• BI分析

而 AI 数据平台 需要解决的是：

• 知识理解
• 语义检索
• 自然语言交互
• AI分析

因此一个完整的企业级架构往往是：

Paimon → AI 数据湖
Embedding → 语义理解
Vector DB → 检索
RAG → 大模型问答

最终形成：AI × 湖仓架构

让企业数据真正成为 AI 的燃料