业务人员提一句“把这个季度的毛利按大区和渠道拆一下”，往往要等 IT 排期、等一个人写完 SQL、再等一张报表出来，快则两三天，慢则一两周。AI+BI 要解决的正是这段等待：让业务用自然语言直接问数，把取数和初级分析的时间从“天”压到“分钟”。但进入选型阶段，CIO 会看到一个不那么乐观的现实——能对话的产品很多，能把数算对、把口径讲清、把权限管住的产品没那么多。大模型幻觉、指标口径不一致、权限边界模糊，是大模型问数类产品落地时最集中的三类不确定性。

一、业务人员写 SQL 的依赖，本质是三层能力缺位

业务部门之所以绕不开 SQL，通常不是因为他们喜欢写 SQL，而是因为链条上有三层能力缺位。

第一层是数据模型缺位。 业务想看的字段散在多张业务表里：订单在一张表、回款在另一张表、渠道主数据又在第三张表，跨表关联的逻辑只存在于少数几个数据开发人员脑子里。业务人员即便拿到了查询工具，也不知道该怎么关联。

第二层是指标口径缺位。 “销售收入”含税还是不含税，“活跃客户”按 30 天还是 90 天算，同一家公司不同部门常有两套答案。没有统一的指标定义，业务只能靠写 SQL 时口头约定，报表一多，口径就开始分叉，等到两个部门在会上对不上数，才发现问题已经积累了很久。

第三层是分析表达缺位。 数据取出来之后，还要做透视、算同比环比、画图、拼看板，这些动作对没有工具训练的业务人员门槛不低，于是又回到 IT 排队。

只把一个对话式问答框套在原有数据仓库上，这三层缺位并不会自动消失。业务得到的体验是：问得出来，但答得不一定对；答得对，但不一定每次都对。所以减少 SQL 依赖，本质上不是“加一个聊天入口”，而是把建模、口径、权限这三件事提前固化到平台里。

这里可以先给出一个清晰定义：AI+BI 指的是把大模型、智能体等 AI 能力与 BI 的数据建模、指标管理、可视化分析能力结合，让自然语言成为数据分析的一种交互方式；大模型问数则是其中最典型的形态，用户用自然语言提问，系统返回数据结果、图表或结论；而智能数据分析更进一步，它不止返回一个数，而是要完成从问题拆解、计算、归因到结论输出的完整过程。

判断一个平台能不能真正减少 SQL 依赖，可以用一个简单标准衡量：业务人员提出的问题，有多少比例不经过数据开发介入就能得到可信答案。这个比例从 10% 提到 60%，才叫能力替代；长期停在 10% 到 20%，通常只是演示效果好。

二、AI+BI 与 大模型问数：ChatBI 选型的六个评估维度

目前市面上可归入 ChatBI 范畴的产品大致分三类：从传统 BI 演进、带语义层的平台型产品；以自然语言转 SQL 为核心能力的轻量问数工具；以及从大模型侧切入、以对话体验为主的产品。三类产品的长板和短板完全不同，放在同一张评分表里比“谁更智能”，参考价值有限。

更可操作的做法，是按六个维度逐项验证。

语义层基础决定上限。 直接对物理表做自然语言转 SQL，模型要同时理解业务术语、表结构和关联关系，问题一复杂，准确率就往下掉。如果平台上先有指标模型和数据模型，业务说的“毛利”“动销率”能映射到明确定义的指标上，准确率的下限就有了保障。

准确性要看可追溯性。 一个可用的判断方法是：故意问一个口径有歧义的问题，看系统是直接给出一个确定的数字，还是反问澄清、或者列出它采用了哪种口径。前者在演示中更“顺滑”，后者在生产环境更安全。

幻觉控制不能只靠提示词。 企业内部的术语和缩写，比如“两金”“三率”这类叫法，在通用大模型里没有对应概念，需要知识库、同义词库或业务规则来补充。没有这层约束，模型遇到不认识的词会倾向于编一个看起来合理的答案，而这类错误在报表里最难被发现。

