如何构建AI上下文管道

AI模型价格对比 | AI工具导航 | ONNX模型库 | Vibe Coding教程 | PLC在线仿真器 | Tripo 3D | Meshy AI | ElevenLabs | KlingAI | ArtSpace | Phot.AI | InVideo

AI上下文管道是LLM应用中决定模型接收什么信息、以什么顺序、在什么权限下、以及具有什么评估覆盖范围的组成部分。它将原始应用数据转化为模型实际可用的受控提示词载荷。

对于构建代理、副驾驶、RAG系统或AI工作流的团队来说，上下文质量往往比模型选择更重要。即使是一个更强大的模型，如果你发送过时的文档、冲突的指令、私密记录或80,000个松散相关的token的文本，它仍然可能失败。

构建上下文管道意味着将上下文视为生产基础设施。你定义数据源、检索规则、格式化、权限检查、排序、截断、日志记录和评估。你不再将提示词视为埋在应用代码中的字符串构建器。

1、AI上下文管道的作用

上下文管道准备发送给LLM的最终输入。在典型的应用中，该输入可能包括：

• 系统指令：规则、角色、输出格式、安全约束和工具使用策略。
• 用户请求：用户的直接消息或任务。
• 对话历史：选定的先前轮次、摘要或状态。
• 检索到的知识：文档、工单、代码片段、数据库行或搜索结果。
• 工具结果：API响应、计算结果、工作流状态或代理观察。
• 用户和组织元数据：计划类型、权限、地区、时区、产品设置或功能标志。
• 示例：用于上下文学习的少样本样本。

管道决定这些片段中哪些属于提示词以及如何呈现它们。一个好的管道是有选择性的。它发送足够的信息让模型成功，而不会用噪声淹没提示词。

2、定义任务边界

首先写下模型应该做什么和不应该做什么。这听起来很基础，但许多上下文问题来自不明确的任务边界。

例如，客户支持副驾驶可能需要：

• 使用帮助中心文档和客户账户数据回答问题。
• 为支持人员起草回复。
• 升级计费、法律或安全请求。
• 避免向客户暴露内部备注。

这些需求改变了你包含的上下文。模型可能需要公开文档、客户当前的订阅等级和最近三条支持消息。它可能不需要每一个历史工单、完整计费历史、内部账户备注和无关的产品文档。

为每个工作流写一个简短的上下文合约：

• 任务：起草关于账户设置的支持回复。
• 必需上下文：用户问题、相关帮助文档、账户计划、近期工单线程。
• 禁止上下文：私有管理员备注、支付详情、无关的客户记录。
• 输出：带有源文档引用的草稿回复。
• 失败行为：当缺少必需上下文时，提出澄清问题或升级。

这个合约为你的检索、提示词格式化、权限和评估提供了一个具体目标。

3、盘点你的上下文来源

列出你的应用可能使用的每个来源。将每个来源视为一个具有新鲜度、权限、成本和故障模式的系统。

为每个来源添加元数据。至少跟踪所有者、最后更新时间、可见性级别、允许的用户、预期大小和来源ID。如果你无法将一段上下文追溯到其来源，你后续将很难调试糟糕的输出。

4、将指令与事实分离

一个常见的错误是将指令和事实混合在同一段文本中。例如：

糟糕的模式：

You are a helpful support assistant.
The customer is on the Pro plan.
Always offer a discount if the customer is upset.
The refund policy says refunds are allowed within 14 days.

这个提示词混合了角色指令、账户事实、业务策略和一个有风险的行为规则。当模型失败时，你可能不知道是哪个部分导致了问题。

使用结构化段落代替：

<instructions>
You draft support replies for agents.
Follow the refund policy exactly.
Do not offer discounts unless the policy context explicitly allows it.
</instructions>

<user_context>
Plan: Pro
Account age: 38 days
Region: US
</user_context>

<policy_context>
Refunds are allowed within 14 days of purchase.
Discounts require manager approval.
</policy_context>

清晰的段落帮助模型区分持久规则和临时事实。它们也使测试变更更容易。如果在添加账户元数据后响应质量下降，你可以隔离那个块。

5、在检索之前添加权限检查

