2026 智能问数主流方案全景：从 Text-to-SQL 到语义层与数据 Agent

过去一年，智能问数这个词有点被叫滥了。

早期大家说“智能问数”，通常指一句中文问题变成一段 SQL：

这个月华东区 GMV 环比增长多少？ -> SELECT ...

但从 2026 年以来的公开资料看，主流方案已经明显不止 Text-to-SQL。Microsoft Fabric data agent、Snowflake Cortex Analyst、Databricks Genie、Amazon Q in QuickSight、Tableau Next、ThoughtSpot Spotter，以及国内 BI 厂商的智能问数能力，都在把重点放到三个更工程化的问题上：

指标口径是否统一？ 权限是否可控？ 回答是否可追溯、可复核、可持续改进？

这篇文章基于截至 2026-07-29 17:17（Asia/Shanghai）的公开资料和 GitHub 快照，做一次全景梳理。它不试图给某个厂商排名，而是回答一个更实用的问题：

如果今天要做智能问数，主流解决方案到底有哪些？它们共同点是什么？各自适合什么场景？底层怎么实现？

1. 先给结论：今年智能问数的核心变化

智能问数正在从“NL2SQL 工具”变成“受治理的数据分析系统”。

这句话可以拆成四层。

第一，单纯让大模型直接读数据库 schema 然后写 SQL，已经不够了。真实企业数据库里有上千张表、历史遗留字段、同名不同义指标、复杂权限和跨部门口径。模型即使能写出语法正确的 SQL，也可能算错业务口径。

第二，语义层正在成为核心。所谓语义层，不只是表字段注释，而是把“收入”“活跃用户”“转化率”“新客”“复购”这些业务概念，映射到可执行的数据资产上。Snowflake Cortex Analyst 使用 semantic model，Databricks Genie 强调 trusted data assets 和 instruction，WrenAI 把自己描述为基于 open context layer 的 governed text-to-SQL，都是这个趋势。

第三，主流产品越来越像 Agent。它们不只是生成 SQL，而是会检索元数据、澄清问题、选择指标、调用查询接口、生成图表、解释结果、记录反馈，有些还会进入仪表板、报告、审批和工作流。

第四，落地门槛从“模型能力”转向“数据治理能力”。智能问数不是把 GPT 接上数据库就完事。真正决定效果的是指标资产、表血缘、权限模型、样例问法、查询历史、SQL 校验、成本控制和运营反馈。

2. 共同特点：一个成熟智能问数系统通常长这样

不管厂商名字怎么变，成熟架构基本都绕不开下面这条链路：

用户自然语言问题 -> 意图识别与澄清 -> 检索业务语义、指标定义、表字段、样例 SQL、历史问答 -> 选择数据集、指标、维度、过滤条件和时间粒度 -> 生成 SQL / DAX / LookML / Metric DSL / Analytics API 调用 -> 权限校验、语法校验、成本估计、只读约束 -> 在用户权限下执行查询 -> 返回表格、图表、解释、口径说明和可追溯链接 -> 收集反馈，沉淀为语义层和评测集

这里最关键的不是中间那一步“生成查询”，而是前后的保护层。

一个能上线的智能问数系统，至少应该有这些共同能力：

所以，智能问数的真实技术栈不是单点模型，而是一个数据产品工程：

LLM + RAG + Semantic Layer + Query Engine + BI UI + Governance + Observability

3. 主流方案一：BI 平台内置 Copilot

这一类最容易被业务用户感知，因为入口就在 BI 工具里。典型代表包括 Power BI Copilot、Tableau Agent / Tableau Next、ThoughtSpot Spotter、Amazon Q in QuickSight、Google Looker 里的 Gemini 能力，以及国内 Quick BI、FineBI、Smartbi、DataFocus 等智能问数产品。

3.1 适合什么场景

如果公司已经大量使用某个 BI 平台，有现成数据集、仪表板、权限和指标管理，那么 BI 内置 Copilot 往往是最短路径。

典型问题包括：

今年各区域销售额排名是什么？ 帮我解释这个看板为什么下滑。 用自然语言生成一个趋势图。 把这个 dashboard 总结成一段经营分析。

