Text2SQL救不了问数，能救的是口径

智能问数赛道又添一名选手，但这次的看点不是模型，而是路线之争。

开源智能问数平台 YOLO Data 发布 v1.0，抛出了一个在业内私下被反复讨论、却很少有人敢在产品文档里写明白的判断：「让模型直接写 SQL」这条路，大概率行不通；把确定性还给平台、还给工作流，这才是可行的路径。

这句话几乎是对过去两年 ChatBI 热潮的一次公开纠偏。当几乎所有问数产品都在卷 Prompt、卷模型微调、卷 Text2SQL 的准确率榜单时，YOLO Data 选择把大模型 DataAgent、实时指标体系、业务数据集、数据权限、会话记忆和工作区产物，整合成一条可审计、可复现、可治理的 workflow。

这不是技术细节的分歧，而是对『问数到底难在哪』这个根本问题的两种回答。

📉 Text2SQL 的三年弯路：准确率的幻觉

每一代问数产品，几乎都从同一个演示开始。

业务人员对着输入框敲下一句「上个月华东区客单价 top10 的商品」，三秒后，一张带图表的答案弹出来。台下掌声，投资人心动，Demo 圆满。

但真正落地过的团队都知道，演示和生产之间隔着一道深渊。演示里问的是问题，生产里问的是口径。

同一个「销售额」，财务口径含税、销售口径不含税、运营口径还要剔除退款；同一个「活跃用户」，有人按登录算、有人按关键行为算、有人按去重设备算。模型可以写出语法完美的 SQL，但它不知道你的公司把哪个定义叫做「销售额」。

更麻烦的是 Text2SQL 的工程特性：

• 不可复现。同一句自然语言，今天生成的 SQL 和上周的 SQL 可能走了不同的表、不同的过滤条件。业务拿着两张对不上的报表来找你，你连「上周那个数是怎么算出来的」都解释不清。
• 不可审计。模型生成的 SQL 直接打到生产库，谁来为一次全表扫描、一次误删的 WHERE 条件负责？
• 不可治理。权限控制如果只做到『这个用户能问』，而没做到『这个 SQL 只能扫到这几行』，那数据安全就是纸糊的。

多位做过 ChatBI 落地的平台架构师私下表达过类似的挫败感：模型准确率从 70% 提到 85%，业务满意度反而没涨——因为剩下的 15% 恰恰是口径歧义，而口径歧义不是模型问题，是组织问题。

用模型的概率性去对抗企业数据的确定性要求，方向从一开始就错了。

🧭 把确定性还给工作流：YOLO Data 的架构选择

YOLO Data v1.0 的核心主张，一句话概括就是：模型负责理解和编排，平台负责确定性。

它没有把『自然语言进来、SQL 出去』当作产品终点，而是把六类能力整合进一条 workflow：大模型 DataAgent、实时指标体系、业务数据集、数据权限、会话记忆、工作区产物。

这条 workflow 的执行逻辑大致如下：

这里面有几个设计值得单独拎出来说。

第一，指标体系优先于自由生成。 用户的提问不是直接翻译成 SQL，而是先去匹配平台上已经定义好的指标和业务数据集。指标口径是唯一权威来源，模型只是找到了『该用哪个口径』，而不是『发明了一个口径』。这就把 Text2SQL 的开放生成问题，收敛成了一个检索与路由问题——后者的确定性高得多。

第二，反问是产品能力，不是兜底话术。 当模型判断口径存在歧义时，它会主动向用户澄清，而不是硬着头皮给一个可能错的答案。这个细节很关键：问数产品的信任是脆弱的，一次错误的数字造成的伤害，远大于一次追问带来的摩擦。宁可多问一句，不可错算一次。

第三，会话记忆支持多轮追问。 业务对同一个问题可以连续追问——「那再看环比」「只看线上渠道呢」「按城市拆一下」——上下文在会话内延续，而不是每一轮都重新解释一遍业务背景。这是问数从『玩具』走向『日常工具』的必要条件。

第四，工作区产物可沉淀。 每一次问答的结果不只是聊天气泡，而是落成工作区里可复用、可追溯的产物。上周的结论，这周可以引用；同事的看板，可以直接基于同一套口径续作。

