作者：来自 Elastic Mark Puddick

学习如何使用 Groq 与 Elasticsearch 在毫秒级运行 LLM 查询和自然语言搜索。

Elasticsearch 具有与行业领先的 Gen AI 工具和提供商的原生集成。查看我们关于超越 RAG 基础的网络研讨会，或构建生产就绪的 Elastic Vector Database 应用。

为了为你的使用场景构建最佳搜索解决方案，现在就开始免费云试用，或在你的本地机器上尝试 Elastic。

---

在将大语言模型（ LLMs ）与 Elastic 结合使用时，其中一个挑战是我们通常需要非常快的结果。Elastic 在提供毫秒级响应时间方面没有问题。然而，当我们引入 LLM 调用时，性能可能会下降到不可接受的水平。这正是使用 Groq 的硬件推理在将 Elastic 与 LLM 结合时可以极大提升结果速度的地方。

Groq 是一家专注于在规模化场景下提供超低延迟、确定性 AI 推理的硬件和软件公司。其核心创新是 Groq Language Processing Unit（ LPU ）推理引擎，这是一种专门为以极高速度运行 LLMs 并保持可预测性能而定制设计的芯片架构。下面的链接提供了对 Groq 架构更详细的概述。

• Groq： 介绍 LPU
• Groq： 新的 LLM 推理基准

与传统基于 GPU 的系统不同，Groq 面向推理的专用架构可以以空前的吞吐量处理 token，同时响应时间的波动极小。这直接解决了通常会拖慢传统 LLM 调用的内存带宽瓶颈和调度开销，确保将 LLM 与 Elastic 的搜索结果集成时仍能保持实时的用户体验。Groq 通过 GroqCloud 提供这种行业领先的速度和性能，GroqCloud 是一个易于使用的 tokens-as-a-service 平台，并且通常具有最佳的性能价格比。

让我们先来看一个常见的智能查询层请求模式，以及我们可以从中获得哪些改进。

自然语言搜索

自从 LLMs 广泛应用以来，一个常见的搜索需求是能够使用自然语言进行特定领域搜索。一个简单的解决方法是在 RAG（检索增强生成）工作流中进行简单的语义搜索；然而，在大多数情况下，这并不能提供理想的结果。这主要是因为问题中存在需要转换为查询词的特定属性。为了解决这个问题，我们可以让 LLM 生成一个可执行的查询。然而，这仍然存在很大错误空间。最终，我们发现为工具提供特定领域的参数并与 LLM 配合使用可以得到最佳结果。更多信息请参见这篇博客。

为了定义 agent，我们将使用以下 prompt：

You are a helpful banking transaction agent. You help users search and analyze their banking transactions.

Current date: {current_date}

When users ask about transactions, use the appropriate tools:
- Use trans-search for finding specific transactions

For date references:
- "last month" = past 30 days from today
- "this month" = current month from 1st to today
- "last week" = past 7 days
- "this year" = January 1st of current year to today

By default set the make the to date today and the from date 1 year ago
Common categories: groceries, dining, gas, shopping, entertainment, utilities, healthcare, transportation, travel, subscriptions, insurance, phone, internet

例如：

这给我们带来了不错的结果，但由于 LLM 调用，我们的搜索时间从不到 100ms 增加到超过 1 秒。

为了解决这个问题，我们可以使用 Groq 的硬件推理在更短的时间内运行此查询。要运行这个示例，你需要注册一个 Groq 账户。

然后你可以从右上角菜单生成一个 API key：

我们在这里创建了这个工具，以便能够执行搜索。

克隆上述 repo 后，你需要更新 .env 指向 Groq：

OPENAI_API_KEY=gsk-........

OPENAI_API_BASE=https://api.groq.com/openai/v1

OPENAI_MODEL=openai/gpt-oss-20b

我们使用了 20b gpt-oss 模型，因为这可以提供准确的结果。对于这种类型的解决方案，使用更大的模型几乎没有任何收益。

现在，从测试情况来看，我们可以通过一个简单的 UI 使用 prompt 调用该工具运行：

为了测试时间，我们将运行该工具 50 次，并计算总响应、LLM 和 Groq 的平均值。我们将使用 ChatGPT-4.1-nano 和 Groq OSS-20b 模型。以下是此次测试的结果：

显然，通过使用 Groq 的硬件推理，我们可以将大约一秒的延迟降低。我们还使用了一个较小的模型，对于这个使用场景，它仍然提供了良好的结果。将响应时间从 1.5 秒降低到 250ms 后，通常可以满足许多组织的服务等级协议（SLA）要求。

Elastic Agent Builder

