感谢各位的到来。大家好，我是杰夫·埃斯特尔（Jeff Estle），在 Elastic 工作，是一名 AI 架构师。今年我们换了一个更贴切的新标题。这是詹姆斯（James），你想自我介绍一下吗？
是的，我是詹姆斯·威廉姆斯（James Williams）。我是一名专注于搜索解决方案的架构师。所以，我会帮助客户处理今天将要深入探讨的所有技术细节。
这次工作坊非常注重动手实践，也就是说，我不打算讲太多话。最近我在各地演讲已经说得太多了，所以这次我们要让我少说话。大家将进行大量的动手操作。在右上角你会看到一个短链接，它是 elastic.co/ela... 这是工作坊的运行环境。
有个小插曲：他们没告诉我会有多少人参加，所以我随机猜了 75 人。看起来我低估了一点。所以，大约有 75 位朋友会很快启动环境，其他几位稍慢一点也没关系。只是多花几分钟而已。
基本上，这个链接会带你进入一个 Instruct 环境。在等待启动时，我先做个简短介绍。点击这里，然后点击“Start”，就会为你生成一个运行环境。
趁这个时间，有多少人熟悉 Elastic 这家公司？或者使用过 Elasticsearch？看来反响不错，人气很旺。
那么，有多少人曾经用 Elastic 构建过基于 RAG（检索增强生成）的应用程序？太棒了。有多少人已经听腻了“RAG”这个词，在过去两三年里听得耳朵都起茧子了？
太好了。我知道我在很多会议上说过上千次这个词，而且我以前的老板（现在已离职）甚至会因为我们要频繁提到 RAG 而感到恼火。
事实上，RAG（检索增强生成）并没有消失，只是幸运地退居幕后了。随着智能体（Agents）变得越来越强大和有效，它们接管了检索数据和分析数据的任务。
模型确实越来越聪明。虽然 Fable 曾短暂出现并引起轰动，然后迅速消失。但无论如何，我们仍然需要将这些模型与外部信息连接起来。
无论是基于时间的数据、专有信息、价格数据，还是任何模型可能没有训练过的内容——不管它们是否承认这一点。
这就是 Elasticsearch 等工具发挥作用的地方，作为检索层，它极大地增强了这些智能体的能力。
但这里有个关键问题：如果你向模型输入垃圾数据，并自信地告诉它这就是答案，无论模型多么智能，它们大概率都会相信你的话。
因此，我们需要提供准确的信息。这正是本次工作坊的核心内容。当然，网上有 20 个其他关于如何构建智能体的教程，我们网站也有类似资源。
但这次工作坊将回顾向量搜索和语义搜索的重要性、适用场景及其局限性；接着探讨词法搜索（BM25），即我们几十年来一直使用的关键词搜索，它在今天依然相关且有用。
同时也会指出词法搜索的局限性，然后将两者结合为混合搜索（Hybrid Search），以兼顾两者的优势。我们将使用 RRF（倒数排名融合）这种开箱即用的组合方式，并进行一些更高级的线性组合调整。
如果时间允许，我们还会将其应用到 Elastic 的智能体构建平台中，看看当检索到错误信息并告诉智能体这是正确的时候会发生什么——虽然它能运行，但会给出糟糕的答案。
如果你动作非常快并完成了所有内容，还有一个关于重排序器（Rerankers）的附加挑战。所以整个工作坊大致分为四个主要章节加一个附录，每个部分包含两个环节：
第一部分是在 Dev Tools 控制台中运行 Elasticsearch API 命令。当你点击启动后，系统会为你创建一个无服务器实例并加载小型数据集（毕竟只是工作坊，数据量不大）。
第二部分是在 Python 笔记本标签页中运行更深入的内容。我稍后会停止讲解，让大家动手操作工作坊内容，然后每隔 20-25 分钟我们会检查一次进度。
我会简要总结你当前所在的章节挑战内容。为了从工作坊中获得最大收益，我强烈建议大家花时间阅读 Jupyter 笔记本中的说明文档。
特别是关于为什么文档会按特定顺序出现、如何调整参数以及调优重要性的解释。如果你只是盲目地点击“运行全部”，可能 10 分钟就结束了；但如果你想真正理解内容，所需时间可能会超过本次工作坊的时长。
好了，我就说这么多，大家开始吧。有些人应该已经启动了，有些可能需要几分钟。有人已经开始了吗？有时候确实需要一点时间加载。
好的，如果卡住了请举手示意。我主要负责巡视协助。我会查看你的系统情况，并在遇到简单问题时帮你解决。
如果有疑问也请举手，我很乐意提供关于练习内容的更多细节解释。如果你感到困惑或想提问，随时可以举手示意。
所有内容也都公开在仓库中（我已经设为公共可见），你可以在 Instruct 环境之外，无论是在工作坊结束后还是其他时间运行这些笔记本。
刚才我略过了一点：我认为过去一年半里 RAG 领域最大的变化之一是，一些向量数据库的数据提供商（我们也在这一范畴内）引入了推理能力。
进入向量数据库，因此您将在 Elasticsearch Serverless 中看到嵌入生成的过程。我们有一个名为 Elastic Inference Service 的推理服务，这个名字非常富有创意，它为这些研讨会所使用的模型提供动力。我们拥有通过收购获得的 GINA 模型，因此我们现在实际上在进行自己的模型开发。这主要侧重于密集向量模型和重排序模型。您将了解到一些一年前不属于 Elasticsearch 的新技术，这就是我要补充的全部内容。
我们听说过分块（chunking）。 是的，我们确实帮助处理分块。所以我们可以回答这个问题，欢迎随时插话。他是搜索专家团队的经理，我只是四处走动。正如 James 提到的那样，我们在 Elasticsearch 中有文本字段语义文本（semantic text）。有两种方法可以做到这一点。语义文本是一种自动且简单的方法，默认情况下我们会按句子边界进行分块并分成一定数量。我一时想不起具体数字是多少 >> 250。 没错，就是这样。这是可配置的。默认情况下按句子分块，您也可以按单词边界、段落或页面边界进行更改和配置。
James 提到的 GINA 模型，无论它是我们的一部分还是我们是它的一部分，它具有非常大的上下文窗口，但由于各种原因，您并不总是希望填满该窗口。因此您可以将分块配置到单词、段落或页面边界等程度。我们在 Elasticsearch 中有一个语义映射字段，基本上是将一段文本进行分块。如果您发送给我们五页文本，我们将把它分成 250 个 token 的分块，并带有单个句子的重叠部分存储在系统中以供检索。
有一些框架讨论语义分块，还有其他标签将我称为大上下文窗口分块的东西。实际上这在后面部分的实验室中会讨论到，我们使用一种称为后期分块（late chunking）的技术，它可以在大上下文窗口上工作，虽然尚未通过 Elastic Inference Service 暴露出来，但 GINA 模型确实支持这一点。我认为这是最接近语义分块的东西。
但我们实际上并不需要这种构造，因为语义文本字段本身允许我们通过先对数据进行分块然后在语义层面上运行搜索来提供与语义分块相同的效果，您将在实验室中接触到这一点。因此我们将使用传统分块和混合搜索来解决这个问题，而不是任何异乎寻常的语义分块方案。>> 不客气。
好的，是的。 我让它可用了一周时间，因为我知道事情会如何发展。所以它在那里可用一周。这不是在任何地方，这个研讨会在我的仓库中，不管好坏。笔记本都在里面。如果您只想运行笔记本，可以将其连接到您的 serverless 集群或任何包含语义文本的集群都应该有效。但研讨会本身只有一周的有效期。
我在哪里了？是的，就像我提到的那样，每个实验室的第一部分是 Dev Tools，您在那里运行映射。左侧是 API 的输入，右侧是输出。然后您将进入第二部分，即 Python 笔记本，它将自动连接到为您启动的 Elasticsearch 环境。我看到他们正在让人们进入以确保房间仍然满员。右上角是您要访问的实际 URL，所有研讨会内容都在那里。
还有一个第二个 URL 是今天研讨会所有笔记本的源代码仓库。这两个是最有用的资源。所以如果您进来且尚未启动研讨会，请看右上角；如果您对驱动今天所 walkthrough 内容的 Python 笔记本感兴趣，请查看右下角。每次我看到有人走进来我可能会重复这条消息。
这是一个非常好的问题，我会重复它以便其他人也能听到，但这确实是这个实验室序列的一个主要观点，让您知道基于 BM25 的搜索（即传统的词汇搜索）我们长期以来一直在做，以及密集向量语义搜索，这两件事是否需要结合起来形成混合搜索？这是目前我们公司的核心论点。我们要添加的除了这个之外显然还有价值的是在上面添加重排序器的选项，但是的，这是核心论点。我们是这种方法的坚定信仰者，这也符合我加入 Elastic 之前所见的一切。
即使您使用的是专用的纯向量数据库，通常也必须将其与其他检索系统配对并执行等效的混合搜索。Elastic 的优势在于您正在实验室中看到这一点：只需一次 API 调用，我们处理从摄入分块到实时搜索的所有推理过程，其中查询被转换为查询向量，我们在幕后为您完成所有工作。特别是当谈论大规模用例时，延迟、准确性和可调整性至关重要，我们认为这是高价值的所在。
它们是可配置的。分块设置是否可配置？是的。文档中有洞察说明您可以如何更改它们以及可以更改哪些分块设置。我们拥有非常详细的 API 文档逐步介绍这一点。虽然研讨会上没有详细描述，但如果您去 Elastic 文档，您会看到分块的配置设置是什么。
我们的一些客户确实带来自己的向量并自行进行分块。我们通过标准 SDK 支持这一点。所以如果您使用 Python、Java、.Net Core，或者几乎任何 TypeScript、现代编程语言，您仍然可以以这些研讨会使用的格式使用 Elastic。只是作为开发人员您需要做更多工作。>> 我确信人们正在继续前进，您可以按照自己的节奏继续进行。
就像我说的那样，我会偶尔检查一下并稍微谈谈实验室的内容。第一个，对吧？重点基本上就是这里的小图表，讨论向量搜索和语义搜索是如何工作的以及您得到的是什么。当您使用连接到 Elastic 的嵌入模型时，
我们常把 Gina 视为开箱即用的方案，但你当然也可以自带模型。你可以连接其他推理服务，我们只是让你更容易上手 Gina，但也完全支持你使用自己的模型进行语义搜索或处理语义文本。这种设置方式的优点在于，你在索引时从文档创建嵌入向量，但在查询时必须使用相同的嵌入模型来处理查询，否则就像我尝试说葡萄牙语一样，结果会很糟糕。
几年前我们刚开始做这件事时，早期你需要跟踪推理 ID 和模型版本，确保所有开发人员都使用正确的模型。通过将嵌入信息直接集成到字段 ID 中，这带来了两个好处：首先只需设置一次。作为索引配置者，可能还有其他人使用该索引来摄入数据或查询，因此你可以一次性设置好 Gina 模型或其他任何模型。
此后每次使用该字段时，它就变成了普通字段一样，你只需传入数据或进行查询。在查询阶段，文本进入后可能会根据大小和设置被分块，然后发送到默认的 Elastic 推理服务或其他外部推理服务。接着生成嵌入向量并传回 Elastic，以执行 HNSW 算法进行检索。
虽然我们有其他近似最近邻搜索方法如 Disk ANN，但默认使用的是 HNSW（层次导航小世界图）。这种结构允许快速遍历以找到相关文档的最近邻，从而返回你指定的 Top K（如 5 或 10）个文档。如果一切正常，这能帮你找到在语义上与查询意图相似的文档或分块，而不仅仅是匹配精确关键词。
正如你在实验中所学到的，语义搜索关注的是你提问的“意思”。例如，如果房间里所有人都在问如何在 Elastic 中设置 TLS 安全配置，虽然每个人的措辞略有不同，但核心意图是一样的。因此，理想情况下你应该得到相同的文档结果。然而你也看到了，语义搜索有时会出现偏差或失效的情况。
其中一个关键失败点在于存在非常特定的关键词时，特别是那些毫无意义且高度具体的标识符（如产品 ID）。在这种情况下，语义搜索往往会失效，因为它并不真正需要这种机制。这正是第二个实验的内容：引入 BM25、词汇匹配、关键词过滤以及其他传统的搜索方法，这些长期以来的技术可以增强语义搜索的效果。
我确信有些人已经超越了第一个实验阶段，但我稍后会检查一下并回顾第二个实验室的内容。如果有任何问题，请随时提问。“对吗？分页。”“是的，分页。”所以如果你有一百个结果，想要每次只获取十个，这就是你问的吗？“哦是的。”
你可以做到这一点。虽然我不记得确切的具体参数，但基本上存在一个检查点 ID 机制。这样查询就可以继续下去，而无需重新研究或再次运行该部分的搜索逻辑。这就是我们的分页 API 部分所做的事情：它提供一个起始键，你使用该键即可继续后续查询。
“我认为它的官方标签是‘时间点’（Point in Time）。”没错，如果你在 Elastic 文档中搜索“point in time”，它会展示如何使用该功能来实现这一目的。“好问题。”关于摘要字段，它是为本研讨会特别生成的，由大语言模型生成，并非核心功能的一部分。
真实原因是当我第一次运行演示时，打印出整个正文字段太长了，导致界面杂乱无章。因此添加这个简短的摘要字段只是为了让展示更清晰。当然，你也可以在 Elastic 搜索中使用摄入管道（Ingest Pipeline）进行推理调用，生成文档摘要或提取可能的查询建议。
你正在搜索的向量字段是标题。“是的。”随着我们深入实验，后续步骤不再使用这种构造方式。但在后面的实验中涉及大语言模型补全 API 调用时，原理是完全相同的：只需将其接入你的摄入管道即可。“这是个很好的问题。”关于让 HNSW 更高效的工作，实际上始于两年多前。
我们引入了 INT8 量化技术，这至今仍是默认设置。默认情况下，我们会将 Float32 向量进行量化后再存储到内存中。虽然我们仍然保留完整的原始向量，但仅在内存中存储量化后的版本以节省空间。此外还有 BBQ 技术，相关博客文章发布已有一年多时间，它进一步压缩了我们使用的 HNSW 图向量。
通过底层复杂的技术支持，BBQ 将压缩率降至比特级别，同时保持高召回率。最近我们推出了 Disk BBQ，几乎消除了向量搜索中的内存开销。关于磁盘近似最近邻与底层搜索机制之间的区别……以及最新形式，这是 Elastic 独有的专利技术。
没有其他厂商实现这种基于图的搜索方式。“你想回答这个问题吗？”（笑声）“好的，关于基于图的搜索。”为了完全澄清一点：我们不是图数据库。虽然存在专门的图数据库，且图结构有其适用场景，但它通常维护成本高昂。如果你确实需要它，那很好。
但对于大多数人来说，我们发现这并非必需。特别是结合量化技术后，你可以快速搜索大量文档。在当今智能体（Agent）时代尤其如此，因为可以执行多次查询往返。例如在后面的某个实验中就涉及了几次这样的交互过程。
以两个为例，但你可以进入获取你的第一阶段结果，拿到一批文档样本，然后看看“哦，好吧，它们都与这个标签相关”，然后再进行搜索。这就是过滤和其他一些搜索方法发挥作用的地方。嗯，是的，我的意思是这确实会出现，但我们还没有看到它经常成为必须设置的真正阻碍。
关于这一点我要说的最后一件事是，我们看到更常见的情况是使用机器学习模型进行实时分类，这是解决图谱挑战的另一种方式。它在某些情况下有效，但并非所有情况都适用。Neo4j 和其他图谱数据库已经存在很长时间了。我不知道有哪款能真正很好地扩展，而我们正致力于针对数百亿向量数据集的目标，这意味着我们非常小心地避免引入任何阻碍我们在该级别扩展的结构。
虽然我们还没有发现需要这样做的必要，尽管这个问题经常被提及。去年这次会议上这是一个大主题。我记得当时在这里看到“图谱 RAG”被热烈讨论，预计未来仍会继续如此。嗯，我还没有见过哪种技术能完美解决这一问题。也许现场有 Neo4j 的人要反驳我说：“不，不，不，我们已经搞定了。”我认为他们确实做到了，但并未达到我们运营所需的规模。
是的哦，你是从他们的会议来的吗？不错好的在后排我想问题是我们可以使用分类模型来实现与图谱遍历类似的结果。嗯，所以在 Elastic 中我们有在所谓的 ML 节点上运行机器学习模型的概念。你基本上可以上传任何已确定的有效分类模型，并以这种方式将其接入 Elastic。
另一种选择是创建你自己的模型，拥有自己的外部推理服务，并可能用它来替代我们的 ML 技术。我希望未来在这方面能引入更多复杂性功能。但目前我们没有值得宣布的新内容。我们专注于利用现有的生成模型，并推动处理非结构化数据和密集向量嵌入及重排序器的能力极限。
一旦我们掌握了重排序部分以及正在开发且在市场上表现良好的密集向量模型，我们可能会在此基础上进行转型。此外还要补充一点，除了分类模型外，你还可以运行诸如命名实体识别（NER）等功能。如果你试图识别人名、地点或企业名称等产品名称，你可以作为查询的一部分实时运行这些模型。
当查询进入时，你通过 NER 模型运行它，而 NER 模型非常快因为它们非常小。提取出这些实体后，借助代理等技术，你不必连接复杂的 Painless 脚本，代理可以获取这些数据并创建更针对该场景的查询。因此有很多机器学习功能我们没有像以前那样多提及，因为正如 Jim 所说我们转向关注其他事物但它们仍在技术栈中且非常强大。
过滤功能很棒。你好啊？我们那边角落里那位杰出的同事可以回答我们的所有问题。我现在要转移话题了。对于那些后来加入的人，除了 Snell 之外右上角是研讨会的短链接你可以启动它它会为你打开一个实验室环境并自动配置好 Elastic Search Serverless 集群。所以请随意在那里运行测试。
关于倒数第二个问题有一个主要旋钮用于 RRF（互斥性相关性融合）我一时想不起来了。我不确定你是否在检索器的 RRF 属性中暴露了它默认常数是多少？常数是排名常数。这是一个你可以配置的东西。我不确定范围是什么那是实验室五它是可选的它主要关于重排序 RRF 在其中某处抱歉我大脑宕机了一秒它在其中某处更多地讨论了 Sil 提到的内容并举例说明你可以更改这些设置。
所以我不确定这是否回答了你的问题？好的酷继续提问这是一个很好的问题实际上在后面的研讨会中有一个表格解释了其中一些决策树我想说是第四号研讨会。简短的回答是对于小型文档语料库我的经验法则是始终看看你能通过组合 BM25 和语义搜索实现什么。如果这能让你达到所需的召回率或精度目标，无论你有什么相关性目标就停止使用它。
任何时候你在其上添加任何东西都会带来额外的延迟开销只有在你需要时才这样做下一个扩展点将是使用重排序模型然后只是选择你认为最适合你语料库的一个并进行测试验证它是否足以推动效果提升。这将是标准的理想路径方法。
有些人会稍微改变这一建议说只看 BM25 即常规搜索然后如果不够相关再添加语义搜索。但我非常推崇密集向量所以我建议一开始就将它们接入架构这样我就不必担心诸如同义词或高级词汇调优技术等问题如果你能将语义搜索与词汇搜索很好地配对可能就不需要这些了。
欢迎好吧我知道大家正在继续前进这很好。让我们对实验室二做一个简单的总结，那又是关于你最爱的词汇搜索的。但希望你也学到了它确实有其价值之处。我们只是刚刚触及了词汇搜索的表面因为你知道在 Elastic 的十二年左右的时间里那就是我们所拥有的。所以如果你曾经访问过 Elasticsearch 文档网站并进入搜索部分
点击搜索 API，有无数种方法可以修改、调整和微调词汇搜索。正如 James 所指出的，在我们能够进行语义搜索之前，必须采取各种疯狂的手段才能获得相关的搜索结果。幸运的是，现在通常不需要做那么多工作，尽管偶尔仍需要这样做。但是，词汇搜索确实有其用武之地。不过，一旦你不再寻找非常特定的关键词或短语时，它往往会失效。它的优势在于速度——我甚至不想说它通常更快，虽然现在随着量化等技术的发展情况并非总是如此，但默认情况下它确实相对较快。
在实验三中，大多数人可能已经掌握了这一点，接下来就是如何将它们结合起来。我要说的是，尽管我是密集向量搜索的忠实粉丝，但词汇搜索在几乎所有用例中通常都具有更低的延迟特性。这是因为没有发生机器学习推理过程。因此，每当进行基于密集向量的语义搜索时，你都会引入对推理端点的调用。而且往往这个推理端点会成为比系统其余部分更大的瓶颈。这也是我们将推理集成到数据平台中的另一个原因，因为在进行端到端测试时，如果你的向量数据库返回向量的速度很快，但依赖的推理服务很慢，那么你的搜索整体就会变慢。
我认为这个问题正在随着数据平台将更多能力集成到系统中以及模型的改进而发生演变，每个供应商都会有自己独特的见解。我们的观点是，一切始于传统搜索，鉴于我们的历史背景这很有意义，然后在其上添加语义能力，如果需要的话再分层加入重排序。至于这些功能具体在哪里执行，那就是细节决定成败的地方。作为一名试图围绕此类技术构建架构的开发者，你的选择非常广泛。
取决于你起步的技术栈不同，你会对数据平台中应该做什么以及是否需要在周围构建某种中间件产生不同的看法。我 loosely 地使用“中间件”这个词，但在 AI 热潮开始以来，整个应用程序运行时结构已经消失，现在必须重新回归。它要么落地在数据平台本身内部（我们在其中执行推理以及协调通常需要与外部服务配合的其他功能），要么会有尝试实现这一目标的平台，而数据平台仅仅作为一个插件存在。
这让我想起我刚开始技术职业生涯时的旧时代做法：我们当时在做对象关系映射（ORM），数据库号称是可插拔的。你只需交换凭据即可，因为不再使用 SQL 了。我认为我们现在处于 AI 的非常早期阶段，对于检索目的而言，一旦你开始编写代码，就会被锁定在你选择的任何技术栈中。这决定了你必须做出的许多不同设计决策，尤其是在开始扩展规模时。
我们在数据量变大且延迟要求变得更为严格（我不想说是严重，但 SLA 确实非常紧凑）时介入并相对于所谓更简单的栈拥有优势。那时我们会表现出色，因为我们可以做其他平台无法做的事情，并且在相关性方面具有其他数据平台无法实现的调优水平。这是一个很好的问题，我们在实验中讨论过，但我认为我们没有提供那种权威的答案指南，告诉你如何根据数据形状或用户可能执行的搜索形状来构建权重。
简短的回答是：今天这实际上很难做到。更长的回答是，我认为你会看到我们在这方面的发展，目前相关性调优中缺少一个尚未以使其即插即用方式解决的要素。我一年前发布了一个参考架构，基于 Mashra 关于自动化的概念涵盖自调优。但在理想世界中，你实际上能够获取通过系统的搜索、来自这些用户体验的遥测数据（如点击流量和点赞/点踩），以及任何已集成到用例中的其他业务指标，来实际调优相关性。
这可能会为线性搜索引入不同的权重，或者根据传入查询的类型在 TF-IDF 和线性之间切换并赋予特定权重。当然，还有各种其他技术类型。我认为比上述两种更常见的技术是根据传入查询生成不同的过滤器集。Sunnil 构建了这一架构的原始版本，我们称之为智能搜索层。Azure Search 试图将其集成到产品中，这也是今天使用 Elastic Agent Builder（在最后一个实验中涵盖）可以实际实现的功能。
但这与仅根据我们看到的实时情况动态调整权重略有不同。你实际上会让 LLM 对查询进行 interrogate（审查/分析），然后根据该审查结果执行带有不同过滤器的搜索。我实际上非常喜欢这种技术，认为它非常棒，很高兴 Elastic 为此提供了相应的构建块。这正是 Agent Builder 旨在解决的问题。
没错。这也是我希望的——虽然这还不是我们要宣布的计划，但我希望未来你会看到“自动调优相关性”的概念成为你可以启用的功能。你可以指定属性或设置来开启它，甚至根据用例和系统实际使用情况将其调高。为了向大家明确说明：我们尚未发布任何实现此功能的技术，但这确实是一个经常被提及的话题。
在我和客户合作的过程中，有一个功能如果具备的话，将会产生巨大的影响，并极大地简化开发者的工作。你同意吗？好的，我要再次向我们的首席技术官提出这个问题，让他再说一次“不行”。
我们要梳理一下这个流程。在座的大多数人都已经超越了这一阶段，如果没有也没关系。我们试图在这里结合两种不同的方法论，问题的核心在于：BM25 的评分范围是从零到某个数值，而向量搜索通常是在零到一之间。因此，当这些尺度不一致时，从纯数字角度来看，词汇搜索中较差的结果往往会在数值上胜过语义搜索结果。
那么有趣的游戏就在于如何结合它们。这里有几种不同的方法，我们在这里不深入讨论如何选择其中一种，但确实存在多种途径来实现。我们要讲的是基础知识。RRF（倒数排名融合）旨在开箱即用，效果相当不错，直到它不再有效为止。它是一个很好的起点，你不需要知道如何调整参数，也不需要深入了解数据的细节。
其基本思想是：这里有一个表格，你抛弃具体的分数。并行运行两次搜索后，取它们的排名顺序。虽然其中包含一些秩常数（rank constant），但基本上如果你的结果文档在两者中排名都很高，那它很可能是一个很好的匹配。当它们不重合时，组合策略就开始发挥作用了。
这里有一个相当简单的评分机制（我刚才滑过去了）。你会有一个表格，本质上返回的不是按分数排序的文档列表，而是排名顺序。这就是为什么那里有秩常数的原因，因为你只是获取文档的排名。你可以看到它在表格中是如何工作的：虽然文档以不同的顺序出现，但通过排序，你希望能得到最佳答案。但这并不总是有效。
正如詹姆斯刚才提到的，过滤是一种非常强大且有效的辅助手段。如果你能通过关键词、地理位置或日期等条件对数据进行过滤，将候选数据集缩小到较小的范围，通常你会得到更好的结果。因为你不是在盲目地撒网覆盖一切，而是在缩小和收窄范围。
这就好比我想今晚吃披萨，我可能不会只搜索“食物”，但如果我这样做了，我可以随后过滤出“披萨”结果。这就是过滤发挥作用的地方，Elasticsearch 在这方面做得非常出色且迅速，我们有多种不同的方式来实现它。但这并不总是有效，因此你可以进入线性组合阶段，这里提到了 MinMax 等不同方法。
在这里你需要对分数进行归一化。与其取排名，不如将分数标准化到相同的范围（零到一），然后将它们结合起来。这里有一些调整权重的示例，虽然这属于入门级的调优知识，但你可以看到哪种方式效果良好。这就是基于判断集（judgment sets）的地方。
我们有很多不同的研讨会等，智能查询层等功能以更自动化的方式处理这些事务。本质上，你拥有人类的判断（如今你可以让 LLM 协助），即基于这个查询，“这些是我想要的精确文档”。然后你运行实验，查看哪些权重能最准确地给出结果。你有什么想补充的吗？抱歉，我要再增加一点内容。
这实际上是我们去年和前年经常讨论的智能查询层架构中使用的一种技术。Elasticsearch 支持搜索模板的概念。因此，你理论上可以拥有三种不同的搜索策略：一种使用 RRF，一种使用线性组合，另一种可能结合线性和/或 RRF 与重排序器。
如果你在上面加一层，比如一个 LLM，其提示语很简单：“基于这种类型的查询，我希望你路由到这个搜索模板；基于那种其他类型的查询，我希望你路由到那个搜索模板。”你可以实现一种所谓的“穷人的自动调优”，即根据传入的搜索查询外观，在完全不同的搜索策略之间进行切换。
大多数构建高级用例的开发人员，如果无法对所有查询使用单一策略，最终都会在底层实现类似的东西。这仅仅是编码实现的难度问题。在 Elasticsearch 的情况下，很多人不知道搜索模板的存在，但这是一种强大的机制，可用于减少为该类型架构编写的样板代码量。
虽然实验室中未涵盖这一点，但值得了解该概念在 Elasticsearch 中存在。最后再次强调那个表格仅供参考，但它是一个很好的入门方式：如果你不太了解数据或面对未知的查询混合，可以从 RRF 开始，它的效果相当不错。这不是我们发明的（RRF），但我们在其他地方也使用它。
在此基础上，你可以开始探索其他组合数据的方法。但你并不总是需要进行混合搜索；有时语义搜索就足够了，有时 BM25 也足够。不过通常我们发现，语义和词汇搜索的某种组合能最有效地帮助检索工作。
然后是实验四，尽管标题如此，你确实会将数据输入模型。但我们要再次展示的是，正如我在开头所说，大型语言模型（LLMs）极其……你知道的，“聪明”不是形容它们最准确的词，但它们确实能有效提供答案。然而，只要你向它们输入超出其训练知识范围的数据，或者任何类似情况，你都可以相当自信地让它们给出错误答案。比如提供一组数据并说“天空是橙色的”，通常它会告诉你天空确实是橙色的。当然有办法规避这种情况，但在这里我们大致展示了检索对于代理式答案仍然至关重要。
快速举手示意一下。还有谁没有（轻笑）完成实验三吗？好的，很好。大家进展顺利，太棒了。
顺便提一下，这里我们实际上进入了 Agent Builder，即 Elastic 的代理平台。该平台显然具备运行代理、工具和技能的能力。你可以接入多种大型语言模型，Elastic 的推理服务提供了你所有喜爱的大型语言模型。当然，你也可以自带自己的大型语言模型，然后直接针对 Elastic 内的数据进行这些工具的运行。
虽然工作坊中未涵盖工作流程（Workflows），但本质上，当你有一组需要按顺序完成的任务时，就可以使用它们，其中包含决策树等机制。代理可以调用这些工作流程，也可以向外连接。因此，你可以调用其他系统、MCP 工具或 API，随心所欲地调用任何东西。
但这超出了本次工作坊的范围。既然我们有一点时间，这里代理便具备了开始执行操作的能力。这不仅仅是为你检索答案，还有另一个完整的工作坊可以学习：例如因观测性中的日志和追踪数据引发的事件，代理可以判断系统资源不足需要扩展。因此你可以调用工作流程来自动扩缩 Kubernetes 环境，这只是一个例子，这里我们实际进入了 Agent Builder 并简要介绍了其功能。
对于软件开发人员来说，Agent Builder 更有趣的一点是：你在 Agent Builder 的 Kibana UI中看到的所有内容都可以通过 API 进行编程。如果你决定快速原型开发，使用 Elastic 的 Agent Builder 机制并心想“哦，我现在必须从头重写所有代码来构建真正的应用”，你不必这样做。你可以在应用程序中重用这些相同的端点，并在自定义的用户体验中进行相同调用，而该用户体验由你控制。
此外，如果你决定将 Agent Builder 组件提取出来并接入另一个框架或另一组你构建或使用不同框架的 API，我们也将与之兼容。因此我们的目标是尽可能提供开箱即用的体验，但不将你锁定，迫使你按照我们希望的方式构建应用。我们非常灵活，甚至到了近乎过度的程度。所以当你问问题时，答案通常以“视情况而定”开头。
最近有人进来但不知道 URL 吗？抱歉，我想是的，但从那里开始吧。它在右上角，那个短链接 ELD one。以防有人后来进来没听到我说，这个实际的工作坊将提供一周时间。而蓝色的“By James”链接是包含所有笔记本的仓库，里面也有其他代码，但你在使用 instruct 时主要使用的是这些笔记本。
你可以将其连接到任何你拥有的 Elasticsearch 集群，即使是免费的（好吧，如果是连接不同服务的话）。它会加载数据并让你运行整个过程。所以它将一直可用直到有人删除它——删掉我吧。（旁白：顺便说一句，感谢我们杰出的架构师 Sunnil，我们要确保给你提供额外内容和补充工作坊材料。网上有额外的在线工作坊，采用我们今天使用的相同格式，基本上是一个预构建的 instruct 环境，让你可以逐步了解概念并深入学习 Elastic 的内部工作原理。）
我们强烈建议你访问该 URL 并使用这些工作坊。这本质上是免费培训，一旦你完成这些工作坊，你的市场价值可能会增加……我不知道是十万还是二十万美元一年。这是 guaranteed 的加薪。（旁白：好的。）所以当人们在那工作时，我要做两件事。抱歉（清嗓子），我几次提到向这些大型语言模型提供新信息、最新信息和新鲜或专有信息，作为一种增强手段……这就是 RAG 介入以增强其知识的地方。
另一件频繁出现的问题，而且随着代理开始运行并更快地执行操作，这个问题在各地都越来越突出，那就是能够引用来源。模型非常擅长生成信息，而且通常也是正确的。但它们也很擅长欺骗你，并非因为它们被专门训练去这样做。而是当你要问的问题与其他两条线之间界限非常模糊，而它不知道那个具体答案但知道足够多的相关信息时，它可以生成一个极具说服力的回应。除非你是专家或真正了解实际答案，否则这可能会欺骗人们。
所以总而言之，这个实验中间部分（现在显示在屏幕上）的一项功能是让大型语言模型引用来源。大多数模型不具备引用其来源的能力，因为它不是数据库。这些模型并不进行表查找并提取信息，而是基于训练生成令牌。无论如何，通过向语言模型提供实际答案并让它解析出来组成对人类友好的答案或你希望的格式，它还可以引用其来源。
这在法律领域极其重要，你可能在新闻中多次看到律师因案件陷入麻烦，因为他们编造答案、引用不存在的案例或歪曲答案。因此，如果能让模型处理大量复杂数据但仍能引用来源，这将使它们成为……
更加有用且值得信赖，直到某个程度。正如詹姆斯提到的那样，智能体构建平台的一个优点在于它完全由 API 驱动。这也是为什么本次实验的顺序略有反转，旨在展示如何通过编程方式构建这一切。你可以以这种方式创建技能、工具、智能体，通过代码实现所有操作，从而能够根据需求随时构建、拆除、扩展或修改它们。同时，你依然可以使用堆栈中内置的所有功能特性。
我们将进入界面并提问。在概览页面，我们提供了许多开箱即用的技能。这些就是所谓的“技能”，我相信在场各位都清楚这一点，毕竟这是一个人工智能会议。“技能”包含多种要素，但本质上它是向模型或智能体解释如何以特定方式执行任务。例如规定何时使用工具、如何创建演示文稿或构建其他服务。任何你可以写下来以辅助它的东西都算作技能，智能体不必完全靠自己摸索。
有些内容旨在加速处理过程，另一些则用于确保产生特定的结果。如果你希望提供核心指令（如屏幕所示），我们可以提供大量开箱即用的技能，比如创建图表、可视化数据或进行搜索。此外我们还创建了“工具”。两者的区别在于：工具是执行具体动作的实体。我们提供的开箱即用工包括运行搜索、列出工作流等。我提到过的工作流，是指以确定的方式联系外部服务或执行特定操作的方法，但你也可以创建自定义工具。
例如查看你创建的智能体的概览页面，这是一个非常简单的演示用智能体。它包含一个技能，主要讲解如何诊断你正在查找的问题。与开箱即用的模板相比，这里的描述相当简短，但你可以在此提供尽可能多的信息以辅助智能体。它有助于查找故障原因、修复方案，并查看错误代码等。此外它还具备一个工具功能。
这里我们有一个搜索工具，但为了演示如何创建新工具，我可以添加其他工具。（清嗓子）这是一个我常问的有趣问题：在座有多少人知道或听说过 Elastic 中的 ESQL？好的，有一位。这符合我的预期。不过很高兴听到很多人熟悉 Elasticsearch。ESQL 是 Elastic 中较新的查询语言，即 ES PipeSQL。它是一种接近 SQL 的类 SQL 语言，拥有类似 SQL 的语法，“Pipe”的作用是将命令串联起来。
你运行某个操作，结果传递给下一个管道步骤，依此类推。你可以使用 ESQL 工具来查询 Elasticsearch 中的文档。“索引搜索”是一个有趣的工具，或者说是功能。ESQL 是运行特定查询并返回具体字段；而索引搜索更像是一种文档工具。你告诉它某个或某组索引的用途、字段映射关系以及具体包含哪些字段。
例如，如果你有产品索引和定价库存索引，它会说明如何像 ESQL 那样将这两个索引连接起来。由于智能体可以进行往返查询和探索，它们通常能够识别集群中的各个索引。如果你提问而它一无所知，它会启动这个搜索工具或映射查询功能，查找所有索引及其元数据。
然后尝试猜测哪些看起来像产品相关的信息并组合起来。总之，它会进行几轮循环查询，这会消耗 Token 资源——我们都喜欢节省 Token 的开销。因此这个工具能极大地加速这一过程，并引导智能体走向正确的方向。“工作流”我之前提过几次，它可以有序地运行任务并与其他系统交互。如果你想调用外部 MCP 服务器，也可以这样做。（清嗓子）
需要指出的是，智能体构建平台中的工具（包括开箱即用和自定义的）都作为 MCP 暴露出来。Kibana 提供了一个 MCP 服务器，因此如果你的智能体希望通过 MCP 连接，可以使用其中的任何工具。最后这一点在实验中可以操作，它展示了智能体如何进行多次循环迭代。首先加载技能以了解如何回答关于“集群为何频繁因 137 退出代码崩溃”的问题。
这是一个两部分的问题：为什么发生这种情况？以及如何防止它再次发生？智能体需要找出答案，然后调整设置以防止问题重现。因此它会运行该技能并寻找答案。经过几轮循环，它诊断出你的问题：实际上是操作系统的内存管理器在运行并杀死了进程。接着它会讲解如何调整 JVM 选项来修复问题，以及如何预防此类情况发生。
由于答案存在于 Elastic 内部数据中，且智能体具备查询能力和运行多个工具的功能，它能够为你提供答案并指引你下一步操作。是的。我还要补充一点：如果你处于活跃的原型开发阶段，试图寻找能够解决你用例的搜索逻辑或查询语言逻辑，这实际上是一个非常好的开发和调试工具。你可以借此发现哪些搜索策略能有效检索到你所需的数据。
关于 ESQL，我是它的忠实粉丝。起初我持保留态度，因为 Elastic Query Language 中的一些功能在 ESQL 中尚未实现。但我认为它的功能已经足够完善，至少值得你尝试一下，特别是如果你正在构建生成式搜索用例。因为 ESQL 中有一些非常酷的概念，非常适合用于解决此类问题。
某些搜索任务的表现优于 Elastic 查询语言，您应将 ESQL 视为当前功能的超集。ESQL 的另一大亮点在于其参数化功能可无缝集成到 MCP（模型上下文协议）工具调用链中，并与 Agent Builder 配合使用。虽然技术上在 ESQL 之外也能实现类似功能，但我们架构设计的初衷就是为了解决许多所谓的“智能体搜索”用例。如果您尚未研究过 ESQL，我强烈建议您尝试一下。
若想关注我们在搜索领域的创新动态，首先应查阅 ESQL 文档，了解我们开发的新颖检索机制。例如，我们正在探索联邦搜索以及通过 ESQL 调用非传统 Elastic 查询的不同系统等功能。这些功能目前处于开发阶段，但即将推向产品市场。届时，ESQL 将成为您接入这些新特性的门户。
我们可以利用 SQL 调用对 Elastic 外部的 Parquet 文件进行查询，如果将其与来自 Elastic 的数据结合使用，这将具有极大的威力。从演示中可以看到，智能体确实使用了 ESQL 进行此类调用。它能够将两个搜索线程合并（即所谓的“融合”），从而回答复杂问题并返回结果。
这种管道式语言允许您逐步执行查询阶段，获取答案后进入下一环节。ESQL 高度可参数化，旨在实现 Splunk 查询语言在其鼎盛时期所追求的目标。同时，它融合了经过验证的 SQL 概念。ESQL 的一个优势是查询语句中的标记更少，能更直接地实现精准检索。
其他公司也利用类似技术构建针对非结构化数据（如日志）的搜索系统。我们最初开发 ESQL 的主要动力，是为了打造一流的搜索体验，让用户能够替代 Splunk。如今，鉴于该架构的实用性，我们已将其扩展至 Elastic 的所有支柱领域：搜索、安全和可观测性。
ESQL 已成为这三个领域的核心构建模块，并将作为我们未来创新的主要机制。在执行混合搜索查询时，系统会响应并展示审计轨迹，让您清楚了解答案的来源。您可以在底部引用处点击深入查看细节，例如 JVM 设置等具体内容。
系统会限制显示结果数量（如五个），避免界面杂乱，但您可以点击跳转至 Discover 页面。Discover 是文档检索的主要接口（类似 Kibana/Cabana），近年来有所更新，现在也支持 ESQL。在这里您可以查看返回的五个文档，系统还会为您生成图表以便分析。
通过顶部的查询语句和实际文档内容，您可以查看详细信息（如 URL）。由于我们在文档中提供了 URL 链接，因此可以直接提供更多信息入口，而无需猜测。此时讨论接近尾声（约420分钟标记），剩余18分钟可用于提问环节，欢迎大家自由交流。
接下来介绍关于重排序器（Rerankers）的实验部分。重排序是一个常被误解的概念，我们特意加入此环节以解释其必要性。如果演示正常播放，我们将看到重排序的作用：之前的查询属于第一阶段检索；第二阶段则是重排序。
如果您在第一阶段（向量搜索、语义搜索或混合搜索）返回了大量数据，就可以对这些数据进行重排序。重排序在评分时将查询与文档结合考虑。而在常规向量搜索中，数据预先嵌入，查询时仅通过算法返回结果，两者并未在评分阶段紧密结合。
重排序虽然能提升精度（例如区分答案一和答案二），但由于需在查询时运行推理，无法预先嵌入数据，因此会产生性能开销。为了缓解这一问题，我们不建议对全量数据进行重排序，而是先通过第一阶段获取较小规模的数据集，再使用模型对该小数据集进行重排序。
如果在您的延迟预算允许的情况下添加排名器，或者您愿意花费额外时间运行第二阶段以生成嵌入并提升精度（特别是在答案选择至关重要的场景下），那么重排序将非常有用。
支付时，你知道轻微的延迟惩罚会起作用。如果你在第一阶段就把文档处理得足够好，并让智能体去检索它们，那么你可能就不需要重排序器了。但当你需要特定的顺序时，它就派上用场了。我们在智能体搜索用例中经常看到这种情况。我们经常遇到一些场景，人们基于返回的第一、第二和第三个文档块进行评估，这给了你非常小的机会窗口来确保答案正确。如果你只是将少量候选项交给大语言模型去回答问题，而不是提供较大的候选集然后让模型从中选出正确答案，那么很多相关性问题的根源就在这里。
你传递了过多的上下文信息。这就像是一个多项选择题，其中两三个答案看起来对大语言模型来说同样正确，它只是随机挑选了一个。如果它选错了，那么你的用户以及你新智能体搜索系统的测试人员就会抱怨搜索功能无法正常工作。这种情况非常普遍，也非常常见。在这种情况下，像这样的重排序器实际上会非常有用的。因此，我们支持两种类型的重排序器：一种是单点式（Point-wise），这是目前大多数重排序器的类型，也是V2模型采用的方式。
单点式仍然将查询和文档结合在一起，但它只是独立地对它们进行评分。它只看查询和文档，不看其他任何东西。另一种是列表式（Listwise），这是Gina V3模型采用的方式，它接收你的候选集。例如目前最多支持64个文档或64个候选项，并将它们全部一起查看。因此，如果答案本质上或者潜在的候选项都非常相似，比如它们都在谈论同一件事，那么列表式就能胜过单点式。
因为通过同时查看多个文档，它可以捕捉到这些细微差别中的微妙之处。不过，这需要稍微多一点内存或时间，因为它必须一次性为所有这些候选项生成嵌入向量并将它们保留在内存中，然后在它们之间运行评估。这与逐个发射并单独处理不同。如果你的数据相当多样化，返回的答案是一组截然不同的候选项，其中一、二、三、四、五个都足够不同，使得单点式方法有效的话。
那么通常来说，单点式往往效果不错。但是，如果你的候选项集非常相似，列表式可能会更好地帮助你解决问题。我们在这里插入这些内容是因为我们希望提供帮助。虽然这是一个两步、两阶段的过程——第一阶段是查询，第二阶段是你的排序——但你不需要手动将这些作为单独的API调用。我们可以在一次操作中完成所有工作，这在实验室环境中通过检索器实现是可以做到的。
问：你可以对SQL进行重排序吗？答：是的，当然可以。所以你也可以在SQL中这样做。基本上在一版本中，你拥有重排序器，告诉它你想使用哪个模型和查询，它会为你运行这两个阶段。这样你就不需要单独管理推理设置，也不需要先调用推理API再查询最后重排序。你可以一次性触发所有操作，我们会为你处理好这一切。
我要再次展示那张幻灯片，附上一些链接。右上角是我们今天一直在做的内容，这一部分已经开放了一周。底部的蓝色参考仓库是代码所在的地方，包括笔记本等内容。中间有两个红色的链接。一个是Sunnil的秘密Elastic环境。哦天哪，我也打错字了。每个人都会拍下来这张照片的。另一位嘉宾说这证明了我们是直播环节，我要怪灯光问题，证明我们是在即兴发挥。
我还有事得走了。好的。还有其他在线研讨会。我们要有很多其他完全免费的在线研讨会。例如处理数据流，如果你有持续流入的数据流，这是一种极其高效的处理方式。还有另一个RAG教程、词汇搜索和向量搜索教程。如果你有人从事可观测性工作，比如涉及OpenTelemetry数据或寻找根本原因分析等事情，我们也有相关的实验室课程。所以有一些可观测性的实验内容。这里应该还有一些安全方面的内容，因为安全是我们平台的重要组成部分。
从攻击发现和检测规则做起。我知道随着我们将越来越多的智能体能力添加到堆栈中，新的内容也在不断推出。还有问题吗？好的，让我快速问一个问题。如果你一直待在这里，你会自动获得下一个研讨会的席位吗？我只是好奇大家是否因为这点才留下来。好的，我在判断谁还在工作，谁只是闲逛着，这完全没问题。无论如何我都可以离开。我们假设大多数人都是留下来闲聊的，而不是在等待任何帮助。
但如果你确实需要帮助，你还有7分57秒的时间。Sil，你想演示点什么吗？希望这对仍然在房间里的人而言是时间的好用途。我们非常希望能得到你们的反馈。我们没有提前告诉你们，但在研讨会结束时有一个反馈意见的数据输入入口。所以当你完成时，你有能力告诉我们这个研讨会有多棒，或者你有多么不喜欢它。如果你说了坏话，那会伤害我们的感情。但我们会据此改进研讨会以造福他人。