企业官网建设流程全解析

1. 2026 年智能问数选型，为什么先聊可追溯性再聊准确率

如果你今年也在帮业务团队选智能问数工具，大概率会经历这样一个过程：厂商发来的 Demo 视频一个比一个惊艳，口头回答准确率“95%以上”，口径问题问三遍给你三种答案。等到真正接上你库里的 300 张表和十几套指标口径，情况立刻不一样了。这种差异的根源，不在于各家大模型谁的智商更高，而在于技术路线和产品定位的底子不同。

我今年前后对比了五家有代表性的厂商——帆软 FineBI、阿里云 Quick BI、数势科技、Kyligence（跬智）以及开源路线的 Chat2DB。这五家恰好代表了目前智能问数领域五种截然不同的技术路线：传统 BI 厂商的对话式补全、云厂商全家桶式闭环、新锐厂商的 Agent 原生路线、语义层优先的指标平台路线，以及开发者工具式的极简路线。

先说结论：到了 2026 年，智能问数这个赛道的比拼重点已经从“能不能把自然语言转成 SQL”，变成了“转出来的 SQL 业务敢不敢信、出了问题能不能查、口径变了会不会跟着变”。准确率当然重要，但准确率是个很虚的词。厂商公布的准确率大多来自自建测试集，测试集里的表和指标口径全是它自己定义的。真正决定落地效果的，是可追溯性——也就是用户从输入问题到看到图表，中间每一步是否都留有可审计、可回查、可解释的证据链。

我给可追溯性下了个判断标准，一共四层：第一层是生成过程可追溯，回答背后用的表和 SQL 字段完整可见；第二层是指标口径可追溯，回答里涉及的“GMV”“留存率”这类指标，能关联到定义版本和血缘来源；第三层是执行过程可追溯，SQL 是在什么查询引擎上跑的、数据截至什么时间、过滤条件是否和问题意图一致；第四层是交互行为可追溯，谁在什么时候问了什么问题、系统给了什么回答，整个过程能导出来。

这四层逐一看下来，五家厂商的差异会非常明显。有些厂商在第四层做得很好，因为你问他“上季度华东区销售额”和“上季度华东区销售额是多少”，他能把一次指标解释原封不动回给你；有些厂商连第一层都做不到，只给一个最终结论和图表，过程完全黑盒。我用这套标准做了几轮实测，也踩了挺多坑，下面按技术路线、能力层级、可追溯性三个维度逐一展开。

2. 五家厂商的技术路线分布：语义层、BI 绑定、Agent 化

在深入对比之前，先梳理清楚这五家厂商各自走的技术路线。智能问数本质上是一个自然语言处理到数据分析执行的翻译问题，但翻译的“中间环节”每家处理方式完全不同。根据中间环节的差异，我把它们分成了四派：传统 BI 补全派、云平台全家桶派、Agent 原生派和语义层优先派。

2.1 帆软 FineBI：传统 BI 老将的对话式补全

帆软的智能问数能力是长在 FineBI 这个成熟的 BI 平台里的。技术路线非常务实：先建立好数据集、指标、权限体系，然后在上面加一层自然语言交互层。用户问问题，系统先做意图识别，再把它映射到 FineBI 里已配置好的数据集和字段上，最后生成查询并在 BI 看板中呈现。

这条路线有个天然优势——权限和语义模型是现成的。帆软沉淀了多年的数据权限控制体系，意味着“某主管只能看自己部门的数据”这类权限约束，在问数环节天然生效。很多纯生成式路线的产品在这一块非常头疼，因为 SQL 一旦由模型直接生成，权限过滤逻辑很容易被绕过去。帆软的思路是“不重新造轮子”，把已有的 BI 资产复用起来，这条路线对老帆软用户极其友好。

2.2 阿里云 Quick BI：云厂商的“全家桶”闭环

阿里云做智能问数，本质上是把数据资产从生产到消费的全链路都装在自家云环境里。数据存在 MaxCompute 或 Hologres，元数据在 DataWorks 里管理，提问入口嵌在 Quick BI 里，底层模型是通义千问系列。当用户提问时，系统会从 DataWorks 拉取元数据、从 Quick BI 拉取数据集信息、再结合通义千问的 NL2SQL 能力生成查询。

