RAG 或 Fine Tume - 为您的用例选择正确方法的权威指南

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