不要先检索后过滤。如果检索层在权限运行之前就能访问私密记录，你增加了将敏感数据泄露到追踪记录、日志、模型调用或缓存的提示词载荷中的可能性。

在上下文组装之前运行权限检查：

1. 识别请求用户、组织、工作区和角色。
2. 计算允许的数据范围。
3. 将这些范围传入检索和数据库查询。
4. 在提示词组装之前再次过滤返回的记录。
5. 记录包含的来源ID，但不以明文存储密钥。

例如，内部销售助理不应该为一个只拥有SMB账户访问权限的用户检索企业合同备注。编程代理不应读取被授予范围之外的仓库或工作区文件。HR助理不应拉取薪酬记录，除非工作流明确需要且用户有权限。

如果你使用基于工具的上下文访问，要以同样的谨慎定义工具权限。模型上下文协议可以帮助标准化工具和资源向模型暴露上下文的方式，但你仍然需要应用级别的访问规则。

6、少检索，好排序

许多团队通过添加更多上下文来应对糟糕的模型回答。这通常会使性能更差。大型提示词可能将有用的记录埋在低价值文本、旧策略页面、重复块或无关聊天历史之下。

从倾向于精确性的检索规则开始：

• 返回3到8个高置信度块，而不是30个弱匹配。
• 去重几乎相同的段落。
• 当策略经常变更时，优先选择最近更新的文档。
• 使用来源权威性，例如官方文档优先于Slack消息。
• 保持块边界与含义对齐，例如一个流程、一个策略部分或一个API方法。

对于代码助手，检索一个完整函数及其测试可能优于检索20个分散的代码片段。对于支持机器人，当前的计费策略应该优于两年的旧支持宏，即使两者都提到退款。

模型的上下文窗口设定了一个上限token数，但它不保证对其中的所有内容进行有用的推理。长上下文窗口减少了硬截断错误。它们并不消除了对排序、修剪和评估的需要。

7、为模型使用格式化上下文

上下文应该对模型易于解析，对你的团队易于检查。使用一致的标签、来源ID、时间戳和分隔符。

一个实用的上下文块可能如下所示：

<retrieved_context>
<document id="kb_1042" source="help_center" updated_at="2026-04-18">
Title: Resetting SSO for an organization
Content: Org admins can reset SSO settings from Security > SSO...
</document>

<document id="ticket_8821" source="support_ticket" updated_at="2026-05-02">
Customer reported SSO login failures after rotating their IdP certificate.
</document>
</retrieved_context>

这种格式为模型提供了有用的线索，并为你的日志提供了足够的结构用于调试。你还可以要求输出中包含引用：

When you use retrieved context, cite the document id in square brackets.
If no document supports the answer, say what information is missing.

对于JSON密集型工作流，保持schema简短和稳定。每个提示词中200行的schema会浪费token并增加错误。在应用代码中链接schema ID，然后只注入当前任务所需的字段。

8、有意管理对话历史

聊天历史可以帮助模型跟踪用户意图，但原始历史很快就会变得混乱。用户会改变主意。代理会犯错。工具调用会增加噪声。旧指令可能与新指令冲突。

使用历史记录包含策略：

• 近期轮次：对于简短的支持聊天，包含最近3到6条用户和助手消息。
• 摘要：为长会话维护一个运行中的状态摘要。
• 关键事实：提取持久性事实，如选定的项目、首选语言或确认的约束。
• 丢弃内容：在安全时丢弃闲聊、失败的工具尝试和被取代的需求。

在预订会议的代理中，当前日期、请求的参会者、时区和确认的可用性比每一个早期的排程建议都重要。在编程代理中，最新的失败测试输出和更改的文件比一长串先前的推理都重要。

注意上下文腐烂，即累积的上下文使响应随时间变差。你可以通过比较短、中、长历史载荷在相同任务上的性能来检测它。

9、在需要之前构建截断规则

每个生产上下文管道都需要截断策略。如果你等到提示词超过模型限制时才处理，你的应用可能会截断错误的部分。

分配优先级级别：

1. 最高优先级：系统指令、安全规则、任务所需的工具schema、当前用户请求。
2. 高优先级：权限范围的用户事实、当前工作流状态、排名最高的检索文档。
3. 中等优先级：近期对话轮次、次要检索文档。
4. 低优先级：较旧的聊天历史、冗长的工具日志、低置信度搜索结果。