3.2 实现方式

BI 内置方案通常这样实现：

BI 数据集 / Semantic Model / Dashboard -> 抽取字段、指标、可视化上下文、用户权限 -> LLM 理解问题 -> 生成平台内部查询表达式，如 DAX、VizQL、LookML、SQL 或厂商自有 DSL -> 调用 BI 查询引擎 -> 渲染图表、解释洞察、生成报告

它的关键优势是“不绕开 BI 治理”。用户原本能看什么数据，智能问数原则上也只能看什么数据；原本在语义模型里定义好的指标，Copilot 可以直接复用。

3.3 优点

第一，落地快。已有数据集、权限和仪表板可以直接复用，不需要从零开发前端和权限系统。

第二，业务用户接受度高。问数入口就在熟悉的 BI 页面里，用户不需要跳到单独聊天工具。

第三，和可视化天然结合。它不仅回答数字，还能生成图表、解释看板和辅助搭建报告。

第四，比较容易控制口径。只要企业本身已经把指标和数据集治理好，AI 问数会站在这些资产之上，而不是直接乱查物理表。

3.4 缺点

第一，受限于平台生态。Power BI 的 Copilot 更贴近 Fabric 和 Power BI 资产；Tableau 的智能分析会贴近 Tableau 语义与 Salesforce 生态；QuickSight、Looker、Quick BI 也各有自己的数据建模方式。

第二，跨平台能力有限。如果数据和报表分散在多个 BI 工具里，单一平台 Copilot 很难给出完整视角。

第三，深度定制不一定方便。比如你想加入公司内部审批流、复杂推荐策略、私有模型路由，厂商内置能力可能不如自建灵活。

第四，效果高度依赖已有 BI 资产质量。语义模型混乱、指标重复、字段命名不清，Copilot 只会把混乱放大。

4. 主流方案二：云数仓 / Lakehouse 原生数据 Agent

这一类的入口不一定在 BI，而在数据平台本身。典型代表是 Databricks Genie、Snowflake Cortex Analyst、Microsoft Fabric data agent。

它们共同点是：让智能问数更靠近数据存储、目录、权限和计算引擎。

4.1 适合什么场景

当企业已经把核心数据放在 Snowflake、Databricks、Fabric 这类平台上，并希望在统一数据治理下做自然语言分析，这类方案很适合。

典型问题包括：

过去 90 天不同渠道留存率有什么变化？ 找出本季度毛利率下降最明显的产品线。 基于 lakehouse 中的订单和用户表，分析新客贡献。

4.2 实现方式

数据平台原生方案一般采用这种结构：

Data Catalog / Unity Catalog / Snowflake Objects / Fabric Items -> 管理员配置可信数据资产、语义模型、说明文档和样例问题 -> LLM 根据问题检索相关资产 -> 生成 SQL 或平台原生查询 -> 在平台权限、审计和资源控制下执行 -> 返回结果、图表和解释

Snowflake Cortex Analyst 的核心是 semantic model / semantic view 与 REST API；Databricks Genie 使用 Genie spaces，把可信数据资产、说明和示例组织起来；Fabric data agent 则面向 Fabric 里的 lakehouse、warehouse、Power BI semantic model 等数据资产提供问答能力。

4.3 优点

第一，数据不需要搬家。问数逻辑直接贴近数仓、湖仓和目录治理。

第二，权限和审计更自然。查询在原平台里执行，容易继承数据目录、行列权限、审计日志和成本控制。

第三，适合数据团队运营。数据工程师可以直接维护数据资产说明、表关系、样例问题和语义模型。

第四，服务化能力更强。比如 Cortex Analyst 通过 API 暴露能力，适合嵌入到内部系统；Fabric data agent 也更像企业数据应用的一部分。

4.4 缺点

第一，绑定底层平台。如果主要数据不在该云数仓或 lakehouse，迁移和接入成本会比较高。

第二，业务用户体验未必优于 BI。数据平台更懂数据资产，但不一定有成熟的报表消费场景。

第三，仍然需要语义治理。平台原生不等于自动理解业务。指标定义、字段解释、表关系和样例问题仍要人工建设。

