"智能问数"这个概念这两年在企业数据分析领域越来越常见，但不同产品的实现深度差异很大。有的产品是简单的Text2SQL套壳，有的则构建了完整的语义层。这篇文章从技术架构角度，把智能问数的实现路径讲清楚。
一、智能问数的基础链路
一个完整的智能问数系统，技术链路大致包含以下几层:
用户自然语言提问
↓
意图理解 & 实体抽取(NLU)
↓
语义层映射(业务术语 → 数据字段)
↓
查询生成(Text2SQL / Text2DSL)
↓
查询执行
↓
结果呈现(表格/图表/自然语言总结)
二、两种主流实现路径的技术对比
路径一：直接Text2SQL，把数据库结构直接暴露给大模型
实现相对简单：获取数据库DDL(表结构)，连同用户问题一起交给大模型，直接生成可执行的SQL。
优点是开发成本低，接入速度快。
缺点也很明显：大模型直接面对底层数据库结构，一旦表结构复杂、字段命名不规范，或者业务口径需要额外的计算逻辑(比如"复购率"需要结合多个表的计算规则)，直接生成SQL的准确率会明显下降，而且生成过程是"黑盒"，很难对生成逻辑做统一管控。路径二：构建语义层，先转换为可解释的中间表达(Text2DSL)
这种路径会先构建一层业务语义模型，把常用的业务指标(如"新增用户数""GMV")、维度(如"渠道""地区")、口径规则提前定义好，形成结构化的语义层。用户提问后，系统先把问题转换成基于语义层的中间查询指令(DSL,Domain Specific Language)，再由DSL转换成最终的SQL执行。
这种方式的优势在于：每一步的转换都是可追溯、可解释的——命中了哪个语义模型、用了哪些维度和指标，都可以清晰展示给用户，同时也便于人工审核和干预，避免大模型"乱选表、算错数"的风险。缺点是需要前期投入构建语义层，对已有数据资产的建模成本较高。
三、两种路径的适用场景
数据结构简单、查询需求以基础统计为主的中小团队：直接Text2SQL的路径成本更低，足以覆盖大部分场景。
数据结构复杂、业务指标口径需要严格统一(比如涉及财务、经营分析)的企业级场景：构建语义层的路径虽然前期投入更大，但长期看结果的可信度和可维护性更高。
四、影响智能问数准确率的技术因素
元数据质量。 字段是否有清晰的注释、表之间的关联关系是否有明确定义，直接决定了Text2SQL的可用性下限。
时间维度的处理。 "最近一周""上个月"这类模糊时间表达，需要在语义层或Prompt设计中明确转换规则，否则容易出现边界理解偏差。
聚合逻辑的歧义消解。 "活跃用户"到底是"登录过"还是"有下单行为"，需要在系统里提前配置好业务规则，而不是完全依赖大模型自行判断。
结果的可解释性设计。 良好的实现应该让用户能看到生成的SQL或DSL逻辑，而不是只给一个黑盒结果，这对结果的信任度和纠错能力都很重要。
五、实践：从工具切入
对于还没有能力构建完整语义层的团队，可以先从带有Text2SQL能力、且能展示生成SQL的工具切入，比如开源项目 Chat2DB，支持自然语言转SQL并保留生成过程可见，适合作为智能问数的起点。
使用时建议注意：涉及复杂业务口径的查询，最好人工核对生成的SQL逻辑，不要直接信任结果；如果业务发展到一定规模，再考虑投入构建更完整的语义层和治理体系。
六、总结
智能问数不是一个单一技术，而是一整套从意图理解到结果呈现的工程体系。理解了背后的技术路径差异，再评估某个产品或工具的智能问数能力时，就能更准确地判断它到底处于"简单套壳"还是"扎实的语义层建模"哪个阶段，从而做出更合理的技术选型决策。
