SQLBot 这个开源项目，我是在一条“智能问数”工具推荐帖里翻到的，当时手头正好有一批 5 万条脱敏订单数据，就顺手拉起来做了一次完整的实测。所谓智能问数，简单说就是业务人员不用写 SQL，直接输入中文问题，系统负责把问题翻译成 SQL、连接数据库执行、再把结果整理成人话。SQLBot 属于这一波开源方案里比较“轻”的那种：服务可以自己部署，前端是聊天窗口，后端接大模型完成语义到 SQL 的转换。我陆续测了二十多个问题，覆盖单表查询、多表关联、时间统计、窗口函数等场景，整体结论是：它能覆盖大部分日常取数需求，但距离“无脑给领导用”还有不小距离。这篇记录会把我的测试环境、问题集、失败案例和落地经验全部展开，正在评估开源智能问数工具的同学可以参考。
1. 为什么盯上 SQLBot：智能问数的现实需求与开源价值
1.1 企业取数这件事，卡点不在数据库，而在翻译
每个公司数据库里都不缺数据，真正缺的是能把业务问题翻译成 SQL 的人。业务侧说一句“上个月华东区销售额前 10 的商品”，从提需求、排期、写 SQL、验证结果到回传，快则半天，慢则一两天。这个问题表面上是取数效率低，本质上是自然语言到结构化查询的翻译成本太高。
AI 出现后，Text-to-SQL 成了智能化改造的焦点。很多 BI 工具内置了 AI 问数，但大多绑定自家数据源或商业版本；云厂商的智能问数服务效果虽然好，却涉及数据出域的问题，很多公司在合规层面就会犹豫。于是开源项目开始被关注。SQLBot 吸引我的点很直接：代码开源，连上数据库就能对话，还支持自定义大模型接口。对有研发能力的团队来说，这是一个既能私有化、又能改代码的起点。
1.2 这次实测我到底想验证什么
测试不能只停留在“好不好用”这种感受层面，所以我拆了四个具体目标。
第一，准确率。同一个问题换几种说法，SQL 能不能一次写对，查出来的数是否和人工 SQL 一致。第二，稳定性。5 万行数据量不大，连续提十几个问题，服务会不会变慢、会话记忆会不会干扰后续回答。第三，边界。哪些问题它能轻松处理，哪些问题一定会翻车，翻车原因是模型还是系统设计。第四，工程化成本。从零部署、接入模型、配置只读权限、优化 schema 信息，需要投入多少人力和时间。
带着这些目标，我设计了一套可控的测试方案，而不是随机聊天，这样最后得出的结论才真正有选型参考价值。
2. 测试环境与数据准备：5 万行数据如何构成
2.1 数据表设计与数据生成逻辑
为了模拟典型零售场景，我建了三张关联表：客户表、商品表、订单表。客户 3000 条，商品 500 条，订单明细正好 5 万行，字段包含订单号、客户 ID、商品 ID、数量、金额、订单状态、订单时间、支付时间等。
建表语句如下：
CREATE TABLE customers ( customer_id INTEGER PRIMARY KEY, customer_name VARCHAR(100) NOT NULL, region VARCHAR(50) NOT NULL, city VARCHAR(50), register_date DATE ); CREATE TABLE products ( product_id INTEGER PRIMARY KEY, product_name VARCHAR(200) NOT NULL, category VARCHAR(50), list_price NUMERIC(10,2) ); CREATE TABLE orders ( order_id BIGINT PRIMARY KEY, customer_id INTEGER NOT NULL REFERENCES customers(customer_id), product_id INTEGER NOT NULL REFERENCES products(product_id), quantity INTEGER NOT NULL, amount NUMERIC(12,2) NOT NULL, status VARCHAR(20) NOT NULL, order_time TIMESTAMP NOT NULL, pay_time TIMESTAMP );数据生成直接用 Python 脚本随机抽取客户、商品，订单时间分布在 2023 年 1 月到 2024 年 12 月，状态字段包含已完成、已支付、已发货、已取消、退款中。这样设计是为了让测试中涉及时间过滤、状态排除、去重统计时，SQL 本身需要做多条件组合，而不是一个SELECT COUNT(*)就能敷衍过去。
提示：5 万行对数据库性能来说非常小，SQLBot 真正的考验其实是对表关系和业务语义的理解。很多刚接触这类工具的人以为数据量大才能测出问题，实际恰恰相反，这里数据量的意义更多是让结果具备统计区分度。
2.2 使用 Docker Compose 快速部署 SQLBot
部署时参考 README 用 Docker Compose 拉起服务。项目主要包含 API 服务、数据库连接器、前端聊天界面几个部分，核心配置都通过环境变量传递。我当时用的是类似这样的配置：
services: sqlbot: image: sqlbot/sqlbot:latest ports: - "8080:8080" environment: LLM_PROVIDER: openai_compatible LLM_API_BASE: http://localhost:11434/v1 LLM_API_KEY: ollama LLM_MODEL: qwen2.5-coder:7b DB_TYPE: postgresql DB_HOST: host.docker.internal DB_PORT: 5432 DB_USER: sqlbot_readonly DB_PASSWORD: 'readonly_password' DB_NAME: biz_demo这里有个细节容易被忽略：SQLBot 默认使用 OpenAI 兼容接口，而本地 Ollama 也提供同样的协议。只要把LLM_PROVIDER设成openai_compatible，就可以随时在本地模型和云端模型之间切换。为了对比，我测了两套模型：一套是 Qwen2.5-Coder-7B 本地开源模型，另一套是通用商业 API 模型，我当时用的是 GPT-4o-mini。这个对比主要不是为了证明谁更强，而是想验证文档里说的“支持开源模型”到底能用成什么程度。
2.3 模型接入方式才是最大变量
启动服务和接入模型之间，其实隔着一大段距离。SQLBot 本身只负责提问编排、SQL 执行、结果格式化，真正理解中文问题并写出正确 SQL 的，是背后的大模型。同一个问题，模型能力强弱不同，结果可能差出 20% 到 30%。
如果文档不把这点说透，用户很容易误以为 SQLBot 能力不行，实际上它更像一座桥，桥那边的车才是决定速度的关键。所以后面第三部分的实测数据，我都会标明用的是哪个模型，避免给大家造成错误预期。
3. 核心能力实测：问数准确率与语义理解
3.1 如何设计一套有效的问题集而不是随口问
我准备了 20 个问题，分成三类。
第一类，单表简单查询。比如“客户总数是多少”“2024 年每月的订单总额是多少”“取消订单有多少”。第二类，多表关联查询。比如“每个区域下单最多的客户是谁”“各商品类别的销售额排行”“哪个城市的客单价最高”。第三类，复杂逻辑问题，主要覆盖窗口函数、时间差、去重统计、状态过滤。比如“近 90 天新增客户的复购率”“每个客户最近一次下单时间”“2024 年每个区域销售额最高的 3 个商品类别”。
问题集设计的关键在于提前人工写好标准 SQL 和预期结果，不能等系统返回数字后觉得差不多就算对，必须逐条比对，差一分都算错。同时我会记录 SQLBot 每次生成的 SQL 原文，方便判断错误到底来自前端的自然语言理解，还是后端的 SQL 语句生成。
3.2 三类问题实测结果对比
最终跑下来的结果如下表。需要先说明，本组数据基于商业 API 模型。
| 测试类别 | 题数 | SQL 语法正确率 | 查询可执行率 | 结果正确率 | 平均端到端耗时 |
|---|---|---|---|---|---|
| 单表简单统计 | 6 | 100% | 100% | 100% | 3.1s |
| 多表关联查询 | 8 | 87.5% | 75% | 62.5% | 5.6s |
| 复杂逻辑与窗口函数 | 6 | 83.3% | 83.3% | 50% | 6.4s |
语法正确率代表生成的 SQL 能被数据库解析；可执行率代表字段和表都存在且连接关系有依据；结果正确率则是我与标准 SQL 逐一核验的结果。单表问题基本没有悬念，多表关联开始出现字段张冠李戴，复杂逻辑里凡是涉及“分组后取 TopN”的问题，错误率明显上升。
更值得关注的是，结果正确率远低于可执行率。也就是说，SQL 能跑通不代表算得对，工具会把一个错误的 JOIN 条件执行得理直气壮，如果没有人工复核，很容易让业务拿到一个看起来正常、实际上算错的数。
3.3 一个典型失败 Case 的完整复盘
翻车最明显的问题是“2024 年每个区域销售额最高的 3 个商品类别”。正确思路是先关联三张表，算区域和类别维度的销售额，再在每个区域里排序取前三。SQLBot 第一次生成的 SQL 是这样的：
SELECT c.region, p.category, SUM(o.amount) AS sales_amount FROM orders o JOIN customers c ON o.customer_id = c.customer_id JOIN products p ON o.product_id = p.product_id WHERE EXTRACT(YEAR FROM o.order_time) = 2024 AND o.status NOT IN ('已取消', '退款中') GROUP BY c.region, p.category ORDER BY c.region, sales_amount DESC LIMIT 3;这个 SQL 的坑非常典型。它没有做到“每个区域内部取前三”，而是把所有区域混合排序后直接取前 3，最终只会返回第一个区域的前几行，其他区域全部丢失。模型虽然知道要按区域分组，却没有理解“每个区域”隐含的窗口逻辑。正确写法应该用ROW_NUMBER() OVER (PARTITION BY c.region ORDER BY SUM(o.amount) DESC)，或者通过关联子查询实现。
修复时，我直接在对话里补了一句“注意：按区域分组后每个区域单独取前 3，不是全表前 3”，第二次生成的 SQL 就正确了。这说明模型对“每个区域 Top N”这类语义依赖问题表达，如果用户只说“销售额最高的 3 个商品类别”，它很容易按通用 TopN 去理解。
另一个高发问题是状态过滤不一致。部分订单在业务上要排除取消和退款，但有的问题里我没有带这个背景，SQLBot 就不会主动过滤；一旦问题里明确写了“排除取消订单”，它又能正确生成。这说明智能问数要落地，必须先把业务口径固化到提示词或规则中，不能指望模型每次都猜对。
4. 性能与稳定性：5 万行数据下扛不扛得住
4.1 端到端耗时拆解
测试环境是 4 核 CPU、16GB 内存的容器，目标数据库是 PostgreSQL 14。SQLBot 返回一个问题的平均耗时在 5 秒左右，我把耗时分了三段：提问提交和模型生成 SQL 约 2.5 秒，数据库执行不到 50 毫秒，结果格式化约 0.2 秒。
也就是说，5 万行数据下 SQL 执行根本不是瓶颈，瓶颈全在大模型把自然语言翻译成 SQL 的推理过程。这个结论对选型很有用：如果觉得响应慢，优先优化模型推理，比如换更好的 GPU 服务或更快的 API，而不是去给数据库加索引或调参数。
4.2 并发与长会话下的表现
我用脚本模拟了 10 个问题同时提交，每个问题相对独立，结果 API 容器把请求排队处理，最长的请求等待了接近 15 秒才返回。原因是模型服务本身没有并行推理能力，所有请求都要排队。这样的表现适合小团队内部使用，如果要开放给几十人同时访问，必须在上游加网关限流和排队提示，否则体验会很差。
另一个容易被忽略的问题是长会话拖慢速度。SQLBot 会把历史问题和历史 SQL 结果留在上下文中，方便用户追问时保持一致口径，但这也会让 Prompt 越来越长。我在一个会话里连续问了 30 个问题，不刷新页面，后半段的响应耗时比开头增加了接近一半。生产使用建议设置最大上下文长度，或者定期清理会话。
4.3 资源占用实测
实测期间，SQLBot API 服务常驻内存约 800MB 到 1.2GB，算比较正常。但如果本地接 Ollama 跑 7B 模型，Ollama 还要额外占用 6GB 左右内存，CPU 推理时经常跑满。综合来看，纯 CPU 服务器跑 SQLBot 配本地模型，体验不会太好；要么上 GPU，要么模型接口走云端或公司内部已有的模型服务。
数据库侧负载反而很低，5 万行表即使没加复杂索引，普通聚合查询也就几十毫秒。最需要担心的是权限问题，而不是性能问题，接下来第五部分会重点展开。
5. 工程落地中的几个坑：权限、元数据、提示词与模型选型
5.1 数据库账号权限是第一条红线
智能问数工具会自动生成 SQL 并执行，如果连的是业务主库账号，理论上完全可能生成UPDATE、DELETE甚至DROP语句。即使模型很少这么做，也不能把安全建立在概率上。落地的第一件事，就是为 SQLBot 建立独立的只读账号：
CREATE ROLE sqlbot_readonly LOGIN PASSWORD 'readonly_password'; GRANT CONNECT ON DATABASE biz_demo TO sqlbot_readonly; GRANT USAGE ON SCHEMA public TO sqlbot_readonly; GRANT SELECT ON ALL TABLES IN SCHEMA public TO sqlbot_readonly; ALTER DEFAULT PRIVILEGES IN SCHEMA public GRANT SELECT ON TABLES TO sqlbot_readonly;同时，在 SQLBot 的配置里打开“仅查询”模式，提示模型只能生成以SELECT或WITH开头的 SQL。两道防线配合，即使模型输出异常，也无法改写数据。另一个建议是单独准备只读从库，把所有问数流量都打到从库，彻底隔离对主库的影响。
5.2 表注释和字段注释就是命门
第一轮测试完成后，我重新加工了 schema 注释，把之前翻车的题目又跑了一遍。结果相当惊人：光补充COMMENT，结果正确率大概提升了一到两成。原因是模型在生成 SQL 前会读取数据库 schema 信息，表名和字段名的业务含义越清楚，它就越不需要靠猜。
订单状态字段我加的是这样的注释：
COMMENT ON TABLE orders IS '订单表'; COMMENT ON COLUMN orders.status IS '订单状态：0=待支付，1=已支付，2=已发货，3=已完成，4=已取消'; COMMENT ON COLUMN orders.amount IS '订单实付金额，单位元，已扣除优惠';如果你的字段是a0101或f_status这类毫无业务含义的编号，再强的模型也很难理解。想用开源智能问数工具，第一步不是调提示词，而是做元数据治理，这是投入产出比最高的工作。
5.3 提示词、示例库和业务口径要一起配
只靠系统默认提示词远远不够。SQLBot 通常支持配置 few-shot 示例，格式就是“业务问题 + 标准 SQL”的成对样例。我在配置里加了 5 个最常见的取数模式：按月统计、按区域统计、TopN、同比、排除取消订单。加完之后，多表关联的准确率再次提升。
示例不需要很长，关键是让模型知道当前库里的状态值到底存的是中文还是数字。很多业务口径就藏在示例里，比如“有效订单”指的是“已完成、已支付、已发货”，而不是全部记录。如果不在提示词里给出这条口径，模型只能根据字段名猜。
提示：我整理的标准示例里有一条规则会放到全局提示词中：“如果问题没有特别说明，统计订单时默认排除已取消和退款中。”这条规则比逐个问题去叮嘱模型更管用，能覆盖一批相似问法。
5.4 模型选型不要盲目跟风
开源模型和商业模型之间的差别，在 SQL 生成这件事上特别明显。我测试的 7B 模型，单表查询完全够用，一到多表连接和窗口函数就容易犯“列名不存在”“分组逻辑错误”的毛病。如果团队没有 GPU 资源，硬上开源大模型可能反而是给自己挖坑。
更务实的做法是：把开源模型当作默认方案，把商业 API 模型当作高准确率备选。数据敏感且合规允许的场景，本地用更大参数的模型微调；数据允许出域的场景，直接调用云端模型效果最好。选定模型后，一定要把测试问题集保存成回归集，每次换模型都重新跑一遍，用同一把尺子衡量。
6. 开源智能问数到底能走多远，我的最终判断
6.1 它目前适合做哪种角色
实测下来，SQLBot 的真实定位更像“数据开发助理”，而不是“万能自助 BI”。对于熟悉数据逻辑的分析师，它能快速给出一份可参考的 SQL，省去大量写简单查询的时间；对于完全没有 SQL 基础的业务人员，在缺少复核机制的情况下，它给出的“正确答案”必须打一个问号。
所以我的建议是：先把它开放给数据团队内部使用，由分析师判断结果，再把确认后的结论分发给业务侧，而不是让业务直接面对生成式 AI。这个角色定位决定了 SQLBot 在当前阶段不会淘汰数据分析师，反而能把他们从基础取数里解放出来。
6.2 最有价值的二次开发：建立反馈闭环
开源工具最怕只做一次性问答，答完就丢。SQLBot 可以把人工验证过的正确问答保存下来，积累成高质量示例库，定期把高频问题新增到 few-shot 配置中。做到这一步，系统会随着使用次数不断变强，等于团队自己构建了一套行业内的 SQL 语义知识库。
我在测试完成后，把一批手工验证正确的 SQL 追加到了示例文件里，重新跑这套题时，几个原本会翻车的窗口函数问题已经能一次通过。这说明开源智能问数的瓶颈不在“能不能做到”，而在使用者有没有建立持续优化机制。
6.3 我现在对开源问数的预期管理
如果要说最终结论，我觉得开源智能问数目前适合场景是“内部数据问答助手”，不适合“完全无监控的对外生产系统”。要做到对外投产，还需要补上指标层统一、权限细化、结果血缘追踪、人工审核流等一堆工程能力，这些不是单靠模型迭代能解决的。
从我个人的实际体验看，SQLBot 这类项目最让人惊喜的不是它写 SQL 多完美，而是把“查数”变成“对话”，让业务人员先通过自然语言摸清数据规律，再由专业人员做最终确认。只要把权限、元数据、口径和反馈机制四件事处理好，它已经能在小团队里稳定创造价值；这条路会越走越顺，但它前面还有一些需要团队自己填平的坑。填好之后，它比想象中走得更远。
