第一部分:从提示到上下文工程的范式转变

1.1. 引言:超越提示字符串

随着大型语言模型(LLM)应用的成熟，行业正在经历一场深刻的范式转变。最初，与LLM交互的艺术和科学主要集中在”提示工程”(Prompt Engineering)上一一即精心设计文本输入以引导模型产生期望的输出。然而，当应用从简单的、一次性的问答任务演变为复杂的、有状态的、多轮交互的智能体(Agent)时，这种以指令为核心的方法便显现出其局限性。成功的关键不再仅仅是crafting a perfect instruction(精心设计一条完美的指令)，而是 designing the perfect informational environment(设计一个完美的信息环境)²。

这一演变催生了一门新的学科：上下文工程（Context Engineering）。正如业界广泛引用的观点所指出的，上下文工程是”在下一步操作中，用恰到好处的信息填充上下文窗口的精妙艺术和科学”。这一定义将焦点从单一的文本字符串转移到了一个动态的、结构化的环境上。它不再是一个简单的输入- 输出问题，而是一个系统设计和流程编排的挑战，其本质更接近于为LLM设计的软件工程。

这种转变的背后是一个关键的认知：在生产环境中，大多数智能体应用的失败并非源于模型本身能力的不足，而是源于上下文的失败（context failures）。模型没有被给予足够的信息、工具或历史记录来合理地完成任务。因此，上下文工程作为一门旨在构建可靠、可预测和可扩展AI系统的核心方法论，其重要性日益凸P显，成为了构建生产级AI应用的关键技能²。这种转变并非简单的术语更迭，而是由行业向更高级、更自主的智能体系统发展的雄心所驱动的必然结果。智能体的定义本身就要求其具备记忆、工具使用和与外部状态交互的能力，而这些能力恰恰是上下文工程所要管理和编排的核心要素。一个无法有效进行上下文工程的系统，本质上无法构建出可靠的智能体。因此，AI工程团队的关注点必须从招聘”提示词编写者”转向培养”AI系统架构师”，后者需要深刻理解数据管道、状态管理和API编排一一这些正是上下文工程的核心技能²。

1.2. 界定边界:提示工程与上下文工程

为了深刻理解上下文工程，必须将其与提示工程进行细致的比较。提示工程是上下文工程的一个重要组成部分，而非相互竞争的实践。简而言之，上下文工程决定了什么内容应该被放入上下文窗口，而提示工程则关注如何在窗口内更好地表述这些内容。一个设计精妙的提示，如果被数千个无关紧要的聊天历史记录或格式混乱的检索文档所淹没，其效果将大打折扣²。

两者之间的核心区别可以从多个维度进行剖析：

两者之间的核心区别可以从多个维度进行剖析：- 思维模式 (Mindset): 提示工程的核心在于精心设计清晰的指令，其目标是让模型准确理解并执行一个特定任务。而上下文工程则关注设计模型的整个思维流程架构，它考虑的是模型在接收指令之前需要知道什么，以及这些知识如何影响其后续的推理和行动²。- 范围 (Scope): 提示工程通常在一个单一的输入- 输出对的范围内操作。上下文工程则处理模型所能“看到”的全部信息，这包括系统指令、短期记忆（对话历史）、长期记忆（用户偏好）、可用的工具集以及从外部知识库中检索到的数据²。- 目标 (Goal): 提示工程旨在从单次提示中获得一个特定的、高质量的响应。上下文工程的目标则是确保模型在不同的会话、用户和各种混乱情况下都能保持一致且可预测的良好性能¹。- 时间性 (Temporality): 提示工程关注的是在特定时刻对模型说什么。上下文工程则关注当你说这句话时，模型已经知道了什么，以及为什么这些先验知识是重要的²。- 类比 (Analogy): 如果说提示工程类似于创意写作或文案优化，那么上下文工程则更接近于系统设计或软件架构。前者是语言的艺术，后者是构建可靠信息流的工程科学²。

下表系统地总结了提示工程与上下文工程之间的关键区别。

表1：提示工程与上下文工程的比较分析

维度	提示工程 (Prompt Engineering)	上下文工程 (Context Engineering)
核心思维	精心设计指令 (Crafting clear instructions)	设计思维流程架构 (Designing the architecture of a thought process)
操作范围	单一输入-输出对 (Single input-output pair)	模型的完整信息环境，包括记忆、工具、历史记录等
主要目标	获得特定的、一次性的高质量响应	在多次会话中实现一致、可预测的性能
可扩展性	难以规模化，边缘案例增多时效果下降	从设计之初就为规模化和可重复性而构建
调试方法	重写措辞，猜测模型内部状态	检查完整的上下文窗口、记忆槽和令牌流
所需工具	文本编辑器或聊天界面即可	需要记忆模块、RAG系统、API链、后端协调等
学科类比	创意写作、文案优化	系统设计、软件架构

资料来源：2

1.3.上下文窗口剖析：上下文的构建模块

上下文窗口是LLM的“工作记忆”，是上下文工程师进行操作的核心场域。理解其构成是进行有效工程实践的前提。一个被精心设计的上下文窗口通常由以下几个动态组合的构建模块构成：1. 系统指令/提示 (System Instructions/Prompts): 这是上下文的基础层，定义了LLM在整

个交互过程中的角色、行为准则、个性和输出格式。例如，“你是一个专业的客户支持助手，请始终保持礼貌，并以JSON格式回答问题”⁵。2. 用户输入 (User Input): 用户当前提出的问题或任务指令，是触发模型响应的最直接动因⁶。3. 对话历史/短期记忆 (Conversation History/Short- Term Memory): 最近几轮的交互记录。这对于维持对话的连贯性至关重要，能让模型理解诸如“它”或“那个”之类的指代词³。4. 检索到的信息/知识 (Retrieved Information/Knowledge): 这是上下文工程中最具变革性的部分。通过检索增强生成 (RAG) 等技术，从外部知识库（如公司文档、数据库、API）动态获取与用户查询相关的信息，注入到上下文中。这极大地减少了模型产生真实性错误（“幻觉”）的风险，并使其能够利用其训练数据之外的最新或私有知识³。5. 工具及其定义 (Tools and Their Definitions): 向模型提供其可以调用的外部工具（如API、函数）的描述、参数模式 (schema) 和预期返回格式。这赋予了模型超越文本生成、与外部世界进行交互并执行具体操作的能力³。6. 结构化输出格式 (Structured Output Formats): 明确指定模型响应的结构，例如提供一个JSON schema。这本身也是一种上下文，它强力约束了模型的输出，确保其生成的数据能被下游程序稳定地解析和使用⁴。7. 状态/长期记忆 (State/Long- Term Memory): 关于用户、项目或工作流的持久化信息。这些信息通常存储在外部（如用户画像数据库、工作流状态机），并根据当前任务的需求被选择性地加载到上下文中。例如，用户的语言偏好、之前设定的项目预算等³。上下文工程师的职责就是像一位系统架构师一样，动态地、智能地从这些模块中选择、过滤、排序和格式化信息，最终构建出一个最优的上下文窗口，以驱动LLM在特定任务中取得成功。

第二部分：检索增强生成 (RAG) 作为上下文工程的基石

如果说上下文工程是构建动态AI系统的宏伟蓝图，那么检索增强生成 (Retrieval- Augmented Generation, RAG) 就是实现这一蓝图的核心引擎。RAG不仅是上下文工程中的一项关键技术，更是其 foundational technological pattern（基础技术范式）。它从根本上解决了LLM知识静态、易产生幻觉的核心痛点，是实现上下文动态性的关键机制。

2.1. RAG架构：范式概览

RAG的核心思想是在模型进行推理（生成响应）时，通过从外部知识源检索相关证据来对其进行条件化 (conditioning)¹³。这种“先检索，后生成”的模式，使得LLM能够利用其强大的语言和推理能力，来处理那些并非存储在其参数化知识中的、最新的、领域特定的信息，从而显著提升了响应的事实一致性和领域适应性¹⁷。

随着研究的深入，RAG的架构也日益丰富。根据近期的综合性学术调查，RAG架构可以依据其核心创新点所在的模块，划分为以下几种主要范式¹⁴：

