Elastic AI 架构师的混合搜索工作坊导览

本次由 Elastic 的 AI 架构师 Jeff Vestal 和专注于搜索解决方案的架构师 James Williams 主导，旨在通过动手实验深入探讨检索增强生成（RAG）背后的搜索技术。Jeff 指出，虽然 RAG 概念在过去几年中热度极高，但随着智能代理（Agents）能力的提升，它们逐渐接管了数据检索与分析的管理工作。然而，无论模型多么智能，如果输入垃圾数据并自信地告知这是答案，模型往往会盲目相信。因此，构建一个能够准确提供信息的检索层至关重要。本次工作坊的核心在于打破单一搜索模式的局限，重点讲解向量语义搜索的优势与短板，以及传统关键词搜索（BM25）的持续价值。

"The trick or the catch... is if you feed these models, no matter how smart they are, garbage data and you confidently tell them this is the answer... pretty much they're going to believe you."

工作坊采用“理论+实践”的模式，参与者将通过 Elastic 提供的服务器实例环境进行操作。内容涵盖向量搜索、BM25 关键词搜索以及将两者结合的混合搜索（Hybrid Search）技术。此外，还将演示如何使用 Elastic 的代理构建平台展示错误检索导致的后果，并在最后介绍重排序器（Rerankers）的高级应用。整个流程分为四个主要章节加一个_bonus_ 挑战，每个部分包含 Dev Tools API 操作和 Python Notebook 深度分析两个环节。

RAG 的演变与检索层的关键角色

尽管“RAG”一词在会议和讨论中被频繁提及甚至令人厌倦，但 Jeff 强调检索增强生成并没有消失，只是退居幕后。随着代理（Agents）变得更加智能和有效，它们开始自行管理数据检索和分析任务。然而，这并不意味着对高质量检索层的需求降低。模型需要获取时间敏感、专有信息或价格数据等未训练过的内容，而 Elastic Search 正是作为这一关键的检索层发挥作用。

James Williams 补充道，本次工作坊将深入探讨为什么向量搜索重要且有用，同时也明确指出其失效的场景。随后引入沿用数十年的关键词搜索（BM25），分析其在当今环境下的相关性与实用性，以及其局限性。最终目标是将两者结合，实现混合搜索（Hybrid Search），以获取两者的最佳效果。参与者将学习如何使用开箱即用的组合方式（如 RRFR）以及更高级的线性组合方法来调整平衡权重。

工作坊实操环境与学习建议

为了获得最佳学习效果，参与者需访问指定的短链接启动 Elastic Instruct 环境。Jeff 提到，由于预估人数为 75 人但实际到场略少，启动速度会有所差异。每个环境都会自动启动一个服务器实例，并加载小型数据集供实验使用。工作坊的结构设计为每个章节包含两部分：首先在 Dev Tools 控制台中运行 API 命令进行快速测试，然后切换到 Python Notebook 标签页进行深入分析。

"If you just blindly hit run all in the notebook and fire through, you'll be done 10 minutes. But if you actually spend through it... it's going to probably take longer than this workshop session."

Jeff 强烈建议参与者不要盲目点击“运行全部”，而是仔细阅读 Jupyter Notebook 中的文档。这些文档解释了文档排序的原因、调整方法以及调优的重要性。代码仓库已公开，参与者可以在实验后或任何时间在其他环境中运行这些 Notebook。如果在操作过程中遇到困难，可以举手示意，Jeff 和 James 将作为“跑步者”协助排查 trivial（琐碎）问题并提供详细解释。这种互动式学习旨在确保参与者真正理解混合搜索背后的逻辑，而不仅仅是完成代码执行。

Elastic 的推理服务与 GINA 模型技术背景

Elastic Search Serverless 内部集成了名为 Elastic Inference Service 的推理服务，该服务直接驱动了当前研讨会中使用的模型。Elastic 通过收购获得了 GINA 模型，并由此开启了自主模型开发的阶段。目前的技术重点主要集中在 密集向量模型（dense vector models） 和重排序模型上。这代表了 Elastic 在过去一年中引入的新兴技术，旨在为开发者提供最新的搜索能力洞察。这种内置的推理服务使得从数据摄入到实时查询向量生成的全过程都能在 Elastic 内部自动完成，无需外部依赖。

Semantic Text 字段与默认分块机制

在 Elastic Search 中，处理文本检索的核心工具是 Semantic Text 字段。这是一种自动化的“快速通道”方案，默认情况下会在句子边界进行分块，并将文本拆分为 250 个 token 的片段。虽然默认设置是句子边界，但用户可以根据需求配置为单词、段落或页面边界进行切分。当向系统输入如五页长的文本时，Elastic 会自动将其切割成 250 token 的块，并保留一个句子的重叠部分以维持上下文连贯性。这种机制旨在简化数据预处理流程，让用户无需手动编写复杂的分块逻辑即可实现语义检索。

