过去一年智能问数这个词有点被叫滥了。早期大家说“智能问数”通常指一句中文问题变成一段 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:17Asia/Shanghai的公开资料和 GitHub 快照做一次全景梳理。它不试图给某个厂商排名而是回答一个更实用的问题如果今天要做智能问数主流解决方案到底有哪些它们共同点是什么各自适合什么场景底层怎么实现1. 先给结论今年智能问数的核心变化智能问数正在从“NL2SQL 工具”变成“受治理的数据分析系统”。这句话可以拆成四层。第一单纯让大模型直接读数据库 schema 然后写 SQL已经不够了。真实企业数据库里有上千张表、历史遗留字段、同名不同义指标、复杂权限和跨部门口径。模型即使能写出语法正确的 SQL也可能算错业务口径。第二语义层正在成为核心。所谓语义层不只是表字段注释而是把“收入”“活跃用户”“转化率”“新客”“复购”这些业务概念映射到可执行的数据资产上。Snowflake Cortex Analyst 使用 semantic modelDatabricks Genie 强调 trusted data assets 和 instructionWrenAI 把自己描述为基于 open context layer 的 governed text-to-SQL都是这个趋势。第三主流产品越来越像 Agent。它们不只是生成 SQL而是会检索元数据、澄清问题、选择指标、调用查询接口、生成图表、解释结果、记录反馈有些还会进入仪表板、报告、审批和工作流。第四落地门槛从“模型能力”转向“数据治理能力”。智能问数不是把 GPT 接上数据库就完事。真正决定效果的是指标资产、表血缘、权限模型、样例问法、查询历史、SQL 校验、成本控制和运营反馈。2. 共同特点一个成熟智能问数系统通常长这样不管厂商名字怎么变成熟架构基本都绕不开下面这条链路用户自然语言问题 - 意图识别与澄清 - 检索业务语义、指标定义、表字段、样例 SQL、历史问答 - 选择数据集、指标、维度、过滤条件和时间粒度 - 生成 SQL / DAX / LookML / Metric DSL / Analytics API 调用 - 权限校验、语法校验、成本估计、只读约束 - 在用户权限下执行查询 - 返回表格、图表、解释、口径说明和可追溯链接 - 收集反馈沉淀为语义层和评测集这里最关键的不是中间那一步“生成查询”而是前后的保护层。一个能上线的智能问数系统至少应该有这些共同能力能力为什么重要语义层解决业务口径、指标定义、维度层级和字段同义词问题元数据检索让模型知道哪些表、字段、指标、示例和规则与当前问题相关权限继承用户只能问到自己原本有权访问的数据SQL/DSL 校验防止模型生成危险、昂贵、错误或不可执行的查询多轮澄清当“销售额”“本月”“客户”含义不明确时让系统反问可视化生成问数不只是数字还要能自动选择柱状图、折线图、表格或指标卡结果解释告诉用户数字怎么来的、口径是什么、用了哪些筛选条件反馈闭环把用户纠错、收藏、改写问题沉淀为样例和评测集所以智能问数的真实技术栈不是单点模型而是一个数据产品工程LLM RAG Semantic Layer Query Engine BI UI Governance Observability3. 主流方案一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 APIDatabricks 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 frameworkarXiv 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 的快照显示项目快照信息代表方向dataease/SQLBot约 6509 stars / 808 forks当天仍有 push基于大模型和 RAG 的智能问数系统Canner/WrenAI约 16724 stars / 1886 forks当天仍有 pushopen context layer governed text-to-SQL / GenBIeosphoros-ai/DB-GPT约 19589 stars / 2846 forks2026-07-28 有 pushopen-source agentic AI data assistantvanna-ai/vanna约 23823 stars / 2456 forksMITGitHub API 显示 archivedtrueRAG Text-to-SQL 思路影响较大这些数据会随时间变化但能看出一个趋势开源智能问数并不冷尤其在私有化和可控部署场景里很有生命力。6.1 适合什么场景开源自建适合这些情况数据必须在内网或私有云 需要接很多非标准数据库 希望用国产模型或自部署模型 要把问数嵌入公司已有系统 需要完全控制提示词、工具、权限和日志6.2 实现方式开源 Text-to-SQL 通常采用 RAG 架构Schema / DDL / 字段注释 / 数据字典 / 样例 SQL / 历史问答 - 向量化或关键词索引 - 根据用户问题检索相关上下文 - LLM 生成 SQL - SQL parser 校验只读、表白名单、limit、复杂度 - 执行查询 - 结果表格化、图表化、自然语言解释一个最小实现可以这样理解defask_data(question:str,user_id:str):contextretrieve_metadata(question)promptbuild_sql_prompt(question,context)sqlllm_generate_sql(prompt)validate_readonly(sql)validate_table_permissions(sql,user_id)estimate_query_cost(sql)resultexecute_sql(sql,user_iduser_id)chartchoose_chart(question,result)answerexplain_result(question,sql,result)log_feedback_trace(question,context,sql,result,answer)returnanswer,chart6.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 内置 CopilotPower BI Copilot、Tableau、ThoughtSpot、QuickSight、Quick BI、FineBI已有 BI 资产的企业上手快图表和权限复用受平台限制依赖已有语义质量云数仓 / Lakehouse 原生 AgentSnowflake Cortex Analyst、Databricks Genie、Fabric data agent数据集中在云数仓或 lakehouse贴近数据治理和执行引擎平台绑定业务消费体验要补语义层 / 指标平台优先Kyligence、WrenAI、dbt/Cube 类语义层、自研指标平台经营指标和口径治理口径一致、可审计、可复用前期建模成本高临时探索较弱开源 Text-to-SQL / ChatBISQLBot、WrenAI、DB-GPT、Vanna私有化、自定义、低成本试点灵活、可控、可二开生产治理和安全要自己做Agentic Analytics多智能体分析系统、自研数据 Agent复杂归因、报告、自动分析流程能处理多步骤分析任务成本高、验证难、需要人工复核如果用一句话做选型已有成熟 BI优先 BI Copilot 数据集中在云数仓优先数据平台原生 Agent 指标口径最重要优先语义层 / 指标平台 需要私有化和深度定制优先开源自建 想自动生成分析报告再考虑 Agentic Analytics9. 企业实现智能问数的推荐路线我不建议企业一上来就做“万能问数机器人”。这通常会变成一个漂亮但不可靠的 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 documentationhttps://learn.microsoft.com/en-us/fabric/data-science/concept-data-agentMicrosoft Power BI Copilot documentationhttps://learn.microsoft.com/en-us/power-bi/create-reports/copilot-introductionSnowflake Cortex Analyst documentationhttps://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analystDatabricks AI/BI Genie documentationhttps://docs.databricks.com/aws/en/genie/Amazon Q in QuickSight documentationhttps://docs.aws.amazon.com/quicksuite/latest/userguide/generative-bi.htmlGoogle Looker / Gemini documentationhttps://cloud.google.com/looker/docs/gemini-in-lookerTableau Next / Tableau Agent official informationhttps://www.tableau.com/products/tableau-nextThoughtSpot Spotter official informationhttps://www.thoughtspot.com/product/spotterAlibaba Cloud Quick BI documentationhttps://help.aliyun.com/zh/quick-bi/FineBI official informationhttps://www.finebi.com/Smartbi AIChat official informationhttps://www.smartbi.com.cn/DataFocus official informationhttps://www.datafocus.ai/Kyligence official informationhttps://kyligence.io/SQLBot GitHubhttps://github.com/dataease/SQLBotWrenAI GitHubhttps://github.com/Canner/WrenAIVanna GitHubhttps://github.com/vanna-ai/vannaDB-GPT GitHubhttps://github.com/eosphoros-ai/DB-GPTarXiv 2606.31041, Semantic Layer Based Agentic Framework for Natural Language Querying of Enterprise Databaseshttps://arxiv.org/abs/2606.31041arXiv 2605.21027, Translating Natural Language Requests to Governed Analytics API Callshttps://arxiv.org/abs/2605.21027GitHub API 快照本文开源项目 star、fork、pushed_at、license 等信息抓取时间为 2026-07-29 17:17Asia/Shanghai原始记录保存在本地研究目录。许可说明本文为原创中文技术分析与方案梳理不是对任何厂商文档或论文的完整翻译。文中仅基于公开资料做必要概括、对比和技术解释不搬运第三方受限图片或大段原文所有关键资料均在参考来源中列出。
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:17Asia/Shanghai的公开资料和 GitHub 快照做一次全景梳理。它不试图给某个厂商排名而是回答一个更实用的问题如果今天要做智能问数主流解决方案到底有哪些它们共同点是什么各自适合什么场景底层怎么实现1. 先给结论今年智能问数的核心变化智能问数正在从“NL2SQL 工具”变成“受治理的数据分析系统”。这句话可以拆成四层。第一单纯让大模型直接读数据库 schema 然后写 SQL已经不够了。真实企业数据库里有上千张表、历史遗留字段、同名不同义指标、复杂权限和跨部门口径。模型即使能写出语法正确的 SQL也可能算错业务口径。第二语义层正在成为核心。所谓语义层不只是表字段注释而是把“收入”“活跃用户”“转化率”“新客”“复购”这些业务概念映射到可执行的数据资产上。Snowflake Cortex Analyst 使用 semantic modelDatabricks Genie 强调 trusted data assets 和 instructionWrenAI 把自己描述为基于 open context layer 的 governed text-to-SQL都是这个趋势。第三主流产品越来越像 Agent。它们不只是生成 SQL而是会检索元数据、澄清问题、选择指标、调用查询接口、生成图表、解释结果、记录反馈有些还会进入仪表板、报告、审批和工作流。第四落地门槛从“模型能力”转向“数据治理能力”。智能问数不是把 GPT 接上数据库就完事。真正决定效果的是指标资产、表血缘、权限模型、样例问法、查询历史、SQL 校验、成本控制和运营反馈。2. 共同特点一个成熟智能问数系统通常长这样不管厂商名字怎么变成熟架构基本都绕不开下面这条链路用户自然语言问题 - 意图识别与澄清 - 检索业务语义、指标定义、表字段、样例 SQL、历史问答 - 选择数据集、指标、维度、过滤条件和时间粒度 - 生成 SQL / DAX / LookML / Metric DSL / Analytics API 调用 - 权限校验、语法校验、成本估计、只读约束 - 在用户权限下执行查询 - 返回表格、图表、解释、口径说明和可追溯链接 - 收集反馈沉淀为语义层和评测集这里最关键的不是中间那一步“生成查询”而是前后的保护层。一个能上线的智能问数系统至少应该有这些共同能力能力为什么重要语义层解决业务口径、指标定义、维度层级和字段同义词问题元数据检索让模型知道哪些表、字段、指标、示例和规则与当前问题相关权限继承用户只能问到自己原本有权访问的数据SQL/DSL 校验防止模型生成危险、昂贵、错误或不可执行的查询多轮澄清当“销售额”“本月”“客户”含义不明确时让系统反问可视化生成问数不只是数字还要能自动选择柱状图、折线图、表格或指标卡结果解释告诉用户数字怎么来的、口径是什么、用了哪些筛选条件反馈闭环把用户纠错、收藏、改写问题沉淀为样例和评测集所以智能问数的真实技术栈不是单点模型而是一个数据产品工程LLM RAG Semantic Layer Query Engine BI UI Governance Observability3. 主流方案一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 APIDatabricks 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 frameworkarXiv 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 的快照显示项目快照信息代表方向dataease/SQLBot约 6509 stars / 808 forks当天仍有 push基于大模型和 RAG 的智能问数系统Canner/WrenAI约 16724 stars / 1886 forks当天仍有 pushopen context layer governed text-to-SQL / GenBIeosphoros-ai/DB-GPT约 19589 stars / 2846 forks2026-07-28 有 pushopen-source agentic AI data assistantvanna-ai/vanna约 23823 stars / 2456 forksMITGitHub API 显示 archivedtrueRAG Text-to-SQL 思路影响较大这些数据会随时间变化但能看出一个趋势开源智能问数并不冷尤其在私有化和可控部署场景里很有生命力。6.1 适合什么场景开源自建适合这些情况数据必须在内网或私有云 需要接很多非标准数据库 希望用国产模型或自部署模型 要把问数嵌入公司已有系统 需要完全控制提示词、工具、权限和日志6.2 实现方式开源 Text-to-SQL 通常采用 RAG 架构Schema / DDL / 字段注释 / 数据字典 / 样例 SQL / 历史问答 - 向量化或关键词索引 - 根据用户问题检索相关上下文 - LLM 生成 SQL - SQL parser 校验只读、表白名单、limit、复杂度 - 执行查询 - 结果表格化、图表化、自然语言解释一个最小实现可以这样理解defask_data(question:str,user_id:str):contextretrieve_metadata(question)promptbuild_sql_prompt(question,context)sqlllm_generate_sql(prompt)validate_readonly(sql)validate_table_permissions(sql,user_id)estimate_query_cost(sql)resultexecute_sql(sql,user_iduser_id)chartchoose_chart(question,result)answerexplain_result(question,sql,result)log_feedback_trace(question,context,sql,result,answer)returnanswer,chart6.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 内置 CopilotPower BI Copilot、Tableau、ThoughtSpot、QuickSight、Quick BI、FineBI已有 BI 资产的企业上手快图表和权限复用受平台限制依赖已有语义质量云数仓 / Lakehouse 原生 AgentSnowflake Cortex Analyst、Databricks Genie、Fabric data agent数据集中在云数仓或 lakehouse贴近数据治理和执行引擎平台绑定业务消费体验要补语义层 / 指标平台优先Kyligence、WrenAI、dbt/Cube 类语义层、自研指标平台经营指标和口径治理口径一致、可审计、可复用前期建模成本高临时探索较弱开源 Text-to-SQL / ChatBISQLBot、WrenAI、DB-GPT、Vanna私有化、自定义、低成本试点灵活、可控、可二开生产治理和安全要自己做Agentic Analytics多智能体分析系统、自研数据 Agent复杂归因、报告、自动分析流程能处理多步骤分析任务成本高、验证难、需要人工复核如果用一句话做选型已有成熟 BI优先 BI Copilot 数据集中在云数仓优先数据平台原生 Agent 指标口径最重要优先语义层 / 指标平台 需要私有化和深度定制优先开源自建 想自动生成分析报告再考虑 Agentic Analytics9. 企业实现智能问数的推荐路线我不建议企业一上来就做“万能问数机器人”。这通常会变成一个漂亮但不可靠的 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 documentationhttps://learn.microsoft.com/en-us/fabric/data-science/concept-data-agentMicrosoft Power BI Copilot documentationhttps://learn.microsoft.com/en-us/power-bi/create-reports/copilot-introductionSnowflake Cortex Analyst documentationhttps://docs.snowflake.com/en/user-guide/snowflake-cortex/cortex-analystDatabricks AI/BI Genie documentationhttps://docs.databricks.com/aws/en/genie/Amazon Q in QuickSight documentationhttps://docs.aws.amazon.com/quicksuite/latest/userguide/generative-bi.htmlGoogle Looker / Gemini documentationhttps://cloud.google.com/looker/docs/gemini-in-lookerTableau Next / Tableau Agent official informationhttps://www.tableau.com/products/tableau-nextThoughtSpot Spotter official informationhttps://www.thoughtspot.com/product/spotterAlibaba Cloud Quick BI documentationhttps://help.aliyun.com/zh/quick-bi/FineBI official informationhttps://www.finebi.com/Smartbi AIChat official informationhttps://www.smartbi.com.cn/DataFocus official informationhttps://www.datafocus.ai/Kyligence official informationhttps://kyligence.io/SQLBot GitHubhttps://github.com/dataease/SQLBotWrenAI GitHubhttps://github.com/Canner/WrenAIVanna GitHubhttps://github.com/vanna-ai/vannaDB-GPT GitHubhttps://github.com/eosphoros-ai/DB-GPTarXiv 2606.31041, Semantic Layer Based Agentic Framework for Natural Language Querying of Enterprise Databaseshttps://arxiv.org/abs/2606.31041arXiv 2605.21027, Translating Natural Language Requests to Governed Analytics API Callshttps://arxiv.org/abs/2605.21027GitHub API 快照本文开源项目 star、fork、pushed_at、license 等信息抓取时间为 2026-07-29 17:17Asia/Shanghai原始记录保存在本地研究目录。许可说明本文为原创中文技术分析与方案梳理不是对任何厂商文档或论文的完整翻译。文中仅基于公开资料做必要概括、对比和技术解释不搬运第三方受限图片或大段原文所有关键资料均在参考来源中列出。
