支持私有化部署
AI知识库

53AI知识库

学习大模型的前沿技术与行业应用场景


大模型效果差?可能你输在了上下文工程!

发布日期:2025-07-24 10:04:33 浏览次数: 1589
作者:前言集

微信搜一搜,关注“前言集”

推荐语

大模型效果不佳?可能是你的上下文工程没做好!解锁模型潜力的关键在于工程化增强,而非一味追求更大参数。

核心内容:
1. 造模型与用模型的根本区别与ROI考量
2. 上下文工程的核心技术与实现路径
3. 复杂任务下的挑战与"记忆宫殿"式解决方案

杨芳贤
53AI创始人/腾讯云(TVP)最具价值专家

人类再聪明,也受环境所限

模型再强大,亦为上下文所困

面对大模型的浪潮,一个根本性的选择摆在我们面前:是造模型,还是用模型
造模型:需要基础训练和模型优化。需要AI研究员,聚焦于基础训练与模型优化,解决的是领域理解的问题。

用模型:需要应用增强模型能力。需要工程师,聚焦应用增强层落地,解决的是领域流程的问题。

现在也不用想了,造模型的就这么几家大玩家,广大的人民群众都转到用模型的赛道上,这也是智能体为什么火的原因之一。

其实选哪种方式,最终的决策在ROI投入产出比。显然从ROI角度考量,工程化、可解释性强、更可控的“用模型”路径,是更普适的选择。



工程增强:解锁模型潜力的关键

用模型:又叫基于工程应用对大模型能力进行增强。在不修改模型参数,通过系统设计扩展能力边界。

    • 无需训练模型:不触及底层参数。

    • 依赖工程架构与交互设计:通过外部系统弥补模型固有缺陷。

    • 核心逻辑:在模型推理阶段进行干预,精准解决如知识陈旧、精确计算缺失、业务流程陌生等问题。


    实现这一目标的关键技术包括:上下文学习(In-Context Learning)、Prompt工程、检索增强生成(RAG)、工具调用(Tool Use / Function Calling) 等。而贯穿这些技术的核心支柱,便是上下文工程

    为什么要提上下文工程?

    想象一下人机协作场景:确保大模型与你拥有“共同的记忆”,是达成预期一致的前提。 上下文(Context)正是承载这份“共同记忆”的载体。然而,模型的“记忆”是有限的——即上下文窗口(Context Window)。

    这个窗口再大也是有限的,现在普遍是128K,但是在实际应用场景中,通常是不够的。

    1、文档超限:我们有时需要处理的文档非常大,各类pdf、word、网页等内容很容超出上限;

    2、性能衰减:一次性处理大量上下文长度,就会漏掉细节,模型性能往往会下降;

    3、成本高昂每次推理都需传输冗长的历史对话,计算开销巨大。

    复杂任务下的挑战与陷阱

    我们设计智能体时,一定会通过多轮MCP步骤(规划、调用、感知)、通过RAG查找答案、塞入各种提示词等,一个智能体经过十几轮甚至几十轮的步骤,大模型的上下文中被塞入了大量的信息,很容易时期偏离主题或忘记早期目标,尤其在越复杂的任务中,所以如何让大模型“保持清醒”,是设计的关键难点。

    以前的设计,是将内容进行压缩,记得在去年很多方案是对上下文进行总结,将总结的内容给大模型,这样失去了内容原本的含义,导致回答假大空。

    更优解:构建“记忆宫殿”式上下文

    因为上下文有限,所以不能把所有东西塞入其中,必须要有逻辑、要有结构、要有目录树。

    我们可以利用文件系统来解决这个问题,将prompt提示词、网页、pdf等文档、过程对话、RAG搜索出的答案等存入文件系统,然后通过文件系统的文档路径放在上下文中,这样我们可以构建一个或多个Agent来对文件系统进行调用。

    给上下文是大纲,好比人类记忆时会使用的“记忆宫殿”,只有用到某些细节的时候再去文件系统中取细节内容。这种方法有助于降低上下文负担,提高了信息组织的逻辑性和可控性。

    1. 将Prompt模板、网页/PDF文档、过程对话记录、RAG检索结果等结构化存入文件系统。

    2. 在模型的上下文窗口中,仅保留指向这些文件的关键路径(如目录树、大纲索引)。

    3. 模型如同拥有一个“记忆宫殿”,上下文窗口里是清晰的“大纲目录”,仅当需要处理具体细节时,才按需从文件系统中调用相应片段。


    当然也碰到一些方案,是在某些时刻,将上下文中的不需要的内容进行删减。但从经验来看,会导致不连贯,尤其忘记犯错的过程,使得大模型做出死循环的操作,比如反复犯同样的错误。

    最近在做一些小工具的时候,由于流程简单,变量少,很容易感受到由于上下文断裂引发的典型问题:利用大模型做任务的步骤分解,人工进行校验,与大模型反复沟通,确定最终步骤,再进行工具调用,最后让大模型进行提醒和回溯。发现由于人为对中间的步骤进行删减,导致最后大模型在回溯的时候,总是会犯同样的错误,有点“死循环”的意思。



    写到最后,刚好看到了一篇刚出炉的论文大模型上下文工程综述,论文认为虽然当前模型在先进上下文工程的增强下表现出对复杂上下文出色的理解能力,但在生成同等复杂的长篇输出方面却表现出明显局限。解决这一缺口是未来研究的重点。

    通过对1400篇论文的系统分析,将上下文工程作为一门学科提出,它超越了简单的提示设计,涵盖了对LLM信息负载的系统性优化

    提出上下文工程基础组件:

    1. 上下文检索与生成,包括基于提示的生成和外部知识获取;

    2. 上下文处理,解决长序列处理、自我优化和结构化信息整合;

    3. 上下文管理,涵盖记忆层次结构、压缩和优化


    以及探讨这些组件如何被架构整合以创建复杂的系统实现:

    1. 检索增强生成(RAG),包括模块化、代理和图增强架构;

    2. 记忆系统,实现持久交互;

    3. 工具集成推理,用于函数调用和环境交互;

    4. 多智能体系统,协调通信和编排




    恰好印证了最近的实验和猜想,也与之前关于大模型和RAG的想法。有兴趣可以翻看人工智能合集文章。

    在“用模型”以及用好模型中,核心是通过控制上下文控制大模型。

    盗梦空间开篇即强调“最顽固的寄生物莫过於一个想法”("The most resilient parasite is an idea")。一旦某个念头在潜意识中生根,它就会持续影响人的认知和行动,甚至改变人生轨迹。

    大模型的可解释性与可控性,是生产场景中使用大模型的前提条件。


    53AI,企业落地大模型首选服务商

    产品:场景落地咨询+大模型应用平台+行业解决方案

    承诺:免费场景POC验证,效果验证后签署服务协议。零风险落地应用大模型,已交付160+中大型企业

    联系我们

    售前咨询
    186 6662 7370
    预约演示
    185 8882 0121

    微信扫码

    添加专属顾问

    回到顶部

    加载中...

    扫码咨询