最新的AIEY脉搏调查显示，87%的高级管理人员指出，AI应用面临诸多障碍，包括网络安全和数据问题，以及政策与治理缺失。将生成式AI（GenAI）融入业务，既要有意愿，也要有能力付诸实践。两者之间的差距源于运营复杂性，以及对这项新技术可信度的要求。
数十年来，企业一直在构建和部署软件，但生成式AI（GenAI）带来了一项新挑战：控制。与传统软件不同，GenAI应用具有自主性和非确定性。因此，至少目前还不能确信GenAI应用只会执行预期操作，而绝不会执行任何非预期操作。控制能力不足制约了全面采用。通过分析上下文的作用，可以更深入地理解控制方面的挑战，并据此扩展传统软件设计，使其适应GenAI。
有了足够的上下文，GenAI应用的不确定性就变得可控，因为上下文能够弥合GenAI应用能力与业务意图之间的差距。上下文可来自三个领域：GenAI应用、环境和业务。
应用上下文对比
GenAI应用中可用的上下文与传统应用有显著差异。传统应用会预先确定允许的输入，并将其作为预定义操作的参数。相同的输入始终会产生相同的结果。相比之下，GenAI应用可接受更广泛的输入，并将其传入大语言模型（LLM）；这类模型在设计上会产生非确定性输出。相同的输入可能会产生相同的结果，也可能不会。
传统应用确定性示例：
此Python示例使用出生日期和当前日期计算一个人的年龄。为简洁起见，示例未包含类型处理，以及判断当年生日是否已过等完善逻辑。
from datetime import datetime
from typing import Union
def calculate_age(birthdate:str, current_date:str) -> int
age = current_dt.year - birth_dt.year
return age
已知：出生日期 = 1972 年 6 月 30 日，当前日期 = 2025 年 8 月 31 日
年龄 = 53 岁。
生成式 AI 应用非确定性示例：
此应用无需知道某人的出生日期或当前日期，即可利用更概括的信息推测其大致年龄。
生成式AI应用可接受多种输入，用于大语言模型推理。
提示词：一个喜欢迪斯科音乐，并且记得巴塞罗那奥运会女子100米金牌得主的人有多大年纪？
将这一确切提示词分别输入大语言模型3次后，得到的回答如下：
回答1：55岁
回答 2：40 至 60 岁
回答3：40多岁、50多岁或60多岁
传统应用程序中的Python函数接受两个输入值（出生日期和当前日期），并计算两者相差的年数。由于无法综合信息或得出结论，该函数不能推断一个人的年龄，也不能接受对其偏好、习惯等方面的描述。
相比之下，GenAI应用可以接收有关童年时期流行音乐类型的陈述，并结合重大体育赛事的常识推导出回答。但由于输入中的细微差异（包括问题表述方式或温度设置的变化，温度设置会影响LLM回答的随机程度），答案可能有所不同。即使两次回答之间的应用代码没有变化，回答也可能不同。提示词越复杂、纳入的其他输入源越多，以及推理基础设施中路由组件的行为变化，回答的差异就越大。
鉴于这种灵活性，不难想象，在缺少额外上下文的情况下，生成式AI应用可能会严重偏离预期行为。上述两个上下文示例说明了传统软件的高度确定性与生成式AI应用的非确定性。通常不会要求传统软件根据上下文猜测或预测某人的年龄，但生成式AI应用需要经常处理这类非确定性问题。如果应用包含的上下文不足，接下来就必须考察应用环境。
环境上下文从外部为应用提供信息
环境由应用周边的基础设施和服务组成。早在1982年7月的计算机行业研讨会CreativeThink上，Alan Kay曾说：“真正认真对待软件的人应该自己制造硬件。”他之所以这样说，是因为他深信软硬件之间联系紧密。我想进一步延伸这一观点，将部署环境也纳入其中。
应用并非孤立运行。各种基础设施服务共同为应用提供运行环境。这些服务虽然位于应用之外，却像硬件一样，对应用正常运行至关重要。进一步来说，需要使用各种可观测性解决方案对这些基础设施服务进行细致监控，持续收集和跟踪丰富的遥测数据。这些数据反映应用的运行状况，以及周围环境可能对其产生的影响。
环境上下文可分为两类：被动型和主动型。各类遥测数据（例如日志、指标、跟踪和事件）均可视为被动型，因为在基础设施和应用运行期间，这些数据会持续生成并被收集。警报、通知和仪表板则属于主动型。它们使用规则解读遥测数据并传达运维上下文。通过调整规则，可以赋予这些信息运维意义，判断整个环境中各处的容差何时接近或超出阈值。
GenAI应用给基于规则的方法带来了挑战，因为目前尚无可靠的遥测数据能够涵盖自主组件近乎无限的潜在行为。但这并不意味着相关创新停滞不前。目前正在尝试两种方法：用于衡量GenAI成效的领域指标，以及LLM-as-a-Judge。前者通过其他方式确定基准事实，再与GenAI的结果进行比较，并统计成功率和失败率。后者使用一个LLM来评判另一个LLM的准确性。这两种截然不同的方法能在多大程度上利用环境上下文实现对GenAI的真正控制，仍有待时间检验。
业务意图让上下文信息更加完整
业务意图可定义为：“涵盖企业希望发生的一切，排除企业不希望发生的一切。”它涵盖了应用和环境可能遗漏的情况。
近期新闻报道了这样一个案例：某应用的GenAI组件被授予了过高权限，因而能够执行破坏性极强的操作，例如删除数据库中的所有客户记录。以下是该事件中的一些数据点，说明业务意图与GenAI应用可能执行的操作之间存在差距。
| 事件经过 | 缺失的业务背景 |
|---|---|
| AI编码工具在代码冻结期间删除了生产数据库。 |
|
| AI编码工具声称不支持数据库回滚，也没有可用于恢复的实例，但手动执行回滚实际上成功了。 |
|
本案例研究展示了生成式 AI 获准执行的操作与企业期望其执行的操作之间可能存在的诸多差距中的几个。
为应用设计删除记录的功能完全合理，但允许AI未经许可删除所有记录则不合理。在传统软件中，删除记录的权限会受到限制，以降低业务损失风险；但GenAI引入了自主性，而基于角色的访问控制无法充分管控这种自主性。业务上下文可明确预期行为与非预期行为，并将其转化为具体要求，包括明确禁止的操作，以及必须暂停并由人工介入的情形。正是完整的上下文实现了这种程度的控制。
在生成式AI出现之前构想的应用架构已无法满足需求。生成式AI的出现需要一种新的架构模式，将应用、应用环境和业务意图这三个上下文领域结合起来。Google DeepMind高级AI关系工程师Phil Schmid的这篇解读尤其有助于理解生成式AI应用带来的关键变化。文中强调，大语言模型（LLM）的输入中包含上下文，并说明生成式AI应用的不同组件如何各自定义和使用上下文。
GenAI应用的架构和工程设计需要充分利用全部三个上下文域，才能使结果始终与业务意图保持一致。如果缺乏完整的上下文全貌，控制将形同虚设，信任也无从建立，更无法实现全面采用。
关于作者
相关博客文章
