作者：来自 Elastic Woody Walton

发现如何使用上下文工程和混合搜索，通过聚合、RBAC 和非内容信号来提升 AI 输出的准确性。

Elasticsearch 充满了新功能，可以帮助你为你的用例构建最佳搜索解决方案。在我们关于构建现代 Search AI 体验的实践型网络研讨会上，学习如何将它们付诸行动。你也可以现在开始免费云试用，或在本地机器上尝试 Elastic。

我们已经讨论了混合搜索（部分 I）和上下文工程（部分 II）；现在，让我们深入了解它们如何协同工作，为 RAG 和 agentic AI 操作提供最大效果的目标上下文。

搜索没有消失，它只是换了位置

所以我们已经从主要通过文本框搜索上下文，并使用返回的信息（上下文）来自己构建答案，转变为现在用自然语言告诉 agent 我们想要什么，并让它自动研究并编写答案。科技界的许多人都在指出这一变化，并宣称 “搜索已死”（嗯，SEO 和广告词世界确实在改变：GEO 有人吗？），但搜索对 agentic 操作来说仍然绝对关键 —— 它现在只是主要通过工具在幕后完成。

过去，人类是主观相关性的主要裁定者：每个用户都有自己进行搜索的原因，他们的个人经验也会影响结果的相对准确性。如果我们要信任 agent 能够得到和我们相同（或更好）的结论，我们就需要确保它们可以访问的上下文信息尽可能接近我们的主观意图。我们必须为实现这一目标而为 LLMs 设计上下文！

使用混合搜索检索生成上下文

回到部分 I 里提醒过的，Elastic 的混合搜索结合了传统基于关键词的搜索（语法灵活性、关键词精确性和相关性评分）与向量相似性搜索的语义理解，并提供多种重新排序技术。这种协同（这个词从未有过更真实的用法！）能够带来高度相关的结果，让查询在定位内容时可以更加细致。你不仅可以把主观相关性作为检索阶段之一；真正重要的是，第一阶段检索可以同时包含相关性评分和所有其他模式。

更高的准确性与效率

使用能够提供分布式搜索、检索和重新排序的数据平台作为主要上下文检索引擎非常有意义。你可以使用高级查询语法加入主观意图这个缺失的组件，并过滤掉可能分散注意力或降低返回上下文信息价值的内容。你可以从任意可用的语法选项中选择，或将多种模式组合成一次性搜索，以各自最擅长的方式定位每个数据类型，然后通过重新排序进行组合或重排。你可以让响应只包含你想要的字段或数值，避免无关数据干扰。为了 agent，这种定向灵活性让你能够构建在检索上下文时极其准确的工具。

上下文优化（聚合和非内容信号）

聚合在塑造工具传递到上下文窗口的内容时尤其有用。聚合天然能提供基于数字的事实，描述返回上下文数据的形状，使 LLM 更容易且更准确地进行推理。因为聚合可以分层嵌套，它是为 LLMs 添加多层细节、让其形成更细致理解的简单方式。聚合还可以帮助管理上下文窗口大小 —— 你可以轻松将 100k 文档的查询结果压缩成几百个 token 的聚合洞见。

非内容信号是数据中的固有指标，它告诉你正在查看内容的宏观图景；它们是结果的附加特征，例如受欢迎程度、新鲜度、地理位置、类别、主机多样性或价格区间。这些信息有助于指导 agent 如何衡量其接收到的上下文的重要性。一些简单的例子可以更好说明：

• 提升最新且受欢迎的内容 —— 想象你有一个文章知识库。你想找到与用户查询相关的文章，但你也希望提升那些既最新又被其他用户认为有用的文章（例如 “点赞” 数高）。在这种场景中，我们可以使用混合搜索找到相关的文章，然后基于发布时间和受欢迎度组合进行重新排序。
• 带销售量与库存调整的电商搜索 —— 在电商场景下，你想展示符合用户搜索词的商品，但你也希望推广那些销售良好且有库存的商品。你可能还希望下调库存不足的商品，以避免用户失望。
• 在缺陷跟踪器中优先显示高严重性问题 —— 对软件开发团队来说，搜索问题时，首先呈现高严重性、高优先级、最近更新的问题至关重要。你可以使用 “严重性” 和 “讨论度” 等非内容信号独立衡量不同因素，确保最关键且讨论最活跃的问题排在最前。