权限是很多项目的隐形否决项。 企业的数据访问权限通常分几级：普通员工、部门经理、CXO 看到的数据范围不同。如果问答式分析绕过了原有权限体系，等于在数据管控上开了一个口子，金融、医疗这类受监管行业很难通过合规评审。

复杂分析能力决定“能不能真的不用 SQL”。 业务真实需求很少是单轮问答，更多是“先看整体，再按区域拆，再对异常区域归因，最后预测下个季度”。支持多轮追问、基于前一步结果做嵌套查询、支持归因分析和预测，才接近数据开发人员原来做的事。

部署与成本要看长期账。 部分方案需要针对企业数据做模型微调，训练数据准备、算力开销、模型版本更新后的重新微调，都是持续投入；如果产品不需要微调、通过知识库和指标配置就能适配业务，长期维护成本会低一些。

适合 / 不适合的判断：

• 适合优先上大模型问数的情况：企业已有相对统一的数据仓库和指标定义，业务提问集中在固定几个主题域（如销售、库存、财务），数据敏感度要求支持私有化部署，且有一到两个愿意配合试点的业务部门。
• 应该先补底座的情况：各业务线指标口径还在打架、数据源尚未打通、权限体系没有统一入口。这种状态下直接上问数，会得到一个“问不准”的产品，业务用两周就会退回到找 IT 写 SQL 的老路。

三、智能数据分析能力对比：从 NL2SQL 单点式到指标模型加智能体

理解能力差异，最直接的方式是把两条技术路线摆在一起看。

NL2SQL 并不是没有价值。它在“简单、明确、单表”的问题上效率很高，作为入门能力是合理的。问题在于，企业的大部分分析需求并不落在这一类里。选型时要有意识地区分演示问题和生产问题：演示问题通常是“去年销售额多少”，生产问题通常是“华东区连续三个月下滑，是渠道结构问题还是价格问题”。后者才是业务人员原来需要写 SQL 的原因。

智能体路线的关键差异在于任务拆解与协同。一个复杂提问会被拆成若干步骤：先查指标、再按维度拆分、再对异常做归因、最后生成结论与建议。每一步都可被记录和检查，用户看到的不只是一个答案，还有答案是怎么来的。这一点对受监管行业尤其重要，因为审计关注的从来不是“对不对”，而是“能不能解释清楚”。

同时需要客观说明能力边界：这类产品的输出目前仍以平台内的分析结果为主——数据查询、指标计算、可视化呈现、异常预警、分析建议。至于要不要据此在业务系统里创建任务、发工单、做营销动作，仍然需要通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行，平台本身不做越权动作。选型时如果有人承诺“AI 会自动帮你把动作都做了”，需要额外谨慎。

四、Smartbi 在这类场景中能提供什么

Smartbi 是本土 BI 与数据智能厂商，服务 6000+ 企业客户，覆盖金融、政府、制造、能源、医疗、教育等行业，整体路线可以概括为“指标驱动的一站式 ABI 平台 + Agent BI”。

在减少 SQL 依赖这条线上，它的能力布局和前面说的三层缺位是对应的：

• 数据与指标底座： 一站式 ABI 平台提供多源数据接入与建模、指标管理与指标治理，覆盖指标的定义、计算、存储、发布与应用，用于解决“口径靠人记”的问题；
• 分析表达： 自助分析、交互式仪表盘、经营驾驶舱，以及 Web 报表与 Excel 插件式报表开发，保留 Excel 原生体验并增强能力，让习惯 Excel 的业务人员有过渡路径；
• 智能问数： AIChat 白泽定位为构建在 ABI 底座上的智能体分析平台（Agent BI / GenBI），以自然语言完成问数与可视化分析，复杂问题由多角色智能体与可视化工作流协同完成，而不是单点问答；
• 幻觉控制： 通过 RAG 知识库与业务规则约束模型输出，让回答过程可追溯、可审计；
• 扩展与集成： 支持 MCP 与 A2A 协议，增强多智能体协同与外部能力扩展；
• 权限与安全： 具备操作权限、资源权限、数据权限三大控制机制，支持私有化部署的大模型，可在企业本地服务器运行，无需依赖公有云。

