什么是召回？

召回率 以 0 到 1 的范围来衡量用户真正想要的文档有多少出现在搜索结果中。如果某个查询应显示三个产品，而您的搜索结果仅有两个进入前 10 名，则该查询的得分为 recall@10 = 0.67。这是一个基于集合的指标：它并不关心相关文档在这 k 个结果中的位置。位置 10 的相关文档与位置 1 的相关文档具有同等效力。高召回率意味着您不会丢失相关结果。

该图表显示了两组文档：所有相关文档（左侧）和 BM25 实际检索到的文档（前 10 个，右侧）。只有交集部分才计入召回率，找到了 prod_1 和 prod_2，而 prod_3、prod_4 和 prod_6 则完全遗漏。结果：Recall@10 = 2/5 = 0.40。

准备工作

让我们言归正传，更好地了解召回的工作原理。本演示使用 Python。您可以在配套笔记本 (notebook.ipynb) 中跟着操作，其中每个代码块都是一个可直接运行的单元。

提供的代码使用以下内容：

• Elasticsearch 9.3+

• Python 3.10+

• 包含 Elasticsearch 凭据的 .env 文件

该数据集

我们将使用包含 1,000 种产品的产品目录，涵盖鞋类、电子产品、工具等多个类别。

每份文档有四个字段：

字段

类型

“标题”

文本

“描述”

文本

“品牌”

关键字

`类别`

关键字

该数据集加载自 dataset.csv。

词汇搜索的支持和局限性

BM25 是 Elasticsearch 和大多数搜索引擎的默认排名算法。它根据查询词在文档中的出现频率对其进行评分，并根据文档长度和这些词在整个索引中的出现频率进行调整。在此基础上，您还可以获得分析器：小写规范化、词干提取和停用词消除。查询“跑步鞋”将匹配“跑步鞋”，也可能匹配“跑步”。

这对很多查询都很有效：

• “跑鞋”会立即匹配标题中包含这些确切标记的产品。

• “蓝牙扬声器”会显示便携式音频产品，因为这些词语是逐字匹配的。

搜索结果具有确定性和可解释性：文档排名靠前，是因为查询词出现在其中。调试相关性很简单。

出现问题的地方

现在，让我们针对同一目录尝试这些查询：

• “护肤流程”：在任何产品标题中都没有出现“流程”这个词。BM25 能够部分匹配“护肤”这一词，但面部精华液、身体精油和保湿霜等产品是用“维生素 C”、“视黄醇”或“提亮”等术语来描述的，这些术语与查询词都没有重叠。构成完整护肤流程的产品分散在索引中，没有任何共同的令牌将其关联起来。

• “宠物旅行配件”：这是一个用例分组，而非产品类别。宠物狗背带、宠物汽车座椅和旅行笼都与此相关，但它们的描述侧重于便携性、安全性和舒适性，而非“旅行配件”。BM25 与“宠物”大致匹配，但无法区分旅行专用产品与宠物目录中的其他产品。

这是一个召回问题。相关文档已存在于您的索引中。BM25 无法找到它们，因为用户的用词和文档中的词语匹配度不够高。

添加同义词有助于处理已知情况。但您无法枚举用户表达某种意图的所有方式。这就是向量发挥作用的地方。

为何要测量召回率

在解决问题之前，需要先对问题进行量化。

Recall@k 衡量有多少用户真正想要的文档出现在搜索结果中。正式来说：

Precision@k 衡量前 k 个结果，以及其中有多少是实际相关的：

高精度意味着您返回的结果质量较高。在电子商务领域，缺少相关产品（召回率低）通常比显示稍有瑕疵的结果（精度较低）更糟糕，因为隐藏的产品意味着销售损失。

Elasticsearch 的 rank_eval API 允许您系统地测量两者。您提供一系列查询，每个查询都有一组已评分的文档，Elasticsearch 会为您计算所有查询的指标。

设置评估

rank_eval API 需要一个评级数据集：查询与每个查询相关的文档之间的映射，以及相关性等级（0＝不相关，1＝相关，2＝高度相关）。

在笔记本中，这是判断列表：

这种混合是有意为之：q1 是 BM25 可以很好处理的查询（产品标题中的精确标记），而 q2、q3 和 q4 是基于意图的查询，用户的意图是以概念而非具体产品关键词来表达的。

测量 BM25 基线召回率

首先，设置 Elasticsearch 客户端，并对原始文本数据建立索引：

现在为 BM25 构建 rank_eval 请求。列表中的每个请求都将会查询及其评分结合起来：

结果：

0.43 这意味着在所有四个查询中，BM25 只找到了它应该找到的文档的 43%。这种不足集中体现在基于意图的查询中：“护肤流程”漏掉了面部精华液和身体精油，因为“流程”一词从未出现在产品标题中；而“宠物旅行配件”则检索出了一些不相关的宠物产品，却遗漏了那些以便携性和安全性而非“旅行配件”来描述的宠物笼和宠物箱。

这就是我们的基准。现在我们有了一个要超越的数字。

使用 Jina 嵌入添加向量搜索

Vector search 将文档和查询编码为高维向量，这是一种由数百甚至数千个数值组成的向量，每个数值都对它所代表的数据的特定特征进行编码。意义相似的文档最终会在向量空间中靠近，即使它们没有共同的词汇。“健身器材”和“哑铃套装”会放在一起，因为这两个概念是相关的。我选择 Elasticsearch 作为我的向量数据库，是因为它支持混合搜索，让我既能理解语义，又能精确查找关键字。

EIS 包括通过其推理 API 嵌入模型的开箱即用支持。

步骤 1：使用 Jina 嵌入 v5 作为推理终端

如果您的集群具有 GPU 资源（在 Elastic Cloud 和 Elasticsearch 9.3+ 中可用），嵌入将在 GPU 上生成，这比 CPU 推理快得多，并消除了历史上使向量在扩展时变得昂贵的性能权衡。

为什么要特别选用 Jina 嵌入？jina-embeddings-v5-text 是一种多语言模型（支持 119 种以上语言），具有 32,000 个标记的上下文窗口，并支持特定任务的低秩自适应 (LoRA) 适配器。它适用于开箱即用的简短产品描述。点击此处了解有关 jina-embeddings-v5-text 模型的更多信息。

步骤 2：创建具有语义字段的索引

这里的关键在于 semantic_text 字段类型。这是对 dense_vector 的更高级别的抽象：您将其指向一个推理终端，Elasticsearch 会自动生成嵌入。

title 和description 上的 copy_to 属性意味着这两个字段的内容都会流入 semantic_field 进行嵌入，因此单个向量就能捕获完整的产品表示。

步骤 3：为产品编制索引

索引时，Elasticsearch 会调用每个文档的推理端点，并将生成的嵌入存储在 semantic_field 中。您无需编写任何额外代码。

混合搜索：将 BM25 与向量结合并采用 RRF

添加向量可以提高召回率，但仅使用向量可能会在精确匹配查询中失去精度；“跑鞋”仍应将逐字匹配的结果排在首位。混合搜索则保留词汇成分，以保持这种精确性。

使用倒数排序融合 (RRF) 的混合搜索可以保持两者的优点：

• BM25 可以高精度处理精确和近似精确的查询。

• 语义搜索能以高召回率处理基于意图和多语言的查询。

