智能问数是什么？AI问数如何让业务人员自助取数

业务部门提一个取数需求，IT 排期三到五天；报表拿到了，口径又和别的部门对不上；想自己查，却不会写 SQL。这是很多企业数据团队每天都在经历的循环。智能问数要解决的正是这条链路——把“提需求、等排期、拿报表”压缩成一句自然语言提问。它到底能问到什么程度、企业该怎么落地、选型时该看什么，下面分几个层面说清楚。

一、智能问数是什么：把取数请求从“工单”变成“对话”

一句话定义：智能问数是一种以自然语言为入口的数据分析方式——用户用日常语言提出业务问题，系统自动完成语义理解、指标识别、查询计算，直接返回数字、图表或结论，并支持连续追问。行业里也把它称作 AI 问数、ChatBI 或对话式分析，本质上是自助分析能力的一种新形态。

它和“给报表加个聊天框”的区别：真正的问数能力，答案的准确性不来自大模型的“猜”，而来自背后的指标模型。用户问“华东区上月新单价值多少”，系统需要先判断“新单价值”对应哪个已定义的指标、“华东区”是哪一层组织维度、“上月”按自然月还是财务月，再去取数计算。

所以判断一个平台能不能用，先看它答一个稍微绕一点的问题时，是给了个数字，还是给了数字、口径和计算过程。

能跑起来需要三个前提：

1. 指标已被定义清楚——有名称、口径、计算逻辑、责任部门；
2. 数据已经建模——维度、事实、粒度、权限边界明确；
3. 业务语义被补全——行业术语、同义词、指标与机构、渠道、产品的关联关系。

缺了这三样，问数就容易退化成“把自然语言翻译成 SQL”，遇到行业黑话或模糊表达就答不准。

表 1：三种取数方式的对比

从 ChatBI 到 Agent BI 的演进：早期 ChatBI 主要解决“问答式查数”，一个问题一个答案；再往前的固定报表连追问都做不到。随着智能体（Agent）技术引入，平台开始具备任务拆解能力——先查数，再判断异常，再拆解影响因素，最后给出结论和建议。

这一步跨越的意义在于，业务人员不必自己规划分析路径。例如问“这个月保费为什么没达标”，系统按机构、渠道、产品、时间逐层下钻，指出主要拖累项，而不是只返回一个数字。相应地，对企业的指标治理水平要求也更高：分析越深，口径错误的放大效应越大。

二、智能问数能问到什么程度：能力边界与典型场景

业务负责人最常问的一句话是：“这东西到底能问到什么程度？”诚实的答案是分层的：有些问题今天就能问准，有些需要先做治理，有些在可预见的时间内仍然要靠人。

表 2：问题类型与支持程度

第一层：能稳定问准的，是“有明确口径的指标类问题”。 单指标查询、时间对比、多维拆解、排名、占比、异常波动提示，这些场景对准确率要求最高，也最依赖指标模型。一旦指标定义清晰，问数的效果往往比人手写 SQL 更稳定。

第二层：需要条件才成立的，是“分析与推理类问题”。 归因分析、趋势预测、经营解读，需要平台具备多步推理能力，也需要企业预先完成维度建模。这类问题的答案不应是“结论式的一句话说死”，而应能展开看：影响了多少、由哪几个因子构成、下一步建议看哪几个维度。

第三层：目前不该指望的，是“跨越系统边界的动作”。 例如让系统直接在业务系统里创建一条任务、修改一条记录，这超出了数据分析平台的职责范围。成熟的做法是：平台负责分析、预警、可视化与建议输出，再通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行。

适合优先上线的四类场景：

• 高频、重复的固定取数，如日报、周报、KPI 查询；
• 指标数量可控、口径相对稳定的经营分析主题，如收入、成本、渠道、队伍；
• 管理层在 PC 和移动端随时看数、追问；
• 数据分析师临时取数需求的削峰。

暂时不适合的四类情况：

• 指标口径本身还在业务部门之间打架；
• 数据分散在多个系统、没有统一出口；
• 期望“上线即替代所有报表开发”；
• 缺少专人维护指标字典和语义库。

三、为什么取数长期依赖 IT：三重壁垒与一个可参考的落地样本

在多数企业里，取数依赖 IT 并不是因为 IT 不愿意做，而是三件事叠加在一起：需求侧的临时性、供给侧的排期制、以及中间层的口径分歧。

壁垒一：取数难。 固定报表之外的查询都要走需求流程，业务等不起，IT 也疲于应付零散工单。

壁垒二：口径乱。 同一个指标在不同机构、不同报表里算法不一致，业务不敢用，最后又回头找 IT 核对。

壁垒三：落地难。 即便引入了 AI 能力，业务侧对它的预期往往过高，第一期效果不达预期就失去信任。

保险行业的“中英知行”项目，是一个把这三重壁垒拆开处理的样本。

案例：中英人寿“中英知行”智能问数智能体

中英人寿是中粮资本与英杰华集团合资的寿险公司，长期位居合资寿险公司第一梯队。项目启动前，业务侧面临的问题很典型：非固化报表查询需排队找 IT，周期长达数天甚至一周；VNB、APE 这类核心指标在不同机构统计口径不一致，容易误导决策；同时 GPU 资源有限，业务人员对 AI 能力存在过高预期。

