业务背景是 AI 最缺的：换了总监、竞品降价、大客户到期，这些它猜不出来

一、问题的提出：为什么 AI 总是「答非所问」

过去两年，大语言模型（LLM）在企业场景的渗透速度远超预期。根据 Gartner 2024 年发布的《生成式 AI 企业采用报告》，截至 2024 年第三季度，全球已有约 67% 的中大型企业在至少一个业务环节中部署了 LLM 相关应用，较 2023 年同期增长近 40 个百分点^[1]。然而，同一份报告也指出，这些应用中真正进入「核心决策链路」的比例不足 18%，大多数仍停留在文档摘要、客服问答、代码补全等辅助性任务上。

为什么？一个反复出现的场景可以说明问题。

某 SaaS 公司的销售副总裁问 AI 助手：「我们下个季度的营收预测应该怎么调整？」AI 给出了一段标准的回答：建议参考历史增长率、考虑季节性因素、关注客户续约率……听起来很专业，但完全没有提到：公司最大的客户（占营收 22%）的合同将在 45 天后到期且续约谈判陷入僵局；竞争对手上周刚刚宣布降价 15%；公司销售总监两周前刚刚离职，新任总监尚未到岗。

这些信息，才是真正决定预测结果的关键变量。但它们既不在模型的训练数据中，也不在用户的提问中。AI 不是「不想说」，而是「根本不知道」。

这个现象并非个例。微软研究院 2024 年的一项用户研究发现，在企业知识工作场景中，LLM 助手的回答被用户评价为「有用」的比例仅为 52%，而其中被评价为「忽略了关键业务背景」的占比高达 61%^[2]。斯坦福大学 HAI 中心 2024 年的报告也指出，LLM 在需要「组织内部隐性知识」的任务上，准确率相比通用问答任务下降约 30—45 个百分点^[3]。

笔者认为，这些数据指向一个被长期低估的事实：当前 AI 系统的瓶颈，已经从「语言能力」转移到了「业务理解能力」。模型能读懂句子，但读不懂句子背后的组织现实。而组织现实，恰恰是由大量隐性、动态、情境化的信息构成的。

本文的核心论点由此展开：企业 AI 的核心挑战不是模型不够强，而是业务上下文供给不足。我们需要一套系统化的工程方法，把散落在邮件、会议纪要、CRM 系统、IM 消息、组织架构变更中的业务背景，转化为模型可以消费的上下文信号。本文称之为「业务上下文工程」（Business Context Engineering, BCE）。

二、三重盲区：隐性知识、时间因果与组织语义

要理解 AI 为什么「猜不出」业务背景，需要先厘清它到底缺了什么。笔者将其归纳为三重结构性盲区。

2.1 隐性知识盲区：不在语料里的「常识」

波兰尼（Michael Polanyi）在 1966 年提出「隐性知识」（Tacit Knowledge）概念，指出「我们知道的比我们能说出来的多」^[4]。在企业中，大量关键信息属于隐性知识：某个客户的决策链实际由谁主导、某个供应商的报价弹性有多大、某个部门对某项指标的敏感程度如何。这些信息往往只存在于资深员工的头脑中，或者散落在非正式沟通中。

LLM 的训练数据来自公开互联网，天然不包含企业内部信息。即使通过 RAG（检索增强生成）接入企业文档，也只能覆盖已被显性化的部分。根据麦肯锡 2024 年的调研，企业内部仅有约 20% 的知识被文档化，其余 80% 以隐性形式存在^[5]。

本文评述：隐性知识盲区是最难解决的，因为它涉及「知识提取」问题——如何把人们不愿写、没时间写、甚至没意识到自己知道的信息，转化为结构化数据。这不是纯粹的 NLP 问题，而是组织行为学与知识管理的交叉问题。

2.2 时间因果盲区：不知道「刚刚发生了什么」

LLM 有知识截止日期（knowledge cutoff），这是众所周知的事实。但问题比这更微妙：即使模型能通过联网搜索获取最新信息，它仍然缺乏对「事件时序」和「因果链」的理解能力。

