随着大家对大型语言模型（LLM）的兴趣激增，许多开发者也在构建基于LLM的应用。当直接使用Prompt驱动的LLM表现不如预期时，问题就出现了：如何提高LLM应用的可用性。这时我们需要权衡：是选择检索增强生成（Retrieval-Augmented Generation 缩写 RAG）还是模型微调来改善结果？
01
在深入探讨之前，让我们揭开这两种方法的神秘面纱：
RAG： 这种方法将检索（或搜索）的能力整合到LLM文本生成中。它结合了一个检索系统，从大型语料库中获取相关的文档片段，LLM利用这些片段中的信息生成答案。实质上，RAG帮助模型“查找”外部信息，以改善其回应。
Finetuning： 也就是微调，这是将预训练的LLM进一步训练到较小、特定数据集上的过程，以使其适应特定任务或提高性能。通过微调，我们根据特有的数据集调整模型的权重，使其更适合我们应用程序的独特需求。
RAG和微调都是增强LLM应用性能的强大工具，但它们涉及优化过程的不同方面，这在选择其中一种时至关重要。
02
以前，我经常建议在深入微调之前尝试使用RAG。这是基于我对两种方法都能够取得类似结果但在复杂性、成本和质量方面有所不同的看法。甚至过去常常用这样的图表来说明这一观点：
在这个图表中，各种因素，如复杂性、成本和质量，沿着一个维度表示出来。结论是？RAG更简单且成本更低，但其质量可能无法匹配。通常的建议是：首先尝试RAG，评估其性能，如果发现不足，再转向微调。
现在我的观点已经发生了变化。之前很多人把RAG和微调视为两种实现相同结果的技术，只是其中一种比另一种更便宜和不那么复杂，这是一种过于简单化的看法。
两种技术工具在本质上是完全不同的，两者不是相互关联的，算是正交的相互独立关系，单独一种都可以满足LLM应用的需求。
为了更清晰地说明这一点，考虑一个简单的现实世界类比，**当面临：“我应该用刀还是勺子吃饭”的问题时，最合乎逻辑的反问是：“那得看你吃的是什么”。**我问了身边人这个问题，每个人都本能地回答了这个反问，表明他们不认为刀和勺子可以互换使用，也不认为其中一个是另一个的劣质替代品。
03
接下来我们会探讨如何区分RAG和微调的细微差别，这些差别涵盖了我认为在确定特定任务的最佳技术时至关重要的各个方面。此外，我们将研究LLM应用程序的一些最受欢迎的用例。在文章的最后部分，我们将提及在构建LLM应用程序时应考虑的其他方面。
选择正确的技术来适应大型语言模型可以对自然语言处理应用程序的成功产生重大影响。选择错误的方法可能导致：
- 在您特定任务上模型性能不佳，导致不准确的输出。
- 如果技术未针对您的用例进行优化，可能导致模型训练和推断的计算成本增加。
- 如果您需要后来切换到不同的技术，可能需要额外的开发和迭代时间。
- 延迟部署您的应用程序并将其呈现给用户。
- 如果选择了过于复杂的适应方法，可能会导致模型可解释性不足。
- 由于计算规模的限制，难以将模型部署到生产环境中。
RAG和微调之间的微妙差别涵盖了模型架构、数据要求、计算复杂性等多个方面。忽视这些细节可能会使您的项目进度和预算失控。选择正确的工具成了项目成功的基础。
04 提升性能的关键考虑因素
在选择RAG与微调之前，我们应该通过一些维度来评估我们LLM项目的需求，并问自己一些问题：我们的用例是否需要访问外部数据源？
在选择微调LLM还是使用RAG之间，一个关键考虑因素是应用程序是否需要访问外部数据源。如果答案是肯定的，那么RAG可能是更好的选择。
RAG系统根据定义旨在通过从知识源中检索相关信息，然后生成响应来增强LLM的功能。这使得这种技术非常适用于需要查询数据库、文档或其他结构化/非结构化数据存储库的应用程序。检索器和生成器组件可以进行优化以利用这些外部来源。
相反，虽然可以通过微调LLM来学习一些外部知识，但这需要一个大规模的标记数据集，其中包含来自目标领域的问题答案对。这个数据集必须在底层数据发生变化时进行更新，这使得它对于频繁变动的数据源不切实际。微调过程还不会明确建模查询外部知识所涉及的检索和推理步骤。
因此，如果我们的应用程序需要利用外部数据源，使用RAG系统可能比仅通过微调来“嵌入”所需的知识更有效和可扩展。
第二个问题就是：**我们是否需要修改模型的行为、写作风格或领域特定知识？**另一个非常重要的考虑因素是我们是否需要模型调整其行为、写作风格或为领域特定应用程序定制其响应的程度。
微调在将LLM的行为调整到特定细微差别、语气或术语方面表现出色。如果我们希望模型听起来更像医疗专业人员、以诗意的风格写作，或使用特定行业的行话，那么在领域特定数据上进行微调可以实现这些定制。影响模型行为的能力对于需要与特定风格或领域专业知识保持一致的应用程序至关重要。
RAG虽然在整合外部知识方面非常强大，但主要侧重于信息检索，不会根据检索到的信息固有地调整其语言风格或领域特定性。它将从外部数据源中提取相关内容，但可能不会表现出微调模型可以提供的定制细微差别或领域专业知识。
因此，如果我们的应用程序需要专业的写作风格或深刻与领域特定的用语和惯例相一致，微调提供了实现这种一致性的更直接途径。它提供了深度和定制所需，以真正与特定受众或专业领域产生共鸣，确保生成的内容感觉真实且富有见识。
05
在决定使用哪种方法来提升LLM应用性能时，考虑这两个方面是迄今为止最重要的。有趣的是，它们在我看来是正交的，可以独立使用也可以结合使用。在深入研究用例之前，在选择方法之前还有一些关键方面需要考虑：
06 抑制幻觉有多重要
LLM的一个缺点是它们倾向于产生幻觉，也就是编造没有现实依据的事实或细节。在强调准确性和真实性至关重要的应用中，这可能会带来很大问题。
微调可以通过将模型基于特定领域的训练数据来一定程度上减少幻觉。然而，当面临不熟悉的输入时，模型仍然可能会编造响应结果，所以需要不断的重新训练以不断减少虚假制造。
相比之下，RAG在生成最终的响应时受到合并检索上下文支持的约束，使得RAG不容易产生幻觉。具体来说就是，检索器在生成器构建答案之前从外部知识源中识别相关事实，这个检索步骤充当事实检查机制，大大降低模型虚构的能力。
因此，在抑制虚假和想象性制造非常重要的应用中，RAG系统提供了内置机制以减少幻觉。RAG在确保事实准确和真实的输出方面具有优势。
07 有多少标记的训练数据可用
在选择RAG和微调之间时，一个关键因素是我们手头是否有领域或任务特定的标记训练数据的数量。
微调LLM以适应特定任务或领域在很大程度上取决于可用的标记数据的质量和数量。 丰富的数据集可以帮助模型更深入地理解特定领域的细微差别、复杂性和独特模式，从而生成更准确和上下文相关的响应。
如果我们只使用有限的数据集，微调可能带来的改进可能会有限。在某些情况下，较少的数据集甚至可能导致过拟合，模型在训练数据上表现良好，但在看不见的或用户真实的输入上表现不佳。
相反，RAG系统独立于训练数据，因为它们利用外部知识源来检索相关信息。即使我们没有大量的标记数据集，RAG系统仍然可以通过访问并整合来自其外部数据源的见解来胜任工作。检索和生成的结合确保了该系统在领域特定训练数据稀缺时仍然具有数据的基础和上下文的意识。
简而言之，如果我们拥有大量捕捉领域细微差别的标记数据，微调可以提供更贴合和精细的模型行为。但在数据有限的情况下，RAG系统提供了一个坚固的选择，确保应用程序通过其检索功能保持数据意识和上下文感知。
08 数据是静态的还是动态的
在选择RAG和微调之间的另一个基本方面是我们数据的动态性质，也就是数据的更新频率，模型保持最新的重要程度。
在特定数据集上微调LLM意味着模型的知识成为训练时的那个时间点上的数据的静态快照。 如果数据经常更新、更改或需要扩展，这可能会迅速使模型过时。
为了在这种动态环境中保持LLM的最新性，我们需要频繁重新训练它，这是一个既耗时又资源密集的过程。此外，每次迭代都需要仔细监控，以确保更新后的模型在不同场景下仍然表现良好，并且没有产生新的偏见或理解差距。
相比之下，RAG系统在动态数据环境中具有固有的优势。它们的检索机制不断查询外部源，确保用于生成响应的信息是最新的。随着外部知识库或数据库的更新，RAG系统无缝集成这些变化，无需频繁重新训练模型即可保持其相关性。
如果我们面临的是不断发展的数据格局，RAG提供了传统微调难以匹配的灵活性。通过始终与最新数据保持连接，RAG确保生成的响应与信息的当前状态保持一致，使其成为动态数据场景的理想选择。
09 LLM应用需要的可解释性
最后一个方面是我们需要对大语言模型的决策过程了解多少，也就是LLM的可解释性如何。
微调LLM虽然非常强大，但操作起来像一个黑匣子，这代表着其响应背后的推理过程是模糊的。 模型内化了数据集中的信息，这使得我们很难辨别每个响应背后的确切来源。
这可能会使开发人员或用户难以信任模型的输出，尤其是在关键应用程序中，了解答案背后的“为什么”至关重要时。
相较而言，RAG系统提供了通常在仅微调模型中达不到的透明度。鉴于RAG的两步特性：检索然后生成，开发者或者用户可以窥视整个过程。检索组件允许检查选择为相关的外部文档或数据点。这提供了一个切实可行的证据或参考轨迹，可以评估并且真正去理解响应构建的过程。
在RAG应用中，我们拥有可以将模型的答案追溯到特定数据源的能力，在需要高度负责任的应用程序中或需要验证生成内容准确性时这是非常有价值的。
简而言之，如果透明度和解释模型响应底层机制的能力是优先考虑的因素，那么RAG占据明显优势。 通过将响应生成拆分为不同阶段，并允许查看其数据检索，RAG在其输出中培养了更高的信任和理解。
10
在考虑以上06-09这几个维度时，选择RAG还是微调，变得更加直观。如果我们需要倾向于访问外部知识并重视透明度，那么RAG是我们的首选。另一方面， 如果我们使用稳定的标记数据并希望更紧密地适应特定需求，微调是更好的选择。
接下来我们根据上述的标准，依次评估LLM应用在几个场景中如何选择合适的方法：
11 专业领域摘要或进行特定风格摘要
\1. 需要外部知识吗？对于以前摘要的风格进行摘要的任务，主要数据源将是以前的摘要本身。如果这些摘要包含在静态数据集中，就不太需要持续外部数据检索。但是，如果有一个频繁更新的摘要动态数据库，目标是不断与最新条目对齐的话，RAG可能在这个场景更好发挥作用。
\2. 需要模型适配吗？这个用例的核心是适应专业领域或特定的写作风格。微调特别擅长捕捉风格细微差异、语调变化和特定领域的词汇，因此对于这个维度来说，微调也是是一个必要的选择。
\3. 必须是最小化幻觉吗？在大多数LLM应用中，都会存在响应幻觉的问题。但是在摘要的场景中，通常是会提供上下文的，这使得幻觉相对于其他场景不太重要。源文本限制了模型，减少了模型的幻觉。虽然依据事实，准确回答是必要的，但在摘要中，由于上下文的基础，抑制幻觉不是首要任务。
\4. 是否有训练数据可用？如果有大量的以前的摘要，这些摘要以一种模型可以从中学到的方式进行标记或结构化，那么微调将成为一个非常有吸引力的选择。另一方面，如果数据集有限，我们依赖外部数据库进行风格对齐，那么RAG可能会发挥作用，尽管其主要优势不在于风格适应。
\5. 数据的动态性如何？如果以前摘要的数据库是静态的或更新不频繁的，那么微调模型的知识可能会保持较长时间的相关性。然而，如果摘要经常更新，并且需要模型不断与最新的风格变化对齐，那么由于其动态数据检索能力，RAG可能具有优势。
\6. 需要透明度以及可解释性吗？这里的主要目标是风格对齐，因此一个特定摘要风格背后的“为什么”可能不像其他场景那么重要。如果需要追溯并理解哪些以前的摘要影响了特定的输出，RAG提供了更多的透明度。对于摘要来说这可能是次要的。
建议：如果我们的主要目标是内容摘要风格的对齐，微调似乎更合适，这也是微调的亮点。假设有足够多的数据可供训练，微调LLM将允许对所需的风格进行深度适应，捕捉到特定领域的细微差异。 如果摘要数据库需要是动态的，并且在追溯影响方面有要求，可以考虑混合使用两者或倾向于使用RAG。
12 外部数据驱动的问答系统
\1. 需要外部知识吗？依赖组织知识库的问答系统固有的需要访问外部数据，即组织的内部数据库和文档存储。该系统的有效性取决于其能够从这些源中提取并检索相关信息以回答查询。因此，在这种情况下，RAG更适合这个维度，因为它旨在通过从知识源中检索相关数据来增强LLM的能力。
\2. 需要模型适应吗？根据组织及其领域的不同，模型可能需要与特定的术语、语气或约定保持一致。虽然RAG主要关注信息检索，但微调可以帮助LLM调整其响应以适应公司内部术语或领域的细微差异。因此，在这个维度上，根据具体要求，微调可能会发挥作用。
\3. 必须最小化幻觉吗？对于这种用例来说，幻觉是一个主要问题，因为LLM的内部的知识截止日期。如果模型无法根据其训练数据回答问题，它肯定会回答一个合理但不正确的答案。
\4. 是否有训练数据可用？如果组织有以前回答问题的结构化和标记的数据集，这可以加强微调方法。然而，并非所有内部数据库都用于训练目的而进行了标记或结构化。在数据没有被整齐标记或主要关注检索准确和相关答案的情况下，RAG能够检索外部数据源的能力使其成为一个引人注目的选择。
\5. 数据有多动态？组织内部的数据库和文档存储可以非常动态，经常更新、更改或添加。如果组织知识库的这种动态特征，RAG提供了明显的优势。它不断地查询外部来源，确保其答案基于最新的可用数据。而微调需要定期重新训练以跟上这些变化，这可能是不切实际的。
\6. 需要透明度/可解释性吗？对于内部应用，尤其是在金融、医疗保健或法律等领域，理解答案背后的原因或来源可能至关重要。由于RAG提供了检索和生成的两步过程，它自然地提供了更清晰的洞察，了解哪些文件或数据点影响了特定答案。对于可能需要验证或进一步调查某些答案的内部利益相关者，这种可追溯性可能非常有价值。
建议：对于这种场景，RAG系统似乎是更合适的选择。考虑到需要动态访问不断发展的内部数据库以及在答案过程中可能需要更多透明性和可解释性，RAG与这些需求能良好的契合。 如果强调定制模型的语言风格或适应特定领域的细微差异，可以考虑引入微调。
13 自动化客服
\1. 需要外部知识吗？自动化客服通常是需要访问外部数据，特别是在处理产品详情、账户特定信息或故障排除时。虽然许多查询可以用通用知识回答，但有些可能需要从公司数据库或产品常见问题解答中提取数据。在这里，RAG从外部源中检索相关信息的能力将是有益的。然而，值得注意的是，许多客户支持交互也是基于预定义的脚本或知识的，可以有效地通过微调模型来处理。
\2. 需要模型适应吗？客户互动需要一定的语气、礼貌和清晰度，还可能需要公司特定的术语。微调特别适用于确保LLM适应公司的声音、品牌和特定的术语，确保一致和与品牌一致的客户体验。
\3. 必须最小化幻觉吗？对于客户支持聊天机器人，避免提供虚假信息对于维护用户信任至关重要。仅依赖微调会使模型在面对不熟悉的查询时容易产生幻觉。相比之下，RAG系统通过将响应基于检索到的证据来抑制制造，这种依赖于来源事实的方式允许RAG聊天机器人最小化有害的虚假信息，并为用户提供在准确性至关重要的情况下可靠的信息。
\4. 是否有训练数据可用？如果公司有客户互动的历史数据，这些数据对于微调非常有价值。以前的客户查询和其解决方案的丰富数据集可以用于训练模型以处理未来类似的互动。如果这样的数据有限，RAG可以通过从外部来源检索答案，例如产品文档，提供一个后备。
\5. 数据有多动态？客户支持可能需要回答有关新产品、更新政策或更改服务条款的查询。在产品线、软件版本或公司政策经常更新的情况下，RAG动态地从最新的文档或数据库中检索的能力是有利的。另一方面，对于更静态的知识领域，微调可能足够。
\6. 需要透明度/可解释性吗？尽管透明度在某些领域非常重要，但在客户支持中，主要关注的是准确、快速和礼貌的回应。然而，对于内部监控、质量保证或处理客户争议，关于答案来源的可追溯性可能是有益的。在这种情况下，RAG的检索机制提供了额外的透明度层面。
建议：对于客服自动化，混合方法是最佳的选择。 微调可以确保客服机器人与公司客服人员的语气一致，可以更加方便的处理多数典型客户的问题。然后，RAG可以作为补充系统，用于处理更动态或非常特定的查询，确保客服机器人可以从最新的公司文档或知识库中检索，从而最小化幻觉。通过整合这两种方法，公司可以提供全面、及时并且与品牌形象一致的客户支持体验。
14 其他因素
决定使用RAG还是微调或两者同时使用时，还有其他因素需要考虑。这些因素都是多方面的，没有明确的答案。例如，如果没有训练数据集，微调就根本不可能。
15 可扩展性
随着业务的增长和产品需求的演变，就得考虑的现在选择的方法是否可扩展。由于RAG具有模块化的特性，尤其是当知识库不断增长时，它们可以提供更简单的可扩展性。另一方面，频繁地微调模型以满足不断扩展的数据集，可能会对计算资源提出更高要求。
16 延迟和实时响应
如果应用需要实时响应，那就必须考虑每种方法引入的延迟。使用阶段RAG相比微调会引入更多延迟。
17 维护和支持
RAG需要同时维护数据库和检索机制，而微调则需要持续的重复训练，尤其是如果数据或需求发生变化时。
18 健壮性和可靠性
虽然RAG系统可以从外部知识源中获取数据，并且可能处理各种各样的问题，但经过良好微调的模型在某些领域可能提供更一致的性能。
19 伦理和隐私问题
从外部数据库中存储和检索数据可能会引发隐私问题，尤其是如果数据是敏感的。微调模型虽然不会查询实时数据库，但仍可能根据其训练数据产生输出，这可能会涉及到伦理问题。
20 与现有系统的集成
现在我们可能已经拥有某些软件应用的基础设施，RAG或微调与现有系统的兼容性也是值得考虑的问题。无论是现有的数据库、云基础设施还是前端用户界面，都可能影响我们的选择。
21 用户体验
考虑最终用户及其需求，如果他们需要详细的、有参考依据的答案，那么RAG可能更可取。如果用户重视速度和特定的领域专业知识，那么微调模型可能更合适。
22 成本
微调可能会昂贵，尤其是基于非常大的模型进行微调。不过在过去的几个月里，**由于像QLoRA这样的高效微调技术的出现，使得成本已经大幅下降。**RAG可能需要初始投资，主要是清洗整合知识库，之后还需要考虑外部数据的维护成本。
23 复杂性
微调可能会比RAG更加复杂。虽然现在许多出现了很多一键微调的服务，我们只需提供训练数据，但跟踪模型版本，确保新模型在各个方面仍然表现良好都是具有挑战性的。RAG也可以很快变得复杂，因为需要设置多个组件，确保数据库保持更新，以及确保检索和生成等部分完美配合。这两种方法都需要针对生成结果进行评估，而评估的复杂程度在目前依旧很高。
24 总结
正如我们所探讨的，选择 RAG 和微调需根据 LLM 应用程序的需求进行细致评估。不同的解决方案适用于不同情况，成功在于将优化方法与任务具体要求相结合。通过评估关键标准，如外部数据需求、调整模型行为、训练数据可用性、数据动态性、结果透明度等，组织可以明智地选择最佳路径。在某些情况下，RAG 与微调的混合方法可能是最佳选择。
关键是避免认为一种方法在所有情况下都具有优越性。这些方法如同工具，适用性取决于手头的任务和需求。方法与目标不一致可能会阻碍应用的进展，而正确的方法会加速进展。
在评估提升LLM应用程序能力的选项时，我们需要避免过度简化。虽然这些方法所开启的可能性令人瞩目，但关键还是在于执行。之后我们会结合以上的讨论，实际应用这些工具做出有价值的产品，敬请期待！
如何学习大模型 AI ？
由于新岗位的生产效率，要优于被取代岗位的生产效率，所以实际上整个社会的生产效率是提升的。
但是具体到个人，只能说是：
“最先掌握AI的人，将会比较晚掌握AI的人有竞争优势”。
这句话，放在计算机、互联网、移动互联网的开局时期，都是一样的道理。
我在一线互联网企业工作十余年里，指导过不少同行后辈。帮助很多人得到了学习和成长。
我意识到有很多经验和知识值得分享给大家，也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑，所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限，很多互联网行业朋友无法获得正确的资料得到学习提升，故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。
第一阶段（10天）：初阶应用
该阶段让大家对大模型 AI有一个最前沿的认识，对大模型 AI 的理解超过 95% 的人，可以在相关讨论时发表高级、不跟风、又接地气的见解，别人只会和 AI 聊天，而你能调教 AI，并能用代码将大模型和业务衔接。
- 大模型 AI 能干什么？
- 大模型是怎样获得「智能」的？
- 用好 AI 的核心心法
- 大模型应用业务架构
- 大模型应用技术架构
- 代码示例：向 GPT-3.5 灌入新知识
- 提示工程的意义和核心思想
- Prompt 典型构成
- 指令调优方法论
- 思维链和思维树
- Prompt 攻击和防范
- …
第二阶段（30天）：高阶应用
该阶段我们正式进入大模型 AI 进阶实战学习，学会构造私有知识库，扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架，抓住最新的技术进展，适合 Python 和 JavaScript 程序员。
- 为什么要做 RAG
- 搭建一个简单的 ChatPDF
- 检索的基础概念
- 什么是向量表示（Embeddings）
- 向量数据库与向量检索
- 基于向量检索的 RAG
- 搭建 RAG 系统的扩展知识
- 混合检索与 RAG-Fusion 简介
- 向量模型本地部署
- …
第三阶段（30天）：模型训练
恭喜你，如果学到这里，你基本可以找到一份大模型 AI相关的工作，自己也能训练 GPT 了！通过微调，训练自己的垂直大模型，能独立训练开源多模态大模型，掌握更多技术方案。
到此为止，大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗？
- 为什么要做 RAG
- 什么是模型
- 什么是模型训练
- 求解器 & 损失函数简介
- 小实验2：手写一个简单的神经网络并训练它
- 什么是训练/预训练/微调/轻量化微调
- Transformer结构简介
- 轻量化微调
- 实验数据集的构建
- …
第四阶段（20天）：商业闭环
对全球大模型从性能、吞吐量、成本等方面有一定的认知，可以在云端和本地等多种环境下部署大模型，找到适合自己的项目/创业方向，做一名被 AI 武装的产品经理。
- 硬件选型
- 带你了解全球大模型
- 使用国产大模型服务
- 搭建 OpenAI 代理
- 热身：基于阿里云 PAI 部署 Stable Diffusion
- 在本地计算机运行大模型
- 大模型的私有化部署
- 基于 vLLM 部署大模型
- 案例：如何优雅地在阿里云私有部署开源大模型
- 部署一套开源 LLM 项目
- 内容安全
- 互联网信息服务算法备案
- …
学习是一个过程，只要学习就会有挑战。天道酬勤，你越努力，就会成为越优秀的自己。
如果你能在15天内完成所有的任务，那你堪称天才。然而，如果你能完成 60-70% 的内容，你就已经开始具备成为一名大模型 AI 的正确特征了。
这份完整版的大模型 AI 学习资料已经上传CSDN，朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
1582
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