我们已经展示了这不仅可以用来加速 Elastic 的自然语言处理（NLP）搜索，还可以用来加速 Elastic Agent Builder。Agent Builder 最近发布了技术预览版，现在可以通过 Groq 端点连接 Groq。Agent Builder 在 Elastic 9.1+ 可用。我们可以使用之前使用的相同 API key。

以下是设置方法：

如果你使用 serverless，你需要从 Stack Management Connectors 页面创建一个新的 connector。首先，点击 AI Connector。

在下一个界面，选择 Groq 作为服务：

然后你可以设置要使用的模型。支持的模型列在 Groq 网站上。

如果你需要添加你的 organization ID，可以在 Settings 下展开 More options 添加。

如果你使用的是托管版 Elastic，在本文撰写时，你可以使用 Groq 上与 OpenAI 兼容的端点连接 Elastic。为此，选择 OpenAI 服务，并使用指向 Groq URL 的自定义 URL，如下所示：

一旦你使用上述任一方法设置了 Groq，进入 GenAI Settings 并将 Groq 设置为默认 GenAI。

Agent Builder 现在将默认使用 Groq connector。

让我们看看是否可以在 Agent Builder 中复制 NLP 搜索并使用 Groq。

为了创建 agents，我们通常需要为 agent 提供一些工具。在 Agent Builder 中，你可以使用内置工具或创建自己的工具。许多内置工具在此处有文档说明。

你可以使用这些工具进行交易搜索。LLM 将使用内置工具，如 index_explorer、generate_esql 和 execute_esql，它们会尝试找到相关的索引、检查结构，并执行生成的 Elasticsearch Query Language（ ES|QL ）查询。然而，这会带来一些挑战：

• 运行 agent 的时间会显著增加，因为会有多个推理步骤和工具执行。由于我们使用 Groq 获取更快的结果，这并不理想。
• 随着步骤数量和工具使用的增加，我们将消耗更多的 token，从而增加成本。

为避免上述问题，我们可以创建一个新工具，专门用于搜索交易。在本文撰写时，我们可以使用三种类型的工具：

• ES|QL 工具：允许你使用模板化的 ES|QL 定义查询。
• Index 搜索工具：允许你提供索引，LLM 创建查询。
• Model Context Protocol（MCP）工具：允许你通过 MCP 使用外部工具。

我们可以使用之前创建的 MCP 工具；然而，为了简单起见，我们将使用 index 搜索工具。你可以按如下方式设置：

创建工具后，我们可以在 Agent Builder 中创建一个 agent。为此，点击 Create agent 按钮，并按照下图填写信息，使用我们在原始示例中使用的 prompt：

我们还需要选择我们创建的工具作为 agent 的一部分：

然后在 Agent Builder UI 中测试，通过提出几个不同的问题：

通过 Agent Builder，我们实际上可以获得更多功能，因为它可以根据我们选择的额外内置工具创建额外查询。唯一的真正缺点是整体回答问题的时间可能更长，因为 LLM 能做更多操作。同样，这也是 Groq 可以提供帮助的地方。让我们来看一下在 Agent Builder 中使用 Groq 的性能差异。

Agent Builder 中 Groq 的性能

Agent Builder 的一个很棒的功能是它开箱即用支持 MCP 和 agent-to-agent（A2A）。我们可以利用这一点进行一些简单的基准测试。通过 A2A，我们可以替换 UI 和测试环境中的内置 agent。这使我们能够使用 Elastic LLM 和 Groq 中的几个不同模型测试 Agent Builder。

有一个更新的 repo，其中包含基准测试脚本。

为了测试，我们将提出问题：

我在汽油上花了多少钱？

测试结果如下所示：

	Groq -openai/gpt-oss-120b	Groq llama-3.3-70b-versatile	Elastic LLM
Min: 6.040s	6.04	4.433	15.962
Max: 9.625s	9.625	7.986	24.037
Mean: 7.862s	7.862	6.216	17.988
Median: 7.601s	7.601	6.264	17.027
StdDev: 1.169s	1.169	1.537	2.541

如你所见，内置的 Elastic LLM 表现不错，但 Groq 平均仍快了近 3 倍。你会注意到整体速度比外部应用慢得多。这是因为我们在 Agent Builder 中设置工具时仅使用了 index。因此，大部分时间花在了 Agent Builder 的推理上（即检查 index）。我们可以使用模板化的 ES|QL 工具替代 index，这将使结果更接近外部应用。

结论

显而易见，通过将 Groq 与 Elastic 结合使用，我们开启了一系列新的可能性，其中速度是一个重要因素。本文介绍了基本的智能查询示例，但还有许多其他应用，如图像理解、摘要和字幕生成，这些在速度提升 10 倍的情况下都变得可行。

原文：https://www.elastic.co/search-labs/blog/groq-elasticsearch