高级分块策略：Late Chunking 与混合搜索理念

尽管存在基于大上下文窗口的“语义分块”概念，Elastic 认为传统的 Late Chunking（晚期分块）技术已能胜任。GINA 模型支持这种处理大上下文窗口的方法，虽然目前尚未通过 Elastic Inference Service 直接暴露该功能，但它被视为最接近语义分块的方案。然而，Elastic 的核心观点是：我们不需要复杂的语义分块构造。通过传统的分块结合 混合搜索（Hybrid Search），即传统词汇搜索与密集向量语义检索的结合，即可达到相同甚至更好的效果。混合搜索是 Elastic 的核心论点之一，即将 BM25（传统词汇）与向量语义检索结合，并可选地添加重排序器以提升精度。这种方案的优势在于通过 单一 API 调用 即可完成所有工作，包括推理、分块和搜索，极大降低了大规模应用中的延迟和优化复杂度。

实验室资源与自定义向量支持

本次研讨会的实验环境在讲师的仓库中提供，有效期为一周。参与者可以通过右上角的 URL 访问实验室内容，并通过右下角的链接获取所有 Python Notebook 源代码。实验分为两部分：第一部分使用 Dev Tools（左侧输入 API，右侧查看输出）进行映射设置；第二部分进入 Python 环境自动连接 Elastic Search。对于希望自定义流程的高级用户，Elastic 支持通过标准 SDK（如 Python、Java、.NET Core）导入 自有向量，用户可以在 Elastic 中自行处理分块和向量化。虽然这需要开发者承担更多工作，但提供了更高的灵活性。

"We handle all the inference that happens from ingest chunking to real-time search where the query gets translated into a query vector and we do all the work for you under the hood."

"The only thing that we add to that well obviously that's of value is the option of adding rerankers on top of but yes that is a core thesis we're firm believers in that approach."

"We do have a technique that we use called late chunking that can work on large context windows... That's the closest thing that I would say we would have to semantic chunking."

向量嵌入的标准化与查询一致性

在 Elastic 中，虽然默认提供 Gina 模型作为开箱即用的解决方案，但用户完全可以接入自己的推理服务以支持语义搜索。这种设计的核心优势在于将嵌入配置直接绑定在字段 ID 中，从而解决了早期版本中需要手动追踪推理 ID、模型名称以及确保开发者使用一致模型的复杂性。通过将嵌入逻辑内嵌于字段定义，索引设置者只需配置一次，后续无论是数据摄入还是查询操作，系统都会自动调用相同的嵌入模型。这避免了因模型不匹配导致的语义偏差，正如演讲者所比喻的：“就像我试图说葡萄牙语一样，如果不匹配结果会很糟糕”。这种机制简化了多用户共享同一索引时的管理负担，使得语义搜索的部署更加标准化和易用。

混合检索弥补纯向量搜索局限

在查询阶段，文本经过分块处理后发送至推理服务生成嵌入向量，随后 Elastic 利用 HNSW（分层导航小世界）图算法进行最近邻搜索。HNSW 允许快速遍历以找到与查询语义最相关的文档片段，返回 Top K（如前 5 或前 10）结果。然而，纯语义搜索并非万能。当遇到高度特定的关键词（如产品 ID 或无意义的专有名词）时，语义搜索往往失效，因为这些信息不需要也不适合通过向量相似度来匹配。因此，第二阶段的实验引入了 BM25、词法搜索和传统关键词过滤等混合检索方法。这种组合策略能够弥补纯向量搜索在精确匹配上的不足，确保用户即使使用不同的措辞（如询问 TLS 安全设置的不同方式），也能获得一致且准确的文档结果。

HNSW 性能优化与内存管理演进

为了提升向量搜索的效率，Elastic 在过去两年多里引入了多项底层优化技术。首先是 INT8 量化，默认情况下系统会将 Float32 向量量化后存储在内存中，同时保留完整精度以维持高召回率。随后推出的 BBQ 技术进一步压缩了 HNSW 图向量，将其精度降低至比特级别，同时通过底层复杂算法保持高检索准确率。最新的 Disk BBQ 技术则几乎消除了向量搜索的内存开销，允许将数据存储在磁盘上。此外，Elastic 还推出了专有的 DisB（基于倒排索引的图搜索），这是一种其他厂商未实现的独特技术。尽管存在专门的图数据库，但对于大多数场景而言，结合量化技术的向量搜索已能高效处理大规模文档查询，特别是在 Agent 应用中支持多轮次、高并发的查询需求。

