如何使用-5-种强大技术将你的-AI-搜索扩展以处理-1000-万次查询

如何使用 5 种强大技术将你的 AI 搜索扩展以处理 1000 万次查询

原文：towardsdatascience.com/how-to-scale-your-ai-search-to-handle-10m-queries-with-5-powerful-techniques/

使用 AI 进行搜索自从 2022 年 LLM 的引入以来已经变得普遍。检索增强生成（RAG）系统迅速适应利用这些高效的 LLM 来改善问答。AI 搜索非常强大，因为它为用户提供快速访问大量信息的能力。例如，你看到 AI 搜索系统有

ChatGPT
法律 AI，例如Harvey
每当你进行 Google 搜索，Gemini 都会响应

实际上，无论你在哪里有 AI 搜索，RAG 通常都是其核心。然而，使用 AI 进行搜索远不止简单地使用 RAG。

在本文中，我将讨论如何使用 AI 进行搜索，以及如何从质量和可扩展性两个方面扩展你的系统。

这张信息图表突出了本文的内容。我将在整篇文章中讨论使用 AI 搜索、RAG、可扩展性和评估的系统。图片由 ChatGPT 提供。

动机

我写这篇文章的动机是，使用 AI 进行搜索已经迅速成为我们日常生活中的一个标准部分。你随处可见 AI 搜索，例如，当你用 Google 搜索某事时，Gemini 为你提供答案。以这种方式利用 AI 非常节省时间，因为我，作为提问者，不需要输入任何链接，我只需在我面前直接得到一个总结性的答案。

因此，如果你正在构建一个应用程序，了解如何构建这样的系统，理解其内部运作方式是很重要的。

构建你的 AI 搜索系统

在构建搜索系统时，有几个关键方面需要考虑。在本节中，我将介绍最重要的方面。

RAG

这张图展示了 NVIDIA 的 RAG 蓝图，使用他们的内部工具和模型。图中信息量很大，但主要点是 RAG 使用向量相似性检索最重要的文档，并将其提供给 LLM 以响应用户的问题。图片来自github.com/NVIDIA-AI-Blueprints/rag（Apache 2.0 许可证）

首先，您需要建立基础。任何 AI 搜索的核心组件通常是 RAG 系统。这是因为 RAG 是一种非常高效的数据访问方式，并且相对简单易设。实际上，您可以用很少的努力制作一个相当不错的 AI 搜索，这也是为什么我总是建议从实现 RAG 开始。

您可以利用端到端 RAG 提供商，如Elysia；然而，如果您想要更多的灵活性，创建自己的 RAG 管道通常是一个好选择。本质上，RAG 包括以下核心步骤：

将所有数据嵌入，这样我们就可以对其执行嵌入相似性计算。我们将数据分成固定大小的块（例如，500 个标记）。
当用户输入查询时，我们使用与步骤 1 中相同的嵌入引擎嵌入查询，并使用向量相似性找到最相似的片段。
最后，我们将这些片段以及用户问题一起输入到 LLM（如 GPT-4o）中，它为我们提供答案。

就这样。如果您实现了这一点，您已经创建了一个在大多数场景中表现相对良好的 AI 搜索。然而，如果您真的想做好搜索，您需要结合更多高级的 RAG 技术，这些技术我将在本文的后续部分介绍。

可扩展性

可扩展性是构建您的搜索系统的一个重要方面。我将可扩展性方面分为两个主要区域：

响应时间（用户等待答案的时间）应尽可能低。
服务器正常运行时间（您的平台正常运行的时间百分比）应尽可能高。

响应时间

您必须确保您能够快速回复用户的查询。使用标准的 RAG 系统，这通常不是问题，考虑到：

您的数据集在之前已经嵌入（在用户查询期间不占用时间）。
将用户查询嵌入几乎瞬间完成。
执行向量相似性搜索也几乎是瞬间的（因为计算可以并行化）

因此，LLM 的响应时间通常是决定 RAG 性能快慢的决定性因素。为了最小化这个时间，您应该考虑以下因素：

使用响应时间快的 LLM。
- GPT-4o/GPT-4.1的速度略慢，但 OpenAI 通过GPT-5大幅提高了速度。
- Gemini flash 2.0 模型一直都非常快（这里的响应时间快得令人难以置信）。
- Mistral 还提供快速 LLM 服务。
实现流式传输，这样您就不必等待所有输出标记生成后再显示响应。