• RRF 将两份排名表合并为一份排名表。

RRF 公式根据每个文档在每个结果列表中的排名，为每个文档分配分数：

在两个列表中均排名靠前的文档将获得更高的综合得分。rank_constant用于控制排名较低的文档获得的权重大小。

结果：

混合搜索在 BM25 (0.43) 的基础上有了显著提升，并为“跑鞋”等精确匹配查询保留了精确度。

结果：前后结果对比

以下是所有三种方法的完整对比：

结果：

方法

Recall@10

BM25（词法）

0.43

混合型（BM25 + 向量）

0.75

按查询细分：

结论

在这篇文章中，我们看到，当用户键入精确的查询时，BM25 词汇搜索是可靠的，但当他们根据意图而非关键词进行搜索时，其召回率就会下降。借助 rank_eval，我们建立了一个可重复的基线，用真实数据来衡量这一差距。在此基础上，我们添加了一个由 Jina 嵌入提供支持的 semantic_text 字段，并再次运行了评估。结果：混合搜索将召回率从 0.43 提高到 0.75，同时保留了精确匹配查询的精确度，但实际幅度取决于您的查询组合。

该模式可扩展至本示例之外：从用户的实际查询中收集判断，以 rank_eval 作为基准运行，添加 semantic_text，然后再次进行测量。您将确切了解改进了哪些方面以及改进了多少。

后续步骤

• 深入了解召回与向量搜索：《召回与向量搜索量化》，作者：Jeff Vestal

• 添加重排序功能，以进一步提升前几条结果的精准度

• 探索 Elasticsearch 混合搜索文档

• 阅读有关 rank_eval API 的更多信息

本文将探讨构建自定义 Elasticsearch MCP 服务器的优势，并展示如何使用 TypeScript 创建该服务器，以将 Elasticsearch 连接到 LLM 驱动的应用程序。

为什么要构建自定义 Elasticsearch MCP 服务器？

Elastic 为 MCP 服务器提供了一些替代方案：

• Elastic Agent Builder MCP 服务器，适用于 Elasticsearch 9.2 及以上版本

• 适用于旧版本的 Elasticsearch MCP 服务器（Python）

如果您需要更好地控制 MCP 服务器与 Elasticsearch 的交互，构建自己的自定义服务器可以让您灵活地根据自身需求进行定制。例如，Agent Builder 的 MCP 终端仅限于 Elasticsearch 查询语言 (ES|QL) 查询，而自定义服务器允许您使用完整的查询 DSL。在将结果传递给 LLM 之前，您还可以控制结果的格式，并可以集成其他处理步骤，例如我们将在本教程中实现的由 OpenAI 驱动的摘要功能。

通过阅读本文，您将学会使用 TypeScript 创建 MCP 服务器，该服务器可搜索存储在 Elasticsearch 索引中的信息，对其进行总结并提供引用。我们将使用 Elasticsearch 进行检索，使用 OpenAI 的 gpt-4o-mini 模型提炼摘要并生成引用，并使用 Claude Desktop 作为 MCP 客户端和 UI 来接收用户查询并提供回复。最终我们将得到一个内部知识助手，帮助工程师在整个组织的技术文档中发现并综合最佳实践。

准备工作：

• Node.js 20 +

• Elasticsearch

• OpenAI API 密钥

• Claude Desktop

什么是 MCP？

MCP 是由 Anthropic 创建的开放标准，提供大型语言模型与外部系统（如 Elasticsearch）之间的安全双向连接。您可以在这篇文章中了解更多关于 MCP 现状的信息。

MCP 的发展每天都在变化，服务器的使用范围越来越广。此外，构建自定义 MCP 服务器也非常简单，我们将在本文中进行演示。

MCP 客户端

可用的 MCP 客户端由很多，每个客户端都有自己的特点和局限性。为了简化和普及，我们将使用 Claude Desktop 作为演示中的 MCP 客户端。它将作为聊天界面，用户可以用自然语言提问，它还将自动调用我们的 MCP 服务器提供的工具来搜索文档和生成摘要。

创建 Elasticsearch MCP 服务器

通过使用 TypeScript 软件开发工具包，我们可以轻松创建一个能够根据用户查询输入来查询 Elasticsearch 数据的服务器。

本文将介绍将 Elasticsearch MCP 服务器与 Claude Desktop 客户端集成的步骤：

1. 为 Elasticsearch 配置 MCP 服务器。

2. 将 MCP 服务器加载到 Claude Desktop。

3. 测试一下。

为 Elasticsearch 配置 MCP 服务器。

首先，我们来初始化一个 Node 应用程序：

这将会创建一个 package.json 文件，有了它，我们就可以开始安装该应用程序所需的依赖项。

• @elastic/elasticsearch 将使我们能够访问 Elasticsearch Node.js 库。

• @modelcontextprotocol/sdk 提供核心工具来创建和管理 MCP 服务器、注册工具以及处理与 MCP 客户端的通信。

• openai 允许与 OpenAI 模型进行交互以生成摘要或自然语言响应。

• zod帮助定义和验证每个工具中输入和输出数据的结构化模式。

ts-node，@types/node 和 typescript 将在开发过程中用于键入代码和编译脚本。

配置数据集

为了提供 Claude Desktop 可以使用我们的 MCP 服务器进行查询的数据，我们将使用模拟的内部知识库数据集。来自该数据集的文档是这样子的：

为了摄取数据，我们准备了一个脚本，该脚本在 Elasticsearch 中创建一个索引并将数据集加载到其中。您可以在这里找到它。

MCP 服务器

创建一个名为 index.ts 的文件，并添加以下代码来导入依赖项并处理环境变量：

此外，让我们初始化客户端以处理 Elasticsearch 和 OpenAI 的调用：

为了使我们的实现更加稳健，并确保输入和输出结构化，我们将使用 zod 定义模式。这使我们能够在运行时验证数据，及早发现错误，并使工具响应更容易以编程方式进行处理：

请在此处了解更多关于结构化输出的信息。

现在让我们初始化 MCP 服务器：

定义 MCP 工具

完成所有配置后，我们就可以开始编写将由 MCP 服务器公开的工具了。此服务器公开两种工具：

• search_docs：使用全文本搜索在 Elasticsearch 中搜索文档。

• summarize_and_cite：汇总和综合先前检索到的文档中的信息，以回答用户的问题。该工具还可添加引用源文档的引文。

这两个工具共同构成了一个简单的“检索后总结”工作流，其中一个工具获取相关文档，另一个工具使用这些文档生成汇总的引用回复。

工具响应格式

每个工具都可以接受任意输入参数，但必须以以下结构作出响应：

• 内容：这是工具以非结构化格式做出的响应。该字段通常用于返回文本、图像、音频、链接或嵌入内容。在本应用程序中，它将用于返回包含工具生成的信息的格式化文本。

• 结构化内容： 这是一个可选返回，用于以结构化格式提供每个工具的结果。这对程序化用途非常有用。虽然本 MCP 服务器没有使用它，但如果您想开发其他工具或以编程方式处理结果，它可能会很有用。

基于这个结构，让我们详细探讨每个工具。

Search_docs 工具

此工具在 Elasticsearch 索引中执行 全文本搜索，以根据用户查询检索最相关的文档。它突出显示关键匹配项，并快速提供相关性评分概述。