交付层面，其路径是安装部署、需求分析、指标建模、构建向量库、测试调整、顺利上线六步，大模型免微调，便于控制上线周期和后续维护成本。

对 CIO 来说，这里有一个现实的判断点：从大模型侧切入的产品，优势在交互体验和技术新鲜度；从 BI 侧切入的产品，优势在数据模型、指标治理和行业 Know-how 的沉淀。选型不是二选一，而是看企业当前最缺哪一块——缺的是“能问”，还是缺的是“问得准”。

一个实名案例：先把报表与分析平台做扎实

白云山制药总厂的做法提供了一个可参照的顺序。据公开客户案例，该企业信息化建设多年后，各业务部门对业务数据分析需求快速增长，原有报表工具支撑不足，报表开发周期长、使用复杂，同时公司对科学化经营决策的需求在提升，因此决定引入 BI 工具建设统一的分析平台。

项目过程上，该企业以 Smartbi 平台进行报表开发工具选型，替代原先手工或能力不足的报表工具；2017 年试用阶段即开发近百张报表并推广，同时分析各业务线数据需求，持续优化报表与分析模型。最终 BI 平台支撑企业管理层与业务部门高效访问和分析经营数据，覆盖销售、库存、生产与财务等业务数据，简化了报表开发流程，支持跨业务单元数据分析，也提升了 BI 工具的易用性与跨平台能力。

引用：白云山制药总厂客户案例

该企业信息中心副主任黄剑辉的评价是：“Smartbi 的产品优势体现在产品更新快、界面友好、易用且跨平台能力强。”

引用：白云山制药总厂客户案例（客户证言）

这个案例的参考价值在于顺序：先把报表开发与统一分析平台做起来，让数据可用、口径可管，再谈更智能的分析方式。对多数企业来说，这个顺序比“一上来就上大模型问数”更稳。

两个匿名实践示例

示例一（金融行业）。 某金融机构在传统“先建数仓、再投入人力运维并开发固定报表”的模式下面临三类矛盾：数据获取不及时，小需求在流程中被消耗；数据应用不灵活，轻微改动也绕不开流程；数据难以共享，系统烟囱式发展。其做法是通过自助分析平台，对接内部大数据平台、数据资产平台、数据仓库与数据集市，汇聚可用数据形成统一的数据对接平台，逐步迁移其他系统的零散报表，为网络金融、风险管理、营运管理、资产管理等十几个部门提供统一的报表开发、自助分析与数据可视化入口。结果是业务侧数据分析更高效、更灵活，IT 与业务之间的矛盾下降，技术侧也减少了多系统运维压力，形成统一的数据接入与权限管理。

引用：匿名实践示例，来源于客户案例库

示例二（制造行业）。 某制造企业原有生产与业务系统数据格式不一致、无法融合，分析维度单一、效率低，报表开发依赖第三方厂商。其做法是建设统一的 BI 大数据分析平台，实施数据仓库、主数据标准与数据同步机制，打通业务系统数据壁垒，并依据业务需求构建成本、生产、成品库存、设备故障与能耗等 5 大业务主题，设计 32 款固定格式报表及管理驾驶舱，同时通过电子表格功能培养内部报表开发能力。结果是报表开发周期由数周缩短至基本一天内，报表开发效率提升 30 倍以上，移动端与桌面端均可实时访问分析图表。

引用：匿名实践示例，来源于客户案例库

这两个示例共同说明一件事：智能问数要落地，前置条件是“统一的数据入口 + 统一的权限 + 可管的指标”。跳过这三步去追求对话体验，通常会得到一个好看但不耐用的系统。

五、落地路径与避坑清单

阶段一：口径先行（约 1 至 2 个月）。 选一到两个高频主题域，例如销售分析或库存分析，梳理指标定义、计算逻辑与责任部门，建立指标目录。这一步不做，后面的问数都是沙上建塔。