这条路线的最大优势是链路完整度高。数据权限、数据血缘、数据质量规则这些基础能力，阿里的数据中台体系早就搭好了，智能问数只是在这个成熟底座上长出的一个新交互层。缺点也很明显：如果你没有用阿里云的数仓体系，或者 Mix 了他们家的全家桶，落地时会发现很多能力其实是绑定在云产品里的，单独抽出来用效果大打折扣。

2.3 数势科技：Agent 原生的新派路线

数势科技是这五家里最激进的一家，产品和架构完全围绕 LLM Agent 来设计。它不是给已有 BI 加一个对话入口，而是把整个分析过程拆解成一个 Agent 任务流：解析用户意图、检索指标定义、选择数据源、生成 SQL、执行验证、生成图表、归因解释。每个环节都由不同模块协同，中间还会和用户的反馈进行多轮交互。

这种路线的好处是上限高，特别是在复杂分析问题上有明显优势。传统 BI 的对话化往往只能回答“基于已建好的数据集”的问题，而 Agent 原生路线可以动态决策用哪几张表、做怎么样的关联。但这也带来了新的挑战：Agent 灵活度越高，路径越不可控。它可能这次用了三张表关联，下次用了另外两张表，结果看起来都对，但背后逻辑完全不同。所以数势科技现在非常强调指标层的建设，通过指标语义平台来约束 Agent 的分析路径，保证同口径问题的结果一致。

2.4 Kyligence：语义层优先，多维模型兜底

Kyligence 的路线和它做 OLAP 的基因一脉相承。它的核心观点是：与其让模型自由发挥生成 SQL，不如先把指标口径和数据关系在语义层里定义好，再让大模型做“自然语言到语义查询”的翻译。翻译完之后，由语义层负责把查询转换成 OLAP 引擎能执行的多维查询语句，而不是直接对着裸表跑数。

这个路线的可追溯性天然很强。因为用户的问题最终被映射到语义层的指标和维度上，指标对应的口径是明确且受控的。Kyligence 还允许管理员在语义层里限制哪些维度、哪些度量可以被查询，从入口处就规避了“模型生成出不存在的字段”这类幻觉问题。代价是前期需要投入一定的语义建模成本，这部分如果不做扎实，后续问数体验会受到很大限制。

2.5 Chat2DB：开发者工具式的极简派

Chat2DB 走的是另一条路线——把智能问数做成开发者的数据工具。它像一个增强版的数据库客户端，用户连上 MySQL、PostgreSQL 等数据源，输入自然语言问题，模型直接生成 SQL 并在客户端里执行返回结果。整个交互非常轻，不需要建语义层、不需要配看板、不需要指标系统。

这也许是五家里门槛最低的方案，尤其适合研发团队自己用。但门槛低也意味着能力边界非常清晰——它没有指标口径管理，没有数据权限体系，也没有统一的数据血缘。同一个问题，如果底层表结构发生了变化，模型可能生成出和业务定义不一致的结果，而且没有任何机制去参照这种偏差。它更像一个“智能取数加速器”，而不是业务级的问数平台。

3. 能力层级拆解：从规则对齐到多 Agent 自治，五家各在哪一层

要说清楚智能问数的能力水平，光说“支不支持多轮对话”太粗了。我参考语言模型 agent 领域的成熟分层思路，结合实际评测场景，把问数能力拆成了六个层级，从低到高依次是：

• L1 单表单指标查询：能处理“本月销售额是多少”这类最简单的单表聚合问题，SQL 结构固定，几乎不涉及多表关联。
• L2 多表关联与条件过滤：能处理带时间范围、业务分组、多表 JOIN 的查询，具备基本条件理解能力。
• L3 多轮口径修正：用户在第一轮回答基础上追加约束，比如“不要包含退单”“换成美元计价”，系统能够准确改造上一轮查询而不是推倒重来。
• L4 指标归因与解释：不仅能给出数字，还能解释数字背后的构成逻辑，比如“为什么华东区销售额下降”能拆出渠道变化、价格变化、退款变化等多个因素。
• L5 自动洞察与建议：主动从数据中挖掘异常点和趋势变化，在用户提问之前就给出业务提示。
• L6 多 Agent 自治编排：系统能把一个复杂问题拆分成多个子任务，调用不同 Agent（取数、建模、图表、归因）协同完成，并能自我验证结果。