我们将 fuzziness : “AUTO” 配置为根据被分析的词元的长度具有可变的拼写错误容忍度。我们还设置了 title^2 来提高标题字段匹配的文档的分数。

摘要和引用工具

该工具根据上一次搜索中检索到的文档生成摘要。它使用 OpenAI 的 gpt-4o-mini 模型来综合最相关的信息，提供直接来自搜索结果的响应，以回答用户的问题。除了摘要之外，它还返回所使用源文档的引用元数据。

最后，我们需要用 stdio 启动服务器。这意味着 MCP 客户端将通过读取和写入其标准输入和输出流与我们的服务器进行通信。stdio 是最简单的传输选项，适用于客户端作为子进程启动的本地 MCP 服务器。在文件末尾添加以下代码：

现在请您使用以下命令编译该项目：

这将创建一个 dist 文件夹，并在其中创建一个 index.js 文件。

将 MCP 服务器加载到 Claude Desktop。

请按照本指南配置 MCP 服务器和 Claude Desktop。在 Claude 配置文件中，我们需要设置以下值：

args 的值应指向 dist 文件夹中的编译后文件。您还需要在配置文件中设置环境变量，使其名称与代码中定义的名称完全一致。

测试一下

在执行每个工具前，点击搜索和工具，确保这些工具已启用。您还可以在这里启用或禁用每个工具：

最后，让我们从 Claude Desktop 聊天中测试 MCP 服务器，并开始提问：

针对问题“搜索有关身份验证方法和基于角色的访问控制的文档”，已执行 search_docs 工具并返回以下结果：

回复是：“太好了！我找到了 5 份关于身份验证方法和基于角色的访问控制的相关文档。以下是找到的内容：”

该工具调用会将源文档作为其响应有效负载的一部分返回，这些文档随后用于生成引用。

您也可以在一次交互中串联使用多个工具。在这种情况下，Claude Desktop 会分析用户的问题，并确定首先需要调用 search_docs 来检索相关文档，然后将这些结果传递给 summarize_and_cite 以生成最终回答，所有这些都无需用户单独提示：

在这种情况下，对于“在我们的系统中改进身份验证和访问控制的主要建议是什么？附上参考文献”，我们得到了以下结果：

与上一步一样，我们可以看到每个工具对该问题的响应：

注意：如果出现子菜单询问是否批准使用每个工具，请选择“始终允许”或“允许一次”。

结论

MCP 服务器代表了本地和远程应用中 LLM 工具标准化的重要一步。虽然完全兼容仍在开发中，但我们正朝这个方向快速推进。

在本文中，我们学习了如何用 TypeScript 构建一个自定义 MCP 服务器，将 Elasticsearch 连接到基于 LLM 的应用。我们的服务器公开了两个工具：search_docs 用于使用查询 DSL 检索相关文档；summarize_and_cite 用于通过 OpenAI 模型和 Claude Desktop 作为客户端 UI 生成带引用的摘要。

不同客户端和服务器提供商之间的兼容性前景看起来一片光明。下一步包括为您的智能体添加更多功能和灵活性。这里有一篇实用的文章介绍了如何使用搜索模板参数化查询，以获得精确性和灵活性。

准备工作

• Elasticsearch 9.3 或 Elastic Cloud Serverless：您可以按照这些说明创建云部署，或者改用 start-local 快速入门。

• Python 3.12：在此处下载 Python。

• Hugging Face 访问令牌。

使用 Hugging Face 推理终端完成聊天

首先，我们将构建一个实用示例，将 Elasticsearch 连接到 Hugging Face 推理终端，以从博客文章集合中生成 AI 驱动的推荐。对于应用知识库，我们将使用公司博客文章数据集，其中包含有价值但通常难以查找的信息。

通过这个终端，语义搜索可以检索与给定查询最相关的文章，而 Hugging Face LLM 则会根据这些结果生成简短的上下文推荐。

让我们来看看我们将要构建的信息流的高级概述：

在本文中，我们将测试 SmolLM3-3B 是否能将其紧凑的大小与强大的多语言推理和工具调用能力相结合。根据搜索查询，我们将把所有匹配的内容（英语和西班牙语）发送到 LLM，以生成一份推荐文章列表，并根据搜索查询和结果提供自定义描述。

以下是具备 AI 推荐生成系统的文章网站用户界面可能的外观。

您可以在已链接的笔记本中找到此应用程序的完整实现。

配置 Elasticsearch 推理终端

要使用 Elasticsearch Hugging Face 推理终端，我们需要两个重要元素：Hugging Face API 密钥和正在运行的 Hugging Face 终端 URL。它应该如下所示：

Elasticsearch 中的 Hugging Face 推理终端支持不同的任务类型：text_embedding、completion、chat_completion 和 rerank。在这篇博客文章中，我们使用 chat_completion 是因为我们需要模型根据搜索结果和系统提示生成对话式推荐。此终端允许我们使用 Elasticsearch API 以简单的方式直接从 Elasticsearch 执行聊天完成：

这将作为应用程序的核心，接收通过模型传递的提示和搜索结果。有了理论基础，我们就开始实施应用程序。

在 Hugging Face 上设置推理终端

要部署 Hugging Face 模型，我们将使用 Hugging Face 一键式部署，这是一种用于部署模型终端的简单快速的服务。请记住，这是一项付费服务，使用它可能会产生额外费用。此步骤将创建用于生成文章推荐的模型实例。

您可以从一键目录中选择一个模型：

让我们选择 SmolLM3-3B 模型：

从此处获取 Hugging Face 终端 URL：

正如在 Elasticsearch Hugging Face 推理终端文档中提到的，文本生成需要一个与 OpenAI API 兼容的模型。因此，我们需要将 /v1/chat/completions 子路径附加到 Hugging Face 终端 URL。最终结果将如下所示：

有了这个，我们就可以在 Python 笔记本中开始编码了。

生成 Hugging Face API 密钥

创建 Hugging Face 账户，并按照以下说明获取 API 令牌。您可以选择三种令牌类型：细粒度（推荐用于生产，因为它仅提供对特定资源的访问）、读取（适用于只读访问）或写入（适用于读取和写入访问）。在本教程中，读取令牌就足够了，因为我们只需要调用推理终端。请保存此密钥以备下一步使用。

设置 Elasticsearch 推理终端

首先，让我们声明一个 Elasticsearch Python 客户端：

接下来，我们创建一个使用 Hugging Face 模型的 Elasticsearch 推理终端。此终端将允许我们基于博客文章和传递给模型的提示来生成响应。

数据集

该数据集包含将要查询的博客文章，代表整个工作流中使用的多语言内容集：

Elasticsearch 映射

定义数据集后，我们需要创建一个适合博客文章结构的数据模式。以下索引映射将用于在 Elasticsearch 中存储数据：

在这里，我们可以更清楚地看到数据的结构。我们将使用语义搜索来检索基于自然语言的结果，同时使用 copy_to 属性将字段内容复制到 semantic_text 字段中。此外，title 字段包含两个子字段：original 子字段根据文章的原始语言存储英语或西班牙语标题；而 translated_title 子字段仅存在于西班牙语文章中，并包含原始标题的英语翻译。

采集数据

以下代码片段使用批量 API 将博客文章数据集摄取到 Elasticsearch 中：