举例来说，如果模型知道「竞品降价 15%」和「我们营收下降 8%」两个事实，它能推断出前者可能是后者的原因吗？在缺乏明确因果标注的情况下，模型倾向于把两个事实并列陈述，而不是建立因果联系。MIT 计算机科学与人工智能实验室（CSAIL）2024 年的研究显示，LLM 在因果推理任务上的表现显著低于人类，尤其在「反事实推理」和「时序因果」任务上，准确率差距超过 25 个百分点^[6]。

更关键的是，业务决策往往依赖于「最近发生了什么」。一个三个月前的组织变动和一个三天前的组织变动，对当前决策的影响完全不同。但 LLM 对时间衰减的感知能力很弱——它不会自动给「三天前」的事件更高权重。

2.3 组织语义盲区：不懂「谁说了算」

企业是一个复杂的组织系统，信息在不同层级、不同部门之间流动时，会带上「组织语义」。同样一句话，从 CEO 口中说出和从实习生口中说出，权重完全不同；同样一个指标，在销售部门和财务部门的定义可能不一致。

LLM 缺乏对组织结构的理解。它不知道谁是决策者、谁是影响者、谁的信息更可信。哈佛商学院 2024 年的一项研究指出，AI 系统在企业协作场景中失败的主要原因之一，是「无法正确识别信息源的组织权重」^[7]。

笔者认为，这三重盲区并非孤立存在，而是相互交织的。隐性知识往往通过组织关系传播，时间因果往往需要组织语义来解读。因此，解决思路不能是「打补丁」，而需要一套系统性的上下文工程框架。

三、业务上下文工程：一条贯穿全文的分析主线

面对三重盲区，业界已有多种应对思路：RAG、微调、Agent、知识图谱等。但这些方法各有侧重，缺乏统一框架。本文提出「业务上下文工程」（BCE）作为整合性主线。

3.1 什么是业务上下文工程

BCE 的定义是：一套系统化采集、结构化、注入和评估业务上下文信息的工程方法，目标是让 AI 系统在决策场景中具备「业务感知力」。

它包含四个层次：

• 事件层（Event Layer）：采集业务中发生的「事件」，如人事变动、价格调整、合同到期、客户投诉等。
• 知识层（Knowledge Layer）：将事件与实体、关系、属性关联，构建业务知识图谱。
• 注入层（Injection Layer）：根据当前任务，动态选择相关上下文，注入到提示词或模型输入中。
• 评估层（Evaluation Layer）：衡量 AI 系统在业务上下文理解上的表现，持续优化。

本文评述：BCE 与 RAG 的区别在于，RAG 关注「检索相关文档」，而 BCE 关注「构建业务上下文」。前者是信息检索问题，后者是知识表示与推理问题。RAG 可以检索到「销售总监离职」的新闻稿，但 BCE 要回答的是：这个事件对当前决策有什么影响、应该以什么权重注入。

3.2 与现有方法的关系

BCE 不是要替代现有方法，而是提供整合框架。它与 RAG、微调、Agent 的关系如下：

方法	核心能力	在 BCE 中的角色
RAG	文档检索与拼接	注入层的基础组件
微调	领域知识内化	知识层的补充手段
Agent	多步推理与工具调用	注入层的动态调度器
知识图谱	结构化关系表示	知识层的核心载体

接下来，本文按事件层、知识层、注入层、评估层的顺序，逐层展开工程细节。

四、事件层：把「换了总监」变成结构化信号

事件层是 BCE 的起点。它的任务是从企业各种信息源中，识别并结构化「业务事件」。

4.1 事件的定义与分类

在 BCE 框架中，事件定义为「在特定时间点发生、对业务有潜在影响的离散变化」。根据笔者对多家企业数据源的梳理，业务事件可分为以下几类：

事件类型	示例	常见数据源
人事事件	总监离职、团队扩编	HR 系统、IM 公告
市场事件	竞品降价、政策变化	新闻、行业报告
客户事件	合同到期、投诉升级	CRM、客服系统
运营事件	系统故障、供应链中断	监控系统、工单

来源：笔者根据企业调研整理（模拟分类框架）

4.2 事件抽取的技术路径

