智能问数产品现况、优缺点与项目启示

更新时间：2026-06-26

1. 结论先行

智能问数正在从早期的“自然语言转 SQL”进入“语义层 + 数据治理 + Agent 工作流”的阶段。2023 年前后的多数产品强调“问一句、出一张图”；2025-2026 年主流方向已经明显变成：围绕可信语义、权限、指标口径、可解释查询、多轮分析、自动报告、嵌入式数据智能体来做完整闭环。

当前市面产品大致分为四类：

  1. 传统 BI 厂商的 AI 化：Power BI Copilot、Tableau Agent、ThoughtSpot Spotter、Qlik、FineBI/FineChatBI、Quick BI 小Q、Smartbi AIChat、观远问数 Agent 等。优势是 BI 底座、权限、图表和企业交付成熟；短板是价格、绑定生态、二开受限。
  2. 云数仓/数据平台原生智能问数：Snowflake Cortex Analyst、Databricks Genie、Looker Conversational Analytics、Amazon QuickSight Q 等。优势是和底层数据治理、计算、权限结合深；短板是平台锁定明显，很多能力偏 API/平台能力，不一定是完整业务端产品。
  3. 开源/可自建 ChatBI 与 Text-to-SQL：SQLBot、SuperSonic、WrenAI、DB-GPT、QueryWeaver、OpenChatBI 等。优势是可控、可私有化、适合二开；短板是需要自己解决企业级治理、评测、权限和运维。
  4. AI 数据库客户端/分析师工具：Chat2DB、SQLChat、PandasAI 等。优势是对技术人员友好，上手快；短板是更像辅助写 SQL 或探索数据，不适合直接面向大量业务用户做正式问数入口。

最值得借鉴的趋势是：不要只做 Text-to-SQL，而要做“业务语义层驱动的可信问数系统”。一个可落地的项目应包含数据目录、指标口径、同义词、权限、问题改写、SQL 生成、SQL 校验、结果解释、图表推荐、反馈学习和离线评测。

2. 什么是智能问数

智能问数，也常被称为 ChatBI、NLQ、Text-to-SQL、Conversational Analytics、AI Analyst。它的目标是让用户用自然语言直接询问业务数据，例如：

  • “近三年各学院招生人数趋势如何？”
  • “本月预算执行率低于 70% 的部门有哪些？”
  • “和去年同期相比，哪个专业的报到率下降最多？”
  • “把结果按学院维度画成柱状图，并解释异常点。”

一个完整的智能问数系统通常包括以下链路：

  1. 用户自然语言输入。
  2. 意图识别和问题改写。
  3. 业务术语、指标、维度、表字段、样例问题召回。
  4. 基于语义层或数据库 schema 生成查询计划。
  5. 生成 SQL 或语义查询。
  6. 权限校验、SQL 安全校验、性能限制。
  7. 执行查询并返回结果。
  8. 自动选择图表和生成自然语言解释。
  9. 支持追问、下钻、归因、同比环比、异常分析。
  10. 记录反馈，持续优化语义和问答样例。

3. 评估维度

维度 关注点 对项目成败的影响
准确率 能否正确理解业务词、指标口径、时间表达和维度关系 决定用户是否敢用
语义层 是否有指标、维度、实体、同义词、口径说明和表关系 决定复杂问题能否稳定回答
权限治理 是否支持行级、列级、数据集级权限以及审计 决定能否在企业内推广
多轮能力 是否能承接上下文、追问、澄清和下钻 决定体验是否像“分析师”
可视化 能否自动选择图表、调整图表并支持导出 决定业务用户接受度
可解释性 是否展示查询逻辑、SQL、口径来源、置信度和引用 决定可信度
数据源 支持关系库、数仓、湖仓、Excel、API、国产库等能力 决定接入成本
部署方式 SaaS、私有化、混合云、本地模型、国产化适配 决定采购和安全可行性
成本 软件授权、模型调用、数仓计算、运维、语义治理人力 决定长期可持续性
可扩展性 是否有 API、SDK、MCP、插件、Agent 工作流 决定能否嵌入现有平台

4. 海外主流商业产品

4.1 Microsoft Power BI Copilot

定位：Microsoft Fabric / Power BI 生态中的生成式 BI 助手，服务业务用户、报表作者和数据模型维护者。

主要能力

  • 在 Power BI 报表中进行问答、总结、洞察解释。
  • 支持根据语义模型生成报表页面、视觉对象和 DAX。
  • 支持面向业务用户的独立 Copilot 体验、报表侧边栏 Copilot、Power BI app 内 Copilot 等形态。
  • 依托 Power BI semantic model 和 Microsoft Fabric 权限体系。

优点

  • 与 Power BI、Fabric、Microsoft 365、Azure 生态结合紧密，适合已经重度使用微软生态的企业。
  • 语义模型、权限、报表订阅、指标和工作区治理比较成熟。
  • 对报表作者有明显生产力提升，尤其是 DAX、摘要、报表搭建和解释。
  • 管理员可统一开关 Copilot，并通过 Fabric 容量管理使用。

