AI 问数上线前，为什么要先准备一套标准问题集？

很多企业测试 AI 问数时，会让几个人随便问几句。

如果 AI 答对了，就觉得效果不错。

如果 AI 答错了，就觉得模型不行。

这种测试方式很直观，但不适合企业上线。

企业真正需要的不是一次演示里的“看起来能用”，而是长期可评估、可回归、可优化的 AI 数据分析能力。

这就需要一套标准问题集。

标准问题集不是 FAQ

FAQ 通常是给用户看的。

标准问题集是给系统验收和持续优化用的。

它应该覆盖企业真实业务里最常被问、最容易出错、最能体现价值的问题。

例如：

• •昨天销售额为什么下降？
• •本周哪些门店库存周转异常？
• •某个渠道的 ROI 变差，是流量问题还是转化问题？
• •新会员复购率按哪个口径计算？
• •区域经理能不能看到其他区域的数据？

这些问题背后不只是 SQL。

它们会同时考验数据源选择、指标口径、字段理解、权限控制、时间范围、异常归因和结果解释。

只测“能不能生成 SQL”是不够的

AI 问数的第一层能力，是能生成查询。

但企业关心的是：

这个查询是否选对了表？

是否使用了正确指标？

是否过滤了无效订单、测试数据和无权限数据？

是否能解释结果，而不是只返回一张表？

微软 Fabric Data Agent 的文档里，把 example queries 作为配置的一部分，用样例问题和查询逻辑帮助 Agent 形成更稳定的回答方式。它还要求示例查询和所选表结构匹配，未通过校验的查询不会被使用。

这说明企业级 Data Agent 不是只把自然语言丢给模型，而是需要把“好问题”和“正确解法”沉淀下来。

标准问题集应该怎么设计

一套可用的问题集，至少应该分成五类。

第一，高频经营问题。

例如销售、库存、投放、会员、毛利、订单、客单价等日常问题。

第二，指标口径问题。

例如 GMV、净销售额、有效订单、复购率、活跃会员、库存周转天数。

第三，权限边界问题。

同一个问题由老板、区域经理、门店店长、运营同事来问，答案范围应该不同。

第四，异常归因问题。

让 AI 不只是查一个数，而是沿区域、渠道、商品、客户、时间等维度拆解原因。

第五，不应该回答的问题。

例如越权数据、无业务定义的数据、缺少必要上下文的问题，系统应该拒答、追问或提示补充条件。

AskTable 如何使用标准问题集

AskTable 的落地不应该从“随便问”开始。

更好的方式，是先和业务团队一起整理一批真实问题。

BuildTable 负责把相关数据表、字段、指标和业务文档整理成 AI 可理解的数据基础。

AskTable 再围绕这些标准问题测试数据源选择、SQL 生成、权限过滤、解释质量和报告输出。

当问题集稳定后，它还可以继续用于版本回归。

每次调整语义配置、指标口径、权限规则或模型策略，都可以重新跑一遍核心问题，观察答案是否变好、是否退化、是否出现新的风险。

结论

AI 问数不是一次性演示能力。

它是一个需要持续评估和迭代的企业能力。

标准问题集的价值，是把“感觉准不准”变成“哪些问题能稳定回答，哪些问题还需要治理”。

企业越早建立这套问题集，越容易把 AI 问数从试用推进到可上线、可复制、可长期运营。

参考来源

• •Microsoft Fabric：Data Agent Example Queries
• •Microsoft Fabric：Create a Fabric Data Agent