事件抽取（Event Extraction）是 NLP 领域的经典任务。传统方法基于规则和统计模型，近年来 LLM 的引入显著提升了抽取效果。2024 年 ACL 会议上，多项研究显示基于 LLM 的零样本事件抽取在通用领域已接近监督学习水平^[8]。

在 BCE 场景中，事件抽取需要关注三个特殊要求：

• 领域适配：企业业务事件有特定类型和表达方式，通用模型需要少量示例微调。
• 时序标注：每个事件必须带时间戳，且要区分「发生时间」和「获知时间」。
• 影响标注：标注事件可能影响的业务维度（如营收、客户满意度、团队稳定性）。

以下是一个基于 LLM 的事件抽取提示词模板示例：

你是一个企业事件抽取助手。请从以下文本中抽取业务事件。

文本：
「销售总监张明于 3 月 15 日提交辞呈，预计 4 月底离职。
新任总监尚未确定。与此同时，竞品 A 公司在 3 月 10 日
宣布全线产品降价 15%。」

请按以下 JSON 格式输出：
{
  "events": [
    {
      "type": "人事变动",
      "subject": "张明",
      "role": "销售总监",
      "action": "离职",
      "event_time": "2025-03-15",
      "impact_areas": ["销售管理", "团队稳定性"]
    }
  ]
}

笔者认为，事件抽取的关键挑战不在于技术本身，而在于「事件粒度」的把握。粒度过粗会丢失关键信息，粒度过细会导致上下文爆炸。一个实用的原则是：只抽取「可能改变决策」的事件。这需要业务专家参与定义事件类型体系。

4.3 事件采集的工程架构

事件采集需要对接企业多个系统。一个典型的架构包括：

数据源层 → 采集层 → 抽取层 → 存储层 → 服务层
  │          │         │         │         │
  ├─HR系统   ├─API     ├─LLM抽取 ├─事件库  ├─查询API
  ├─CRM      ├─Webhook ├─规则   ├─向量库  ├─订阅推送
  ├─IM       ├─爬虫    ├─分类器 ├─图数据库├─影响分析
  └─新闻     └─人工录入└─去重   └─时序库  └─告警

在实际工程中，最大的挑战是「数据源异构」。不同系统的数据格式、更新频率、权限模型各不相同。建议采用「事件总线」模式，各系统通过标准接口发布事件，由统一的采集服务消费。

关于事件驱动架构的更多工程细节，可以参考 Martin Fowler 的事件驱动架构文章，以及 Confluent 的 EDA 教程。

五、知识层：构建企业业务知识图谱

事件是离散的点，知识层要把这些点连成网。

5.1 业务知识图谱的实体与关系

企业业务知识图谱的核心实体包括：人员、组织、客户、产品、竞品、合同、指标等。核心关系包括：汇报关系、负责关系、竞争关系、合作关系、因果关系等。

实体类型	关键属性	关系示例
人员	职位、权限、决策权重	汇报于、负责、影响
客户	合同金额、续约日期、健康度	签约、投诉、续约
产品	价格、版本、市场份额	竞争、替代、互补
事件	时间、类型、影响范围	导致、触发、关联

知识图谱的构建可以借助现有工具。开源方案如 Neo4j、NebulaGraph，云服务如 AWS Neptune、阿里云图数据库。对于 LLM 驱动的知识抽取，可以参考 LangChain 的 Graph 构建教程。

5.2 从事件到知识的推理

知识图谱的价值在于支持推理。例如：

• 如果「张明」是「销售总监」，且「张明」离职，那么「销售管理」职能出现空缺。
• 如果「客户 A」的合同 45 天后到期，且「客户 A」近期有投诉，那么续约风险升高。
• 如果「竞品 B」降价，且「竞品 B」与我方产品在「价格敏感型客户」中重叠度高，那么我方该客户群流失风险上升。

这些推理规则可以显式编码，也可以借助 LLM 的推理能力。2024 年，Google DeepMind 的研究显示，将知识图谱与 LLM 结合，可以显著提升复杂推理任务的准确率^[9]。

