优化 LLM 准确性

优化 LLM 很困难。

我们与初创企业和企业的许多开发人员合作过，优化困难的原因始终归结为以下原因：

• 知道如何开始优化准确性
• 何时使用什么优化方法
• 对于生产来说，什么级别的精度才足够好

本文为如何优化 LLM 的准确性和行为提供了一个心智模型。我们将探索提示工程、检索增强生成 （RAG） 和微调等方法。我们还将重点介绍如何以及何时使用每种技术，并分享一些陷阱。

在通读时，请务必在脑海中将这些原则与准确性对您的特定用例的意义联系起来。这似乎是显而易见的，但制作人工需要修复的不良副本与向客户退款 1000 美元而不是 100 美元是有区别的。在讨论 LLM 准确性时，您应该粗略地了解 LLM 的失败会让您付出多少代价，以及成功会为您节省或赢得多少 - 这将在最后重新讨论，我们将介绍多少准确性对于生产来说“足够好”。

许多关于优化的 “how-to” 指南将其描绘成一个简单的线性流程 - 你从提示工程开始，然后你继续进行检索增强生成，然后是微调。然而，情况往往并非如此 - 这些都是解决不同事情的杠杆，要朝着正确的方向进行优化，您需要拉动正确的杠杆。

将 LLM 优化构建为更多的矩阵是有用的：

典型的 LLM 任务将从左下角开始，提示工程，我们在其中测试、学习和评估以获得基线。一旦我们审查了这些基线示例并评估了它们为什么不正确，我们就可以拉动我们的杠杆之一：

• 上下文优化：在以下情况下，您需要针对上下文进行优化：1） 模型缺乏上下文知识，因为它不在训练集中，2） 它的知识已过时，或者 3） 它需要专有信息的知识。该轴最大限度地提高了响应精度。
• LLM 优化：在以下情况下，您需要优化 LLM：1） 模型产生不一致的结果，格式不正确，2） 语气或语音风格不正确，或者 3） 推理没有得到一致遵循。此轴可最大程度地提高行为的一致性。

实际上，这变成了一系列优化步骤，在这些步骤中，我们评估、假设如何优化、应用它、评估和重新评估下一步。下面是一个相当典型的优化流程示例：

在此示例中，我们执行以下操作：

• 从提示开始，然后评估其性能
• 添加静态的 few-shot 示例，这应该会提高结果的一致性
• 添加检索步骤，以便根据问题动态引入少数样本 - 这可以通过确保每个输入的相关上下文来提高性能
• 准备包含 50+ 个示例的数据集并微调模型以提高一致性
• 调整检索并添加事实核查步骤以查找幻觉，以实现更高的准确性
• 在新的训练示例上重新训练微调的模型，其中包括我们增强的 RAG 输入

这是一个针对棘手业务问题的相当典型的优化管道 - 它帮助我们确定我们是否需要更相关的上下文，或者我们是否需要来自模型的更一致的行为。一旦我们做出了这个决定，我们就知道该拉哪个杠杆作为我们迈向优化的第一步。

现在我们已经有了心智模型，让我们深入研究在所有这些领域采取行动的方法。我们将从左下角的 Prompt Engineering 开始。

提示工程通常是最好的起点**。它通常是摘要、翻译和代码生成等使用案例所需的唯一方法，在这些用例中，零样本方法可以达到生产水平的准确性和一致性。

这是因为它迫使您定义准确性对您的使用案例意味着什么 - 您从最基本的级别开始，提供输入，因此您需要能够判断输出是否符合您的期望。如果这不是您想要的，那么原因将向您展示如何使用来推动进一步优化。

为此，您应该始终从简单的提示和预期的输出开始，然后通过添加上下文、说明或示例来优化提示，直到它为您提供所需的内容。

为了优化您的提示，我将主要依赖 OpenAI API 文档中的提示工程指南中的策略。每种策略都可以帮助您调整 Context 和/或 LLM：

策略	上下文优化	LLM 优化
编写清晰的说明		X
将复杂任务拆分为更简单的子任务	X	X
给 GPT 时间“思考”		X
系统地测试更改	X	X
提供参考文本	X
使用外部工具	X