3.1 六层能力模型的核心差异在哪里

我用一个真实问题来说明这六层的差异。假设用户的提问是：“帮我分析一下最近三个月华东大区各个品类的销售额变化，重点是美妆品类的同比情况。”

L1 水平的系统只能启动“最近三个月”和“华东大区”这两个条件，在单表上算销售额，大概率输出一张简单的趋势图。L2 能进一步拆出“各个品类”这个分组维度，做成品类的对比。但要做到“重点是美妆品类的同比情况”，就需要 L3 及以上的能力——系统要意识到这是一个需要追加分析步骤的问题，而不是一个简单的分组查询。

到了 L4 才算是质变。系统不仅输出美妆品类的同比数据，还会进一步拆解这个同比变化是由新客贡献还是老客复购驱动的，是平均客单价变了还是订单量变了。这需要系统能够自主地把一个大问题分解成“客单价分析”“订单结构分析”“新老客分群”等多个子查询，再合并结果。L5 在这个基础上更进一步，系统会在回答中主动标注“值得注意的是，虽然整体销售额平稳，但美妆品类的环比下跌了 7%，主因是 9 月中下旬新客转化率骤降”。

L6 则是在真实企业环境中最难实现也最理想化的状态。它意味着系统能够像一个初级分析师那样，面对一个模糊问题，比如“看一下我们最近生意做得怎么样”，自主决定从 GMV、订单量、客单价、复购率、渠道分布等多个角度切入，自动完成取数、建模、图表生成和结论撰写，整个过程是一个多人协同的 Agent 团队在工作。

3.2 五家厂商的实际能力分布

基于公开资料和我在实际场景中的体验，用这六个层级来对照五家厂商，大致可以给出这样的能力分布：

需要注意，这里的“实测稳定层级”和“峰值能力”是两个概念。峰值能力往往是厂商在宣传视频中最亮眼的表现，但实际业务环境下，能不能保持住这个峰值，非常考验系统的工程兜底能力。我见过某厂商在 Demo 里能完成一段非常复杂的归因分析，但同样的模型能力在客户现场调用时，因为底层数据表和 Demo 环境里的命名风格差异过大，输出的 SQL 频繁引用不存在的字段，最终实际效果只能回到 L2。

这正是我强调能力层级测试要用自己业务数据的原因。厂商给的测试集不会覆盖你“订单表叫 ods_order_d 但别名又切换过”这类真实糟心事。构造一个贴近自身业务的评测集，比盲目追求六层全通要务实得多。

4. 可追溯性专项对比：证据链不是看功能列表

聊完能力层级，进入这篇文章的核心话题——可追溯性。我之所以把可追溯性放在准确率前面，是因为在实际业务落地中，不可解释的准确率等于零。业务方看到智能问数给出的结论，第一反应不是“这个数字准不准”，而是“这个数字怎么算出来的、凭什么这么算、和之前报表里的口径是不是一个意思”。

权威性文化越重的企业，这个需求越突出。财务、运营、经营分析团队用智能问数做决策复盘时，一定会要求留痕。出了审计问题或者业务事故，需要能把当时问的问题、系统生成的 SQL、查询的数据源、指标的定义版本全部翻出来核对。能做到这一点的厂商，和做不到的厂商，在选型中的位置完全是两个档位。

4.1 查询语句透明：能不能看到 SQL 是分水岭

第一层可追溯性是最基础的，也是我最先测的：生成的 SQL 能不能看到？能不能导出？能不能在系统外手动执行？

这五家里面，Chat2DB 做得最彻底。因为它本质就是个数据库客户端，SQL 是直接展示在执行面板上的，用户随时可以复制、修改、重新执行，天然透明。帆软 FineBI 和 Kyligence 会在界面里展示生成的 SQL 或查询表达式，但可编辑程度不同，有的必须回到 BI 的编辑界面才能改动，有的可以直接在对话窗里调整。

阿里云 Quick BI 的情况比较特殊，它的问数结果会和数据集面板联动，能够看到问题使用的数据集和字段，但如果是系统自动生成的复杂 SQL，在部分界面层级里并不会直接展开。数势科技在 Agent 模式下会展示每个分析步骤对应的 SQL，但如果 Agent 自主调用了多个子任务，每个子任务的 SQL 是拆开的，需要用户自己组装才能看到完整查询逻辑。