• 以检索器为中心的架构 (Retriever-centric): 这类架构的创新重点在于优化检索过程本身。其目标是提升检索结果的准确性、相关性和效率。技术手段包括改进索引策略、采用混

合搜索（结合关键词与语义搜索）、查询重写或扩展等。

• 以生成器为中心的架构 (Generator-centric): 这类架构的创新重点在于优化生成器模型如何消费和利用检索到的上下文。技术手段包括对生成器进行特定任务的微调，使其更好地理解和融合检索到的信息，或者在解码过程中引入控制机制，以确保生成内容对检索到的证据保持忠实。- 混合/协同架构 (Hybrid/Coordinated): 这类设计强调检索器和生成器之间的紧密互动与协同优化。它们不再将检索和生成视为两个独立的串行步骤，而是通过迭代、反馈循环等方式将两者耦合起来。例如，生成器可以向检索器请求更多信息，或者检索器根据生成器的初步输出来调整后续的检索策略。- 以鲁棒性为导向的架构 (Robustness-oriented): 这类架构专门为处理现实世界中充满噪声或对抗性输入的场景而设计。其重点在于提升RAG系统在面对不完美或误导性检索内容时的稳定性，例如通过引入对检索文档进行评估和过滤的机制，或者训练生成器对无关信息具备更强的抵抗力。

2.2. RAG流水线详解

一个典型的RAG工作流可以分解为三个核心功能组件，它们共同构成了上下文工程中动态知识注入的基础设施：

1. 检索器 (Retriever): 检索器的核心职责是获取外部知识。当系统接收到用户查询时，检索器会访问一个或多个外部知识库（如公司内部文档库、结构化数据库、网页索引等），并根据查询的语义或关键词，找出最相关的信息片段（通常称为“chunks”或“documents”）。这是将外部世界与LLM连接起来的第一座桥梁。2. 增强器 (Augmenter): 这一环节是构建最终上下文的核心。它接收由检索器返回的信息片段，并将其与上下文窗口的其他构建模块（如原始用户查询、对话历史、系统指令等）进行整合。增强器的任务不仅仅是简单的拼接，还可能包括对检索内容进行排序、过滤、压缩或格式化，以最优的方式呈现给生成器。3. 生成器 (Generator): 生成器通常是一个大型语言模型。它的任务是合成最终响应。与没有RAG的LLM不同，RAG系统中的生成器被明确指示要基于“增强器”提供的、包含了外部知识的上下文来生成答案。这使得其输出不再仅仅依赖于其内部的、可能过时的参数化知识，而是“锚定”在实时检索到的、具有权威性的事实上。

2.3. RAG的演进前沿

RAG技术本身也在不断演进，以满足上下文工程日益复杂的应用需求。其发展前沿主要体现在以下几个方向：

• 面向知识的RAG (Knowledge-Oriented RAG): 早期的RAG主要关注非结构化的文本文档。而面向知识的RAG则致力于利用更多样化的外部知识源，包括结构化数据（如数据库中的表格）和半结构化数据，以提供更精确、更丰富的上下文。图谱RAG (GraphRAG): 为了克服传统“扁平化”文本检索的局限性，GraphRAG应运而生。它采用知识图谱 (Knowledge Graphs) 作为知识库，通过图结构来显式地表示实体之间的复

杂关系。这使得RAG系统能够进行多跳推理(multi- hop reasoning)，回答那些需要综合多个信息源才能解决的复杂问题24。

• 多模态RAG (Multimodal RAG): 这是RAG领域最具挑战和潜力的前沿方向。多模态RAG旨在将RAG的能力从纯文本领域扩展到包含图像、音频、视频等多种模态的数据。这意味着上下文工程师未来将能够构建可以“看”图表、“听”录音并结合文本进行综合推理的AI系统，极大地扩展了“上下文”的内涵和应用边界21。

RAG的这些演进，清晰地展示了它作为上下文工程核心技术的地位。它不仅仅是为LLM提供事实的一种手段，更是实现上下文动态性的根本机制。没有RAG，上下文窗口就是一个相对静态、预定义的空间，其内容主要由开发者预设的指令和用户输人的短期历史构成。LLM的能力被其内部知识和手动注入的信息所限制。RAG的引入，在推理的时刻(at inference time)增加了一个动态的检索步骤16，这意味着上下文是根据用户查询的即时需求“即时构建”（on the fly）的9。正是这种动态性，将上下文工程从理论变为现实，将静态的提示词演化为动态的、与现实世界实时同步的工作空间。因此，要精通上下文工程，就必须深入理解和掌握信息检索系统，包括向量数据库、搜索算法和数据索引策略，因为整个系统的性能上限，在很大程度上取决于其检索组件的质量。

第三部分：上下文构建与推理的先进方法论

在掌握了RAG这一基础架构之后，上下文工程的实践进入了更高级的阶段。其目标不仅是为LLM提供事实信息，更是要构建一个能够自我纠正、进行结构化推理的“认知架构”。本部分将探讨代表上下文工程前沿的几种先进方法论，它们赋予了AI系统更强的自主性和解决复杂问题的能力。

3.1. RAG中的自我纠正与反思

传统的RAG流水线是单向的：检索、增强、生成。然而，这种模式的鲁棒性有限，一旦检索环节出现偏差（即检索到不相关或错误的信息），错误就会被传递并放大到最终的生成结果中。为了解决这一核心痛点，研究者们开始在RAG流程中引入反馈循环，使其具备自我评估和纠正的能力，这种模式也被称为“智能体式RAG”（Agentic RAG）29。

纠正性RAG (Corrective RAG, CRAG)

• 核心思想：CRAG通过在检索后、生成前引入一个轻量级的检索评估器（retrieval evaluator）或“自我评分”机制，来主动评估检索文档的相关性29。- 工作机制：评估器会对每个检索到的文档块给出一个相关性分数。如果所有文档的相关性都低于预设的阈值，CRAG会触发纠正措施。最常见的措施是转向一个备用数据源进行补充检索，例如进行一次网络搜索（web search），以获取更广泛或更新的信息20。此外，CRAG还引入了知识精炼（knowledge refinement）步骤：在生成之前，它会将高相关性的文档分解成更小的“知识条带”（knowledge strips），并对每个条带进行再次评分，最终只保留最核心、最相关的知识条带传递给生成器30。- 解决的问题：CRAG直接解决了朴素RAG（Naive RAG）最常见的失败模式——检索不准确或不相关，通过主动过滤和补充信息，显著提升了输入给生成器的上下文质量31。

自反思RAG（Self-RAG)

自反思RAG (Self- RAG)- 核心思想: Self- RAG是一种集成度更高、更根本的方法。它通过对LLM本身进行微调，使其学会生成特殊的***反思令牌”(reflection tokens)**来主动控制整个检索和生成过程30。- 工作机制：这种经过微调的模型具备了多种元认知能力。首先，它能自适应地决定是否需要进行检索。对于某些常识性问题，模型可以判断无需外部知识，直接回答。其次，在检索后，它会生成令牌来评判每个检索到的段落是否相关。最后，在生成答案的每一步，它都会进行自我评估，判断其输出是否得到了检索文档的支持(即事实性)以及是否对回答问题有用。整个过程是端到端训练的，模型在推理时自主地进行检索、评估和生成，无需外部的评估器模块33。- 解决的问题：Self- RAG不仅能纠正错误的检索，更实现了按需检索(on- demand retrieval)，并确保最终输出的每一句话都有据可查，极大地提升了答案的事实性和可验证性，从而有效抑制了模型幻觉33。

下表对朴素RAG、纠正性RAG和自反思RAG进行了详细的比较。

表2：先进RAG技术概览（CRAG，Self-RAG）

技术	核心机制	解决的主要问题	实现复杂度
朴素 RAG (Naive RAG)	检索 -> 增强 -> 生成	LLM知识静态、过时	低
纠正性 RAG (CRAG)	检索 -> 外部评估器 -> 知识精炼/网络搜索 -> 生成	检索结果不准确、不相关	中等（模块化，无需微调）
自反思 RAG (Self-RAG)	微调模型，通过生成内部反思/评判令牌来控制检索和生成	按需检索、事实性不足、幻觉	高（需要模型微调）

