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 语法正确率查询可执行率结果正确率平均端到端耗时单表简单统计6100%100%100%3.1s多表关联查询887.5%75%62.5%5.6s复杂逻辑与窗口函数683.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 多完美而是把“查数”变成“对话”让业务人员先通过自然语言摸清数据规律再由专业人员做最终确认。只要把权限、元数据、口径和反馈机制四件事处理好它已经能在小团队里稳定创造价值这条路会越走越顺但它前面还有一些需要团队自己填平的坑。填好之后它比想象中走得更远。