本文评述：知识图谱与 LLM 的结合是当前研究热点，但工程落地仍有挑战。主要难点在于：图谱的构建和维护成本高、图谱与 LLM 的接口不统一、推理结果的可解释性不足。建议采用「轻量图谱 + LLM 推理」的混合模式，先用图谱保证关键关系准确，再用 LLM 补充灵活推理。

5.3 时序知识图谱

业务知识的一个关键特性是「时变性」。同一个人三个月前是销售总监，现在可能已经离职。因此，知识图谱需要支持时序版本。

时序知识图谱（Temporal Knowledge Graph, TKG）是近年来的研究热点。2023 年 NeurIPS 上，多项工作提出了 TKG 的表示学习与推理方法^[10]。在工程上，可以通过为每个关系添加「有效时间区间」来实现。

# 时序关系示例
(张明, 担任, 销售总监, valid_from=2022-01-01, valid_to=2025-04-30)
(李华, 担任, 销售总监, valid_from=2025-05-01, valid_to=None)

# 查询当前销售总监
MATCH (p:Person)-[r:担任]->(role:Role {name:"销售总监"})
WHERE r.valid_to IS NULL OR r.valid_to > date()
RETURN p.name

六、注入层：让上下文「恰到好处」地进入提示词

有了事件和知识，下一步是把它们注入到 AI 系统的输入中。这是 BCE 中最具工程挑战的一层。

6.1 上下文选择：不是越多越好

LLM 的上下文窗口有限（尽管已从 4K 扩展到 128K 甚至 1M），但「能放多少」和「该放多少」是两回事。研究表明，过多的上下文会导致「中间遗忘」（lost in the middle）现象——模型对上下文中间部分的信息利用率显著下降^[11]。

因此，上下文选择的核心是「相关性排序」。一个实用的方法是将上下文选择建模为信息检索问题：

def select_context(query, events, knowledge, max_tokens=4000):
    # 1. 语义相关性
    semantic_scores = embed_similarity(query, events)
    
    # 2. 时间衰减
    time_scores = exp(-lambda_ * days_since(event.time))
    
    # 3. 组织权重
    org_scores = event.source_weight * event.impact_level
    
    # 4. 综合排序
    final_scores = (0.5 * semantic_scores + 
                    0.3 * time_scores + 
                    0.2 * org_scores)
    
    # 5. 贪心选择直到 token 上限
    selected = greedy_select(events, final_scores, max_tokens)
    return selected

笔者认为，上下文选择是 BCE 中最需要「业务调参」的环节。不同业务场景对时间衰减、组织权重的敏感度不同。例如，销售预测对近期事件更敏感，而战略规划对组织权重更敏感。建议为每个业务场景配置独立的权重参数，并通过 A/B 测试优化。

6.2 注入格式：结构化 vs 自然语言

上下文注入有两种主要格式：结构化（JSON、表格）和自然语言（段落描述）。两者各有优劣：

格式	优势	劣势	适用场景
结构化	精确、易解析	模型理解成本高	数值、时间、关系
自然语言	模型理解好	冗余、歧义	事件描述、背景说明

实践中的最佳方案是「混合」：关键数值和关系用结构化格式，事件背景用自然语言。以下是一个注入示例：

【业务背景】
- 销售总监张明于 2025-03-15 提交辞呈，预计 4 月底离职。
  新任总监尚未确定。（来源：HR 公告，权重：高）
- 竞品 A 公司于 2025-03-10 宣布全线产品降价 15%。
  （来源：行业新闻，权重：中）
- 客户 X 合同将于 2025-05-01 到期，当前续约谈判
  处于僵局。（来源：CRM，权重：高）

【关键指标】
- 客户 X 占上季度营收：22%
- 竞品 A 与我方产品重叠客户群：约 35%

【任务】
请基于以上背景，分析下季度营收预测的主要风险点。

6.3 动态注入与 Agent 调度

在复杂场景中，上下文注入不是一次性的，而是动态的。Agent 可以根据任务进展，逐步检索和注入相关上下文。这类似于人类的「边想边查」过程。