这些可能有点难以可视化，因此我们将通过一个示例来测试这些示例。让我们使用 gpt-4-turbo 来纠正冰岛语句子，看看这是如何运作的。

我们已经看到，Prompt Engineering 是一个很好的起点，通过正确的调整方法，我们可以将性能推得很远。

然而，快速工程的最大问题是它通常无法扩展 - 我们要么需要动态上下文来允许模型处理比我们通过简单的上下文填充处理的更广泛的问题，要么我们需要比使用少数样本实现的更一致的行为。

那么，您真的可以走多远的提示工程呢？答案是这要看情况，而你做决定的方式是通过评估。

这就是为什么带有一组评估问题和真实答案的好提示是这个阶段的最佳输出。如果我们有一组 20+ 个问题和答案，并且我们已经研究了失败的细节并假设了它们发生的原因，那么我们就有了正确的基线来采用更高级的优化方法。

在继续采用更复杂的优化方法之前，还值得考虑如何自动化此评估以加快迭代速度。我们在这里看到的一些常见做法是：

• 使用 ROUGE 或 BERTScore 等方法提供 finger-in-the-air 判断。这与人工审阅者没有那么密切的关联，但可以快速有效地衡量迭代对模型输出的影响程度。
• 使用 GPT-4 作为评估器，如 G-Eval 论文中所述，您可以在其中为 LLM 提供记分卡以尽可能客观地评估输出。

如果您想更深入地了解这些内容，请查看这本说明书，它将带您在实践中了解所有这些内容。

所以你已经完成了快速工程，你有一个 eval 集，但你的模型仍然没有做你需要它做的事情。最重要的下一步是诊断它失败的地方，以及什么工具最能改进它。

以下是执行此操作的基本框架：

您可以将每个失败的评估问题视为上下文问题或学习性记忆问题。打个比方，想象一下写一场考试。有两种方法可以确保您得到正确的答案：

• 您在过去 6 个月上课，在那里您看到了许多关于特定概念如何运作的重复示例。这是学习到的记忆 - 您可以通过展示您期望的提示和响应的示例以及模型从中学习来使用 LLM 来解决这个问题。
• 你带着教科书，可以查找正确的信息来回答问题。这就是上下文内存 - 我们在 LLM 中通过将相关信息填充到上下文窗口中来解决这个问题，要么以静态方式使用提示工程，要么以工业方式使用 RAG。

这两种优化方法是相加的，而不是排他性的 - 它们相叠加，某些用例需要您将它们一起使用才能获得最佳性能。

假设我们面临一个短期记忆问题 - 为此，我们将使用 RAG 来解决它。

RAG 是在 G激活答案之前将内容检索到 Augment 您的 LLM 提示的过程。它用于为模型提供对特定于域的上下文的访问权限以求解任务。

RAG 是提高 LLM 准确性和一致性的非常有价值的工具——我们在 OpenAI 的许多最大客户部署都是仅使用提示工程和 RAG 完成的。

在此示例中，我们嵌入了统计信息知识库。当用户提出问题时，我们会嵌入该问题并从知识库中检索最相关的内容。这被呈现给模型，模型回答了这个问题。

RAG 应用程序引入了我们需要优化的新轴，即检索。为了使我们的 RAG 正常工作，我们需要为模型提供正确的上下文，然后评估模型是否正确回答。我将在此处将这些框定在一个网格中，以展示一种考虑使用 RAG 进行评估的简单方法：

您的 RAG 应用程序可以分解两个区域：

面积	问题	分辨率
检索	你可以提供错误的上下文，所以模型不可能回答，或者你可以提供太多不相关的上下文，这会淹没真实信息并导致幻觉。	优化您的检索，其中可能包括： - 调整搜索以返回正确的结果。 - 调整搜索以包含更少的噪音。 - 在每个检索到的结果 中提供更多信息这些只是示例，因为调优 RAG 性能本身就是一个行业，像 LlamaIndex 和 LangChain 这样的库在这里提供了许多调优方法。
法学硕士	模型还可以获得正确的上下文并对其执行错误的操作。	通过改进模型使用的指令和方法来提示工程，如果展示示例可以提高准确性，则添加微调

