大模型优化：RAG还是微调？

提高性能的关键考虑因素

在我们选择 RAG 与 Fintuning 之前，我们应该从某些维度评估我们的 LLM 项目的要求，并问自己几个问题。

我们的用例是否需要访问外部数据源？

在微调 LLM 或使用 RAG 之间进行选择时，一个关键考虑因素是应用程序是否需要访问外部数据源。如果答案是肯定的，RAG 可能是更好的选择。

根据定义，RAG 系统旨在通过在生成响应之前从知识源检索相关信息来增强LLM的能力。这使得该技术非常适合需要查询数据库、文档或其他结构化/非结构化数据存储库的应用程序。可以优化检索器和生成器组件以利用这些外部源。

相比之下，虽然可以对LLM进行微调以学习一些外部知识，但这样做需要来自目标领域的大量带标签的问答对数据集。该数据集必须随着基础数据的变化而更新，这对于频繁变化的数据源来说是不切实际的。微调过程也没有明确地对查询外部知识所涉及的检索和推理步骤进行建模。

总而言之，如果我们的应用程序需要利用外部数据源，那么使用 RAG 系统可能比尝试仅通过微调“融入”所需的知识更有效且可扩展。

我们是否需要修改模型的行为、写作风格或特定领域的知识？

另一个需要考虑的非常重要的方面是我们有多少需要模型来调整其行为、编写风格或针对特定领域的应用程序定制其响应。

微调的优势在于能够使LLM的行为适应特定的细微差别、语气或术语。如果我们希望模型听起来更像医学专业人士，以诗意的风格写作，或者使用特定行业的术语，那么对特定领域的数据进行微调可以让我们实现这些定制。这种影响模型行为的能力对于与特定风格或领域专业知识保持一致至关重要的应用程序至关重要。

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 和微调的混合方法可能是最佳选择。