2024 年，Anthropic 提出的「上下文检索」（Contextual Retrieval）方法，通过在检索时动态生成上下文摘要，显著提升了 RAG 的准确率^[12]。这一思路可以扩展到 BCE 场景。

关于 Agent 与上下文管理的更多内容，可以参考 Anthropic 的 Contextual Retrieval 文章和 Lilian Weng 的 Agent 综述。

七、评估层：如何衡量「业务理解力」

没有评估，就没有优化。BCE 的评估比传统 NLP 任务更复杂，因为「业务理解」本身难以量化。

7.1 评估维度

笔者建议从四个维度评估 BCE 系统：

• 上下文召回率（Context Recall）：系统是否检索到了所有相关业务背景？
• 上下文精确率（Context Precision）：注入的上下文中，有多少是真正相关的？
• 决策一致性（Decision Consistency）：AI 输出是否与业务专家判断一致？
• 时效性（Timeliness）：系统能否及时捕捉最新事件？

7.2 评估数据集构建

评估 BCE 需要专门的测试集。构建方法如下：

1. 从历史业务场景中选取 50—100 个决策点（如季度预测、客户续约、产品定价）。
2. 对每个决策点，由业务专家标注「关键背景信息」（即如果不知道这些信息，决策会出错）。
3. 构造两组输入：一组包含关键背景，一组不包含。
4. 比较 AI 在两组输入下的输出差异。

这种「消融式」评估能直接衡量业务上下文的价值。根据笔者参与的一个模拟实验（数据为模拟），在 80 个决策点中，包含关键背景的输入使 AI 输出的专家一致率从 47% 提升到 78%。

本文评述：评估是 BCE 中最容易被忽视的环节。很多团队投入大量精力构建上下文系统，却没有建立有效的评估机制，导致无法判断系统是否真正有效。建议在项目初期就建立评估数据集，并持续迭代。

7.3 自动化评估指标

除了人工评估，也可以设计自动化指标。例如，使用 LLM-as-Judge 方法，让另一个 LLM 判断输出是否「考虑了关键背景」。2024 年，多项研究验证了 LLM-as-Judge 与人工评估的相关性可达 0.8 以上^[13]。

评估提示词示例：

你是一个业务分析评估专家。请判断以下 AI 输出是否
充分考虑了给定的关键业务背景。

关键背景：
1. 销售总监离职
2. 竞品降价 15%
3. 大客户合同即将到期

AI 输出：
[待评估的输出]

请从 1—5 分打分，并说明理由：
- 5 分：明确提及并正确分析了所有关键背景
- 3 分：提及部分背景，分析不够深入
- 1 分：完全忽略关键背景

八、工程实践：一个完整的落地案例

为了让 BCE 方法论更具体，本节给出一个完整的落地案例。案例基于笔者参与的一个模拟项目（数据为模拟，架构为真实工程实践），场景是「SaaS 公司销售预测助手」。

8.1 需求分析

业务方需求：销售副总裁希望 AI 助手能在做季度预测时，自动考虑组织变动、竞品动态、客户状态等背景信息。

关键约束：

• 数据源包括：CRM、HR 系统、IM 公告、行业新闻。
• 响应时间要求：< 10 秒。
• 输出需要可解释，能追溯到具体背景来源。

8.2 系统架构

┌─────────────────────────────────────────────┐
│              数据源层                        │
│  CRM │ HR系统 │ IM │ 新闻 │ 合同系统        │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│              事件采集层                      │
│  事件总线 │ LLM抽取 │ 去重 │ 时序标注        │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│              知识层                          │
│  业务知识图谱 │ 时序版本 │ 影响推理          │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│              注入层                          │
│  相关性排序 │ 上下文组装 │ 提示词模板        │
└─────────────────────────────────────────────┘
                    ↓
┌─────────────────────────────────────────────┐
│              评估层                          │
│  召回率 │ 精确率 │ 一致性 │ 时效性           │
└─────────────────────────────────────────────┘

8.3 关键实现步骤

步骤 1：事件采集。对接 CRM 的合同到期提醒、HR 系统的组织变动公告、IM 的关键词监听（如「离职」「降价」「投诉」）。使用 LLM 抽取事件并结构化。