实际选型时，我会建议用一个“硬性测试”：拿一条业务问题去问，把系统生成的 SQL 拷贝到数据仓库的 SQL 编辑器里手动执行一遍，看结果是否和系统展示的完全一致。如果这条能做到，说明第一层追溯是可靠的。如果系统展示的 SQL 只是“示意”，实际执行的是另一套改写后的查询，追溯链路在这里就断了。

4.2 指标口径溯源：回答里引用的指标要有“身份证”

指标口径是所有数据分析工具最怕的深水区。一个“GMV”，在合同上可能是“通过移动端下单且支付成功”的金额，在经营分析里可能是“所有端用户确认收货”的金额，在财务口径里又可能是“计入当期收入并剔除退款”的金额。大模型如果直接从底层字段名猜含义，大概率会对口径产生误解。

在这个维度上，语义层路线的厂商优势显现出来了。Kyligence 因为有明确的语义模型，每个指标都有配置文件，问数系统在回答问题前先查“指标解释”，再把解释拼进提示模板让模型理解和计算，所以问题答案里的每个数字都能追溯到指标的原始定义。数势科技的指标平台也做了类似的事，但它的 Agent 路由策略更灵活，如果 Agent 在检索指标时找错了对象，或者检索到多个相似指标而选择了不恰当的一个，口径追溯就失败了。

帆软 FineBI 的指标管理和它的数据集是深度绑定的，如果企业之前已经通过 FineBI 的数据集做了指标规范化配置，问数的口径追溯效果不错；但如果只是用 FineBI 做可视化，没有做底层的指标建模，系统也难无中生有。Chat2DB 在这一项上基本没有能力，因为它完全依赖模型的推测。

4.3 血缘链路和执行留痕：出问题查得清才是真可追溯

如果说前两层追溯解决的是“结果对不对”，血缘和执行留痕解决的是“出了问题能不能定位”。一个理想的可追溯系统，必须能把这样一条完整链路画出来：

用户问题 → 意图识别结果 → 引用的指标定义 → 涉及的数据表 → 生成的 SQL → 执行引擎日志 → 返回的数据集 → 最终图表

这个链路里任何一个环节断裂，都可能导致业务事故时责任不明。阿里云在这一块有天然优势，因为 DataWorks 本身就有完善的数据血缘能力，如果智能问数查询的数据表能自动关联血缘图谱，追数据来源非常方便。帆软由于在私有化部署市场深耕多年，它的操作日志和权限记录体系很完善，适合对审计要求极高的金融、央企类客户。

数势科技和 Kyligence 在交互留痕方面也做得不错，二者都能把会话过程完整导出，但导出的详细程度不同。Kyligence 的优势是语义层和查询引擎的映射关系固定，如果用户发现结果不对，回去查的就是一条确定的执行路径；数势科技的 Agent 路径则相对灵活，事后可追溯的成本更高，因为它需要同时复盘模型决策路径和指标检索过程。

5. 评估方法与避坑实录：这套选型测试是怎么做的

上面的判断不是凭感觉拍脑袋得出的。我在对比这五家厂商时，搭了一套相对完整的评估框架，覆盖数据准备、测试用例设计、评分模型三个部分。这里把方法和踩过的坑分享出来，供正在做选型的团队参考。

5.1 评估数据集与测试用例设计

第一步是准备一套“有辨识度”的数据环境。我不建议直接用厂商提供的 Demo 环境和公开样例，因为那些数据在模型训练集中大概率已经出现过，测试结果天然偏好。我建议从自己业务中抽取三张左右的真实表，故意做一些和常见模式不一样的设计，比如：

• 字段名不用 standard_name，而是用了一个简称加拼音，比如商品表里用spmc（商品名称）、cate_lv2（二级品类）；
• 日期字段不用统一的date，而是分布在create_time和pay_time两个字段里，业务口径要求优先用pay_time；
• 存在一张多用途的宽表，同一个字段在不同部门语境下含义不同。

测试用例按能力层级设计，从单表、多表、口径修正、归因解释逐级递增。每组问题还要加一些“语气干扰项”，比如同一个问题，分别用“帮我看下”“能不能查一下”“麻烦给个数字”三种表达方式问一遍，用以测试系统的意图抽取稳定性。

