智能问数测试调研
一、 文档概述
测试背景与目的
随着大语言模型在企业数据分析场景中的应用逐渐成熟，“智能问数（Text-to-SQL）”类工具开始被广泛关注。这类工具试图通过自然语言交互的方式，降低业务人员访问和分析数据的门槛，并在一定程度上提升数据分析效率。
本次测试以开源项目SQLBot为研究对象，通过实际部署和功能验证，评估其在真实数据场景下的可用性、稳定性以及能力边界。测试重点并非验证模型理论性能，而是从“是否好用、是否可落地”的角度出发，分析其在实际业务环境中的应用价值与局限性，为后续选型或二次开发提供参考依据。
被测试工具简介
SQLBot 是一个开源的“智能问数”系统，其核心能力是将用户的自然语言问题自动转换为可执行的 SQL 语句，并对数据库进行查询，最终以表格或图表的形式返回结果。从产品定位上看，SQLBot 属于典型的 Chat-BI（对话式商业智能）工具，面向不熟悉 SQL 的业务用户，也可作为 BI 系统或企业内部平台中的智能查询组件。
在技术实现上，SQLBot 并非完全依赖大模型端到端生成 SQL，而是结合了检索增强生成（RAG）机制，对数据表结构、字段描述、业务术语以及 SQL 示例进行检索，再将相关上下文提供给大模型，从而提升 SQL 生成的准确性与可控性。
测试范围与不包含内容
本次测试主要围绕 SQLBot 的核心问数能力和工程可用性展开，测试范围包括：
工具的安装与部署体验
不同类型数据源与数据集的接入情况
自然语言转 SQL 的基本能力与稳定性
常见查询场景下的图表展示效果
多表查询、数据量限制及 token 消耗相关表现
产品在复杂分析场景下的能力边界
需要说明的是，本次测试不包含以下内容：
对底层大语言模型本身性能的系统性评测
大规模并发或生产级性能压测
深度定制化开发或源码级改造分析
测试结论仅基于当前版本 SQLBot 在默认或轻度配置条件下的实际表现。
适用读者
本文档主要面向以下读者群体：
业务人员 / 数据使用方：希望通过自然语言直接获取数据，对 SQL 不熟悉，但关注工具是否“好用、直观”。
技术人员 / 数据工程师：关注系统部署成本、数据接入方式、多表查询能力以及潜在的工程限制。
产品经理 / 技术决策者：关注 SQLBot 的整体定位、能力边界及其在企业数据分析体系中的适用场景。
二、工具与测试环境说明
测试部署环境
本次测试采用WSL（Windows Subsystem for Linux）+ Docker的方式部署 SQLBot，并通过Windows 本地浏览器进行访问和使用。这种部署方式在保证 Linux 运行环境一致性的同时，也兼顾了 Windows 桌面环境下的使用便利性，较符合实际开发与测试场景。
具体环境说明如下：
操作系统：Windows10（本地桌面环境）
Linux 子系统：WSL2
Linux 发行版：Ubuntu 20.04
容器环境：Docker Desktop（启用 WSL 集成）
需要说明的是，官方文档中建议使用 Ubuntu 22.04 及以上版本，但在本次测试中，Ubuntu 20.04 环境下 SQLBot 仍可正常部署和运行，未出现因系统版本导致的兼容性问题。
部署方式说明
SQLBot 通过官方 GitHub 提供的命令行方式进行部署。测试过程中未对源码进行修改，也未引入额外的自定义组件，整体部署流程遵循官方推荐路径。
部署流程可概括为：
在 Windows 系统中安装 Docker Desktop，并在安装过程中启用 WSL 相关选项
进入 WSL2 环境（Ubuntu）
按照官方文档，通过命令行方式一键启动 SQLBot 服务
整体安装和启动过程较为顺畅，未出现报错或需要额外排查的问题，部署成本相对较低。
访问方式与使用形态
SQLBot 服务启动后，通过Windows 本地浏览器进行访问和操作。测试中直接在浏览器地址栏输入：
http://localhost:8000即可访问 SQLBot 提供的 Web 界面。
这种“后端运行在 WSL，前端通过 Windows 浏览器访问”的使用方式，对用户而言几乎无感知额外成本，既保留了 Linux 环境的稳定性，也符合 Windows 用户的日常操作习惯。
大模型与外部依赖说明
在实际使用 SQLBot 进行智能问数时，需要配置大语言模型的 API 接口。本次测试中使用的是第三方大模型服务（如 DeepSeek），该部分属于外部依赖，需单独配置，并涉及一定的使用成本。
需要强调的是，SQLBot 本身并不内置大模型，而是作为上层应用框架，通过调用外部大模型能力完成自然语言理解和 SQL 生成。
三、 SQLBot介绍
官方文档：https://sqlbot.org/docs/v1/
GitHub链接：https://github.com/dataease/SQLBot
官网：https://sqlbot.org/
教学视频：https://www.bilibili.com/video/BV1SBtizgED4/
SQLBot 是什么
SQLBot 是一个“智能问数”（自然语言 → SQL）系统 —— 即用户可以使用自然语言对数据库提出问题，系统通过大语言模型 + 检索增强生成 (RAG) 技术，将自然语言问题转换为 SQL 查询并执行。
它本质上为“Chat-BI”（对话式商业智能 / 数据分析）工具，使得即便不熟悉 SQL 语法，也能通过普通语言快速获取数据、生成表格或图表。
核心能力与特性
SQLBot 的关键功能和优势可归纳为以下几点：
开箱即用：只需简单配置 —— 指定大语言模型 (LLM) 与所连接的数据源 (数据库或文件) —— 即可启动使用，无需复杂开发或编码。
Text-to-SQL + RAG：结合自然语言理解与 RAG 技术，将自然语言问题转化为结构化 SQL 查询，使查询更准确、可执行。
数据源支持多样：兼容多种类型数据源 —— 包括主流关系型数据库 (如 MySQL, PostgreSQL, Oracle, SQL Server 等)，也支持 OLAP/数据仓库、数据湖、文件 (Excel / CSV) 等。
易于集成 / 嵌入：除了作为独立系统使用，也支持嵌入到第三方业务系统或其它平台 (例如 AI 平台、BI 工具等)，支持 Web 嵌入、弹窗嵌入、MCP 调用等多种方式。
安全与权限控制：设计有“工作空间 (workspace)”级资源隔离机制，支持细粒度的数据权限配置，从而保障数据访问的安全性与合规性。
持续优化 (“越问越准”)：支持自定义提示词 (prompt) 和术语库 (terminology) 配置，也可以通过维护 SQL 示例 (示例查询) 来校准系统在特定业务 / 语义上的问数质量；随着使用和反馈积累，系统表现可持续优化。
适用场景
SQLBot 的定位和使用场合包括但不限于：
对业务人员／非专业数据分析人员开放数据库查询 —— 用户无需了解 SQL，即可“问出”所需数据。
集成到 BI 平台 / 企业内部系统中，作为智能问数 / 数据分析组件。
数据可视化与报告生成 —— 将结果直接转为表格 / 图表 /仪表板 (dashboard)，便于汇报或决策支持。
教育与培训用途 —— 帮助学习数据库 / 数据分析 / SQL 查询的人，用自然语言理解与 SQL 之间的对应关系。
技术架构
根据公开资料，SQLBot 的架构与实现具有以下特征：
后端基于现代 Web API (例如 Python + FastAPI) 构建。
前端可能使用现代前端框架 (如 Vue + TypeScript) 实现。
系统模块化设计 —— 后端包含多个子模块 (数据源管理、聊天 / 问答模块、模板 / 术语管理、权限系统等)，便于扩展和维护。
支持通过 RAG + 向量检索 (vector-based retrieval) 来增强自然语言到 SQL 的映射准确性 (特别适合大 schema /复杂数据库) 。
该开源工具整体安装过程较为顺畅，未出现报错情况。本次测试通过 GitHub 提供的命令行方式进行一键安装，部署成本较低。
实际部署环境为 WSL2。只需在 Windows 系统中提前安装 Docker Desktop，并在安装过程中启用与 WSL 相关的配置选项，随后进入 WSL 环境执行官方提供的启动命令即可完成部署。
虽然官方文档中建议使用 Ubuntu 22.04 及以上版本，但本次测试使用的是 Ubuntu 20.04，实际部署和运行过程均未受到影响，系统能够正常启动。
部署完成后，返回 Windows 系统，通过浏览器访问http://localhost:8000即可进入 SQLBot 的 Web 界面。
四、 测试数据和数据源说明
测试数据集概述（Building Data Genome Project 2）
本次测试选用Building Data Genome Project 2（BDG2）作为主要测试数据集。BDG2 是一个在建筑能耗分析和时间序列研究领域被广泛使用的开源数据集，最早发布于Scientific Data（Nature 子刊），并曾作为 ASHRAE Great Energy Predictor III（GEPIII）竞赛的核心数据基础。
该数据集覆盖1,636 栋非住宅建筑、3,053 个能耗与水务计量表，数据时间跨度为2016–2017 两个完整年度，时间粒度为小时级（hourly），总体数据规模约5,000 万条以上时间序列记录。从数据复杂度、规模和结构多样性来看，BDG2 非常适合作为智能问数（Text-to-SQL）系统的综合测试样本。
- kaggle官网
https://www.kaggle.com/datasets/claytonmiller/buildingdatagenomeproject2/data
数据内容与结构复杂性说明
BDG2 数据集并非单一表结构，而是由多类高度异构的数据表共同组成，主要包括：
建筑元数据表（Metadata）
包含建筑唯一标识、所属站点、建筑用途类型、建筑面积、时区、行业类别等信息。该表是连接各类时间序列数据的核心维表。能耗与水务计量数据（Meter Data）
按计量类型拆分为多张表，例如：electricity（电力）
chilledwater（冷冻水）
hotwater（热水）
steam（蒸汽）
gas（燃气）
water / irrigation（水与灌溉）
solar（太阳能）
每类计量数据均为建筑 × 时间的小时级时间序列，不同建筑所拥有的计量类型并不完全一致。
气象数据表（Weather Data）
与建筑站点关联的小时级气象信息，包括气温、湿度、风速、气压等，用于描述外部环境对能耗的影响。
从数据库视角来看，该数据集呈现出以下显著特征：
表数量较多，且存在明显的多表关联关系
主键、外键语义依赖于业务理解，而非显式数据库约束
字段命名偏学术 / 工程风格，不直接对应自然语言表达
时间序列表数据量大，且查询通常涉及聚合、过滤和分组操作
这些特性使 BDG2 成为检验 SQLBot 在复杂真实数据场景下表现的合适选择。
数据库落库方式（MySQL）
为便于 SQLBot 进行统一管理和查询，本次测试中将 BDG2 原始数据整理后导入至 MySQL 数据库中，并以关系型数据库的方式进行管理。
具体做法包括：
将原始 CSV 文件拆分并导入为多张 MySQL 表
明确建筑元数据表作为核心维表
各类计量数据表通过建筑标识与元数据表进行逻辑关联
保留时间字段为标准时间戳格式，支持时间范围查询与聚合
该方式能够较真实地模拟企业内部常见的数据仓库或业务数据库结构，同时也更符合 SQLBot 当前对关系型数据库的支持方式。
SQLBot 数据源连接方式
在数据完成 MySQL 落库后，通过 SQLBot 提供的数据源管理功能，将该 MySQL 数据库作为统一数据源接入系统。SQLBot 能够自动识别数据库中的表结构和字段信息，并在后续问数过程中基于这些结构生成 SQL 查询。
由于 BDG2 数据表数量较多，为了控制上下文规模和 token 消耗，在测试过程中对部分与当前测试目标无关的数据表进行了隐藏或未启用配置。这一操作在实际测试中对提升问数稳定性具有明显帮助，也更贴近真实生产环境中的使用方式。
数据复杂性对测试的影响说明
需要强调的是，BDG2 数据集的复杂性并非测试噪声，而是本次测试的重要组成部分：
多表结构用于验证 SQLBot 在复杂 schema 下的理解能力
异构计量数据用于测试字段歧义和语义映射问题
大规模时间序列用于检验聚合查询和性能边界
因此，后续测试结果（包括成功案例与失败场景）均应结合该数据集本身的复杂度进行理解，而不应简单等同于在单表或简化数据集上的问数效果。
五、 SQLBot核心功能测试
隐藏无关表，节省token
SQLBot 支持对数据源中的表进行隐藏配置，在问数过程中仅向大模型提供与当前问题相关的数据表信息。通过隐藏无关表，可以有效减少上下文中的 schema 规模，从而降低 token 消耗，并在实际测试中对响应速度和稳定性均有一定提升。
在多表、复杂数据集场景下，该机制有助于控制模型输入规模，是提升系统可用性的重要工程手段。
术语别名与语义配置能力
在实际业务场景中，数据库中的表名和字段名通常偏技术化，而业务用户更倾向于使用口语化、业务语义明确的表达方式进行提问。SQLBot 支持为字段配置别名和描述信息，用于将技术字段映射为更贴近业务语境的表达。
在测试中，该配置方式有助于缩小自然语言与数据库结构之间的语义差距，对提升问数成功率和理解一致性具有积极作用。
业务场景中，数据库的表名或者变量名太过于技术化，客户更偏向于用口语化的语言。
折线图展示与 SQL 可解释性
测试中使用折线图展示Peacock_lodging_Terrie随时间的变化趋势时，SQLBot 能生成对应查询语句并完成可视化展示。但观察到其返回的 SQL 更像“展示用的伪 SQL”（格式或语法不完全符合数据库可直接执行的标准写法）。推测系统内部存在二次解析/解释器机制，将该伪 SQL 转换为真实可执行 SQL 后再完成查询与绘图。
SELECT “timestamp” AS “time”,
“Peacock_lodging_Terrie” AS “peacock_lodging_terrie_value”
FROM “public”.“sheet1_bd3a0fd2df”
ORDER BY “timestamp”
LIMIT 1000
数据分析功能
SQLBot 提供了基础的数据分析能力，主要以执行 SQL 查询并对结果进行简单处理和可视化为主。在实际测试中，系统能够完成常见的统计汇总和趋势分析，但对于相关系数计算、复杂统计分析等超出 SQL 原生表达范围的分析任务，当前版本无法直接支持。
整体来看，其数据分析能力仍以“查询型分析”为主，更适合作为智能问数工具，而非通用的数据分析或统计建模平台。
非 SQL 统计分析能力限制
在测试中尝试计算不同变量之间的皮尔逊相关性系数，SQLBot 无法完成该类分析任务。系统提示其仅支持执行 SQL 语句，无法直接进行相关性等统计分析计算。
该结果表明，当前 SQLBot 的分析能力主要受限于 SQL 表达范围，对超出 SQL 原生能力的统计分析场景支持不足。
折线图展示时间序列趋势
在测试中，使用折线图展示Eagle_education_Jewell随时间的变化趋势，SQLBot 能够根据自然语言问题生成对应查询并完成可视化展示。整体趋势呈现符合预期，能够反映该变量在时间维度上的变化情况。
该测试表明，SQLBot 在时间序列类查询和基础趋势分析场景下具备较为稳定的表现，适用于常见的时序数据展示需求。
饼图展示分类占比
在测试中，使用饼图展示不同子行业的建筑数量占比。SQLBot 能够根据自然语言问题生成分组统计查询，并将结果以饼图形式进行可视化展示。
该功能适用于分类统计和结构占比分析等场景，在展示不同类别分布情况时具有一定实用性。
SELECTsubindustryASsubindustry,
COUNT(*) ASbuilding_count
FROMmetadata
WHEREsubindustryIS NOT NULL
GROUP BYsubindustry
ORDER BYbuilding_countDESC
LIMIT 1000
六、 异常与边界测试
错别字识别能力
在测试过程中发现，若在问题中引入少量错别字（例如简单拼写错误或个别字符错误），SQLBot 往往无法正确理解用户意图，导致无法匹配相关字段或生成有效 SQL。
在错别字较轻、语义仍然明确的情况下仍出现该问题，说明系统对输入文本的容错能力较弱。考虑到底层使用大语言模型，该类场景理论上应具备基本的拼写纠错能力，该问题在实际业务使用中可能影响用户体验。
查询不存在的数据
在测试中，当查询的数据在当前数据集中不存在时，SQLBot 能够返回明确的“不存在”提示，而未生成错误或误导性的查询结果。
该表现符合预期，说明系统在基础数据校验和异常场景处理方面具备一定的合理性。
多表关联分析能力
在测试中尝试让 SQLBot 自动分析多表之间的关联关系，但系统无法直接给出有效结果，需要通过手动方式配置或指定表之间的关联。
这表明当前版本 SQLBot 在多表关系自动推断方面能力有限，多表查询仍较依赖人工配置。
多表关系配置方式
SQLBot 支持用户自行选择参与问数的数据表，并通过拖拉拽的方式手动建立多表之间的关联关系。
在测试中，该方式能够较直观地完成多表配置，为后续多表查询提供基础，但整体仍依赖人工操作，自动化程度有限。
七、 权限、安全与工程能力
表级权限控制能力
SQLBot 支持为不同用户配置数据表的访问权限，从而控制用户可见和可操作的数据范围。
在测试中，该机制能够满足基本的数据隔离和权限管理需求，适用于多用户使用场景下的数据安全控制。
术语与同义词配置效果
SQLBot 支持为业务术语配置描述信息及同义词映射，用于增强自然语言问题与数据库字段之间的语义匹配。在实际测试中，该术语配置在一定程度上提升了问数的准确性和稳定性，尤其在业务表达与技术字段差异较大的场景下效果较为明显。
八、 类似产品对比
SQLBot：轻量级、私有化友好的基础智能问数工具，工程取向清晰，但分析与产品能力有限
Vanna：以交互体验为核心的 Text-to-SQL 产品，适合协作和快速使用
SuperSonic：问数 + BI 的完整平台方案，功能最全，适合正式分析与展示场景
SeekDB：数据库生态内的智能问数工具，SQL 能力强，但通用性有限
WrenAI：云端 Chat-BI 工具，上手快，但私有化与深度定制受限
Seekdb
https://github.com/oceanbase/seekdb?tab=readme-ov-file
https://vanna.ai/docs/quick-start
Vanna
https://github.com/vanna-ai/vanna
https://app.vanna.ai/app/new-chat
在同类型智能问数产品中，Vanna 在整体产品化程度和用户交互体验方面表现相对成熟。首先，从界面层面来看，Vanna 的整体 UI 设计更加简洁、美观，信息层级清晰，对首次使用的用户较为友好，能够降低上手成本。
在交互机制上，Vanna 对“问数失败”场景提供了更明确的用户引导。当大模型无法给出有效结果时，系统并非简单返回失败，而是引导用户判断失败原因，例如区分是提问方式不够清晰，还是模型对业务语义理解不足。同时，在每次回答完成后，Vanna 提供了用户满意度反馈入口，使用户可以直接对当前回答进行评价。这类反馈机制有助于系统持续优化模型效果，也能在一定程度上改善用户使用体验。
在协作与结果复用方面，Vanna 支持将问数过程和结果以类似文档或对话的形式进行分享，使用体验接近飞书或腾讯文档的共享方式，便于在团队内部进行传播和讨论。该能力在实际业务场景中具有较高实用价值，能够避免重复提问，提高数据分析结果的复用效率。
此外，Vanna 提供了一定数量的现成集成工具和接口，方便其与其他系统或平台进行对接，整体集成成本相对较低。从整体定位来看，Vanna 更偏向“以用户体验和交互为导向”的智能问数产品，而非单纯强调底层 SQL 生成能力。
SuperSonic
SuperSonic 是一款国产的智能问数与数据分析框架，整体界面设计较为简洁，功能覆盖范围相对更广，产品完成度较高。相比偏“问数入口”定位的工具，SuperSonic 更接近于集成式的数据分析与 BI 平台。
https://github.com/tencentmusic/supersonic
http://117.72.46.148:9080/chat?agentId=1
在功能层面，SuperSonic 支持用户自定义业务指标，并基于查询结果进一步创建仪表板、看板以及大屏展示，能够覆盖从数据查询到结果展示的完整流程。该能力使其在数据可视化和结果汇报场景中具有明显优势。
此外，SuperSonic 支持创建不同用途的智能助理，其中既可以配置专门用于智能问数的助理，也可以新建仅用于通用大语言模型对话的助理，功能边界相对清晰，有助于满足不同使用场景下的需求。
在交互体验方面，当用户获得查询结果后，系统支持通过可视化方式对查询时间范围、展示方式等参数进行二次调整，而无需重新输入自然语言问题。这种交互方式在实际使用中能够显著提升分析效率。同时，SuperSonic 还支持将查询结果数据导出，便于进行后续分析或离线处理。
WrenAI
https://github.com/Canner/WrenAI
https://wrenai.readme.io/reference/cloud-getting-started
https://cloud.getwren.ai/projects/13182/home
智能问数工具选型建议表
九、 总体评价与结论
综合本次测试结果来看，SQLBot 是一个定位清晰、工程取向明确的开源智能问数框架，其核心优势在于私有化部署友好、RAG 机制有效控制 token 消耗，以及在基础问数场景下具备一定稳定性。对于希望在企业内部快速落地自然语言查询能力的团队而言，SQLBot 具备一定实用价值。
但同时也需要看到，当前版本的 SQLBot 功能整体偏基础，更适合解决“能不能用自然语言查数据”的问题，而非“能否进行深入数据分析或智能决策”。在图表类型、统计分析、预测能力、多表复杂场景处理等方面，其能力仍存在明显边界。尤其是在涉及多表联查、字段歧义、复杂 SQL 生成时，系统表现高度依赖底层大语言模型能力，框架本身的兜底和校验能力有限。
从产品成熟度角度看，与 Vanna、SuperSonic 等同类产品相比，SQLBot 在交互体验、结果复用和协作能力方面仍有差距，但在私有化、权限控制和工程简洁性方面保持了一定优势。这也决定了 SQLBot 更适合被定位为轻量级、可控、面向基础问数场景的技术组件，而非开箱即用的完整 BI 或数据分析平台。
总体而言，SQLBot 目前更像是一个“良好的起点”，而不是“终态产品”。如果后续能够在鲁棒性、多表稳定性、分析能力和系统扩展性等方面持续投入，其在企业级智能数据应用中的价值仍有较大的提升空间。
十、建议改进和后续计划
SQLBot 当前整体流程仍以“所有问题尝试转 SQL”为核心路径，但在实际业务中，用户问题往往同时包含SQL 问数型问题与非结构化咨询型问题。通过引入通用对话模式、失败分流机制、用户反馈与问题记忆能力，并在数据源和模型侧增强扩展性（如国产数据库、Dify 工作流、本地模型），SQLBot 可从“问数工具”进一步演进为更完整的智能数据交互入口。
基于本次对 SQLBot 的完整测试，可以看出其整体架构思路清晰，工程目标明确，但在功能深度、交互体验以及复杂业务场景支持方面仍存在较明显的提升空间。后续改进方向可从短期可落地优化与中长期能力演进两个层面推进。
在短期层面，建议优先聚焦于提升系统可用性和用户体验。一方面，可以在问数入口引入更明确的失败反馈机制，当 SQL 生成失败或无法回答时，区分是“用户提问方式不清晰”还是“模型对业务理解不足”，并通过交互选项引导用户修正问题。同时，在回答完成后增加用户满意度反馈入口，为后续优化提供数据基础。另一方面，可以引入基础的输入容错能力，如错别字纠正和同义词增强，以降低业务用户的使用门槛。
在数据分析能力方面，当前 SQLBot 主要停留在“查询型分析”阶段，建议逐步引入非 SQL 原生的分析算子，例如相关性分析、同比环比等常见统计能力，使系统能够覆盖更多实际分析需求。同时，在预测功能上，可考虑开放模型扩展接口，支持调用外部模型或模型库（如 HuggingFace），避免预测能力长期局限于简单线性模型。
在多表和复杂数据场景下，SQLBot 的能力仍较依赖人工配置。后续可重点增强多表关系推断与字段消歧能力，例如在 join 场景下提供自动关联建议、字段冲突提示等，降低复杂业务数据使用成本。同时，可优化表结构同步与加载策略，在数据表数量较多时减少初始化开销。
在系统扩展性方面，建议进一步完善数据源与模型的接入机制。一方面，对非 SQLAlchemy 直接支持的数据库（如达梦、GaussDB 等）提供更清晰的适配规范和示例实现；另一方面，可考虑支持本地模型调用（如通过 Ollama），以及与 Dify 等工作流平台的集成，使 SQLBot 能够更好地融入企业现有 AI 应用体系。
从后续计划角度看，SQLBot 可以逐步从“智能问数工具”演进为“统一的数据智能入口”，在保证私有化、安全可控的前提下，承担更多交互与分析职责。