项目采用“大模型 + 指标模型 + 知识库”的三层架构推进：

1. 把 109 个复杂经营指标拆解为不可再分的原子指标，统一口径与计算逻辑；
2. 构建行业术语知识字典、同义词库，以及“机构—渠道—产品—指标”的关联知识图谱，提升自然语言解析的语义匹配能力；
3. 落地五大功能：对话式分析、趋势预警、归因分析、自动洞察报告、语音交互；
4. 分阶段实施：一期聚焦 53 个核心指标试点，二期扩展至 109 个并向全公司推广。

上线后的量化结果集中在四个维度：

• 数据收集与整理时间缩短约 90%；
• 移动端日活提升 3 倍；
• 核心指标问答准确率稳定在 90% 以上；
• 项目入选 IDC《中国金融行业智能体最佳实践案例分析之保险与资管篇》。

引用：中英人寿“中英知行”智能问数智能体案例资料

这个样本值得注意的地方，不是模型规模，而是顺序：先做指标拆解与语义补全，再做问答入口。如果反过来，把自然语言接口直接接在未治理的数据上，准确率不可能稳定在 90% 这个量级。另一个细节是分期策略——先用 53 个核心指标跑通闭环，让业务建立信任，再扩面，这比一次性上线上百个指标更可控。

自助分析对 IT 工单的削峰作用，在银行业也有可对照的实践。平安银行基于统一平台构建决策支持体系，覆盖核心经营指标体系、可视化管理驾驶舱、风险监控预警和自助分析模块，项目结果显示业务需求工单减少约 70%，风险事件下降约 30%。

引用：平安银行数据决策支持平台案例资料

两个案例指向同一个结论：业务侧自助能力提升之后，减少的不只是等待时间，还有 IT 的重复劳动。这也是很多企业把“降低临时取数工单量”作为项目一级验收指标的原因。

四、AI 问数怎么落地：五步路径、选型清单与避坑

落地顺序比工具选型更影响成败。以下是可复用的五步路径，适合中大型企业的第一期建设。

步骤 1：先定指标，不要先选模型。 挑一个业务价值高、口径相对稳定的主题域，通常是经营分析或财务分析，把该主题下的指标清单拉出来，明确名称、口径、计算逻辑和负责人。

步骤 2：建好数据模型与指标模型。 数据模型解决“数据从哪来、按什么粒度组织”，指标模型解决“这个数字怎么算、在哪些维度上可用”。两者共同构成问数可信的地基。

步骤 3：补业务语义层。 把行业术语、简称、同义词、指标与组织/渠道/产品的关联关系整理成知识库。业务人员不会按标准指标名提问，这一步决定了“听得懂”的比例。

步骤 4：把权限放在前面，不要事后补。 从总公司到分支机构，不同角色能看到的数据范围不同。权限设计要在试点前完成，否则一期上线就要面对数据越权的风险。

步骤 5：小范围试点，用准确率验收，再扩面。 建议以高频问题集为单位做验收，例如整理 50 到 100 个真实业务问题，逐条比对答案，把准确率、追问成功率作为上线门槛。

表 3：AI 问数平台选型清单

五条避坑建议：

1. 只看演示惊艳度，不看口径。 演示用的往往是干净数据，真实环境的口径分歧才是难点。
2. 一次性上线几百个指标。 覆盖面看起来漂亮，但每个指标的准确率都无法验证，反而拖慢推广。
3. 忽略权限，事后补。 权限模型和指标模型一样，属于地基，不能作为二期工程。
4. 把大模型当成万能答案。 没有数据模型和指标模型支撑，语言理解能力再强也答不准业务问题。
5. 用“答得像不像”验收，而不是“答得对不对”。 表达流畅但数字错误，比答不出来更危险。

建议跟踪的六个验收指标：问答准确率、高频问题覆盖率、平均取数时长、IT 临时取数工单量、月活与周活用户数、追问率（反映用户是否真的在做分析而非一次性查数）。

以某区域银行为例（匿名实践示例）：该行把经营分析主题下的核心指标先做统一治理，再开放对话式查询给分支机构的业务负责人，第一阶段只覆盖几十个指标。上线后，业务人员查询日常经营数据的等待时间明显缩短，IT 侧的临时取数需求随之下降——这类渐进式路径，比“全行一次性开放”更稳妥。

五、Smartbi 在这个场景中的位置：ABI 底座 + Agent BI

Smartbi 是本土 BI 与数据智能厂商，服务 6000+ 企业客户，覆盖金融、政府、制造、能源、医疗、教育等行业。其总体路线是“指标驱动的一站式 ABI 平台 + Agent BI”，这条路线与前面讲的落地顺序是吻合的：先有底座，再谈智能。

底座层：一站式 ABI 平台。 包括多源数据接入与建模、指标管理与指标治理（覆盖指标的定义、计算、存储、发布、应用）、自助分析与交互式仪表盘、经营驾驶舱、企业级报表（Web 报表与 Excel 插件式报表开发，保留 Excel 原生体验），以及权限、安全、审计、集群等企业级能力。这一层决定了问数答得准不准、能不能被审计。

