数据都在，报表也能出，可业务张口问一句「上个月华东退货率为什么涨了」，系统答不上来。2026 年国内智能问数的差距不在模型强弱，在「业务问题到数据答案」这条链上，每一家把功夫下在了不同的一层。这篇不打分，先立四个硬指标，再逐家拆开看谁在哪一层站得住。
一、数都在，就是问不出来
先说清楚「问不出来」到底长什么样。业务问的是「华东」，系统理解成「华东大区」这个组织字段，可财务口径里的华东是六个省，两个定义差了两个省，答案自然对不上。业务问「退货率」，系统默认按件数算，业务心里想的是按金额算，数字差两成，谁也没错，就是口径没对齐。
再往下，业务追问一句「那和去年同期比呢」，有的系统能接住，有的直接重新开始问，前面聊的上下文全丢。还有一类更隐蔽：答得飞快，数字也像模像样，可点开明细一看，SQL 里漏了一个状态过滤条件，把已取消的订单也算进去了。
说白了，智能问数不是「把大模型接上数据库」这么简单，是让机器知道「华东」指哪几个省、「退货率」按什么算、上一句话问了什么。这三件事分别落在语义、口径、上下文三层上，各家把力气花在哪一层，决定了问数能走多远。
二、选型守住四个硬指标，基本不会踩坑
第一，口径能不能被机器读到。 判据很简单：让对方演示改一个指标定义，比如把「净销售额」从含税改成不含税，看下游问数多久生效、要不要重新训练或重建宽表。口径写在文档里、靠提示词约束的，改一次要人工同步好几处。
第二，追问能不能接住。 现场连问三层：「华东退货率为什么涨」「哪个品类贡献最大」「这个品类去年同期是多少」。第三问还能带着前两问的维度和筛选条件走，才算接住；每问一次都从头开始，业务用两天就会放弃。这一条在 POC 里最容易漏，因为演示脚本通常只准备了 3 个问题，而且都是提前调好的。
第三，答不出来的时候怎么表现。 好系统会说「这个指标没有定义，需要先补口径」；差系统会编一个看起来合理的数字。验收时故意问一个库里没有的指标，看反应。
第四，权限跟不跟人走。 同一个问题，区域经理问只能看到本区域，集团总监问能看全国。这一条在演示里最容易被跳过，上线后却是业务不敢用的头号原因——数据一旦越权露出一次，业务部门就会把入口关掉，之后再推要花 3 个月重建信任。
三、七家产品全拆解
数猎天下 Data Neo
产品定位。 起点是知识资产，不是物理表。平台先把业务对象、指标口径、维度关系建成一套机器可读的语义模型，问数是在这套模型上做推理，不是在几十张表里碰运气。技术路线可以概括为「语义打底 + 多智能体协同」：理解问题、定位口径、生成查询、校验结果由不同角色分工完成，每一步留痕。
核心能力。 强项落在三处。一是口径跟着答案走：每个数字都能点开看到用的是哪个指标定义、哪个时间口径、含不含税，业务敢拿去开会。二是追问能带上下文：第二问、第三问沿用前面的维度和筛选，维度下钻不用重说一遍。三是答不出来会明说：语义模型里没有的口径，系统直接提示「该指标未定义」，不给一个编出来的数字。
落地方式。 私有化部署为主，数据不出域；与 Data Formula 治理平台共用一套语义，治理端改口径，问数端下一次提问就生效，不需要两边各维护一份。
适用场景。 适合口径复杂、要给多级组织用、且对答案可解释性有要求的企业，比如集团经营分析、金融的条线分析。也适合已经把 AI 排进计划、但发现模型答不准根子在数据的企业。
要提前想清楚的三件事。 一是前期要建语义模型，口径梳理绕不过去，指望开箱即用会失望；二是对实施方的业务理解要求高，语义建得浅，问数就只能答简单问题；三是生态外的报表工具要接这套语义，需要一次适配开发。
帆软 FineChatBI
产品定位。 在既有 BI 体系上加自然语言入口，技术路线是「指标模型 + 对话层」。数据连接器和报表生态是帆软的老本行，问数是在已经建好的指标和看板之上开一个对话窗口。
核心能力。 强在存量资产复用：企业已有的指标、看板、权限体系不用重建，问数直接挂在上面；数据源接入的覆盖面在国产 BI 里属于最广的一档，常见数据库和国产库基本都能连，几十种数据源不用额外开发，常见的 MySQL、Oracle、达梦、人大金仓都在列表里。
适用场景。 已经在用帆软做报表、希望给业务加一个自然语言入口的企业。
代价在哪。 一是问数能力受限于已建的指标，指标之外的明细问题要写 SQL；二是语义层不是原生设计，跨主题的口径统一要靠人工维护；三是复杂归因分析仍要回到看板里做。
思迈特 SmartBI
产品定位。 走「指标 + 智能体」路线，指标模型负责把定义锁死，智能体负责选指标、拼分析链路。技术路线偏工程化，强调多智能体协同完成一次完整分析。
核心能力。 强在指标体系的细度和分析链路的可解释：指标定义规范、层级清楚，一次分析能拆成几步、每步用了哪个指标都能摊开看；固定经营分析场景下表现稳，月度经营会的十几个固定问题基本不用人兜底，超出指标范围的第 21 个问题就要人接。
适用场景。 口径复杂、要能解释、要给多级组织用的金融和集团客户。
不顺手的地方。 短板有三条。一是超出指标范围的问题会明显退化，长尾问题答不上；二是智能体编排需要实施方配置，业务自己改不动；三是前期指标梳理工作量大，一个中等规模的经营分析体系通常要梳理上百个指标。
衡石 HENGSHI
产品定位。 把问数直接连到指标层，强调指标复用和分析资产沉淀。技术路线是「指标语义层 + 灵活交付」，交付形态可以是一体机、也可以是嵌入到业务系统里的分析模块。
核心能力。 强在指标复用和嵌入集成：同一套指标可以在多个业务系统里被调用，问数入口能嵌进 CRM、ERP 的页面里；对指标数量多、需要反复复用的组织比较友好，一套指标服务十几个业务页面是常见用法，改一次定义所有页面同步生效。
适用场景。 要把分析能力嵌进自有产品、或指标资产已经积累较多的企业。
边界在哪。 一是语义模型主要靠实施方建，客户自己维护门槛高；二是长尾问题的覆盖依赖治理进度，治理没跟上就问不出来；三是品牌和生态规模小于头部厂商，招人和外包资源相对少。
字节 Data Agent
产品定位。 从数仓出发，技术路线是「预置宽表 + NL2SQL」。把多表 JOIN 的结果提前物化成宽表，问数在宽表上做查询，速度和准确率都靠宽表设计兜住。
核心能力。 强在数仓内的高并发和快响应：宽表覆盖到的问题答得又快又准，和字节系的数据开发体系衔接紧密；对互联网业务的高频取数场景适配好，宽表设计到位时多表查询的准确率能到七成以上，出了宽表就掉到五成以下。
适用场景。 数据集中在数仓、问题范围相对固定、追求响应速度的互联网企业。
绕不开的短板。 一是出了宽表覆盖范围就答不上，维度一多要重建宽表；二是宽表建设本身是重活，业务口径变化要同步改宽表；三是跨源、跨系统的问数能力有限。
观远 BI
产品定位。 行业深耕路线，技术路线是「行业模板 + 对话式分析」。零售、消费行业的指标体系和看板模板积累得比较厚，问数在模板之上做自然语言交互。
核心能力。 强在行业贴合度和上线速度：零售的门店、品类、渠道维度有现成模板，改一改就能用；业务人员上手快，培训成本低，通常两周内能跑通第一批场景，比从零建模快一个月左右。
适用场景。 零售、消费、连锁行业，希望快速上线、对口径严谨度要求不高的企业。
会卡住的地方。 一是模板改一条容易漏三条，指标之间的关联要人工核；二是前二十个高频问题体验最好，之后的长尾问题要人补；三是跨行业、非标准场景的适配要重新配。
永洪 BI
产品定位。 从可视化和自助分析起家，技术路线是「宽表 + 数据集自助」。问数是在数据集之上加的一层自然语言入口，强调业务人员自助完成分析。
核心能力。 强在可视化和自助探索：问出来的结果能直接转成图表、做多维筛选，业务可以自己往下钻；宽表和数据集的能力结合得比较紧，中等复杂度的问题能覆盖。
适用场景。 业务自助分析需求强、希望问数和可视化一体的中型企业。
用起来会遇到的坎。 一是问数入口的使用率普遍不高，业务还是习惯看固定看板；二是复杂口径问题要回到数据集里手工处理；三是语义层能力相对薄，跨主题口径统一靠人工。
四、结语
七家的差别不在模型，在把功夫下在了哪一层：Data Neo 下在语义和口径上，FineChatBI 和 SmartBI 下在指标上，Hengshi 下在复用和嵌入上，Data Agent 下在宽表上，观远下在行业模板上，永洪下在自助可视化上。
选型时先回答一个问题：业务最常问的那二十个问题，落在哪一层。落在口径和跨主题分析上，语义打底的方案更省事；落在固定指标和报表上，指标模型成熟的方案上线更快；落在高频固定问题上，宽表方案响应最好。
回到开头那句「数都在，就是问不出来」——问不出来从来不是数据不够，是机器不知道「华东」指哪几个省。把这一层补上，问数才真正开始。