缺点

  • 使用门槛和成本较高，需要付费 Fabric capacity 或 Power BI Premium capacity；普通 Pro/PPU 许可证不一定足够。
  • 对数据模型准备要求高，官方也强调需要为 AI 准备 semantic model，否则容易出现泛化、误解或误导性结果。
  • 多语言能力和区域可用性存在限制，非英文场景需要充分验证。
  • 强绑定微软云和 Fabric 体系，私有化、本地模型或国产化场景不友好。

适合场景

  • 企业已经以 Power BI/Fabric 为核心 BI 平台。
  • 需求重点是报表总结、图表生成、DAX 辅助、办公协同。
  • 数据安全和权限已经在 Power BI 体系内治理好。

4.2 Tableau Agent / Tableau AI

定位：Tableau 的生成式分析助手，围绕自然语言建图、探索数据、计算字段生成和解释。

主要能力

  • 在 Tableau authoring 体验中使用自然语言生成可视化。
  • 支持推荐分析问题、选择图表类型、时间序列分析、过滤排序、计算字段创建和解释。
  • 可用于 Tableau Cloud；从 Tableau Server 2025.3 起也支持相关能力。
  • 依托 Einstein Trust Layer，强调不把客户数据用于训练模型。

优点

  • Tableau 的可视化表达能力强，适合从问题快速进入图表探索。
  • 对分析师、报表作者友好，能减少“空白画布”压力。
  • 适合做可视化迭代：先生成图，再人工调整。
  • 在视觉分析和交互探索上仍然是强项。

缺点

  • 更偏“辅助分析和建图”，不是完全开放式企业问数机器人。
  • 对数据源、主数据源、extract/live 连接有边界；复杂 blending、cube 等场景有限制。
  • 企业级语义治理需要依赖 Tableau 体系和前期建模，不能指望模型自动理解所有口径。
  • 价格和生态绑定对中小团队压力较大。

适合场景

  • 已经使用 Tableau 作为核心可视化平台。
  • 分析师希望提高建图、计算字段和探索效率。
  • 业务用户对图表表达要求高，而不是只要一行数字答案。

4.3 ThoughtSpot Spotter

定位：面向业务用户的 AI Analyst / 搜索式分析平台，强调自然语言搜索、可信答案和可视化。

主要能力

  • 用自然语言提问并返回数据答案和图表。
  • Spotter Agent 支持多问题回答、推荐后续问题、解释计算字段。
  • ThoughtSpot 长期强调 Search-driven Analytics，避免直接让 LLM 乱写 SQL，而是把自然语言转成受控的数据问题表达。
  • 支持面向企业业务用户的自助分析和嵌入式分析。

优点

  • 产品定位非常贴近“人人问数”，用户体验成熟。
  • 搜索式分析和语义建模积累深，适合高频业务查询。
  • 强调 trust layer 和 human-in-the-loop，降低纯 Text-to-SQL 幻觉。
  • 嵌入式分析和应用内分析能力较强。

缺点

  • 商业授权成本较高。
  • 上线效果依赖建模、字段命名、业务口径配置和数据准备。
  • 国内私有化、国产数据源和本地大模型适配要单独评估。
  • 对复杂跨域分析，仍需要较强的数据建模和治理。

适合场景

  • 大中型企业希望给业务部门提供“搜索式自助分析”。
  • 数据模型比较清晰，指标体系可治理。
  • 有预算采购成熟商业产品。

4.4 Qlik Insight Advisor / Qlik Answers

定位：Qlik 云分析平台中的增强分析、自然语言问答和 GenAI 助手能力。

主要能力

  • Insight Advisor 支持自然语言问题，自动生成可视化和分析建议。
  • Qlik Answers 提供生成式 AI 助手，可面向结构化和非结构化数据构建问答应用。
  • Qlik 有关联式引擎和业务逻辑层积累，适合探索式分析。
  • 提供自然语言 API，可嵌入应用。

优点

  • Qlik 的关联式分析引擎适合探索数据关系。
  • 同时覆盖 BI 数据和知识文档问答，适合“指标 + 文档解释”的混合场景。
  • 有自然语言 API 和嵌入能力，平台化程度较高。
  • 对治理、业务逻辑层和企业部署有较成熟积累。

缺点

  • 国内生态和人才池不如 Power BI/Tableau/帆软广。
  • 产品体系较多，选型时需要区分 Insight Advisor、Answers、AutoML 等能力边界。
  • 复杂中文业务口径仍需要大量配置。
  • 授权和云服务成本需要评估。

适合场景

  • 已有 Qlik Cloud/Qlik Sense 基础。
  • 同时需要结构化数据分析和非结构化知识问答。
  • 业务希望做探索式关联分析，而不是固定报表。

4.5 Amazon QuickSight Q / Amazon Q in QuickSight

定位：AWS QuickSight 中的自然语言查询和生成式 BI 能力。

主要能力

  • 用户用自然语言询问 QuickSight 数据集，返回答案和可视化。
  • 通过 Topic 组织业务主题，让模型理解数据集、字段、同义词和业务语境。
  • 支持嵌入到应用中，面向业务用户提供问答入口。
  • 与 AWS 数据和权限生态结合。