分页机制与摘要生成的工程实践

在结果展示方面，Elastic 提供了基于 Point in Time (PIT) 的分页机制。当用户需要获取大量结果（如每页 10 条，共 100 条）时，PIT 允许系统记录搜索检查点，避免重复计算或重新运行之前的搜索结果段。用户通过接收到的密钥继续下一页查询，从而保证分页的高效性和一致性。关于结果字段的设计，演讲者指出演示中的摘要字段是由 LLM 生成的，旨在避免输出过长的正文导致界面杂乱。在实际工程中，用户可以通过 Ingest Pipeline 在数据摄入阶段调用推理服务自动生成摘要或提取潜在查询词。虽然演示中主要搜索标题字段，但在后续涉及 LLM 完成的实验中，这种在 Ingest Pipeline 中集成推理调用的模式将被广泛使用。

图数据库与大规模向量数据的扩展性权衡

在讨论如何处理文档标签关联等复杂关系时，虽然过滤和其他搜索方法论能提供帮助，但图数据库（如Neo4j）在超大规模数据上的扩展性仍存疑。演讲者指出，尽管图数据库历史悠久且常被提及（如去年的Graph RAG主题），但在处理数十亿级向量数据集时，引入图结构可能会成为扩展性的瓶颈。因此，Elastic选择谨慎避免引入此类限制规模的构造。

"I don't know of any that scale really well... we're very careful not to introduce a construct that keeps us from being able to scale at that level."

目前，Elastic尚未发现必须采用图数据库的硬性需求。虽然这一话题在行业会议中热度很高，但尚未有技术能在Elastic所运营的大规模尺度上完美解决该问题。即便Neo4j等厂商声称已攻克此难题，其实际表现是否匹配Elastic的规模要求仍待验证。这种对扩展性的极致追求，使得他们在架构设计上倾向于更轻量、更易水平扩展的方案。

机器学习模型在检索中的实时应用策略

除了图遍历，利用即时分类模型（On-the-fly Classification）是解决复杂检索挑战的另一种常见路径。Elastic支持在专门的ML节点上运行用户上传的分类模型，或连接外部推理服务。此外，命名实体识别（NER）因其模型体积小、速度快，非常适合在查询时实时运行。通过提取人名、地点或产品名等实体，代理（Agents）可以直接生成更精准的查询语句，而无需编写复杂的Painless脚本。

"NE models are very fast because they're really small models... the agent can take those and then create a query that's more tuned for that."

尽管Elastic近期将重心转向了密集向量嵌入（Dense Vector Embeddings）和重排序器（Rerankers）的处理极限，但内部的ML能力依然强大且可用。演讲者提到，未来可能会在这些领域引入更多 sophistication（复杂性/高级功能），但目前的重点在于优化现有模型对非结构化数据的处理能力。这意味着企业可以在不依赖外部复杂图架构的情况下，通过内置的ML能力实现精细化的检索增强。

混合搜索架构选型：从BM25到重排序的渐进路径

对于大多数小型文档库，首选策略是结合BM25（关键词搜索）与语义搜索。演讲者强调了一个核心原则：如果这种组合能满足召回率或精确度目标，就应停止增加复杂度，因为任何额外组件都会带来延迟惩罚。只有在基础组合无法满足需求时，才考虑引入重排序模型（Re-ranking Model）。

"My rule of thumb is always see what you can accomplish with a combination of BM25 and semantic search... Anytime you add anything on top of that, you're going to be taking an additional latency hit."

推荐的“快乐路径”是：首先部署密集向量，因为语义搜索能有效减少传统词汇搜索中需要手动调整同义词或进行高级词法调优的需求。虽然也有观点建议先只用BM25，再加语义搜索作为补充，但演讲者更倾向于从一开始就集成向量技术。这种渐进式的方法确保了系统在保持低延迟的同时，能够逐步提升检索质量，避免过度工程化。

"I'm a big fan of dense vectors so I would just go ahead and wire them into the architecture right out of the gate."

关于检索器中的具体参数配置（如RRF的秩常数），虽然存在可配置的旋钮，但默认设置通常已足够应对大多数场景。具体的决策树和参数调整细节可在后续的工作坊（如Workshop 4或5）中通过实验环境进一步探索，建议用户在实际环境中测试不同配置对性能的影响。

传统词汇搜索的局限性与性能优势