这里要了解的关键是，原则与一开始的心智模型相同 - 你评估以找出问题所在，并采取优化步骤来修复它。与 RAG 的唯一区别是，您现在需要考虑检索轴。

虽然有用，但 RAG 只解决了我们的上下文学习问题——对于许多用例，问题将是确保 LLM 能够学习任务，以便它能够一致且可靠地执行任务。对于这个问题，我们转向微调。

为了解决学习到的内存问题，许多开发人员将在较小的特定领域数据集上继续 LLM 的训练过程，以针对特定任务对其进行优化。此过程称为微调。

执行微调通常出于以下两个原因之一：

• 要提高特定任务的模型准确性：在特定于任务的数据上训练模型，通过向模型展示正确执行该任务的许多示例来解决学习到的内存问题。
• 要提高模型效率，请执行以下操作：使用较少的令牌或使用较小的模型实现相同的准确性。

微调过程从准备训练示例的数据集开始 - 这是最关键的一步，因为您的微调示例必须准确表示模型在现实世界中看到的内容。

拥有这个干净的集合后，您可以通过执行训练运行来训练微调的模型 - 根据您用于训练的平台或框架，您可能有可以在此处优化的超参数，类似于任何其他机器学习模型。我们始终建议维护一个保持集，以便在训练后用于评估以检测过拟合。有关如何构建良好训练集的提示，您可以查看我们的微调文档中的指南，而有关如何准备和调整保持集的提示，请在此处了解更多信息。训练完成后，新的微调模型即可用于推理。

为了优化微调，我们将重点介绍我们在 OpenAI 的模型定制产品中观察到的最佳实践，但这些原则应该适用于其他提供商和 OSS 产品。这里要遵守的主要做法是：

• 从 prompt-engineering 开始：从 prompt engineering 中获得一个可靠的评估集，您可以将其用作基线。这允许采用低投资方法，直到您对基本提示有信心为止。
• 从小处着手，注重质量：在基础模型之上进行微调时，训练数据的质量比数量更重要。从 50+ 个示例开始，进行评估，如果您尚未达到准确性需求，并且导致错误答案的问题是由于一致性/行为而不是上下文，请调整您的训练集大小。
• 确保您的示例具有代表性：我们看到的最常见的陷阱之一是不具有代表性的训练数据，其中用于微调的示例在格式或形式上与 LLM 在生产中看到的示例略有不同。例如，如果您有一个 RAG 应用程序，请对包含 RAG 示例的模型进行微调，这样它就不会学习如何使用上下文 zero-shot。

这些技术相互叠加 - 如果你的早期评估显示上下文和行为都存在问题，那么你很可能最终会在生产解决方案中使用微调 + RAG。这没关系 - 这些堆栈可以平衡两种方法的弱点。一些主要好处是：

• 使用微调来最大限度地减少用于提示工程的标记，因为您将指令和小样本替换为许多训练示例，以在模型中根深蒂固一致的行为。
• 使用广泛的微调来教授复杂行为
• 使用 RAG 注入上下文、更新的内容或您的用例所需的任何其他专用上下文

现在您应该对 RAG 和微调以及何时合适有所了解。使用这些工具后，您应该欣赏的最后一件事是，一旦您引入了它们，我们的迭代速度就会受到权衡：

• 对于 RAG，您需要调整检索以及 LLM 行为
• 使用 fine-tuning 时，您需要重新运行微调过程，并在执行其他优化时管理您的训练集和验证集。

这两者都可能是耗时且复杂的过程，随着 LLM 应用程序变得更加复杂，这可能会引入回归问题。如果您从本文中学到一件事，那就是在进行更复杂的 RAG 或微调之前，尽可能多地从基本方法中挤出准确性 - 让您的精度目标成为目标，而不是跳转到 RAG + FT，因为它们被认为是最复杂的。