优点

  • 适合 AWS 用户，和 Redshift、Athena、S3、Glue 等生态结合顺。
  • Topic 机制有利于把问数范围限定在业务主题内，降低歧义。
  • 嵌入式和云端 BI 能力较强。
  • 可与 QuickSight 现有 dashboard/report 复用数据集和权限。

缺点

  • 强绑定 AWS 与 QuickSight，国内本地化和私有化不占优。
  • Topic 配置质量直接影响问答效果，需要业务和数据团队维护。
  • 中文复杂表达、组织内部术语和跨主题问题需要验证。
  • 成本由 BI 授权、查询计算和 AI 能力共同构成。

适合场景

  • AWS 是主要云平台，QuickSight 已经承接 BI。
  • 应用需要嵌入式问数。
  • 数据主题边界清晰，如销售、财务、运营、人力等。

4.6 Google Looker Conversational Analytics

定位：基于 Gemini 和 LookML 语义层的自然语言分析能力。

主要能力

  • 使用自然语言查询 Looker Explore 或 Data Agent。
  • 以 LookML 语义模型作为事实来源，保证指标、关系、权限一致。
  • 可创建面向特定 Explores 的数据代理，支持自定义说明、golden queries、业务词汇表。
  • 支持通过 iframe 嵌入；部分能力支持 Python 代码执行做高级分析。

优点

  • LookML 语义层能力强，适合工程化治理指标和维度。
  • 从语义模型生成查询，而不是直接拼 SQL，可靠性更高。
  • 可通过 data agent 管理上下文，适合多业务域问数。
  • 与 BigQuery / Google Cloud / Gemini 生态自然衔接。

缺点

  • LookML 建模门槛高，对数据团队工程能力要求高。
  • 强绑定 Looker 和 Google Cloud 生态。
  • Gemini 相关合规、区域和数据处理边界要审查。
  • 对没有 Looker 基础的团队，前期建设成本较高。

适合场景

  • 已有 Looker/LookML 语义层，或愿意以代码化方式治理指标。
  • 重视一致口径、可审计和多团队协作。
  • 数据主要在 Google Cloud 或跨云数仓，但愿意用 Looker 做统一语义层。

4.7 Snowflake Cortex Analyst

定位：Snowflake 原生的 LLM-powered 自助分析服务，偏 API-first 的 Text-to-SQL/语义问答能力。

主要能力

  • 业务用户用自然语言询问 Snowflake 中的结构化数据。
  • 通过 REST API 集成到 Streamlit、Slack、Teams、自研聊天界面等。
  • 使用 semantic model / semantic views 描述业务概念、指标、维度、关系和示例查询。
  • SQL 在 Snowflake warehouse 中执行，权限遵守 Snowflake RBAC。
  • 支持多轮对话，但官方也列出对长对话、依赖上轮查询结果等场景的限制。

优点

  • 和 Snowflake 计算、权限、治理边界强结合。
  • API-first，适合把问数能力嵌入自己的系统或数据门户。
  • 语义模型 YAML / Semantic Views 让准确率提升路径比较清晰。
  • 官方托管模型和服务，减少自建 RAG/Text-to-SQL 的工程成本。

缺点

  • 只适合 Snowflake 数据主场景。
  • 本身不是完整 BI 门户，需要自己做前端体验、会话管理、图表和业务流程。
  • 需要维护 semantic model，复杂企业口径不是开箱即准。
  • 费用包含 AI service 和 warehouse 执行成本，要做好限流和审计。

适合场景

  • 数据核心在 Snowflake。
  • 想在现有应用中嵌入“问数据”的 API。
  • 技术团队具备产品化包装能力。

4.8 Databricks Genie

定位：Databricks 湖仓中的 domain-specific 自然语言数据空间。

主要能力

  • Genie Space 是特定业务域的自然语言聊天界面。
  • 用户可获得 SQL、结果表和可视化。
  • 分析师通过 Unity Catalog 数据集、示例 SQL、业务语义表达式和文本说明来策划空间。
  • 支持评测、监控、API、嵌入外部应用、上传 CSV/Excel 与 Unity Catalog 数据混合分析。
  • Genie family 还包括面向更宽入口的 Genie One、面向开发者的 Genie Code 等。

优点

  • 与 Unity Catalog、Lakehouse、权限、血缘和治理结合紧。
  • 适合围绕具体领域建立“问数空间”，例如招生、人事、财务、运营。
  • 能把 SQL、可视化、示例、业务说明和评测组合起来。
  • 对数据工程和高级分析团队友好。

缺点

  • 强绑定 Databricks 平台。
  • 要获得好效果，需要分析师长期策划和调优 Genie Space。
  • 对传统业务用户而言，仍需要产品化包装和场景运营。
  • 成本涉及 Databricks 计算、AI 能力和数据治理投入。

适合场景

  • 已经以 Databricks Lakehouse 为核心数据平台。
  • 数据团队希望把已治理的数据域开放给业务自助探索。
  • 问数项目需要和数据工程、机器学习、湖仓治理打通。

4.9 Domo AI Chat、Sigma Assistant、Sisense、Zoho Zia

