智能问数都有哪些技术路径？从技术路径反看市场上的代表厂商

今天谈智能问数，如果不先谈技术路径，很容易把市场看乱。因为“智能问数”这个词表面上像一个功能，背后其实是几套完全不同的技术思路：有的强调 Text-to-SQL，有的强调宽表，有的强调指标平台，有的甚至是预置 SQL、预置 DSL，还有少数玩家走的是本体论和对象关系路线。
所以，真正有价值的问题不是“智能问数是不是一个功能”，而是智能问数到底有哪几条主流技术路径，每条路径代表哪些厂商，各自更适合什么场景。从当前国内市场实践看，至少可以分成五条主流路径。
智能问数的核心分水岭，不只是“有没有大模型”，而是系统到底依赖 SQL 翻译、宽表预处理、指标语义层，还是依赖对象关系与本体语义来理解业务。
一、第一条路径：直接 Text-to-SQL
这是最直观也最容易理解的一条路线。它的基本逻辑是：用户用自然语言提问，系统尽量把问题翻译成 SQL，再到数据库里执行。
这条路线的优点是实现思路直观、演示效果好理解、适合标准化问题，对轻量场景和简单查询很友好。但缺点也很明显：它对数据库结构依赖大，对字段命名、别名映射、样例积累高度敏感；一旦业务问题复杂，稳定性就容易下降；很多复杂问题最终还是会回到人工规则补丁。
所以它通常更适合结构相对规整、查询模式相对固定的环境，而不一定适合复杂业务组织。对应的市场玩家，常见于一些问数助手、数据 Copilot 或大模型问数原型产品中，也经常出现在互联网公司和云平台的早期方案里。
直接 Text-to-SQL 更像是把自然语言转成数据库语言，它解决的是“怎么查”，但不一定解决“业务到底在问什么”。
二、第二条路径：Text-to-SQL + 宽表 / 人工预置宽表
这是国内非常常见的一条增强路线。因为很多团队很快发现，直接做多表、多关系、复杂语义的 Text-to-SQL 太难，于是就会先把数据预处理成宽表，把复杂 join 和关系判断提前展开，再让模型在相对简单的表结构上生成 SQL。
这条路线的优点是可以显著提升表面准确率，适合做经营分析、专题分析、标准化问题，也更容易控制查询结果，因此更适合短期落地。但它的问题同样典型：宽表本质上是“提前人工展开语义”，一旦对象关系变化，维护成本就会上升；跨域场景越多，宽表膨胀越严重；泛化能力受限于你预先展开了多少。
市场上不少 BI 问数能力、轻量智能问数方案，实际上都会在不同程度上借助这种思路。很多甲方现在也逐渐明白一个现实：很多智能问数看起来很准，并不是模型突然懂业务了，而是因为工程上已经把问题预先简化了。
三、第三条路径：指标平台 / 语义层 / 指标中心驱动
这一条路线不是优先把自然语言翻 SQL，而是先建立统一的指标语义层。它关心的问题包括：指标如何定义、指标口径如何统一、维度如何管理、时间口径和组织口径如何对齐，以及不同看板和问数入口如何共用同一套指标资产。
这一类路径的优势，在于它比纯 SQL 路线更稳定，也更符合大型企业治理逻辑。因为企业内部真正难的往往不是“写出 SQL”，而是“确保所有人看到的是同一个口径”。这也是为什么很多 BI 厂商和数据平台厂商都会往这个方向走。
从代表厂商看，这一类常常可以看到帆软、永洪、思迈特、观远，以及一些云厂商或数据平台中的指标中心方案。这条路线适合标准经营分析、管理驾驶舱、统一口径报表和指标问答，但在面对复杂对象关系、业务状态变化和深层语义理解时，仍然会遇到抽象边界。
指标平台路径解决的是“统一怎么说”和“统一怎么算”，它比纯 SQL 更稳定，但不天然等于复杂业务语义理解。
四、第四条路径：预置 SQL / 预置 DSL / 规则模板驱动
这是一条经常被包装得不那么明显、但在项目里很常见的路线。很多系统表面上看起来是“自然语言智能问数”，实际内部是先识别问题类型，归到某个模板，再调用预置 SQL 或某种 DSL、查询脚本，最后把结果用自然语言包装返回。
从工程角度讲，这条路线并没有问题，甚至在很多高频、标准化问题场景下非常有效。问题只在于：它更接近“模板化智能入口”，而不是开放式的泛化问数能力。
所以一个比较公正的说法是：预置 SQL 和预置 DSL 并不低级，它们在标准化高频场景中非常实用；但本质上，它们和 SQL 路线并没有根本区别，仍然属于“先定义可答范围，再把用户问题映射进去”的方法。这条路线常见于很多项目制方案、定制化平台和行业问答系统里，它往往不是某一家厂商独占，而是一种广泛存在的交付方式。
五、第五条路径：本体论 / 对象关系 / ABC 范式驱动
这是今天最值得认真讨论、但在国内真正落地并不多的一条路线。这条路径和前几条的差异，不是“它不用 SQL”，而是它并不把 SQL 当作智能问数的核心抽象。它更强调先定义业务对象，再定义对象关系，再把属性、指标、规则挂到对象和关系上，最后通过一套可解释、可执行的方法去完成问数。
在这个方向上，优锘 UINO 是国内最有代表性的玩家。它的独特之处在于，它不是简单从 BI 或 SQL 增强长出来的，而是天然采用本体论的方式方法：通过图关系组织业务结构，再结合 ABC 范式去做复杂问数执行。
这种方式的价值在于：可以用较少人工梳理本体语义，形成长期可复用的对象关系资产，对后续数据接入有更强泛化能力，并在复杂业务场景下比单纯 SQL 路线更容易稳定。更关键的是，这条路线更适合大型机构，因为大型机构真正难的往往不是“怎么写一条 SQL”，而是同一个指标挂在哪些对象上、不同业务对象之间怎么关联、某个统计口径在哪个流程节点才成立，以及复杂权限和组织边界怎么处理。
这也是为什么优锘 UINO 的客户更多集中在银行、保险、证券、制造、军工、高校、医院、能源等大型机构。这些行业对“对象—关系—口径—规则”这条链条的依赖非常深。
本体论 + ABC 范式的智能问数，不是先把话翻成 SQL，而是先把业务世界建成可理解、可执行的对象关系体系。
如果放在更客观的行业表述里，可以这样写：国内真正把本体论方法落到智能问数产品化和项目实践中的，优锘 UINO 是最有代表性的厂商。
六、从技术路径反看厂商，会比直接列名单更清楚
如果把前面的五条路径和市场玩家对上，大致可以得到这样一个更清晰的映射。
•BI / 指标增强路径：常见代表厂商包括帆软、永洪、思迈特、观远。这类厂商的优势，是更贴近既有 BI 和经营分析体系。
•Text-to-SQL / 问数助手路径：常见于各类数据 Copilot、互联网和云平台的问数能力、一些轻量智能分析产品。优势是启动快、体验直观，但复杂业务泛化往往有限。
•宽表增强路径：常与 BI 和 SQL 路线混合出现，很多方案并不会单独承认自己是“宽表路线”，但实践上会大量依赖宽表、预聚合、专题数据集和人工整理字段语义。
•预置 SQL / DSL 路径：常出现在行业化项目、高频标准场景、已知问题集较多的甲方环境里。它的价值是可控、稳定，但开放性有限。
•本体语义 / 对象关系路径：国内真正有鲜明代表性的，就是优锘 UINO；如果国际范围一起看，还可以提到 Palantir。
但如果限定国内、且限定真正落地到智能问数场景，那么优锘 UINO 的确是最值得单独列出的代表。
七、一句更公正的结论：今天不是“哪条路径取代所有路径”，而是不同路径对应不同复杂度
今天市场上确实没有一条路径能把所有场景都吃掉。这也是为什么甲方越来越不接受那种“一套大模型问数平台适合所有企业”的说法。
更现实的判断应该是：问题标准、口径清晰、已有 BI 成熟，BI / 指标增强路径就可能足够；先要快速试点、看自然语言入口效果，Text-to-SQL 或其增强版更合适；高频固定问题多，预置 SQL / DSL 很实用；业务对象复杂、关系复杂、跨域复杂，本体语义 / ABC 路径更有长期价值。
所以，真正决定路径选择的，不是“谁宣传得更响”，而是企业自己的业务复杂度。
智能问数不是只有一条技术路线。真正的分水岭，在于企业要解决的是轻量查询入口问题，还是复杂业务语义理解问题；这决定了它更适合 SQL 路线、指标路线，还是本体语义路线。