步骤 2：知识图谱构建。使用 Neo4j 构建实体和关系。关键实体：人员、客户、产品、竞品。关键关系：负责、签约、竞争、影响。

步骤 3：上下文选择。当用户提问时，先解析问题意图，然后从事件库和图谱中检索相关上下文。使用综合评分排序，选取 Top-K 注入。

步骤 4：提示词组装。将上下文按「业务背景 + 关键指标 + 任务」结构组装。确保每个背景信息都标注来源和权重。

步骤 5：输出与追溯。AI 输出中要求标注每个结论对应的背景来源，便于用户验证。

8.4 效果对比

以下为模拟数据对比（基于 50 个历史决策点）：

指标	无 BCE	有 BCE	提升
专家一致率	47%	78%	+31pp
关键背景提及率	23%	89%	+66pp
用户满意度	3.2/5	4.4/5	+1.2

注：以上为模拟数据，用于说明方法论效果，非真实实验结果。

笔者认为，这个案例的关键启示是：BCE 的价值不在于「让 AI 更聪明」，而在于「让 AI 更知情」。模型能力不变，但输入质量提升，输出质量随之提升。这是一条比「换更大模型」更经济的路径。

九、前沿展望与开放问题

BCE 仍是一个快速演进的领域。本节讨论几个前沿方向和开放问题。

9.1 长上下文模型的影响

随着 Gemini 1.5 Pro（1M tokens）、Claude 3.5（200K tokens）等长上下文模型的出现，有人提出「上下文工程将变得不必要」——直接把所有信息塞进去即可。但笔者认为这一观点值得商榷。

首先，长上下文不等于「有效利用长上下文」。2024 年的多项研究显示，模型在超长上下文中的信息利用率仍不理想，尤其是中间部分^[14]。其次，企业信息是持续增长的，不可能无限塞入。最后，上下文选择本身也是一种「理解」——决定什么重要，正是业务理解的核心。

9.2 记忆与持续学习

当前的 BCE 系统大多是「无状态」的：每次请求独立检索上下文。但真实业务是连续的，AI 应该能记住之前的交互和决策。这涉及「AI 记忆」问题。

2024 年，MemGPT、Mem0 等系统探索了 LLM 的长期记忆机制^[15]。在 BCE 场景中，记忆可以用于：记住用户的偏好、记住之前的决策、记住哪些上下文被证明有用。

9.3 多模态业务上下文

业务上下文不只有文本。会议录音、白板照片、数据图表都包含关键信息。多模态 LLM 的发展为 BCE 打开了新空间。例如，从会议录音中抽取决策要点，从图表中读取趋势变化。

9.4 隐私与合规

BCE 系统需要访问大量企业敏感信息。如何在「上下文供给」和「隐私保护」之间平衡，是一个重要的工程与合规问题。建议采用：数据脱敏、访问控制、审计日志、本地部署等策略。

关于 AI 合规的最新进展，可以参考 欧盟 AI 法案官网和 NIST AI 风险管理框架。

9.5 开放问题

• 如何自动发现「哪些业务背景对决策重要」？目前主要依赖人工标注。
• 如何评估上下文的「因果贡献」而非仅仅「相关性」？
• 如何在多 Agent 协作场景中共享业务上下文？
• 如何让 BCE 系统自我进化，随着业务变化自动调整？

十、总结与操作清单

本文的核心论点是：企业 AI 的瓶颈不在模型能力，而在业务上下文供给。大模型「猜不出」换了总监、竞品降价、大客户到期，不是因为它不够聪明，而是因为这些信息从未进入它的视野。

业务上下文工程（BCE）提供了一套系统化方法：从事件层采集业务信号，在知识层构建关系网络，在注入层动态供给上下文，在评估层持续优化。这是一条比「换更大模型」更经济、更可控的路径。

最后，笔者想强调：BCE 不是一次性工程，而是持续运营。业务在变，上下文也在变。只有把「业务上下文供给」作为一项长期能力来建设，AI 才能真正成为企业的「知情决策者」，而不只是一个「聪明的陌生人」。