这些产品可作为补充了解：

  • Domo AI Chat：强调自然语言探索数据、推荐下一步动作和治理上下文，适合已有 Domo 平台用户。
  • Sigma Assistant：以云数仓 spreadsheet-like 分析体验为基础，支持自然语言生成图表、信息抽取和迭代分析，适合数据团队和业务分析师共同使用。
  • Sisense AI：偏嵌入式分析和产品内 AI 分析能力，适合 SaaS 产品把分析能力嵌进应用。
  • Zoho Analytics Zia：面向中小企业和 Zoho 生态，提供自然语言问答、洞察和自动分析，成本相对友好。

这些产品的共同特点是：在各自 BI 平台内体验较好，但跨平台、深度二开、私有化和中文复杂业务场景通常需要单独验证。

5. 国内常见商业产品

5.1 阿里云 Quick BI 小Q问数

定位：阿里云 Quick BI 的智能数据助手和 ChatBI 能力。

主要能力

  • 用户通过 PC 或移动端以自然语言提问，直接获取数据结果。
  • 支持数据集选择、快捷提问、多轮对话、历史对话。
  • 支持仪表板小Q问数，在仪表板预览界面通过自然语言获取结果。
  • 可结合 Quick BI 数据集、权限和嵌入能力。

优点

  • 与阿里云、Quick BI、钉钉/企业应用生态衔接较自然。
  • 中文产品体验、国内交付和本地支持较好。
  • 适合已使用 Quick BI 的企业快速开通智能问数。
  • 支持 PC 和移动端，便于会议、经营看板和移动办公。

缺点

  • 属于增值模块，需要额外购买和席位分配。
  • 功能可用区域、嵌入方式和版本有条件限制。
  • 强绑定 Quick BI 数据集和阿里云产品体系。
  • 如果底层指标口径和数据集治理不足，问数效果仍会受限。

适合场景

  • 企业已经使用 Quick BI。
  • 需要快速让业务人员通过中文提问看数据。
  • 业务系统希望嵌入 Quick BI 看板和部分问数能力。

5.2 帆软 FineBI / FineChatBI

定位：帆软 FineBI 体系中的企业级对话式分析能力，强调可信查数和降低数据消费门槛。

主要能力

  • FineChatBI 支持通过对话实现数据查询和业务分析。
  • 有智能模式和极速模式：智能模式强调问题改写、分析过程和核心结论；极速模式强调响应速度。
  • 结合 FineBI 数据分析底座、数据门户、报表、权限和企业级能力。
  • 面向老板、数据分析师、一线业务等角色。

优点

  • 帆软在国内企业、政企、制造、财务报表和中国式报表场景积累深。
  • 私有化交付、中文服务、权限和复杂报表能力强。
  • 适合已有 FineBI/FineReport/FineDataLink 等帆软生态客户。
  • 对“可信查数”和企业交付的叙事比较清晰。

缺点

  • 商业闭源产品，二开和底层算法可控性有限。
  • 问数效果高度依赖已治理的数据模型、指标和业务术语。
  • 如果希望做自研智能体平台，帆软更多是成品能力而非底层框架。
  • 授权和服务成本要按企业规模评估。

适合场景

  • 已经使用帆软体系做报表、BI 或数据门户。
  • 国内政企、制造、财务、人力等需要私有化交付的场景。
  • 业务诉求偏“可靠查数 + 报表闭环”，而不是高度自研。

5.3 Smartbi AIChat / 白泽 ChatBI

定位：Smartbi 的 AI + BI 能力，覆盖智能问数、复杂计算、图表生成、数据解读和多轮对话。

主要能力

  • 支持灵活问数、上下文追问、歧义澄清、下钻引导。
  • 支持同环比、期初期末、累计值等复杂计算。
  • 自动生成图表并支持展示方式切换。
  • 对外宣称在特定场景中可达到较高准确率。

优点

  • 国内 BI 厂商，企业级部署和国产化适配经验较多。
  • 比纯 Text-to-SQL 更重视复杂指标计算和业务解释。
  • 适合金融、政务、电信等对私有化、权限和审计要求高的行业。
  • 产品表达上已经从 ChatBI 向 AgentBI / 分析智能体扩展。

缺点

  • 商业闭源，技术路线、模型选择和评测细节不可完全掌控。
  • 准确率宣传通常依赖特定业务域和数据准备，不能简单外推到所有场景。
  • 需要购买和实施，前期数据治理工作不可省。
  • 与现有非 Smartbi 平台集成深度要单独评估。

适合场景

  • 企业已有 Smartbi 或希望采购国产 BI + 智能问数一体方案。
  • 业务问题包含大量同环比、累计、复杂指标口径。
  • 对私有化、国产化、权限审计有较强要求。

5.4 观远问数 Agent / 观远 ChatBI

定位：基于 LLM 的场景化问答式 BI，强调意图识别、知识召回、问题理解、数据查询、可视化生成和洞察报告。

主要能力

  • 自然语言提问，获取数据分析结果。
  • 提供数据问答、洞察分析、图表生成和行动建议。
  • 面向企业中高层分析报告、一线业务探索、数据团队知识沉淀等场景。
  • 强调统一数据口径和可信数据源。

