# 知识图谱 / 本体提取的价值场景

## 什么时候知识图谱没用

小规模、单系统、信息在人脑里能管住的场景。

- 200 人公司、150 个客户、十几条产品线 — 人脑 + Excel 完全覆盖
- 数据集中在一两个 Excel 里，Ctrl+F 比任何 query 工具快
- 存进图谱的信息用户本人已经全部掌握，图谱只是换了格式存了一遍
- 没有下游消费者（Agent、BI、数据中台），图谱是死数据

**判断标准**：如果用户的反应是"这些我都知道"，说明图谱没有产生增量价值。

## 什么时候知识图谱有用

### 场景一：跨系统概念对齐（本体的核心战场）

多个系统对同一业务概念使用不同名称、不同字段、不同粒度。

例：某大型集团几万人、几十个子公司、几百个系统。CRM 里叫"蓝天航空"，计费系统里叫"蓝天"，合同系统里叫"蓝天航空有限责任公司"，订座终端里是三字码 "LT"。四个名字指向同一业务实体。

本体提供跨系统的概念对齐层，让"蓝天航空去年给集团贡献了多少收入"这类问题可以被回答 — 因为它知道四个名字是同一个东西，数据分散在五个系统里。

**适用条件**：3+ 个异构系统、实体名称不统一、需要跨系统聚合查询。

### 场景二：Agent 的事实基座（与 LLM 产品直接相关）

Agent 最大的问题是幻觉。客户问"我们用了蓝天信息哪些产品"，Agent 没有事实基础就会编。

知识图谱不是给人查的，是给 Agent 查的：
- 客户来电 → Agent 先查图谱拿到客户画像（产品、在建项目、客户经理）→ 带上下文回答
- 写投标书 → Agent 查"我们在同类机场做过哪些项目" → 生成经验描述
- 售前准备 → Agent 查"这个客户去年有什么工单/投诉" → 风险预判

Agent 对话前自动 query 图谱、注入上下文，比人手动喂 prompt 高效一个量级。

**适用条件**：有 Agent 产品需要事实性回答、客户/产品/项目信息分散在多个文件中。

### 场景三：规模化模式发现

150 个客户没什么好分析的。但几千个客户、几万个合同、十几年的交易记录拉通后，知识图谱能发现：
- 哪些客户在流失（三年没新项目）
- 哪些产品组合最常被一起采购（交叉销售机会）
- 哪些项目团队复用率最高（能力中心在哪）

Excel 做不了这个 — 数据分散在几十个文件、字段名不统一、时间跨度太大。

**适用条件**：实体数 >1000、关系密度高、需要发现非显性模式。

## 个人知识图谱的定位

个人知识图谱（Mode B）的真实价值是：

1. **练手 + 验证 Skill 可用性** — 在自己数据上跑通全流程，才能在客户数据上有信心
2. **Agent 上下文注入的 PoC** — 证明"图谱 + Agent"模式可行，再推广到产品
3. **跨时间的记忆外存** — 三年后你忘了某个项目的关键人物，图谱还记得

不要期望个人图谱本身产生直接业务价值。它的价值在于**作为能力验证和产品原型**。

## 本体提取的核心交付物（咨询视角）

对客户项目（Mode A）做本体提取，交付物是：

| 产出 | 客户价值 |
|------|---------|
| 实体目录（业务语言命名） | 客户第一次看到自己有多少业务概念 |
| 跨系统映射表 | 知道哪些系统在说同一件事 |
| 关系网络图 | 理解实体间的依赖和影响链 |
| review_flag 清单 | 标出需要业务专家确认的模糊判断 |

这才是咨询式营销要卖的东西 — 不是"帮你建知识图谱"，而是"帮你看清自己的数据资产长什么样"。