现在，我们已将文章摄取到 Elasticsearch 中，我们需要创建一个能够针对 semantic_text 字段进行搜索的函数：

我们还需要一个调用推理终端的函数。在这种情况下，我们将使用 chat_completion任务类型调用终端，以获取流式响应：

现在，我们可以编写一个函数，调用语义搜索函数以及 chat_completions 推理终端和建议终端，以生成将分配到卡片中的数据：

最后，我们需要提取信息并将其格式化以便打印：

让我们通过询问一个有关安全博客文章的问题来测试一下：

如下所示，我们可以看到工作流在控制台中生成的卡片：

您可以在此文件中查看全部结果，包括所有点击和 LLM 响应。

我们正在征集与“安全与漏洞”相关的文章。此问题将用作针对 Elasticsearch 中存储的文档的搜索查询。然后将检索到的结果传递给模型，该模型根据这些结果的内容生成推荐。我们可以看到，该模型出色地生成了引人入胜的短文本，能够激发读者点击的欲望。

结论

本示例展示了如何将 Elasticsearch 和 Hugging Face 结合起来，为 AI 应用程序创建一个快速高效的集中式系统。由于 Hugging Face 拥有丰富的模型目录，这种方法不仅减少了人工操作，还具有灵活性。通过使用 SmolLM3-3B，我们特别看到了紧凑的多语言模型在与语义搜索搭配使用时，仍能提供有意义的推理和内容生成。这些工具共同为构建智能内容分析和多语言应用程序提供了可扩展且高效的基础。

什么是 LangGraph

LangGraph 是一个用于构建 AI 代理，并将其编排进工作流，从而打造 AI 辅助应用的框架。LangGraph 采用节点式架构，我们可以声明代表不同任务的函数，并将这些函数指定为工作流中的节点。多个节点相互作用后形成的便是一个图结构。LangGraph 是更广泛的 LangChain 生态系统的一部分，该生态为构建模块化、可组合的 AI 系统提供了丰富的工具。

为了更直观地理解 LangGraph 有何用处，我们不妨用它来解决一个真实的业务难题。

解决方案概述

在一家风险投资公司中，投资人可以访问一个带有大量筛选条件的大型数据库，但一旦需要组合多重条件，查询就会变得既繁琐又缓慢。这可能会导致一些本应纳入投资视野的优质初创公司被漏掉。结果就是，团队要耗费大量时间去筛选最佳标的，甚至因此错失投资机会。

借助 LangGraph 和 Elasticsearch，我们能够使用自然语言进行过滤搜索，从而无需用户手动构建包含数十个筛选器的复杂请求。为了提高灵活性，工作流会根据用户输入在两种查询类型之间自动选择：

• 聚焦投资维度的查询：这类查询专注于初创公司的财务与融资维度，例如融资轮次、估值或营收等指标。示例：“查找已完成 A 轮或 B 轮融资、融资额在 800 万至 2,500 万美元之间且月收入超过 50 万美元的初创公司。”

• 聚焦市场维度的查询：这类查询侧重于行业垂直领域、目标市场或商业模式，帮助识别特定领域或地区中的投资机会。示例：“查找位于旧金山、纽约或波士顿的金融科技和医疗健康领域初创公司。”

为了让查询更稳健，我们会让 LLM 生成搜索模板，而不是直接构造完整的 DSL 查询。通过这种方式，你获得的始终是预期的查询结果，LLM 只需填入参数，而不必每次从头构建整条查询。

开始前的准备工作

• Elasticsearch API密钥

• OpenAPI API密钥

• Node 18 或更高版本

分步操作指南

在本节中，我们先来看一下这个应用的外观。为此，我们将使用 TypeScript，这是 JavaScript 的一个超集，添加了静态类型，使代码更可靠且更易维护，并能更早发现错误，同时又与现有 JavaScript 完全兼容。

节点的流程将如下所示：

上图由 LangGraph 生成，直观地呈现了工作流结构，包括各节点的执行顺序和它们之间的条件分支关系：

• decideStrategy：使用 LLM 分析用户查询，在“聚焦投资维度”与“聚焦市场维度”这两种专门搜索策略之间做出选择。

• PrepareInvestmentSearch：从查询中提取筛选值并构建一个强调财务和资金相关参数的预定义模板。

• prepareMarketSearch：同样会提取筛选条件，但重点是围绕市场、行业和地域背景，动态生成相应的搜索参数。

• ExecuteSearch：通过搜索模板将构建好的查询发送到 Elasticsearch，检索并返回所有匹配的初创公司文档。

• visualizeResults：将最终结果整理成清晰易读的摘要，呈现融资、行业、营收等关键创业公司属性。

该流程包括一个条件分支，相当于一条“if”语句，可根据用户输入决定使用投资还是市场搜索路径。这种由 LLM 驱动的决策机制让工作流具备自适应和上下文感知能力，后续章节将对这一机制进行更详细的说明。

LangGraph 状态

在查看各个节点之前，我们需要先理解节点之间的通信和数据共享方式。为此，LangGraph 可支持定义工作流状态。这个状态就是在各个节点之间传递的共享状态。

该状态相当于一个共享容器，在整个工作流中保存中间数据：从最开始的用户自然语言查询，到选定的搜索策略、为 Elasticsearch 准备好的参数、检索到的搜索结果，一直到最后的格式化输出，都会依次写入其中。

这种结构让每个节点都能读取和更新状态，确保从用户输入到可视化实现顺畅一致的信息流动。

设置应用程序

本节所有代码均可在 elasticsearch-labs 仓库 中找到。

在应用所在的文件夹中打开终端，并通过以下命令初始化一个 Node.js 应用：

现在我们可以为这个项目安装必要的依赖项：

• @elastic/elasticsearch：帮助我们处理 Elasticsearch 请求，例如数据摄取和检索。

• @langchain/langgraph：用于提供所有 LangGraph 工具的 JS 依赖项。

• @langchain/openai：适用于 LangChain 的 OpenAI LLM 客户端。

• @langchain/core：为 LangChain 应用提供基础构建模块，包括提示模板。

• dotenv：在 JavaScript 中使用环境变量所需的依赖项。

• zod: 对类型数据的依赖。

@types/node tsx typescript 允许我们编写和运行 TypeScript 代码。

现在创建以下文件：

• elasticsearchSetup.ts：将创建索引映射，从 JSON 文件加载数据集，并将数据摄取到 Elasticsearch。

• main.ts：将包含 LangGraph 应用。

• .env：用于存储环境变量的文件

在 .env 文件中，我们添加以下环境变量：

OpenAPI APIKey 不会直接在代码中使用，而是由 @langchain/openai 库在内部调用。

所有关于映射创建、搜索模板创建和数据集摄取的逻辑都可以在 elasticsearchSetup.ts 文件中找到。在接下来的步骤中，我们将重点关注 main.ts 文件。此外，您可以查看该数据集，以便更好地理解 dataset.json 中数据结构。

LangGraph 应用程序

在 main.ts 文件中，我们导入一些必要的依赖项来构建整个 LangGraph 应用。在此文件中，您还必须定义各个节点函数以及工作流状态的声明。在后续步骤中，我们会在 main 方法中完成这个图结构的声明。elasticsearchSetup.ts 文件中包含一组 Elasticsearch 辅助函数，我们会在后续步骤的各个节点中使用这些函数。