优点

  • 场景化包装较强，适合零售、消费、连锁、经营分析等业务场景。
  • 既关注“取数”，也关注“洞察报告和行动建议”。
  • 对企业中高层临时追问、经营会议场景比较贴近。
  • 国内交付和中文业务术语支持较好。

缺点

  • 商业闭源，底层可控性和二开空间有限。
  • 效果依赖业务场景沉淀、指标体系和知识库维护。
  • 如果企业数据模型分散、口径混乱，上线初期需要较多整理工作。
  • 与非观远 BI 体系的集成深度需要验证。

适合场景

  • 零售、消费、供应链、经营管理类企业。
  • 希望从“看板”升级到“经营问答 + 洞察报告”。
  • 有明确业务域和高频问数场景。

5.5 衡石 HENGSHI Data Agent / Text2Metrics

定位：企业级 AI + BI / Agentic BI 平台，强调从 Text2SQL 转向 Text2Metrics，用指标语义层支撑可信问数。

主要能力

  • 覆盖问数、建模、报表创作与智能报告等 Agentic BI 流程。
  • Text2Metrics 技术路线：让自然语言先映射到受治理的指标、维度和度量，而不是直接生成任意 SQL。
  • 面向 ISV 嵌入、企业级 BI、指标管理、数据集成和报表。

优点

  • 技术路线值得关注：用指标语义层约束查询，降低幻觉。
  • 对嵌入式 BI、多租户 SaaS、ISV 场景友好。
  • 强调指标管理和 Agentic Analytics，贴近未来趋势。
  • 适合已有指标体系或希望建设统一指标平台的企业。

缺点

  • 商业产品，底层实现和评测细节需要商务/POC 验证。
  • Text2Metrics 的前提是指标体系要建设好，前期治理成本不低。
  • 对简单临时查表类需求，完整语义层路线可能显得较重。
  • 国内市场认知度相对帆软、阿里等头部产品低一些。

适合场景

  • 企业已经重视指标中台、统一口径和嵌入式 BI。
  • SaaS/ISV 需要把智能分析能力嵌入业务系统。
  • 项目目标是“可信指标问数”，不是任意 SQL 探索。

5.6 网易知数 / 有数 ChatBI

定位：网易 BI 引擎经验上的数据分析智能体，强调指标体系、知识库和企业职能/业务线问数。

主要能力

  • 面向企业各职能和业务线构建指标体系与知识库。
  • 提供自然语言数据分析、ChatBI 和智能数据助手能力。
  • 依托网易内部数据实践经验。

优点

  • 有互联网大厂内部数据分析经验沉淀。
  • 强调指标体系和知识库运营，方向正确。
  • 适合希望借鉴互联网运营分析实践的企业。

缺点

  • 市场公开资料相对少，产品边界和实施方式需要实地 POC。
  • 对非网易生态客户，交付、集成和行业适配要验证。
  • 如果只是采购一个轻量问数插件，可能不是最轻方案。

适合场景

  • 互联网、内容、运营、增长类场景。
  • 需要围绕指标体系和知识库建设数据智能体。
  • 有预算做定制化实施和长期运营。

5.7 永洪科技、亿信华辰等

永洪科技：公开资料中强调 Megrez 天权智能问数平台、自然语言对话式分析、指标体系问数、专用知识库和权限控制。优势在国产 BI 和行业项目经验；短板是公开技术细节有限，需要 POC 验证准确率、权限、可解释性和集成能力。

亿信华辰：强调基于 LLM 与 BI 引擎深度融合的新一代数据智能平台，支持自然语言查询、分析、洞察与报告生成。优势在政企、统计、数据治理、BI 工具链经验；短板同样是商业闭源，需要验证项目落地成本和模型适配。

这类厂商适合在政企、信创、行业大数据平台项目中纳入候选，但不建议只看宣传页，需要用本单位真实数据集做测试集评测。

6. 开源与自建方案

6.1 SQLBot

定位：DataEase 开源项目组推出的基于大模型和 RAG 的智能问数系统。

主要能力

  • 支持对话式数据分析 ChatBI。
  • 通过 RAG 提升 Text-to-SQL 效果。
  • 可生成数据结果和可视化图表，并支持进一步智能分析。
  • 官网强调开箱即用、易集成、安全可控、越问越准。

优点

  • 中文开源项目，定位和国内智能问数需求高度一致。
  • 相比从零搭建，能较快跑通数据源接入、对话、SQL、图表闭环。
  • 社区关注度较高，适合做 PoC 和二开参考。
  • 和 DataEase / FIT2CLOUD 生态有潜在协同。

缺点

  • 许可证是修改版 GPLv3，带有额外条件；商用、二开、去标识需谨慎评估。
  • 企业级权限、审计、评测、指标治理仍需项目化增强。
  • 适合快速验证，但要成为核心生产系统，需要补齐运维和治理。

适合场景

  • 中文智能问数 PoC。
  • 希望快速有一个可演示、可自建的 ChatBI 系统。
  • 数据源和业务域相对清晰，团队愿意二开。