然后定义确定性的截断行为。例如：

• 永远不要截断当前用户请求。
• 如果需要检索，至少保留2个排名最高的检索块。
• 12条消息后用摘要替换较旧的对话轮次。
• 在缩短高置信度块之前先丢弃低置信度块。
• 如果必需的策略上下文无法容纳，则以安全失败方式处理。

这可以防止随机的提示词切片。它还使评估结果更容易解释，因为相同的输入会产生相同的上下文组装行为。

10、记录发送给模型的精确上下文

如果你不记录最终的提示词载荷，你就是在盲目调试。你需要准确知道模型看到了什么，包括指令、检索到的块、工具输出、历史、元数据和截断决策。

至少记录：

• 提示词模板版本。
• 模型名称和参数。
• 发送给模型的最终组装消息。
• 来源ID和检索分数。
• 检索期间使用的权限范围。
• 按部分计数的token数。
• 截断事件。
• 输出和下游用户操作（如果可用）。

你可能需要编辑密钥、支付数据、健康数据或凭证。编辑应保留足够的结构来调试运行。例如，存储[REDACTED_API_KEY]而不是删除整个工具响应。

精确的上下文记录有助于回答实际问题：

• 模型是否收到了当前策略？
• 检索是否返回了错误的文档？
• 权限过滤器是否失败了？
• 截断是否移除了提示词依赖的示例？
• 模型是否忽略了好的上下文，或基于坏的上下文做出了正确响应？

11、评估每一次上下文变更

即使提示词指令保持不变，上下文变更也可能破坏行为。添加新的文档来源、更改块大小、增加历史长度或重新排列段落都可能影响准确性、延迟和成本。

为重要工作流创建评估集。一个有用的支持助手评估集可能包括：

• 50个常见产品问题及预期源文档。
• 20个策略敏感问题，如退款、数据删除和计费变更。
• 20个权限测试，模型不得暴露私有记录。
• 20个缺失上下文案例，正确答案是提出澄清问题或升级。
• 10个长历史案例，旧指令与最新用户请求冲突。

跟踪与工作匹配的指标：

• 答案正确性：响应是否解决了任务？
• 依据性：响应是否使用了提供的来源？
• 引用准确性：引用的来源是否支持声明？
• 权限安全性：模型是否避免了受限数据？
• 拒绝质量：模型是否正确处理了缺失或禁止的上下文？
• 延迟和成本：上下文变更是否使工作流太慢或太贵？

在上下文管道变更之前和之后运行评估。一个将平均正确性提高3%的检索调整，如果导致一次严重的权限泄露，仍然可能是失败的。像对待代码变更一样对待上下文变更：测试它们、审查它们、版本化它们，并在需要时回滚。

12、需要避免的常见错误

将所有可用数据倾倒入提示词

更多上下文不一定意味着更好的输出。大型提示词通常会增加干扰。在销售助手中，发送每个CRM字段可能导致模型关注旧备注而非当前商机阶段。发送工作流需要的字段即可。

仅依赖长上下文窗口

更大的token限制可能有帮助，但它不能修复糟糕的检索、过时的文档、薄弱的格式化或缺失的权限。长上下文也可能增加延迟和成本。将其视为容量，而非质量保证。

将指令与事实混合

将持久规则与检索到的事实和用户元数据分开。这帮助模型遵循正确的层级，并帮助你的团队调试回归。

忽略权限

权限检查属于上下文管道内部。如果模型不应使用某条记录，该记录就不应进入提示词。这适用于文档、数据库行、工具输出、缓存摘要和对话历史。

未能评估上下文变更

小的上下文变更可能产生大的行为变更。用真实案例测试分块、排序、提示词顺序、摘要、示例和截断规则。

不记录精确的上下文

仅显示用户输入和最终答案的请求日志是不够的。你需要组装后的模型输入来复现故障。没有它，你无法判断是模型失败了还是管道发送了糟糕的上下文。

让上下文焦虑驱动设计

团队有时因为担心模型可能遗漏某些东西而不断添加上下文。这会创造上下文焦虑，其中每个边缘情况都变成另一个提示词段落。使用评估来决定什么值得在提示词中占有一席之地。

