情境工程的全面调查：从即时工程到生产级AI系统。数百篇论文，框架和LLM和AI代理的实施指南。
在大型语言模型时代，静态提示的局限性越来越明显。上下文工程代表了解决LLM不确定性和实现生产级AI部署的自然演变。与传统的提示工程不同，上下文工程包括在推理时提供给LLM的完整信息有效载荷，包括完成合理任务所需的所有结构化信息组件。
这个知识库是对上下文工程技术、方法和应用程序的全面调查。
为什么选择Context Engineering？
范式转变：从战术到战略
从提示工程到上下文工程的演变代表了AI系统设计的基本成熟。正如Andrej Karpathy，Tobi Lutke和Simon Willison等有影响力的人物所认为的那样，“即时工程”一词已被淡化为简单的“将东西输入聊天机器人”，未能捕捉到工业强度LLM应用程序所需的复杂性。
从提示工程到上下文工程的演变代表了AI系统设计的基本成熟。正如Andrej Karpathy，Tobi Lutke和Simon Willison等有影响力的人物所认为的那样，“即时工程”一词已被淡化为简单的“将东西输入聊天机器人”，未能捕捉到工业强度LLM应用程序所需的复杂性。
1.当前方法的基本挑战
人类意图沟通的挑战
- 不清晰的人类意图表达：人类意图在用自然语言表达时通常是不清晰、不完整或模糊的
- 人工智能对人类意图的不完全理解：人工智能系统很难完全理解复杂的人类意图，特别是那些涉及隐含上下文或文化细微差别的意图。
- 过度字面化的AI解释：AI系统经常过于字面化地解释人类指令，从而错过了潜在的意图或上下文含义
单靠单一模型无法解决复杂的问题，这些问题需要：
静态知识限制：- 静态知识问题：预先训练的模型包含过时的静态知识
- 知识截止：模型无法访问训练数据以外的信息
- 特定领域的差距：模型缺乏特定行业或应用的专业知识
- AI幻觉：LLM在缺乏适当上下文时生成看似合理但实际上不正确的信息
- 缺乏出处：生成的信息缺乏明确的来源归属
- 置信度校准：即使在生成错误信息时，模型也经常表现出自信
- 透明度差距：无法追踪结论是如何得出的
- 问责问题：难以验证人工智能生成内容的可靠性
2.静态校准的局限性
从字符串到系统
传统提示将上下文视为静态字符串，但企业应用程序需要：
- 动态信息组装：动态创建上下文，为特定用户和查询量身定制
- 多源集成：结合数据库、API、文档和实时数据
- 状态管理：维护会话历史记录、用户首选项和工作流状态
- 工具演示：协调外部函数调用和API交互
如果说提示工程是为演员写一行对话，那么语境工程就是构建场景、设计灯光、提供详细的背景故事和指导场景的整个过程。对话之所以能达到预期的效果，是因为它周围有丰富的、精心构建的环境。
3.企业和生产要求
上下文故障是新的瓶颈
现代代理系统中的大多数故障不再归因于核心模型推理能力，而是“上下文故障”。真正的工程挑战不在于问什么问题，而在于确保模型具有所有必要的背景、数据、工具和内存，以有意义地、可靠地回答问题。
超越简单任务的可扩展性
虽然快速工程足以完成简单、独立的任务，但当扩展到以下情况时，它就会崩溃：
- 复杂的多步骤应用
- 数据丰富的企业环境
- 有状态、长期运行的工作流
- 多用户、多租户系统
企业应用需求：
- 确定性行为：跨不同上下文和用户的可预测输出
- 错误处理：当信息不完整或矛盾时，
- 审计跟踪：背景如何影响模型决策的透明度
- 合规性：满足数据处理和决策的法规要求
环境工程支持：
- 成本优化：RAG和长期背景方法之间的战略选择
- 延迟管理：高效的信息检索和上下文组装
- 资源利用率：优化使用有限的上下文窗口和计算资源
- 维护可扩展性：更新和管理知识库的系统方法
4.认知与信息科学基础
人工体现
LLM本质上是“缸中之脑”--缺乏与特定环境联系的强大推理引擎。上下文工程提供：
- 合成感觉系统：人工感知的检索机制
- 代理实施例：工具用作人工动作能力
- 人工记忆：结构化信息存储和检索
上下文工程解决了信息检索的根本挑战，其中“用户”不是人类，而是AI代理。这需要：
- 语义理解：弥合意图和表达之间的差距
- 相关性优化：对庞大的知识库进行排名和过滤
- 查询转换：将模糊的请求转换为精确的检索操作
5. AI系统架构的未来
上下文工程将AI开发从一系列“提示技巧”提升到系统架构的严格学科。它将数十年的操作系统设计，内存管理和分布式系统知识应用于基于LLM的应用程序的独特挑战。
这门学科是释放LLM在生产系统中的全部潜力的基础，使其能够从一次性文本生成过渡到自主代理和复杂的AI副驾驶，这些代理和副驾驶可以在复杂的动态环境中可靠地运行。
语境上下文Context工程的基本定义
上下文不仅仅是用户发送给LLM的单个提示。上下文是在推理时提供给LLM的完整信息有效载荷，包括模型可执行地完成给定任务所需的所有结构化信息组件。
LLM生成
为了正式定义上下文工程，我们必须首先从数学上描述LLM生成过程。让我们将LLM建模为概率函数：
P（输出|context）=1TP（tokent|以前的标记，上下文）
其中：
- context表示提供给LLM的完整输入信息
- output表示生成的响应序列
- P(tokent|previous tokens,context)是在给定上下文的情况下生成每个标记的概率
在传统的提示工程中，上下文被视为一个简单的字符串：context=prompt
然而，在上下文工程中，我们将上下文分解为多个结构化组件：
context=Assemble（instructions，knowledge，tools，memory，state，query） |
其中Assemble是一个上下文组装函数，用于编排：
- instructions：系统提示和规则
- knowledge：检索到相关信息
- tools：可用的函数定义
- memory：对话历史和学到的事实
- state：当前世界/用户状态
- query：用户的即时请求
Context Engineering的定义
上下文工程被正式定义为优化问题：
AssembleE[Reward（LLM（context），target）] |
受限制：
- |context|≤MaxTokens(context window limitation)
- knowledge=Retrieve(query,database)
- $\text{memory} = \text{Select}（\text{history}，\text{query}）$
- state=Extract(world)
- Reward衡量生成的响应的质量
- Retrieve，$\text{Select}$，Extract是收集信息的功能
动态上下文解释
上下文程序集可以分解为：
context=Concat（格式（指令），格式（知识），格式（工具），格式（内存），格式（查询）） |
其中，
格式 |
因此，上下文工程是设计和优化这些组装和格式化功能的学科，以最大限度地提高任务性能。
数学原理
从这种形式化，我们得出四个基本原则：
- 系统级优化：上下文生成是一个针对汇编函数的多目标优化问题，而不是简单的字符串操作。
- 动态自适应：上下文组装函数在推理时适应每个查询和状态：Assemble（Assemble|查询，状态）。
- 信息论最优性：检索函数最大化相关信息：=argmaxRelevance（knowledge，query）。
- 结构敏感性：格式化功能编码与LLM处理能力一致的结构。
理论框架：贝叶斯语境Context推理
情境Context工程可以在贝叶斯框架内形式化，其中推断出最佳情境：
P(context|query,history,world)∝P(query|context)⋅P(context|history,world) |
其中：
- P(query|context)模型查询上下文兼容性
- P(context|history,world)表示先验上下文概率
最佳上下文程序集变为：
context∗=argmaxcontextP(answer|query,context)⋅P(context|query,history,world) |
这种贝叶斯公式使得：
- 不确定性量化：在上下文相关性中建模置信度
- 自适应检索：基于反馈更新上下文信念
- 多步推理：在交互中维护上下文分布
网站地图
- 相关调查
- 一般人工智能调查文件
- 语境与推理
- 记忆系统和上下文持久性
- ️语境工程的基本定义
- LLM生成过程
- 语境的定义
- 上下文工程形式化
- 动态上下文解释
- 数学原理贝叶斯框架
- 为什么选择Context Engineering？
- 范式转变：从战术到战略
- 当前方法的基本挑战
- 静态校准的局限性
- 企业和生产要求
- 认知与信息科学基础
- 组件、技术和架构
- 上下文缩放：位置插值，记忆高效的注意力，超长序列（10万+令牌）
- 结构化数据集成：知识图、图神经网络、结构化数据处理
- 自我生成的上下文：自主推理，迭代细化，自我改进
- 可持续发展实施和挑战
- 检索增强生成（RAG）：基础模型，高级策略，多模态集成
- 记忆系统：持久上下文，分层记忆，长期存储
- Agent通信：多Agent协议、协调、协作推理
- 工具使用和函数调用：API集成、外部系统交互
- 上下文驱动系统的可扩展性评价范式
- 环境质量评估（RULER、LongBench、InfiniteBench）
- 对上下文工程系统进行基准测试
- 应用程序和系统
- 复杂的研究系统：人工智能驱动的科学发现，自动化的研究工作流程
- 生产系统：企业应用程序、会话代理、实际部署
- 限制和未来方向
- 当前的技术限制
- 未来研究机会
- 新兴模式和技术