第四，成本控制要认真设计。自然语言问数可能生成扫描很大的查询，必须做 SQL 复杂度、时间范围、limit、预算和缓存控制。

5. 主流方案三：语义层 / 指标平台优先

这是我认为今年最值得重视的一类。

它的思路不是“问题直接生成 SQL”，而是先把自然语言问题翻译成受治理的业务概念：

自然语言 -> 指标、维度、过滤条件、时间粒度 -> Metric DSL / Semantic API / 分析 API -> 编译为 SQL -> 执行并解释

2026 年的一些研究也在往这个方向走。例如 arXiv 2606.31041 讨论了面向企业数据库的 semantic-layer-mediated agentic framework；arXiv 2605.21027 则讨论把自然语言请求翻译为 governed analytics API calls，而不是让模型直接操作底层数据库。

这背后的判断很清楚：企业问数最怕的不是 SQL 写不出来，而是“同一个问题问出两套数字”。

5.1 适合什么场景

这类方案特别适合强指标治理场景：

经营分析 财务分析 销售管理 用户增长 SaaS 指标体系 供应链指标看板 集团级统一经营口径

如果公司最关心的是“收入、GMV、毛利、转化率、留存、活跃、复购”这些标准指标，语义层优先通常比裸 Text-to-SQL 更稳。

5.2 实现方式

一套典型指标语义层问数系统可以这样设计：

metrics:revenue:name:收入formula:sum(order_amount)filters:order_status:paidtime_dimension:paid_atdimensions:region:name:区域column:dim_region.region_namesynonyms:收入:[销售额,营收,revenue]华东:[华东区,East China]

用户提问：

本季度华东收入同比增长多少？

系统解析为：

{"metric":"revenue","dimension":"region","filter":{"region":"华东"},"time_range":"current_quarter","comparison":"year_over_year"}

然后由指标引擎生成 SQL。

5.3 优点

第一，口径一致。只要指标定义稳定，问数、看板、报表都能复用同一套口径。

第二，可审计。系统可以明确告诉你使用了哪个指标、哪个维度、哪个过滤条件。

第三，安全边界更清楚。模型不直接操作任意表，而是调用受限的指标 API。

第四，适合高频经营分析。越是标准化业务问题，语义层方案越稳定。

5.4 缺点

第一，前期建设成本高。要梳理指标、维度、口径、同义词、层级和权限。

第二，开放探索能力弱于裸 SQL。用户问一个没有建模过的临时问题，系统可能答不上来。

第三，组织协同要求高。指标平台不是技术团队单独能完成的，需要业务、数仓、BI、治理团队共同维护。

第四，版本管理很重要。指标口径变化后，历史问答、看板和报表都要能解释差异。

6. 主流方案四：开源 Text-to-SQL / ChatBI 自建

如果预算有限、数据不能出内网、需要深度定制，开源方案会很有吸引力。

今年仍然活跃或有代表性的项目包括 SQLBot、WrenAI、DB-GPT，以及影响较大的 Vanna。GitHub API 在 2026-07-29 的快照显示：

这些数据会随时间变化，但能看出一个趋势：开源智能问数并不冷，尤其在私有化和可控部署场景里很有生命力。

6.1 适合什么场景

开源自建适合这些情况：

数据必须在内网或私有云 需要接很多非标准数据库 希望用国产模型或自部署模型 要把问数嵌入公司已有系统 需要完全控制提示词、工具、权限和日志

6.2 实现方式

开源 Text-to-SQL 通常采用 RAG 架构：

Schema / DDL / 字段注释 / 数据字典 / 样例 SQL / 历史问答 -> 向量化或关键词索引 -> 根据用户问题检索相关上下文 -> LLM 生成 SQL -> SQL parser 校验只读、表白名单、limit、复杂度 -> 执行查询 -> 结果表格化、图表化、自然语言解释

一个最小实现可以这样理解：