资料来源：29

3.2.结构化模型的思维过程

除了提供事实，上下文工程的另一个高级目标是引导和结构化LLM的推理过程，使其能够解决需要多步骤、复杂逻辑才能完成的任务。

$\bullet$ 思维链(ChainofThought,CoT)

$\bullet$ 思维链 (Chain of Thought, CoT)- 核心思想: CoT是一种提示技术，它通过引导模型”大声思考”(think out loud)，以线性的、一步一步的方式来分解和解决复杂问题35。- 工作机制: 实现CoT主要有两种方式。少样本(Few- shot) CoT 在提示中提供几个完整的示例，每个示例都清晰地展示了从问题到中间推理步骤再到最终答案的全过程37。- 霉样本 (Zero- shot) CoT 则更为简单，只需在用户问题的末尾加上一句简单的指令，如”让我们一步一步地思考”(Let’s think step by step) 即可触发模型的逐步推理模式37。

• 优势: 通过将复杂问题分解为一系列更简单的中间步骤, CoT显著提升了LLM在需要算术、常识和符号推理的任务上的表现³⁶。

- 思维树 (Tree of Thoughts, ToT)

• 核心思想: ToT是对CoT的泛化和升级。它认识到许多复杂问题的解决路径并非单一的线性链条, 而是充满了选择和分支。因此, ToT允许模型并行地探索多个不同的推理路径, 形成一个树状的探索结构³⁶。- 工作机制: 在ToT框架下, LLM在每个推理节点上会生成多个可能的“中间想法”(intermediate thoughts)。然后, 模型会自我评估这些想法的可行性或前景。基于评估结果, 系统可以进行前瞻(lookahead)或回溯(backtrack), 选择最有希望的路径继续深入探索。这个过程通常与经典的搜索算法(如广度优先搜索BFS或深度优先搜索DFS)相结合, 系统地在思维空间中进行搜索⁴⁰。- 优势: 对于那些需要探索、战略规划和试错的复杂问题(如下棋、创意写作、解决数学难题), ToT的表现远超CoT。它赋予了模型一种更接近人类的、深思熟虑的决策能力⁴⁰。

这些先进方法论的出现和融合, 标志着一个重要的趋势: 我们正在从将LLM视为一个简单的“文本生成黑盒”, 转向为其构建一个明确的“认知架构”。在这个架构中, 不同的技术扮演着类似人类心智功能的不同角色。RAG系统提供了工作记忆和访问长期知识的通道⁵。CoT和ToT则为如何处理这些知识以解决问题提供了明确的推理框架, 模拟了人类的审慎思考过程³⁵。而CRAG和Self- RAG则增加了一层**元认知(metacognition)或自我反思的能力, 使系统能够评估自己的中间步骤和知识检索, 并据此纠正其行为路线³⁰。当这些组件被有机地结合在一起时, 它们构成的就不再是一个简单的“流水线”, 而是一个初级的认知系统。上下文工程师的角色也因此升华: 不再是简单的数据投喂者, 而是模型整个思维过程的设计师。

第四部分: 上下文感知系统的工程生命周期

构建一个生产级的、由上下文工程驱动的系统, 本质上是构建一个先进的RAG系统。这个过程涉及一个完整的工程生命周期, 从原始数据的处理到最终上下文的优化, 每一步都充满了关键的技术决策和权衡。

4.1. 阶段一: 数据摄取与索引

这是构建RAG系统的基石。其目标是将非结构化的知识源转化为机器可高效检索的格式。

- 分块策略 (Chunking Strategies)

• 挑战: 分块是整个流程的第一步, 也是至关重要的一步。其核心挑战在于在上下文连贯性与分块大小之间取得平衡。分块太小, 可能会将一个完整的语义单元(如一个段落或一个逻辑步骤)切断, 导致上下文信息丢失; 分块太大, 则可能引入过多无关的“噪声”信息, 同时也会增加处理成本并可能超出模型的token限制⁴⁵。- 方法: 实践中存在多种分块方法。基于token的分块最简单, 但容易破坏语义结构。基于句子的分块是一个很好的折中方案, 它在保留基本语义单元的同时, 实现起来也相

对简单高效 45。

基于语义的分块则利用LLM来识别文档中的逻辑断点，效果最好但成本也最高。更高级的策略包括Small2Big（用小块进行精确检索，然后返回其所属的更大父块作为上下文）和滑动窗口（让相邻的块之间有部分重叠），以确保关键信息不会在分块边界丢失 46。

• 最佳尺寸：虽然没有universally optimal（普遍最优）的尺寸，但大量实践表明，对于许多应用场景，每个分块200到512个token是一个比较理想的范围 48。

- 向量嵌入与数据库（Vector Embeddings and Databases）

• 索引策略：将文本块转化为向量后，需要将其存储在专门的向量数据库中，并建立索引以实现快速的近似最近邻（Approximate Nearest Neighbor, ANN）搜索。两种最主流的索引算法是：

• IVF (Inverted File)：该算法通过k-means等聚类方法将向量空间划分为多个簇（cluster）。查询时，系统首先找到与查询向量最近的几个簇中心，然后只在这些簇内部进行搜索。这种方法适合超大规模数据集，构建速度快，但精度相对较低，且依赖于预先设定的簇数量 51。- HNSW (Hierarchical Navigable Small World)：该算法构建一个多层的图结构。搜索从最稀疏的顶层图开始，快速定位到目标区域，然后逐层向下，在更密集的图中进行更精细的搜索。HNSW的查询速度和召回率通常都非常出色，是目前许多高性能向量数据库的默认选择，但其构建索引的时间更长，且内存消耗更大 51。- 权衡：选择IVF还是HNSW，是在索引构建时间、查询速度和内存占用之间的权衡。对于需要频繁更新索引且内存资源有限的场景，IVF可能是更经济的选择。而对于读密集型、对查询延迟要求极高的应用，HNSW则更具优势 52。

4.2.阶段二：上下文检索与精炼

一旦数据被索引，系统就准备好进行实时检索。目标是不仅要“找到”信息，还要确保找到的是“最好”的信息，并以最佳方式呈现。

- 混合搜索 (Hybrid Search)

• 机制：混合搜索是一种业界公认的最佳实践。它将两种搜索范式结合起来：传统的关键词搜索（基于稀疏向量，如BM25算法）和现代的语义搜索（基于密集向量嵌入）。系统会并行执行这两种搜索，然后通过一个融合算法（如Reciprocal Rank Fusion, RRF）将两组结果合并并重新排序，得到最终的检索列表 45。- 优势：这种方法兼具两者的优点。语义搜索能够理解查询的深层含义和上下文，即使用户的用词与文档不完全一致也能找到相关内容。而关键词搜索则能确保对特定术语、产品名称、代码变量等专有名词的精确匹配。两相结合，极大地提升了检索的鲁棒性和相关性 57。

- 重排与重组 (Re-ranking and Re-packing)

• 重排 (Re-ranking)：这是一个两阶段的检索过程。第一阶段，使用高效的检索算法（如向量搜索）从海量数据中快速召回一个较大的候选集（例如，前100个文档）。第二阶段，使用一个更强大但计算成本更高的模型（称为“重排器”，通常是一个跨编码器

模型，如monoT5)对这个小得多的候选集进行更精细的打分和排序，以将最相关的文档精确地排到最前面 45。

• 重组 (Re-packing): 这关系到最终入选的文档在提交给LLM的提示词中的排列顺序。这是一个微妙但极其重要的步骤。研究发现，LLM存在“中间迷失”（Lost in the Middle）问题，即它们对位于上下文开头和结尾的信息记忆更深刻。因此，一个关键的优化策略是采用“逆序”(Reverse)重组方法，即将经过重排后最相关的文档放在上下文的最末尾，紧邻用户的问题。这样可以最大化地利用模型的注意力机制，确保最重要的信息被充分利用 45。

4.3. 阶段三：上下文窗口优化

即使现代LLM拥有越来越大的上下文窗口，但无限制地填充窗口既不经济也不高效。因此，对窗口内容进行优化是工程实践的最后一道关键工序。