这些示例查询及更多内容可以在随附的 Elasticsearch Labs 内容页面找到。

安全性执行

在上下文工程中利用像 Elastic 这样的搜索驱动加速层的一个关键优势，是它内置的安全框架。Elastic 平台确保提供给 agentic 和生成式 AI 操作的上下文能够遵守并保护敏感的私有信息，通过精细的基于角色的访问控制（RBAC）和基于属性的访问控制（ABAC）实现。这意味着查询不仅能被高效处理，结果也会根据发起请求的 agent 或用户的特定权限进行过滤。

Agent 以认证用户的身份运行，因此安全性会通过平台内置的安全功能自动应用：

• 细粒度权限：在文档、字段、甚至术语级别定义访问，确保 AI agent 只接收它被授权查看的数据。
• 基于角色的访问控制（RBAC）：为 agent 或用户分配角色，根据其定义的职责授予特定数据集或功能的访问权限。
• 基于属性的访问控制（ABAC）：基于数据、用户或环境的属性实施动态访问策略，实现高度自适应且具上下文感知的安全性。
• 文档级安全（DLS）和字段级安全（FLS）：这些能力确保即便是在被检索的文档内部，也只有被授权的部分可见，避免敏感信息暴露。
• 与企业安全集成：与现有身份管理系统（如 LDAP、SAML、OIDC）无缝集成，在整个组织范围内执行一致的安全策略。

通过将这些安全措施直接集成到上下文检索机制中，Elastic 充当了一个安全的守门人，确保 AI agent 在定义的数据边界内运行，防止未授权数据暴露，并保持对数据隐私法规的合规性。这对于构建处理机密或专有信息的 agentic AI 系统的可信度至关重要。

额外的好处是，通过在企业数据源之上使用统一的数据加速层，你可以避免 agentic 工具对这些仓库产生意外的临时查询负载。你能在一个位置以近乎实时的方式搜索所有内容，并在一个地方应用安全和治理控制。

基于混合搜索的工具

Elastic 平台有一些核心功能（而且不断增加中），可以大幅加速上下文工程的实现。关键点是平台提供多种实现方式，并具备灵活性，可以随着 AI 生态的发展进行适配、调整和扩展。

介绍 Agent Builder

Elastic Agent Builder 是我们首次进入 agentic AI 工具领域的尝试，它被构建用于与存储在 Elastic 中的数据对话。Agent Builder 提供一个聊天界面，使用户能够在 Kibana 中创建和管理自己的 agent 和工具。它内置 MCP 和 A2A 服务器、可编程 API，以及一组预构建的系统工具，用于查询和探索 Elasticsearch 索引，并从自然语言生成 ES|QL 查询。Agent Builder 允许你创建自定义工具，通过富表达性的 ES|QL 查询语法来定向并塑造返回给 agent 的上下文数据。

你可能会问 ES|QL 如何执行混合搜索？核心能力通过 semantic_text 字段类型与 FORK/FUSE 命令的组合来实现（FUSE 默认使用 RRF 来合并每个 fork 的结果）。下面是一个虚构的商品搜索的简单示例：

FROM products
| FORK
  (MATCH description "high performance gaming laptop" | EVAL search_type = "bm25"),
  (MATCH description_semantic "high performance gaming laptop" | EVAL search_type = "semantic")
| FUSE 
| LIMIT 20
| KEEP product_name, description, _score, search_type

在上例中，每个 FORK 分支中包含的 EVAL 子句并非严格必要；它只是用来演示如何追踪某个结果来自哪种搜索模式。

搜索模板