defask_data(question:str,user_id:str):context=retrieve_metadata(question)prompt=build_sql_prompt(question,context)sql=llm_generate_sql(prompt)validate_readonly(sql)validate_table_permissions(sql,user_id)estimate_query_cost(sql)result=execute_sql(sql,user_id=user_id)chart=choose_chart(question,result)answer=explain_result(question,sql,result)log_feedback_trace(question,context,sql,result,answer)returnanswer,chart

6.3 优点

第一，可私有化。数据、模型、日志、提示词和中间结果都可以留在自己的环境里。

第二，可深度定制。可以接内部权限系统、数据目录、审批流、模型网关和告警系统。

第三，成本可控。对中小团队来说，开源方案比直接采购全套商业 BI AI 能力更容易试错。

第四，适合技术团队学习和二次开发。想理解智能问数本质，开源项目是很好的入口。

6.4 缺点

第一，工程责任都在自己身上。权限、审计、缓存、SQL 安全、失败重试、模型评测都要自己补齐。

第二，模型效果高度依赖元数据质量。字段名像f_001、表名没有注释、样例 SQL 不足，再强模型也会迷路。

第三，生产稳定性需要长期运营。问数系统不是一次部署就结束，它需要持续收集错误样例、补同义词、补指标解释、调查询策略。

第四，安全风险更突出。SQL 注入、越权访问、prompt injection、昂贵查询、敏感字段泄露，都必须从第一天设计。

7. 主流方案五：Agentic Analytics，多智能体深度分析

第五类更像未来方向：不是只回答一个数，而是让 Agent 完成一段分析任务。

例如：

帮我分析过去半年新客留存下降的原因，给出三条可验证假设，并生成一页经营汇报。

这类任务不是单条 SQL 能解决的。它可能需要：

拆解问题 -> 查询多张表 -> 做分组、对比、归因 -> 生成图表 -> 读取业务文档或实验记录 -> 写成报告 -> 标出不确定性和需要人工确认的地方

7.1 实现方式

Agentic Analytics 通常由多个角色或工具组成：

Planner Agent：拆解分析任务 Metadata Agent：找数据源、指标、字段和样例 SQL Agent：生成查询 Validator：检查权限、口径、SQL 安全和成本 Executor：执行查询 Chart Agent：选择图表 Narrative Agent：生成分析叙事 Human Review：关键结论人工确认

它的关键不是“多个 Agent 很酷”，而是把复杂分析拆成可观测、可回滚、可校验的步骤。

7.2 优点

第一，能处理复杂问题。比如归因、异常解释、分群对比、报告生成，单次 NL2SQL 很难完成。

第二，更接近真实数据分析师工作流。分析师不是只写一条 SQL，而是反复提出假设、查证、修正和总结。

第三，适合嵌入业务流程。周报、经营例会、异常告警、销售复盘，都可以做成半自动工作流。

7.3 缺点

第一，验证难度大。步骤越多，越容易出现看似合理但实际错误的推理链。

第二，成本和延迟更高。多轮模型调用、多次查询、多次图表生成，都会增加成本。

第三，需要人工审批。涉及经营决策、财务口径、外发报告时，不应完全自动发布结论。

第四，对可观测性要求高。没有 traces、SQL 日志、输入输出快照和评测集，后期很难定位错误。

8. 各类方案横向对比

如果用一句话做选型：

已有成熟 BI：优先 BI Copilot 数据集中在云数仓：优先数据平台原生 Agent 指标口径最重要：优先语义层 / 指标平台 需要私有化和深度定制：优先开源自建 想自动生成分析报告：再考虑 Agentic Analytics

9. 企业实现智能问数的推荐路线

我不建议企业一上来就做“万能问数机器人”。这通常会变成一个漂亮但不可靠的 demo。

更稳的路线是分四步。

第一步：选一个窄场景

不要从“公司所有数据都能问”开始。先选一个业务闭环，比如：

销售经营分析 客服工单分析 渠道投放分析 会员增长分析 库存周转分析

窄场景更容易定义指标、权限和正确答案，也更容易收集反馈。

第二步：先建设语义资产

至少要准备这些内容：

核心指标定义 维度层级 字段注释 同义词词表 常见问题 标准 SQL 样例 反例和错误样例 权限规则

很多智能问数失败，不是因为模型差，而是因为业务知识没有结构化。

