prompt Engineering与context Engineering

发表于 分类于 ， 阅读次数：

prompt Engineering

Prompt Engineering是与大型语言模型（LLM）交互的基础，其核心在于精心设计输入内容，以引导模型生成期望的输出。

尽管 Prompt Engineering 至关重要，但对于构建稳健、可用于生产环境的系统而言，它存在固有的局限性：

  • 脆弱性&不可复现性： 提示中微小的措辞变化可能导致输出结果的巨大差异，使得这一过程更像是一种依赖反复试错的“艺术”，而非可复现的“科学” 。

  • 扩展性差： 手动、迭代地优化提示的过程，在面对大量用户、多样化用例和不断出现的边缘情况时，难以有效扩展 。

  • 用户负担： 这种方法将精心构建一套详尽指令的负担完全压在了用户身上，对于需要自主运行、或处理高并发请求的系统而言是不切实际的 。

  • 无状态性： Prompt Engineering 本质上是为单轮、“一次性”的交互而设计的，难以处理需要记忆和状态管理的长对话或多步骤任务 。

Context Engineering

Context Engineering是一门设计、构建并优化动态自动化系统的学科，旨在为大型语言模型在正确的时间、以正确的格式，提供正确的信息和工具，从而可靠、可扩展地完成复杂任务 。

prompt 告诉模型如何思考，而 Context 则赋予模型完成工作所需的知识和工具。

  • Context Engineering 决定用什么内容填充 Context Window ，

  • Prompt Engineering 则负责优化窗口内的具体指令 。

Context Engineering 的基石：RAG（Retrieval-Augmented Generation）

本部分将阐述检索增强生成（RAG）作为实现 Context Engineering 的主要架构模式。

解决LLM的核心弱点

RAG直接解决了标准LLM在企业应用中存在的固有局限性：

  • 知识冻结： LLM的知识被冻结在其训练数据的时间点。RAG通过在推理时注入实时的、最新的信息来解决这个问题 。

  • 缺乏领域专有知识： 标准LLM无法访问组织的内部私有数据。RAG则能够将LLM连接到这些内部知识库，如技术手册、政策文件等 。

  • 幻觉（Hallucination）： LLM 会不同程度上地编造事实。RAG通过将模型的回答“锚定”在可验证的、检索到的证据上，提高事实的准确性和可信度 。

RAG工作流

  1. 索引（离线阶段）： 在这个阶段，系统会处理外部知识源。文档被加载、分割成更小的 chunks，然后通过Embedding Model 转换为向量表示，并最终存储在专门的向量数据库中以备检索 。

  2. 推理（在线阶段）： 当用户提出请求时，系统执行以下步骤：

    1. 检索（Retrieve）： 将用户的查询同样转换为向量，然后在向量数据库中进行相似性搜索，找出与查询最相关的文档块。
    2. 增强（Augment）： 将检索到的这些文档块与原始的用户查询、系统指令等结合起来，构建一个内容丰富的、增强的最终提示。
    3. 生成（Generate）： 将这个增强后的提示输入给LLM，LLM会基于提供的上下文生成一个有理有据的回答 。

Context 工程化：如何判断和提取哪些内容应该进入上下文？

1.chunking

文本分块（Chunking）是RAG流程中最关键也最容易被忽视的一步。其目标是创建在语义上自成一体的文本块。

2.Reranking

为了平衡检索的速度和准确性，业界普遍采用两阶段检索流程。

  • 两阶段流程：

    • 第一阶段（召回）： 使用一个快速、高效的检索器（如基于 bi-encoder 的向量搜索或BM25等词法搜索）进行广泛撒网，召回一个较大的候选文档集（例如，前100个） 。
    • 第二阶段（精排/重排序）： 使用一个更强大但计算成本更高的模型，对这个较小的候选集进行重新评估，以识别出最相关的少数几个文档（例如，前5个） 。

  • Cross-Encoder： 交叉编码器之所以在重排序阶段表现优越，是因为它与双编码器的工作方式不同。双编码器独立地为查询和文档生成嵌入向量，然后计算它们的相似度。而交叉编码器则是将查询和文档同时作为输入，让模型在内部通过 Attention Mechanism 对二者进行深度交互。这使得模型能够捕捉到更细微的语义关系，从而给出更准确的相关性评分 。

  • 实际影响： 重排序显著提高了最终送入LLM的上下文质量，从而产出更准确、幻觉更少的答案。在金融、法律等高风险领域，重排序被认为是必不可少而非可选的步骤 。

