业务黑话太多，AI 问数怎么听懂同一个意思？

企业做 AI 问数时，经常遇到一个看似很小、实际很关键的问题：

业务人员不会按照数据库字段名提问。

数据库里可能叫 gross_profit_amount，财务说“毛利额”，运营说“毛利”，老板说“赚了多少钱”。

数据库里可能叫 channel_name，电商团队说“渠道”，投放团队说“流量来源”，门店团队说“来源平台”。

这些都不是用户表达不规范，而是企业真实业务语言。

AI 问数首先要听懂业务语言

如果 AI 只知道表名和字段名，它能回答的范围会很窄。

业务人员提问时，通常不会说“查询订单表中支付金额字段按门店维度聚合”。

他们会说：

• •昨天哪个门店卖得最好？
• •华东区这周赚得怎么样？
• •抖音渠道 ROI 为什么掉了？
• •这个新品在哪些城市起量？

AI 问数要进入业务场景，就必须把这些表达映射到正确的数据表、字段、指标和筛选条件。

常见的业务黑话类型

第一类是指标同义词。

例如销售额、GMV、成交额、实收金额，在不同公司可能代表不同口径。

第二类是组织别名。

例如华东、东区、一战区、上海大区，可能指向同一组组织节点，也可能有细微差异。

第三类是商品简称。

例如内部 SKU 名、商品企划名、直播间简称、供应链编码，往往不是同一套命名。

第四类是场景词。

例如“起量”“掉量”“爆品”“滞销”“睡眠会员”，这些词背后通常对应一组计算规则或判断条件。

不能只靠大模型猜

很多演示型 AI 问数会让模型直接猜用户意图。

这在简单样例里看起来很顺，但在企业场景里风险很高。

因为“销售额”到底是支付金额、发货金额、确认收入，还是剔除退款后的净销售额，不能靠模型自行决定。

可靠的做法，是把业务别名、指标说明、字段备注、示例问题和组织关系沉淀到可管理的语义配置里。

语义层要能持续维护

业务黑话不是一次性配置完的。

新活动会产生新叫法，新商品会产生新简称，新部门会形成新的问题表达。

因此，企业需要一个持续维护机制：

• •新增指标时同步写清业务含义；
• •高频问题沉淀为示例问法；
• •答错的问题回收为语义优化线索；
• •业务和数据团队共同确认关键口径；
• •让同义词、别名和字段说明可以版本化管理。

Snowflake Cortex Analyst 的语义模型、Microsoft Fabric Data Agent 的说明配置，以及 Databricks Genie 的指令和可信资产，都体现了同一个原则：AI 需要被业务上下文约束。

AskTable 的做法

AskTable 不把 AI 问数理解为“让用户说字段名”。

BuildTable 负责把原始表整理成更适合 AI 使用的数据基础，包括表说明、字段说明、指标定义和业务关系。

AskTable 在此基础上理解用户自然语言问题，把业务表达映射到正确的数据查询与分析路径。

当系统发现一个词有多种可能含义时，也应该支持澄清，而不是直接给出一个看似确定的答案。

结论

AI 问数真正要解决的，不是把自然语言翻译成 SQL。

它要把企业内部的业务语言、指标口径和数据结构连接起来。

业务黑话越多，越说明企业需要一个可维护的语义层，而不是只依赖模型临场猜测。

参考来源

• •Snowflake：Cortex Analyst Semantic Model Specification
• •Microsoft Fabric：Create a Fabric data agent
• •Databricks：Tune Genie Agent quality