$\bullet$ 管理Token限制的技术

• 智能截断 (Intelligent Truncation)：并非所有上下文都同等重要。可以为不同类型的上下文（如系统指令、对话历史、检索文档）设定优先级。在token超出限制时，优先保留“必须拥有”(must-have)的上下文，而从“可有可无”(optional)的上下文中进行截断 56。- 分层摘要 (Hierarchical Summarization): 对于非常长的文档或冗长的对话历史，可以采用分层摘要技术。系统首先将长文本分块，对每个块生成摘要，然后再对这些摘要进行摘要，最终形成一个高度浓缩但保留了核心信息的摘要，以此替代原始长文本放入上下文 45。- 上下文压缩 (Context Compression): 与生成新文本的摘要不同，压缩技术旨在通过移除冗余词、填充词和非核心短语来缩减原文的token数量，同时保留原文的核心措辞和信息 59。

$\bullet$ 应对“中间迷失”挑战

• 问题：大量实证研究揭示了LLM在处理长上下文时的一个普遍缺陷：模型在回忆和利用位于上下文窗口中间部分的信息时，性能会显著下降，呈现出一种U型的性能曲线。即，模型对开头和结尾的信息最敏感，而中间的信息则容易被“遗忘”或忽略 63。- 缓解策略：这一发现直接驱动了上文提到的“重组”策略。通过有意识地将最关键的信息（如最相关的检索文档）放置在上下文的末尾，工程师可以有效地规避当前模型架构的这一内在局限性，确保核心证据能够被LLM充分关注和利用 45。

整个RAG流水线的设计过程，实际上是一个在多个维度上进行权衡和优化的系统工程。在分块阶段做出的选择会直接影响检索的效果 47；检索算法的选择是在速度和精度之间权衡 52；而是否引入重排器则是在相关性与延迟、成本之间做出的决策 45。因此，不存在一个“一刀切”的RAG架构。一个成功的上下文工程师，其核心价值不在于孤立地选择“最好”的组件，而在于深刻理解这些组件之间的相互依赖关系，并根据具体的应用需求（对准确性、速度、成本的不同要求），设计出一个各部分协同工作的、平衡的、整体最优的系统。

第五部分:上下文工程系统的生产化

将一个上下文工程驱动的RAG原型系统转化为一个稳定、高效、可维护的生产级服务，是AI工程领域面临的核心挑战。这不仅需要解决技术问题，还需要在多个相互制约的目标之间找到最佳平衡点，并建立起一套完善的评估和运维体系。

5.1.三难困境：平衡成本、延迟与准确性

在生产环境中，任何RAG系统的设计都必须面对一个核心的”三难困境”(Trilemma)：即同时优化成本(Cost)、**延迟(Latency)和准确性(Accuracy)**是极其困难的，对一个目标的优化往往会损害另一个目标46。

成本优化（CostOptimization)

• 成本优化 (Cost Optimization)
• 模型路由 (Model Routing): 并非所有用户查询都需要最强大、最昂贵的LLM来回答。一个有效的成本控制策略是建立一个模型路由层。简单的、信息性的查询可以被路由到更小、更便宜的模型（甚至是开源模型），而需要复杂推理或创造性生成的查询才被发送到顶级的商业模型。这可以显著降低API调用成本⁶²。
• 批处理 (Batching): 对于非实时或延迟容忍度较高的任务，可以将多个请求打包成一个批次，通过一次API调用来处理。许多模型提供商对批处理API有额外的折扣，这可以大幅降低单位请求的成本⁶²。

延迟降低(LatencyReduction)

• 缓存 (Caching): 缓存是降低延迟最有效的手段之一，可以在多个层面实施：

• KV缓存 (Key-Value Caching): 在生成长序列时，LLM内部的注意力机制会计算键 (Key) 和值 (Value) 的投影。KV缓存会保存已处理token的KV状态，这样在生成下一个token时就无需重复计算，极大地加速了生成过程⁶²。- 提示缓存 (Prompt Caching): 缓存完全相同的用户查询及其响应。- 语义缓存 (Semantic Caching): 更进一步，缓存语义上相似的查询及其响应。当一个新查询与缓存中的某个查询在向量空间中足够接近时，可以直接返回缓存的答案，从而跳过整个RAG流程⁷⁰。

• 并行处理 (Parallel Processing): RAG流水线中的多个步骤，如从不同数据源检索文档或执行多个子查询，可以并行化执行，以减少串行执行造成的总延迟⁶²。- 流式响应 (Streaming): 对于生成步骤，不等待整个答案生成完毕再返回，而是以token by token的方式流式地将结果推送给用户。这极大地改善了用户的“感知延迟”。

• 权衡: 这些优化策略之间存在明显的权衡。例如，引入一个复杂的重排器模型会提高准确性，但同时也会显著增加延迟和计算成本⁶⁹。使用更小的模型可以降低成本和延迟，但可能会牺牲准确性。生产系统的架构师必须根据业务需求，明确各个目标的优先级，并做出明智的决策。

5.2. 评估框架与关键指标

没有测量，就没有改进。对RAG系统进行持续、量化的评估是迭代优化和保证生产质量的基石。评估应分为两个层面：对核心组件的评估和对系统整体的评估。

• 组件级核心指标

评估一个RAG系统，需要分别考察其检索和生成两个核心组件的性能72：

• 检索质量评估（Retrieval Evaluation）：

• 上下文精确率（Context Precision）：衡量检索到的上下文中，相关信息的占比。高精确率意味着噪声少，提供给LLM的信息质量高72。- 上下文召回率（Context Recall）：衡量所有真实相关的知识点中，有多大比例被成功检索了回来。高召回率意味着信息覆盖全面，LLM有足够依据来回答问题72。

• 生成质量评估（Generation Evaluation）：

• 忠实度（Faithfulness）：衡量生成的答案是否完全基于所提供的上下文，没有添加外部信息或与上下文相矛盾。这是量化“幻觉”程度的关键指标72。- 答案相关性（Answer Relevancy）：衡量生成的答案是否直接、有效地回应了用户的问题，没有跑题或包含冗余信息72。

• 排序感知指标（Order-Aware Metrics）：除了上述指标，还可以使用信息检索领域的经典指标来评估检索结果的排序质量，如平均倒数排名（Mean Reciprocal Rank, MRR）和折扣累积增益（Discounted Cumulative Gain, DCG），它们都强调将最相关的文档排在最前面75。

• 主流评估框架

为了自动化和标准化评估流程，社区涌现出了一些优秀的开源框架：

• RAGAS (Retrieval-Augmented Generation Assessment)：RAGAS是一个流行的、轻量级的RAG评估框架。其主要特点是采用“LLM-as-a-judge”的方法，即使用一个强大的LLM来对上述核心指标进行打分。这使得它在很多情况下无需依赖大量人工标注的“黄金标准”数据集，非常适合快速迭代和持续监控72。- ARES (Automated RAG Evaluation System)：ARES是一个更侧重于严谨性和统计置信度的评估框架。它通过从文档库中自动生成合成的测试数据，然后微调一系列轻量级的LLM作为评判模型。其核心创新在于使用了**预测驱动推断（Prediction-Powered Inference, PPI)**技术，可以用极少量的人工标注数据来校准模型评判结果，并给出具有统计置信区间的评估分数，非常适合在上线前进行严格的基准测试79。

下表对比了RAGAS和ARES这两个主流评估框架。

表3：RAG评估框架对比（RAGAS，ARES）

维度	RAGAS	ARES
评估方法	LLM-as-a-judge（使用通用大模型作为评判者）	微调的轻量级评判模型+合成数据+PPI
核心指标	上下文精确率/召回率,忠实度,答案相关性	上下文相关性,答案忠实度,答案相关性
“黄金标准”数据需求	需求极少或无需	需求少量（约150+）人工标注样

	(Reference-free)	本用于校准
主要应用场景	快速原型验证、持续集成中的回归测试	严格的基准测试、系统上线前的性能验证

资料来源：72

5.3. 常见的生产陷阱与缓解策略

在将RAG系统投入生产的过程中，团队常常会遇到一些共性的问题。

