Elasticsearch 作为 GenAI 缓存层
作者：JEFF VESTAL，BAHA AZARMI
探索如何将 Elasticsearch 集成为缓存层，通过降低 token 成本和响应时间来优化生成式 AI 性能，这已通过实际测试和实际实施进行了证明。
随着生成式人工智能 (GenAI) 不断革新从客户服务到数据分析等各个领域，它也面临着一系列挑战，包括计算成本和响应时间。 通过使用 Elasticsearch 作为缓存层，我们可以正面解决这些问题，优化效率和效果。 让我们了解一下这种组合如何为部署生成式人工智能模型的固有复杂性提供真正的解决方案。
RAG 概述
检索器增强生成（Retriever-Augmented Generation），俗称 RAG，是自然语言处理中的一种高效机制。 它通过接受给定的提示或问题并从大型数据集中检索相关信息来进行操作。 对于 Elasticsearch，通常使用语义搜索来检索此结果。 然后，相关文档和提示会发送到生成式大语言模型 (LLM)，以创建易于人类使用的响应。 理想的最终结果是更准确但上下文更丰富的响应，比简单的基于关键字的答案提供更多深度。
大规模 GenAI 的问题
首先，存在每个生成调用的 token 成本问题。 token 是转换为模型可以理解的输入文本。 它们可以短至单个字符，也可以长至单词。 这很重要，因为你需要根据处理的 token 数量进行计费。 现在，想象一个场景，多个用户询问完全相同的问题或向模型提供类似的提示。 每个调用都需要花费 token，因此如果处理两个相同的提示，则成本实际上会加倍。
然后是响应时间的问题。 生成模型需要时间来接收数据、处理数据，然后生成响应。 根据模型大小、提示的复杂性、运行位置以及其他因素，此响应时间可能会增长到数秒。 这就像等待网页加载一样； 几秒钟的时间感觉就像是永恒，并可能阻止用户进一步参与。
Token 成本和响应时间这两个问题尤其重要，因为它们不仅影响运营效率，而且对用户体验和整体系统性能有直接影响。 随着对更新的实时、智能响应的需求不断增长，这些挑战不容忽视。 因此，我们发现自己正处于一个迫切需要寻找可扩展且高效的解决方案的时刻。
Elastic 作为缓存层
Elasticsearch 是一个向量数据库。 这意味着 Elasticsearch 不仅可以存储问题和答案的原始文本，还可以以数值向量格式存储它们的语义或 “基于含义” 的表示形式。 然后可以快速比较这些向量的相似性，从而提供一种稳健且有效的方法来识别已回答的相关问题。
实现这种智能匹配的一个关键方面是 k 最近邻 (kNN) 相似性参数。 借助 kNN，Elasticsearch 可以快速识别与新传入提示最相似的提示。 结果是一个快速而高效的检索过程，如果已经回答了足够相似的问题，则可以绕过资源密集的生成模型。 这会带来更快的响应时间，而无需支付 token 成本。 Elasticsearch 通过 similarity 参数在 knn 查询中启用了此功能。
要将 Elasticsearch 集成为缓存层，工作流程可以如下进行：出现新提示并查询 Elasticsearch，包括对提示进行向量化，以查找任何紧密匹配的现有向量。 如果找到匹配项，则返回先前生成的针对先前提示的答案。 如果没有，问题将经历通常的 RAG 流程，新生成的答案将存储回 Elasticsearch 以供将来使用。 你甚至可以为用户提供坚持要求 “新鲜” 答案的选项，从而在他们愿意的情况下绕过缓存。
Elasticsearch 可以被配置为类似于其他缓存系统中的 TTL 一样，自动清除旧数据。这确保缓存保持最新且有用。类似地，可以使用 Elasticsearch 的 Frozen Searchable Snapshot 功能来采用分层的方法。这将允许你构建一个庞大的缓存层，成本较低，用于不经常访问的数据，同时仍然比生成新响应更快。
还可以实施质量保证措施，例如某些响应的 “approved” 标志。 这允许人工审核员在向最终用户提供缓存的响应之前进行审查，从而增加了额外的可靠性。
通过将 Elasticsearch 实现为缓存层，你可以实现更具可扩展性、更高效且在许多方面更智能的系统，解决部署 RAG 等生成式 AI 模型时常见的限制。
评估语义相似性：容忍与抵抗 - Tolerance vs. Resistance
在利用 Elasticsearch 作为缓存层时，一个关键方面在于评估新提出的问题和之前存储的问题之间的语义相似性。 我们的缓存机制的有效性很大程度上取决于我们将新查询与现有查询匹配的程度。 该评估的核心有两个截然不同的概念：语义容忍和语义抵抗。
语义抵抗通常指系统或模型对语义相似性的严格度或抵抗力。在信息检索或自然语言处理的语境中，语义抵抗表示系统对于确定两段文本或查询是否在语义上相似的标准更为严格。
语义容忍度
语义容忍度（Semantic Tolerance），反映了召回率（Recall），是一个用更广泛的视角评估相似性函数的概念，允许问题之间更广泛的语义相似性。 这种宽大处理可以带来更多匹配，从而有可能减少 LLM 的计算负载。 然而，它也可能导致匹配不太精确，从而影响生成响应的准确性和相关性。
语义抵抗
另一方面，与精确性相一致的语义抵抗采用更严格的相似性函数，缩小了被视为 “匹配” 的范围。这种严格性往往会在可能更高的计算成本的情况下产生更准确和相关的匹配，因为较少的存储问题可能符合严格的相似性标准。
与语义宽容性和语义抵抗之间的平衡，类似于召回和精确性之间的权衡，对于优化 Elasticsearch 缓存层的性能和效果至关重要。通过微调 KNN 搜索中的 similarity 参数，可以在特定的操作需求和用户期望方面找到这种权衡，使缓存机制达到最佳状态。
用 HR 示例说明语义相似性
为了更好地理解语义相似性的细微差别，让我们考虑一下公司环境中的一个常见场景：员工询问有关家庭活动（例如孩子的婚礼）的带薪休假 (PTO) 政策。 这里有两个这样的查询：
- [A]：“I have a wedding in the family, my son is getting married. Am I eligible for some PTO?（我家里要举行婚礼，我的儿子要结婚了。我有资格获得一些 PTO 吗？”
- [B] : “My child is getting married soon, can I take some PTO for the event? （我的孩子即将结婚，我可以请 PTO 参加婚礼吗？）”
乍一看，很明显这两个查询都在寻求相同的信息，尽管措辞不同。 我们的目标是确保系统能够识别这些查询的语义接近度，并提供一致且准确的响应，而不管措辞有何差异。
相似度参数对语义容忍度和抵抗的影响
在这种情况下，语义匹配的有效性受 Elasticsearch 中 KNN 搜索中 similarirty 参数的选择的影响。该参数确定被视为匹配所需的最小相似度。我们可以通过检查两个具有不同相似性阈值的假设情景来说明该参数的影响：
- 情景 A（高阈值 - 抵抗力）：设置严格的相似度参数，比如说 0.95，封装语义抵抗力。这只允许具有高度相似性的查询检索缓存的答案，以提高精确度为代价来牺牲召回率。
- 情景 B（低阈值 - 容忍度）：设置更宽松的相似度参数，比如说 0.75，封装语义容忍度。这允许更广泛的语义相关查询检索缓存的答案，有利于召回而不是精确度。
通过比较这些情景，我们可以观察相似度参数如何影响语义抵抗和语义容忍之间的平衡，以及随后召回率和精确率之间的权衡。下表说明了在这些情景下，根据查询与有关孩子婚礼 PTO 的原始查询的假设相似度分数，不同查询可能如何处理：
| Query | Hypothetical Similarity Score | Retrieved in Scenario A (High Threshold - 0.95) | Retrieved in Scenario B (Low Threshold - 0.75) |
|---|---|---|---|
| Can I take PTO for my son's wedding? | 0.94 | No | Yes |
| Is there a leave policy for family events? | 0.80 | No | Yes |
| I need time off for my daughter's marriage, is that possible? | 0.97 | Yes | Yes |
| How do I apply for leave for personal family occasions? | 0.72 | No | No |
| What's the process to get time off for family ceremonies? | 0.78 | No | Yes |
| Can I get some days off for my sibling's wedding? | 0.85 | No | Yes |
该表演示了不同的相似性阈值如何影响缓存答案的检索，显示了响应准确性（场景 A）和计算效率（场景 B）之间的权衡。
用例
最简单的应用程序之一是在新查询出现时存储问题和响应。当用户与人工智能模型交互时，他们的问题以及生成的答案都会被缓存。 随着时间的推移，这会构建一个有机缓存，随着每次用户交互而变得更加丰富和多样化。 这是一个双赢的局面。 未来的用户查询不仅可以从这些预先存在的知识财富中受益，而且还可以节省 token 成本并减少延迟。
另一个引人注目的用例是向系统预加载常见问题的答案。 如果你已经在监控用户输入的查询类型，则可以针对常见问题预先生成响应并存储它们以供立即检索。 这有双重目的：它可以实现更快的响应时间，并提供一个评估人工智能响应的质量和一致性的平台。 可以将其视为具有常见问题 (FAQ) 部分，但该部分具有令人难以置信的动态性并针对用户需求不断优化。
从用户问题中识别趋势和常见主题开辟了另一条实用途径。 通过分析问题及其相应的回答，你可以将这些数据反馈到生成模型中以进行摘要报告甚至基于主题的分组。 你还可以对存储的提示使用情绪分析来评估用户交互的语气和情绪。 这提供了一个有价值的分析层，可以为产品开发、客户服务改进甚至营销策略提供信息。
测试一下
虽然特定的应用程序取决于你的最终用例，但可以从此 Github 存储库复制示例设置。
考虑一个涉及查询响应计时指标的场景。 在没有缓存的第一次运行中，假设用户查询需要 300 毫秒才能从 RAG 接收生成的答案。 现在，将该响应存储在 Elasticsearch 中后，会出现第二个类似的查询。这一次，由于我们的智能缓存层，响应时间降至仅 50 毫秒。 这表明系统响应能力得到了切实的改进 —— 这对任何实时应用程序来说都是一个福音，也证明了所获得的成本和时间效率。
在示例项目中，你将找到两个主要文件。
elasticsearch_llm_cache.py 是包含 Python 类 ElasticsearchLLMCache 的示例存储库，你的应用程序将在启动时实例化该类。 该类包含以下方法：
- create_index 这将在 Elasticsearch 中创建一个新的缓存索引（如果不存在）
- query 执行 kNN 搜索，包括对提示进行向量化。 它将返回相似度范围内的前 k 个相似文档。
- add 通过调用 _generate_vector 对提示进行向量化，并以文本形式对提示和生成响应以及向量化提示进行索引
elasticRAG_with_cache.py 是一个利用 elasticsearch_llm_cache 的 Streamlit 应用程序示例。
但这不仅仅与速度有关；还与速度有关。 这也与见解有关。 如果你使用 Elasticsearch 的 Python 应用程序性能监控 (APM) 库，你可以获得有关查询时间、资源利用率甚至错误率的丰富指标。 这些数据对于持续的系统优化非常宝贵，并且可以成为寻求微调性能的数据科学家和工程师的宝库。 监控这些指标不仅可以改善用户体验，还可以更有效地管理资源。
这是一条 APM 跟踪，显示输入新提示（没有匹配的缓存）时所花费的时间。 我们可以看到，在此示例中，示例应用程序中从用户点击提交到应用程序从 GenAI 模式返回响应的总时间花费了 7,150 毫秒，即大约 7 秒。
现在，该提示和响应已缓存在 Elasticsearch 中以供将来使用，下面的 APM 跟踪显示了何时回答类似的提示。 这里我们看到，因为找到了足够接近的提示，所以我们可以直接返回之前生成的响应。 现在，此快捷方式的总时间为 124 毫秒。
通过查看这些示例用例，你可以清楚地看出，将 Elasticsearch 实现为缓存层不仅仅是一项学术练习；它也是一项实践。 它对性能、成本和用户体验具有现实意义。
总结
通过利用 Elasticsearch 作为向量数据库的功能及其相似性参数，我们为响应速度更快、更具成本效益且可扩展的生成 AI 系统打开了大门。 无论是改善查询时间、实现细致的匹配，还是通过人工监督增加另一层可靠性，其好处都是显而易见的。
准备好开始了吗？ 查看 Python 库和示例代码并开始免费试用 Elastic Cloud。
原文：https://www.elastic.co/search-labs/elasticsearch-as-a-genai-caching-layer