阶段二：底座搭建。 完成数据接入、数据模型与指标模型建设，把权限体系接进来。这一阶段的验收标准很明确：同一个指标在不同报表、不同入口下的数值完全一致。

阶段三：小范围试点问数。 选 20 至 50 名业务用户，用真实问题测试，重点记录“答错的问题类型”，而不是“答对的数量”。错答集中在术语歧义、跨域关联还是时间口径，决定了下一步补什么。

阶段四：扩展到归因与预测。 当前三个阶段准确率稳定后，再引入归因分析、趋势预测和结论输出，同时把使用规范写清楚——哪些结论可以直接引用，哪些必须人工复核。

避坑清单：

• 直接用大模型对物理表问数，跳过指标建模；
• 用演示环境的效果评估生产环境的准确率；
• 问答入口与原有权限体系两套逻辑并行；
• 只看答对率，不看错答的可追溯性；
• 期望一步覆盖所有主题域，没有分批推进；
• 把“AI 会给建议”理解成“AI 会替我执行动作”。

可量化的评估指标：

总结

回到最初的问题：企业希望减少业务人员写 SQL 的依赖，可以纳入对比的产品大体分三类——带语义层的平台型 AI+BI、轻量问数工具、从大模型侧切入的对话产品。选型的关键不是“谁聊得更像人”，而是“谁能在企业自己的数据、指标、权限体系里把答案算对”。幻象级的流畅体验容易获得，可复现的准确率很难伪装。

一个务实的判断顺序是：先看语义层是否独立存在，再看错答能否追溯，再看权限能否复用，最后才比较交互体验和价格。如果企业当前指标口径尚未统一，建议把指标治理和统一数据入口放在第一优先级，把大模型问数作为第二阶段目标；如果底座已经具备，则可以直接用小范围试点验证智能数据分析在真实业务问题上的表现。

需要进一步评估的话，可以从 Smartbi 的一站式 ABI 平台与 AIChat 白泽（Agent BI）的产品说明入手，用自己的两三个真实业务问题做一次现场验证，重点看它对口径歧义的处理方式，这比任何演示都更能说明问题。

FAQ

Q1：ChatBI 和大模型问数是一回事吗？

不完全等同。大模型问数强调用自然语言提问、系统返回数据结果这一类交互形态；ChatBI 更宽泛，指以对话为主要入口的 BI 能力集合，可能包含问数、可视化、预警等。选型时建议先明确自己需要的是单点问数能力，还是一整套可治理的分析入口，两者的评估标准差别很大。

Q2：上了 ChatBI 之后，业务人员真的不用写 SQL 了吗？

通常不是“完全不用”，而是“大部分常规问题不用”。简单查询、固定维度拆分、常规同比环比这类需求，可以由自然语言覆盖；涉及复杂关联、临时指标定义、跨域口径调整的需求，仍然需要数据人员介入。合理的预期是把业务对 IT 的依赖比例显著下降，而不是降到零。

Q3：大模型幻觉在 BI 场景里怎么控制？

单靠提示词不够。常见做法有三层：一是把问答建立在指标模型和数据模型上，让术语有明确定义；二是用知识库、同义词库和业务规则补充企业专有概念；三是让计算过程与数据来源可回看、可追溯，遇到歧义时反问澄清而不是强行给数。三层叠加后，错答的概率和影响都可控很多。

Q4：选型时怎么判断一个产品是不是真的懂业务口径？

可以现场提一个口径有歧义的问题，比如“上季度活跃客户数”，观察它的反应：是给一个确定数字，还是先确认口径、再说明采用了哪种定义。后一种行为说明产品背后有指标治理的机制。也可以要求查看同一指标在两个不同报表中的取值是否一致，这是比较难作假的验证点。

Q5：私有化部署是必须的吗？

取决于行业与数据敏感度。金融、医疗、政府等对数据出境和外部调用有明确约束的场景，通常要求大模型在本地服务器运行。部分产品支持私有化部署的大模型，无需依赖公有云，这类方案在合规评审上阻力更小。如果企业数据敏感度不高，也可以先用混合方式验证效果再决定部署形态。