企业取数这件事，在过去三十年里经历了三次大的变化。每一次变化的背后，都是同一个驱动力：业务部门对数据的需要越来越频繁、越来越复杂，而旧的工具和流程已经撑不住了。

这篇文章就来梳理这条演进脉络——每一代工具解决了什么问题，又留下了什么新问题。最后，我们也会聊聊当前最热的两种AI问数路径——ChatBI和工程化系统解决方案——各自的优势和局限。

一、Excel时代：灵活，但管不住

在BI工具普及之前，企业取数几乎全靠Excel。一张表从ERP导出来，财务、运营、供应链各自在上面加工、关联、计算，最后拼成一份能用的分析报告。

这个阶段的优势是灵活。任何一个会用Excel的人，都能对数据做加工处理。但问题也出在灵活上——当多张表需要关联，当多个部门各自维护自己的计算口径，Excel的局限性就暴露出来了。

公开案例中，海南橡胶曾因多系统口径不一致，导致存货盘亏约1.7万吨，连续六年年报失真。某大型企业在2022年审计中被发现，仅因成本表中产品编码规则变更、VLOOKUP引用范围未覆盖新编码，导致报表利润虚增数百万元。这些事故的根因不是操作失误，而是“靠人工在多张表之间做关联”这件事本身的脆弱性。

Excel能管好一张表，但管不了多张表之间的复杂关联和跨部门口径的统一。

二、BI时代：统一了看板，但没解决“临时要数”

2000年代以后，BI工具开始在企业中普及。Tableau、Power BI等平台把数据从Excel里抽出来，放到统一的数据模型里，通过可视化看板呈现关键指标。

这个阶段的进步是显而易见的：口径统一了，看板标准化了，管理者打开仪表盘就能看到核心经营数据。但一个新问题也随之而来——BI看板只能回答预先设计好的问题。

业务人员的问题常常在看板之外。运营经理想知道“上周华东区退货率最高的三个产品是什么，对比上个月同期变化”，这个问题在看板上找不到，只能走工单流程——提交需求、IT排期、人工取数、返回结果。观远数据针对87家年营收10亿以上企业数据团队的调研显示，近70%的数据团队每周有一半以上的工时被消耗在响应临时取数、调整报表、解释口径这类工作上。业务部门平均每个数据需求需要等待3.7个工作日才能获得响应。

BI统一了看板，但看板之外的需求依然要排队。企业需要的不是更多的看板，而是让业务人员自己能“问”数据。

三、AI智能问数第一阶段：通用大模型——Demo很美，生产很骨感

2023年以后，大语言模型的能力让行业看到了新的可能：如果AI能理解自然语言，自动生成SQL查询数据库，那业务人员就可以跳过IT排期，直接“问”数据了。

这个方向逻辑上完全成立，Demo也跑得很漂亮。单表查询、标准问题、干净数据，准确率接近满分。但进入生产环境后，问题开始暴露。

车间主任问“昨天A线跑得怎么样”，系统返回空——大模型不知道“跑得怎么样”在这家工厂的语境里对应的是良品率、日产量和设备利用率三个指标的组合。财务部问“上季度华东区新品毛利率”，结果和手工报表差了几个百分点——大模型不知道这家公司财务部和运营部对“毛利率”用的是两套不同的计算口径。

Gartner在2026年4月的调研给出了宏观印证：仅有28%的AI用例能完全成功并达到预期ROI，超过三分之一的失败项目根因指向数据质量差或数据可用性有限。60%的AI项目预计在2026年底前因缺乏AI就绪数据而被放弃。

通用大模型的根本局限在于：它只是个概率系统，它不知道你们公司内部的业务口径，它不会留下审计记录。对个人用户来说，AI偶尔出错可能是个段子；对企业来说，财务对账、库存盘点这类零容错场景里，“大概率对”等于“不可用”。

四、AI智能问数第二阶段：工程化系统——从“能问”到“敢信”

走到这一步，行业开始意识到一个关键问题：企业级AI问数不是模型问题，是工程问题。

通用大模型能写SQL，但回答不了“为什么是这个结果”。企业需要的不是更聪明的大脑，而是一套能管住口径、能自我纠错、能追溯审计的工程化系统。这套系统的核心，通常包括三个组件：语义层、多智能体协作、全链路可追溯。但在展开这三个组件之前，有必要先厘清一个概念——同样是“工程化”，目前行业里主要有两种路径：ChatBI和深度工程化系统。两者在定位、能力和适用场景上有显著差异。

ChatBI vs 工程化系统：两种路径，两种取舍

ChatBI，顾名思义，是在传统BI平台之上叠加一层自然语言交互能力。用户在对话框里输入问题，系统将其翻译为SQL，查询已有的数据模型，返回可视化结果。这条路径的核心优势在于轻量和易集成——它依托企业已有的BI资产（数据模型、看板、权限体系），实施周期短，对现有工作流的冲击小。目前主流BI厂商如Tableau、Power BI、帆软等均已推出或正在整合类似功能。

