华为大咖说 | 上下文工程:AI进入“理解时代”的必经之路

举报
华为云PaaS服务小智 发表于 2025/11/06 15:22:20 2025/11/06
【摘要】 本文来自华为云时习知公众号当前,人工智能在实际应用中面临诸多挑战:意图识别准确率遭遇瓶颈,在复杂场景下频繁出现“幻觉”,以及Agent在任务规划与执行中表现乏力等问题日益凸显。在这样的背景下,上下文工程应运而生,成为破解这些问题的关键路径。它有望打破现有局限,为AI系统注入更强的理解力与推理能力,引领其从混沌走向清晰,从片面走向全面。 然而,如何真正有效地构建和应用上下文工程?它应当以怎样的...

本文来自华为云时习知公众号

当前,人工智能在实际应用中面临诸多挑战:意图识别准确率遭遇瓶颈,在复杂场景下频繁出现幻觉,以及Agent在任务规划与执行中表现乏力等问题日益凸显。在这样的背景下,上下文工程应运而生,成为破解这些问题的关键路径。它有望打破现有局限,为AI系统注入更强的理解力与推理能力,引领其从混沌走向清晰,从片面走向全面。

然而,如何真正有效地构建和应用上下文工程?它应当以怎样的方式落地实施?又与我们早已熟悉的知识工程存在怎样的内在联系? 本文将围绕这些问题,逐步展开阐述,为你一一解答心中疑惑,揭示上下文工程背后的逻辑与实践路径


一、从上下文工程谈起


01
什么是上下文工程?


20256月,某AI公司的前研究员Andrej Karpathy带火了Context Engineering 概念。其核心定义:构建一个动态系统,旨在以正确的格式提供正确的信息和工具,从而使大语言模型(LLM)能够可靠地完成指定任务。


· Instructions / System Prompt:定义模型在对话中行为的初始指令集,可以/应该包括示例、规则等。

· User Prompt:用户的即时任务或问题。 

· State / History (short-term Memory):当前对话,包括用户和模型的响应,截至此刻。 

· Long-Term Memory:跨多次之前对话收集的持久知识库,包含学习到的用户偏好、过去项目的摘要或要求记住以备将来使用的事实。

· Retrieved Information (RAG):外部、实时的知识,来自文档、数据库或API的相关信息,用于回答特定问题。 

· Available Tools:模型可以调用的所有功能或内置工具的定义,比如check_inventorysend_email

· Structured Output:模型响应格式的定义,例如JSON对象。

通过抽象,可以得到这3个上下文类型:


AI问答环节中,有了上下文才能得到更准确的信息。主要涉及如下场景:

提升意图识别准确性

· 举例:用户说明天天气怎么样?,若结合上下文我在北京AI就能返回北京的天气,而不是默认城市或错误信息。

问数减少幻觉现象,增强可信度

· 举例:在数据问答中,AI若能结合历史对话和数据源上下文,就能避免生成不存在的数字或错误结论。

复杂任务处理

· 举例:在客服场景中,用户可能分多次描述问题,AI通过上下文记忆,能连贯理解并逐步解决用户问题。

增强个性化与用户适应能力

· 举例:音乐推荐系统根据用户近期听歌记录和情绪上下文,推荐更贴合心情的歌曲。

 提升Agent的规划与执行能力

· 举例:一个智能家居Agent在执行关闭客厅灯光任务时,若结合当前是晚上”“客厅无人等上下文,决策会更合理。

推动知识工程与AI深度融合

· 举例:在医疗问诊AI中,结合患者病史、当前症状、药品知识库等上下文,AI能给出更准确的辅助诊断建议。

 

总之,上下文是AI实现理解用户,理解环境,理解任务的关键钥匙,是通往真正智能服务的核心支撑




02
上下文工程与知识工程的关系是什么?

 

上下文说到底,终究是知识。知识需要不断建设,需要有对应的owner看护。但上下文知识又是比较特殊的知识,这些知识需要超高质量地生产,还需要模型能更精准地检索到。因此,上下文知识的生产和消费将会对知识工程带来挑战。



另外,上下文工程本身还有一些数据工程的参与,如主数据表管理,指标,维度建模等。

因此,无论是知识工程还是数据工程,上下文工程都要求相关知识或数据的生产和消费都要高质量,更精准。



二、AI面临哪些挑战?

 

当前AI已经进入爆发期,AI应用领域广泛,包括金融领域,医疗健康,推荐系统,计算机视觉等。尽管AI在多个领域展现了强大的潜力,但在实际应用中仍然面临一系列的挑战:

 数据的问题,如数据的质量,隐私,偏差;

 模型局限性问题,如泛化能力不足,可解释性差等;

 持续学习与更新的问题,如信息变化极快,但很多模型不能自我更新;

 资源,法规问题等等。

下面就常见的几个场景深入说明下:


01
意图识别准确率提升遇到瓶颈

以下是几个主要的挑战和瓶颈:

 

① 数据质量和数量