第三步：把 SQL 生成关进笼子

生产系统里，LLM 生成 SQL 后不能直接执行。至少要有这些保护：

只允许 SELECT 禁止 DDL / DML 限制表白名单 限制行数和扫描成本 强制加时间范围 继承用户权限 执行前 EXPLAIN 敏感字段脱敏 失败时返回可解释错误

智能问数不是让模型自由发挥，而是让模型在受控空间里完成任务。

第四步：建立评测和运营机制

上线后要持续维护：

问题命中率 SQL 可执行率 结果正确率 用户采纳率 平均响应时间 高成本查询占比 越权拦截次数 被用户纠正的问题

最好把高频问题沉淀成回归测试集。每次换模型、换 prompt、改语义层，都跑一遍评测。

10. 我对 2026 智能问数的判断

今年智能问数会继续火，但真正能留下来的，不会是“会写 SQL 的聊天框”。

能留下来的会是三种系统：

第一种，和现有 BI 深度结合的问数入口。它服务大多数业务用户，让看数、问数、解释、做报表变得更轻。

第二种，数仓和 lakehouse 原生的数据 Agent。它服务数据团队和数据应用开发者，把自然语言分析能力变成平台能力。

第三种，语义层驱动的指标问答系统。它服务经营管理和核心决策，让“同一个问题只有一个可信答案”。

开源自建也会继续存在，尤其在私有化、国产模型、信创和复杂内网环境里。只是开源方案要想进生产，必须补齐治理、安全、评测和运营。

所以，做智能问数时最重要的判断不是“用哪个大模型”，而是：

你想让用户问什么范围的问题？ 这些问题有没有统一口径？ 查询是否受权限控制？ 结果错了能不能追溯？ 系统能不能随着反馈变得更准？

如果这些问题没有答案，再强的 Text-to-SQL 也只是一次演示。
如果这些问题有答案，智能问数才可能从 demo 走向真正的数据生产力。

参考来源

• Microsoft Fabric data agent documentation：https://learn.microsoft.com/en-us/fabric/data-science/concept-data-agent
• Microsoft Power BI Copilot documentation：https://learn.microsoft.com/en-us/power-bi/create-reports/copilot-introduction
• Snowflake Cortex Analyst documentation：https://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analyst
• Databricks AI/BI Genie documentation：https://docs.databricks.com/aws/en/genie/
• Amazon Q in QuickSight documentation：https://docs.aws.amazon.com/quicksuite/latest/userguide/generative-bi.html
• Google Looker / Gemini documentation：https://cloud.google.com/looker/docs/gemini-in-looker
• Tableau Next / Tableau Agent official information：https://www.tableau.com/products/tableau-next
• ThoughtSpot Spotter official information：https://www.thoughtspot.com/product/spotter
• Alibaba Cloud Quick BI documentation：https://help.aliyun.com/zh/quick-bi/
• FineBI official information：https://www.finebi.com/
• Smartbi AIChat official information：https://www.smartbi.com.cn/
• DataFocus official information：https://www.datafocus.ai/
• Kyligence official information：https://kyligence.io/
• SQLBot GitHub：https://github.com/dataease/SQLBot
• WrenAI GitHub：https://github.com/Canner/WrenAI
• Vanna GitHub：https://github.com/vanna-ai/vanna
• DB-GPT GitHub：https://github.com/eosphoros-ai/DB-GPT
• arXiv 2606.31041, Semantic Layer Based Agentic Framework for Natural Language Querying of Enterprise Databases：https://arxiv.org/abs/2606.31041
• arXiv 2605.21027, Translating Natural Language Requests to Governed Analytics API Calls：https://arxiv.org/abs/2605.21027
• GitHub API 快照：本文开源项目 star、fork、pushed_at、license 等信息抓取时间为 2026-07-29 17:17（Asia/Shanghai），原始记录保存在本地研究目录。

许可说明

本文为原创中文技术分析与方案梳理，不是对任何厂商文档或论文的完整翻译。文中仅基于公开资料做必要概括、对比和技术解释，不搬运第三方受限图片或大段原文；所有关键资料均在参考来源中列出。