检索增强生成和自主托管LLM的预期结果 (Jiǎnsuǒ zēngqiáng shēngchēng hé zìzhǔ tuōgǔan LLM de yùqí jiéguǒ)

提升搜索引擎生成和自动化管理LLM的预期效果' (Tíshēng sōusuǒ yǐnqíng shēngchéng hé zìdòng huǎnliàng LLM de yùqí xiàoguǒ)

检索增强生成(Retrieval-augmented generation, RAG)是一种人工智能框架,旨在通过将外部知识库中检索到的信息与语言模型(LLM)集成,从而增强LLM的能力。鉴于RAG近期受到的关注度不断增加,可以合理得出结论,RAG现在是人工智能/自然语言处理(AI/NLP)领域中一个重要的主题。因此,让我们深入讨论当RAG系统与自托管的LLM配对使用时,可以期待什么。

在题为“通过检索增强生成提升性能”的博文中,我们探讨了检索到的文档数量如何提高LLM答案的质量。我们还描述了基于MMLU数据集的矢量化LLM,将其存储在诸如MyScale之类的矢量数据库中,与相关背景知识集成,而无需微调数据集,从而生成更准确的响应。

因此,关键点是:

RAG通过增加外部数据来填补知识空白,减少虚假信息。

在应用中使用外部LLM API可能会对数据安全性带来潜在风险,降低对系统的控制力,并且显著增加成本,特别是在用户量大的情况下。因此,引发的问题是:

如何确保更大的数据安全性并保持对系统的控制力?

简明的答案是使用自托管的LLM。这种方法不仅可以更好地控制数据和模型,还可以加强数据隐私和安全性,并提高成本效益。

为什么选择自托管的LLM?

基于云的即服务大型语言模型(例如OpenAI的ChatGPT)方便访问,并且可以为各种应用领域增添价值,提供即时可靠的访问。然而,公共LLM提供商可能违反数据安全性和隐私,还存在明显的控制力、知识泄漏和成本效益方面的问题。

注意:如果您对其中任何/所有的问题感到担忧,那么使用自托管的LLM是值得的。

在我们继续讨论的同时,让我们详细讨论这四个重要问题:

隐私

将LLM API与应用集成时,隐私必须是重要关注点。

为什么隐私是个问题?

对于这个问题的答案有几个要点,如下所示:

  • LLM服务提供商可能使用您的个人信息进行训练或分析,从而损害隐私和安全性。
  • 此外,LLM提供商可能会将您的搜索查询纳入到其训练数据中。

自托管的LLM可以解决这些问题,因为它们是安全的,您的数据永远不会暴露给第三方API。

控制力

像OpenAI GPT-3.5这样的LLM服务通常会审查暴力和咨询医疗建议等主题。您对被审查的内容没有控制权。然而,您可能希望开发自己的审查模型(和规则)。

如何采用满足您需求的审查模型?

从广义上讲,通过构建自定义过滤器对LLM进行定制微调优于使用提示,因为微调模型更加稳定。此外,自托管精细调校的模型可以提供修改和覆盖默认审查功能的自由,而这些功能是公共领域LLM所包含的。

知识泄漏

如上所述,使用第三方LLM服务器时,知识泄漏是一个问题,特别是如果您运行的查询包含专有商业信息。

注意:可能的知识泄漏是双向的,从提示到LLM,再返回查询应用。

如何防止知识泄漏?

总的来说,应使用自托管的LLM,而不是公共领域的LLM,因为您的专有业务知识库是其中最有价值的资产之一。

成本效益

关于自托管的LLM是否比云托管的LLM更具成本效益,这是一个有争议的问题。在文章“连续批处理如何使LLM推理的吞吐量提高23倍,并降低了p50延迟”中描述的研究报告中,明确指出通过正确平衡延迟和吞吐量,并采用先进的连续批处理策略,自托管的LLM更具成本效益。

注意:我们会在本文稍后的部分进一步阐述这个概念。

最大程度利用自托管的LLMs

LLMs需要大量的计算资源。它们需要大量的资源来进行推断和提供响应。添加RAG只会增加对计算资源的需求,因为它们可能会增加超过2,000个令牌以提高问题回答的准确性。不幸的是,这些额外的令牌会产生额外的成本,特别是当您与OpenAI等开源LLM API进行交互时。

通过自托管LLM,并使用矩阵和方法,例如KV缓存连续批处理,可以改善效率,尤其是当您的提示增加时,这些数据可能会有所改善。然而,对于大多数基于云的核心GPU计算平台,例如RunPod,它们按运行小时计费,而不是按令牌吞吐量计费:对于自托管的RAG系统来说,这是一个好消息,可以降低每个提示标记的成本。

下表说明了自托管的LLMs与RAG结合使用可以提供成本效益和准确性。总结如下:

  • 当达到最大程度时,成本仅为gpt-3.5-turbo的10%。
  • llama-2-13b-chat RAG管道中只使用10个上下文,成本为$0.04,含有1840个令牌,是没有上下文的gpt-3.5-turbo成本的三分之一。

表格:以美分计算的总成本比较

我们的方法论

