你在数据库里丢了一个问题：“第二季度有多少客户流失了？”
AI 模型秒回了一段 SQL，语法完美，LEFT JOIN 和 WHERE 子句一个不落。你满怀信心地执行——结果返回了 0 行。
查询没错。数据也确实存在。只是模型选了另一张表，里头的“客户状态”字段存的是“已流失”，而不是“churned”。语法对，答案错。这种“沉默的错误”没有报错信息，没有红色警告，连数据库都不知道自己做错了——却是 Text-to-SQL 领域最隐蔽、也最致命的陷阱。
Feyn AI（YC 孵化创业公司）刚刚发布了一组名为 SQRL 的模型家族，试图用一种全新的思路解决这个问题：不先写查询，而是先查数据库。在生成一段 SQL 之前，SQRL 可以主动向数据库发送只读探测查询，搞清楚数据到底长什么样，再动笔。这种“先查后写”的范式，把 Text-to-SQL 从“翻译任务”重新定义为“侦查任务”。
一个被忽视的沉默杀手
Text-to-SQL 在学术界和工业界都不是新话题。从早期的 Seq2Seq 模型到今天的 GPT-4o、Claude Opus，这条路已经走了近十年。但一个根本性的问题始终未被触及：一段 SQL 的语法正确性和一段 SQL 的答案正确性，是两件完全不同的事。
一段 SQL 可以完美通过语法检查，却因为 JOIN 了错误的表、读取了模棱两可的列、或者过滤了不存在的值，返回完全错误的结果。更糟糕的是，这些错误全部是“沉默的”——数据库不会报错，用户不会警觉，只有当有人拿着结果去核对原始数据时，才发现答案错了。
BIRD 基准测试让这种失败变得可测量。BIRD 包含 12,751 个问题-SQL 对，覆盖 95 个真实数据库（总计 33.4 GB），横跨 37 个专业领域——从区块链到冰球，从医疗到教育。这些数据库保留了真实世界的“脏数据”：一个县名可能存为“Alameda”、“Alameda County”或“ALAMEDA”三种形式。在这种数据上，仅仅靠 schema 信息来生成 SQL，就像只看了地图就声称自己走过了整条路。
70.6% 的答案
这正是 SQRL 发力的地方。
Feyn 团队公布的数据显示，旗舰版本 SQRL-35B-A3B 在 BIRD Dev 集上达到了 70.6% 的执行准确率，超过了 Claude Opus 4.6 在同一评估下的 68.77%。更值得关注的是最小版本 SQRL-4B——仅 4B 参数，达到了 68.80%，几乎追平了 Opus。9B 版本则稳定在 69.80%，保留了教师模型绝大部分质量。
Feyn 同时开源了三个模型检查点：SQRL-4B、SQRL-9B 和 SQRL-35B-A3B，全部托管在 Hugging Face 上，并提供 vLLM 部署方案。
范式之争：为什么“翻译”本身就是错的
传统 Text-to-SQL 系统把问题框架为“翻译”：给定自然语言问题和数据库 schema，输出 SQL 查询。这个框架隐含了一个假设——schema 包含了生成正确查询所需的全部信息。
但事实并非如此。Schema 告诉你表名、列名和数据类型，但它不会告诉你“Alameda”和“Alameda County”是同一个地方。它不会告诉你哪个 JOIN 会产生重复行。它更不会告诉你，用户口中的“客户流失”在数据库里到底对应哪个枚举值。
Feyn 的洞察是：这些缺失的信息其实已经存在于数据库中——模型只需要被允许去“问”它们。SQRL 的核心创新不是更大的模型或更好的训练数据，而是给模型增加了一个“问问数据库”的步骤。
技术拆解：SQRL 如何“先查后写”
SQRL 的推理流程分为几个清晰的步骤。首先，模型接收问题、schema 和可选的数据库证据。如果上下文足够清晰，它直接返回 SQL。如果存在歧义，SQRL 会发送只读探测查询，根据返回的数据行起草最终答案。
这种“探测-生成”的循环最多执行 5 次。每次探测都是只读操作，不会修改数据库状态。SQRL 使用两种动作原语：<sql> 块用于执行 SQL 查询并获取结果，<answer> 块用于输出最终答案。执行引擎以只读模式运行探测查询，将返回的行包裹在 <observation> 标签中供模型继续推理。
一个关键设计细节：SQRL 的决策是“视情况而定”的。如果问题是“用户表有多少行”，不需要探测，直接回答。如果问题是“第二季度哪些客户流失了”，它会先发一条探测查询看看“客户状态”字段有哪些取值，再写最终查询。这种动态决策机制让 SQRL 在简单问题上保持高效，在复杂问题上保证准确。
训练链路：从巨人到迷你
SQRL 的训练方法同样值得关注。
Feyn 团队使用了一个 Qwen3.5-235B-A22B 教师模型（MoE 架构，每个 token 激活 22B 参数），让它通过完整的“探测-回答”流程在 BIRD 和 Spider 训练集上生成推理轨迹。但在此之前，团队做了一项关键的数据清理工作：首先删除了参考 SQL 无法产生可用结果的样本，然后让三个模型评审员审查剩余的问题-查询对，删除那些查询实际并未回答问题的样本。
清理之后，团队用 10,200 条高质量推理轨迹监督微调了三个学生模型。这一步之后，又引入了 CISPO（Contrastive Imitation from Stepwise Preference Optimization）训练——一种基于执行奖励的对比学习策略。每组训练中，模型生成 8 条完整轨迹，执行每条最终 SQL，将结果与参考答案对比，然后强化那些做出正确决策的路径。这种训练让模型不仅学会了“怎么写 SQL”，还学会了“什么 SQL 是对的”。
最终结果：SQRL-35B-A3B（总参数 35B，每个 token 仅激活约 3B 参数）达到 70.6%；9B 版本达到 69.80%；4B 版本达到 68.80%。这种“参数量缩小 50 倍，性能下降不到 2 个百分点”的效率，对部署在边缘或企业内网环境具有实际意义。
竞争格局：一个拥挤赛道的差异化突围
Text-to-SQL 赛道并不冷清。BIRD 排行榜上，Google Cloud 的 CHASE-SQL + Gemini 在 Test 集上达到 76.02%，阿里云的 XiYan-SQL 达到 75.63%，腾讯的 CYAN-SQL 达到 75.35%。SQRL 的 70.6%（Dev 集）放在绝对分数上并不领先。
但 SQRL 的差异化不在绝对分数，而在两个关键维度。
第一，模型规模与自主性。BIRD 排行榜前列的模型几乎全部依赖 Oracle Knowledge——即人工标注的领域证据，模型不是自主得出的答案。SQRL 的 70.6% 是模型通过自主探测数据库得到的结果，不需要人工提供额外证据。SQRL-4B 的 68.80% 是用 4B 参数做到的，这个规模可以跑在单张消费级 GPU 上，甚至 CPU 推理。
第二，部署边界。Feyn 选择完全开源，模型托管在 Hugging Face，代码在 GitHub 上。SQRL-4B 可以部署在企业内网，schema、查询和数据库观察结果全部在自有数据路径上流转，无需与第三方共享数据。对于金融、医疗、政府等对数据主权敏感的行业，这可能是比调用 GPT-4o 或 Claude API 更现实的选择。
从“看图说话”到“实地考察”
SQRL 的意义不在于它比 Claude Opus 高了 1.8 个百分点。这个差距在快速迭代的 AI 领域可能在下个月就被抹平。SQRL 的真正贡献是打开了一条新的技术路线：把 Text-to-SQL 从“看图说话”（只看 schema）升级为“实地考察”（查数据库）。
这个思路的延伸可能超出 SQL 本身。在 AI Agent 调用 API、操作文件系统、访问数据库的任何场景中，“先探查再行动”的范式都适用。SQRL 可以被视为一个更宏大趋势的缩影：AI 系统正在从“一次生成”走向“交互式推理”。
对于企业数据分析团队，SQRL 提供了一个可以在内网部署、不依赖外部 API 的 Text-to-SQL 方案。4B 模型意味着不需要昂贵的 GPU 集群。对于开源社区，SQRL 的“教师-学生-CISPO”训练流程本身就是一个可复现的配方，可以在自己的数据和领域上应用。
这条路线对“闭源 API + 大模型”的传统 Text-to-SQL 方案构成了底层挑战。如果一个小型开源模型，通过自主探测数据库就能达到接近前沿闭源模型的准确率，那么企业为什么还要把数据送到外部 API 去做查询？“先查后写”的范式天然更适合数据主权敏感的场景，而数据主权敏感，恰恰是企业级数据分析最普遍的特征。
SQL 不只是“怎么写”的问题，更是“该问什么”的问题。SQRL 懂了这一点。而真正懂数据的 AI，不需要你告诉它数据长什么样，它会自己去看看。
快报