但ChatBI的局限也同样清晰。Tableau在其官方博客中曾指出，基本的自然语言查询（NLQ）已经日益商品化，但89%的数据和分析领导者报告其AI输出存在不准确或误导性问题，根本原因在于缺乏稳固的语义层。ChatBI的查询准确率高度依赖底层数据模型的完善程度——如果企业的BI模型已经覆盖了绝大多数业务场景、指标口径严格统一，ChatBI可以跑得很顺；但如果底层数据模型本身存在口径不一致、关联关系缺失等问题，ChatBI就会频繁出错。更重要的是，ChatBI通常不具备多表关联的智能优化能力、业务术语的动态感知能力，以及面向审计的完整追溯能力。

工程化系统解决方案则走了另一条路。它不是“在现有BI上加一个对话框”，而是从底层重构了AI访问企业数据的完整链路。这条路的核心逻辑是：先建立一套语义层，把企业内部所有的业务术语、指标口径、表间关联关系做结构化建模，让AI不再“猜”业务逻辑；再通过多智能体协作机制，让多个AI互相校验查询结果，把概率输出转化为确定性推理；最后，每一次查询都留下完整的审计日志，做到可追溯、可复现。

这条路线的优势在于，它解决了ChatBI难以覆盖的深层问题：多表关联的准确率断崖、行业“黑话”的理解、跨部门口径的动态对齐，以及合规审计的刚性要求。但它的代价是前期需要一定的工程投入——语义层的梳理、术语映射的建立、与企业数据治理体系的对接，都不是零成本的事情。

两者的对比可以这样总结：ChatBI适合“数据基础好、查询场景相对简单”的企业，它能快速上线，让看板之外的高频简单查询实现自助化；工程化系统适合“数据环境复杂、查询涉及多表关联和行业术语、对准确率和可追溯性有刚性要求”的企业，它提供的是从底层语义到顶层审计的完整保障。两者不是替代关系，而是适用不同阶段和场景的两种选择。

有了这个区分，我们再来看工程化系统的三个核心组件，它们各自的角色和价值会更容易理解。

语义层：让AI听懂企业内部的“黑话”

语义层是把企业内部的口语化表达、行业术语、跨部门各有定义的概念，与数据库中的字段、表、计算逻辑之间建立确定性的映射关系。不再靠模型去猜，而是靠事先约定好的“翻译手册”。

劳埃德银行的实践数据是这方面的经典案例：他们仅在数据库Schema中添加同义词、缩写和已验证的示例查询，准确率就从80%提升至86.1%。BlazesQL在2026年NL2SQL技术指南中给出了一个准确的判断：“一个普通模型配上高度富化的语义层，会轻易地超越一个在真空中运行的顶尖模型。”

多智能体协作：从一次生成到多轮验证

单靠一个大模型生成SQL，出了错只能等用户发现。多智能体协作的思路是把任务拆开，让几个各有分工的智能体一起工作，生成的和检查的互相校验。

2026年的前沿研究已经在落地这个方向。EvoAgent-SQL提出了进化多智能体框架，把用户反馈和反思性自适应机制融进了NL2SQL流程。SQLFixAgent在BIRD基准上实现了超过3%的执行准确率提升。

全链路可追溯：让每次查询经得起审计

Gartner将“数字溯源”列为2026年十大战略技术趋势。可追溯意味着每一次查询的原始SQL、语义版本和执行时间戳都有完整记录；业务术语到数据库字段的映射过程有迹可循；数据从源头到计算结果的路径可以完整追溯。

德勤发布的《2026全球企业AI状况报告》覆盖了3235名信息技术与业务领导者，结论值得关注：仅有21%的企业建立了成熟的AI智能体治理框架，约80%的受访组织缺乏实时监控与审核追踪机制。当合规审查要求出示AI查询的完整审计记录时，可追溯性就不再是加分项，而是及格线。

五、一个简单的阶段对比

把上述四个阶段的关键特征放在一起，演进的脉络一目了然：

六、演变背后的主线：从“人找数”到“人数对话”

回顾这三十年，企业取数方式的变化有一条清晰的主线。

Excel时代是人找数。所有的数据加工、关联、计算全部靠人工完成。BI时代是系统推数。关键指标通过看板自动推送，减少了人工重复劳动。通用大模型时代是人问数。业务人员可以用自然语言主动查询数据。工程化系统时代是人数对话。AI不只是被动回答，而是理解业务语境、自我校验、承担审计责任。

每一步变化，都是在缩短“业务需求”和“数据结果”之间的距离。Excel把这距离控制在个人手里，但跨部门协作时断裂；BI把看板内的距离压到最短，但看板外的需求反而被排期拉长；通用大模型把对话距离压到最短，但答案的可靠性反而成了新距离；工程化系统做的事，就是保证“距离最短”的同时“结果最可靠”。

我们的团队在部署中反复验证过一个结论：企业级AI问数，真正的分水岭不是“谁家的对话更流畅”，而是“谁先完成了从裸调大模型到工程化系统的跨越”。语义层让AI听懂你们的业务语言，多智能体协作让AI能自我纠错，全链路可追溯让AI经得起审计——这三个组件，构成了企业级AI问数的工程化底座。