尽管语义搜索已成为主流，但传统的词汇搜索（Lexical Search）在特定场景下仍具有不可替代的价值。Jeff Vestal 指出，在进行非常具体的关键词或短语匹配时，词汇搜索依然有效；然而，一旦用户查询超出精确匹配的范畴，其相关性就会迅速下降。从性能角度来看，词汇搜索通常具有更低的延迟。这是因为它不需要进行机器学习推理（ML Inference），而语义搜索必须调用外部或内部的推理端点。James Williams 强调，任何引入密集向量语义搜索的操作都会增加对推理端点的调用，这往往成为整个系统的瓶颈。因此，即使量化等技术正在改变速度对比的现状，默认情况下词汇搜索的速度优势依然存在。

"Lexical search usually does have lower latency profiles in almost all use cases and that's because there is no ML inference happening."

混合搜索架构的设计哲学与中间件回归

在构建基于 AI 的检索系统时，开发者面临巨大的架构选择。Elastic 的观点是一切始于传统搜索，随后在其上叠加语义能力，最后根据需要引入重排序（Re-ranking）。这种分层方法反映了 Elastic 的技术遗产。James Williams 观察到，随着 AI 浪潮的兴起，曾经被边缘化的中间件（Middleware）概念正在回归。过去开发者可能将数据库视为可插拔的黑盒，但在 AI 时代，一旦开始编写代码以进行检索，开发者就被锁定在所选的技术栈中。这种锁定效应在系统扩展时尤为明显。数据平台正在将推理能力内置，以解决端到端测试中的延迟问题。如果向量数据库返回速度很快但推理缓慢，整体搜索体验依然糟糕。

"Our take is that everything starts with traditional search... and then you add semantic capabilities on top of that."

大规模场景下的竞争壁垒与调优挑战

Elastic 的核心优势体现在数据量巨大且服务等级协议（SLA）要求极其严格的场景中。在这些情况下，其他平台无法提供的可调整性（Tunability），特别是在相关性调优方面，成为了关键竞争力。然而，关于如何根据数据形状或用户查询模式来构建权重，目前并没有权威的“标准答案”。James Williams 坦言，当前的相关性调优缺乏开箱即用的自动化方案。虽然可以通过智能搜索层（Intelligent Search Layer）让 LLM 分析查询并应用不同过滤器，但这与基于遥测数据的动态权重调整仍有区别。这种技术目前主要通过 Elastic 的 Agent Builder 实现，而非简单的参数微调。

"We've got a level of tunability especially on the relevance side that can't be accomplished with other data platforms."

自动相关性调优的未来愿景

尽管尚未发布，但自动调整的相关性（Autotuned Relevance）是 Elastic 未来发展的重点方向。理想的系统应能收集用户行为遥测数据，如点击流、点赞/点踩反馈以及业务指标。基于这些数据，系统可以自动调整线性权重（Linear Weights），或在特定查询类型下在 TF-IDF 与向量之间切换。Sunil 最初构建的“智能搜索层”架构展示了通过 LLM interrogation（询问）查询来执行不同过滤器搜索的技术潜力。James Williams 希望未来用户只需指定属性或设置，即可根据实际使用情况开启并调整自动调优功能。目前这仍处于规划阶段，但代表了从手动配置向基于用户体验数据的自适应搜索系统演进的趋势。

"In a perfect world, you would actually be able to take the searches that are coming through the system... and then also any other business metrics... to actually tune the relevance."

混合搜索的核心难题：量纲不一致

在构建现代搜索引擎时，开发者面临的最大挑战之一是如何将基于关键词的BM25算法与向量语义搜索有效结合。这两者在底层评分机制上存在本质差异：BM25的得分范围是不固定的，它根据文档的相关性给出从0到任意值的评分；而向量搜索通常将结果归一化在0到1之间。这种量纲的不一致导致了一个直观但错误的问题：一个在纯数值上表现较差的关键词搜索结果，往往会在排序中击败语义匹配度极高的向量结果。因此，简单的数值相加或比较是行不通的。

"BM25 has a scale it scores documents from zero to kind of whatever whereas vector search normally it's zero to one... a poor result in a lexical BM25 search is almost always going to beat out from a pure number perspective a good semantic search."

为了解决这一矛盾，Elastic提供了多种融合策略。其中一种基础且开箱即用的方法是Reciprocal Rank Fusion (RRF，倒数排名融合)。这种方法不直接处理原始分数，而是关注文档在各自搜索结果列表中的相对排名位置。其核心逻辑是：如果一个文档同时在关键词搜索和向量搜索中排名靠前，那么它被判定为相关匹配的概率就极高。RRF的优势在于其简单性，开发者无需深入了解数据分布或进行复杂的参数调优即可使用。

RRF机制与过滤器的协同作用

