业务知识库不是资料归档，而是 AI 数据分析的上下文层

很多企业都有业务知识库。

里面有制度文档、指标说明、活动方案、销售政策、渠道规则、财务口径、商品分类说明和项目复盘。

过去，这些内容主要给人看。

业务新人查制度，运营查活动规则，数据同事查指标说明，管理层查复盘材料。

但到了 AI 数据分析场景，业务知识库的价值会发生变化。

它不再只是资料归档，而是 AI 理解企业业务的上下文层。

表结构不能解释所有业务问题

AI 问数看起来是在问数据库。

但业务问题往往不只存在于数据库里。

比如用户问：“这次活动效果为什么不好？”

数据库里可能有订单、流量、转化、客单价、库存和渠道数据。

但活动规则在哪里？优惠门槛是什么？活动覆盖哪些门店？目标人群是谁？是否叠加了会员权益？竞品同期有没有动作？

这些信息常常不在结构化表里，而在业务文档里。

如果 AI 只看数据库，它可能能算出转化率下降，却很难解释为什么下降。

业务知识库应该进入 AI 分析过程

企业级 AI 数据分析需要两类上下文。

一类是结构化数据上下文。

包括表、字段、指标、维度、字段值和权限。

另一类是业务知识上下文。

包括制度、规则、政策、活动方案、分析方法、业务黑话和历史复盘。

这两类上下文合在一起，AI 才能更接近业务人员真正的判断方式。

微软 Fabric Data Agent 的说明里，也把 instructions 和 example queries 作为配置的一部分。也就是说，数据 Agent 不只是连接数据源，还需要被告知应该如何理解和回答问题。

业务知识库，就是企业给 AI 的重要 instructions。

业务知识可以帮助 AI 做三件事

第一，理解指标和规则。

例如“有效订单”是否排除退款订单，“活跃会员”按消费频次还是登录行为判断，“活动期”按下单时间还是核销时间计算。

第二，解释异常。

例如某个城市销售下降，可能和天气、门店装修、渠道活动、库存缺货或区域政策调整有关。这些因素不一定都在交易表里。

第三，沉淀分析偏好。

业务团队可能习惯先看同比，再看环比；先拆区域，再拆渠道；先排除大促影响，再看日常经营。这些方法也应该成为 AI 可复用的上下文。

AskTable 如何承接业务知识

AskTable 的语义配置不应该只理解表和字段。

它需要把业务文档、指标说明、活动规则和分析偏好纳入 AI 数据分析过程。

BuildTable 负责把企业分散数据整理成 AI 可理解的数据基础。

AskTable 在此基础上，结合表字段说明、字段值索引、指标口径、业务文档和权限规则，让 AI 在回答问题时不只是“查到一个数”，而是能解释这个数和业务规则之间的关系。

例如，在分析投放 ROI 时，AI 不仅要知道花费、转化和 GMV，还应该知道不同渠道归因规则、活动周期和商品结构变化。

在分析门店异常时，AI 不仅要看销售额，还应该知道门店营业时间、区域活动和库存规则。

从资料库到上下文层

企业可以从一个很小的动作开始：

把 10 个高频业务问题背后的文档整理出来。

例如经营日报、投放复盘、会员分析、库存预警、活动复盘。

然后为每类问题补充：

• •使用哪些指标；
• •相关业务规则是什么；
• •常见例外情况有哪些；
• •应该先拆哪些维度；
• •哪些角色可以看哪些范围；
• •结果出来后通常做什么动作。

这些内容如果只放在人脑和文档里，就很难被 AI 稳定使用。

如果进入 AskTable 的业务上下文层，就可以持续提高 AI 问数和分析报告的可信度。

参考来源

• •Microsoft Learn：Fabric data agent creation
• •AWS：Context Engineering with Agents on Amazon Bedrock