腾讯推出 AI 原生数据分析产品 Omega，内测阶段的名称是「马尔摩斯（marmos）」。产品形态很直接：用自然语言生成完整的数据仪表盘，并且不是一次性出图了事——支持持续交互修改、筛选联动与数据动态刷新。真正值得关注的不是”能生成 dashboard”这件事本身（业界已有不少先行者），而是它为此专门设计的底层：QueryRegistry 数据契约 + DTBridge 运行时架构，再叠加多层权限校验与 AST 只读检查。这套组合指向两个长期痛点：AI 看板的数据凝固与把写库权限交给模型的风险。
结论先行：它要解决的是”生成之后怎么办”
过去两年，用大模型生成 SQL、画出图表已经不算新鲜。落地中最尴尬的场景通常出现在第 2 天：昨天生成的看板还是那张图，数据停留在彼时快照；业务口径变了一下，模型又重跑出一份”看起来专业但口径不同”的结果；更棘手的是，没人敢把数据库写权限交给一个会自由发挥的执行器。
因此判断 Omega 这类产品是否成立，看的不该是首屏效果，而是三件事：数据会不会自动跟上、口径能不能被约束、执行安全边界在哪。
能力拆解：从一句话到一块可交互面板
| 环节 | 用户动作 | 系统动作 | 对应要解决的问题 |
|---|---|---|---|
| 发起 | 用自然语言描述想看的指标 | 理解意图，映射到已注册的数据资产 | 避免模型直接自由拼 SQL |
| 生成 | 确认或调整 | 生成图表组合与布局 | 降低取数门槛 |
| 交互 | 追问、改条件、拖拽筛选 | 在上下文基础上持续修改 | 避免每次从头再来 |
| 联动 | 点选某个维度 | 联动刷新关联图表 | 让看板成为探索工具而非静态图 |
| 刷新 | 无感知 | 按数据契约动态刷新 | 破解”数据凝固” |
这张表中真正的难点落在首行的”映射到已注册的数据资产”。它意味着模型不被允许对数据库做任何它想做的事，所有查询必须以事先定义好的契约为边界。这正是 QueryRegistry 的用武之地。
QueryRegistry 数据契约：把口径变成可执行的约束
数据分析里最贵的错误不是 SQL 报错，而是跑通了但算错了。”活跃用户”的定义、GMV 是否含退款、去重口径落在哪个键上——这些口径分歧在人工协作中都会出错，交给模型只会更隐蔽。
数据契约（Data Contract）的思路是：把指标定义、维度取值、关联关系、更新频次等元数据显式登记到一个中央注册表里。模型生成的每一条查询，都必须能在注册表中找到对应条目，而不是临时解读字段名。这样做的好处是多重的：
- 口径统一：同一个指标在任何看板上的计算方式一致，不同人问得到的结果可比；
- 降低幻觉面：模型的自由空间从”任意 SQL”收缩到”从有限契约中选择”，错误的可能形态大幅减少；
- 可治理：口径变更只需改契约定义，依赖它的所有看板同步生效，避免逐个脚本排查。
DTBridge 运行时：让”刷新”成为默认而非例外
传统 BI 看板之所以会凝固，是因为查询结果被当成静态产物保存下来了。DTBridge 这类运行时的作用是把查询定义与执行结果分离：留下的是查询意图与参数，每次访问时按契约重新执行。于是”数据动态刷新”从需要额外配置的功能变成默认行为。
与之配套的代价是运行时压力——高频访问需要缓存策略、增量更新、结果一致性保障等手段。这也是评判产品成熟度时可以留意的地方：在数据量上亿的表上，交互能否维持秒级响应。
安全设计：为什么 AST 只读检查值得单独提一笔
把查询执行权交给 AI，最大的顾虑是写操作。一次误判可能让 AI 执行出一条 UPDATE 或 DELETE，而这在普通行业事故里属于最高等级。AST（抽象语法树）只读检查的做法是：不依赖”模型会听话”的假设，而是在执行前把语句解析成语法树，逐节点核验是否只含查询算子，凡出现写算子一律拦截。
叠加多层权限校验后，形成的是典型的纵深防御：既有模型层的意图约束，也有执行层的语法校验，还有数据层的行/列级权限。三层各自独立，任一环节失效仍有兜底。
和传统 BI、 ChatBI 类产品的位置对比
| 维度 | 传统 BI 工具 | 通用 ChatBI | AI 原生分析平台（Omega 类） |
|---|---|---|---|
| 上手门槛 | 需学习建模与拖拽 | 低（直接提问） | 低（自然语言 + 交互式修改） |
| 口径治理 | 强（语义层成熟） | 弱（多靠模型解读） | 通过数据契约显式约束 |
| 数据时效 | 成熟但配置复杂 | 多为一次性结果 | 运行时动态刷新为默认 |
| 写操作防护 | 由账号权限控制 | 依赖提示词约束 | AST 只读检查 + 多层校验 |
| 主要短板的考察点 | 灵活性与学习成本 | 结果可靠性 | 大规模数据下的交互性能 |
需要说明的是，这部分对比是按产品类型做的一般性归纳，具体到某个功能点的表现，仍以官方当期文档与实际测试为准。
落地前需要想清楚的几点
先把口径治理做在前面
数据契约的价值取决于登记质量。若契约本身残缺，模型只能退回自由发挥。建议优先把高频核心指标登记完整，再逐步扩展。
分场景放开权限
建议先开放只读的探索分析场景，确认规模化可用后再考虑更复杂的用途。写操作无论如何都不应对 AI 直接开放。
建立结果校验习惯
对首批由自然语言生成的看板，建议与人工 SQL 结果做一次交叉验证，把差异记录下来，用于完善契约定义。
常见问题
Q1：Omega 和普通的「对话式 BI」有什么本质区别？
差别主要在治理与执行架构。通用 ChatBI 的短板通常是口径不一致和结果一次性——同一个指标换个问法可能算出不同的值，生成的图表也往往停留在快照。Omega 按公开介绍口径采用了 QueryRegistry 数据契约与 DTBridge 运行时：前者把指标定义显式登记、限制模型自由拼 SQL 的空间；后者把查询定义与执行结果分离，让动态刷新成为默认行为。
Q2：AST 只读检查是怎么保护数据安全的？
它在 SQL 执行前把语句解析成抽象语法树，逐节点核验是否只包含查询类算子，一旦出现写操作算子就拦截。它不依赖模型”自觉不写库”，而是在执行层做强制校验，再叠加多层权限控制形成纵深防御。这意味着即便模型生成了不当语句，也不会到达数据库。
Q3：什么样的团队适合先引入这类工具？
两类团队收益最明显：一是分析需求多但数据人力不足的业务部门，自然语言取数能显著缓解排队；二是已经在工作但口径混乱的团队，被数据契约强制收敛口径本身就是收益。反过来，数据表结构极不规范、元数据缺失严重的团队，建议先做一次资产梳理再接入。
写在最后
AI 进入数据分析领域，第一波解决的是”会不会写 SQL”，第二波要解决的是”算出来的数能不能信、会不会变“。Omega 把答案放在了架构里：契约约束口径、运行时负责时效、AST 只读检查兜住安全边界。这种把约束前置到基础设施的做法，比反复优化提示词更接近工程常态。对企业而言，检验它的标准也很简单——让业务同事自己问一次，看拿到的数与财务口径是否对得上。