调整准确性可能是一场与 LLM 的永无止境的战斗 - 使用现成的方法，它们不太可能达到 99.999% 的准确率。本节是关于确定何时足以保证准确性 - 您如何适应将 LLM 投入生产，以及如何管理您发布的解决方案的风险。

我发现在业务和技术上下文中考虑这一点很有帮助。我将介绍管理这两种情况的高级方法，并使用客户服务帮助台使用案例来说明我们如何在这两种情况下管理风险。

对于企业来说，在基于规则或传统机器学习系统或人类的相对确定性之后，可能很难信任 LLM！故障是开放式和不可预测的系统是一个难以平方的圆圈。

我在这里看到的一种成功方法是针对客户服务用例 - 为此，我们做了以下工作：

首先，我们确定主要的成功和失败案例，并为它们分配估计成本。这让我们清楚地阐明了该解决方案可能节省的费用或基于飞行员绩效的成本。

• 例如，一个案件由 AI 解决，而以前由人类解决可能会节省 20 美元。
• 有人在不该升级为人类时可能要花费 40 美元
• 在最坏的情况下，客户对他们流失的 AI 感到非常沮丧，损失了 1000 美元。我们假设这种情况发生在 5% 的情况下。

事件	价值	案例数	总价值
AI 成功	+20	815	16,300 美元
AI 故障 （升级）	-40	175.75	7,030 美元
AI 故障 （改动）	-1000	9.25	9,250 美元
结果			+20
盈亏平衡精度			81.5%

我们做的另一件事是衡量围绕该过程的经验统计数据，这将有助于我们衡量解决方案的宏观影响。再次使用客户服务，这些可能是：

• 纯人工交互与 AI 交互的 CSAT 分数
• 回顾性审查的人类与 AI 案例的决策准确性
• 人类与 AI 的解决时间

在客户服务示例中，这有助于我们在进行一些试点后做出两个关键决策，以获得明确的数据：

1. 即使我们的 LLM 解决方案升级到人类的程度超出了我们的预期，它仍然比现有解决方案节省了大量的运营成本。这意味着即使 85% 的准确率也可以，如果这 15% 主要是早期升级。
2. 在失败成本非常高的情况下，例如欺诈案件被错误解决，我们决定由人类驾驶，而 AI 将充当助手。在这种情况下，决策准确性统计数据帮助我们做出了我们对完全自主性不满意的决定。

在技术方面，情况更加清晰 - 既然企业已经清楚地了解他们期望的价值和可能出错的成本，那么您的角色是构建一个解决方案，以不破坏用户体验的方式优雅地处理故障。

让我们再次使用客户服务示例来说明这一点，我们假设我们有一个模型，它对确定意图的准确率为 85%。作为技术团队，我们可以通过以下几种方式将不正确的 15% 的影响降至最低：

• 如果模型没有信心，我们可以提示工程师模型，以提示客户提供更多信息，因此我们的首次准确性可能会下降，但给定 2 次射击来确定意图，我们可能会更准确。
• 我们可以为二线助手提供返回意图确定阶段的选项，再次为 UX 提供一种自我修复的方法，但代价是一些额外的用户延迟。
• 如果意图不明确，我们可以提示设计模型，将其移交给人工，这在短期内会花费我们一些运营成本，但从长远来看可能会抵消客户流失风险。

然后，这些决策会反馈到我们的 UX 中，而我们的 UX 会变得更慢，但代价是准确性更高，或者需要更多的人工干预，这会影响到上文业务部分介绍的成本模型。

现在，您有一种方法可以分解设置基于业务现实的准确性目标所涉及的业务和技术决策。

这是一个高级心智模型，用于考虑最大限度地提高 LLM 的准确性、可用于实现它的工具，以及确定在哪些情况下足以进行生产的方法。您拥有持续投入生产所需的框架和工具，如果您想从其他人通过这些方法取得的成就中获得灵感，那么我们的客户案例就是您的不二之选，其中 Morgan Stanley 和 Klarna 等使用案例展示了您可以利用这些技术实现的目标。

祝你好运，我们很高兴看到你用它构建了什么！