· 标注数据不足:高质量的标注数据对于训练高精度的意图识别模型至关重要。然而,在很多情况下,获取足够的标注数据既耗时又昂贵。

· 数据偏差:如果训练数据集中某些类别的样本过少或者存在偏差,会导致模型在这些类别上的表现不佳。

· 数据多样性不足:现实世界中的用户输入形式多样,包括不同的方言、口音、表达习惯等。如果训练数据缺乏多样性,模型可能无法很好地泛化到未见过的数据。

 

② 语言复杂性

· 多义性和模糊性:自然语言充满了多义词和模糊表达,同一个词语或句子在不同上下文中可能表示完全不同的意图。

· 语法结构变化:不同的语言有不同的语法结构,即使是同一种语言内部也存在大量的变体,这增加了理解的难度。

③ 上下文理解能力

· 缺乏上下文感知:许多意图识别系统难以有效地利用对话历史或其他背景信息来改进当前请求的理解准确性。

· 跨领域适应性差:现有的模型往往在一个特定领域内表现较好,但在跨领域迁移时性能会大幅下降。

④ 持续更新的需求

· 动态变化的语言环境:随着社会文化的发展,新词汇不断涌现,旧词汇的意义也可能发生变化。模型需要定期更新以适应这些变化。

· 实时反馈机制缺失:有效的意图识别系统应当能够根据用户的即时反馈进行自我调整,但目前大多数系统在这方面做得还不够好。

 

总之,面对复杂多样、持续更新的数据环境,依靠固定的大模型和提示词无法解决当前的问题

 


02
问数场景针对复杂场景出现幻觉

① 精确度和可靠性

· 数值处理:大模型擅长处理文本,但在处理精确的数值计算和比较时可能存在困难。例如,直接从文本中提取并准确处理复杂的数学运算(如百分比变化、比率计算等)可能不准确。

· 事实核查:尽管大模型可以生成看似合理的回答,但这些回答并不总是基于事实。尤其是在缺乏明确的数据支持时,可能会产生“幻觉”,即生成与实际情况不符的信息。

 

② 理解复杂查询

· 多层次逻辑:一些查询可能包含多个层次的逻辑关系(例如条件语句、嵌套查询),这对模型来说是一个挑战。理解和正确解析这类复杂查询需要较高的语言理解和逻辑推理能力。

· 上下文依赖:许多查询依赖于特定的上下文信息。如果模型无法充分理解整个对话的历史背景或相关联的信息,它可能会给出错误的回答。

 

 数据访问与集成

· 实时数据更新:大多数预训练的大模型都是基于固定时间点的数据集进行训练的,因此它们无法自动反映最新的数据变化。对于需要实时数据的应用场景,这成为一个显著的限制。

 

 个性化适应性

· 领域适应性差:虽然大模型具有较强的泛化能力,但在特定领域的专业术语和特定业务逻辑的理解上仍存在不足。未经微调的大模型可能无法很好地适应某些特定行业的特殊需求。

·  用户偏好识别:为了提供个性化的服务,系统需要识别用户的偏好并据此调整响应策略。然而,当前的大模型在这方面的能力仍然有限。



03 single Agent
在规划执行时无所适从

① 信息获取与理解

· 数据源多样性:不同的数据源可能使用不同的格式、协议和接口,这要求Agent具备处理多种数据格式的能力,并能够从异构数据源中提取有用的信息。

· 语义理解:仅仅获取数据是不够的,Agent还需要理解数据的意义。例如,在自然语言处理任务中,Agent需要准确地理解查询意图,并将查询转化为对数据库的有效请求。

 

② 动态环境适应

· 实时更新:如果目标数据源频繁更新,Agent必须能够及时捕捉到这些变化并做出相应的调整。这对于监控系统或实时数据分析尤为重要。

· 环境不确定性:现实世界中的许多因素都是不确定的,比如网络延迟、数据丢失等。Agent需要设计有弹性机制来应对这些不确定性,确保任务的连续性和稳定性。

 

③ 安全与权限

· 数据保护:在访问敏感信息时,确保数据的安全传输和存储至关重要。Agent需要遵循严格的安全协议,防止数据泄露或被非法访问。Agent如果要访问,需要考虑权限的设置可开通问题。

 

④ 交互复杂性

· 多轮对话管理:对于需要通过对话进行信息访问的任务(如智能客服),Agent需要有效地管理和跟踪对话状态,理解用户的上下文,并提供连贯的回答。

· 用户意图识别:准确识别用户的实际需求并非易事,尤其是在自然语言处理领域,用户表达方式多样且模糊,增加了意图识别的难度。

总结来说,以上这几种AI应用的挑战,归根到底为数据的质量问题,缺失问题,不及时问题;也就是上下文知识的质量、缺失和不及时。因此,我们如果能解决上下文知识持续稳定高质量地提供,就可以基本解决当前面临的问题



三、上下文知识能否应对这些挑战?

 

