序言
随着对大型语言模型(llm)的兴起，许多开发人员和组织都在忙着利用它的能力构建自己的应用程序。然而，当预训练的大语言模型开箱即用的表现不如预期时，关于如何提高LLM应用程序性能的问题就被提了出来。就目前来说，这个问题可以具象到：我们应该使用检索增强生成（RAG）还是模型微调（Fine-Tuning）来改进结果?
在深入研究之前，让我们揭开这两种方法的神秘面纱:
RAG: 这种方法将检索(或搜索)的能力集成到LLM文本生成中。它结合了检索系统(从大型语料库中获取相关文档片段)和LLM(使用这些片段中的信息生成答案)。本质上，RAG帮助模型“查找”外部信息以改进其响应。
微调: 这是采用预训练的LLM并在较小的特定数据集上进一步训练它以使其适应特定任务或提高其性能的过程。通过调优，我们根据数据调整模型的权重，使其更适合应用程序的独特需求。
RAG和微调都是增强基于llm的应用程序性能的强大工具，但它们处理优化过程的不同方面，这在选择一个而不是另一个时至关重要。
以前，我经常建议组织在进行微调之前先试验一下RAG。这是基于我的看法，即两种方法都获得了类似的结果，但在复杂性、成本和质量方面有所不同。我甚至用下图来说明这一点:
在这个图中，像复杂性、成本和质量这样的各种因素沿着一个维度表示。外卖呢?RAG更简单，更便宜，但其质量可能无法匹配。我的建议通常是:从RAG开始，评估它的性能，如果发现不足，就转向微调。
然而，我的观点后来发生了变化。我认为将RAG和调优视为实现相同结果的两种技术过于简单化了，只是其中一种比另一种更便宜，更简单。它们从根本上是不同的——不是“共线性”，而是“正交”——并且满足LLM应用程序的不同要求。
为了更清楚地说明这一点，考虑一个简单的现实类比:当被问到“我应该用刀还是用勺子吃饭?”，最合乎逻辑的反问是:“那你在吃什么?”我问朋友和家人这个问题，每个人都本能地反问，表明他们不认为刀和勺子是可以互换的，或者一个是另一个的劣等变体。
这是怎么回事?
在这篇博文中，我们将深入探讨不同维度上区分RAG和调优的细微差别，在我看来，这些细微差别对于确定特定任务的最佳技术至关重要。此外，我们将查看LLM应用程序的一些最流行的用例，并使用在第一部分中建立的维度来确定哪种技术可能最适合哪种用例。在这篇博文的最后一部分，我们将确定在构建LLM应用程序时应该考虑的其他方面。这其中的每一个都有自己的博客文章，因此我们只能在这篇文章的范围内简要地介绍一下。
你为什么要在意?
为适应大型语言模型选择正确的技术会对NLP应用程序的成功产生重大影响。选择错误的方法会导致:
- 模型在特定任务上表现不佳，导致输出不准确。
- 如果该技术没有针对您的用例进行优化，则会增加模型训练和推理的计算成本。
- 如果以后需要转向不同的技术，则需要额外的开发和迭代时间。
- 延迟部署应用程序并将其呈现在用户面前。
- 如果选择过于复杂的适应方法，则缺乏模型可解释性。
- 由于尺寸或计算限制，难以将模型部署到生产中。
RAG和微调之间的细微差别涵盖了模型体系结构、数据需求、计算复杂性等等。忽略这些细节可能会破坏你的项目时间表和预算
这篇博文的目的是通过清楚地列出每种技术的优势，避免浪费精力。有了这些见解，您就可以从第一天开始就采用正确的适应方法。详细的比较将使您能够做出最佳的技术选择，以实现您的业务和AI目标。本指南为工作选择正确的工具将使您的项目获得成功
提高性能的关键考虑因素
在我们选择RAG vs Fintuning之前，我们应该沿着一些维度评估我们的LLM项目的需求，并问自己一些问题。
我们的用例是否需要访问外部数据源?
在选择调优LLM还是使用RAG时，一个关键的考虑因素是应用程序是否需要访问外部数据源。如果答案是肯定的，那么RAG可能是更好的选择。
根据定义，RAG系统旨在通过在生成响应之前从知识来源中检索相关信息来增强LLM的能力。这使得该技术非常适合需要查询数据库、文档或其他结构化/非结构化数据存储库的应用程序。检索器和发电机组件可以优化以利用这些外部源。
相比之下，虽然有可能对LLM进行微调以学习一些外部知识，但这样做需要来自目标领域的大型标记的问答对数据集。该数据集必须在底层数据更改时更新，这使得频繁更改数据源变得不切实际。微调过程也没有明确地为查询外部知识所涉及的检索和推理步骤建模。
因此，总而言之，如果我们的应用程序需要利用外部数据源，那么使用RAG系统可能比仅仅通过调优来尝试“导入”所需的知识更有效和可伸缩。
我们是否需要修改模型的行为、写作风格或特定领域的知识?
另一个需要考虑的非常重要的方面是，我们需要多少模型来调整它的行为、它的写作风格，或者为特定领域的应用程序定制它的响应。
微调卓越的能力，以适应LLM的行为，具体的细微差别，音调，或术语。如果我们想让模型听起来更像医学专业人士，用诗意的风格写作，或者使用特定行业的行话，对特定领域的数据进行微调可以让我们实现这些定制。这种影响模型行为的能力对于与特定风格或领域专业知识保持一致至关重要的应用程序是必不可少的。
RAG虽然在整合外部知识方面很强大，但主要侧重于信息检索，并没有根据检索到的信息固有地调整其语言风格或领域特异性。它将从外部数据源中提取相关内容，但可能不会显示出经过微调的模型所能提供的细微差别或领域专业知识。
因此，如果我们的应用程序需要专门的写作风格或与特定于领域的本地语言和惯例进行深度对齐，那么调优提供了实现这种对齐的更直接的途径。它提供了与特定受众或专业领域真正产生共鸣所需的深度和定制，确保生成的内容感觉真实且消息灵通。
快速回顾
在决定使用哪种方法来提高LLM应用程序性能时，这两个方面是迄今为止需要考虑的最重要的方面。有趣的是，在我看来，它们是正交的，可以单独使用(也可以组合使用)。
然而，在深入研究用例之前，在选择方法之前，我们应该考虑几个关键方面:
抑制幻觉有多重要?
大语言模型的一个缺点是他们倾向于产生幻觉——编造没有现实基础的事实或细节。在准确性和真实性至关重要的应用程序中，这可能是非常有问题的。
通过将模型建立在特定领域的训练数据中，微调可以在一定程度上帮助减少幻觉。然而，当面对不熟悉的输入时，模型仍然可能产生响应。需要对新数据进行再培训，以不断减少虚假编造。
相反，RAG系统天生就不容易产生幻觉，因为它们的每个反应都是基于检索到的证据。在生成器构造答案之前，检索器从外部知识来源识别相关事实。这个检索步骤作为事实检查机制，降低了模型虚构的能力。生成器被限制为合成检索上下文支持的响应。
因此，在压制谎言和虚构的应用中，RAG系统提供了内置机制来最大限度地减少幻觉。在生成响应之前检索支持性证据使RAG在确保实际准确和真实的输出方面具有优势。
有多少有标签的训练数据可用?
当决定在RAG和微调之间进行选择时，要考虑的一个关键因素是我们可以处理的特定于领域或任务的标记训练数据的数量。
调整LLM以适应特定的任务或领域在很大程度上取决于可用标记数据的质量和数量。丰富的数据集可以帮助模型深入理解特定领域的细微差别、复杂性和独特模式，从而生成更准确和上下文相关的响应。然而，如果我们使用的是有限的数据集，那么微调所带来的改进可能是微不足道的。在某些情况下，缺乏数据集甚至可能导致过拟合，其中模型在训练数据上表现良好，但在看不见的或现实世界的输入上挣扎。
相反，RAG系统独立于训练数据，因为它们利用外部知识来源来检索相关信息。即使我们没有广泛的标记数据集，RAG系统仍然可以通过访问和合并来自外部数据源的见解来胜任工作。检索和生成的结合确保系统保持信息灵通，即使领域特定的训练数据是稀疏的。
从本质上讲，如果我们有丰富的标记数据来捕获领域的复杂性，微调可以提供更裁剪和精细的模型行为。但是在此类数据有限的场景中，RAG系统提供了一个健壮的替代方案，确保应用程序通过其检索功能保持数据知情和上下文感知。
数据是静态的还是动态的?
在RAG和调优之间进行选择时要考虑的另一个基本方面是数据的动态性。数据更新的频率有多高，模型保持最新的必要性有多大?
对特定数据集的LLM进行微调意味着模型的知识在训练时成为该数据的静态快照。如果数据经历频繁的更新、更改或扩展，这可能很快使模型过时。为了使LLM在这种动态环境中保持最新状态，我们必须经常对其进行再培训，这一过程既耗时又耗费资源。此外，每次迭代都需要仔细监控，以确保更新的模型在不同的场景中仍然表现良好，并且没有在理解中产生新的偏差或差距。
相反，RAG系统在具有动态数据的环境中具有固有的优势。它们的检索机制不断地查询外部源，确保它们用于生成响应的信息是最新的。随着外部知识库或数据库的更新，RAG系统无缝地集成了这些更改，在不需要频繁的模型再训练的情况下保持其相关性。
总而言之，如果我们正在努力应对快速发展的数据环境，RAG提供的敏捷性很难与传统的调优相匹配。通过始终保持与最新数据的连接，RAG确保生成的响应与信息的当前状态保持一致，使其成为动态数据场景的理想选择。
我们的LLM应用程序需要有多透明/可解释?
要考虑的最后一个方面是我们需要深入了解模型决策过程的程度。
对LLM进行微调，虽然非常强大，但操作起来就像一个黑盒子，使其反应背后的原因更加不透明。由于模型内化了数据集的信息，因此识别每个响应背后的确切来源或原因变得具有挑战性。这可能使开发人员或用户难以信任模型的输出，特别是在关键应用程序中，在这些应用程序中，理解答案背后的“为什么”是至关重要的。
另一方面，RAG系统提供了在单独调优的模型中通常找不到的透明度级别。考虑到RAG的两步性质——检索然后生成——用户可以窥视到这个过程。检索组件允许检查哪些外部文档或数据点被选择为相关的。这提供了一种有形的证据或参考线索，可以对其进行评估，以了解建立响应的基础。在需要高度问责制或需要验证生成内容的准确性的应用程序中，将模型的答案追溯到特定数据源的能力是非常宝贵的。
从本质上讲，如果透明度和解释模型响应的基础的能力是优先考虑的，那么RAG提供了一个明显的优势。通过将响应生成分解为不同的阶段并允许洞察其数据检索，RAG在其输出中培养了更大的信任和理解。
总结
在考虑这些维度时，在RAG和微调之间进行选择变得更加直观。如果我们需要倾向于获取外部知识和重视透明度，RAG是我们的首选。另一方面，如果我们正在使用稳定的标记数据，并旨在使模型更接近特定需求，则微调是更好的选择。
在下一节中，我们将看到如何基于这些标准评估流行的LLM用例。
Use cases
让我们来看看一些流行的用例，以及如何使用上述框架来选择正确的方法:
总结(在专门的领域和/或特定的风格)
**1. 需要外部知识吗?**对于以以前的摘要样式进行摘要的任务，主要数据源将是以前的摘要本身。如果这些摘要包含在静态数据集中，则几乎不需要持续的外部数据检索。但是，如果有一个经常更新的动态摘要数据库，并且目标是不断地使样式与最新条目保持一致，那么RAG在这里可能很有用。
**2. 需要模型调整吗?**这个用例的核心围绕着适应一个专门的领域或一个和/或一个特定的写作风格。微调特别擅长捕捉风格上的细微差别、音调变化和特定的领域词汇表，使其成为这个维度的最佳选择。
**3. 最小化幻觉的关键?**幻觉在大多数LLM申请中都是有问题的，包括总结。然而，在这个用例中，要摘要的文本通常作为上下文提供。与其他用例相比，这使得幻觉不那么令人担忧。源文本限制了模型，减少了想象中的虚构。因此，尽管事实的准确性总是可取的，但鉴于上下文基础，抑制幻觉是总结的较低优先级。
**4. 有培训数据吗?**如果有大量以前的总结，这些总结以模型可以从中学习的方式被标记或结构化，那么微调就成为一个非常有吸引力的选择。另一方面，如果数据集是有限的，并且我们依靠外部数据库进行风格对齐，RAG可以发挥作用，尽管它的主要优势不是风格适应。
**5. 数据有多动态?**如果先前摘要的数据库是静态的或不经常更新，则微调模型的知识可能会在较长时间内保持相关性。但是，如果摘要经常更新，并且需要模型不断地与最新的风格变化保持一致，那么由于RAG的动态数据检索功能，它可能具有优势。
**6. 需要透明度和可解释性?**这里的主要目标是风格一致性，所以特定摘要风格背后的“为什么”可能没有其他用例那么重要。也就是说，如果需要追溯并了解哪些先前的摘要影响了特定的输出，RAG提供了更多的透明度。不过，这可能是这个用例的次要问题。
建议:对于这个用例微调**似乎是更合适的选择。主要目标是风格对齐，这是微调的亮点。假设有相当数量的以前的总结可用于培训，微调LLM将允许深度适应所需的风格，捕捉领域的细微差别和复杂性。但是，如果摘要数据库是非常动态的，并且追踪影响是有价值的，那么可以考虑采用混合方法或倾向于RAG。
组织知识(即外部数据)问答系统
**1. 需要外部知识吗?**依赖于组织知识库的问答系统本质上需要访问外部数据，在这种情况下，是组织的内部数据库和文档存储。该系统的有效性取决于其从这些资源中挖掘和检索相关信息以回答查询的能力。考虑到这一点，RAG作为更适合这个维度的选择脱颖而出，因为它被设计为通过从知识来源检索相关数据来增强LLM功能。
**2. 需要模型调整吗?**根据组织及其领域的不同，可能需要模型与特定的术语、语气或约定保持一致。虽然RAG主要侧重于信息检索，但微调可以帮助LLM调整其对公司内部方言或其领域细微差别的反应。因此，对于这个维度，取决于特定的需求微调可能会发挥作用。
**3. 最小化幻觉的关键?**在这个用例中，由于大语言模型的知识限制，幻觉是一个主要问题。如果模型无法根据它所训练的数据回答问题，它几乎肯定会(部分或全部)恢复到编造一个看似合理但不正确的答案。
**4. 有培训数据吗?**如果组织有一个结构化和标记的先前回答问题的数据集，这可以支持微调方法。然而，并非所有的内部数据库都是为培训目的而标记或构建的。在数据没有整齐地标记或主要关注检索准确和相关答案的场景中，RAG无需大量标记数据集即可利用外部数据源的能力使其成为一个引人注目的选择。
**5. 数据有多动态?**组织中的内部数据库和文档存储可能是高度动态的，有频繁的更新、更改或添加。如果这种动态是组织知识库的特征，RAG提供了一个明显的优势。它不断地查询外部来源，确保其答案基于最新的可用数据。微调需要定期的再培训来跟上这些变化，这可能是不切实际的。
**6.需要透明度和可解释性?**对于内部应用程序，特别是在金融、医疗保健或法律等领域，理解答案背后的推理或来源可能是至关重要的。由于RAG提供了检索和生成的两步过程，因此它可以更清楚地了解哪些文档或数据点影响了特定的答案。这种可追溯性对于可能需要验证或进一步调查某些答案来源的内部涉众来说是无价的。
**建议:**对于这个用例 一个RAG系统似乎是更合适的选择。考虑到对组织不断发展的内部数据库的动态访问的需求，以及在回答过程中对透明度的潜在需求，RAG提供的功能很好地满足了这些需求。但是，如果非常强调裁剪模型的语言风格或适应特定于领域的细微差别，则可以考虑合并调优元素。
客户支持自动化
(即自动聊天机器人或帮助台解决方案，为客户查询提供即时响应)
**1. 需要外部知识吗?**客户支持通常需要访问外部数据，特别是在处理产品详细信息、帐户特定信息或故障排除数据库时。虽然许多查询可以用一般知识解决，但有些查询可能需要从公司数据库或产品faq中提取数据。在这里，RAG从外部来源检索相关信息的能力将是有益的。然而，值得注意的是，许多客户支持交互也基于预定义的脚本或知识，这可以通过微调模型有效地解决。
**2. 需要模型调整吗?**客户互动需要一定的语气、礼貌和清晰，也可能需要公司特定的术语。微调对于确保LLM适应公司的声音、品牌和特定术语，确保一致和品牌一致的客户体验尤其有用。
**3. 最小化幻觉的关键?**对于客服聊天机器人来说，避免虚假信息对于维护用户信任至关重要。当面对不熟悉的查询时，仅微调就会使模型容易产生幻觉。相反，RAG系统通过在检索到的证据中接地响应来抑制捏造。这种对事实来源的依赖使RAG聊天机器人能够最大限度地减少有害的谎言，并在准确性至关重要的情况下为用户提供可靠的信息。
**4. 有培训数据吗?**如果一家公司有客户互动的历史记录，那么这些数据对于调整是非常宝贵的。以前的客户查询及其解决方案的丰富数据集可用于训练模型，以便在将来处理类似的交互。如果这样的数据是有限的，RAG可以通过从外部来源(如产品文档)检索答案来提供一个备用方案。
**5. 数据有多动态?**客户支持可能需要解决有关新产品、更新政策或更改服务条款的查询。在产品阵容、软件版本或公司策略经常更新的场景中，RAG动态提取最新文档或数据库的能力是有利的。另一方面，对于更多的静态知识领域，微调就足够了。
**6. 需要透明度和可解释性?**虽然透明度在某些领域是必不可少的，但在客户支持方面，主要关注的是准确、快速和礼貌的回应。然而，对于内部监控、质量保证或处理客户纠纷，具有关于答案来源的可追溯性可能是有益的。在这种情况下，RAG的检索机制提供了一个额外的透明层。
建议:对于客户支持自动化混合方法**可能是最佳的。微调可以确保聊天机器人与公司的品牌、语气和一般知识保持一致，处理大多数典型的客户查询。然后，RAG可以作为一个补充系统，介入更动态或更具体的查询，确保聊天机器人可以从最新的公司文档或数据库中提取信息，从而最大限度地减少幻觉。通过整合这两种方法，公司可以提供全面、及时和品牌一致的客户支持体验。
Image by author
需要考虑的其他方面
如上所述，在决定是使用RAG还是微调(或两者都使用)时，还应该考虑其他因素。我们不可能深入研究它们，因为它们都是多方面的，并且不像上面的某些方面那样有明确的答案(例如，如果没有训练数据，则根本不可能进行微调)。但这并不意味着我们应该无视它们:
扩展性
随着组织的发展和需求的演变，所讨论的方法的可扩展性如何?考虑到RAG系统的模块化特性，它可能提供更直接的可伸缩性，特别是在知识库增长的情况下。另一方面，经常微调以适应扩展的数据集可能需要大量的计算。
时延和实时性要求
如果应用程序需要实时或接近实时的响应，请考虑每种方法引入的延迟。RAG系统需要在生成响应之前检索数据，与基于内部化知识生成响应的经过微调的LLM相比，RAG系统可能会引入更多的延迟。
维护与支持
考虑长远。哪个系统更符合组织提供一致维护和支持的能力?
RAG可能需要维护数据库和检索机制，而微调则需要一致的再训练工作，特别是在数据或需求发生变化的情况下。
稳健性和可靠性
每种方法对不同类型输入的鲁棒性如何?虽然RAG系统可以从外部知识来源中提取，并且可以处理广泛的问题，但是一个精心调整的模型可能会在某些领域提供更多的一致性。
道德及私隐问题
存储和从外部数据库检索可能会引起隐私问题，特别是如果数据是敏感的。另一方面，一个经过微调的模型，虽然不查询实时数据库，但仍然可能产生基于其训练数据的输出，这可能有其自身的伦理含义。
如果要保护本地数据，又想享受LLM的能力，那么最好的方式是用模拟的业务数据先做一套prompt模板。对于业务询问，还是经过大模型处理返回相应的agent内容。如，在本地输入“{xx部门} {2月份}的{销售额}是多少？”，大模型生成相应的结果，类似一条SQL指令：“select … ”。这个指令回到本地，本地有一个小模型来解决执行这个输出结果的指令，而它可以利用内网访问本地的业务数据库。这样既利用LLM的能力完成了对复杂的用户询问内容的理解，也避免了本地数据进入外网的LLM。
集成能力
组织可能已经有了一定的基础设施和其他业务系统。RAG和微调的集成能力会和具体现有系统的数据库、云资源和交互界面等相关，但总体上来说，RAG更白盒，集成相对容易。
用户体验
考虑最终用户和他们的需求。如果他们需要详细的、有参考依据的答案，RAG可能更可取。如果他们重视速度和特定领域的专业知识，那么一个经过微调的模型可能更合适。
成本
微调可能会很昂贵，特别是对于非常大的模型。但在过去的几个月里，由于QLoRA等参数高效技术，成本已经显著下降。建立RAG可能是一笔巨大的初始投资——包括集成、数据库访问，甚至可能是许可费用——但是还需要考虑对外部知识库的定期维护。
复杂度
微调很快就会变得复杂。虽然现在许多提供商都提供一键微调，我们只需要提供训练数据，但跟踪模型版本并确保新模型仍然全面表现良好是一项挑战。另一方面，RAG也会很快变得复杂。需要设置多个组件，确保数据库保持新鲜，并确保各个部分(如检索和生成)正确地组合在一起。
结论
正如我们所探讨的，在RAG和微调之间进行选择需要对LLM应用程序的独特需求和优先级进行细致的评估。没有放之四海而皆准的解决方案——成功在于使优化方法与任务的具体要求保持一致。通过评估关键标准——对外部数据的需求、调整模型行为、培训数据可用性、数据动态、结果透明度等等——组织可以在最佳的前进道路上做出明智的决定。在某些情况下，同时利用RAG和微调的混合方法可能是最优的。
关键是避免假设一种方法普遍优越。像任何工具一样，它们的适用性取决于手头的工作。方法和目标的不一致会阻碍进步，而正确的方法则会加速进步。当组织评估提升LLM应用程序的选项时，它必须抵制过度简化，不要将RAG和微调视为可互换的，并选择使模型能够满足其与用例需求一致的功能的工具。这些方法打开的可能性是惊人的，但可能性本身是不够的-执行是一切。工具都在这里——现在让我们把它们付诸实践。
原文：RAG vs Finetuning — Which Is the Best Tool to Boost Your LLM Application?