3.优化上下文窗口：压缩与摘要

本节详细介绍用于主动管理上下文的技术，确保最有价值的信息被优先呈现。

  • 上下文压缩的目标： 缩短检索到的文档列表和/或精简单个文档的内容，只将最相关的信息传递给LLM。这能有效降低API调用成本、减少延迟，并缓解 Lost in the Middle 的问题 。

  • 压缩方法：

    • 过滤式压缩： 这类方法决定是保留还是丢弃整个检索到的文档。
      • LLMChainFilter： 利用一个LLM对每个文档的相关性做出简单的“是/否”判断 。
      • EmbeddingsFilter： 更经济快速的方法，根据文档嵌入与查询嵌入的余弦相似度来过滤文档 。
    • 内容提取式压缩： 这类方法会直接修改文档内容。
      • LLMChainExtractor： 遍历每个文档，并使用LLM从中提取仅与查询相关的句子或陈述 。
    • 用 top N 代替压缩： 像LLMListwiseRerank这样的技术，使用LLM对检索到的文档进行重排序，并只返回排名最高的N个，从而起到高质量过滤器的作用 。

  • 作为压缩策略的摘要： 对于非常长的文档或冗长的对话历史，可以利用LLM生成摘要。这些摘要随后被注入上下文，既保留了关键信息，又大幅减少了 Token 数量。这是在长时程运行的智能体中管理上下文的关键技术 。

智能体架构中的数据流与工作流编排

工作流（Workflow） vs. 智能体（Agent）

  • 工作流（Workflows）
    • 指的是LLM和工具通过预定义的代码路径进行编排的系统。在这种模式下，数据流动的路径是固定的、由开发者明确设计的，类似于上世纪流行的“专家系统”。例如，“第一步：分析用户邮件；第二步：根据分析结果在日历中查找空闲时段；第三步：起草会议邀请邮件”。这种模式确定性高，易于调试和控制，非常适合有明确业务流程的场景（如风控需求高、数据敏感、安全等级要求）。
  • 智能体（Agents）
    • 指的是LLM动态地指导自己的流程和工具使用，自主控制如何完成任务的系统。在这种模式下，数据流动的路径不是预先固定的，而是由LLM在每一步根据当前情况和目标动态决定的。这种模式灵活性高，能处理开放式问题，但可控性和可预测性较低 。

复杂的智能体通常是这两种模式的混合体，在宏观层面遵循一个预定义的工作流，但在某些节点内部，又赋予LLM一定的自主决策权。管理这一切的核心，我们称之为编排层（Orchestration Layer） 。

核心架构：预定义数据流的实现

  1. 链式工作流（Prompt Chaining）

  2. 路由工作流（Routing)

  3. 编排器-工作者模式（Orchestrator-Workers）

框架与工具

上述的架构和机制并非凭空存在，而是通过具体的开发框架实现的。其中，LangGraph作为LangChain的扩展，为构建具有显式数据流的智能体系统提供了强大的工具集。

LangGraph：用图（Graph）定义工作流（Workflow）

LangGraph的核心思想是将智能体应用构建成一个状态图（State Graph） 。这个图由节点和边组成，清晰地定义了数据如何在不同模块间流动

  • 状态（State）： 这是整个图的核心，一个所有节点共享的中央数据对象。
    • 你可以把它想象成一个“数据总线”或共享内存。开发者需要预先定义State的结构，每个节点在执行时都可以读取和更新这个State对象 。
  • 节点（Nodes）： 代表工作流中的一个计算单元或一个步骤。
    • 每个节点通常是一个Python函数，它接收当前的State作为输入，执行特定任务（如调用LLM、执行工具、处理数据），然后返回对State的更新 。
  • 边（Edges）： 连接节点，定义了工作流的路径，即数据在State更新后应该流向哪个节点。
    • 简单边（Simple Edges）： 定义了固定的、无条件的流向，用于实现链式工作流 。
    • 条件边（Conditional Edges）： 用于实现路由逻辑。它会根据一个函数的输出来决定接下来应该走向哪个节点，从而实现流程的分支 。
  • 检查点（Checkpointer）： LangGraph提供了持久化机制，可以在每一步执行后自动保存State的状态。这对于构建需要长期记忆、可中断和恢复、或需要 Human-in-the-Loop 的复杂业务流程至关重要 。

复杂业务流程的AI智能体，其核心挑战已从单纯优化信息检索（如RAG）或提示词，转向了对内部工作流和数据流的精心设计与编排。