RRF算法通过计算排名的倒数之和来生成最终得分，其公式中包含一个常数（通常为60），用于防止排名极高的文档获得过大的权重。在实现上，系统并行运行两种搜索策略，提取各自的排名顺序，然后应用RRF公式进行重排序。这种方法在处理未知数据分布或混合查询类型时表现稳健，但它并非万能。

为了提升RRF的效果，引入预过滤（Filtering）是关键步骤。通过关键词、地理位置或日期等结构化条件缩小候选集，可以显著减少搜索范围。例如，在寻找晚餐时，先过滤出“披萨”类别，再在该子集中进行语义搜索，比在全量数据中盲目搜索效率更高。Elastic擅长快速执行此类过滤操作，从而为混合搜索提供更精准的候选池。

"Filtering is a really powerful and effective way to help along... if you can filter your data by keyword, geoloccation, date, anything that gets that data set down to a smaller candidate pool, you're going to have better results usually."

然而，当过滤条件不足或数据分布复杂时，RRF可能无法达到最佳效果。此时需要转向更精细的线性组合（Linear Combination）方法。该方法要求对BM25和向量得分进行归一化处理，使两者都映射到相同的0-1区间内。随后，通过调整权重系数（Weights）将两者加权求和。这需要开发者根据具体业务场景进行调优，例如通过人工标注或LLM辅助生成“判断集（Judgment Sets）”，以实验方式确定最优权重组合。

智能路由与搜索模板的高级应用

在更复杂的架构中，单一策略往往无法满足所有查询需求。Elastic支持搜索模板（Search Templates）概念，允许开发者定义多种不同的检索策略组合。例如，可以预设一个仅使用RRF的模板、一个使用线性加权的模板，以及一个结合了重排序器（Reranker）的高级模板。通过在上层构建智能查询层，可以利用LLM或规则引擎分析用户意图。

"You could technically have three different search strategies... if you have a layer on top, let's call it an LLM that's got a simple prompt... you can literally have the equivalent of what I'll call poor man's autotuning."

这种架构实现了基于查询类型的动态路由。当用户输入特定类型的问题时，系统自动选择最合适的搜索模板执行。虽然这被称为“穷人的自动化调优”，但它极大地简化了高级用例的开发复杂度，避免了为每种场景编写大量样板代码。对于大多数开发者而言，如果无法用单一策略覆盖所有查询，这种分层路由架构是必然选择。尽管在基础实验课程中未深入涉及，但理解搜索模板的存在及其在混合搜索架构中的核心地位至关重要。

实践建议与总结

在实际应用中，并非所有场景都必须使用混合搜索。有时纯向量语义搜索或纯关键词BM25已足够满足需求。但在大多数复杂检索场景中，结合语义与词汇搜索能显著提升召回率和准确率。对于初学者或数据背景不明的情况，建议从RRF开始尝试，因为它易于实现且效果良好。随着对数据理解的加深和性能需求的提高，再逐步引入归一化线性组合或智能路由机制。Elastic的灵活性允许开发者根据业务成熟度逐步演进搜索架构，从简单的并行排名融合走向复杂的自适应混合检索系统。

LLM 的知识局限与检索的核心价值

尽管大型语言模型（LLM）在生成回答方面非常有效，但它们并非全知全能。演讲者指出，LLM 的核心弱点在于处理其训练数据之外的信息。当用户向模型提供与其预训练知识相悖的数据（例如告知“天空是橙色的”）时，模型往往会自信地给出错误答案。这种幻觉现象表明，单纯依赖 LLM 进行事实性问答存在巨大风险。因此，在构建智能代理（Agentic）应用时，检索机制依然至关重要。通过 RAG（检索增强生成），系统可以将最新、最准确的外部数据喂给模型，从而弥补其知识盲区。这一环节（Lab 4）旨在展示如何在将数据输入模型的同时，利用检索技术确保答案的准确性，避免模型因缺乏特定上下文而产生误导。

Elastic Agent Builder 的功能扩展与自动化能力

Elastic 的 Agentic Platform（智能代理平台）不仅限于检索，还具备执行复杂任务的能力。该平台允许用户连接多种 LLM（包括 Elastic Infrastructure Service 提供的模型或自定义模型），并直接调用工具、技能以及外部 API。演讲者特别提到了 Workflows（工作流） 的概念，即当需要按顺序完成一组任务或进行决策时，代理可以调用这些预设的工作流。例如，在可观测性场景中，如果系统检测到资源不足，代理可以自动触发工作流来 扩展 Kubernetes 环境。此外，平台支持调用 MCP（Model Context Protocol）工具和其他系统接口。虽然这些高级功能超出了当前工作坊的范围，但它们展示了代理从“被动回答”向“主动执行”的转变潜力。

