当AI分析师开始撒谎:Omni用1.5亿美元的语义层,解决企业数据信任危机
一、问题比答案更重要
2026年4月,一家叫Omni的公司宣布完成了1.2亿美元C轮融资,估值15亿美元。
这不是一个简单的融资新闻。
它指向了企业AI应用中一个正在爆发的核心矛盾:AI可以给你答案,但企业不敢信任那个答案。
想象一下这个场景。你是一家中型科技公司的CFO,你问公司的AI数据助手:”我们上季度的收入怎么样?”AI在几秒钟内给出了一个数字。
这个数字是对的吗?
如果AI把”收入”理解成了总销售额而不是净收入,如果它把某个尚未确认的合同也算进去了,如果它用的是去年第四季度而不是自然年第一季度……你怎么知道?
大多数企业的解决方案是:再去找数据分析师确认一遍。
这就是问题所在。你花了大钱买了AI,结果又多雇了一个人来验证AI。效率没有提升,信任危机反而加深了——因为”我知道AI可能错,所以我得查”这件事本身,就是对AI价值的根本性否定。
Omni的联合创始人兼CEO Colin Zima在公司官方博客中直接点出了这个现象的本质:
“AI并不天然理解你的业务。每家公司都有自己独特的’收入’、’客户’、’上季度’的定义。这些定义背后的逻辑通常是散落在人们脑子里的部落知识和四处分散的文档。没有这些特定的背景信息,LLM就会充满自信地进行猜测。分析工作依赖可靠性,所以猜测行不通。”
“充满自信地猜测”(confidently guess)——这六个字精确描述了企业AI分析的核心风险。
二、AI分析的”置信度黑洞”
大型语言模型(LLM)有一个已知的特性:它们在大多数情况下不说”我不确定”,它们会给出一个听起来很合理的答案。在个人助手场景里,这种特性有时是优点——”大致正确”比”拒绝回答”更有用。
但在企业数据分析场景里,这是灾难。
一个错误的销售预测,一个误算的客户留存率,一个张冠李戴的运营成本——每一个都可能影响数百万乃至数十亿美元的商业决策。财务报表的误差会触发审计。错误的增长数字会误导投资人。
Omni在C轮融资的官方新闻稿中明确指出了这一困境:”随着企业竞相将AI连接到数据,许多尝试都失败了。大多数AI工具在没有理解业务背景的情况下生成查询。它们忽略权限,返回相关方无法验证和信任的数字。AI支出与AI准确性之间的差距,已成为企业中最严重的问题之一。”
这个”差距”在Omni自身的成长数据中得到了印证:ARR在2025年增长了4倍,而这个增长不是发生在AI使用量下降的时候,恰恰相反,正是AI使用量最激进增长的一年。这意味着,AI用得越多,对可信数据基础设施的需求就越大,而不是越小。
ICONIQ Growth合伙人Matt Jacobson在投资声明中直接说出了他们的判断:
“数据领域的障碍已经从获取转向了理解。每个人都能提问,但如果没有共享的业务背景层,答案可能会崩溃。我们认为真正的问题从来不是可访问性——而是信任。数据分析是AI Agent最重要的工作负载之一,Omni正在构建那个被治理的数据层,帮助这些Agent做对。我们相信他们将成为数据分析类别的领先平台。”
这段话里有一个值得反复咀嚼的洞察:数据障碍从获取转向了理解。
在没有AI的年代,企业数据的主要问题是”拿不到”——数据锁在各个系统里,分析师需要写复杂SQL才能提取出来。BI(商业智能)工具解决了这个问题,它们让更多人能看到和使用数据。
AI更进一步,让任何人都能直接用自然语言”问”数据。技术获取门槛几乎消失了。
但一个新问题出现了:你能问,但你不知道得到的答案对不对。旧的障碍是访问权限,新的障碍是理解深度和信任建立。
三、语义层:不是AI的”护栏”,是AI的”母语词典”
Omni的解决方案,用一个词概括,叫做语义层(Semantic Layer)。
这个概念在BI领域已有二十多年历史——它是一个中间层,把复杂的数据库结构翻译成业务人员能理解的语言。但Omni的核心主张是:在AI时代,语义层的价值不是弱化了,而是变得比任何时候都更加关键,并且需要被重新设计。
原因在于一个根本的语言学问题。
当你问AI”上季度收入如何”,AI实际上需要解决三个层次的问题:
第一层:技术翻译。”上季度”对应数据库里的哪个时间字段?”收入”对应哪张表的哪个字段?这已经很复杂了——一家典型的中大型企业可能有数百张数据表,字段命名几乎从不标准化,同一个概念可能在不同系统里有6个不同的技术名称。
第二层:业务语义。”收入”在你们公司的定义是什么?是账单金额还是已确认收入(recognized revenue)?是含税还是不含税(net of tax)?是按合同签署时间记账(booking)还是按服务交付时间(delivery)?是否包含退款?每家公司的答案都不同,而且有时连同一家公司的不同部门之间的答案也不同。
第三层:权限上下文。这个提问的人有权限看全公司的数据吗?还是只能看他负责的地区或产品线?收入数据里有没有涉及保密条款的大客户需要脱敏?财务报告期前的数据是否应该显示?
一个没有语义层的AI,面对这三层问题,只能猜。而且,因为LLM的训练方式,它会用一种自信的、似乎合理的方式猜——这让错误更难被发现。
Omni构建的语义层,从技术层面来看,是一个”受治理的上下文图谱(governed context graph)”,存储了:
- 指标定义(Metric Definitions):公司层面统一的业务术语定义,例如”净收入 = 已确认订单金额 - 退款 - 折扣,不含税,按服务交付时间记账”
- 业务逻辑(Business Logic):计算规则和实体关系,例如”客户留存率 = 首次付费12个月后仍在付费的用户比例,按首次付费日期的月份队列计算”
- 权限控制(Permissions):细粒度的数据访问规则,例如”区域销售总监只能查询所在地区的数据,高级管理层可看全国数据,财务报告数据在季报发布前15天锁定”
- Git版本控制(Version Control):所有定义的修改历史完整可追溯,例如”2026年Q1将收入确认时点从合同签署改为服务交付,影响历史对比数据”
这个语义层不只是给Omni自己的分析界面用的——Omni将其开放为API和MCP服务器,使所有连接进来的AI工具都能共享同一套上下文。当用户在Claude、ChatGPT、Cursor或VS Code里问数据相关的问题,这些外部AI调用的也是同一套语义层定义和权限控制。
用Zima的话说:”您为构建出色的商业智能而建立的,正是构建出色的人工智能所需要的(What you build for great business intelligence is exactly what AI needs)。”
这是一个优雅的价值主张:为AI时代重新设计的BI,不是让AI替代BI,而是让BI成为AI的可信基础设施。
四、为什么这个赛道在2026年爆发了
Omni成立于2022年3月,距ChatGPT公开发布还有8个月。那时候他们甚至没意识到自己在做的是”AI时代的数据基础设施”——他们只是想做一个比Looker更好用、更灵活的BI工具。
Zima在C轮博客中回忆说:
“四年前,我们出发去修复数据分析。2022年3月,在ChatGPT公开发布前8个月,我们还没有意识到我们在为一个Agent原生的世界建立基础。”
时间线提供了一个重要的线索:Omni的语义层架构,是在AI浪潮到来之前就出于BI本身的需求而设计的。这意味着它不是为了迎合AI热潮而仓促拼凑的产品,而是一个经过多年验证的架构,恰好在AI时代找到了更大的价值。
2025年是转折年。企业开始给员工大规模配备AI助手,各类”数据Copilot”产品铺天盖地。数据分析是AI最自然的应用场景——”问数据”这件事,比”写代码”对普通业务人员更直接、更高频、需求更刚性。
问题随之暴露。”text-to-SQL”作为数据分析AI的主要实现路径,在规模化应用中不断暴露出根本性缺陷。Omni的工程师在2026年4月撰写了一篇技术博客《为什么text-to-SQL会失败》,直接指出:
“LLM可以写SQL,但它不知道哪个表才是正确的那个,不知道哪个字段是你们公司定义的’收入’,不知道JOIN这两张表会不会导致重复计数。它只是在猜,而且猜得非常自信。”
这不只是Omni一家公司的判断。数据领域研究机构Eckerson Group的分析师Wayne Eckerson在2025年指出,文本到SQL转换的失败率在企业生产环境中高达40%-60%,主要原因是模型无法理解企业特定的业务语义和数据模型。同期,多家企业数据团队(包括Airbnb、Uber的工程博客)公开记录了类似的挑战——通用LLM在理解公司特定数据schema时反复出错,最终不得不引入”元数据注释层”来辅助AI理解。
企业开始意识到,AI给出的数据分析结果,依然需要传统数据分析师验证后才敢使用。这不只是效率的双重损耗,更是对AI投资回报率(ROI)的根本性质疑。
Omni的ARR在这一年增长了4倍。
不是因为Omni忽然变好了。而是因为问题变得足够大、足够痛,让企业愿意为解决方案付钱了。
五、已经在生产中验证的规模化案例
Omni在官方新闻稿中提供了3个可量化的生产案例,让抽象的价值主张变得具体可信:
BambooHR(人力资源SaaS):将AI分析产品Elite Analytics在前4个月内推送给超过3万名终端用户,现在已经服务超过10万名用户。这10万人都在直接使用AI驱动的数据查询,没有经过传统数据分析师作为中间验证层。对于一家中型SaaS公司,10万用户的规模意味着这已经不是内部试验,而是核心产品特性。
Cribl(数据管道工具公司):在3个月内完成向Omni的全面迁移,在全公司范围内实现了自助AI分析。”3个月全面迁移”是一个值得注意的数字——这说明Omni的部署和培训成本并没有高到让企业望而却步。
Guitar Center(乐器零售连锁):将多个分散的BI工具整合进Omni,构建了一个统一的、上下文丰富的数据基础,使公司所有部门都能使用AI获取分析结果。零售业的数据结构通常特别复杂(SKU数量巨大、多渠道库存、门店与电商并行),这个案例说明Omni能处理真实世界的数据复杂性。
Checkr(背景调查服务公司)的Staff Analytics Engineer Sarah Fischbach提供了一个关于语义层网络效应的重要描述:
“Omni的突出之处在于它让我们所有的知识都变得结构化和持久化,使AI更智能。随着越来越多的人和越来越多的AI工具依赖它,它变得更有价值。在Omni受治理的上下文图谱中构建,让我们能够捕捉到复利增长的机构知识。”
这里描述的是一个正反馈循环,也是Omni护城河的核心逻辑:
- 越多人使用Omni → 越多业务上下文被编码进语义层
- 语义层越丰富 → AI的答案越准确
- 答案越准确 → 越多人信任并使用AI
- 使用AI越多 → 越多反馈继续优化语义层
这是数据网络效应的一种新形式——不是”用户越多数据越多”(传统数据网络效应),而是”使用越多业务上下文越深”(语义网络效应)。对于已经在Omni上积累了大量业务定义的企业,切换成本会随时间推移持续增加。
六、竞争格局与护城河:旧战场的新战争
Omni并不是第一家做语义层的公司。在BI领域,这是一个已经存在几十年的核心课题:
- Looker(被Google收购):LookML是一个定义型DSL,让数据团队定义指标和维度,2025年已有AI Studio和Gemini集成,但核心架构是面向中心化存储和人类仪表板消费设计的
- dbt:Semantic Layer + MetricFlow允许在数据转换流程中定义业务指标,对开发者友好,但在2026年它仍是一个更偏向数据工程管道的工具,而非面向业务用户的AI查询入口
- ThoughtSpot:AI搜索分析,有自己的关键词到数据的映射层,在查询层做了不少AI工作,但架构假设数据存储的中心化
- Tableau、Power BI:各自有语义层实现,但在API可编程性和AI Agent调用的原生支持上,仍处于追赶阶段
Omni的核心差异化主张是:这些传统工具的设计出发点是”人类通过GUI消费分析结果”——即便有AI插件,底层架构也没有为”AI Agent作为主要数据消费者”而重新优化。具体差距在于:当Claude或ChatGPT通过API调用查询企业数据时,它需要的不只是一个SQL接口,还需要一个能告诉它”在这家公司,这些词是什么意思”的上下文系统,而这个上下文系统需要与AI Agent的调用方式(API/MCP/工具调用)原生集成,而不是通过人类操作的GUI中转。
Zima在博客中指出了具体的架构区别:
“过去,那个基础(指语义层)赢得了跨越仪表盘、电子表格、SQL和点击式工作流的信任。今天,它驱动着我们客户赖以帮助数千人自助获取答案的AI Agent。”
从集成策略看,Omni的商业逻辑是”成为所有AI工具的数据大脑”,而不是”替代现有的BI工具”。Omni直接支持dbt定义导入(把已有的指标定义复用进来),同时通过MCP服务器和API,让Claude、ChatGPT、Cursor这些外部AI工具能把Omni当作”可信的数据查询端点”调用。
从护城河的形成机制来看,Omni押注的是制度性锁定(institutional lock-in),而非技术锁定:
一家企业在Omni上花了6个月时间,把”收入”的5种不同计算口径全部编码进语义层,建立了200条指标定义,配置了50个部门的权限矩阵,还把历史上所有的定义变更全部记录在Git版本控制里。
这些资产,不是从Omni迁移到另一个平台的技术问题,而是重新教育整个数据团队重新建立所有业务共识的组织问题。
切换成本不只是数据迁移,而是知识重建。这是一种比技术专利更难被复制的护城河。
七、局限性与三个值得追问的问题
任何严肃的分析都不能只讲美好的故事。
问题1:语义层的维护成本是隐性风险
建一个初始的语义层不难。难的是持续维护它。
业务定义在变化,数据库schema在变化,产品线在调整,公司收购新业务……一个落后于业务现实的语义层,带给AI的不是可信,而是一种更危险的”错误的可信”——AI很自信地给了一个基于过时定义的错误答案。
Zima承认了这一点:”我们建立Omni的方式是把上下文当作一个随着人们使用而变得越来越聪明的活系统。”但这个”随着使用变聪明”的前提,是有足够知识丰富的员工持续输入正确的业务上下文——这对于缺乏专职数据工程团队的中小企业是一个真实的挑战。
如果企业买了Omni,但没有人认真维护语义层,信任保证也就名存实亡。这是一个执行层面的风险,产品本身解决不了。
问题2:”单一真理”假设与组织政治的冲突
Omni的价值主张建立在”一个地方定义所有指标”的前提上。但在大型组织里,不同部门往往有合理理由维护不同的指标定义——销售团队的”收入”确实可能与财务团队的”收入”有合理差异(前者强调pipeline,后者强调GAAP合规),二者并非其中一个”错了”。
强制统一到单一定义,可能引发组织内部的权威性争议:谁来定义”官方”版本?财务部门?数据团队?C-suite?”谁拥有真理”这个问题,是一个技术工具掩盖不了的组织政治问题。
问题3:语义层能确保语义正确,但无法确保推理正确
语义层保证了AI用了正确的指标定义和正确的权限控制。但这只是”查询端的正确”,不是”分析端的正确”。
如果AI正确地查出了”收入”数据,但在分析趋势时把季节性波动错误归因为产品原因;如果AI正确地查出了”客户留存率”,但在比较时混淆了不同队列的计算基准——这类推理错误,语义层捕捉不了。
信任的边界 ≠ 推理的正确性。这个限制需要用户清楚地理解,而不是被”有了语义层AI就可信了”的简化说法掩盖。
八、一个更大的问题:谁来为AI时代的企业数据立法
让我们把视角从Omni这一家公司拉高,看一个更大的结构性问题。
AI Agent正在快速侵入企业工作流的每一个角落。它们写代码、回邮件、制定计划、分析数据。其中,数据分析是被渗透得最深、商业价值最高的一个领域——因为数据直接连接着商业决策。
当AI Agent处理企业数据的时候,它们需要回答一套哲学问题:这个数字是什么意思?我有权限看这个数据吗?这个结果和上次的结果为什么不同?
在这套问题没有被系统性地回答之前,企业要么不敢用AI分析数据,要么用了之后还要派人验证,要么冒险用了但承担着数据误判的风险。这三种选项,哪一个都不是AI承诺的生产力革命。
Omni押注的答案是:语义层将成为企业AI堆栈的治理宪法——它定义了AI能看什么、怎么理解、如何使用。
更重要的是,这个”宪法”一旦被写入,就有很强的路径依赖效应:
第一,深度耦合:语义层里编码的是企业的业务语言,而不是通用的技术接口。每一条指标定义、每一个权限规则,都是企业知识的结晶。这不是可以被通用化替换的东西。
第二,复利效应:随着越来越多的AI工具、越来越多的员工查询通过这个语义层,它能观察到哪些定义被频繁使用、哪些查询经常出错、哪些权限规则被经常申请豁免——这些信号反过来帮助企业持续优化和完善业务上下文的定义。
第三,组织记忆:传统企业的业务知识是分散的,存在于各个部门各个人员的脑子里。语义层提供了一个将这种”部落知识”(tribal knowledge)结构化、持久化的机制——让组织记忆不再随人员流动而流失。
这种”组织记忆基础设施”的价值,在AI时代被急剧放大了:当AI Agent代表企业做决策的时候,它们需要调取的是整个组织的知识积累,而不只是某一个员工的个人经验。
从这个角度看,Omni争夺的不只是BI工具市场,也不只是AI基础设施市场。它在争夺的,是企业AI时代的”知识宪法”地位——谁来定义企业数字真相的标准,谁就在企业AI堆栈里拥有了最具粘性的位置。
ICONIQ出手1.2亿美元,押注的正是这个判断。
九、结语:数据信任是AI落地的最后一公里
让我们回到开头那位CFO的问题。
她问:”我们上季度的收入怎么样?”
有了经过良好维护的语义层,AI的回答变了:它不再猜测”收入”是什么意思,而是查询语义层里被公司正式定义的指标;它不再无视权限,而是以提问者的身份级别执行查询;它展示推理过程,注明数据来源和计算口径,标出与上一季度比较的基准和注意事项。
这个答案,CFO不需要找分析师再验证一遍。
这才是企业真正想要的AI:不只是快,还要可信。可信,才是AI在企业场景下真正的价值密度所在。
Omni的1.2亿美元C轮,押注的正是这个判断:在AI大规模侵入企业工作流的时代,数据信任基础设施将成为比AI模型本身更稀缺、更有价值的资产。因为AI模型可以被替换,但企业花了数年时间构建的语义层——里面有几百个指标定义、几十条业务逻辑、几千条权限规则——不是一天能复制走的。
这不是一个BI工具的融资故事。这是关于谁来为AI时代的企业数据立法——谁来定义”真相”——的一场控制权之争。
而这场争夺,才刚刚开始。
参考资料
- Omni官方博客:四年回顾与Series C公告(”Four years of Omni: Announcing Omni’s Series C at a $1.5B Valuation”)
- 来源:Omni Analytics 官方博客
- 日期:2026-04-23
- URL:https://omni.co/blog/omni-series-c-funding
- Omni Series C新闻稿:以15亿美元估值完成1.2亿美元融资,构建企业AI分析平台
- 来源:Omni Analytics 官方新闻稿
- 日期:2026-04-23
- URL:https://omni.co/blog/press-release-omni-series-c-funding
- 为什么text-to-SQL会失败(”Why text-to-SQL fails”)
- 来源:Omni Analytics 工程博客
- 日期:2026-04-08
- URL:https://omni.co/blog/why-text-to-sql-fails
- 为什么AI需要语义模型(”Why AI needs a semantic model”)
- 来源:Omni Analytics 官方博客
- 日期:2026年(持续更新)
- URL:https://omni.co/blog/why-ai-needs-a-semantic-model
- Omni推出Slack Agent(”Introducing the Omni Slack Agent”)
- 来源:Omni Analytics 官方博客
- 日期:2026-04-22
- URL:https://omni.co/blog/introducing-the-omni-slack-agent
- Omni Modeling Agent发布公告(”Announcing Omni’s Modeling Agent”)
- 来源:Omni Analytics 官方博客
- 日期:2026-04-09
- URL:https://omni.co/blog/announcing-omnis-modeling-agent