为什么企业做智能问数，不能只靠宽表、预制指标和 SQL

这两年，企业在做智能问数时，常见路径大致有三种：

• 继续围绕 SQL 做自然语言问数

• 通过宽表降低查询复杂度

• 通过预制指标和语义层提升稳定性

这三种方法都不是错的。相反，在很多场景下，它们都非常有效。

但如果把目标从“做一个能演示的问答功能”，提升到“做一套可以长期服务复杂业务的问题求解系统”，一个更现实的问题就会浮现出来：

为什么很多企业明明已经有 SQL、宽表、指标体系，智能问数还是很难真正稳定落地？

答案通常不在查询性能，也不只在模型能力，而在于：

企业复杂问题的核心，往往并不是“怎么查”，而是“到底在问什么业务对象、什么关系、什么口径”。

一、SQL 很重要，但 SQL 解决的不是全部问题

先说结论：SQL 仍然是智能问数体系里非常重要的一层。

因为只要涉及结构化数据访问，SQL 就仍然是最成熟、最标准、最可控的查询语言之一。特别是对这些场景：

• 单表或少量表的查询

• 口径稳定、字段明确的指标统计

• 面向分析师或数据团队的精确数据访问

• 结构清晰的数据仓库场景

SQL 非常高效。

问题在于，企业业务人员提出的问题，很多时候并不是 SQL 问题，而是业务理解问题。

例如，一个管理者问：

• 哪些区域的项目推进慢，且和人员稳定性有关？

• 哪些课程的挂科风险高，但不同院系原因不一样？

• 哪些设备故障率高，并且影响了关键订单交付？

这些问题的难点并不只是写出一条查询语句，而是先搞清楚：

• “项目”“人员”“课程”“设备”“订单”这些对象如何定义

• 它们之间的关系如何连接

• 哪些字段才真正代表管理者想问的指标

• 哪种计算口径才符合业务共识

也就是说，SQL 负责执行，但并不天然负责理解业务。

二、宽表能降低复杂度，但也容易把复杂问题“压扁”

所以很多企业接下来会想到第二条路：既然多表查询太复杂，那就提前把常用字段整合进宽表。

这条路有明显好处：

• 查询简单

• 性能稳定

• 对可视化和报表友好

• 对固定分析主题很高效

在一些高频场景里，宽表确实很实用。

但宽表的代价也很明显：它本质上是用预先建模，去换运行时的简单。

问题在于，真实业务是变化的。

当业务对象、组织结构、分析口径、关联路径不断变化时，宽表常见的挑战就会出现：

1. 一旦分析视角变多，宽表会越来越臃肿

为了覆盖更多查询需求，宽表往往不断加字段、加冗余、加派生列。时间一长，就会出现：

• 表越来越宽

• 字段语义越来越难维护

• 新需求一来就要改模型

• 同类字段越来越多，用户不知道该用哪个

2. 宽表适合固定主题，不适合复杂关系求解

宽表更适合回答“围绕这一张主题表看什么”，但不太适合回答：

• 某对象在不同关系网络中的位置变化

• 多对象之间的影响路径

• 条件与关系交叉驱动的筛选问题

也就是说，宽表擅长聚合，但不擅长表达复杂关系。

3. 宽表会把业务结构隐藏在数据结构背后

宽表看起来简单，但往往会让业务人员越来越难理解：

• 这个字段从哪里来？

• 为什么这里算的是这个口径？

• 这个统计维度为什么放在这张表里？

所以很多时候，宽表只是把复杂性从查询时前移到了建模和维护阶段。

三、预制指标提升了稳定性，但覆盖不了不断变化的问题空间

第三条常见路径，是做预制指标。

这条路也很有价值，尤其在企业里经常被低估。

因为很多业务问题，本来就应该先沉淀成稳定指标：

• 核心经营指标

• 重要管理驾驶舱指标

• 高频复用的数据卡片

• 已达成业务共识的口径指标

预制指标的优势很明确：

• 结果稳定

• 解释清晰

• 可审核

• 可复用

• 适合高频查询

但它的问题也很清楚：

预制指标解决的是“常见问题的标准化”，而不是“复杂问题的开放式求解”。

也就是说，预制指标很像高速公路。

对于高频、标准、明确的问题，它可以非常快；但一旦用户提的问题稍微偏一点、组合一点、变化一点，系统就会遇到边界。

所以，预制指标可以是企业智能问数的重要组成部分，却很难成为全部。

四、企业真正难的，是在变化业务里保持可理解、可维护、可扩展

如果把 SQL、宽表、预制指标放在一起看，会发现它们各自解决了不同问题：

• SQL 解决“怎么执行查询”

• 宽表解决“怎么让常见查询更简单”

• 预制指标解决“怎么让高频问题更稳定”