编程灵活性：API 优先与无锁定设计

对于软件开发者而言，Elastic Agent Builder 的一个关键优势在于其 高度的可编程性和灵活性。在 Cabana UI（Elastic 的用户界面）中配置的所有代理逻辑，都可以通过 API 进行编程访问。这意味着开发者无需为了构建生产级应用而重写代码；他们可以复用相同的端点，在自定义的用户体验中调用代理功能。演讲者强调：“我们提供尽可能现成的体验，但绝不锁定用户”（We're very flexible, almost to a fault）。如果开发者希望将代理组件与其他框架或自建 API 集成，平台也完全兼容。这种设计允许用户根据需求自由组合技术栈，答案往往取决于具体场景（“it depends”），体现了平台对多样化开发需求的包容性。

引用来源：解决 LLM 幻觉的关键机制

随着代理运行速度加快，引用信息来源（Citing Sources） 变得愈发重要。LLM 擅长生成看似合理但可能完全虚构的回答，这种现象在法律等领域尤为危险——律师曾因引用不存在的案例而陷入麻烦。演讲者指出，大多数模型本身不具备数据库式的查表功能，而是基于训练数据生成令牌。然而，通过 RAG 架构，系统可以将实际答案提供给 LLM，并指示其 解析数据并以人类友好的格式输出时附带来源引用。这一机制极大地提升了回答的可信度，特别是在处理复杂数据或需要审计追踪的场景中。工作坊提供了预构建的环境和笔记本代码（通过短链接 ELD 1 访问），用户可连接任意 ElasticSearch 集群进行实践，这些资源将保留一周以供学习。

额外资源与社区支持

为了帮助用户更深入地理解 Elastic 的内部工作原理，演讲者介绍了额外的在线工作坊资源。这些资源由架构师 Sunnil 等人提供，采用与现场类似的交互式环境（Instruct environment），让用户能够亲手操作并学习概念。演讲者幽默地表示，完成这些工作坊不仅能免费获得培训，还可能 显著提升个人的市场价值（“increase your market value by I don't know $100,200 a year”）。这些补充材料旨在帮助用户掌握 Elastic 的核心技术，从基础检索到高级代理构建，形成完整的学习闭环。

“Anytime you have to feed them data that's outside their training knowledge... you can pretty confidently get them to give you the wrong answer.”

“Everything that you see in a Cabana user interface in Agent Builder is programmable via API.”

“One of the things that's extremely important in things like legal... if you can have the model process large amounts of data complex data but still cite its answer, it makes them trustworthy.”

Agent Builder 的平台架构与核心概念

Elastic 的 Agent Builder 平台采用全 API 驱动的设计，这种架构使得用户能够以编程方式构建、销毁和扩展技能（Skills）、工具（Tools）以及智能体（Agents）。这种可编程性不仅保留了底层堆栈的所有能力，还赋予了系统极高的灵活性和可扩展性。在平台中，“技能”被定义为指导模型或智能体以特定方式执行任务的指令集合，它涵盖了何时使用工具、如何创建演示文稿或服务等各种逻辑。> “技能本质上是在告诉模型或智能体如何以某种特定方式执行任务。” 与技能不同，“工具”则侧重于实际的动作执行。平台内置了如运行搜索、列出工作流等现成工具，同时也支持用户创建自定义工具。这种区分使得智能体既能获得高层级的逻辑指导，又能通过具体的工具执行确定性操作。

技能与工具的协同工作机制

在演示案例中，一个用于诊断问题的智能体包含了一个简短的技能描述和一个搜索工具。该技能明确指示智能体如何查找错误代码、定位问题根源并提供修复方案，从而避免了让模型完全依靠自身推理可能带来的低效或错误。> “你可以提供尽可能多的信息来帮助它，比如查找子句、寻找修复方法以及查看错误代码。” 除了内置工具，用户还可以创建自定义工具。例如，通过引入 ESQL（Elastic SQL）作为查询文档的工具，智能体可以直接在 Elastic 中执行类 SQL 语法的管道命令。这种机制允许将复杂的查询逻辑封装为工具，使智能体能够以结构化方式获取数据。此外，“索引搜索”作为一种特殊的文档类工具，向智能体提供特定索引的用途、字段映射及组合逻辑（如产品索引与定价库存索引的关系），从而指导智能体更准确地构建查询。

ESQL 在检索与调试中的应用价值

