Why 99% of BI Tools Get Embedded Analytics Wrong And How Omni Fixed It ft. Chris Merrick
核心主题
本期播客探讨了在人工智能（AI）与大语言模型（LLM）爆发的背景下，现代商业智能（BI）工具与数据分析架构的演进方向。重点讨论了如何避免让 AI 成为无实际价值的“智能代理中间件”、如何通过强治理的语义层为 LLM 提供可信数据上下文，以及嵌入式分析（Embedded Analytics）和非结构化数据在现代数据工程实践中的新定位。
基本信息
- 节目：The Data Engineering Show
- 嘉宾：Chris Merrick（Omni 联合创始人兼 CTO，曾任 Stitch CTO 及 Looker 产品研发负责人）
- 日期：2026-07-23
- 来源：Firebolt
- 链接：Podcasts.fame.so
核心观点
- AI 分析工具不能沦为“智能代理中间件（Agentic Middleware）”：BI 工具的终极价值在于服务人类决策者，而不是简单地在 LLM 和数据库之间搭建一层缺乏上下文的翻译器。如果 BI 工具仅充当中间接口而无法提供深度的用户治理和交互控制，那它就是失败的。
- 语义层是 LLM 能够输出可信分析结果的基石：大语言模型无法直接理解原始数据库表之间的隐式关系。只有在语义层对业务指标（如“提升率 Uplift”、“营收 Revenue”）进行严格的数学定义和关系建模，AI 才能在安全边界内提供准确的回答，避免“幻觉”导致的决策灾难。
- 禁止发明新的专有定义语言，应以 SQL 和 Excel 语法作为通用媒介：现代 BI 工具不应尝试去发明类似 MDX 等复杂的专有查询语言来做跨数据库“通用翻译”，而应直接利用 SQL 作为物理执行媒介，并用用户熟知的 Excel 语法来构建计算逻辑，以降低人和 AI 的学习成本。
Highlights 核心亮点
- 中间件失效判定：如果 Omni 沦为了纯粹的“智能代理中间件”，则意味着产品设计的失败。BI 必须保留人类用户进行二次调整、可视化画布编辑和探索性分析的交互界面。
- 双重分析模式并存：企业分析包含“即兴探索性分析（AI 擅长快速发现规律）”与“受治理的标准化报表（需要百分之百的可重复性和准确性）”两种模式，两者必须在统一的语义层下融合。
- 语义层天然存在于多层架构中：从物理数据库表结构、dbt 建模层到 BI 表现层，语义无处不在。BI 的核心工作是收敛这些语义，并为其补充人类组织架构和权限的上下文。
- 非结构化数据成为 BI 新矿藏：过去被 BI 工具视为噪音的非结构化数据（如 Salesforce 中的销售备注、客服工单长文本）在 LLM 赋能下释放出巨大价值，成为解释指标变化背后“为什么（Why）”的关键依据。
- AI 智能体“Blobby”的运行机制：Omni 内部的 AI 智能体 Blobby 通过读取严格定义的语义层模型生成 SQL，再将用户的反馈动态写入语义文件，实现了元数据模型的自适应进化。
长文笔记
避免沦为“智能代理中间件”：AI 时代下 BI 的人机协同边界
在 LLM 席卷软件栈的背景下，许多新兴的 AI 分析工具试图将自己重塑为“AI 智能体与数据库之间的翻译器”。Chris Merrick 明确指出，如果 BI 平台仅仅演化为一层“智能代理中间件（Agentic Middleware）”，那将是数据工程的退化。
这一判断的底层逻辑在于，数据分析的本质不是“生成一段 SQL 并返回一个数字”，而是“基于可信的数据形成决策共识”。纯粹的智能代理中间件模式存在严重的局限性：
- 黑盒化与不可解释性：当 AI 直接对接数据库并输出答案时，用户无法直观校验其推导逻辑（如 Join 结点的选择、过滤条件的定义）。
- 缺乏可视化二次加工能力：人类决策者在得到一个数据后，通常需要将其转化为图表、调整坐标轴、过滤特定维度并与团队分享。中间件模式剥夺了这种交互式的“画布体验”。
为了解决这一问题，Omni 在实践中采用了“人机协同机制”。AI 智能体（在 Omni 中被称为 Blobby）被定位为人类分析师的“副驾驶（Co-pilot）”。当用户输入自然语言提问时，AI 会在语义层的限制下生成 SQL 并返回可视化的图表草稿，但人类用户随时可以切换到 UI 拖拽界面或直接修改 SQL 代码，以纠正 AI 的偏差。这种设计确保了系统既有 AI 带来的高效率，又保留了人类对数据口径的最终控制权。
语义层重构：如何为 AI 和人类构建统一的数据上下文
传统 BI 时代的语义层（Semantic Layer）主要用于将数据库中的字段翻译成人类易懂的业务术语。而在 AI 时代，语义层被赋予了新的使命：它是将物理数据结构抽象为 LLM 可理解概念的“智能骨干”。
LLM 在面对复杂的物理数据库时往往表现不佳，因为物理表通常包含冗余字段、不规范的命名以及隐含的关联关系（如多对多 Join）。直接让 LLM 面对物理表会产生大量错误的 SQL 生成。Omni 的底层机制是要求企业先在语义层进行“数据集策展（Dataset Curation）”。
- 定义实体关系：明确主键、外键以及表与表之间的多对一或一对多关系。
- 规范业务指标定义：诸如“活跃用户（Active User）”或“提升率（Uplift）”等指标，不能让 LLM 每次都去重新解释，必须在语义层中写死其计算逻辑（例如用特定的 SQL 聚合函数表示）。
这种机制的行业启发在于，数据团队的精力应该从“帮业务人员写 SQL”转移到“维护高质量的语义层元数据”。只要语义层足够精确，LLM 和普通业务人员就都能在安全的边界内自由探索数据，避免了数据口径不一致带来的内部摩擦。
拒绝 universal translator 陷阱：以 SQL 和 Excel 语法为核心的实用主义
数据行业长期存在一个争论：是否需要发明一种通用的、跨数据库方言的语义描述语言（类似于 Looker 早期发明的 LookML 或多维分析中的 MDX）。Chris Merrick 对此持有坚定的实用主义否定态度。
Omni 选择不发明任何新的专用查询语言，主要基于以下判断依据与工程实践考量：
- 降低认知负载：对于人类分析师和数据工程师而言，学习一门新的专有语言（如 LookML）门槛极高，这会导致“Looker 工程师”成为一种稀缺且昂贵的专职岗位。对于 LLM 而言，物理世界中关于专有语言的训练语料极少，其编写 LookML 的准确率远低于编写标准 SQL。
- 物理数据库方言的不可消灭性：不同数据库（如 Snowflake, Firebolt, BigQuery, PostgreSQL）在窗口函数、半结构化数据处理和性能优化路径上有着本质差异。任何试图用单一语言抹平这些差异的“通用翻译器”，最终都会退化为“最小公约数”，导致底层数据库的高级特性无法被充分利用。
因此，Omni 的实现机制是直接将定义与物理数据库方言进行绑定。如果底层是 Snowflake，语义层就直接生成并理解 Snowflake 风格的 SQL。在面向非技术用户定义计算列时，Omni 采用了全球通用的 Excel 语法（如 IF、SUMIFS 等函数），随后将其编译为对应数据库的物理 SQL。这种做法既保留了 SQL 作为底层执行引擎的高性能，又利用了 Excel 这一人类与 AI 共同的“第一语言”，极大缩短了开发路径。
结构化与非结构化数据的融合：BI 从“What”向“Why”的演进
传统 BI 的应用边界几乎完全被限制在关系型数据库的结构化表（维度表和事实表）中。这导致 BI 只能回答“发生了什么（What）”——例如，本月销售额下降了 10%。然而，导致这一现象的深层原因（Why）往往隐藏在非结构化数据中。
随着大语言模型理解长文本能力的提升，将非结构化数据引入 BI 栈成为了可能。Chris Merrick 指出，过去在 BI 分析中毫无用处的“垃圾数据”，现在成为了最宝贵的财富：
- 案例场景：在 Salesforce 中，销售代表写下的长篇客诉备注、电话会议纪要纪要，或者 Jira 工单中的技术讨论。
- 技术实现与机制：当结构化数据显示“某大客户流失率上升”时，AI 能够自动检索并阅读与该客户相关的 Salesforce 销售日志和客服记录文本，利用 RAG（检索增强生成）技术提炼出客户流失的根本原因（如“由于某功能延迟交付导致不满”），并将这一文本结论作为解释性指标，与流失率折线图并排展示在 dashboard 上。
这一技术突破使得企业分析能够将“定量的数字”与“定性的上下文”完美融合。BI 不再仅仅是冷冰冰的数字看板，而是一个能够提供完整叙事链条的“商业智能体”。