查询+缓存 —— 用 Elasticsearch 极速提升您的 RAG 应用性能原创

在当今数据驱动的世界中，生成式人工智能正在重新定义我们与数据的互动方式。特别是在人工智能应用程序的演进中，基于搜索的技术发挥着不可或缺的作用。今天我要向大家展示一项革命性的技术，利用last search作为大型语言模型LLM的缓存层，我们能显著提高响应速度，降低成本，并提前验证生成式响应。让我们深入了解一下，看看这是如何实现的。以及它能为我们的RA应用带来哪些具体好处。我们先探讨使用lastd测实施LLM缓存层的三大好处。首先是显著提高响应速度。当用户反复询问相同或相似的问题时，我们无需再次调用大型语言模型来重复同样的回答，直接从缓存中获取即可。其次，这不仅提高了效率，还大大减少了LLM代币成本，因为每一次对LLM的调用都是有成本的。此外，通过预先缓存用户最长问的问题，我们可以在实际提问前对生成的AI响应进行预审，确保质量和准确性。接下来让我们看看将E作为缓存层的一个完整数据。首先，我们会查询elastic search,以查看相似度域值内是否存在先前缓存的问题，如果找到缓存命中，则将缓存的生成响应返回给用户，从而跳过对生成模型。

进行新调用的需要。如果没有缓存命中，则遵循正常的rag过程。将新生成的响应返回给用户后，提示和响应会缓存在last search中，以工将来使用。现在让我们来看一个具体的事例。首先，我们要确保一切从零开始。我们点击了清除缓存，以清除last search中的所有现有缓存。接下来确认清除缓存。虽然这是一个手动过程，但你完全可以根据时间戳或特定标签来自动淘汰缓存。现在我们的缓存已经清空了。

我们要开始第一个查询，我想看一部关于飞机的搞笑电影。输入查询后，你会看到elastic search几乎立即返回了与我们问题语义最相似的前5条评论。同时你也会注意到热宁图标正在处理中，此时我们正在等待生成师AI模型根据我们提供的电影评论文档生成一个推荐。我们的生成模型根据我们的请求和提供的电影评论返回了一个推荐。毫不意外，这部关于飞机的搞笑电影是airpla。现在我们来看看模型和我们的应用程序提供的一些信息。首先，智耐模型给出了推荐这部电影的理由。

应用来源是构建RA应用程序的一个关键方面，提供来源可以验证模型的回答，并为想要深入了解的用户提供方便。这里我们可以看到原始评论，帮助我们理解为什么模型推荐飞机。注意elastic search返回5个语义相似文档的时间，以及生成模型处理我们的请求并返回推荐所花费的时间。elastic search用了1.53秒，而生成模型用了19.22秒。接下来我们看看当我们询问一个语义上非常相似但措辞略有不同的问题时会发生什么？例如，我们问什么是有趣的飞机电影？结果是飞机再一次几乎立即因为我们的问题在语翼上足够接近我们之前缓存的问题，所以last search能够立即返回之前生成的答案，这次返回仅用了0.17秒。

与生成答案的初始时间相比，效率大大提升。此外，我们还节省了代币费用，因为无需再次使用生成模型。我们返回的一个重要指标是相似性分数，在本例中为0.95352，这表示与我们原始问题的计算距离。如果我们问的问题与缓存问题完全一样，得分将唯一。通过这个值，我们可以控制什么样的相似程度才能触发缓存命中找到最佳值，取决于你的具体用例。我们来看一个调整电影推荐器相似度分数的例子。当我们问我想看一部会让我哭的电影时会发生什么？对于那些还没有看过1980年电影飞机的人，这可能是个笑中带泪的选择，但显然不是我们所要找的那种悲伤。有趣的是，我们的缓存又命中了飞机，这显然不是一个合适的建议。那么发生了什么？首先，由于我们在演示开始时清除了缓存，所以我们的缓存中只有一个推荐。其次，我们的向量搜索使用的是近似KNN算法。简单来说，KNN就是K最近邻，意味着它会找到语意上最接近的邻居，在这个案例中是文档。在这里我们看到相似度得分下降到了0.89013。有时候数学上最接近的邻居可能并不符合我们的需要，就像这个例子中一样。这时Li stick search向量搜索中的相似性参数就显得尤为重要。如果我们增加查询的相似度阈值，可以确保缓存命中的问题与原问题更加接近，也就是说两者更相似。我们可以通过调整应用程序中的滑块来调整这个参数，让我们把它调高到0.92。现在通过右侧返回的elastic search文档和顶部的正在运行图标，我们可以看到没有缓存命中。因此我们将。

继续常规的辣都线。

我们检索与请求语义相似的评论，并将它们传递给生成模型以获取推荐。现在，我们得到了一个新的更合适的电影推荐，这个新的推荐和输入问题也将被缓存以供未来查询。最后，让我们进行一次测试，看看我们是否能得到一个符合情感要求的电影推荐。这次我们要找的是一部让我们感到悲伤而不是哭泣的电影。结果毫不意外，我们缓存命中的电影付出代价，它同样能让人哭泣。我们看到相似度得分为0.97489，非常接近我们的需求。

随着我们今天的演示接近尾声，我们来到了最后一个环节，性能分析，我们的电影推荐系统，一个用拍on编写的应用程序。通过last search a PM的强大功能，让我们能够深入了解性能的各个方面。虽然这是一个设计简洁的应用程序，但它仍然提供了丰富的数据，帮助我们理解每一个操作背后的性能细节。我们现在来看一下当缓存命中发生时，整个过程是多么的高效。一个简单的查询，从点击任务的cash check按钮到接收last search返回到缓存响应，整个往返过程仅用了150ms。让我们深入细节cash函数完成整个查询仅花费了145ms。其中elastic search执行KNN向量搜索并返回生成响应的时间为103ms，剩下的时间主要用于更新缓存文档的上次访问时间戳，这一步耗时41ms。相比之下，当没有缓存命中时，情况就大不相同了。整个过程耗时26秒。一开始初始缓存检查仅用了45ms。

接下来是向量搜索，用来找到与我们的请求语义最相似的5个评论。这一步用了1270ms，注意，这还包括了所有网络传输的时间。然后大语言模型处理我们的请求和包含的评论，生成推荐，这一步用了整整25秒。最后我们还有额外的时间用于更新缓存。这两种情况的对比清晰的展示了缓存的强大影响。有了last search作为LLM缓存层，我们不仅使得响应速度提高了15倍。还显著优化了整个流程的效率。通过今天的演示，我们见证了elastic search在性能优化和成本控制方面的卓越能力，无论是提高响应速度还是优化资源利用，Elastic search都提供了一个强有力的解决方案。感谢您的观看，希望这次演示能够为您提供有价值的见解。

如有任何问题，欢迎留言讨论。