一句话总结这套架构的哲学：让概率性的部件待在该待的位置，让确定性的环节交还给工程。

🔐 口径、权限与审计：问数的隐形门槛

问数赛道看起来门槛低——接个模型、写个前端就能发布产品。但真正卡住商业化的，是三样看不见的东西：口径、权限、审计。

口径是数据组织的共识问题。一家稍有规模的企业，指标定义散落在数仓文档、Excel、老员工的脑子里。问数产品要可用，前提是这些口径被结构化、版本化、变成机器可消费的语义层。这个工作没有捷径，只能一层一层梳理。这也是为什么 YOLO Data 把『实时指标体系』和『业务数据集』当作一等公民，而不是模型的外挂知识库。

权限是安全底线。分析场景的权限粒度远比报表场景细：一个区域销售可以看自己区域的明细，但不能看其他区域；一个运营可以看聚合指标，但不能拉用户级数据。如果问数产品绕过现有的权限体系直接连库，等于在数据安全墙上开了一个后门。

审计是合规刚需。数据要素流通的政策环境日趋严格，企业内部的每一次数据消费都需要留痕。『这个数字谁问的、基于哪个口径、扫了哪些表』必须能完整还原——这既是合规要求，也是业务信任的基础。

三条 workflow 特性对应的工程价值，可以这样对照：

这三样东西都不性感，但它们才是问数产品真正的护城河。

💼 路线分野与开源逻辑：问数的下一步

把视角拉高，问数赛道实际上存在三条技术路线的竞争：

三条路线的分化，本质是对『错误成本』的不同定价。Text2SQL 直连路线把错误成本转嫁给业务用户——反正 SQL 是模型写的；语义层工作流路线把错误成本前置到平台建设期——先把口径和权限做扎实，换取运行时的确定性；微调路线则试图用数据和算力硬啃，但企业问数场景的语料天然稀缺，且口径一变模型就要重训，维护成本极高。

YOLO Data 明确押注第二条路线。选择开源，逻辑也不难理解：

其一，问数的价值沉淀在企业的语义层和工作流里，不在软件授权费里。 客户真正愿意付费的是平台与自身数据资产的深度融合，而这只能通过开放和共建实现。开源是降低『把口径搬进平台』这件事的心理门槛的最快方式。

其二，工作流路线需要生态。 指标体系要对接各家数仓，权限要打通企业 IAM，DataAgent 的编排能力要随场景扩展——这些都不是一家公司闭门能做完的。开源社区是工作流类产品事实标准化的必经之路。

从产业时序看，问数赛道大致经历了这样几个阶段：

• 2023 年 : ChatBI概念爆发，Text2SQL演示满天飞
• 2024 年 : 试点落地，口径与权限问题集中暴露
• 2024 至 2025 年 : 语义层与DataAgent范式兴起，工作流路线成型
• 2025 年 : YOLO Data v1.0开源，工作流路线走向可复用

这个时间线里藏着一个行业认知的迁移：从『模型能做什么』，走到了『组织需要什么』。

当然，工作流路线也不是没有代价。语义层的建设是重活、累活，需要客户的数据团队深度参与；对中小企业来说，没有清晰的指标体系，再好的 workflow 也无处着力。这意味着这类产品的客户天然偏向数据基础较好的中大型企业——这也解释了为什么开源策略对它尤为重要：用社区的力量把语义层建设的最佳实践沉淀下来，才能逐步降低这条路线的使用门槛。

结语

问数产品的竞争，正在从『谁的模型更聪明』转向『谁的平台更可信』。

YOLO Data v1.0 的价值不在于它是一个新工具，而在于它把一个业内心照不宣的共识变成了开源的实现：大模型在数据分析中的正确位置，是理解意图、编排流程、生成解释，而不是替代企业的口径共识和治理体系。

接下来值得观察的是两点：一是这条开源 workflow 能否在社区中沉淀出跨行业的语义层模板，真正摊薄落地成本；二是当工作流路线被验证后，Text2SQL 直连路线的产品会以多快速度向语义层靠拢——那将是这条赛道格局真正固化前的最后一轮卡位。

数据的确定性，终究要由确定性的工程来守护。这句话，可能会成为下一阶段 Data for AI 产品设计的默认前提。