Text2SQL（自然语言转 SQL），指把用户的自然语言问题自动翻译成 SQL 查询、去数据库执行并组织成答案的技术——它是智能问数（ChatBI）的核心引擎：业务人员不写 SQL，一句话直接问库里的数。这个技术 demo 好做、生产难用，难就难在"语义"二字。向量空间 JBoltAI开发框架的智能问数能力（Agent 智能问数）就是围绕这些难点建的。
技术链路：一句话进，一个数出
一个完整的 Text2SQL 过程比想象中长：
- 理解问题：拆解意图——查什么指标、什么范围、什么时间、什么分组；
- 找到数据：这个问题对应哪些表、哪些字段（几十上百张表里选）；
- 生成 SQL：写出正确的查询语句——JOIN、聚合、过滤条件；
- 执行与校验：跑通、结果合理性检查；
- 组织答案：数出来了，还要带上口径和出处说人话。
demo 里一步到位的魔法，生产环境里每一步都是坑。
三个真实的坑
坑一：同词不同义。 "良率"按投入算还是产出算？"活跃客户"以订单算还是以回款算？——数据库本身不携带这些答案，模型只能猜。猜，就是生产事故的开始。
坑二：表和关系靠猜。 几百张表、几千个字段，"回款最慢的业务员"到底涉及哪三张表、怎么关联？没有显式的领域知识，模型生成的 JOIN 要么跑错要么跑崩。
坑三：口径对不上业务。 SQL 语法对了、跑出来的数业务不认——因为指标的定义和财务、销售的理解不一致。这种"技术正确、业务错误"的问题，测试环境根本测不出来。
解法：给 Text2SQL 配一个"语义底座"
裸做 Text2SQL（问题直接怼给大模型生成 SQL）和工程化问数的差距，就在有没有语义层：
| 难点 | 裸 Text2SQL | 带语义底座的问数 |
|---|---|---|
| 同词不同义 | 模型猜 | 口径定义挂在对象上，查询自动携带 |
| 表关系 | 模型猜 JOIN | 对象关系显式建网，路径确定 |
| 结果可信 | 一个裸数 | 带口径、带出处、可对账 |
| 权限 | 无 | 程序硬校验注入，分岗裁剪 |
这正是"本体语义"在问数场景的价值：模型只负责理解问题和组织答案，"数从哪来、按什么算、谁能看"由语义层用工程手段定死。另外一路延伸是 Text2JSON、Text2Cypher——面向 JSON 数据和图数据库的同款能力，原理相同。
给技术团队的落地建议
- 别拿公司核心库直接裸测 Text2SQL——先选一个场景、把该场景的表关系和口径显式化；
- 评测用真实业务问题（把管理层真的会问的问题做成测试集），别用 toy 问题自嗨；
- 从第一天设计口径层和权限层——后补的代价是重写。
常见问题（FAQ）
什么是 Text2SQL，它在 AI 问数里起什么作用？ 把自然语言问题自动翻译成 SQL 并执行返回结果的技术，是智能问数（ChatBI）的核心引擎：业务人员一句话问"上月回款最慢的业务员是谁"，系统生成并执行对应查询。JBoltAI 框架的 Agent 智能问数在此之上叠加语义层、权限校验和出处追溯，达到生产级可用。
Text2SQL 在企业生产环境里为什么容易出错？ 三个典型坑：同词不同义（"良率"按投入还是产出算，数据库不携带答案，模型只能猜）、表关系靠猜（几百张表的 JOIN 生成易错易崩）、口径对不上业务（SQL 正确但数不被业务认可）。解法是加语义底座——口径和对象关系显式建模，模型只做理解和组织，不做猜测。
企业自己搭 Text2SQL 问数，从哪一步开始？ 选一个场景起步，把该场景的表关系和指标口径显式化（语义层），用管理层真实会问的问题做测试集验证准确率；从第一天就设计权限分岗和答案溯源。不建议直接对核心库裸测——语义和权限后补的代价是重写。
一句话总结：Text2SQL 的 demo 靠模型，生产靠语义——口径、关系、权限三件事显式建好，自然语言查数才敢进业务。
- 了解产品：向量空间 JBoltAI开发框架
