作者：来自 Elastic Woody Walton
探索混合搜索和上下文工程如何从 LLM 基础演变，以支持下一代具备 agent 能力的 AI 工作流程。
Agent Builder 现已作为技术预览版提供。可以通过 Elastic Cloud 试用开始使用，并在此查看 Agent Builder 的文档。
我们全新的 agentic AI 世界
和许多人一样，我对 AI 能力发展的速度既兴奋又惊讶。我们最初看到大型语言模型（LLMs）和向量搜索让我们进入语义革命的时代 —— 我们不再需要依赖关键词来 “搜索和点选” 信息。随后，LLMs 展示了与数据交互的新方式，使用聊天界面将自然语言请求转化为简明的响应，把庞大的知识库提炼成易于理解的摘要。如今（已经！），我们开始看到由 LLM 驱动的自动化逻辑，以 “agentic AI” 工作流程的形式出现，这些流程能够语义化理解输入请求、推理应采取的步骤，并从可用工具中选择、反复执行操作以实现目标。
agentic AI 的出现促使我们从主要依靠 “提示工程”（prompt engineering）来塑造生成式 AI 交互，转向关注如何帮助 agent 工具获取 LLM 在生成响应时所需的最相关、最有效的附加信息 —— “上下文工程”（context engineering）正是下一个前沿领域。混合搜索（Hybrid search）是提供相关上下文的最强大且最灵活的方法，而 Elastic 的 Search AI 平台为上下文工程打开了全新的数据利用方式。本文将从两个角度讨论 LLM 如何改变信息检索的世界，然后探讨它们如何协同工作以获得更好的结果。我们有很多内容要讲……
第一部分：LLM 与搜索
让我们从 LLM 如何改变我们获取和检索信息的方式说起。
我们的词汇遗产
我们长期生活在一个相对受限的词汇搜索世界（尽可能地适应得还不错）。搜索是我们在研究或开始新项目时首先使用的工具，直到最近，我们都需要以词汇搜索引擎能理解的方式来组织查询。词汇搜索依赖于将查询词与文档语料库中的关键词进行匹配 —— 无论内容是非结构化还是结构化的。要让词汇搜索返回一个文档作为命中结果，它必须匹配上那个关键词（或使用受控词表，如同义词列表或词典，来帮助我们建立概念连接）。
`1. POST my-index/_search {
2. "size": 10,
3. "query": {
4. "multi_match": {
5. "query": "machine learning applications",
6. "fields": ["title", "content"]
7. }
8. }
9. }` AI写代码
一个词汇多字段匹配（multi-match）查询示例
至少搜索引擎有能力返回带有相关性评分的结果。搜索引擎提供丰富的查询语法选项来有效地针对索引数据，并内置相关性算法，根据用户查询语法的意图对结果进行评分。搜索引擎受益于数十年来相关性排序算法的进步，使其成为一种高效的数据检索平台，能够根据查询的相关性对结果进行评分和排序。而数据库及其他使用 SQL 作为主要数据检索方式的系统在这方面处于劣势：数据库查询中没有 “相关性” 这个概念；它们最多只能按字母顺序或数字顺序对结果进行排序。好消息是，你会得到包含这些关键词的所有命中结果（召回率高），但它们的排序不一定符合你提出查询的目的（准确率低）。这是一个重要的点，稍后我们会看到……
登场的（语义）巨龙
将信息向量化作为关键词搜索的替代方案，这一潜力已经被研究了很长时间。向量充满希望，因为它让我们摆脱了仅依赖关键词匹配内容的模式 —— 由于它们是词语和权重的数值表示，向量可以基于语言模型对术语间关系的理解，使概念在数学上 “接近”。通用向量搜索迟迟未能普及的原因在于，早期模型主要局限于特定领域，规模不够大，无法充分理解一个术语在不同上下文中可能代表的多种概念。
直到几年前大型语言模型（LLMs）的出现，才让向量搜索真正成为可能。LLMs 通过 transformer 和 attention 机制在更大规模的数据上进行训练，其规模和深度终于让向量能够存储足够多的语义细节，从而真正捕捉语义意义。这种理解深度的骤增，使得 LLM 能够执行许多以前无法实现的自然语言处理（natural language processing - NLP）功能，其中最有影响力的功能之一，是根据当前上下文推测序列中下一个最可能出现的词。推理（Inference）这一过程赋予了生成式 AI 近似人类的文本生成能力。AI 生成的文本基于 LLM 对训练数据中词语关系的理解，并利用请求的措辞来区分词语在不同上下文中的含义。
尽管生成式 AI 看似 “神奇”，但 LLM 仍存在导致质量和准确性错误的局限性，这种错误通常被称为 “幻觉”（hallucinations）。当 LLM 无法访问所需信息（或没有被正确引导到合适的上下文）时，就会凭空生成一个听起来合理但实际错误的回答。造成这种情况的部分原因是，LLM 虽然学习了大量多样化信息领域中的语言使用方式，但它的训练必须在某个时间点停止，因此其理解存在 “时效性” —— 模型只能知道训练截止时的信息。另一个导致幻觉的因素是，模型通常不了解私有数据（未公开在互联网上的数据），而这些数据往往包含特定的术语和命名体系，这在企业或行业场景中尤其重要。
向量数据库
LLM 使用一种称为 text embedding 的技术将内容向量化到其模型空间中，这种技术指的是根据模型训练所形成的世界观，将内容的语义意义嵌入或映射到模型内部。为生成 embedding，需要对内容进行若干预处理步骤，包括分块（chunking）和分词（tokenization，或子词分词 subword tokenization）。最终的结果通常是一组密集向量（dense vectors），代表模型对该文本块在其向量空间中的语义理解。分块是一个不精确的过程，目的是让内容符合模型在生成 embedding 时的处理限制，同时尽量利用语义结构（如句子和段落边界）将相关文本聚在一起。
分块的需要会导致嵌入文档的语义出现一定程度的丢失，因为单个分块之间无法完全关联同一文档中的其他分块。神经网络本身的不透明性会加剧这种语义丢失 —— LLM 实际上是一个 “黑箱”，它在训练过程中建立的词汇与概念之间的连接是非确定性的，也无法被人类解释。这会带来可解释性、可重复性、潜在偏见以及信任与准确性方面的问题。尽管如此，能在语义层面上连接概念、不再局限于具体关键词进行查询的能力，仍然极其强大：
`
1. POST my-index/_search
2. {
3. "size": 10,
4. "query": {
5. "semantic": {
6. "query": "machine learning applications",
7. "field": "semantic-content-field"
8. }
9. }
10. }
`AI写代码
语义查询示例
向量数据库还有一个需要考虑的问题：它们不是搜索引擎，而是数据库！当执行向量相似性搜索时，查询词会被编码，以在模型的向量空间中找到一组（嵌入）坐标。这些坐标随后被用作 “靶心”，以找到与该靶心 “最近邻” 的文档 —— 也就是说，文档的排名（或在结果中的位置）由该文档坐标与查询坐标之间计算出的相似距离决定。
那么，排名应朝哪个方向优先？哪个可能的上下文最接近用户的意图？我将其比作电影《星际之门》中的一个场景 —— 我们有六个坐标点相交来确定目的地（靶心），但如果没有 “第七个符号”，即表示用户主观意图的起始点坐标，我们无法到达目标。因此，与其让向量的相对排序基于一个不断扩展且未分化的相似性球体，不如通过表达性语法和相关性评分来考虑查询的主观意图，从而得到一个类似 “渐变主观相关性圆柱体” 的结果。
大型语言模型的推理能力或许能帮助识别查询最可能对应的上下文，但问题在于，如果没有额外辅助，传入查询的坐标只能由模型最初的训练方式来决定。
在某种意义上，可以说向量相似性与严格的关键词匹配处于两个极端 —— 它的优势在于能克服词语不匹配的问题，但有时也会过犹不及：LLM 倾向于将相关概念统一起来，而不是区分它们。向量相似性提升了我们在语义层面匹配内容的能力，但并不能保证精确度，因为它可能忽略模型未充分消歧的精确关键词和具体细节。向量相似性搜索本身非常强大，但我们需要找到方法将从向量数据库检索到的结果与其他检索方法的结果进行关联。
重排序技术（Reranking techniques）
现在是时候介绍一种通用技术 —— 重排序（reranking），它通过重新评分或归一化，将结果集调整为统一的排序。需要重排序的原因可能在于来自多个来源或不同检索方法的结果具有不同的排名/评分机制（或者根本没有，比如 SQL！），也可能是为了让非语义来源的结果在语义上与用户查询对齐。重排序属于二次处理阶段，意味着它对通过某种初始检索方法（如 SQL、词法搜索、向量搜索）获得的结果集重新排序，采用不同的评分方法。
可用的方法有多种，包括学习排序（Learning-To-Rank，简称 LTR）和倒数排序融合（Reciprocal Rank Fusion，简称 RRF）。LTR 适用于捕获搜索结果的特征（点赞、评分、点击等），并据此对结果进行加权或偏置；RRF 则非常适合将不同查询方式（如词法搜索和向量搜索）的结果合并为一个统一的结果列表。Elastic 还提供通过线性重排序方法调整分数的灵活性。
然而，最有效的重排序技术之一是语义重排序（semantic reranking）。它利用 LLM 的语义理解能力同时分析查询和结果的向量嵌入，然后应用相关性评分或重新评分来确定最终顺序。语义重排序当然需要连接一个重排序模型。Elasticsearch 提供了 Inference API，让你可以创建重排序端点，使用内置模型（Elastic Rerank）、导入的第三方模型或外部托管服务（如 Cohere 或 Google Vertex AI）。然后，然后，你可以通过检索（retriever）器查询抽象语法执行重新排序。
`
1. POST my-index/_search
2. {
3. "size": 10,
4. "retriever": {
5. "text_similarity_reranker": {
6. "retriever": {
7. "rrf": {
8. "retrievers": [
9. {
10. "standard": {
11. "query": {
12. "multi_match": {
13. "query": "machine learning applications",
14. "fields": [
15. "title",
16. "content"
17. ]
18. }
19. }
20. }
21. },
22. {
23. "knn": {
24. "field": "semantic-content-field",
25. "k": 10,
26. "num_candidates": 100,
27. "query_vector_builder": {
28. "text_embedding": {
29. "model_id": "my-text-embedding-model",
30. "model_text": "machine learning applications"
31. }
32. }
33. }
34. }
35. ],
36. "rank_window_size": 50,
37. "rank_constant": 20
38. }
39. }
40. },
41. "field": "content",
42. "inference_id": "my-reranker",
43. "inference_text": "machine learning applications",
44. "rank_window_size": 20
45. }
46. }
`AI写代码
多阶段 retriever 重排序操作示例
听起来很棒，对吧？我们可以对来自不同来源的结果进行重排序，并接近对各种内容的语义理解……语义重排序在计算和处理时间上都可能很昂贵，因此语义重排序实际上只能对有限数量的结果进行，这意味着初始结果的检索方式非常重要。
上下文检索方法很重要
主观意图是决定结果准确性、评分相关性的重要因素。如果无法考虑用户执行查询的意图（通过灵活语法或二次重排序表达），我们只能从模型空间中已有的上下文中选择。我们通常通过 Retrieval Augment Generation (RAG) 技术来解决上下文不足的问题。RAG 的工作方式是通过在预查询中返回相关上下文数据的附加相关词，有效地移动查询坐标。这使得提供附加上下文的引擎及其初始检索方法对上下文准确性更加重要！
让我们回顾不同的上下文检索方法，以及它们如何帮助或影响 RAG 操作：
-
无搜索引擎的混合检索仍缺乏主观相关性。如果提供 RAG 的平台主要是基于 SQL（包括大多数 “数据湖” 平台），在初始检索阶段就缺少相关性评分。许多数据湖平台提供自己版本的混合检索（不是搜索），通常结合语义重排序和 RRF 对 SQL 检索和向量数据库结果进行重排序。简单排序显然不足以实现主观排序，即使作为二次语义重排序的基础，当语义重排序仅在 “top k” 命中上执行时，SQL 作为第一阶段检索也会成为问题 —— 如果没有在检索阶段对结果评分，我们如何保证最佳结果实际上在前几条中？
-
单靠向量相似性不足以支持 RAG。这主要是由于一系列问题叠加 —— 嵌入的损失、简单的分块方法、相似性计算方式，以及缺少主观意图这一关键因素。RAG 的主要目标之一是将生成式 AI 交互建立在客观事实基础上，以防止幻觉，并向 LLM 提供训练中未知的私人信息。我们可以利用 RAG 提供的附加上下文约束并引导 LLM，考虑我们知道对回答问题最重要的连接和细节。为此，我们需要同时使用语义和词法方法。
-
基于文件的 grep/regex RAG。在 agentic AI 的一些应用中，建议使用极大化的上下文窗口，通过 grep 和 regex 访问本地文件进行 RAG，而不是依赖外部检索平台。思路是，通过更大的上下文窗口，LLM 可以在自身思维空间内建立概念连接，而不必依赖分块信息和多重检索方法/平台来收集相关信息。理论上，拥有整篇文档比分段文档提供更完整的视角，但这只能在小数据域中实现（例如，为 vibecoding 提供文件时），即使如此，初始检索方法也是对所有文档的关键词扫描。
搜索不仅仅是检索
搜索引擎专为尽可能快速和灵活地执行查询而设计。内部利用专门的数据结构存储和检索不同类型的数据，以适应这些数据类型。Elasticsearch 提供对几乎所有类型数据的优化存储和查询，包括非结构化/全文词法搜索（match、phrase、proximity、multi-match）、快速关键词（精确匹配）匹配与过滤、数值范围、日期、IP 地址，并且在文档结构存储方面非常灵活（如嵌套或扁平文档）。Elasticsearch 也是一个原生向量数据库，可存储和查询稀疏和密集向量类型，我们不断探索创新方法（例如 Better Binary Quantization (BBQ) & DiskBBQ）在提高向量化内容速度、可扩展性和成本的同时保持搜索准确性。Elasticsearch 平台还提供内置的数据弹性和高可用性，并包括数据生命周期管理功能，如 Searchable Snapshots，可将不常访问或长期保存的数据存储在低成本对象存储中 —— 同时仍然可以完全搜索。
混合搜索是各种方法中最优的
混合搜索（不仅仅是混合检索！）结合了传统词法搜索的优势与 LLM 的语义理解和向量相似性搜索。这种协同作用允许在检索阶段通过搜索引擎提供的各种灵活查询语法选项获取高度相关的结果：意图驱动的语法选项和相关性评分、多模态数据检索、过滤、聚合和偏置。通过像 ES|QL 这样的搜索语法和多阶段 retrievers，我们可以在一次请求中灵活地将传统搜索与语义搜索、过滤器和多种重排序技术结合起来。
混合搜索的最大好处之一是，你的查询可以同时使用针对多种不同数据类型的专用语法。这些不同的查询语法不仅可以用于查找结果，也可以用作结果的过滤或聚合。例如，最常见且经常与其他语法结合使用的查询类型之一是地理空间分析。你可以查询在指定点附近一定距离内的地理坐标结果，或者按区域对结果进行聚合，或进行聚合以跟踪和提醒进入/离开某个区域的移动情况。使用混合搜索，你可以灵活组合语法，以最准确的方式定位结果，检索最接近你上下文的内容。
插曲
第一部分讲述了向量搜索如何改变我们检索数据的方式，并为 LLM 给我们与数据交互的查询机制带来的变化铺垫了背景。我们假装必须将内容拆分成多个部分，以便 LLM 能在不丢失上下文的情况下理解…… ;-) 在第二部分：LLM 和 Chat 中，我们将学习为什么这很重要；在第三部分，我们将回到混合搜索的讨论。
第二部分：LLM 和 Chat
在了解了 LLM 改变信息检索底层流程的背景后，让我们看看它们如何改变我们查询数据的方式。
与数据交互的新方式
生成式（gen AI）和 agentic AI 的工作方式不同于传统搜索。过去我们开始研究信息的方式是搜索（“让我 Google 一下…”），而 gen AI 和 Agent 的启动动作通常是通过在聊天界面输入自然语言。聊天界面是与 LLM 的对话，它利用语义理解将我们的提问转化为精炼答案，一个看似来自拥有广泛知识的神谕的总结性回应。真正吸引人的地方是 LLM 能够生成连贯、深思熟虑的句子，将它呈现的知识片段串联起来 —— 即使内容不准确或完全虚构，也有一种 “真实感”。
我们习惯使用的旧搜索栏可以被视为当我们自己是推理主体时使用的 RAG 引擎。现在，即使是互联网搜索引擎，也正在将我们熟悉的“ 逐字搜索” 词法体验转化为 AI 驱动的概览，用结果摘要回答查询，帮助用户避免逐条点击和评估结果。
生成式 AI 与 RAG
生成式 AI 尝试利用对世界的语义理解解析聊天请求中表达的主观意图，然后使用推理能力即时生成专家答案。生成式 AI 交互包括几个部分：从用户输入/查询开始，聊天会话中的先前对话可以作为额外上下文，指令提示（instructional prompt）告诉 LLM 如何推理以及在构建回答时应遵循的流程。提示已经从简单的 “像对五岁孩子解释一样” 演变为完整的处理请求流程说明。这些说明通常包括 AI 角色/身份细节、生成前推理/内部思考过程、目标标准、约束条件、输出格式、受众以及示例以展示预期结果。
除了用户查询和系统提示之外，RAG（Retrieval Augmented Generation）在所谓的 “上下文窗口” 中提供额外的上下文信息。RAG 是架构中的关键补充；它用于向 LLM 提供其语义理解中缺失的信息。
上下文窗口在提供内容的类型、位置和数量上可能比较挑剔。当然，选择哪部分上下文非常重要，但提供上下文的信噪比以及窗口长度也同样重要。
信息过少
在查询、提示或上下文窗口中提供的信息过少可能导致幻觉，因为 LLM 无法准确判断生成响应所需的正确语义上下文。文档分块大小的向量相似性也会出现问题 —— 一个简短、简单的问题可能与我们向量化知识库中丰富详细的文档语义不匹配。已经开发了诸如假设文档嵌入（Hypothetical Document Embeddings, HyDE）的查询扩展技术，使用 LLM 生成比短查询更丰富、更具表达力的假设答案。当然，这里的风险是，假设文档本身可能是一个幻觉，使 LLM 偏离正确上下文。
信息过多
就像对我们人类一样，上下文窗口中的信息过多会使 LLM 不知所措，难以判断哪些部分是重要的。上下文溢出（或 “上下文腐烂”）会影响生成式 AI 的质量和性能；它会大幅影响 LLM 的 “注意力预算”（工作记忆），并在多个竞争 token 之间稀释相关性。“上下文腐烂” 的概念还包括 LLM 的位置偏向 —— 它们倾向于优先关注上下文窗口开头或结尾的内容，而不是中间部分的内容。
分散注意或冲突信息
上下文窗口越大，包含多余或冲突信息的可能性就越高，这可能会干扰 LLM 选择和处理正确上下文。在某种程度上，这成为了 “垃圾进/垃圾出” 的问题：仅仅将一组文档结果丢入上下文窗口，会给 LLM 提供大量信息（可能太多），但根据上下文的选择方式，更有可能出现冲突或无关信息渗入。
Agentic AI
我说过我们有很多内容要讲，但我们做到了 —— 我们终于要讨论 agentic AI 了！Agentic AI 是 LLM 聊天界面的一种非常令人兴奋的新用途，它扩展了生成式 AI（可以说是 “传统人工智能” 吗？）根据自身知识和你提供的上下文信息生成回应的能力。随着生成式 AI 越来越成熟，我们意识到可以让 LLMs 执行一定程度的任务和自动化，最初是分配给一些繁琐、低风险的活动，这些活动可以轻松由人类检查/验证。在短时间内，这个初始范围扩大了：一个 LLM 聊天窗口现在可以成为触发 AI agent 自主规划、执行、迭代评估并调整计划以实现指定目标的火花。Agents 可以访问它们 LLM 的推理能力、聊天历史和思维记忆（就算有限），还可以使用特定工具来实现目标。我们现在还看到一些架构允许顶层 agent 作为多个子 agent 的协调者，每个子 agent 有自己的逻辑链、指令集、上下文和工具。
Agents 是一个高度自动化工作流程的入口：它们是自我导向的，可以与用户聊天，然后用“ 逻辑” 确定有哪些工具可用来帮助回答用户的问题。工具通常被认为是被动的，与 agent 相比只执行一种类型的任务。工具可以执行的任务类型几乎无限（这非常令人兴奋！），但主要任务是为 agent 收集上下文信息，以便其在执行工作流程时考虑。
作为一项技术，agentic AI 仍处于初期阶段，并容易出现 LLM 版本的注意力缺陷 —— 它容易忘记被要求做的事情，常常去做与任务无关的事情。在表面魔力之下，LLM 的 “推理” 能力仍然基于预测序列中最可能出现的下一个 token。要让推理（或未来的人工通用智能 AGI）变得可靠和值得信赖，我们需要能够验证：在提供正确、最新的信息时，它们会按照预期进行推理（并可能提供我们自己未想到的额外信息）。为此，agentic 架构需要能够清晰沟通（protocols）、遵守我们给定的工作流程和约束（guardrails）、记住任务进度（state）、管理可用内存空间，并验证其回应的准确性和任务符合性。
用我能理解的语言交流
正如新兴开发领域常见的情况（尤其是在 LLMs 世界中），最初 agent 与工具通信有很多方法，但很快收敛到 Model Context Protocol (MCP) 作为事实标准。Model Context Protocol 的定义就在名字里 —— 它是模型请求和接收上下文信息的协议。MCP 作为 LLM agents 连接外部工具和数据源的通用适配器；它简化并标准化了 API，使不同 LLM 框架和工具能够轻松互操作。这使得 MCP 成为协调逻辑和给 agent 的系统提示（以实现自主目标）与发送给工具的操作（至少就发起 agent 而言是隔离的）之间的枢纽。
这个生态系统非常新，每个扩展方向都像是一个新前沿。我们有类似的 agent 与 agent 交互协议（Agent2Agent, A2A），以及其他改进 agent 推理记忆的项目（ReasoningBank）、选择最适合任务的 MCP 服务器（RAG-MCP）、以及对输入输出使用语义分析如 zero-shot 分类和模式检测作为 guardrails 来控制 agent 可操作的范围。
你可能注意到，这些项目的核心意图都是为了提高返回给 agent/gen AI 上下文窗口的信息质量和可控性？随着 agentic AI 生态系统继续发展以更好地处理这些上下文信息（控制、管理和操作），获取最相关的上下文信息作为 agent 的原料始终是必要的。
欢迎来到上下文工程！
如果你熟悉生成式 AI 的术语，你可能听说过 “prompt engineering” —— 现在，它几乎成为一种准科学。Prompt engineering 用于寻找最优和最高效的方法，主动描述你希望 LLM 在生成回答时使用的行为。“Context engineering” 将 prompt engineering 技术扩展到 agent 端之外，还涵盖 MCP 协议工具端的可用上下文来源和系统，包括上下文管理、处理和生成的广泛主题：
- 上下文管理 - 与在长期运行和/或更复杂的 agentic 工作流程中维护状态和上下文效率相关。迭代规划、任务跟踪和工具调用编排，以实现 agent 的目标。由于 agent 的“注意力预算”有限，上下文管理主要关注帮助优化上下文窗口的技术，以捕获最全面的范围和最重要的上下文信息（精度 vs. 召回！）。技术包括压缩、摘要以及保留来自前一步或工具调用的上下文，为后续步骤提供额外上下文的工作内存空间。
- 上下文处理 - 将从不同来源获取的上下文整合、规范化或优化的逻辑步骤（希望大部分可程序化），以便 agent 可以以相对统一的方式在所有上下文上进行推理。核心工作是使所有来源的上下文（prompt、RAG、记忆等）都能被 agent 高效使用。
- 上下文生成 - 如果上下文处理是让检索到的上下文可被 agent 使用，那么上下文生成则是让 agent 能够按需请求和接收额外的上下文信息，同时带有约束条件。
LLM 聊天应用的各种短暂元素直接（有时也有重叠）映射到上下文工程的高级功能：
- 指令 / 系统提示（Instructions / system prompt） - Prompt 是生成式（或 agentic）AI 活动如何引导思维以实现用户目标的框架。Prompt 本身就是上下文；它不仅仅是语气指令 —— 通常还包括任务执行逻辑和规则，例如 “逐步思考” 或 “深呼吸” 以确保回答完全满足用户请求。最近的测试显示，标记语言在框定 prompt 的不同部分方面非常有效，但也需要注意将指令校准到既不太模糊也不太具体的平衡点；我们希望提供足够的指令让 LLM 找到正确上下文，但不要过于规定，以免错过意外见解。
- 短期记忆（状态/历史）（Short-term memory） - 短期记忆本质上是用户与 LLM 的聊天会话互动。这在实时会话中有助于优化上下文，并可以保存以便未来检索和继续使用。
- 长期记忆（Long-Term Memory） - 长期记忆应包括在多个会话中都有用的信息。不仅仅是通过 RAG 访问的特定领域知识库；最近的研究还利用之前 agentic/生成式 AI 请求的结果，在当前 agentic 交互中进行学习和引用。长期记忆领域最有趣的创新之一是调整状态的存储和关联方式，以便 agent 可以从上次中断的地方继续。
- 结构化输出（Structured output） - 认知需要努力，因此即使具备推理能力，LLM（像人类一样）也希望减少思考消耗。在缺乏定义 API 或协议的情况下，有一个用于读取工具调用返回数据的映射（schema）非常有帮助。将结构化输出纳入 agentic 框架，有助于使机器间交互更快、更可靠，减少思考驱动的解析需求。
- 可用工具 - 工具可以执行各种操作，从收集额外信息（如向企业数据仓库发起 RAG 查询，或通过在线 API）到代表 agent 执行自动化操作（如根据 agent 请求的条件预订酒店）。工具也可以是具有自己 agentic 处理链的子 agent。
- Retrieval Augmented Generation (RAG) - 我非常喜欢将 RAG 描述为 “动态知识整合”。如前所述，RAG 是提供 LLM 在训练时无法访问的额外信息的技术，或是重复强调我们认为对获取正确答案最重要的想法 —— 即最符合我们主观查询的答案。
惊人的宇宙力量，微小的生存空间！
Agentic AI 有许多迷人且令人兴奋的新领域等待探索！尽管仍有许多传统数据检索和处理问题需要解决，但也出现了全新的挑战，这些挑战只有在 LLM 新时代才被揭示。我们今天面临的许多直接问题都与上下文工程相关 —— 如何在不超载其有限工作内存的情况下，为 LLM 提供额外的上下文信息。
具有访问多种工具（以及其他 agent）能力的半自主 agent 的灵活性带来了许多新的 AI 实现思路，很难想象我们将如何组合这些部分。目前的大多数研究属于上下文工程领域，重点是构建能够处理和跟踪更多上下文的记忆管理结构 —— 因为我们真正希望 LLM 解决的深度思考问题复杂度更高，需要长时间、多阶段的思考步骤，其中记忆至关重要。
该领域的许多持续实验旨在寻找为 agentic 逻辑链提供最佳任务管理和工具配置的方法。agent 中每次工具调用都会产生累积成本，包括执行该工具功能的计算成本，以及对有限上下文窗口的影响。管理 LLM agent 上下文的一些最新技术引发了意外的连锁效应，如 “上下文崩溃”，即为长时间任务压缩/摘要累积上下文时损失过大。理想结果是工具返回简洁且准确的上下文，而不会有多余信息渗入宝贵的上下文窗口内存空间。
可能性太多/太多
我们希望职责分离，同时能够灵活重用工具/组件，因此为连接特定数据源创建专用 agentic 工具是完全合理的 —— 每个工具可以专门查询一种类型的存储库、一种数据流，甚至一种用例。但要小心：在追求节省时间/金钱/证明可行性时，很容易产生将 LLM 用作联合工具的强烈诱惑……尽量不要，我们以前走过这条路！联合查询就像 “通用翻译器”，将传入查询转换为远程存储库理解的语法，然后必须以某种方式将来自多个来源的结果合理化为连贯的响应。联合查询技术在小规模时效果尚可，但在大规模，尤其是数据多模态时，联合查询试图弥合的差距太大。
在 agentic 世界中，agent 会作为联合器，而工具（通过 MCP）是与不同资源的手动定义连接。使用专用工具跨未连接的数据源进行访问，看似是按查询动态整合不同数据流的新方法，但用工具向多个来源提出相同问题可能会引发比解决更多问题。每个数据源底层可能是不同类型的存储库，每个存储库都有自己的数据检索、排序和安全能力。这些存储库之间的差异或“阻抗不匹配”会增加处理负载，同时可能引入冲突信息或信号，哪怕是评分不对齐也可能极大影响返回上下文的重要性，并最终影响生成回答的相关性。
上下文切换对计算机也很难
当你派出 agent 执行任务时，它们的首要任务通常是找到所有可访问的相关数据。就像人类一样，如果 agent 连接的每个数据源都返回不一致和分散的响应，从检索内容中提取关键上下文信息会产生认知负荷（虽然性质不同）。这需要时间/计算，而每一点都会在 agentic 逻辑链中累积。因此得出结论：正如 MCP 所讨论的那样，大多数 agentic 工具应更像 API —— 具有已知输入输出的独立函数，针对不同类型 agent 的需求进行调优。实际上，我们甚至发现 LLM 需要上下文来理解上下文 —— 当任务是将自然语言转换为结构化语法时，拥有参考 schema 时，它们在连接语义点方面表现更好（确实是 RTFM！）。
第七局拉伸！
现在我们已经了解了 LLM 对数据检索和查询的影响，以及聊天窗口如何发展为 agentic AI 体验。让我们将这两个主题结合起来，看看如何利用新型搜索和检索能力改善上下文工程中的结果。前进到第三部分：上下文工程中混合搜索的力量！
第三部分：上下文工程中混合搜索的力量
我们已经讨论了混合搜索（第一部分）和上下文工程（第二部分），现在让我们深入了解它们如何协同工作，以在为 RAG 和 agentic AI 操作提供目标上下文时发挥最大效果。
搜索没有消失，它只是转移了位置
我们已经从主要通过文本框搜索上下文并自己使用返回的信息（上下文）构建答案，转变为现在使用自然语言告诉 agent 我们想要什么，并让它自动研究和整理答案。许多科技界人士指向这一转变并宣称 “搜索已死”（当然，SEO 和广告世界确实在变化：GEO 呢？），但搜索对 agentic 操作仍然至关重要 —— 只是现在大多通过工具在后台进行。
以前，人类是主观相关性的主要裁决者：每个用户进行搜索都有自己的原因，他们的个人经验会影响结果的相对准确性。如果我们希望相信 agent 可以得出与我们相同（或更好）的结论，就必须确保它们可以访问的上下文信息尽可能接近我们的主观意图。我们必须为 LLM 工程化提供上下文，以实现这一目标！
使用混合搜索生成上下文
回顾第一部分，Elastic 的混合搜索结合了传统基于关键字搜索的优势（语法灵活性、关键字精度和相关性评分）与向量相似性搜索的语义理解，并提供多种重新排序技术。这种协同（这个词的真正用法从未如此贴切！）允许获得高度相关的结果，查询在定位内容时可以更加细致入微。不仅可以将主观相关性应用于某个检索阶段；实际上，第一阶段检索可以同时包含相关性评分和所有其他模式。
卓越的准确性与效率
使用能够提供分布式搜索、检索和重新排序的数据平台作为主要上下文检索引擎非常合理。你可以使用高级查询语法添加缺失的主观意图组件，并过滤可能分散注意力或降低返回上下文信息价值的内容。你可以从任何可用的单独语法选项中选择，或将多种模式组合成单次搜索，以针对每种数据类型最擅长的方式检索，然后通过重新排序进行合并/重新排序。响应可以过滤为仅包含你想要的字段/值，避免多余数据干扰。对于 agent，这种定位灵活性让你能够构建在检索上下文时极其准确的工具。
上下文优化（聚合和非内容信号）
聚合在塑造工具提供给上下文窗口的内容方面特别有用。聚合自然提供关于返回上下文数据形态的基于数值的事实，使 LLM 推理更容易、更准确。由于聚合可以分层嵌套，这是为 LLM 提供多层次细节以生成更细致理解的简便方法。聚合还可以帮助管理上下文窗口大小 —— 你可以轻松将 10 万条文档的查询结果压缩为几百个 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 的结果合并）。下面是一个用于虚构产品搜索的简单示例：
`
1. FROM products
2. | FORK
3. (MATCH description "high performance gaming laptop" | EVAL search_type = "bm25"),
4. (MATCH description_semantic "high performance gaming laptop" | EVAL search_type = "semantic")
5. | FUSE
6. | LIMIT 20
7. | KEEP product_name, description, _score, search_type
`AI写代码
在上面示例中，每个 FORK 分支中包含的 EVAL 子句并非严格必要；它仅用于演示如何跟踪某个结果是从哪种搜索方式返回的。
搜索模板
假设你想将自己的外部 agentic 工具指向 Elastic 部署。并且你不想使用 ES|QL，而是想使用多阶段检索器或重用已经开发的 DSL 语法，同时希望能够控制查询接受的输入、执行搜索所用的语法以及输出中返回的字段。搜索模板允许用户为常见搜索模式定义预设结构，提高数据检索的效率和一致性。这对于与搜索 API 交互的 agentic 工具尤其有益，因为它们有助于标准化模板代码，并加快搜索逻辑的迭代。如果需要调整这些因素，只需更新搜索模板，修改即可生效。如果你想看搜索模板在 agentic 工具中的实际应用，可以参考 Elasticsearch Labs 博客《MCP for intelligent search》，该博客展示了从外部 MCP 服务器调用工具时使用的搜索模板。
集成工作流（FTW！）
在新的 agentic AI 世界中，最难应对的之一是半自主、自我驱动 “推理” 代理的非确定性特性。上下文工程对 agentic AI 至关重要：它们帮助将代理可能生成的结论缩小到我们已知的客观真相范围内。即使上下文窗口高度准确且相关（当超出数值事实范围时），我们仍然缺少对代理响应完全可重复、可靠的保证。
当你对代理多次运行相同请求时，答案可能基本相同，只是响应中有一点微小差异。对于简单查询通常无碍，也许几乎察觉不到，我们可以尝试通过上下文工程技术调整输出。但随着我们要求代理完成的任务变得更复杂，一个或多个子任务可能引入差异，稍微改变最终结果。随着代理间通信的依赖增加，这些差异可能会累积。这再次表明，代理交互的工具需要非常灵活且可调，以精确定位上下文数据，并应以预期的输出格式响应。同时，这也显示了许多用例中我们需要指导代理和工具的交互——这就是工作流的用武之地！
Elastic 很快将在平台核心中内置完全可自定义的工作流。这些工作流能够与代理和工具进行双向操作，因此工作流可以调用代理和工具，而代理和工具也可以调用工作流。在所有数据都驻留的同一搜索 AI 平台上完全集成这些能力，将具有变革性意义，工作流的潜力非常令人兴奋！很快，很快就会到来！
Elastic 作为统一记忆库
作为一个为近实时搜索而设计的分布式数据平台，Elastic 天然地承担了 agentic AI 系统的长期记忆功能。借助内置的 Agent Builder 聊天体验，我们还可以跟踪和管理短期记忆与聊天历史。而且由于整个平台以 API 为先，非常容易将 Elastic 用作持久化工具上下文输出的平台（并可在以后引用），这可以避免超出代理的上下文窗口；在上下文工程领域，这种技术有时被称为 “笔记记录”。
在同一搜索平台上同时拥有短期和长期记忆带来了很多内在优势：想象一下可以将聊天历史和持久化的上下文响应作为未来聊天交互的语义影响因素，或者执行威胁分析，或者创建基于频繁工具调用自动生成的持久化数据产品……可能性无穷无尽！
结论
大型语言模型的出现改变了我们匹配内容的方式以及查询数据的方法。我们正在迅速从当前的世界转变，在那个世界中，人类进行研究、上下文考量和逻辑推理以回答自己的问题；而现在，这些步骤在很大程度上通过 agentic AI 自动化完成。为了让我们信任生成的答案，我们需要确保代理在生成响应时已考虑所有最相关的信息（包括主观相关性因素）。使 agentic AI 可信的主要方法是通过 RAG 和上下文工程技术来为检索额外上下文的工具提供支撑，但这些工具执行初始检索的方式可能对响应的准确性至关重要。
Elastic Search AI 平台提供了混合搜索的灵活性和优势，以及多种内置功能，有助于 agentic AI 在准确性、性能和可扩展性方面的提升；换句话说，Elastic 是上下文工程多个方面的出色平台！通过搜索平台标准化上下文检索，我们在多个方面简化了 agentic 工具的操作 —— 类似于 “慢下来以走得更快” 的悖论，在上下文生成层面的简化意味着更快、更可信的 agentic AI。