6.2 SuperSonic

定位：腾讯音乐开源的 AI + BI 平台，统一 ChatBI 和 Headless BI。

主要能力

  • 内置 ChatBI 界面，业务用户可自然语言查询和图表展示。
  • 内置 Headless BI 界面，用于构建指标、维度、标签及关系等语义模型。
  • Text2SQL 通过语义模型上下文增强。
  • 支持自动补全、多轮对话、查询后推荐、数据集/列/行三级权限。

优点

  • 技术路线很有参考价值：让 ChatBI 使用和传统 BI 相同的治理语义模型。
  • 不把复杂 join、公式完全交给大模型，而由语义层承担一部分复杂性。
  • 权限和语义模型设计更贴近真实企业场景。
  • 适合研究“语义层 + ChatBI”的工程实现。

缺点

  • 许可证是带附加条件的 Apache 2.0，衍生商业分发需联系授权。
  • 技术栈相对重，二开和部署成本高于轻量项目。
  • 最新 release 节奏和社区活跃度需要持续观察。
  • 如果只是做轻量问数 Demo，可能显得复杂。

适合场景

  • 目标是做企业级、可信口径、语义层驱动的问数。
  • 团队有 Java/TypeScript/数据建模能力。
  • 希望参考成熟的 ChatBI + Headless BI 架构。

6.3 WrenAI

定位：面向 AI Agent 的开源 GenBI 引擎和开放上下文层。

主要能力

  • 让 AI Agent 基于业务语义、定义、示例、记忆和治理生成 SQL、图表和可部署 dashboard。
  • 支持 20+ 数据源，使用 MDL 描述模型、列、关系、视图、指标、行列级权限等。
  • 核心、SDK、skills 和上下文文件更偏工程化、版本化、Agent-friendly。
  • 2026 年 README 显示旧版 Docker chat-first BI app 已保留在 legacy/v1，当前重点转向 open GenBI engine。

优点

  • 架构先进，适合 Agentic BI 和“智能体调用数据上下文”的方向。
  • 业务上下文可版本管理，利于审查和协作。
  • 不局限于一个聊天界面，更适合作为自研平台底层。
  • 支持仪表板生成和部署，有未来感。

缺点

  • 对只想买一个可用产品的团队不够直接。
  • 当前定位从传统 ChatBI app 转向 Agent engine，需要理解新架构。
  • 企业要自己包装用户界面、权限体系和运营流程。
  • 许可证结构中包含多类许可，实际商用需逐项确认。

适合场景

  • 自研数据智能体或 AI 平台，需要给 Agent 提供可信数据上下文。
  • 团队有工程能力，想掌握底层架构。
  • 项目目标不只是“问一句 SQL”，还包括自动生成 dashboard 和可复用上下文。

6.4 DB-GPT

定位：开源 Agentic AI Data Assistant，面向 AI + Data 产品构建。

主要能力

  • 连接数据库、CSV/Excel、数仓、知识库。
  • 自然语言提问，由 AI 自动写 SQL。
  • 支持 Python 和代码驱动分析流程。
  • 支持技能、RAG、多模型、沙箱执行、图表、dashboard、HTML 报告和分析摘要。

优点

  • 能力范围很宽，适合做“数据助手”而不只是“问数”。
  • Agent 工作流、技能、代码执行和报告生成能力较强。
  • MIT 许可证相对友好。
  • 社区关注度较高，适合做二开和平台化探索。

缺点

  • 功能面宽意味着系统复杂度高，落地需要做场景收敛。
  • 对企业级权限、指标口径、生产稳定性仍需二次工程。
  • 如果只做 ChatBI，可能需要裁剪很多能力。
  • 代码执行和沙箱分析要严格做安全控制。

适合场景

  • 希望做“数据分析 Agent”，包括 SQL、Python 分析、报告生成。
  • 研发团队愿意基于开源框架二开。
  • 数据分析任务不是固定问答，而是多步探索。

6.5 QueryWeaver

定位：基于图结构 schema 理解的开源 Text2SQL 工具。

主要能力

  • 把自然语言问题转换为 SQL，并返回 SQL 和结果。
  • 使用 graph-powered schema understanding 处理数据库表关系。
  • 提供 REST API、MCP 和前端。
  • Docker 方式便于试用。

优点

  • 技术点集中，适合研究复杂 schema 下的 Text2SQL。
  • REST API/MCP 适合接入 Agent 或自研应用。
  • 图结构理解对多表关系可能有帮助。

缺点

  • AGPL-3.0 许可证，闭源商用集成要谨慎。
  • 不是完整企业 BI 产品，权限、指标、报表、运营需自建。
  • 社区规模较小，长期维护和生产稳定性需观察。

适合场景

  • 技术预研、Text2SQL 引擎实验。
  • 多表关系复杂，希望引入图 schema 理解。
  • 可接受 AGPL 或只做内部研究。

6.6 OpenChatBI、Dataherald、Chat2DB、SQLChat、PandasAI

