共计 8471 个字符，预计需要花费 22 分钟才能阅读完成。

序幕

随着对大型语言模型 （LLM） 的关注浪潮，许多开发人员和组织正忙于利用大模型的能力来构建应用。但是，当开箱即用的预训练LLM没有按照预期或希望的结果执行时，问题成为了如何提高LLM应用的性能。最终，我们到了要回过头来问问自己的地步：我们到底应该使用检索增强生成 Retrieval-Augmented Generation (RAG)还是使用模型微调来改善结果？ 在深入研究之前，我们先揭开这两种方法的神秘面纱：

RAG：这种方法将检索（或搜索）的强大能力集成到LLM的文本生成中。它将检索系统（从大型语料库中获取相关文档片段）和LLM（使用这些片段中的信息生成答案）结合了起来。从本质上讲，RAG是帮助模型“查找”外部信息来改进其响应的内容。

Finetuning 微调：这是采用预训练的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应用程序性能时，这两个方面是迄今为止要考虑的最重要的方面。有趣的是，在我看来，它们是正交的，可以独立使用（也可以组合使用）。

但是，在深入研究用例之前，在选择方法之前，我们还应考虑一些关键方面：

抑制幻觉有多重要？

LLM的一个缺点是它们倾向于产生幻觉 – 编造没有现实基础的事实或细节。在准确性和真实性至关重要的应用中，这可能是非常成问题的。

微调可以通过将模型置于特定领域的训练数据中，在一定程度上帮助减少幻觉。但是，当面对不熟悉的输入时，该模型仍可能捏造响应。需要对新数据进行重新训练，以不断减少虚假捏造。

相比之下，RAG系统本质上不太容易产生幻觉，因为它们将每个反应建立在检索到的证据中。检索器在生成器构建答案之前从外部知识源识别相关事实。此检索步骤充当事实检查机制，降低模型的虚构能力。生成器被约束为合成检索到的上下文支持的响应。

因此，在抑制谎言和富有想象力的捏造至关重要的应用中，RAG 系统提供了内置机制来最大限度地减少幻觉。在生成响应之前检索支持证据使RAG在确保事实准确和真实的输出方面具有优势。

有多少标记的训练数据可用？

在 RAG 和微调之间做出决定时，要考虑的一个关键因素是我们可以处理的特定于领域或任务的标记训练数据的数量。

微调LLM以适应特定任务或领域在很大程度上取决于可用标记数据的质量和数量。丰富的数据集可以帮助模型深入了解特定域的细微差别、复杂性和独特模式，使其能够生成更准确且上下文相关的响应。但是，如果我们使用有限的数据集，微调带来的改进可能是微不足道的。在某些情况下，数据集不足甚至可能导致过度拟合，其中模型在训练数据上表现良好，但在看不见或现实世界的输入中挣扎。

相反，RAG 系统独立于训练数据，因为它们利用外部知识源来检索相关信息。即使我们没有广泛的标记数据集，RAG 系统仍然可以通过访问和整合来自其外部数据源的见解来胜任执行。检索和生成的结合可确保系统保持知情状态，即使特定于领域的训练数据稀疏也是如此。

从本质上讲，如果我们有大量的标记数据来捕捉域的复杂性，那么微调可以提供更量身定制和更精细的模型行为。但在此类数据有限的情况下，RAG 系统提供了一个强大的替代方案，确保应用程序通过其检索功能保持数据知情和上下文感知。

数据的静态/动态程度如何？

在 RAG 和微调之间进行选择时要考虑的另一个基本方面是我们数据的动态性质。数据的更新频率如何，模型保持最新状态的必要性如何？

在特定数据集上微调LLM意味着模型的知识在训练时成为该数据的静态快照。如果数据经历频繁的更新、更改或扩展，这会很快使模型过时。为了在这种动态环境中保持LLM的最新状态，我们必须经常对其进行重新培训，这个过程既耗时又耗费资源。此外，每次迭代都需要仔细监视，以确保更新后的模型在不同方案中仍然表现良好，并且不会在理解上产生新的偏差或差距。

相比之下，RAG 系统在具有动态数据的环境中具有固有的优势。他们的检索机制不断查询外部来源，确保他们为生成响应而提取的信息是最新的。随着外部知识库或数据库的更新，RAG 系统无缝集成这些更改，无需频繁的模型重新训练即可保持其相关性。

总之，如果我们正在努力应对快速发展的数据环境，RAG 提供了传统微调难以比拟的敏捷性。通过始终与最新数据保持连接，RAG 确保生成的响应与当前信息状态保持一致，使其成为动态数据场景的理想选择。

我们的LLM应用程序需要多透明/可解释？

要考虑的最后一个方面是我们需要深入了解模型决策过程的程度。

微调LLM虽然非常强大，但就像一个黑匣子一样运作，使其响应背后的推理更加不透明。随着模型将数据集中的信息内化，辨别每个响应背后的确切来源或原因变得具有挑战性。这可能会使开发人员或用户难以信任模型的输出，尤其是在理解答案背后的“原因”至关重要的关键应用程序中。