数据摄取阶段

• 数据摄取阶段
• 陷阱：对复杂文档（如包含多栏、表格、图表的PDF）的解析效果差；采用“一刀切”的固定长度分块策略，破坏了文档的逻辑结构⁴⁶。
• 缓解策略：采用先进的、能理解文档布局的解析工具（如Layout-aware parsers）；为分块添加元数据（如标题、章节信息）；采用更智能的分块策略（如语义分块或基于句子边界的分块）⁸⁴。

检索准确性阶段

• 检索准确性阶段
• 陷阱：知识库中内容缺失或过时；检索器返回了语义上相似但实际上与查询意图不符的文档（如“水星”的化学性质 vs. 天文学信息）；在重排阶段丢失了真正相关的上下文⁴⁶。
• 缓解策略：建立强大的数据治理和更新流程，确保知识库的时效性²⁷；采用混合搜索策略以兼顾语义和关键词⁴⁵；仔细调优重排模型，并监控其是否会过滤掉关键信息⁸⁴。

可扩展性与性能阶段

• 可扩展性与性能阶段
• 陷阱：由于需要调用多个服务（向量数据库、重排器、LLM），端到端的延迟过高；随着数据量和请求量的增长，基础设施成本（特别是向量存储和高级LLM API调用）急剧上升⁴⁶。
• 缓解策略：部署可水平扩展的分布式向量数据库⁸⁵；积极采用多层缓存策略⁶²；实施基于成本和延迟考量的模型路由⁶²。

将RAG系统投入生产并非一个“一劳永逸”的项目，而是一个需要持续投入和优化的动态过程。系统的性能会随着数据源的变化、用户查询模式的演变而发生漂移。因此，一个成功的生产级RAG架构必须包含一个类似MLOps的强大反馈循环。团队需要持续监控生产环境中的查询，识别失败案例，将这些案例补充到评估数据集中，然后重新调整流水线的各个组件（分块策略、检索模型、提示模板等），并重新部署。这要求组织必须投资于“RAGOps”基础设施——包括自动化评估、性能监控和数据管道管理的工具链——才能确保RAG系统在规模化应用中取得长期成功。

第六部分：生态系统与未来轨迹

上下文工程作为一个新兴领域，其发展离不开强大的工具生态系统支持，同时也面临着新的技术

前沿带来的挑战和机遇。本部分将探讨当前主流的开发框架，展望多模态融合的未来，并对上下文工程的终极走向进行总结。

6.1. 关键框架与工具：LangChain与Llamalndex

在当前的LLM应用开发生态中，LangChain和Llamalndex是两个最核心、最流行的框架，它们为上下文工程师提供了构建RAG和智能体系统的强大武器。

LangChain

• LangChain
• 定位：一个通用的、模块化的LLM应用开发框架。LangChain的核心优势在于其强大的编排能力。它提供了一套标准的接口和组件（如Chains, Agents, Tools），允许开发者像搭积木一样，将LLM、数据源、外部工具等灵活地组合起来，构建复杂的、多步骤的逻辑工作流86。

Llamalndex

• Llamalndex
• 定位：一个专注于RAG的数据框架。Llamalndex的核心优势在于其数据索引和检索能力。它为从各种数据源（文档、数据库、API）摄取数据、构建高效索引（向量索引、树索引、关键词索引等），以及执行高级查询提供了高度优化的解决方案86。

协同与选择

• 协同与选择
• 尽管两者在功能上有所重叠，但它们并非完全的竞争关系，而是可以协同工作、优势互补的。一个非常普遍且强大的架构模式是：使用Llamalndex来处理RAG中“R”（Retrieval）的部分，即利用其强大的数据处理和检索引擎来构建和查询知识库；然后使用LangChain来处理“A”（Augmentation/Agents）和“G”（Generation）的部分，即利用其灵活的编排能力来管理智能体的决策逻辑、工具调用和最终的响应生成87。

下表对LangChain和Llamalndex在RAG开发中的角色进行了对比。

表4：LangChain与Llamalndex在RAG开发中的对比

维度	LangChain	Llamalndex
主要焦点	通用LLM应用编排 (Orchestration)	数据索引与检索(Indexing & Retrieval)
核心优势	灵活性、模块化、强大的智能体和链式逻辑构建	高效的数据摄取、多样的索引策略、高级查询能力
数据处理	提供通用的文档加载器，但索引和检索的实现更依赖于集成第三方库	为数据索引和检索提供了高度优化的内置解决方案
灵活性	极高，允许开发者完全控制应用的逻辑流	相对更“意见化”，为RAG场景提供了开箱即用的最佳实践
主要应用场景	构建复杂的、多工具、多步骤的智能体和工作流	构建以数据查询和知识问答为核心的RAG应用

资料来源：86

6.2.新兴前沿：多模态RAG的挑战

当前上下文工程的实践绝大多数仍局限于文本数据。然而，现实世界的信息是多模态的。下一个重大的技术前沿，就是将上下文工程的原则扩展到图像、音频、视频等非文本数据。

• 目标：构建能够综合理解和推理多种数据模态的RAG系统。例如，一个能够分析财务报表中的图表（图像），并结合CEO演讲的录音（音频）和年报文本，来回答关于公司战略的复杂问题的系统90。- 核心挑战：
• 嵌入(Embedding)：最大的挑战在于如何创建一个统一的、跨模态的向量空间。目前，能够有效表示多种模态语义的嵌入模型仍然稀缺且不成熟。大多数现有模型（如CLIP）仅限于特定的模态对（如文本-图像），难以扩展90。
• 数据处理(Data Processing)：处理非文本数据的计算成本和复杂性远高于文本。例如，从视频中提取关键帧、对音频进行转录和声纹分析，都需要大量的计算资源和专门的模型91。
• “文本锚定”（Text-Grounding）作为权宜之计：鉴于直接进行多模态嵌入的困难，当前最务实的做法是“文本锚定”。即，使用专门的模型（如图像描述模型、语音转录模型）将所有非文本模态的数据预处理成文本描述，然后将这些文本描述送入一个标准的、基于文本的RAG流水线。这种方法虽然可行，但不可避免地会在模态转换过程中造成信息损失90。

6.3.结论：上下文工程的未来

上下文工程正迅速从一个新兴概念演变为构建高级AI系统的核心学科。它的崛起标志着AI工程从关注模型本身转向关注模型所处的信息生态系统。

展望未来，一个看似矛盾的趋势正在显现。一方面，LLM的上下文窗口正在以前所未有的速度扩张，从几千个token迅速增长到百万甚至两百万个token68。这似乎预示着，我们很快就可以将整个知识库”塞”进提示词，从而让RAG和复杂的上下文管理变得多余。然而，大量的研究和实践揭示了截然相反的现实。

“无限上下文”并不能解决上下文问题。恰恰相反，超长的上下文窗口暴露了当前LLM架构的深层缺陷，即”中间迷失”问题63。简单地用海量数据填充上下文窗口，不仅会急剧增加成本和延迟，还会因为引入大量噪声和无关信息，反而降低模型的准确性68。模型在浩瀚的文本中定位关键信息的能力（”大海捞针”）非常有限，识别信息缺失的能力则更弱68。

因此，随着上下文窗口的增长，上下文工程的重要性非但没有减弱，反而变得更加关键。挑战的焦点从**容量（capacity）问题一一如何将足够的信息装入窗口一一转向了相关性与注意力（relevanceandattention）**问题一一如何在巨大的信息空间中，为模型提炼出最精炼、最有效、结构最合理的上下文。

未来的上下文工程，将是一门关于相关性工程、注意力管理以及动态、自纠正认知系统架构设计的科学。它要求工程师不仅是模型的使用者，更是模型信息流的建筑师。掌握如何从噪声中提取信号，并为模型构建一个高效、清晰的思维工作台，将是定义下一代可靠、能干的AI智能体的核心能力10。

附录：上下文工程案例研究

本附录提供了上下文工程在不同行业中应用的具体案例，展示了其如何解决实际业务问题并创造价值。

A.1.企业知识管理

