作者来自 Elastic Tomás Murúa上下文工程技术如何防止 LLM 响应中的上下文投毒。Agent Builder 现在已经正式发布。你可以通过 Elastic Cloud Trial 开始使用并在这里查看 Agent Builder 的文档。随着 Claude Sonnet 4.5、Gemini 3 系列 和 GPT 5 等模型的最新发布这些模型都支持百万 token 级别的上下文窗口一种误解正在出现上下文管理似乎正在变得更简单。如果一个 大语言模型 LLM 可以一次处理数百万个 token那么我们提供什么信息真的还重要吗现实恰恰相反。上下文工程 —— 也就是管理哪些信息能够进入你的 LLM —— 比以往任何时候都更加关键。更大的上下文窗口并不会消除对精确性的需求反而会放大它。上下文越多错误、幻觉以及无关信息污染 LLM 推理过程的机会就呈指数级增长。无论你使用的是检索增强生成 RAG 检索、工具输出还是记忆系统有效的上下文工程并不是提供更多信息而是提供正确的信息。这正是 Elasticsearch 发挥作用的地方它作为你的上下文工程平台。在本文中我们将探讨什么是上下文投毒它如何在不同类型的记忆中表现出来以及 Elasticsearch 的 RAG 能力如何在检索流水线的每一个阶段提供防御 —— 从数据摄取到上下文组合 —— 确保你的 LLM 接收到干净、相关且可靠的上下文。什么是上下文投毒上下文投毒是指被破坏的、过期的或无关的信息进入 LLM 的上下文窗口从而导致响应质量下降、产生幻觉或持续性错误。一旦被污染或不正确的信息进入上下文窗口它就会被传播到答案中。LLM 会将其当作事实来引用从而在整个对话过程中产生级联错误。这种投毒可能发生在 LLM 生命周期的多个阶段例如训练阶段但我们关注的是检索和组合阶段。尽管像 prompt injection 这样的对抗性攻击同样存在风险本文重点讨论的是团队在生产环境中最常遇到的操作模式问题。操作层面的理解上下文投毒通常由于以下原因发生Context rot/上下文衰减信息已经过期但仍然保留在你的知识库中没有被更新或删除。Context overflow/上下文溢出信息量过大淹没了 LLM 对真正重要且相关上下文的关注导致答案中遗漏关键信息。Conflicting information/信息冲突多个来源提供相互矛盾的数据使模型产生混淆。Semantic noise/语义噪声在向量上相似但在语义上下文中无关的内容稀释了相关性。Malicious injection/恶意注入攻击者故意向知识库中插入内容包括 prompt injection 或被操纵的数据。理解这些模式是构建强大防御机制的第一步。接下来我们将逐一分析每种模式以及 Elasticsearch 如何帮助你应对它们。你也可以结合配套的 notebook 一起跟随实践。更多阅读使用 Elasticsearch 管理 agentic 记忆上下文投毒的类型时间降解随着时间推移你的知识库中的信息会变得过时如果没有适当管理陈旧内容会继续被检索并呈现给你的 LLM当作最新事实。这在信息频繁变化的行业尤其成问题例如产品文档、定价、法规或新闻。影响你的 LLM 会提供过时的建议、引用已弃用的功能或与当前实际情况相矛盾从而削弱用户信任。解决方案混合搜索中的时间过滤Elasticsearch 基于日期的查询能力可以通过明确的时间过滤器确保你的 RAG system 优先检索最近且相关的信息。示例带时间过滤的产品文档搜索用户向你的 chatbot 询问认证设置。六个月前认证流程发生了重大变化因此只返回六个月以内的文档或更早的文档非常重要。如果没有时间过滤器POST product-docs/_search { retriever: { rrf: { retrievers: [ { standard: { query: { semantic: { field: content_semantic, query: how to configure OAuth authentication } } } }, { standard: { query: { multi_match: { query: configure OAuth authentication, fields: [title^2, content] } } } } ], rank_window_size: 50, rank_constant: 20 } }, _source: [title, last_updated, version, content_snippet] }未过滤时的响应结果矛盾LLM 收到三种不同的 OAuth 配置方法当前的安全 API9.x、遗留的 realm 设置7.x以及已弃用的 shield 插件6.x。这种矛盾的上下文会导致混乱或误导性的响应{ hits: { total: { value: 23 }, max_score: 24.5, hits: [ { _id: doc-oauth-2025, _score: 24.5, _source: { title: OAuth 2.0 Authentication Setup, last_updated: 2025-10-15, version: 9.x, content_snippet: To configure OAuth 2.0 authentication in Elasticsearch 9.x, use the new security API... } }, { _id: doc-oauth-2023, _score: 23.8, _source: { title: OAuth Authentication Configuration, last_updated: 2023-04-20, version: 7.x, content_snippet: Configure OAuth using the legacy realm settings in elasticsearch.yml... } }, { _id: doc-oauth-deprecated, _score: 22.9, _source: { title: Setting Up OAuth (Deprecated), last_updated: 2022-11-10, version: 6.x, content_snippet: Use the shield plugin to configure OAuth authentication... } } ] } }使用时间过滤添加过滤器将结果限制为过去六个月内更新的文档POST product-docs/_search { retriever: { rrf: { retrievers: [ { standard: { query: { semantic: { field: content_semantic, query: how to configure OAuth authentication } } } }, { standard: { query: { multi_match: { query: configure OAuth authentication, fields: [title^2, content] } } } } ], filter: [ {range: {last_updated: {gte: now-6M}}}, {term: {status: published}} ], rank_window_size: 50, rank_constant: 20 } }, _source: [title, last_updated, version, content_snippet], size: 5 }这个混合搜索查询语义搜索semantic使用 content_semantic 字段捕捉相关概念和上下文。词汇搜索multi_match匹配像 “OAuth” 这样的精确关键词并对 title^2 字段进行加权。倒数排序融合RRF结合两组结果进行平衡重排序检索最相关的结果。时间过滤器确保只检索过去六个月内更新的文档。状态过滤器将结果限制为已发布文档排除草稿或已弃用内容。使用时间过滤后的响应结果一致时间过滤消除了过时文档只保留了 9.x 版本的最新文档。LLM 现在接收到一致的上下文生成自信且准确的响应{ hits: { hits: [ { _source: { title: OAuth 2.0 Authentication Setup, last_updated: 2026-01-15, version: 9.x, content_snippet: Configure OAuth 2.0 in Elasticsearch 9.x using the security API via Stack Management Security. } }, { _source: { title: OAuth Provider Configuration, last_updated: 2025-12-20, version: 9.x, content_snippet: Configure Okta, Azure AD, Auth0 via security API with OIDC auto-discovery. } } ] } }相对时间过滤与绝对时间过滤相对过滤推荐用于大多数用例filter: [ { range: { last_updated: { gte: now-1y } } } ]绝对时间过滤用于特定时间范围filter: [ { range: { last_updated: { gte: 2025-01-01, lte: 2025-12-31 } } } ]对 LLM 响应质量的影响未过滤时LLM 收到 2023–2025 年的矛盾指南生成混合了已弃用和当前方法的不确定响应。使用时间过滤后LLM 只接收最新文档基于当前最佳实践生成自信的响应。信息冲突当你的 RAG system 检索到在不同部署类型、版本或配置下行为不同的功能文档时冲突的信息可能会让 LLM 不清楚哪些指导适用于用户的具体上下文。影响LLM 需要使用更多资源和 token 来理解并判断哪些信息是正确的因此更容易出错或产生幻觉。解决方案带元数据加权的混合搜索Elasticsearch 的 bool 查询结合 should 子句允许你提升特定元数据的权重确保与部署类型或版本相关的文档优先出现在上下文窗口中。有关查询语法详情请参考 Bool query文档。示例部署特定的功能文档用户询问“如何在 serverless 中配置自定义用户” 你的知识库包含关于 cloud、self-hosted 和 managed 部署的信息。通过合理的元数据优先级LLM 能检索到功能可用性信号并提供正确的指导POST platform-docs/_search { retriever: { rrf: { retrievers: [ { standard: { query: { bool: { must: [ { multi_match: { query: How do I configure custom users in serverless?, fields: [title^2, content] } } ], should: [ {term: {deployment_type: {value: serverless, boost: 3.0}}}, {term: {doc_status: {value: current, boost: 2.0}}} ] } } } }, { standard: { query: { semantic: { field: content_semantic, query: How do I configure custom users in serverless? } } } } ], rank_window_size: 50, rank_constant: 20 } }, _source: [title, deployment_type, feature_supported, content_snippet], size: 5 }这个查询的作用must 子句所有文档必须匹配 “How do I configure custom users in serverless?”带显式加权的 should 子句deployment_type 为 “serverless” 的文档权重提升 3 倍。doc_status 为 “current” 的文档权重提升 2 倍。语义搜索并行运行以捕捉概念匹配。倒数排序融合RRF结合词汇搜索带元数据加权和语义搜索结果兼顾两种方法的优势。预期响应{ hits: { hits: [ { _source: { title: Authentication in Serverless, deployment_type: serverless, feature_supported: false, content_snippet: Custom authentication not available in Serverless. Use SSO with your identity provider. } }, { _source: { title: User Management in Serverless, deployment_type: serverless, feature_supported: false, content_snippet: Direct user creation not supported in Serverless. Use your organizations IdP. } }, { _source: { title: Role-Based Access in Serverless, deployment_type: serverless, feature_supported: true, content_snippet: Configure roles in Serverless console. Roles sync with SSO provider groups. } }, { _source: { title: API Keys in Serverless, deployment_type: serverless, feature_supported: true, content_snippet: Create API keys for programmatic Serverless access. Keys inherit user permissions. } }, { _source: { title: SSO Configuration for Serverless, deployment_type: serverless, feature_supported: true, content_snippet: Configure SSO in Serverless via Cloud console with SAML 2.0 or OIDC. } } ] } }元数据加权如何解决冲突对 LLM 响应质量的影响未使用元数据加权上下文窗口接收来自所有部署类型的等权重文档。LLM 生成模糊的响应在多种可能性之间摇摆未能清楚说明特定部署的限制。使用元数据加权3 倍Managed 部署相关文档在结果顶部占主导。LLM 生成关于功能不可用的直接答案并提供可操作的替代方案同时保持跨部署上下文以便后续问题使用。语义噪声向量相似搜索可能会检索到语义相关但在上下文上与用户需求无关的文档。当 embedding 捕捉到相似性但未理解查询意图时就会发生这种 “语义漂移”。因此当上下文窗口充满无关信息时LLM 生成精确答案的能力会下降。影响LLM 接收到正确但不回答问题的信息浪费了上下文窗口降低了提供答案的质量。解决方案混合搜索Elasticsearch 混合搜索结合词汇精确性和语义理解使用明确的产品过滤器消除跨产品漂移同时保持概念召回能力。示例技术文档搜索开发者搜索 “Elastic Agent configuration”你的知识库包含 Elastic AgentElastic Observability和 Elastic Agent Builder 文档。两者都突出使用了 “agent” 一词使它们在语义上相似。让我们搜索 agent 配置文档POST elastic-docs/_search { retriever: { rrf: { retrievers: [ { standard: { query: { multi_match: { query: agent configuration logs metrics collection, fields: [title^3, content, tags^2], type: best_fields } } } }, { standard: { query: { semantic: { field: content_semantic, query: configuring agents to collect logs and metrics from hosts } } } } ], filter: [ {terms: {product: [observability, elastic-agent]}}, {term: {doc_type: configuration}} ], rank_window_size: 50, rank_constant: 20 } }, _source: [title, product, tags, url], size: 5 }这个混合查询词汇组件multi_match确保对 “agent”、“configuration”、“logs”、“metrics” 和 “collection” 的精确关键词匹配。字段加权title^3, tags^2优先显示这些词出现在重要字段的文档。语义组件捕捉关于 “configuring data collection agents” 的概念关系和意图。倒数排序融合RRF使用 rank_constant: 20 对两组结果进行平衡排序合并。产品过滤器将结果限制在 Elastic Observability 和 Elastic Agent 域完全排除 Agent Builder 文档。类别过滤器将结果限制在 “observability” 和 “elastic-agent” 域消除向其他域的语义漂移。预期响应{ hits: { hits: [ { _source: { title: Elastic Agent Input Configuration, product: elastic-agent, tags: [inputs, logs, metrics, configuration], url: /docs/elastic-agent/inputs } }, { _source: { title: Configure Elastic Agent for Log and Metric Collection, product: elastic-agent, tags: [configuration, logs, metrics, observability], url: /docs/elastic-agent/configure } }, { _source: { title: Agent Policies and Integrations, product: observability, tags: [policies, integrations, fleet], url: /docs/fleet/policies } }, { _source: { title: Configuring Agent Outputs, product: elastic-agent, tags: [outputs, elasticsearch, logstash], url: /docs/elastic-agent/outputs } }, { _source: { title: Manage Elastic Agents with Fleet, product: observability, tags: [fleet, agent-management, deployment], url: /docs/fleet/manage-agents } } ] } }混合搜索为什么有效搜索类型优点仅词汇搜索精确的关键词匹配仅语义搜索捕捉语义含义混合搜索兼顾精确性与召回率理解查询意图前后对比LLM 响应比较Elasticsearch RAG 最佳实践遵循以下最佳实践可以优化你的上下文工程有效降低 RAG system 中上下文投毒的风险。通过实施这些策略你可以确保上下文窗口中的每个 token 都为 LLM 提供相关、准确且可靠的响应。选择合适的搜索策略根据数据特性和查询模式选择搜索方法词汇搜索、语义搜索或混合搜索。详细信息请参考 [Search approaches | Elastic Docs]。实现时间意识对于时间敏感的信息需要主动管理以防止过时内容污染上下文窗口。使用带相对时间过滤器的范围查询如 now-6M 或 now-1y来处理频繁变化的内容确保 RAG system 优先检索最近内容。详细信息请参考 [Range query | Reference]。使用元数据加权当知识库中在不同上下文中包含相似内容如多个产品版本、部署类型或用户角色时元数据加权可以优先返回上下文相关的结果。详细信息请参考 [Boolean query | Reference]。必要时应用重排序对于复杂或高优先级查询需要精确性时可实施重排序解决方案通过基于查询和文档语义理解重新排序结果显著提升搜索质量。详细信息请参考 [Ranking and reranking | Elastic Docs]。优化文档切分策略文档切分是将大文本分解为更小 “chunks” 的过程。切分策略影响语义表示和检索精度。较小的 chunk 提供更高粒度但可能丢失上下文较大的 chunk 保留更多上下文但降低检索精度。详细信息请参考 [Understanding chunking strategies in Elasticsearch]。在送入 LLM 前过滤数据向量相似搜索可能检索到语义相关但上下文无关的文档。在将结果送入 LLM 前对 product、category 或 domain 字段应用显式过滤将结果约束到合适的上下文。详细信息请参考 [生产环境中的 RAG 流水线将你的 GenAI 项目落地 - Elasticsearch Labs]。校准检索量 (k)找到检索文档数量的 “适中区间” 至关重要。结果过少会导致答案不完整过多会让 LLM 漏掉关键信息。需要在 token 预算与模型上下文窗口深度之间找到平衡。详细信息请参考 [kNN search in Elasticsearch | Elastic Docs]。考虑对大文档进行摘要当检索内容超过上下文预算时摘要技术可保留关键信息同时减少 token 数量。详细信息请参考 [使用 Elastic 将 AI 摘要添加到你的网站]。监控与迭代随着知识库增长和内容演变建议实施监控以跟踪相关性分数分布、检索结果的时间模式和用户反馈信号。关注过时文档、用户满意度下降或 “no relevant results” 查询增多等迹象。详细信息请参考 [Elastic ObservabilityStreams 数据质量与故障存储洞察]。结论百万 token 上下文窗口的新纪元并未让上下文管理变得无用相反它使上下文工程比以往任何时候都更为关键。随着上下文窗口的扩大来自任何源、工具或内存的投毒风险也随之增加。本文展示的模式不仅适用于 RAG。时间过滤、元数据加权和混合搜索是改善上下文质量的基础技术无论信息源如何都能提高上下文的相关性和准确性。通过实施这些策略你可以控制传递给 LLM 的信息确保在大规模场景下的相关性、准确性和信任度。原文https://www.elastic.co/search-labs/blog/context-poisoning-llm