RAG 全称是 Retrieval-Augmented Generation（检索增强生成），它将检索（或搜索）的能力集成到 LLM 的文本生成中。它结合了一个检索系统和一个 LLM，前者从大型语料库中获取与用户查询最相关的文档，后者使用这些被检索到的文档中的信息生成答案。本质上，RAG 帮助模型“查找”外部信息以改进其响应。
微调（Finetuing）：在较小的特定数据集上进一步训练预训练过的 LLM，以使其适应特定任务或提高其性能。通过微调，我们根据数据调整模型的权重，使其更适合我们应用程序的独特需求。
下面我将从几个不同的角度来说明什么时候应该使用 RAG，什么时候应该使用微调。
是否需要访问外部数据源？
现今所有的 LLM 的知识受到训练这些 LLM 时的数据集的制约，具体来说有两个主要方面的制约：
时间：所有训练数据集的收集都有一个时间范围，这导致 LLM 无法获取最新的知识。
私有数据：很多企业和组织都有自己的私有数据，比如公司内部不公开的资料库，这些资料库中的知识也无法被外部公司或组织收集起来训练 LLM。
如果我们要构建一个需要访问外部数据源的 LLM 应用程序，那么我们就应该选择 RAG。
根据 RAG 的定义，RAG 会通过在 LLM 生成响应之前从外部数据源中检索与当前用户查询最相关的信息来增强 LLM 的能力。这使得该技术非常适合需要查询数据库、文档或其他结构化/非结构化数据存储库的应用程序。
相比之下，虽然可以我们对 LLM 进行微调以学习一些外部知识，但这样做需要来自目标领域的大量带标签的问答对数据集。该数据集必须随着基础数据的变化而更新，这对于频繁变化的数据源来说是不切实际的。微调过程也没有明确地对查询外部知识所涉及的检索和推理步骤进行建模。
总而言之，如果我们的应用程序需要利用外部数据源，那么使用 RAG 系统可能比尝试仅通过微调“融入”所需的知识更有效且可扩展。
是否需要修改模型的行为、写作风格或特定领域的知识？
微调的优势在于能够使 LLM 的行为适应特定领域的语气或术语。如果我们希望模型听起来更像医学专业人士，以诗意的风格写作，或者使用特定行业的术语，那么对特定领域的数据进行微调可以让我们实现这些定制化需求。这种影响模型行为的能力对于与特定风格或领域专业知识保持一致至关重要的应用程序至关重要。
RAG 虽然在整合外部知识方面功能强大，但主要侧重于信息检索，它本身并不根据检索到的信息来调整 LLM 的语言风格或领域特异性。它将从外部数据源提取相关内容，但可能不会展现微调模型可以提供的定制化响应风格。
因此，如果我们的应用程序需要专门的写作风格或与特定领域的语言和惯例深度一致，那么微调提供了一种更直接的途径来实现这种一致性。它提供了与特定受众或专业领域真正产生共鸣所需的深度和定制性，确保生成的内容真实且信息灵通。
抑制幻觉有多重要？
LLM 的缺点之一是容易产生幻觉——编造没有现实依据的事实或细节。在准确性和真实性至关重要的应用中，这可能会产生很大的问题。
通过将模型基于特定领域的训练数据进行微调，可以在一定程度上帮助模型减少幻觉。然而，当面对不熟悉的输入时，模型仍然可能会做出响应。需要对新数据进行再训练，以不断减少模型输出虚假信息的可能性。
相比之下，RAG 本质上不太容易产生幻觉，因为它们将每个响应都基于从指定数据源中检索到的信息。在 LLM 输出答案之前，检索器从外部知识源中识别相关事实。这个检索步骤充当事实检查机制，降低了模型的虚构能力。LLM 也被限制根据检索到的上下文信息合成响应。
有多少标记的训练数据可用？
微调 LLM 以适应特定任务或领域在很大程度上取决于可用标记数据的质量和数量。丰富的数据集可以帮助模型深入理解特定领域的细微差别、复杂性和独特模式，从而使其能够生成更准确且与上下文相关的响应。然而，如果我们使用有限的数据集，微调带来的改进可能微乎其微。在某些情况下，数据集不足甚至可能导致过拟合。
相反，RAG 独立于训练数据，因为它们利用外部知识源来检索相关信息。即使我们没有广泛的标记数据集，RAG 仍然可以通过访问和合并来自外部数据源的信息来有效执行。检索和生成的结合确保系统即使在特定领域的训练数据稀疏的情况下也能保持知情。
从本质上讲，如果我们拥有大量的标记数据来捕获该领域的复杂性，那么微调可以提供更加定制和完善的模型行为。但在此类数据有限的情况下，RAG 系统提供了一个强大的替代方案，确保应用程序通过其检索功能保持数据知情和上下文感知。
数据的静态/动态程度如何？
在特定数据集上微调 LLM 意味着模型的知识成为训练时数据的静态快照。如果数据频繁更新、更改或扩展，模型很快就会过时。为了使 LLM 在这种动态环境中保持最新状态，我们必须经常重新训练它，这个过程既耗时又占用资源。此外，每次迭代都需要仔细监控，以确保更新后的模型在不同场景中仍然表现良好，并且没有产生新的偏差或理解差距。
相比之下，RAG 在动态数据环境中具有固有的优势。它们的检索机制不断查询外部来源，确保他们提取用于生成响应的信息是最新的。随着外部知识库或数据库的更新，RAG 无缝集成这些变化，保持其相关性，而不需要频繁地重新训练模型。
总之，如果我们正在应对快速发展的数据环境，RAG 提供的敏捷性是传统微调难以比拟的。通过始终与最新数据保持连接，RAG 可确保生成的响应与信息的当前状态保持一致，使其成为动态数据场景的理想选择。
我们的 LLM 应用程序需要有多透明/可解释？
微调 LLM 虽然非常强大，但其运作就像一个黑盒子，使其响应背后的推理更加不透明。随着模型内化数据集中的信息，辨别每个响应背后的确切来源或推理变得具有挑战性。这可能会使开发人员或用户难以信任模型的输出，特别是在关键应用程序中，了解答案背后的“原因”至关重要。
另一方面，RAG 提供了一定程度的透明度，这在单独的微调模型中通常是不存在的。鉴于 RAG 的两步性质（检索然后生成），用户可以查看该过程。检索组件允许检查哪些外部文档或数据点被选择为相关。这提供了切实的证据或参考线索，可以对其进行评估以了解响应的基础。在需要高度责任感或需要验证生成内容的准确性的应用程序中，追溯模型对特定数据源的答案的能力可能非常宝贵。
从本质上讲，如果透明度和解释模型响应基础的能力是优先考虑的因素，那么 RAG 具有明显的优势。通过将响应生成分解为不同的阶段并允许深入了解其数据检索，RAG 可以增强用户对其输出的信任和理解。
其他因素
可扩展性
随着企业或组织的发展和需求的变化，所讨论的方法的可扩展性如何？鉴于其模块化性质，RAG 可能会提供更直接的可扩展性，尤其是在知识库增长的情况下。另一方面，频繁微调模型以适应不断扩展的数据集可能需要大量计算资源。
延迟和实时要求
如果应用程序需要实时或接近实时的响应，与基于内化知识生成响应的微调 LLM 相比，RAG 涉及在生成响应之前检索数据，可能会引入更多延迟。
维护与支持
RAG 可能需要维护数据库和检索机制，而微调则需要一致的再训练工作，特别是在数据或需求发生变化的情况下。
稳健性和可靠性
每种方法对于不同类型的输入的鲁棒性如何？ 虽然 RAG 可以从外部知识源中获取知识，并且可以处理广泛的问题，但经过良好调整的模型可能会在某些领域提供更高的一致性。
道德和隐私问题
从外部数据库存储和检索可能会引起隐私问题，尤其是在数据敏感的情况下。另一方面，经过微调的模型虽然不查询实时数据库，但仍可能根据其训练数据产生输出，这可能有其自身的道德含义。
与现有系统集成
要考虑与现有系统（无论是数据库、云基础设施还是用户界面）的兼容性。
用户体验
考虑最终用户及其需求。如果他们需要详细的、有参考资料支持的答案，RAG 可能是更好的选择。如果他们重视速度和特定领域的专业知识，那么微调的模型可能更合适。
成本
微调可能会变得昂贵，尤其是对于非常大的模型。但在过去的几个月里，得益于 QLoRA 等参数高效技术，成本已显著下降。设置 RAG 可能是一项巨大的初始投资——涵盖集成、数据库访问，甚至可能是许可费用——但还需要考虑定期维护外部知识库。
复杂度
微调很快就会变得复杂。虽然许多提供商现在提供一键式微调，我们只需要提供训练数据，但跟踪模型版本并确保新模型仍然全面运行是一项挑战。另一方面，RAG 也可能很快变得复杂。有多个组件的设置，确保数据库保持最新，并确保各个部分（例如检索和生成）正确地组合在一起。
总结
正如我们所探讨的，在 RAG 和微调之间进行选择需要对 LLM 的独特需求和优先事项进行细致入微的评估。没有一种万能的解决方案 ，成功在于使优化方法与任务的具体要求保持一致。通过评估关键标准（外部数据的需求、调整模型行为、训练数据可用性、数据动态、结果透明度等），我们就可以用最佳前进路径做出明智的决策。在某些情况下，同时利用 RAG 和微调的混合方法可能是最佳选择。
关键是避免假设一种方法普遍优越。与任何工具一样，它们的适用性取决于手头的工作。方法和目标不一致可能会阻碍进展，而正确的方法会加速进展。当我们评估提升 LLM 应用程序的选项时，它必须抵制过度简化，不要将 RAG 和微调视为可互换的，并选择使模型能够满足其与用例需求相一致的功能的工具。这些方法所带来的可能性令人震惊，但仅有可能性还不够——执行就是一切。