A.1. 企业知识管理- 问题: 大型企业通常拥有海量但分散的知识资产，包括内部文档、政策手册、技术规范、历史项目记录等。这些信息往往存储在不同的系统中（如Confluence, SharePoint, Jira），导致员工难以快速、准确地找到所需信息，效率低下²⁷。- 解决方案: 通过构建基于RAG的企业知识引擎，将这些孤立的知识源统一起来。员工可以通过自然语言提问，系统能够从所有连接的知识库中检索相关信息，并生成一个综合、准确且有来源依据的答案¹⁸。- 上下文工程实践: 在企业环境中，信任和合规性至关重要。因此，上下文工程的重点在于可验证性和减少幻觉。系统生成的每一条关键信息都必须能够追溯到原始的内部文档来源（即提供引用）。上下文的构建不仅包括检索到的文本片段，还包括严格的系统指令，以确保模型在信息不足时承认“不知道”，而不是猜测。此外，强大的数据治理框架是必不可少的，它确保了注入RAG系统的数据是准确、最新且经过授权的，从而避免“垃圾进，垃圾出”的问题²⁷。

A.2.客户服务自动化

A.2. 客户服务自动化- 问题: 传统的聊天机器人常常因为缺乏记忆和对用户个人信息的访问权限而显得“愚蠢”和重复。它们无法理解对话的上下文，也无法提供个性化的解决方案，导致用户体验差，问题解决率低⁵。- 解决方案: 构建具备上下文感知能力的AI客服智能体。这些智能体通过上下文工程，能够动态地访问和利用多种信息源来提供服务⁵。- 上下文工程实践: 在每次交互时，系统会动态地构建一个丰富的上下文窗口。这个窗口包含了：1)短期记忆：当前的对话历史；2)长期记忆：用户的个人资料、历史购买记录、过往的服务工单；3)外部知识：通过RAG从产品手册、FAQ数据库中检索到的相关信息；4)工具：用于查询订单状态、创建新服务工单的API。通过将这些信息整合在一起，AI客服能够提供高度个性化和高效的服务，例如，它可以在用户提问时，主动意识到用户正在询问的是他们上周购买的特定型号产品的问题。案例研究表明，这种方法能显著降低平均处理时间，并将用户挫败感降低40%⁵。

A.3.代码生成与软件工程

• 问题:像 GitHub Copilot 这样的通用代码生成模型虽然强大, 但它们缺乏对特定项目上下文的理解。它们不知道项目内部的 API、自定义库、编码规范或整体架构, 因此生成的代码可能不适用、不合规, 甚至存在错误¹⁰³。- 解决方案:应用 RAG 技术于代码生成领域, 创建一个能够理解项目本地上下文的“编码助手”。系统不再仅仅依赖其通用的训练数据, 而是从当前项目的代码库、内部文档和 API 规范中检索信息来辅助代码生成¹⁰³。- 上下文工程实践:上下文窗口被精心设计, 以模拟一个经验丰富的开发人员的“心智模型”。它会包含:1) 用户当前正在编辑的文件的内容;2) 文件中已导入的库和定义的变量;3) 通过 RAG 从整个代码库中检索到的最相似的函数或代码模式;4) 相关的 API 文档片段。通过这种方式, LLM 被转化为一个真正理解项目背景的“团队成员”¹⁰⁶。微软的内部研究报告指出, 部署了这种具备架构和组织上下文感知能力的 AI 代码助手后, 软件任务的完成率提高了 26%, 代码质量也有了可衡量的提升¹⁰²。

引用的著作

1. Understanding Prompt Engineering and Context Engineering, 访问时间为八月 30, 2025, https://www.walturn.com/insights/understanding-prompt-engineering-and-context-engineering2. Context Engineering vs Prompt Engineering | by Mehul Gupta | Data Science in Your Pocket, 访问时间为八月 30, 2025, https://medium.com/data-science-in-your-pocket/context-engineering-vs-prompt-engineering-379e9622e19d3. Context Engineering: Moving Beyond Prompting in AI | DigitalOcean, 访问时间为八月 30, 2025, https://www.digitalocean.com/community/tutorials/context-engineering-moving-beyond-prompting-ai4. Context engineering is just software engineering for LLMs - Inngest Blog, 访问时间为八月 30, 2025, https://www.ingest.com/blog/context-engineering-is-software-engineering-for-llms5. Context Engineering: A Guide With Examples - DataCamp, 访问时间为八月 30, 2025, https://www.datacamp.com/blog/context-engineering6. Context Engineering - What it is, and techniques to consider - Llamaindex, 访问时间为八月 30, 2025, https://www.llamaindex.ai/blog/context-engineering-what-it-is-and-techniques-to-consider7. A Gentle Introduction to Context Engineering in LLMs - KDnuggets, 访问时间为八月 30, 2025, https://www.kdnuggets.com/a-gentle-introduction-to-context-engineering-in-llms8. www.ingest.com, 访问时间为八月 30, 2025, https://www.ingest.com/blog/context-engineering-is-software-engineering-for-

llms#:~:text=Context%20engineering%20is%20all%20about.to%20those%20of%20Software%20Engineering.

9. The New Skill in AI is Not Prompting, It’s Context Engineering - Philschmid, 访问时间为八月30,2025, https://www.philschmid.de/context-engineering

10. The rise of “context engineering” - LangChain Blog, 访问时间为八月30,2025, https://blog.rangchain.com/the-rise-of-context-engineering/

11. Context Engineering Guide, 访问时间为八月30,2025, https://wwwpromptingguide.ai/guides/context-engineering-guide

12. What is Context Engineering? The New Foundation for Reliable AI and RAG Systems, 访问时间为八月30,2025, https://datasciencedojo.com/blog/what-is-context-engineering/

13. [2503.10677] A Survey on Knowledge-Oriented Retrieval-Augmented Generation - arXiv, 访问时间为八月30,2025, https://arxiv.org/abs/2503.10677

14. arxiv.org, 访问时间为八月30,2025, https://arxiv.org/abs/2506.00054

15. arxiv.org, 访问时间为八月30,2025, https://arxiv.org/html/2503.10677v2

16. Retrieval-Augmented Generation: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers - ResearchGate, 访问时间为八月30,2025, https://www.researchgate.net/publication/392335133_Retrieval-Augmented_Generation_A_Comprehensive_Survey_of_Architectures_Enhancements_and_Robustness_Frontiers

17. Retrieval-Augmented Generation: A Comprehensive Survey of Architectures, Enhancements, and Robustness Frontiers - arXiv, 访问时间为八月30,2025, https://arxiv.org/html/2506.00054v1

18. What is RAG (Retrieval Augmented Generation)? - IBM, 访问时间为八月30,2025, https://www.ibm.com/think/topics/retrieval-augmented-generation

19. A Survey on Knowledge-Oriented Retrieval-Augmented Generation | Request PDF, 访问时间为八月30,2025, https://www.researchgate.net/publication/389894329_A_Survey_on_Knowledge-Oriented_Retrieval-Augmented_Generation

20. Revision History for A Survey on Knowledge-Oriented… - OpenReview, 访问时间为八月30,2025, https://openreview.net/revisions?id=210f8Rl8zW

21. [2402.19473] Retrieval-Augmented Generation for AI-Generated Content: A Survey - arXiv, 访问时间为八月30,2025, https://arxiv.org/abs/2402.19473

22. Related papers: A Retrieval-Augmented Generation Framework for, 访问时间为八月30,2025, https://fugumt.com/fugumt/paper_check/2412.15404v1_enmode

23. Jie Ma (马杰) - Google Scholar, 访问时间为八月30,2025, https://scholar.google.com.hk/citations?user=VsY24XkAAAAJ&hl=ja

24. [2501.13958] A Survey of Graph Retrieval-Augmented Generation for Customized Large Language Models - arXiv, 访问时间为八月30,2025, https://arxiv.org/abs/2501.13958

25. [PDF] Graph Retrieval-Augmented Generation: A Survey - Semantic Scholar, 访问时间为八月30,2025, https://www.semanticscholar.org/paper/9ab45aa875b56335303398e84a59a3756cd9d530

