让数据开口说话：OntiCards 的四层架构与我们的实践

为什么我们需要 OntiCards

我们在和大量企业的合作中听到过同一句话："数据很多，但没人能用起来。"

BI 报表堆了几百张，分析师每天疲于奔命写新 SQL，业务人员想看个数字要排队等三天。问题的根源不是工具不够多，而是数据从来就没有真正「被理解」过。它躺在 schema 里、躺在字段名里、躺在工程师的脑子里，业务侧和它之间隔着一整层技术语言。

我们做 OntiCards 想解决的就是这件事：让数据从字段升级为「能被问、能被检索、能被复用的知识」，让业务人员可以直接用自然语言和数据打交道，而不是每次都要先找到人。

四层架构

OntiCards 不是一个大模型套壳，是一个有清晰分层的数据智能体平台：

┌─────────────────────────────────────────┐
│  第四层 · 数据消费层                      │
│  BI 对接 / AI 智能体集成 / API 取数        │
├─────────────────────────────────────────┤
│  第三层 · 智能问数层                      │
│  卡片驱动的自然语言问答                   │
├─────────────────────────────────────────┤
│  第二层 · 数据卡片层                      │
│  本体建模 · 业务术语 · 实体识别           │
├─────────────────────────────────────────┤
│  第一层 · 数据接入与质检层                 │
│  多源连接 · 字段抽取 · 质量校验            │
└─────────────────────────────────────────┘

第一层：让数据进来，并知道它干不干净

我们接入了 9 种主流数据库（PostgreSQL、MySQL、Oracle、SQL Server、Trino、SQLite、KingBase、OceanBase、达梦），对结构化数据做自动字段抽取。然后跑一轮质量校验：身份证号格式、姓名一致性、数值范围、外键引用——把脏数据的位置和原因讲清楚。

这一步的目的不是把数据"治理好"（那是另一条慢线），而是让人知道「这里有什么」「哪些字段是可用的」「哪些规则被触发了」。质量分打到 81.1 或 100.0，都是透明可见的。

第二层：把字段变成「数据卡片」

字段是技术视角，业务人员看不懂；术语是业务视角，但又是孤立的。

我们的做法是把两者在中间对齐：对每一张表，自动生成一份「数据卡片」，卡片上同时有技术字段、业务描述、典型问题示例。一个叫 id_card_name 的字段，在卡片里会写清楚它是「身份证姓名」、常用于和 customer_name 做一致性比对、能回答什么样的业务问题。

业务术语库（行业模板）是另一条线：财务、电商、化工、制造，每个行业都有自己的「黑话」。把这些词挂到对应的数据卡片上，问数的时候系统就知道「营收」「流水」「GMV」在不同的语境下指什么。

第三层：用自然语言问数据

这是用户最直接感知的层。前面所有的工作工作，让这一步变得可能：

• 选一张数据卡片（也就是限定了问答的范围）

• 用自然语言提问

• 系统生成 SQL、跑查询、用人话回答

这一步最容易做出来，也最容易做死。三个最常见的坑我们都踩过：

1. schema 太大，模型选择错列 → 用数据卡片做预筛选

1. 业务词和字段名对不上 → 用术语库做意图识别

1. 多表关联出错 → 用本体关系约束 join 路径

第四层：把回答接出去

数据最终要回到业务系统里：BI 看板、自动化报表、AI 智能体、API、推送、订阅。我们把这一层做得足够薄——OntiCards 不是一个封闭的 BI 工具，而是数据智能的「底座」。上面接什么，由你决定。

和传统 BI 的区别

我们想让 OntiCards 成为什么

不是一个更大的 BI 工具，而是一个让数据「被理解」的中间层。

我们希望业务人员拿到手的不是一张张看板，而是一个可以被问、被检索、被复用的「数据世界」。我们希望企业里的隐性知识能留下来，能被下一个十年继续用。

这是 OntiCards 的存在意义，也是我们每天在做的事。