ESQL 是 Elastic 推出的新型查询语言，采用类 SQL 语法并通过管道（Pipe）连接命令。在智能体架构中，ESQL 工具允许直接查询 Elastic 中的文档，而“索引搜索”工具则帮助智能体理解集群结构。> “如果你只问一个问题且它一无所知，它会先查找所有索引及其映射。” 智能体通常通过多轮循环来探索数据：首先尝试猜测相关字段，然后组合查询。然而，这种盲目探索会消耗大量 Token 并增加延迟。“索引搜索”工具通过预先提供元数据，显著加速了这一过程。此外，ESQL 对于开发者而言也是一个强大的调试工具，特别是在原型设计阶段，它有助于快速验证哪些搜索逻辑能有效检索所需数据。尽管初期对 ESQL 的功能完整性有所保留，但演讲者认为其已足够成熟，尤其适合构建生成式搜索用例。

多轮循环诊断案例：OOMKiller 故障排查

演示展示了一个智能体处理复杂两阶段问题的完整流程。用户提问：“为什么集群会因 137 退出代码死亡？以及如何更改设置以防止这种情况？”智能体首先加载技能，理解问题包含“原因分析”和“解决方案”两部分。随后进入多轮循环：首先通过搜索工具诊断出 137 退出代码是由操作系统的 OOMKiller（内存不足杀手）终止进程所致。接着，智能体利用 ESQL 工具查询 Elastic 内部配置或文档，找到关于 JVM 选项调优的建议。> “因为它的答案在 Elastic 内部，并且能够查询并运行多个工具。”最终，智能体综合诊断结果与配置建议，向用户解释了 OOMKiller 的触发机制，并提供了具体的 JVM 参数调整方案以预防问题复发。这一案例充分体现了智能体结合技能指导、工具执行和多轮数据探索的能力，实现了从问题诊断到解决方案生成的自动化闭环。

ESQL：超越传统查询语言的智能搜索网关

ESQL（Elastic SQL）被定位为比现有 Elastic 查询语言更强大的工具，它不仅是后者的超集，更是实现高级智能搜索用例的“快乐路径”。其核心优势在于能够将参数化机制直接集成到 MCP（Model Context Protocol）工具调用链中，并与 Agent Builder 无缝对接。这种架构设计使得开发者能够轻松构建复杂的代理搜索应用。对于尚未探索 ESQL 的用户，官方强烈建议从文档入手，重点关注其中关于联邦搜索（Federated Search）的创新。目前开发中的功能允许通过 SQL 调用外部系统，例如对 Elastic 外部的 Parquet 文件进行查询，并将其与 Elastic 内部数据连接。这种能力使得 ESQL 成为通往未来检索机制的关键网关，能够处理非传统 Elastic 查询的复杂场景。

管道化架构与 Splunk 体验的重塑

ESQL 的设计哲学深受 Splunk 查询语言黄金时代的影响，同时融合了经过时间考验的 SQL 概念。其独特的管道（Pipe）结构允许查询分阶段执行，每完成一个阶段即返回中间结果并进入下一环节，这种机制极大地提升了查询的灵活性和可参数化程度。正如演讲者所言：">> parameterizable and it's it is trying to accomplish all the things that the Splunk query language tried to you know to do with Splunk in its heyday. uh and then um and then also marry that with SQL concepts which are obviously tried and true"。最初构建 ESQL 的主要目的是打造最佳搜索体验，帮助用户摆脱对 Splunk的依赖。如今，这一构造因其通用性已扩展至 Elastic 的所有支柱领域——搜索、安全和可观测性，成为这些模块中第一类公民（First-class citizen）的创新核心机制。这种管道化结构还减少了获取正确检索结果所需的标记（markup），使查询更加简洁高效。

混合搜索的可追溯性与深度探索能力

在演示中，ESQL 展示了其在处理混合搜索查询时的透明度和可追溯性。当系统返回答案时，不仅会在底部提供引用来源（Citations），用户还可以点击这些链接深入查看原始文档。例如，在搜索 JVM 设置相关问题时，系统不仅返回了5个结果（limiting five and it does five），还清晰地展示了审计轨迹。用户可以通过点击链接跳转到 Discover 界面（类似 Kibana/Cabana的文档发现接口），在那里可以运行 ESQL 查询并查看完整的原始文档内容。这种机制避免了仅仅依靠猜测来提供更多信息，而是通过将 URL 作为文档的一部分嵌入，直接链接到更详细的信息源。此外，Discover界面还能根据查询结果自动生成图表（尽管演讲者调侃其帮助性有限），让用户能够直观地浏览文档主体和特定字段，如 URL 或日志内容。

重排序（Reranking）：提升精度的第二阶段检索