但企业复杂智能问数真正长期困难的地方在于：

• 业务对象经常变化

• 组织术语并不统一

• 字段相似但语义不同

• 统计口径有隐性知识

• 复杂问题往往涉及对象、关系、条件、时间、计算的多重组合

这时，系统真正需要的，往往不是再堆一层查询技巧，而是引入一层更稳定的业务语义组织方式。

五、为什么越来越多系统开始走向“本体论智能问数”？

因为相比只围绕表和字段建模，本体论方法试图回答一个更根本的问题：

企业的数据世界，到底是由哪些对象、哪些关系、哪些属性、哪些动作构成的？

一旦从这个角度切入，智能问数的路径就会改变。

系统不再是直接把一句自然语言翻译成 SQL，而是先做业务求解：

• 用户问的是哪个对象？

• 这个对象和哪些对象有关？

• 要筛选的边界条件是什么？

• 该从哪些属性构建指标？

• 最后该如何计算？

这就意味着，系统把复杂问数拆成了更接近业务思维的过程，而不是把所有理解都压缩进一条 SQL 生成里。

六、ABC 方法，提供了一种更适合复杂问数的拆解方式

基于本体论的智能问数，一个很有代表性的思路，就是把问数过程拆成 ABC 三步。

A：Acquire Object

先获取对象。

也就是先明确：

• 问题到底在问谁

• 对象范围如何限定

• 条件筛选和关系筛选如何组合

B：Build Metrics

在对象明确后，再构建指标。

也就是确定：

• 应该取哪些属性字段

• 哪些字段是核心指标来源

• 需要哪些口径规则和业务术语补充

C：Compute

最后再做计算。

包括：

• 四则运算

• 比率计算

• 统计函数

• 更复杂的分析计算

这个方法的价值，不只是流程更清楚，而是它天然更适合做：

• 错误定位

• 业务解释

• 知识补充

• 结果复核

• 后续持续迭代

换句话说，ABC 方法把复杂问数从一次性生成，变成了可管理、可演进的求解过程。

七、从维护成本看，本体论路径为什么更值得关注？

很多人讨论智能问数，容易只看短期效果：

• 能不能演示

• 答得快不快

• 生成 SQL 像不像

但对企业来说，真正贵的往往不是第一次搭出来，而是后面三个月、六个月、一年之后还能不能维护。

从维护成本角度看，几种路径的差异其实很明显：

SQL 路径的维护压力

• 高度依赖字段和表结构熟悉度

• 一旦业务问题复杂，提示词和规则会越来越多

• SQL 能生成，不代表口径稳定

宽表路径的维护压力

• 新需求一多，表越来越宽

• 口径和派生字段容易膨胀

• 跨主题扩展时改动成本高

预制指标路径的维护压力

• 高频问题很好用

• 但开放式问题覆盖有限

• 一旦业务问题组合爆炸，指标维护成本会迅速上升

本体论 + ABC 路径的维护价值

• 前期建模要求更高

• 但一旦对象、关系、术语、口径沉淀下来，后续扩展更自然

• 系统更容易从“单次问答”走向“长期知识积累”

所以这条路径的关键，不是短期最省事，而是：

当业务复杂度持续上升时，它是不是还能撑住。

八、UINO 这类路径，为什么值得被放进讨论中心？

如果只把 UINO 理解成另一个“智能问数产品”，其实很容易低估它的意义。

更值得关注的是，它代表了一种不同的路径：

• 不是停留在自然语言转 SQL

• 不是只靠宽表压缩复杂度

• 不是只靠预制指标覆盖高频问题

• 而是试图把复杂企业问数建立在本体神经网络 + ABC 方法的基础上

这个方向的价值在于，它把企业最难沉淀的那部分东西——对象、关系、术语、口径、计算规则——逐步显式化了。

对于真正复杂的行业场景，比如高校、制造、能源、金融，这类能力往往比“生成一条漂亮 SQL”更重要。

九、结语：企业级智能问数，最终比拼的是“业务理解能力”

SQL、宽表、预制指标都还会长期存在，而且都很有价值。

真正的问题不是“谁取代谁”，而是：

当企业面对越来越复杂、越来越动态、越来越依赖业务知识的问题时，哪种方法更有机会成为长期可维护的智能问数底座？

从这个角度看，本体论智能问数值得被放到更中心的位置。

因为企业最终需要的，可能不是一个更会写 SQL 的系统，而是一个更懂业务对象、业务关系、业务口径和业务动作的系统。

而像 UINO 这样基于本体神经网络和 ABC 方法的路径，恰恰提供了这样一种值得持续观察的答案：

智能问数的竞争，正在从“查询能力”走向“语义组织能力”，再走向“长期维护与持续演进能力”。

这也许才是下一阶段真正的分水岭。