我们使用text-generation-inference来运行一个未量化的llama-2-13b-chat模型,用于本文中的所有评估。我们还租用了一个配备1x NVIDIA A100 80GB的云Pod,每小时费用为$1.99。这样大小的Pod可以部署llama-2-13b-chat。值得注意的是,每个数字都使用第一个四分位数作为下限,第三个四分位数作为上限,使用箱线图直观地表示数据的分布。

注意:部署70B模型需要更多可用的GPU内存。

将LLM吞吐量推到极限

整体吞吐量应该是首要考虑的因素。我们将LLM从1个线程过载到64个线程,以模拟同时进行的查询。下图描述了随着提示变大,生成吞吐量如何下降。无论如何增加并发性,生成吞吐量基本在每秒400个令牌左右收敛。

添加提示会降低吞吐量。作为解决方案,我们建议使用不超过10个上下文的RAG,以平衡准确性和吞吐量。

测量更长提示的启动时间

对于我们来说,模型的响应速度至关重要。我们也知道,非正式语言建模的生成过程是迭代的。为了提高模型的响应时间,我们使用KV缓存将上一次生成的结果缓存起来,以减少计算时间。我们将这个过程称为使用KV缓存生成LLM时的“启动”。

注意:您始终需要在过程的最开始计算所有输入提示的键和值。

我们增加提示长度时,继续评估模型的启动时间。下图使用对数刻度来说明启动时间。

以下几点与此图有关:

  • 具有少于32个线程的启动时间是可以接受的;
  • 大多数样本的启动时间在1000毫秒以下。
  • 当我们增加并发性时,启动时间急剧上升。
  • 使用64个线程的示例的启动时间从1000毫秒左右开始,持续约10秒。
  • 这对于用户来说等待时间太长了。

我们的设置显示了在并发小于32个线程时的平均启动时间约为1000毫秒。因此,我们不建议过载LLM太多,因为启动时间将变得非常长。

评估生成延迟

我们知道,使用KV缓存的LLM生成可以分为启动时间和生成时间;我们可以评估实际的生成延迟,即用户等待在应用程序中看到下一个令牌所需的时间。

生成延迟比启动时间更稳定,因为启动过程中的较大提示难以在连续批处理策略中放置。因此,当您同时有更多的请求时,必须等待前一个提示被缓存后,才能显示下一个令牌。

另一方面,一旦缓存构建完成,生成就简单得多,因为KV缓存缩减了迭代次数,并且一旦批处理中有空位,生成就会被调度。延迟在不同的步骤上升,这些步骤随着更大的提示而提前到达,并且批处理饱和。更多的请求很快将耗尽LLM,增加限制同时处理更多的请求。

我们可以合理地预期生成延迟在90毫秒以下,如果不对上下文和并发性施加过大压力,甚至可能在60毫秒左右。因此,我们建议在此设置中使用五个上下文和32个并发性。

比较的成本

我们对这个解决方案的成本非常感兴趣。因此,我们使用上述收集的数据估算了成本,并为我们的流水线创建了以下成本模型:

  •  Cserv是云GPU服务器的每小时成本。
  •  Tboot和Tgen分别是每个请求的启动和生成时间(以毫秒为单位)。
  •  Nparallel计算并行处理的线程数量。

使用KV缓存和连续批处理可以提高系统的成本效率,通过正确的设置,可以将成本降低到的十分之一。对于最佳结果,建议使用32个线程的并发性。

接下来是什么?

我们提出的最后一个问题是:

我们从这些图表中可以得出什么教训,以及接下来做什么?

延迟和吞吐量之间的平衡

延迟和吞吐量之间总是有一个权衡的关系。估计您的日常使用量和用户对延迟的容忍度是一个好的起点。为了最大化每美元的性能,我们建议您在使用1个1x和或类似模型时期望32个并发性。这将为您提供最佳吞吐量、相对较低的延迟和一个合理的预算。您总是可以更改决策,但请记住始终首先估计您的用例。

模型精调:更长、更强大

您现在可以使用RAG系统对模型进行精调。这将帮助模型适应更长的上下文。有一些开源的存储库对LLM进行了长输入长度的精调,比如。使用更长的上下文进行精调的模型是良好的上下文学习者,比通过进行伸展的模型性能更好。

将MyScale与RAG系统配对:推理与数据库成本分析

通过将MyScale和RunPod的10个A100 GPU与MyScale(向量数据库)配对,您可以轻松配置一个Llama2-13B + Wikipedia知识库RAG系统,无缝满足多达100个并发用户的需求。

在我们结束讨论之前,让我们考虑运行这样一个系统的简单成本分析:

注意:

  • 这些成本是基于上述突出的成本计算的近似值。
  • 大规模的RAG系统可以显著提高LLM的性能,而向量数据库服务的额外成本不到15%。
  • 随着用户数量的增加,向量数据库的摊销成本将更低。

总而言之

直观地可以得出结论,RAG中的额外提示成本更高且速度更慢。然而,我们的评估显示这是一个现实世界应用的可行解决方案。此评估还考察了您在部署具有外部知识库的LLM时,可以期望的成本和整体性能,帮助您建立自己的成本模型。

最后,我们可以看到MyScale的成本效益使RAG系统更具可扩展性!

因此,如果您有兴趣评估RAG管道的QA性能,请加入我们的DiscordTwitter。您也可以使用RQABenchmark评估您自己的RAG管道!

我们将及时向您发布有关LLMs和向量数据库的最新发现!