如前所述，LLM 客户端将根据用户的问题生成 Elasticsearch 搜索模板参数。

上面的方法会生成一张 png 格式的图结构图像，并在后台调用 Mermaid.ink API。当你希望通过一张带有样式的可视化图来直观了解应用中各个节点之间的交互时，这个功能就会非常有用。

LangGraph 节点

现在让我们看看每个节点的详细信息：

decideSearchStrategy 节点

decideSearchStrategy 节点分析用户输入，并确定是执行投资聚焦搜索还是市场聚焦搜索。它使用具有结构化输出模式（用 Zod 定义）的 LLM 对查询类型进行分类。在做出决策之前，它会通过聚合从索引中检索可用的筛选条件，确保模型掌握最新的行业、地域和融资等上下文信息。

为了提取过滤器可能的值并将其发送到 LLM，让我们使用聚合查询直接从 Elasticsearch 索引中检索它们。这个逻辑被分配到一个名为 getAvailableFilters 的方法中：

通过上述聚合查询，我们得到以下结果：

点击此处查看所有结果。

对于这两种策略，我们将使用混合搜索来检测问题的结构化部分（过滤器）和主观部分（语义）。以下是使用搜索模板的两个查询示例：

查看 elasticsearchSetup.ts 文件中详细的查询。在接下来的节点中，将决定使用这两个查询中的哪一个：

prepareInvestmentSearch 和 prepareMarketSearch 节点

两个节点都使用共享的辅助函数 extractFilterValues，该函数利用 LLM 来识别用户输入中提到的相关过滤器，例如行业、地点、资金阶段、商业模式等。我们正在使用这个架构来构建我们的 搜索模板。

根据检测到的意图，工作流会选择以下两种路径之一：

PrepareInvestmentSearch：构建以财务为导向的搜索参数，包括融资阶段、融资金额、投资者以及营收相关信息。您可以在 elasticsearchSetup.ts 文件中找到整个查询模板：

prepareMarketSearch：创建以行业、地域和商业模式为重点的市场驱动参数。在 elasticsearchSetup.ts 文件中查看完整查询：

executeSearch 节点

该节点从状态中获取生成的搜索参数，首先将其发送到 Elasticsearch，使用_render API来可视化查询以便调试，然后发送请求以检索结果。

visualizeResults 节点

最后，此节点显示 Elasticsearch 结果。

从程序角度来看，整个图结构如下所示：

正如你所见，我们有一个条件边，应用在此决定接下来运行哪个“路径”或节点。当工作流需要分支逻辑时，例如在多个工具之间进行选择或包含人机交互步骤，此功能非常有用。

了解了 LangGraph 的核心功能后，我们可以设置代码运行的应用程序：

将所有内容在 main 方法中整合起来，在名为 workflow 的变量中声明这个包含所有元素的图结构：

查询变量用来模拟用户在一个虚拟搜索框中输入的内容：

系统会从这句自然语言“查找已完成 A 轮或 B 轮、融资额在 800 万至 2,500 万美元之间且月收入高于 50 万美元的初创公司”中，自动抽取出所有筛选条件。

最后，调用主方法：

实施结果

对于这条输入，应用会选择聚焦投资维度的路径，由此我们可以看到 LangGraph 工作流生成的 Elasticsearch 查询，它会从用户输入中抽取出各类数值与区间。此外，我们还能看到应用了这些提取参数后实际发送到 Elasticsearch 的查询，以及最后由 visualizeResults 节点格式化输出的结果。

现在，我们再用这条查询来测试聚焦市场维度的节点：“查找位于旧金山、纽约或波士顿的金融科技和医疗健康初创公司”：

学习经验

在写作过程中我学到了：

• 我们必须向 LLM 提供筛选器的精确取值，否则就要完全依赖用户输入这些值。对于低基数，这种方法很好，但当基数很高时，我们需要通过一些机制来过滤结果

• 使用搜索模板比让大语言模型编写 Elasticsearch 查询能使结果更加一致，而且速度也更快

• 条件边是一种强大的机制，用于构建具有多个变体和分支路径的应用程序。

• 结构化输出在使用大型语言模型生成信息时非常有用，因为它能强制执行可预测且类型安全的响应。这不仅提高了整体可靠性，还减少了对提示词的误解。

通过混合检索结合语义和结构化搜索，可以产生更好、更相关的结果，在精确性和上下文理解之间取得平衡。

结论

在这个例子中，我们将 LangGraph.js 与 Elasticsearch 结合，创建一个动态工作流，能够解释自然语言查询并决定使用金融或市场聚焦的搜索策略。这种方法减少了手工查询的复杂性，同时提升了风险投资分析师的灵活性和准确性。

在本文中，我们将实现这一目标。我们将创建一个应用程序，它可以获取仪表盘的图像，分析映射，然后生成仪表盘，而无需接触 Kibana！

步骤：

1. 后台& 应用程序工作流程

2. 准备数据

3. LLM 配置

4. 应用功能

后台& 应用程序工作流程

我首先想到的是让 LLM 生成整个 NDJSON 格式的 Kibana保存对象，然后将它们导入 Kibana。

我们尝试了几种型号：

• 双子座 2.5 pro

• GPT o3 / o4-mini-high / 4.1

• 克劳德 4 号十四行诗

• Grok 3

• Deepseek (Deepthink R1)

至于提示语，我们从最简单的开始：

尽管我们看了一些简单的示例，并详细解释了如何建立每种可视化，但我们还是一无所获。如果您对这项实验感兴趣，请点击此处了解详情。

采用这种方法的结果是，在尝试将 LLM 生成的文件上传到 Kibana 时看到了这些信息：

这意味着生成的 JSON 无效或格式不当。最常见的问题是 LLM 生成不完整的 NDJSON、产生参数幻觉，或者返回普通 JSON 而非 NDJSON，无论我们如何努力去执行其他操作。

受这篇文章的启发--搜索模板比 LLM 自由式更有效--我们决定给 LLM 提供模板，而不是要求它生成完整的 NDJSON 文件，然后我们在代码中使用 LLM 给出的参数来创建适当的可视化。

申请工作流程如下：

为简单起见，我们将省略一些代码，但您可以在 本 笔记本上找到完整应用程序的工作代码 。

准备工作

在开始开发之前，您需要具备以下条件：

1. Python 3.8 或更高版本

2. VenvPython 环境

3. 运行的 Elasticsearch 实例及其端点和 API 密钥

4. 存储在环境变量 OPENAI_API_KEY 下的 OpenAI API 密钥：

准备数据

在数据方面，我们将保持简单，使用 Elastic 样本网络日志。您可以在此了解如何将这些数据导入群集。

每份文档都包含向应用程序发出请求的主机的详细信息，以及请求本身及其响应状态的信息。下面是一个文件示例：

现在，让我们抓取刚刚加载的索引的映射，kibana_sample_data_logs ：

我们将把映射与稍后加载的图像一起传递。

LLM 配置

让我们对 LLM 进行配置，使其使用结构化输出来输入图像，并接收包含我们需要传递给函数的信息的 JSON，以生成 JSON 对象。

我们安装依赖项：

Elasticsearch 将帮助我们检索索引映射。Pydantic 允许我们在 Python 中定义模式，然后要求 LLM 遵循这些模式，而LangChain框架则有助于更轻松地调用 LLM 和人工智能工具。