5.2 评分模型与判定规则

每个问题我按 0-3 分四档打分：

这样打分的好处是把“准确率”这个虚的概念变成了一个综合指标。很多厂商 Demo 测下来准确率能到 80%，但我这套框架一打，综合得分会明显往下掉。原因很简单：单纯看“结果对不对”，很多问题模型都能蒙对；但加了“口径是否清楚”“SQL 能否复现”“过程是否合理”这些约束之后，能拿满分的题就少了。

5.3 几个容易踩的坑

踩坑一：不要被“多轮对话能力”迷惑。有一家厂商在 Demo 中非常能聊，你说“前面那个不对，改成看华东”，它能立刻理解。但实际测试时，我发现这种多轮能力只对“增量条件修改”有效，一旦用户修改的意图和上一轮语义有冲突，系统会生成新一轮完全不同的 SQL，而不是在之前基础上修正。多轮对话的稳定性取决于系统是否真正维护了“查询状态”，而不是简单地把上下文文本拼进提示词里。

踩坑二：时间口径是最容易犯错的点。同一家厂商在回答“本月销售额”时，默认取的自然月还是滚动 30 天，不同场景下可能不一致。我们需要非常仔细地核对这个隐藏假设。我问了多轮之后发现，有些系统在上一轮用了自然月口径，下一轮换了“最近三十天”口径，但界面一点提示都没有。这在实际业务中是致命的。

踩坑三：监控不到“模型幻觉”的老数据。有一家厂商在回答历史同期问题时，生成了一个明显异常的结果，后来排查出原因——模型没有真正查询数据仓库，而是“猜”了一个和上一轮比较类似的数字。这个情况在纯生成式路线的产品里更容易出现，需要厂商在架构上增加“结果必须经过查询引擎验证”的硬约束，才能从根上避免。

6. 选型建议：结合数据成熟度，别盲目追高

聊完了技术路线、能力层级和可追溯性，最后给一个实用主义的选型建议。没有绝对的“最好”，只有“适不适合你当前的数据基础”。

6.1 五类典型场景对应的厂商选择

第一类：已经在用帆软家族产品的企业。如果你的报表体系已经是 FineBI 的天下，且业务团队对帆软的操作习惯根深蒂固，选帆软的对话式分析是风险最低的方案。你不需要额外建指标平台，不需要重新做权限体系，智能问数只是你现有 BI 资产的延伸。它的上限可能不够惊艳，但胜在稳。

第二类：数据已经深度上云，且以阿里云体系为主的。选阿里云 Quick BI 效率最高。DataWorks 的血缘、MaxCompute 的算力、Quick BI 的可视化，加上通义千问的对话能力，链路全闭环。如果你的数据还在自建机房，硬要拆出某个模块用，体验会打不少折扣。

第三类：大型企业对指标标准化有强诉求，追求 Agent 化上限的。数势科技值得重点关注。但它需要一批懂指标建模的人，先把指标平台做好，Agent 的稳定性和可追溯性才能兑现。

第四类：已有 Kyligence 或类似 OLAP 语义层建设基础的。选 Kyligence 水到渠成。语义层会把可追溯性锁得很牢，适合数据治理要求高的企业。如果没有 OLAP 建设基础，需要考虑前置投入。

第五类：研发团队自用取数工具。Chat2DB 这类轻量级方案性价比极高。但不要幻想它能替代业务分析平台，它擅长的是把取数从“写一上午 SQL”变成“一分钟对话”，而不是做企业级指标治理和权限管控。

6.2 推进方式的最终建议

无论选择哪家，有一条建议希望你能记住：先在三个月内跑通一条最小链路，再谈规模化推广。我见过太多团队一上来就铺所有部门和几百张表，结果模型反馈慢、口径对不上、业务抱怨不断，最后项目被喊停。先把最核心的三张表、最常用的十个指标、最有代表性的二十个问题打磨通过，把可追溯性的四个层面完整跑通，再逐步扩大范围。

智能问数在 2026 年已经从“能不能把自然语言变成 SQL”的审美阶段，进入“答案靠得住、过程查得了、口径统一得了”的实用阶段。技术路线决定了产品的边界，可追溯性决定了业务敢不敢用，能力层级决定了能走多远。沿着这三条线去评估，你大概率能避开大部分选型坑。