假设你想将自己的外部 agentic 工具指向你的 Elastic 部署。并且你不想使用 ES|QL，而是想使用多阶段检索器或重用已有的 DSL 语法，同时还希望能控制查询接受的输入、执行搜索的语法，以及输出返回的字段。搜索模板允许用户为常用搜索模式定义预设结构，提高检索数据的效率和一致性。这对与搜索 API 交互的 agentic 工具尤其有益，因为它们帮助标准化模板代码并加快搜索逻辑的迭代。如果需要调整这些因素，只需更新搜索模板，改动即可生效。想看搜索模板与 agentic 工具结合使用的示例，可以参考 Elasticsearch Labs 博客《MCP for intelligent search》，其中在外部 MCP 服务器的工具调用背后使用了搜索模板。

集成工作流（FTW - For The Win!）

在我们新的 agentic AI 世界中，最难应对的事情之一是半自主、自我驱动 “推理” agent 的非确定性特性。上下文工程是 agentic AI 的关键学科：它帮助将 agent 可能生成的结论范围缩小到我们已知的真实情况。即便有高度准确且相关的上下文窗口（当我们超出数值事实的范围时），我们仍然缺少对 agent 响应完全可重复、可靠的那份保证。

当你多次向同一个 agent 发送相同请求时，答案可能基本相同，只是响应中有微小差异。对于简单查询，这通常没问题，几乎察觉不到，我们可以尝试通过上下文工程技术来塑造输出。但随着我们对 agent 的任务变得更复杂，子任务中的一个或多个可能引入轻微变化，从而稍微改变最终结果。当我们更多依赖 agent 之间的通信时，这种差异可能会累积。这再次表明，agent 所交互的工具需要非常灵活和可调，以精确定位上下文数据，并以预期输出格式响应。此外，这也说明在许多用例中，我们需要引导 agent 和工具的交互 —— 这就是工作流发挥作用的地方！

Elastic 很快将在平台核心内集成完全可自定义的工作流。这些工作流可以与 agent 和工具双向操作，工作流可以调用 agent 和工具，agent 和工具也可以调用工作流。在同一个承载所有数据的搜索 AI 平台中完全集成这些能力，将具有变革性，工作流的潜力令人极其兴奋！很快就会到来！

Elastic 作为统一记忆库

作为为近实时搜索设计的分布式数据平台，Elastic 自然执行 agentic AI 系统的长期记忆功能。借助内置的 Agent Builder 聊天体验，我们还可以跟踪和管理短期记忆和聊天历史。由于整个平台是 API 优先的，使用 Elastic 来持久化工具的上下文输出（并能在以后引用）非常容易，这种技术在上下文工程圈子里有时被称为“记笔记”。

在同一个搜索平台上同时拥有短期和长期记忆带来很多内在好处：想象可以将聊天历史和持久化的上下文响应作为未来聊天交互的语义影响因素，或进行威胁分析，或创建由频繁调用工具自动生成的持久化数据产品……可能性无限！

结论

大型语言模型的出现改变了我们匹配内容的方式以及审查数据的方法。我们正快速从当前世界转向一个 agentic AI 主导的世界，在当前世界中，人类进行研究、上下文考量和逻辑推理以回答自己的问题，而在新世界中，这些步骤大部分由 agentic AI 自动完成。为了信任生成的答案，我们需要保证 agent 在生成响应时考虑了所有最相关的信息（包括主观相关性因素）。让 agentic AI 可信的主要方法是通过 RAG 和上下文工程技术为检索附加上下文的工具提供支撑，但这些工具执行初始检索的方式对响应的准确性也至关重要。

Elastic Search AI 平台提供了混合搜索的灵活性和优势，以及多种内置功能，帮助 agentic AI 提高准确性、性能和可扩展性；换句话说，Elastic 是上下文工程多个方面的绝佳平台！通过在搜索平台上标准化上下文检索，我们简化了 agentic 工具的操作 —— 类似于“慢下来才能更快”这个矛盾修辞，在上下文生成层的简化意味着 agentic AI 更快、更可信。

原文：https://www.elastic.co/search-labs/blog/context-engineering-hybrid-search-agentic-ai-accuracy