流式传输的最后一个要点非常重要。作为一个用户，我讨厌在没有收到任何关于正在发生什么的反馈的情况下等待应用程序。例如，想象一下在 Cursor 代理完成大量更改之前，屏幕上什么都没有的情况。

正因如此，流式传输，或者至少在等待时向用户提供一些反馈，是极其重要的。我在下面的引语中总结了这一点。

通常不是关于响应时间作为一个数字，而是关于用户的感知响应时间。如果您用反馈填满用户的等待时间，用户就会感觉到响应时间更快。

还需要考虑的是，当您扩展和改进您的 AI 搜索时，您通常会添加更多组件。这些组件不可避免地会花费更多时间。然而，您始终应该寻找并行化操作。对您的响应时间最大的威胁是顺序操作，并且它们应该减少到绝对最小。

可用性

在托管 AI 搜索时，可用性也很重要。您基本上必须始终有一个服务在运行，这在处理不可预测的 LLM 时可能很困难。我写了一篇关于确保 LLM 应用程序可靠性的文章。如果您想了解更多关于如何使您的应用程序健壮的信息：

如何确保 LLM 应用程序的可靠性

确保您的搜索服务具有高可用性的最重要方面是：

对所有涉及 LLM 的内容进行错误处理。当您进行数百万次 LLM 调用时，事情可能会出错。可能是
- OpenAI 内容过滤
- 令牌限制（这在某些提供商中很难增加）
- LLM 服务速度慢，或者他们的服务器宕机
- …
有备份。无论您在哪里有 LLM 调用，都应该有一个或两个备用提供商准备在出现问题时代替。
部署前的适当测试

评估

当您构建 AI 搜索系统时，评估应该是您的首要任务之一。如果您无法测试搜索并找出您做得好的地方和做得不好的地方，那么继续构建功能就没有意义了。我已经就这个主题写了两篇文章：如何开发强大的内部 LLM 基准和如何使用 LLM 进行强大的自动评估。

总结来说，我建议您采取以下措施来评估您的 AI 搜索并保持高质量：

与提示工程平台结合，对提示进行版本控制，在新提示发布前进行测试，并运行大规模实验。
定期分析上个月的用户查询。标注哪些成功了，哪些失败了，以及为什么会出现这种情况。

我会根据错误的原因将出错的查询分组。例如：

用户意图不明确
LLM 提供商的问题
检索到的上下文没有包含回答查询所需的信息。
…

然后开始解决导致用户查询失败的最紧迫问题。

提高您 AI 搜索的技术

您可以利用许多技术来提高您的 AI 搜索。在本节中，我将介绍其中的一些。

上下文检索

这种技术最初是由 Anthropic 在 2024 年引入的。如果您想了解更多细节，我也写了一篇关于上下文检索的详细文章。

下面的图突出了上下文检索的流程。您所做的是，您仍然维护您在 RAG 系统中拥有的向量数据库，但现在您还结合了一个 BM25 索引（关键字搜索）来搜索相关文档。这效果很好，因为有时用户使用特定的关键字进行查询，而 BM25 比向量相似性搜索更适合这种关键字搜索。

此图突出了上下文检索系统。您仍然包括传统 RAG 中的向量数据库，但您还额外添加了 BM25 来检索相关文档。然后您将来自向量相似性和 BM25 检索到的文档结合起来，最后将问题和检索到的文档输入到 LLM 中进行响应。图片由作者提供。

RAG 之外的 BM25

另一个选项与上下文检索非常相似；然而，在这种情况下，您在 RAG 之外执行 BM25（在上下文检索中，您执行 BM25 来检索 RAG 最重要的文档）。考虑到用户有时将您的 AI 搜索作为基本的关键字搜索，这也可以是一种强大的技术。

然而，在实施此方案时，我建议开发一个路由代理，以检测我们是否应该直接使用 RAG 或 BM25 来回答用户查询。如果你想了解更多关于创建 AI 路由代理或一般构建有效代理的信息，Anthropic 已经撰写了一篇关于该主题的广泛文章。

代理

代理是 LLM 空间中的最新热点。然而，它们不仅仅是炒作；它们还可以用来有效地提高你的 AI 搜索。例如，你可以创建子代理来查找相关材料，类似于使用 RAG 检索相关文档，但不需要代理自己浏览整个文档。这是 OpenAI、Gemini 和 Anthropic 的深度研究工具部分工作原理，并且是执行 AI 搜索的一种极其有效（尽管昂贵）的方法。你可以在这里了解更多关于 Anthropic 如何使用代理构建其深度研究的信息。