26. Daily Papers - Hugging Face, 访问时间为八月 30, 2025, https://huggingface.co/papers?q=Graph-based%20Retrieval-Augmented%20Generation27. Data Governance for Retrieval-Augmented Generation (RAG) - Enterprise Knowledge, 访问时间为八月 30, 2025, https://enterprise-knowledge.com/data-governance-for-retrieval-augmented-generation-rag/28. [2503.18016] Retrieval Augmented Generation and Understanding in Vision: A Survey and New Outlook - arXiv, 访问时间为八月 30, 2025, https://arxiv.org/abs/2503.1801629. Corrective and Self-Reflective RAG with LangGraph | by Cole McIntosh | Medium, 访问时间为八月 30, 2025, https://medium.com/@colemcintosh6/corrective-and-self-reflective-rag-with-langgraph-364b7452fcd3e30. Self-Reflective RAG with LangGraph - LangChain Blog, 访问时间为八月 30, 2025, https://blog.langchain.com/agentic-rag-with-langgraph/31. Four retrieval techniques to improve RAG you need to know | Thoughtworks United States, 访问时间为八月 30, 2025, https://www.thoughtworks.com/en-us/insights/blog/generative-ai/four-retrieval-techniques-improve-rag32. Corrective RAG (CRAG) - GitHub Pages, 访问时间为八月 30, 2025, https://langchain-ai.github.io/langgraph/tutorials/rag/langgraph_crag/33. Advanced RAG Techniques | Pinecone, 访问时间为八月 30, 2025, https://www.pinecone.io/learn/advanced-rag-techniques/34. Self-RAG: AI That Knows When to Double-Check - Analytics Vidhya, 访问时间为八月 30, 2025, https://www.analyticsvidhya.com/blog/2025/01/self-rag/35. Types of prompting - Hochschule Augsburg, 访问时间为八月 30, 2025, https://www.tha.de/en/Types-of-prompting.html36. What is chain of thought (CoT) prompting? | IBM, 访问时间为八月 30, 2025, https://www.ibm.com/think/topics/chain-of-thoughts37. Chain of Thought (COT), Tree of Thought (TOT), and ReAct (Response & Act) - Medium, 访问时间为八月 30, 2025, https://medium.com/@sujathamudadla1213/chain-of-thought-cot-tree-of-thought-tot-and-react-response-act-6d8103f52a4838. AI Prompting (2/10): Chain-of-Thought Prompting - 4 Methods for Better Reasoning - Reddit, 访问时间为八月 30, 2025, https://www.reddit.com/r/PromptEngineering/comments/lif2dlo/ai_prompting_210_chainofthought_prompting4/39. www.tha.de, 访问时间为八月 30, 2025, https://www.tha.de/en/Types-of-prompting.html#/~:text=While%20CoT%20 proposes%20a%20straightforward.a%20tree%20and%20branch%20framework.&text=The%20ToT%20approach%20allows%20the,path%20or%20choose%20another%20one.40. Tree of Thoughts (ToT) | Prompt Engineering Guide, 访问时间为八月 30, 2025, https://www.promptingguide.ai/techniques/tot

27. What is Tree Of Thoughts Prompting? - IBM, 访问时间为八月 30, 2025, https://www.ibm.com/think/topics/tree-of-thoughts42. Tree-of-Thought Prompting: Key Techniques and Use Cases - Helicone, 访问时间为八月 30, 2025, https://www.helicone.ai/blog/tree-of-thought-prompting43. Unlocking LLMs’ Potential with Tree-of-Thought Prompting | by Albert | Medium, 访问时间为八月 30, 2025, https://medium.com/@albert_88839/unlocking-llms-potential-with-tree-of-thought-prompting-31e9a34f483044. Understanding and Implementing the Tree of Thoughts Paradigm, 访问时间为八月 30, 2025, https://huggingface.co/blog/sadhaklal/tree-of-thoughts45. Best Practices in Retrieval-Augmented Generation (RAG), 访问时间为八月 30, 2025, https://agentstudio.ai/blog/best-practices-in-rag46. The Architect’s Guide to Production RAG: Navigating Challenges …, 访问时间为八月 30, 2025, https://www.ragie.ai/blog/the-architects-guide-to-production-rag-navigating-challenges-and-building-scalable-ai47. 12 RAG Framework Challenges for Effective LLM Applications - Data Science Dojo, 访问时间为八月 30, 2025, https://datasciencedojo.com/blog/rag-framework-challenges-in-llm/48. Best Practices for Building RAG Apps - Ziliz blog, 访问时间为八月 30, 2025, https://ziliz.com/blog/best-practice-in-implementing-rag-apps49. Best Practices for RAG Pipelines - Mastering LLM (Large Language Model), 访问时间为八月 30, 2025, https://masteringllm.medium.com/best-practices-for-rag-pipeline-8c12a809645350. Building Production-Ready RAG Systems: Best Practices and Latest Tools | by Meeran Malik, 访问时间为八月 30, 2025, https://medium.com/@meeran03/building-production-ready-rag-systems-best-practices-and-latest-tools-581cae9518e751. How does indexing work in a vector DB (IVF, HNSW, PQ, etc.)? - Milvus, 访问时间为八月 30, 2025, https://milvus.io/ai-quick-reference/how-does-indexing-work-in-a-vector-db-ivf-hnsw-pq-etc52. Optimize generative AI applications with pgvector indexing: A deep …, 访问时间为八月 30, 2025, https://aws.amazon.com/blogs/database/optimize-generative-ai-applications-with-pgvector-indexing-a-deep-dive-into-ivfflat-and-hnsw-techniques/53. Vector Indexing | Weaviate Documentation, 访问时间为八月 30, 2025, https://docs.weaviate.io/weaviate/concepts/vector-index54. Vector Database Basics: HNSW | TigerData, 访问时间为八月 30, 2025, https://www.tigerdata.com/blog/vector-database-basics-hnsw55. About hybrid search | Vertex AI | Google Cloud, 访问时间为八月 30, 2025, https://cloud.google.com/vertex-ai/docs/vector-search/about-hybrid-search56. cloud.google.com, 访问时间为八月 30, 2025, https://cloud.google.com/vertex-ai/docs/vector-search/about-hybrid-search#:~:t ext=With%20hybrid%20search%20in%20Vector.and%20token%2Dbased%20sea

rch%20results.

57. Hybrid Search Explained | Weaviate, 访问时间为八月 30, 2025, https://weaviate.io/blog/hybrid-search-explained

58. Understand Hybrid Search - Oracle Help Center, 访问时间为八月 30, 2025, https://docs.oracle.com/en/database/oracle/oracle-database/23/vecse/understand-hybrid-search.html

59. Top techniques to Manage Context Lengths in LLMs - Agenta AI, 访问时间为八月 30, 2025, https://agentai/blog/top-6-techniques-to-manage-context-length-in-llms

60. 6 Techniques You Should Know to Manage Context Lengths in LLM Apps - Reddit, 访问时间为八月 30, 2025, https://www.reddit.com/r/LLMDevs/comments/1mviv2a/6_techniques_you_should-know_to_manage_context/

61. Strategies and Techniques for Managing the Size of the Context Window When Using LLM (Large Language Models), 访问时间为八月 30, 2025, https://mohdmus99.medium.com/strategies-and-techniques-for-managing-the-size-of-the-context-window-when-using-llm-large-3c2dbc5dccc3a

62. Reducing Latency and Cost at Scale: How Leading Enterprises Optimize LLM Performance, 访问时间为八月 30, 2025, https://www.tribe.ai/applied-ai/reducing-latency-and-cost-at-scale-llm-performance

63. Lost in the Middle: How Language Models Use Long Contexts …, 访问时间为八月 30, 2025, https://direct.mit.edu/tacl/article/doi/10.1162/tacl_a_00638/119630/Lost-in-the-Middle-How-Language-Models-Use-Long

64. Found in the Middle: How Language Models Use Long Contexts Better via Plug-and-Play Positional Encoding - arXiv, 访问时间为八月 30, 2025, https://arxiv.org/html/2403.04797v1

65. Evaluating Long Context Lengths in LLMs: Challenges and Benchmarks | by Onn Yun Hui, 访问时间为八月 30, 2025, https://onnyunhui.medium.com/evaluating-long-context-lengths-in-llms-challenges-and-benchmarks-ef77a220d34d