项目 定位 优点 局限
OpenChatBI LangGraph/LangChain 架构的轻量 ChatBI 适合学习 Agent 工作流、可视化和问数链路 社区较小，生产成熟度有限
Dataherald NL2SQL API/企业问数框架 API 思路清晰，Apache-2.0 最新活跃度偏弱，需要评估维护状态
Chat2DB AI 数据库客户端 支持大量数据库，适合开发/DBA/分析师 更像 SQL 客户端，不适合直接面向业务用户
SQLChat Chat-based SQL client 简单直观，适合个人或小团队 企业治理、权限、语义层弱
PandasAI 面向 DataFrame/CSV/SQL/Parquet 的对话式分析 适合 Notebook、文件分析和数据科学 非企业 BI 门户，治理和多用户能力弱

7. 横向对比

7.1 产品成熟度与可控性

类型 代表产品 成熟度 可控性 适合程度
国际商业 BI Power BI、Tableau、ThoughtSpot、Qlik 高 低-中 适合已有对应生态的企业
云数仓原生 Snowflake Cortex Analyst、Databricks Genie、Looker、QuickSight 中-高 中 适合云数仓/湖仓平台已有基础
国内商业 BI Quick BI、FineBI、Smartbi、观远、衡石、网易知数 中-高 中 适合中文、私有化、政企和国内交付
开源 ChatBI SQLBot、SuperSonic、WrenAI、DB-GPT 中 高 适合自研、PoC、可控化改造
AI 数据库客户端 Chat2DB、SQLChat、PandasAI 中 中-高 适合技术人员，不适合大规模业务自助

7.2 关键能力对比

产品 语义层 问数体验 图表 多轮 权限 二开 私有化/自建 主要短板
Power BI Copilot 强 强 强 中 强 中 弱 绑定微软生态，容量成本高
Tableau Agent 中-强 中-强 很强 中 强 中 中 更偏建图辅助，不是开放问数机器人
ThoughtSpot Spotter 强 很强 强 强 强 中 中 商业成本高，需建模
Looker Conversational Analytics 很强 强 中-强 强 强 中 弱-中 LookML 门槛高
Snowflake Cortex Analyst 强 中 弱-中 中 强 强 弱 API 能力强，但需自建前端体验
Databricks Genie 强 强 中 强 强 中 弱 绑定 Databricks，需策划 Space
Quick BI 小Q 中-强 强 强 中 强 中 中 增值模块，绑定 Quick BI
FineChatBI 强 强 强 中-强 强 中 强 商业闭源，二开有限
Smartbi AIChat 强 强 强 强 强 中 强 准确率需 POC 验证
观远问数 Agent 强 强 强 强 强 中 强 依赖场景沉淀和知识治理
衡石 Data Agent 很强 强 强 强 强 中 强 前期指标体系建设成本较高
SQLBot 中 中-强 中 中 中 强 强 许可证和企业级治理需注意
SuperSonic 强 中-强 中 中 强 强 强 技术栈较重，许可证有附加条件
WrenAI 很强 中 中-强 中 中-强 很强 强 更偏 Agent 引擎，需自建产品体验
DB-GPT 中 中 中-强 强 中 强 强 能力宽泛，需要收敛和治理
QueryWeaver 中 中 弱-中 中 弱-中 强 强 AGPL，非完整 BI 产品

8. 智能问数落地的共性难点

8.1 准确率不是模型一个问题

智能问数的准确率通常由以下因素共同决定：

  • 表名、字段名是否清晰。
  • 是否有业务口径说明。
  • 指标是否统一定义。
  • 时间、组织、部门、人员等维度是否标准化。
  • 多表关系是否明确。
  • 是否有高质量样例问题和标准 SQL。
  • 业务同义词是否维护。
  • 权限和脱敏规则是否影响查询结果。

只换更强的大模型，不能根治口径混乱和数据治理不足。

8.2 纯 Text-to-SQL 风险高

如果只把数据库 schema 塞给大模型，让它直接生成 SQL，常见问题包括：

  • 编造不存在的字段或表。
  • 选错指标口径。
  • join 关系错误。
  • 聚合粒度错误。
  • 时间范围理解错误。
  • 把“学年”“自然年”“财年”等混用。
  • 权限绕过风险。
  • 查询过重拖垮数据库。

更稳的路线是：自然语言 → 语义层/指标层 → 查询计划 → SQL。

8.3 用户真正需要的是“可信回答”

业务用户不只关心结果，还会关心：

  • 这个数从哪张表来？
  • 指标口径是什么？
  • 为什么和报表上的数不一样？
  • 是否包含本月未审核数据？
  • 是否按我的权限过滤？
  • 这个趋势是不是异常？
  • 能不能导出或生成报告？

因此产品必须提供口径来源、SQL/查询逻辑、数据更新时间、权限说明、异常解释和追问建议。

8.4 问数需要运营

智能问数不是一次性上线的软件，而是一个持续运营系统：

  • 收集高频问题。
  • 标注标准答案和标准 SQL。
  • 补充同义词和业务词汇。
  • 维护指标口径。
  • 修复回答失败案例。
  • 定期做回归测试。
  • 分析用户行为，优化推荐问题。