我们将创建一个 Pydantic 模式，以定义我们希望从 LLM 得到的输出。我们需要从图片中了解图表类型、字段、可视化标题和仪表盘标题：

对于图像输入，我们将发送一个我刚刚画好的仪表盘：

现在我们声明 LLM 模型调用和图像加载。该函数将接收 Elasticsearch 索引的映射和我们要生成的仪表盘图像。

通过with_structured_output ，我们可以使用 PydanticDashboard 模式作为 LLM 生成的响应对象。通过Pydantic，我们可以定义带有验证功能的数据模型，从而确保 LLM 输出与预期结构相匹配。

要将图像转换为 base64 并作为输入发送，可以使用在线转换器 或用代码完成。

LLM 已经掌握了 Kibana 面板的上下文，因此我们不需要在提示中解释所有内容，只需提供一些细节，确保它不会忘记自己正在使用 Elasticsearch 和 Kibana。

让我们来分析一下提示：

部门

原因

您是根据 Kibana 9.0.0 版本的图像分析 Kibana 仪表板的专家。

通过强化 Elasticsearch 和 Elasticsearch 版本，我们降低了 LLM 产生旧参数/无效参数的可能性。

您将获得一个仪表盘图像和一个 Elasticsearch 索引映射。

我们解释说，图片是关于仪表盘的，以避免法律硕士做出任何错误的解释。

下面是仪表盘所基于的索引的索引映射，使用它可以帮助你理解数据和可用字段。索引映射： {index_mappings}

提供映射至关重要，这样 LLM 才能动态选择有效字段。否则，我们就可能在这里硬编码映射，这太死板了，或者依靠图像包含正确的字段名，这也不可靠。

根据图像中可见的内容，只包含与每个可视化相关的字段。

我们必须添加这一增强功能，因为有时它会尝试添加与图像无关的字段。

这将返回一个包含要显示的可视化数组的对象：

处理 LLM 答复

我们在上创建了一个 2x2 面板仪表盘示例，然后使用 "获取仪表盘 API "将其导出为 JSON 格式，然后将面板存储为可视化模板（饼状、条状、度量），在这些模板中，我们可以替换部分参数，根据问题创建带有不同字段的新可视化。

您可以在此处查看模板 JSON 文件。请注意我们是如何用 {variable_name} 更改我们稍后要替换的对象值的。

根据 LLM 提供的信息，我们可以决定使用哪个模板，替换哪些值。

fill_template_with_analysis 将接收单个面板的参数，包括可视化的 JSON 模板、标题、字段和可视化在网格上的坐标。

然后，它会替换模板的值，并返回最终的 JSON 可视化。

为了简单起见，我们将为 LLM 决定创建的面板分配静态坐标，并生成如上图所示的 2x2 网格仪表盘。

根据 LLM 决定的可视化类型，我们将选择一个 JSON 文件模板，并使用fill_template_with_analysis 替换相关信息，然后将新面板追加到稍后用于创建仪表盘的数组中。

仪表盘准备就绪后，我们将使用 创建 仪表盘 API 将新的 JSON 文件推送到 Kibana 以生成仪表盘：

要执行脚本并生成仪表盘，请在控制台中运行以下命令：

最终结果将是这样的

结论

在将文本转化为代码或将图像转化为代码时，LLM 展示了其强大的视觉能力。仪表盘 API 还能将 JSON 文件转化为仪表盘，而通过 LLM 和一些代码，我们就能将图片转化为 Kibana 仪表盘。

下一步是通过使用不同的网格设置、仪表盘大小和位置来提高仪表盘视觉效果的灵活性。此外，为更复杂的可视化和可视化类型提供支持也是对该应用程序的有益补充。

我们将审查

• 生产最佳实践

  • 错误处理能力

  • 测试

• 无服务器环境

  • 在 Elastic Serverless 上运行客户端

  • 在功能即服务环境中运行客户端

您可以 在这里查看示例的源代码 。

生产最佳实践

Elasticsearch 中的错误处理

Node.js 中 Elasticsearch 客户端的一个有用功能是，它为 Elasticsearch 中可能出现的错误提供了对象，因此您可以用不同的方式验证和处理这些错误。

要查看全部内容，请执行此操作：

让我们回到搜索示例，处理一些可能出现的错误：

ResponseError 尤其是当答案为4xx 或5xx 时，即表示请求不正确或服务器不可用。

我们可以通过生成错误查询来测试这类错误，比如尝试在文本类型字段上进行术语查询：

默认错误：

定制错误：

我们还可以以某种方式捕捉和处理每种类型的错误。例如，我们可以在TimeoutError 中添加重试逻辑。

测试

测试是保证应用程序稳定性的关键。为了以一种与 Elasticsearch 隔离的方式测试代码，我们可以在创建集群时使用elasticsearch-js-mock库。

通过该库，我们可以实例化一个与真实客户端非常相似的客户端，但只需将客户端的 HTTP 层替换为模拟层，其他部分与原始客户端保持一致，就能满足我们的配置要求。

我们将安装 mocks 库和用于自动测试的AVA。

npm install @elastic/elasticsearch-mock

npm install --save-dev ava

我们将配置package.json 文件以运行测试。确保它看起来是这样的：

现在，让我们创建test.js 文件并安装我们的模拟客户端：

现在，为语义搜索添加一个模拟：

现在我们可以为代码创建一个测试，确保 Elasticsearch 部分始终返回相同的结果：

让我们进行测试。

npm run test

完成！从现在起，我们就可以测试我们的应用程序，100% 专注于代码而不是外部因素。

无服务器环境

如何在 Elastic Serverless 上运行客户端

我们介绍了在云端或内部运行 Elasticsearch 的情况；不过，Node.js 客户端也支持与Elastic Cloud Serverless 的连接。

Elastic Cloud Serverless 允许您创建一个项目，在这个项目中，您无需担心基础设施问题，因为 Elastic 会在内部处理这些问题，您只需担心您想索引的数据以及您想在多长时间内访问这些数据。

从使用角度来看，Serverless 将计算与存储分离，为搜索和索引提供了自动扩展功能。这样，您就可以只增长实际需要的资源。

客户端会进行以下调整，以连接到无服务器：

• 关闭嗅探，忽略任何与嗅探相关的选项

• 忽略配置中传递的除第一个节点外的所有节点，并忽略任何节点过滤和选择选项

• 启用压缩和 "TLSv1_2_method"（与为弹性云配置时相同）

• 为所有请求添加 "elastic-api-version "HTTP 头信息

• 默认使用 "云连接池"，而不是 "加权连接池

• 关闭卖方 "内容类型 "和 "接受 "标头，转而使用标准 MIME 类型

要连接无服务器项目，需要使用参数 serverMode：serverless。

如何在函数即服务环境中运行客户端

在示例中，我们使用了 Node.js 服务器，但您也可以使用功能即服务环境连接 AWS lambda、GCP Run 等功能。

另一个例子是连接像 Vercel 这样的服务，它也是无服务器的。您可以查看这个完整的示例，了解如何做到这一点，但搜索端点最相关的部分如下所示：

该端点位于 /api 文件夹中，从服务器端运行，因此客户端只能控制与搜索词相对应的 "文本 "参数。