根据前述,无论是意图识别、问数场景还是Action场景,核心问题为环境复杂,现有的模型和提示词无法满足不断变化的环境,无法支撑多样的环境,更无法理解复杂的环境的语义形态。因此就引入了上下文工程。

如图,在作业中,持续为知识库提供正确的信息,让各Agent能高精度地获取到相关的上下文,从而可靠地完成指定任务。这些上下文知识的构建是一个持续的过程,需要不断地保持下去。

但当前上下文知识存在不少问题:上下文具体含义理解较复杂,不同领域或行业的文档及交流有其独特的术语、风格和惯例,自然语言本身充满了模糊性和歧义性,以及模型对实时处理能力的要求等;因此,上下文知识的治理需要采用系统性的工程化手段来完成



四、如何搞好上下文工程?

那我们该如何才能提供高质量准实时的上下文,又该采用哪些具体的策略呢?



01
精细化知识管理

① 知识生产质量严格把控 

· 知识模板化:没有规矩,不能方圆;在知识生产的过程中,面对超高质量的上下文知识,需要有知识模板来指引,每个不同的场景所需的模板可能有些许差异;但知识模板需要由相关知识COE明确给出,确保知识生产不会走样。

· 知识质量门禁化:知识门禁主要为了检测知识是否按照模板格式整理,以免影响后续知识的检索效果。另外,也会判断知识是否有语义上的偏差,是否有重复性,低端的错别字等。

· 知识生产责任化:知识保证除了工具支撑外,还需要责任到人。在工具没有完全智能化前,人的作用还是非常必要的。

② 知识消费精细化治理

· 检索细节到一个关键字,一个字段和一个分段

Dify知识消费治理为例。在该示例中,我们通过对将要消费的知识进行精细化微调控制,实现了对知识召回效果的最大化预期。这意味着,我们不仅可以依靠工具来获取知识,而且还可以确保我们获取的知识符合我们的期望,从而实现更好的理解和应用。这种治理方式为我们提供了一种有效的途径,帮助我们更好地管理我们的知识消费,让知识召回更加完美。

· 召回测试前移

在以往,知识只有送到RAG并在助手上进行检索,通过测试集才能发现知识是否符合要求,这样流程太长,不能精细化调试或发现知识召回时,发现的问题。因此,需要在知识消费治理过程中,就能及时获取到知识消费可能存在的问题,进而进行调试,实现精细化运作。

· 知识消费场景责任化

知识消费质量好坏,除了本身知识内容质量外,还与知识的关键字设置,分段设置等有关,这就需要有相关的消费场景的责任人来保证其质量,避免消费过程处置不当,给业务带来影响。 


02
上下文工程组织建设及流程

 ① 组织建设

· 构建跨职能团队

组成:包括但不限于数据科学家、领域专家、软件工程师、用户体验设计师等。

职责:共同定义需求、设计解决方案,并确保所开发的系统能够准确捕捉和利用上下文信息。

· 构建专门的知识管理小组

角色:负责维护企业内部的知识库,确保知识的更新、分类、标注以及质量保证。

任务:定期审查现有知识,清理过时内容,引入新知识,并促进知识共享文化。

· 用户反馈机制

渠道:通过问卷调查、用户访谈、社区论坛等多种方式收集用户反馈。

目的:了解用户对当前系统的看法及其遇到的问题,作为改进系统的重要依据。

· 持续教育与培训计划

对象:面向全体员工,特别是直接参与知识管理和系统开发的人员。

内容:涵盖最新技术趋势、行业最佳实践以及公司特定工具和技术的使用方法。

 ② 流程建设

流程建设与知识工程建设类似,也就是构建知识生产流程,知识准入流程,知识消费流程等。



五、结语

上下文工程的最终目标,是让系统在复杂多变的环境中,具备理解、推理和响应上下文的能力,从而提供更智能、精准和人性化的服务。它不仅是技术的整合,更是组织协作、流程优化和知识沉淀的综合体现。通过持续构建、迭代和深化上下文能力,企业能够真正实现以用户为中心、以数据为驱动的智能决策与服务体验升级。上下文工程不是一蹴而就的终点,而是一个持续演进、不断优化的长期过程。

本文通过参考业界及周边专家的意见,对上下文工程进行了思考和总结,欢迎大家交流,探讨和指正。

【声明】本内容来自华为云开发者社区博主,不代表华为云及华为云开发者社区的观点和立场。转载时必须标注文章的来源(华为云社区)、文章链接、文章作者等基本信息,否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容,欢迎发送邮件进行举报,并提供相关证据,一经查实,本社区将立刻删除涉嫌侵权内容,举报邮箱: cloudbbs@huaweicloud.com
  • 点赞
  • 收藏
  • 关注作者

评论(0

0/1000
抱歉,系统识别当前为高风险访问,暂不支持该操作

全部回复

上滑加载中

设置昵称

在此一键设置昵称,即可参与社区互动!

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。

*长度不超过10个汉字或20个英文字符,设置后3个月内不可修改。