9. 对自研项目的建议

9.1 推荐总体架构

建议采用“语义层 + RAG + 受控 SQL 生成 + 评测闭环”的架构：

  1. 数据连接层：接入 Hive、MySQL、PostgreSQL、ClickHouse、Oracle、API、Excel 等。
  2. 元数据层：同步库表、字段、注释、样例值、血缘、数据更新时间。
  3. 业务语义层：维护指标、维度、实体、同义词、口径、计算公式、适用范围。
  4. 知识检索层：召回相关表、字段、指标、样例问题、文档说明。
  5. 问题理解层：识别意图、时间、对象、过滤条件、聚合方式、排序方式。
  6. 查询生成层：优先生成语义查询计划，再转换为 SQL。
  7. 安全执行层：SQL 白名单、只读限制、超时、limit、权限过滤、脱敏。
  8. 结果表达层：表格、图表、自然语言解释、口径引用、查询逻辑。
  9. 对话分析层：支持追问、下钻、同比环比、异常解释、报告生成。
  10. 评测运营层：标准问题集、自动评测、用户反馈、失败案例修复。

9.2 MVP 范围建议

第一阶段不要追求“什么都能问”，建议选择一个业务域，例如：

  • 招生就业数据问数。
  • 财务预算执行问数。
  • 人事师资数据问数。
  • 教学科研指标问数。
  • 学生画像与学工数据问数。

MVP 只做 30-50 个高频问题，把准确率、可解释性和权限跑稳。上线后再扩展到更多表和更多部门。

9.3 必须建设的基础资产

资产 示例
指标库 招生人数、报到率、就业率、预算执行率、师生比
维度库 学院、专业、年级、学年、部门、项目类型
同义词库 “学生数/在校生人数/在读人数”，“学院/院系/部门”
样例问题库 “近三年各学院招生人数趋势”及其标准 SQL
口径说明 “就业率是否包含升学”，“预算执行率计算公式”
权限规则 院系用户只能看本院，财务敏感字段脱敏
评测集 高频问题、边界问题、歧义问题、权限问题

9.4 技术路线建议

如果目标是快速演示：

  • 可参考 SQLBot 或 DB-GPT，快速完成数据库接入、问答、图表和报告闭环。
  • 用 DeepSeek、Qwen、GLM、OpenAI、Claude 等模型做可替换模型层。

如果目标是企业生产：

  • 参考 SuperSonic / Looker / Snowflake / Databricks 的思路，优先建设语义层。
  • SQL 生成不直接面向物理表，而是面向指标、维度和业务实体。
  • 必须建立自动评测和人工反馈流程。

如果目标是数据智能体平台：

  • 参考 WrenAI / DB-GPT，把问数能力做成可被 Agent 调用的工具。
  • 提供 MCP/API，让工作流、报告生成、门户和办公助手都能复用。

9.5 推荐产品参考组合

目标 可参考产品
中文开源快速 PoC SQLBot、DB-GPT、OpenChatBI
语义层驱动 ChatBI SuperSonic、Looker、Snowflake Cortex Analyst、衡石 Text2Metrics
Agentic BI WrenAI、Databricks Genie、DB-GPT、ThoughtSpot Spotter
企业级商业采购 FineChatBI、Quick BI 小Q、Smartbi AIChat、观远问数 Agent
云数仓内建能力 Snowflake Cortex Analyst、Databricks Genie、Amazon QuickSight Q、Looker Conversational Analytics

10. 总结

  1. 智能问数不是简单的“AI 写 SQL”，而是 BI 消费方式升级。
  2. 市场上产品分四类：商业 BI、云数据平台、国内厂商、开源自建。
  3. 头部产品共同趋势：从 NLQ/Text-to-SQL 转向语义层、Agent、可信治理。
  4. 国内产品更重视中文、私有化、权限、报表闭环和业务交付。
  5. 开源产品适合自研和验证，但要补齐权限、语义、评测和运维。
  6. 自己做项目时，先选一个业务域，用高频问题集把准确率跑出来。
  7. 项目成败关键不是模型，而是指标口径、元数据、权限和持续运营。

11. 可落地的项目路线图

阶段一：PoC 验证（2-4 周）

  • 选择一个业务域和 5-10 张核心表。
  • 整理 30-50 个高频问题。
  • 建立指标、维度、同义词和样例 SQL。
  • 跑通自然语言问数、SQL 生成、结果展示、图表生成。
  • 计算准确率、可用率、平均响应时间。

阶段二：试点上线（1-2 个月）

  • 加入用户权限和只读 SQL 安全限制。
  • 支持多轮追问、同比环比、排序、过滤、图表切换。
  • 增加口径引用、SQL 展示、数据更新时间。
  • 接入业务门户或 IM/办公入口。
  • 建立用户反馈和失败案例修复流程。

阶段三：规模化推广（3-6 个月）

  • 扩展到多个业务域。
  • 建立统一指标和数据目录。
  • 做自动评测、回归测试、日志审计。
  • 支持报告生成、智能订阅、异常预警。
  • 将问数能力封装成 API/MCP，供其他智能体调用。

12. 主要参考资料