Agent 转换语义模型，服务端逐项校验

把指标从一个 BI 工具搬到另一个工具，难点往往不在导出文件，而在「销售额」「延误率」搬过去以后，算出来还是不是同一个数。eMondrian 的做法是让 AI agent 把语义模型转换成 Apache Ossie 文件，再由服务器逐项核对指标。

作者给出的结果是：OnTime 的 13 个指标、FoodMart Sales 的 8 个指标全部匹配。但这套方案验证的是总计一致，层级、权限和部分复杂指标仍有缺口。它值得关注的地方，是把 AI 的灵活转换和服务器的确定性检查接在了一起。

为什么让 agent 转换，却不让它决定对错

语义模型保存的是业务口径：收入怎么算，订单怎么关联客户，哪些指标可以求和，哪些必须重新计算比例。Apache Ossie 提供 YAML 或 JSON 格式，用 datasets、fields、relationships、metrics 描述这些定义。

原文对应的环境是截至 2026 年 11 月的 eMondrian Community 2026.11.10.1、modules 0.0.0.104，采用仍属草案的 Apache Ossie spec 0.3.0.dev0。

作者没有编写固定转换器，而是让 agent 阅读 get_ossie_guide 后处理映射。原因是转换需要判断：SQL 视图如何表达，展示字段如何保留，时间层级遇到格式限制怎么办。规范变化时，可以修改指南。

但「能解释转换过程」不等于「算得正确」。例如比例指标，把各行比例相加，与先汇总分子、分母再相除，结果可能完全不同，文件却都能正常解析。

因此，validate_ossie 把检查分成四层：

• Schema 检查文件是否符合 Ossie 的 JSON Schema。
• Names 检查键、关系和指标引用的字段是否存在，并禁止指标引用另一个指标。
• Source 对照数据库检查数据集、字段和指标，不读取数据行。
• Parity 由服务器根据文档构造 SQL，把每个指标的总计与 cube 中对应 measure 的总计比较。

agent 负责提出转换结果，服务器负责给出匹配证据。

服务器不会执行 agent 编写的 SQL。遇到不一致，返回 MISMATCH 和两边的总计，让 agent 继续修正。

一个文件能搬走什么，又会丢掉什么

导出时，每个 cube 对应一个文档：表和视图变成 datasets，属性变成 fields，键变成 relationships，度量变成 metrics。

下面这段原始示例展示了销售表、门店表以及金额指标如何连接起来：

version: 0.3.0.dev0
name: shop_sales
datasets:
  - name: sales
    source: FACT
    fields:
      - {name: store_id, expression: {sql: STORE_ID}}
      - {name: amount, expression: {sql: AMOUNT}, datatype: Decimal}
    metrics:
      - name: amount_total
        expression: {sql: SUM(amount)}
        custom_extensions:
          - {vendor_name: emondrian, data: '{"cube": "Sales", "measure": "Amount"}'}
  - name: store
    source: STORE
    primary_key: [store_id]
    fields:
      - {name: store_id, expression: {sql: STORE_ID}}
      - {name: city, expression: {sql: CITY}}
relationships:
  - {name: sales_store, from: sales, to: store, from_columns: [store_id], to_columns: [store_id]}

要留意 custom_extensions 中的映射：它记录了指标对应的 cube 和 measure。原文给出的核对结果是 sales.amount_total -> [Sales].[Measures].[Amount] 匹配，两侧分别为 100.00 和 100.0。

作者报告，基于 ClickHouse 美国航班数据的 OnTime cube 达到 13/13 匹配，FoodMart Sales 达到 8/8。公开演示覆盖约 1.82 亿条航班记录，Flights 两侧均为 182,315,946，验证约耗时 2.5 秒。这是作者提供的演示结果，不能直接当作其他模型的性能预期。

反向导入时，agent 把 datasets 变成视图，把关系的 to 端变成维度，把 metrics 变成 measures，并补建层级。随后 Power BI 可以通过 DAX 实时连接，Excel PivotTables 和 AI agent 也能使用这些定义。作者用 Cube converter 的模型试过：生成两个 cube，6/6 指标匹配。

不过，Ossie 没有层级，导入时只能由 agent 提议重建。原文还指出，当时 apache/ossie-converters 中的转换器都输出 spec 0.2，会被 0.3.0.dev0 拒绝，需要按指南升级文档。

更大的缺口在语义覆盖范围。Ossie 没有角色和行限制，导出的文件不携带访问规则。年初至今、上一周期、依赖当前单元格的计算，以及去重计数的求和或比值，也没有对应表达；它们只能进入其他工具会忽略的 eMondrian 扩展，或被省略并告警。

我的判断

这个方案最有价值的设计，是把转换后的指标拿回原系统核对。对于 AI 生成配置、查询或数据模型的流程，「生成成功」很容易被误当作「业务正确」，这里至少建立了可检查的边界。

但 总计一致只是迁移验收的一部分。 不同城市、月份或客户分组下的错误，可能在总计上看不出来。原文明确说 Parity 不检查各维度下的结果，也没给出更完整的对照数据。

验证还有数据权限前提：只有 agent 可以读取目录真实数据时，才执行 Parity；如果目录只向 agent 展示合成数据，就只做结构检查。拿到「通过」结果时，必须先看实际跑了哪些检查。

与固定转换器相比，agent 加指南适合处理草案变化和需要判断的映射，但作者没有提供转换成本、失败率或维护成本的比较，「改指南更方便」仍是经验判断。对于长期稳定、要求每次转换行为一致的流程，固定转换器依然有价值。

权限则必须单独验收。导出文件不含访问规则，接收方不能靠它恢复原有的数据隔离。

能拿来做什么

• 如果你维护 Node 数据服务或 BI 指标配置，可以借鉴「生成、校验、修正」流程：让 AI 转换定义，再用确定性检查核对字段引用与指标结果，并把失败信息返回给 AI。
• 如果准备试用导出，可以把 agent 接到 https://demo.emondrian.com/emondrian/mcp，无需登录，先调用 get_ossie_guide，再要求导出 OnTime 并用 validate_ossie 修复错误。演示环境只读，不能用于新建 cube。
• 如果要测试导入，需要自行安装：原文给出的命令是 git clone https://github.com/eMondrian/emondrian-community 和 ./setup.sh；工具属于 MCP 模块，免费 30 天评估密钥足够试用。验收时除了总计，还应补查关键维度切片、复杂指标和访问规则。