序言

 

随着对大型语言模型（LLMs）的兴趣浪潮涌动，许多开发人员和组织正在忙于构建利用其强大力量的应用程序。然而，当预训练的LLMs无法按预期或希望的方式执行时，如何提高LLM应用程序的性能成为一个问题。最终，我们会问自己一个问题：我们应该使用检索增强生成(RAG)还是模型微调来改善结果？

在深入研究之前，我们先来揭开这两种方法的神秘面纱：

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

  

微调：这是将预训练的LLM进一步训练以适应特定任务或改善性能的过程。通过微调，我们根据数据调整模型的权重，使其更加适应我们应用程序的独特需求。

  

RAG和微调都是增强LLM应用程序性能的强大工具，但它们处理优化过程的不同方面，对于选择一个方法而言，这一点至关重要。

以前，我经常建议组织在深入微调之前先尝试RAG。这是基于我认为这两种方法都能实现类似的结果，但在复杂性、成本和质量方面有所不同。我甚至用这样的图示来说明这一点：

  

在这个图示中，复杂性、成本和质量等各种因素沿着一个维度表示。结论是：RAG更简单、成本更低，但其质量可能无法匹配。我的建议通常是：从RAG开始，评估其性能，如果不足的话，再转向微调。

然而，我的观点已经发生了变化。我相信将RAG和微调视为两种达到相同结果的技术，其中一种只是比另一种更便宜和更简单的观点是过于简单化了。它们在本质上是不同的——而不是共线的——并且满足LLM应用程序的不同需求。

为了让这一点更清楚，考虑一个简单的现实世界的类比：当面临问题，“我应该用刀还是勺子吃饭？”时，最合乎逻辑的反问是：“那你吃什么？”我问朋友和家人这个问题，每个人本能地回答了这个反问，表明他们不认为刀子和勺子是可以互换的，也不认为一个是另一个的劣等变体。

这是关于什么的？

 

在这篇博文中，我们将深入探讨区分RAG和微调的各个维度，这些维度在我看来对确定特定任务的最佳技术至关重要。此外，我们将研究LLM应用程序的一些最流行的用例，并使用在第一部分确定的维度来确定哪种技术最适合哪种用例。在本博文的最后一部分，我们将识别在构建LLM应用程序时应考虑的其他方面。每个方面都可能值得一篇博文，因此我们只能在本文的范围内简要触及这些方面。

 

为什么你应该关心？

 

选择适合的技术来适应大型语言模型对于你的自然语言处理应用的成功有重大影响。选择错误的方法可能会导致以下问题：

• 模型在特定任务上性能差，导致输出不准确。
• 如果技术没有针对你的用例进行优化，模型训练和推理的计算成本增加。
• 如果你之后需要转向其他技术，会增加开发和迭代时间。
• 应用部署和用户面前的时间延迟。
• 如果选择过于复杂的适应方法，模型的可解释性会受到限制。
• 由于大小或计算约束，将模型部署到生产环境可能会困难。

RAG和微调之间的细微差别涉及模型架构、数据要求、计算复杂度等方面。如果忽视这些细节，可能会拖慢项目的进度和预算。

本博客旨在通过清晰地阐述每种技术的优势来避免浪费努力。借助这些见解，你可以从一开始就选择适当的适应方法并快速启动项目。详细的比较将为你提供选择最佳技术以实现业务和人工智能目标的能力。选择正确工具的指南将为你的项目的成功做好准备。

现在就深入探讨吧！

 

提升性能的关键考虑因素

 

在选择RAG和微调之前，我们应该根据某些维度评估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在其输出中培养了更高的信任和理解。

总结

考虑到这些方面，从RAG和微调之间进行选择更加直观。如果我们需要倾向于访问外部知识并重视透明度，RAG是我们的首选。另一方面，如果我们正在使用稳定标记数据并希望将模型更紧密地适应特定需求，微调是更好的选择。