使用 "功能即服务 "的意义在于，与全天候运行的服务器不同，功能只启动运行该功能的机器，一旦完成，机器就会进入休息模式，以减少资源消耗。

如果应用程序没有收到太多请求，这种配置会很方便；否则，成本会很高。您还需要考虑函数的生命周期和运行时间（在某些情况下可能只有几秒钟）。

结论

在本文中，我们学习了如何处理错误，这在生产环境中至关重要。我们还介绍了在模拟 Elasticsearch 服务的过程中测试应用程序的方法，无论集群的状态如何，这种方法都能提供可靠的测试，让我们专注于我们的代码。

最后，我们演示了如何通过配置 Elastic Cloud Serverless 和 Vercel 应用程序来启动完全无服务器堆栈。

在第一部分中，我们将回顾

• 环境

  • 前端、后端还是无服务器？

  • 连接客户端

• 编制文件索引

  • Elasticsearch 客户端

  • 语义映射

  • 批量助手

• 搜索数据

  • 词法查询

  • 语义查询

  • 混合查询

您可以 在这里查看示例的源代码 。

什么是 Elasticsearch Node.js 客户端？

Elasticsearch Node.js 客户端是一个 JavaScript 库，它将 Elasticsearch API 的 HTTP REST 调用放到了 JavaScript 中。这样就能更轻松地处理和使用帮助程序，简化批量编制文档索引等任务。

环境

前端、后端还是无服务器？

要使用 JavaScript 客户端创建搜索应用程序，我们至少需要两个组件：Elasticsearch 集群和运行客户端的 JavaScript 运行时。

JavaScript 客户端支持所有 Elasticsearch 解决方案（云、on-prem 和 Serverless），它们之间没有重大区别，因为客户端内部会处理所有变化，所以你不必担心使用哪一种。

不过，JavaScript 运行时必须从服务器运行，而不能直接从浏览器运行。

这是因为从浏览器调用 Elasticsearch 时，用户可能会获得敏感信息，如集群 API 密钥、主机或查询本身。Elasticsearch 建议永远不要将集群直接暴露在互联网上 ，而是使用一个中间层来抽象所有这些信息，这样用户只能看到参数。您可以在这里了解更多相关信息。

我们建议使用这样的模式：

在这种情况下，客户端只向服务器发送搜索条件和验证密钥，而服务器则完全控制查询和与 Elasticsearch 的通信。

连接客户端

首先，按照以下步骤创建一个 API 密钥。

按照前面的示例，我们将创建一个简单的 Express 服务器，并使用 Node.JS 服务器的客户端连接到该服务器。

我们将使用 NPM 初始化项目，并安装 Elasticsearch 客户端和Express。后者是一个在 Node.js 中调用服务器的库。使用 Express，我们可以通过 HTTP 与后端交互。

让我们初始化项目：

npm init -y

安装依赖项：

npm install @elastic/elasticsearch express split2 dotenv

让我来为你分析一下：

• @elastic/elasticsearch：它是 Node.js 的官方客户端

• 快递：它将使我们能够运行一个轻量级的 nodejs 服务器，以暴露 Elasticsearch

• split2： 将文本行分割成数据流。每次处理一行 ndjson 文件时非常有用

• dotenv：允许我们使用 .env 管理环境变量文件

创建 .env文件，并添加以下几行：

这样，我们就可以使用dotenv 软件包导入这些变量。

创建server.js 文件：

这段代码设置了一个基本的 Express.js 服务器，该服务器监听端口 3000，并使用 API 密钥进行身份验证，连接到 Elasticsearch 集群。它包括一个 /ping 端点，通过 GET 请求访问时，可使用 Elasticsearch 客户端的.info() 方法查询 Elasticsearch 集群的基本信息。

如果查询成功，会以 JSON 格式返回群集信息；否则会返回错误信息。服务器还使用 body-parser 中间件来处理 JSON 请求体。

运行文件，启动服务器：

node server.js

答案应该是这样的

现在，让我们查阅端点/ping ，检查 Elasticsearch 集群的状态。

编制文件索引

一旦连接起来，我们就可以使用语义_文本（用于语义搜索）和文本（用于全文查询）等映射对文档进行索引。有了这两种字段类型，我们还可以进行混合搜索。

我们将创建一个新的load.js 文件来生成映射并上传文件。

Elasticsearch 客户端

我们首先需要对客户端进行实例化和身份验证：

语义映射

我们将创建一个包含兽医院数据的索引。我们将保存主人、宠物和访问详情的信息。

我们要进行全文搜索的数据，如名称和描述，将以文本形式存储。类别中的数据，如动物的种类或品种，将以关键字的形式存储。

此外，我们还将把所有字段的值复制到一个 semantic_text 字段中，以便也能针对这些信息运行语义搜索。

批量助手

客户端的另一个优势是，我们可以使用批量助手来分批建立索引。通过批量辅助器，我们可以轻松处理并发、重试等问题，以及如何处理通过函数成功或失败的每个文档。

该助手的一个吸引人的特点是可以使用数据流。该功能允许您逐行发送文件，而不是将整个文件存储在内存中并一次性发送到 Elasticsearch。

要将数据上传到 Elasticsearch，请在项目根目录下创建名为 data.ndjson 的文件，并添加以下信息（也可以从此处下载包含数据集的文件）：

我们使用 split2 对文件行进行流式处理，而批量助手则将它们发送到 Elasticsearch。

上面的代码读取 .ndjson文件，并使用helpers.bulk 方法将每个 JSON 对象批量索引到指定的 Elasticsearch 索引中。它使用createReadStream 和split2 对文件进行流式处理，为每个文件设置索引元数据，并记录处理失败的文件。完成后，它会记录成功索引的项目数。

除indexData 功能外，您还可以使用 Kibana 直接通过用户界面上传文件，并使用上传数据文件用户界面。

我们运行文件，将文件上传到 Elasticsearch 集群。

node load.js

在 Elasticsearch 中搜索数据

回到server.js 文件，我们将创建不同的端点来执行词法、语义或混合搜索。

简而言之，这些类型的搜索并不相互排斥，而是取决于您需要回答的问题类型。

查询类型

用例

问题示例

词法查询

问题中的单词或词根很可能出现在索引文件中。问题与文件之间的标记相似性。

我在找一件蓝色运动 T 恤。

语义查询

问题中的词语不可能出现在文件中。问题与文件之间的概念相似性。

我在寻找适合寒冷天气穿的衣服。

混合搜索

问题包含词汇和/或语义成分。问题与文档之间的标记和语义相似性。

我想为海滩婚礼找一件 S 码的礼服。

问题的词汇 部分很可能是标题和说明的一部分，或者是类别名称，而语义 部分则是与这些领域相关的概念。蓝色可能是一个类别名称或描述的一部分，海滩婚礼不太可能是，但可以与亚麻服装在语义上相关。

词法查询 (/search/lexic?q=<query_term>)

词法搜索也称全文搜索，是指基于标记的相似性进行搜索；也就是说，经过分析后，将返回包含搜索标记的文档。

您可以点击此处查看我们的词法搜索实践教程。

我们测试：修剪指甲

请回答：

语义查询 (/search/semantic?q=<query_term>)

语义搜索与词汇搜索不同，它通过矢量搜索找到与搜索词含义相似的结果。

您可以点击这里查看我们的语义搜索实践教程。