13、上下文管道的简单架构

你可以从一个直接的架构开始：

1. 请求接收：接收用户输入、会话ID、组织ID和工作流类型。
2. 策略查找：加载该工作流的上下文合约。
3. 权限范围：计算用户可以访问的内容。
4. 查询规划：决定搜索哪些来源或调用哪些工具。
5. 检索：使用权限范围的过滤器获取候选记录。
6. 排序：按相关性、新鲜度、来源权威性和工作流适合度对候选进行评分。
7. 组装：将指令、事实、历史、工具和检索到的上下文格式化为稳定的段落。
8. 预算：计算token数并应用截断规则。
9. 模型调用：发送最终载荷。
10. 日志记录：记录精确的输入、输出、来源ID、token数和版本。
11. 评估：将运行与测试案例和生产反馈进行比较。

这种架构适用于许多LLM应用。RAG聊天机器人可能侧重于检索和引用质量。代理可能添加工具规划、步骤级记忆和中间观察。代码助手可能添加仓库索引、文件级权限和测试输出摘要。

14、示例：支持代理的上下文管道

想象你正在构建一个帮助支持团队回答客户问题的AI代理。

用户问：

Can I reset SSO for only one workspace without affecting the whole organization?

一个弱管道可能会发送完整的账户对象、20个搜索结果、每个历史工单和一个通用的支持提示词。模型可能用一个看似合理但无依据的说法来回答。

一个更强的管道会这样做：

1. 将工作流检测为support_answer_draft。
2. 检查支持代理是否可以访问该客户的工作区。
3. 检索关于SSO范围、工作区设置和组织设置的排名前5的帮助中心段落。
4. 仅获取此问题所需的账户字段：计划、工作区数量、SSO启用状态和管理员角色。
5. 包含最近4轮对话。
6. 丢弃无关的计费工单。
7. 用来源ID和更新日期格式化每个检索到的文档。
8. 指示模型引用来源，如果文档不能回答工作区级别的SSO行为则请求升级。
9. 记录最终的提示词、检索分数和输出。

最终答案更有可能是准确的，因为模型接收到了相关的、有范围的和最新的上下文。

15、示例：编程代理的上下文管道

编程代理需要不同的上下文。如果用户要求它修复一个失败的测试，代理可能需要：

• 失败的测试输出。
• 测试文件。
• 实现文件。
• 最近的差异。
• 包脚本。
• 仓库约定。

它通常不需要整个仓库。上下文管道可以按导入图、堆栈跟踪路径、最近编辑和语义搜索对文件进行排序。它还可以将工具访问限制在当前分支，并从日志中编辑环境密钥。

好的编程代理上下文是紧凑且可执行的。代理应该知道哪个命令失败了，哪些文件可能相关，以及适用什么约束。如果管道包含100个无关文件，模型可能会做出通过一个测试但破坏另一个的广泛更改。

16、生产检查清单

在发布或更改上下文管道之前，使用此检查清单：

• 每个工作流都有书面的上下文合约。
• 指令、用户事实、检索到的文档、示例和工具结果使用独立的段落。
• 权限检查在检索之前运行，并在提示词组装之前再次运行。
• 检索到的记录包括来源ID、时间戳和权威性信号。
• 分块和排序规则已版本化。
• 对话历史具有摘要和修剪规则。
• 截断行为是确定性的。
• 应用记录发送给模型的精确上下文。
• 评估集涵盖正确性、依据性、权限、缺失上下文和长历史案例。
• 上下文变更在生产发布前经过审查。

14、保持管道无聊且可测试

最好的上下文管道通常是简单、明确和可衡量的。它们不依赖一个巨大的提示词或大型上下文窗口来补偿薄弱的数据处理。它们在权限下检索，清晰地格式化上下文，记录发生了什么，并在用户感受到之前测试变更。

如果你的LLM应用持续产生不一致的答案，在更换模型之前检查上下文。在许多情况下，失败存在于检索、过时的文档、提示词段落排序、缺失的权限或未追踪的截断中。修复这些部分可以在不增加模型成本的情况下提高可靠性。

原文链接: How to Build an AI Context Pipeline

汇智网翻译整理，转载请标明出处