LangChain重构智能体检索：从召回结果到精准上下文注入

摘要：LangChain 介绍 Deep Agents 框架中的检索与上下文工程方法，针对智能体常见的低效搜索、结果膨胀和过期数据问题，强调按任务需求筛选、压缩并组织外部信息。其核心并非简单增加一个向量搜索节点，而是让检索结果与代理规划、工具调用及上下文预算协同：在减少无关 Token 消耗的同时保留可验证的新鲜信息。工程落地的关键在于统一召回、去重、重排、时效性过滤与引用追踪，并以端到端任务成功率而非检索命中率单独评估效果。

---

检索不是终点，而是智能体上下文工程的第一道编译层

LangChain 将 Deep Agents 中的检索问题归结为三类：搜索方式笨拙、工具返回结果过大，以及数据已经过期。解决方案的关键不是把更多内容塞进上下文窗口，而是建立一条受约束的信息管线，将外部数据转换为与当前推理步骤匹配、可验证且预算可控的上下文。

传统 RAG 常把文档切块、向量召回和拼接视为一条固定流水线。智能体场景则更复杂：代理会动态改写查询、调用不同工具、切换任务阶段，并反复读取已有观察结果。若每次工具调用都返回原始文档，代理很快会陷入上下文噪声；相关性不足、来源冲突或内容过时的片段，还可能比“没有检索到”更危险。

核心机制：从宽召回转向查询感知的上下文装配

Deep Agents 的实用思路可拆为四层。

1. 查询扩展与分解：根据当前任务和代理目标生成多个检索方向，覆盖术语变体、实体别名和子问题。扩展查询应接受多个候选答案，避免把首次检索结果误当作唯一事实。
2. 混合召回：结合语义向量检索、关键词或元数据过滤，并在需要时接入实时数据源。语义检索擅长处理概念相似性，关键词匹配则更容易保留精确标识符、错误码和专有名词。
3. 压缩与重排：先以轻量方法去除重复、模板化或低信息片段，再由重排序模型选择真正回答当前查询的证据。压缩不能只按文本长度截断，否则可能删除限定条件、时间戳和引用关系。
4. 上下文装配：把证据放入结构化观察结果中，同时附带来源、时间、相关片段与必要的缺口说明。代理由此能够区分事实、推断和尚未找到的内容。

对长文档而言，仅在最终拼接前截取 Top-K 并不充分。更有效的做法是把“召回分数”与“上下文贡献度”分开：前者衡量语义相关性，后者还取决于当前推理状态、已有上下文以及工具返回是否会重复。检索器应避免重复注入代理已经看到的内容，将新增 Token 用于真正未覆盖的信息。

为什么结果压缩与新鲜度同等重要

大型文档或宽泛查询会产生 oversized results，直接进入上下文后不仅增加推理延迟，也会扩大注意力搜索空间。更严重的是，模型可能从冗余内容中拼接出貌似合理、实际没有证据支持的答案。

理想压缩器应尽量保留：

• 与查询直接相关的陈述；
• 数值、单位、主体、时间和例外条件；
• 支持该陈述的原始定位；
• 文档之间的一致与冲突信号。

新鲜度则需要显式建模。静态向量库通常缺少实时更新机制，代理在处理价格、版本、库存或政策等问题时，即使召回了语义最相近的文档，也可能得到过期结论。工程上可组合更新时间戳过滤、索引增量更新和工具实时查询；对无法确认时效的信息，应在上下文中明确标记，而不是默认视为最新事实。

工程权衡：召回率、Token 成本与延迟

提高 Top-K 或加入更多重排候选通常能改善召回率，但会增加 I/O、嵌入计算和模型调用成本。假设每次检索返回 K 个平均长度为 L 的片段，则注入上下文约为 K × L Token；若单片段压缩比为 c，最终成本可近似写成：

C_tokens = K × L × c

与此同时，端到端延迟不只来自检索：查询改写、召回、重排、压缩和代理推理往往构成串行链路。可将独立的召回分支并行执行，但仍需在合并证据前等待必要结果。对交互式代理而言，更现实的优化目标通常不是召回越多越好，而是在保持任务成功率的前提下，减少重复上下文和无效工具轮次。

重排序模型也会形成额外成本。小规模候选集可以放在代理旁进行快速重排；候选规模较大时，则可先用规则、元数据和轻量嵌入模型缩小范围，再调用高成本模型。高精度 LLM 重排并不自动优于较短上下文，提示模板、候选顺序和压缩策略都会影响结果。

检索结果不等于事实正确

即使检索系统精确召回相关段落，也可能在解析、摘要或重排时改变原意。上下文工程需要保留可追溯性：每个关键主张应能映射回来源片段，冲突结果不应被静默拼接成一个确定答案。

LangChain 的框架化实现适合承担这一层工作，但官方简介未给出具体检索器、重排模型、压缩算法、数据集、基线或量化结果。因此，目前不能据此断言某一种方案普遍优于关键词搜索、图谱检索或领域专用 RAG。是否有效，需要在相同语料、相同代理模型和相同工具权限下比较。

评测应从检索指标走向任务结果

单独报告 Recall@K 或 MRR 不足以证明智能体获得了更好的上下文。完整评测至少应覆盖以下维度：

• 任务成功率：代理是否基于证据完成最终目标；
• 忠实度与引用准确率：回答中的主张是否由检索内容支持；
• 上下文效率：完成任务消耗的输入 Token 和工具调用次数；
• 延迟与成本：查询、召回、重排、压缩及代理推理的端到端开销；
• 新鲜度正确率：对时效敏感任务是否选择有效版本；
• 冲突处理：面对相互矛盾证据时是否暴露不确定性。

这些指标需要联合观察。提升 Recall@K 却增加重复片段，可能降低注意力利用率；压缩过度会提高表面简洁度，却删除关键限定条件；更长上下文提高信息覆盖率，也可能让模型更容易被干扰片段带偏。

开发者落地建议

在现有代理系统中引入检索层时，可按以下顺序推进：

1. 建立一组真实任务失败样本，区分召回失败、解析失败、排序失败、压缩损失和代理未使用证据。
2. 为每次检索记录查询、候选、最终片段、来源、时间戳和 Token 数，避免只监控单一向量相似度。
3. 先实现结构化观察与去重，再引入 LLM 压缩；保留原始片段，便于审计和回放。
4. 对时效性字段建立可验证规则，并在索引层与运行时分别处理静态知识和实时数据。
5. 使用任务成功率、忠实度、Token 消耗与 P95 延迟进行端到端 A/B 测试，并加入无检索基线。
6. 对智能体记忆进行分层：短期任务状态、工作摘要和长期知识分别管理，避免所有历史片段永久驻留上下文。

LangChain 此处的真正贡献，是把检索重新定位为智能体运行时的一项上下文编译工作：它不再只是“找到几篇文章”，而要决定什么信息值得进入模型、何时进入、保留多少，以及如何在数据变化时保持可信。

---

消息来源：LangChain Blog (2026-11-10)

—— 完 ——

主题标签： #LangChain 关注 #Deep Agents 关注 #上下文工程 关注 #检索增强 关注 #Agent Memory 关注