智能层：Smartbi AIChat 白泽（Agent BI）。 定位是构建在 ABI 底座上的智能体分析平台，能力可以按四个方向理解：

1. 智能问数与可视化分析——自然语言查数、生成图表、上下文追问，支持同比、环比、累计、期初期末等复杂计算，答案基于指标模型和数据模型而非直接生成 SQL；
2. 多角色智能体与可视化工作流——强调智能体与工作流主线，而不是单一的问答窗口，可定制财报助手、KPI 预警助手、经营分析助手等；
3. RAG 知识库与业务规则——用企业自己的术语、口径、规则约束模型输出，减少幻觉，做到可追溯、可审计；
4. MCP 与 A2A 协议支持——增强多智能体协同与外部生态扩展能力。

在功能场景上，白泽覆盖智能问数、归因分析（多维归因结合预建模与多步推理）、趋势预测、专家模式（处理模糊或复杂问题，自动规划执行计划并生成深度报告）、智能报告与自定义分析助手。目标用户覆盖四类角色：业务人员、管理者与决策者、数据分析师、IT 与数据治理人员。

需要明确的边界：白泽目前在平台内完成分析、预警、可视化与建议输出；它不会自动在 CRM、工单、营销系统中创建任务或执行动作。与外部系统的关系是：通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行。

差异价值可以这样理解：相对大模型厂商，Smartbi 的优势在 BI 能力与行业 Know-how 的沉淀，比如指标模型、数据模型、并行计算与权限体系；相对传统 BI 厂商，优势在 AI 技术的融合方式，比如以智能体和工作流为主线组织分析任务，而不只是给报表加一个输入框。

“看数”和“问数”是互补关系。以省级农信行的移动经营驾驶舱项目为例：该行整合业务系统数据、完成标准化加工，在 4 个月内建成统一的移动经营驾驶舱，实现全行经营数据实时展示与分析，管理者可通过移动设备快速掌握各项经营指标。

引用：省级农信行移动经营驾驶舱案例资料

驾驶舱解决的是“该看的指标一眼看到”，问数解决的是“看到异常之后继续往下问”。两者配合，才形成从监控到洞察的完整路径。

六、总结：先治理口径，再谈智能

回到最初的问题：智能问数能让业务人员自助取数吗？可以，但有条件。条件是指标先被定义清楚、数据先被统一建模、业务语义先被补全、权限先被设计好。做不到这四点，问数只是一个看起来聪明的入口；做到了，它确实能把取数从“排队等排期”变成“随时开口问”。

给业务负责人的三条建议：

1. 从指标清单开始，不要从工具演示开始。 先问自己：我们最常被问的 50 个指标，口径统一了吗？
2. 把准确率写进验收标准。 用真实问题集测，而不是用演示脚本测。
3. 按阶段推进。 先做核心指标试点，跑通“提问—取数—追问—归因”的闭环，再扩面。

如果你的企业正处在这个阶段，可以先了解 Smartbi AIChat 白泽（Agent BI）的产品能力，以及 ChatBI 场景的具体实现方式，再结合自身的指标治理成熟度判断启动时机。

• 产品落地页：https://www.smartbi.com.cn/aichat_agentbi
• 细分场景页：https://www.smartbi.com.cn/chatbi

FAQ

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

不完全等同。ChatBI 通常指“用对话方式查数”的产品形态，重点在问答交互；而现在企业更关注的是在此之上能否做归因、预测和报告生成。可以理解为：ChatBI 解决“问得到”，Agent BI 进一步解决“问得深、答得准、可追溯”。选型时要分清厂商提供的是哪一种。

Q2：业务人员不会写 SQL，问出来的数据可信吗？

可信度取决于底层指标是否统一。如果平台基于指标模型回答，用户问的每个指标都对应已定义的口径和计算逻辑，答案就与报表一致；如果是把自然语言直接翻译成 SQL 再查库，遇到模糊表达就容易出错。判断方法很简单：让它把计算口径讲出来。

Q3：上线一套问数能力大概需要多久？

取决于指标治理的基础。指标口径清晰、数据已集中建模的企业，第一期试点可以在数周到两三个月内跑通；如果指标还在各部门各算一套，前期梳理往往占掉大部分时间。中英人寿的做法是分期上线，一期 53 个核心指标试点，二期扩展到 109 个，这个节奏值得参考。

Q4：准确率 90% 算合格吗？怎么验证？

对核心经营指标而言，90% 以上是可用门槛，但关键在验证方式：用真实高频问题集逐条比对，而不是抽样看几个演示问题。同时要区分错误类型——数字算错和口径理解偏差是两种问题，前者要靠模型和权限约束，后者要靠知识库和语义补全。

Q5：能让系统看到异常后自动去处理吗？

数据分析平台擅长的是发现、解释和建议，不擅长也不应该直接改动业务系统。合理的做法是平台输出预警与分析结论，通过工作流与企业现有系统集成，方便后续由业务或 IT 触发与执行。把人放在决策闭环里，反而更容易被业务接受。