66. [D] Is There a Universally Agreed Explanation for “Lost in the Middle”? - Reddit, 访问时间为八月 30, 2025, https://www.reddit.com/r/MachineLearning/comments/1g6avhy/d_is_there_a_universally_agreed_explanation_for/

67. Make Your LLM Fully Utilize the Context - OpenReview, 访问时间为八月 30, 2025, https://openreview.net/forum?id=YGTVEmBXtV

68. Context Engineering: Can you trust long context? - Vectara, 访问时间为八月 30, 2025, https://www.vectara.com/blog/context-engineering-can-you-trust-long-context

69. Faster, Cheaper, Better: Multi-Objective Hyperparameter Optimization for LLM and RAG Systems - arXiv, 访问时间为八月 30, 2025, https://arxiv.org/html/2502.18635v1

70. A Practical Guide to Reducing Latency and Costs in Agentic AI …, 访问时间为八月

30, 2025, https://georgian.io/reduce- llm- costs- and- latency- guide/

71. Master RAG Optimization: Key Strategies for AI Engineers - Galileo AI, 访问时间为八月 30, 2025, https://galileo.ai/blog/rag-performance-optimization

72. RAG Evaluation Metrics: Best Practices for Evaluating RAG Systems - Patronus AI, 访问时间为八月 30, 2025, https://www.patronus.ai/llm-testing/rag-evaluation-metrics

73. Tutorial - Evaluate RAG Responses using Ragas | Couchbase …, 访问时间为八月 30, 2025, https://developer.couchbase.com/tutorial-evaluate-rag-responses-using-ragas/

74. Understanding RAGAS: A Comprehensive Framework for RAG System Evaluation, 访问时间为八月 30, 2025, https://dev.to/angu10/understanding-ragas-a-comprehensive-framework-for-rag-system-evaluation-447n

75. RAG Evaluation: Don’t let customers tell you first | Pinecone, 访问时间为八月 30, 2025, https://www.pinecone.io/learn/series/vector-databases-in-production-for-busy-engineers/rag-evaluation/

76. RAG Evaluation Survey: Framework, Metrics, and Methods - EvalScope, 访问时间为八月 30, 2025, https://evalscope.readthedocs.io/en/latest/blog/RAG/RAG_Evaluation.html

77. Evaluate RAG pipeline using Ragas in Python with watsonx - IBM, 访问时间为八月 30, 2025, https://www.ibm.com/think/tutorials/evaluate-rag-pipeline-using-ragas-in-python-with-watsonx

78. Ragas, 访问时间为八月 30, 2025, https://docs.ragas.io/en/stable/

79. ARES Documentation: Home, 访问时间为八月 30, 2025, https://ares-ai.vercel.app/

80. stanford-futuredata/ARES: Automated Evaluation of RAG Systems - GitHub, 访问时间为八月 30, 2025, https://github.com/stanford-futuredata/ARES

81. ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems, 访问时间为八月 30, 2025, https://arxiv.org/html/2311.09476v2

82. ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems - ACL Anthology, 访问时间为八月 30, 2025, https://aclanthology.org/2024.naacl-long/20/

83. Paper page - ARES: An Automated Evaluation Framework for Retrieval-Augmented Generation Systems - Hugging Face, 访问时间为八月 30, 2025, https://huggingface.co/papers/2311.09476

84. Making RAG Production-Ready: Overcoming Common Challenges with Solutions, 访问时间为八月 30, 2025, https://www.konverso.ai/en/blog/rag

85. RAG in Production: Deployment Strategies & Practical Considerations - Coralogix, 访问时间为八月 30, 2025, https://coralogix.com/ai-blog/rag-in-production-deployment-strategies-and-practical-considerations/

86. LangChain vs Llamalndex: A Detailed Comparison | DataCamp, 访问时间为八月 30, 2025, https://www.datacamp.com/blog/langchain-vs-llamaindex

87. Llamalndex vs. LangChain: Which RAG Tool is Right for You? - n8n Blog, 访问时间为八月 30, 2025, https://blog.n8n.io/llamaindex-vs-langchain/

88. For RAG Devs - langchain or llamaindex? - Reddit, 访问时间为八月 30, 2025, https://www.reddit.com/r/Rag/comments/1g2h7s8/for Rag_devs_langchain_or_llamaindex/

89. RAG Wars - Llama Index vs. Langchain Showdown - USEReady, 访问时间为八月 30, 2025, https://www.userready.com/blog/rag-wars-llama-index-vs-langchain-showdown

90. The future of Multimodal RAG: Transforming AI… - Superlinear, 访问时间为八月 30, 2025, https://superlinear.eu/insights/articles/the-future-of-multimodal-rag-systems-tra nsforming-ai-capabilities

91. An Easy Introduction to Multimodal Retrieval-Augmented Generation for Video and Audio, 访问时间为八月 30, 2025, https://developer.nvidia.com/blog/an-easy-introduction-to-multimodal-retrieval-a ugmented-generation-for-video-and-audio/

92. An Easy Introduction to Multimodal Retrieval-Augmented Generation - NVIDIA Developer, 访问时间为八月 30, 2025, https://developer.nvidia.com/blog/an-easy-introduction-to-multimodal-retrieval-a ugmented-generation/

93. Multimodal RAG: Boosting Search Precision & Relevance | GigaSpaces AI, 访问时间为八月 30, 2025, https://www.gigaspaces.com/blog/multimodal-rag-boosting-search-precision-relevance

94. A Survey on Multimodal Retrieval-Augmented Generation - arXiv, 访问时间为八月 30, 2025, https://arxiv.org/html/2504.08748v1

95. Context Engineering: The Future of AI Prompting Explained - AI-Pro.org, 访问时间为八月 30, 2025, https://ai-pro.org/learn-ai/articles/context-engineering

96. LLM Context Windows: Basics, Examples & Prompting Best Practices - Swimm, 访问时间为八月 30, 2025, https://swimm.io/learn/large-language-models/llm-context-windows-basics-examples-and-prompting-best-practices

97. [2507.13334] A Survey of Context Engineering for Large Language Models - arXiv, 访问时间为八月 30, 2025, https://arxiv.org/abs/2507.13334

98. 10 Real-World Examples of Retrieval Augmented Generation - Signity Solutions, 访问时间为八月 30, 2025, https://www.signitysolutions.com/blog/real-world-examples-of-retrieval-augmented-generation

99. Enterprise RAG: Beyond the Basics | by Praful Krishna - Medium, 访问时间为八月 30, 2025, https://praful-krishna.medium.com/enterprise-rag-beyond-the-basics-bOff874a3915

100. What is Context Engineering? | Pinecone, 访问时间为八月 30, 2025, https://www.pinecone.io/learn/context-engineering/

101. Context Engineering: The New Backbone of Scalable AI Systems - Qodo, 访问

时间为八月 30, 2025, https://www.qodo.ai/blog/context- engineering/102. Case Studies: Real- World Applications of Context Engineering …, 访问时间为八月 30, 2025, https://www.marktechpost.com/2025/08/12/case- studies- real- world- applications- of- context- engineering/103. RAG for Code Generation: Automate Coding with AI & LLMs - Chitika, 访问时间为八月 30, 2025, https://www.chitika.com/rag- for- code- generation/104. A Survey on Large Language Models for Code Generation - SciSpace, 访问时间为八月 30, 2025, https://scispace.com/pdf/a- survey- on- large- language- models- for- code- generation- 3wcynsnccb.pdf105. A Survey on Large Language Models for Code Generation - ResearchGate, 访问时间为八月 30, 2025, https://www.researchgate.net/publication/381126726_A_Survey_on_Large_Language_Models_for_Code_Generation106. A Recipe for a Better AI- based Code Generator | Pulumi Blog, 访问时间为八月 30, 2025, https://www.pulumi.com/blog/codegen- learnings/107. Gemini Embedding: Powering RAG and context engineering …, 访问时间为八月 30, 2025, https://devagopers.googleblog.com/en/gemini- embedding- powering- rag- context- engineering/