【第5篇】在本体之上植入MCP，AI就会脱胎换骨

“告诉我Coupang的销售额。”

如果你曾把CSV丢给ChatGPT问过这个问题，就会知道结果有多不稳定。有时它只算Wing的销售额，有时连Rocket Growth也加进去，有时又按EZAdmin OMS的口径作答。同一个问题，每次得到的数字都不一样。

接入RAG（检索增强生成）、再喂入文档，情况也一样。即使你在文档里写明“经营管理仪表板的贡献利润率与按商品业绩中的实际贡献利润率分母不同”，AI在回答问题时会不会调出这条信息，全凭运气。

本系列讨论过的问题——商品名称冲突（第2篇）、库存与出库的偏差（第3篇）、广告费分摊（第4篇）——要让AI正确处理，数据之上必须有结构化的关系定义（本体），而且AI必须能够以工具的形式访问这些关系。

这个工具就是MCP（Model Context Protocol）。

为什么仅靠RAG行不通

基于文档的方法的局限

假设你把电商数据的业务背景整理成文档，放进RAG。

文档1：“净销售额 = 支付总额 - Cafe24退款 - Naver Pay退款”
文档2：“按商品业绩的分母是支付金额（扣除退款前）”
文档3：“Sabangnet数据的一致性可能较差”
文档4：“Coupang有Wing/RG/供应商中心3种来源”

无论文档写得多好，仍然存在三个问题。

1. 检索失败：当用户问“Anmod Pro的盈利情况”时，无法保证RAG会调出“文档1”。两者语义相关，但关键词不同。

2. 无法组合上下文：要计算Anmod Pro的贡献利润，需要同时用到文档1（净销售额计算）+第4篇的广告费分摊逻辑+第2篇的商品映射。RAG通常只检索Top-K文档，这三部分同时进入Top-K的概率很低。

3. 无法访问实时数据：文档里只有“净销售额是这样计算的”这类定义，没有实际数字。要回答“Anmod Pro本月的净销售额”，必须查询数据库。

真正需要的是：定义+数据+执行

MCP的作用

MCP是一种让AI能够调用外部工具的协议。我们运行着4个MCP服务器。

关键在于：AI收到问题后会直接查询数据库。不是上传CSV，而是生成并执行与问题相匹配的查询。

本体如何让MCP变得更聪明

示例：“告诉我Coupang的销售额”

只有MCP、没有本体时：

AI会向Trino发出查询，但它不知道该查哪张表。

-- AI生成的查询（不确定）
SELECT SUM(payment_amount) FROM orders WHERE channel = 'coupang'
-- 只算Wing？包含RG？供应商中心呢？按EZAdmin口径？

可能得出5种答案，而且每次都不一样。

本体+MCP时：

本体中有“Coupang销售额”的定义。

概念：Coupang销售额
  基准数据源：[COUPANG_ADMIN_WING, COUPANG_ADMIN_RG, COUPANG_SUPPLIER_HUB]
  汇总方式：3种来源合计，去除重复
  指标：支付金额（不含已发生的退款/取消）
  注意：可能与EZAdmin数据重复，以渠道API数据为准

AI参照这一定义，生成准确的查询。

SELECT SUM(payment_amount)
FROM (
  SELECT payment_amount FROM coupang_wing_orders WHERE ...
  UNION ALL
  SELECT payment_amount FROM coupang_rg_orders WHERE ...
  UNION ALL
  SELECT payment_amount FROM coupang_supplier_orders WHERE ...
)

示例：“分析一下Laplace Pro贡献利润下降的原因”

这一个问题，就要调动整个系列的内容。

1. 商品映射（第2篇）：查询与“Laplace Pro”关联的71个各渠道选项名称

2. 指标选择（第2篇）：贡献利润 = 支付金额 - 成本 - 广告费 - 手续费 - 运费 - 卖家承担运费

3. 广告费核查（第4篇）：从数据源B查询经过4步匹配分摊后的广告费

4. 渠道对比（第3篇）：Cafe24、Coupang、SmartStore各渠道的贡献利润走势

5. 原因推断：广告费增加？成本上涨？退款率上升？还是某个渠道出了问题？

由于本体定义了所有这些关系，AI只需一个问题就能自动执行5个步骤。

为什么会有“Claude专用数据”仪表板

事实上，我们的部分客户会专门搭建一个仪表板来存放提供给AI的数据。

仪表板：Claude专用数据
数据源A：基础商品订单（支付金额、成本、实际毛利、运费等10项）
数据源B：广告（广告费）
分析维度：日期 × 销售渠道 × 基础商品名称
汇总：按日，自2026-01-01起

这个仪表板不是给人看的，而是为AI回答问题提供预先关联好的数据集。

为什么需要它？

• 经营管理仪表板以净销售额为口径 → AI可能误以为这就是“销售额”

• 按商品业绩以支付金额为口径 → 又是另一种“销售额”

• Claude专用数据最接近未经加工的原始形态 → AI可根据需要自行汇总

两级CS标签改变AI对问题的理解

在CS数据上，本体的效果同样一目了然。

标签是扁平结构时：

标签：“AS”“退货”“退款”“配送”
→ AI：“AS共有50件。”（这能说明什么？）

标签是两级树状结构时：

标签1：AS/Laplace
标签2：故障/控制器故障、故障/制造故障、故障/充电故障
→ AI：“Laplace的50件AS中，控制器故障最多，为28件（56%）。
       较上月增加15件，需要排查质量问题。”

有了标签的层级结构（本体），AI就能一次性完成汇总 → 对比 → 原因推断。

实战清单：AX团队引入MCP的步骤

1. 从READ-ONLY开始——只允许AI查询数据，不允许修改。我们的Trino MCP也只开放SELECT/SHOW/DESCRIBE

2. 先搭建元数据MCP——让AI能够查询表清单、字段含义和关系定义

3. 建立指标词典——将“净销售额”“支付金额”“贡献利润”的准确公式和背景结构化

4. 把基准数据源策略植入MCP——在代码层面定义“Coupang销售额 = Wing+RG+供应商中心合计”

5. 先由人工验证——将AI的查询结果与仪表板数字核对，如有不一致，就补充完善本体

结语：本体 → MCP → AI，顺序很重要

把本系列的脉络梳理一下：

第1篇：为什么需要本体（定义数据关系）
  ↓
第2篇：商品名称冲突+指标冲突（同一事物的不同名称）
第3篇：OMS与渠道API的偏差（同一订单的不同数字）
第4篇：广告费分摊的4个步骤（素材→商品匹配）
  ↓
第5篇（本文）：AI通过MCP执行本体

丢给AI一个CSV，相当于给它一堆原材料；接入RAG，相当于在旁边放一本菜谱。本体+MCP则是把整个厨房布置好：让AI清楚食材在哪里、工具在哪里、各种食材之间是什么关系，然后再开始做菜。

如果你在电商AX团队，请在接入AI之前先搭建本体。这才是最快的路。

让AI读懂电商数据——系列第5篇（完结）