另一方面，RAG 系统提供了一定程度的透明度，这通常不是单独微调模型所不具备的。鉴于 RAG 的两步性质——检索和生成——用户可以窥视这个过程。检索组件允许检查哪些外部文档或数据点被选为相关文档或数据点。这提供了有形的证据或参考线索，可以对其进行评估，以了解建立响应的基础。在需要高度问责制的应用程序中，或者当需要验证生成内容的准确性时，追溯模型对特定数据源的答案的能力可能非常宝贵。

从本质上讲，如果透明度和解释模型响应基础的能力是优先事项，那么RAG提供了明显的优势。通过将响应生成分解为不同的阶段并允许深入了解其数据检索，RAG 可以促进对其输出的更大信任和理解。

总结

C 在考虑这些维度时，在 RAG 和微调之间进行选择变得更加直观。如果我们需要倾向于获取外部知识并重视透明度，RAG 是我们的首选。另一方面，如果我们使用稳定的标签数据，并旨在使模型更接近特定需求，那么微调是更好的选择。

I在下一节中，我们将了解如何根据这些标准评估流行的LLM用例。

使用案例

让我们看一些流行的用例，以及如何使用上述框架来选择正确的方法：

摘要（专业领域和/或特定风格）

1. 需要外部知识吗？对于以先前摘要的样式进行汇总的任务，主要数据源将是以前的摘要本身。如果这些摘要包含在静态数据集中，则几乎不需要连续的外部数据检索。但是，如果有一个经常更新的动态摘要数据库，并且目标是不断使样式与最新条目保持一致，那么 RAG 在这里可能很有用。

2. 是否需要模型调整？此用例的核心围绕适应专业领域或和/或特定的写作风格。微调特别擅长捕捉风格上的细微差别、音调变化和特定的领域词汇表，使其成为这个维度的最佳选择。

3. 对减少幻觉至关重要？幻觉在大多数LLM应用程序中都是有问题的，包括总结。但是，在此用例中，要摘要的文本通常作为上下文提供。与其他用例相比，这使得幻觉不那么令人担忧。源文本限制了模型，减少了富有想象力的捏造。因此，虽然事实的准确性总是可取的，但考虑到上下文基础，抑制幻觉是总结的较低优先级。

4. 可用的训练数据？如果有大量以前的摘要以模型可以从中学习的方式进行标记或结构化，那么微调将成为一个非常有吸引力的选择。另一方面，如果数据集有限，并且我们依靠外部数据库进行风格对齐，RAG 可以发挥作用，尽管它的主要优势不是风格适应。

5. 数据的动态性如何？如果先前摘要的数据库是静态的或不经常更新，则微调模型的知识可能会在更长的时间内保持相关性。但是，如果摘要经常更新，并且模型需要不断与最新的样式更改保持一致，则 RAG 可能因其动态数据检索功能而具有优势。

6. 需要透明度/可解释性？这里的主要目标是风格对齐，因此特定摘要风格背后的“原因”可能不如其他用例那么重要。也就是说，如果需要追溯并了解哪些先前的摘要影响了特定输出，RAG 提供了更多的透明度。不过，这可能是此用例的次要问题。

建议：对于此用例，微调似乎是更合适的选择。主要目标是风格对齐，这是微调闪耀的维度。假设有相当数量的先前摘要可用于培训，微调LLM将允许深度适应所需的风格，捕捉该领域的细微差别和复杂性。但是，如果摘要数据库非常动态并且有追溯影响的价值，则可以考虑混合方法或倾向于 RAG。

关于组织知识（即外部数据）的问答系统

1. 需要外部知识吗？依赖于组织知识库的问答系统本质上需要访问外部数据，在这种情况下，是组织的内部数据库和文档存储。该系统的有效性取决于其从这些来源获取和检索相关信息以回答查询的能力。鉴于此，RAG脱颖而出，成为此维度的更合适选择，因为它旨在通过从知识来源检索相关数据来增强LLM功能。

2. 是否需要模型调整？根据组织及其领域，可能需要模型与特定的术语、语气或约定保持一致。虽然RAG主要关注信息检索，但微调可以帮助LLM调整其对公司内部白话或其领域细微差别的反应。因此，对于这个维度，根据具体要求进行微调可能会发挥作用。

3. 对减少幻觉至关重要？幻觉是这个用例中的主要问题，因为LLM的知识截止。如果模型无法根据它所训练的数据回答问题，它几乎肯定会恢复到（部分或全部）组成一个合理但不正确的答案。

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和微调视为可互换的，并选择使模型能够实现其功能的工具，以符合用例的需求。这些方法解锁的可能性令人震惊，但仅靠可能性是不够的——执行就是一切。工具就在这里 – 现在让我们将它们投入使用。