在下一节中，我们将看到如何基于这些标准来评估流行的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系统由于其模块化的性质，尤其在知识库增长时，可能会提供更简单的可扩展性。另一方面，经常对模型进行调整以满足不断扩大的数据集可能需要大量计算资源。

 

延迟和实时要求

 

如果应用程序需要实时或接近实时的响应，请考虑每种方法引入的延迟。相对于根据内部知识生成响应的经过精细调整的LLM，涉及在生成响应之前检索数据的RAG系统可能引入更多延迟。

 

维护和支持

 

考虑长期效果。哪种系统与组织提供持续维护和支持的能力更为匹配？RAG可能需要对数据库和检索机制进行维护，而经过精细调整可能需要持续的重新培训工作，特别是如果数据或需求发生变化时。

 

强健性和可靠性

 

每种方法对不同类型输入的适应能力如何？虽然RAG系统可以从外部知识源中获取信息，并且可能能够处理广泛的问题，但经过良好调整的模型可能在某些领域提供更大的一致性。

 

伦理和隐私问题

 

存储和检索外部数据库的过程可能引发隐私问题，特别是如果数据是敏感的。另一方面，经过精细调整的模型虽然不会查询实时数据库，但可能仍然根据其训练数据产生输出，这可能具有其自身的伦理影响。

 

与现有系统的整合

 

组织可能已经在部署某些基础设施。RAG或精细调整与现有系统的兼容性——无论是数据库、云基础设施还是用户界面——都会对选择产生影响。

 

用户体验

 

考虑最终用户及其需求。如果他们需要详细的、有参考支持的答案，RAG可能是更好的选择。如果他们看重速度和领域专业知识，经过精细调整的模型可能更合适。

 

成本

 

精细调整可能会变得昂贵，特别是对于非常大的模型而言。但在过去几个月中，由于诸如QLoRA之类的参数高效技术，成本已经显著下降。设置RAG可能需要巨额的初期投资——涉及整合、数据库访问，甚至可能还有许可费用——并且还要考虑定期维护外部知识库。

 

复杂性

 

精细调整可能迅速变得复杂。虽然现在许多提供商提供一键式精细调整，我们只需要提供训练数据，但跟踪模型版本并确保新模型在整体上仍然表现良好是具有挑战性的。另一方面，RAG也可能迅速变得复杂。需要安装多个组件，确保数据库保持更新，并确保检索和生成等部件完全合适。

 

结论

 

正如我们所探讨的，选择RAG和精细调整之间需要对LLM应用程序的独特需求和优先事项进行细致评估。没有一种通用的解决方案；成功在于将优化方法与任务的具体要求相协调。通过评估关键标准——对外部数据的需求、调整模型行为、可用的训练数据、数据动态、结果透明性等等——组织可以对未来的最佳路径做出明智的决策。在某些情况下，充分利用RAG和精细调整的混合方法可能更为理想。

关键是避免假设某种方法普遍优越。像任何工具一样，它们的适用性取决于手头的工作。方法和目标不匹配可能阻碍进展，而正确的方法则能够加速进展。当一个组织评估提升LLM应用程序的选择时，它必须抵制过度简化，不能将RAG和精细调整视为可互换的工具，并选择能够使模型满足用例需求的工具。这些方法解锁的可能性是惊人的，但单单可能性是不够的——执行才是关键。工具已经在这里——现在让我们投入使用。

 Heiko Hotz是NLP London的创始人，是一家AI咨询公司，帮助组织实施自然语言处理和对话式AI。在技术行业拥有15年的经验，Heiko是利用AI和机器学习解决复杂业务挑战的专家。

原文。经授权转载。

[Heiko Hotz](https://www.linkedin.com/in/heikohotz/) 是 NLP London 的创始人，这是一家AI咨询公司，帮助组织实施自然语言处理和对话式AI。在科技行业拥有15年以上的经验，Heiko 是利用AI和机器学习解决复杂商业挑战的专家。