我们进行测试：谁做了修脚？

请回答：

混合查询 (/search/hybrid?q=<query_term>)

混合搜索允许我们将语义搜索和词法搜索结合起来，从而获得两全其美的效果：既能获得标记搜索的精确性，又能获得语义搜索的意义接近性。

我们以 "谁做了修脚或牙科治疗？"

响应：

结论

在本系列的第一部分中，我们介绍了如何按照客户端/服务器最佳实践设置环境并创建带有不同搜索端点的服务器，以查询 Elasticsearch 文档。查看我们系列的第二部分，您将了解生产最佳实践以及如何在无服务器环境中运行 Elasticsearch Node.js 客户端。

Elasticsearch 允许用户使用开放推理 API 连接到 LLM，并支持 Amazon Bedrock、Cohere、Google AI、Azure AI Studio、HuggingFace - as a service 等提供商。

Ollama是一款允许您使用自己的基础设施（本地机器/服务器）下载和执行 LLM 模型的工具。在这里，您可以找到与 Ollama 兼容的可用型号列表。

如果你想托管和测试不同的开源模型，Ollama 是一个不错的选择，因为 Ollama 会处理好一切，让你不必担心每个模型的不同设置方式，也不必担心如何创建 API 来访问模型功能。

由于 Ollama API 与 OpenAI API 兼容，我们可以轻松集成推理模型，并使用 Playground 创建 RAG 应用程序。

准备工作

1. Elasticsearch 8.17

2. Kibana 8.17

3. Python

步长

1. 设置 Ollama LLM 服务器

2. 创建映射

3. 索引数据

4. 使用 Playground 提问

设置 Ollama LLM 服务器

我们将设置一个 LLM 服务器，使用 Ollama 将其连接到 Playground 实例。我们需要

• 下载并运行 Ollama。

• 使用 ngrok 通过互联网访问托管 Ollama 的本地网络服务器

下载并运行 Ollama

要使用 Ollama，我们首先需要下载它。Ollama 支持 Linux、Windows 和 macOS，因此只需 在这里 下载与你的操作系统兼容的 Ollama 版本即可 。安装好 Ollama 后，我们可以从支持的 LLM列表中选择一个模型。在本例中，我们将使用llama3.2 模型，这是一个通用的多语言模型。在设置过程中，您将启用 Ollama 的命令行工具。下载完成后，您就可以运行下面一行：

将输出

安装完成后，可以使用此命令进行测试：

我们来提个问题：

模型运行后，Ollama 会启用一个默认在"11434" 端口运行的 API。让我们按照官方文档，向该应用程序接口提出请求：

这就是我们得到的答复：

请注意，该端点的特定响应是流式响应。

使用 ngrok 将终端接入互联网

由于我们的端点在本地环境中运行，因此无法通过互联网从另一个点（如我们的弹性云实例）进行访问。ngrok允许我们公开提供公共 IP 的端口。在 ngrok 中创建账户，并按照官方设置指南进行操作。

安装并配置好 ngrok 代理后，我们就可以公开 Ollama 正在使用的端口：

注意： --host-header="localhost:11434"头 保证请求中的"Host" 头与"localhost:11434 匹配。"

执行该命令将返回一个公共链接，只要 ngrok 和 Ollama 服务器在本地运行，该链接就能正常工作。

在"Forwarding" 中，我们可以看到 ngrok 生成了一个 URL。留着以后用吧。

让我们再次尝试使用 ngrok 生成的 URL 向端点发出 HTTP 请求：

答复应与前一个答复类似。

创建映射

ELSER 端点

在本示例中，我们将使用 Elasticsearch 推理 API 创建一个推理端点。此外，我们还将使用ELSER生成嵌入。

在这个例子中，我们假设有一家药店出售两种药物：

• 需要处方的药物。

• 无需处方的药物。

这些信息将包含在每种药物的描述字段中。

LLM 必须对该字段进行解释，因此这就是我们要使用的数据映射：

字段text_description 将存储描述的纯文本，而作为语义_文本字段类型的semantic_field 将存储由 ELSER 生成的嵌入。

属性copy_to将把字段名和text_description 中的内容复制到语义字段中，以便为这些字段生成嵌入内容。

索引数据

现在，让我们使用_bulk API 为数据建立索引。

响应：

使用 Playground 提问

Playground是一款 Kibana 工具，可让您使用 Elasticsearch 索引和 LLM 提供商快速创建 RAG 系统。您可以阅读本文了解更多信息。

将当地的法律硕士与游乐场连接起来

我们首先需要创建一个连接器，使用我们刚刚创建的公共 URL。在 Kibana 中，转到搜索>Playground，然后点击"连接到 LLM" 。

此操作将显示 Kibana 界面左侧的菜单。在那里，点击"OpenAI" 。

现在我们可以开始配置 OpenAI 连接器了。

访问"Connector settings" ，并为 OpenAI 提供商选择"Other (OpenAI Compatible Service)" ：

现在，让我们配置其他字段。在本例中，我们将模型命名为"medicines-llm" 。在 URL 字段中，使用 ngrok 生成的 URL (/v1/chat/completions)。在"Default model" 字段中，选择"llama3.2" 。我们不会使用 API 密钥，因此只需输入任意文本即可：

点击"保存" 并点击"添加数据源" 添加索引药物：

好极了现在，我们可以使用本地运行的 LLM 作为 RAG 引擎访问 Playground。

在测试之前，让我们给代理添加更具体的指令，并将发送给模型的文件数量增加到 10 份，以便答案有尽可能多的可用文件。由于使用了 copy_to 属性，上下文字段将是semantic_field ，其中包括药品的名称和描述。

现在我们来问一个问题：没有处方可以购买氯硝西泮吗？看看会发生什么：

不出所料，我们得到了正确答案。

后续步骤

下一步是创建自己的应用程序！Playground 提供了一个 Python 代码脚本，你可以在自己的机器上运行，并根据自己的需要进行定制。例如，将其置于FastAPI服务器之后，创建一个由用户界面使用的 QA 药品聊天机器人。

点击 Playground 右上方的 "查看代码"按钮即可找到该代码：

然后使用Endpoints& API 密钥生成代码中所需的ES_API_KEY 环境变量。

本例的代码如下：

要使其与 Ollama 兼容，必须更改 OpenAI 客户端，使其连接到 Ollama 服务器，而不是 OpenAI 服务器。您可以在这里找到 OpenAI 示例和兼容端点的完整列表。

在调用完成方法时，将模型更改为 llama3.2：

让我们补充一个问题：我可以在没有处方的情况下购买氯硝西泮吗？ 至 Elasticsearch 查询：

此外，我们还在完成调用中打印了一些内容，以便确认我们将 Elasticsearch 结果作为问题上下文的一部分发送：

现在运行命令

pip install -qU elasticsearch openai

python main.py

你应该看到这样的内容：

结论

在本文中，当我们将 Ollama 等工具与 Elasticsearch 推论 API 和 Playground 结合使用时，我们可以看到它们的强大功能和多功能性。

经过几个简单的步骤后，我们就拥有了一个可运行的 RAG 应用程序，它可以聊天，使用 LLM 在我们自己的基础设施中运行，成本为零。这也使我们能够对资源和敏感信息有更多的控制权，此外，我们还可以使用各种模型来完成不同的任务。