演讲最后介绍了混合搜索流程中的重排序（Reranking）机制，这是提升检索精度的关键第二步。在传统的向量搜索中，查询和文档的评分通常在索引时或简单匹配阶段完成，而重排序则是在第二阶段将查询和文档在评分时刻结合。由于无法预先嵌入（pre-embed），这需要在查询时运行推理模型，从而带来一定的延迟成本。因此，最佳实践是先通过第一阶段检索获取一个较小的候选数据集（如前文提到的5个结果），再使用重排序模型对该小集合进行精排。演讲者指出：">> reranking combines the query and the document as scoring time together... you can't pre-mbed. So you pay the penalty of having to run inference at, you know, at query time"。只有在延迟预算允许且对答案精度（如区分 answer one 与 answer two）至关重要时，才应引入这一阶段。通过这种两阶段策略，系统能在可接受的延迟范围内最大化检索的相关性和准确性。

重排序器在Agentic Search中的必要性与时机

在使用向量搜索进行文档检索时，虽然第一阶段获取的文档质量足够高可能无需重排序器（Reranker），但在Agentic Search（智能体搜索）场景中，往往需要特定的排序结果来确保准确性。许多测试评估基于返回的前三个文档块（chunk），这极大地缩小了模型正确回答问题的窗口期。如果直接将少量候选集交给大型语言模型（LLM），而非提供更大的候选池让模型从中筛选，相关性问题的出现频率会显著增加。这是因为传递过多的上下文会导致LLM面临“多项选择”困境，当两三个答案看起来同样正确时，模型随机选择一个错误的概率上升。用户和Beta测试者对搜索系统失效的抱怨往往源于此，此时引入重排序器能有效提升最终答案的精准度。

"If you're just handing a small set of candidates to the large language model... versus a larger candidate set and then asking the model to get it right. And that's where a lot of relevancy issues come in."

点式（Point-wise）与列表式（Listwise）重排序机制对比

目前支持两种主要的重排序器类型：Point-wise（点式）和Listwise（列表式）。大多数现有的重排序器，包括V2模型，均采用点式方法。它虽然将查询和文档结合，但独立地对每一对进行评分，仅关注当前查询与单个文档的关系，忽略其他候选项。相比之下，Gina V3模型采用的Listwise方法能够同时处理最多64个文档或候选项。这种方法的优势在于，当潜在答案非常相似、都在讨论同一主题时，Listwise可以通过同时观察多个文档来捕捉细微差别（nuances）。虽然这种方法需要额外的内存和时间来处理所有候选项的嵌入并持有它们，但在区分高度相似的文档时，其效果优于点式方法。

"Listwise... takes your candidate set and it looks at them all together. And so that way if the answers essentially or potential candidates are all very similar... That's where having the listwise can edge out pointwise because it can see the nuances within that list."

适用场景选择与Elastic的一体化API实现

数据分布决定了重排序器的最佳选型。如果返回的答案集差异明显且独特，点式方法通常足以应对；但如果候选项高度相似，Listwise则是更优选择。在工程实现上，用户无需手动将查询和重排序分为两个独立的API调用。Elastic允许在Retriever中通过单一请求完成这两个阶段，用户只需指定使用的重排序器模型和查询内容即可。这种一体化设计避免了单独管理推理设置或调用多个API的复杂性，显著简化了开发流程。此外，该功能同样支持SQL查询环境。

"You don't have to manually have those as separate API calls... you can just fire it all in one shot and we'll take care of it for you."

后续资源与反馈机制

演示结束后，观众可以通过底部蓝色参考仓库获取代码和笔记本。Elastic还提供了多个免费在线工作坊（Workshops），涵盖流数据处理、RAG技术、词汇搜索与向量搜索教程。针对可观测性（Observability）工作，如使用OpenTelemetry数据进行根因分析，以及安全领域的攻击发现和检测规则制定，也有相应的实验室资源。参与者可以在工作坊结束时通过反馈入口提供评价，帮助团队优化后续内容。

"We do have a bunch of other workshops online that are completely free... things like working with streams, if you have streams of data coming in, it's extremely efficient way to handle that data."

结论

混合搜索（Hybrid Search）通过结合BM25关键词检索与向量语义搜索，有效弥补了纯向量模式在精确匹配上的短板。尽管引入推理服务会增加延迟且存在量纲不一致等挑战，但利用RRF算法及预过滤机制可实现高效融合。对于大多数场景，此组合已足够满足需求；仅在候选项高度相似时，才需引入重排序器以提升精度。Elastic凭借内置推理、ESQL管道化查询及自动调优愿景，提供了从传统搜索到智能代理的一体化解决方案。其核心优势在于无需引入图数据库即可支撑大规模数据，并通过API优先设计避免技术锁定。