优化 LLM 准确性

如何在使用 LLM 时最大限度地提高正确性和行为一致性

优化 LLM 是一项艰巨的任务。

我们与许多初创公司和大型企业的开发者合作过，优化的难点始终归结为以下几个原因：

• 知道从何处开始优化准确性
• 何时使用哪种优化方法
• 达到什么准确度水平才足以用于生产环境

本文提供了一个关于如何优化 LLM 以获得准确性和理想行为的心智模型。我们将探讨提示工程 (Prompt Engineering)、检索增强生成 (RAG) 和微调 (Fine-tuning) 等方法。我们还将强调如何以及何时使用每种技术，并分享一些常见陷阱。

阅读时，请务必将这些原则与您特定应用场景中“准确性”的定义联系起来。这看起来很显而易见，但产生一段需要人工修正的劣质文案，与将客户应退款的 100 美元错误处理成 1000 美元之间，存在本质区别。在讨论 LLM 准确性时，您应该对 LLM 失败所带来的成本，以及成功所带来的节省或收益有一个大致的了解——我们将在文末重新探讨这一点，届时将讨论什么程度的准确性才“足以”投入生产。

LLM 优化背景

许多关于优化的“操作指南”将其描述为一个简单的线性流程——从提示工程开始，然后转向检索增强生成，最后是微调。然而，事实往往并非如此——这些都是解决不同问题的杠杆，要向正确的方向优化，您需要找到对应的杠杆。

将 LLM 优化视作一个矩阵会更有用。

典型的 LLM 任务将从左下角的提示工程开始，我们通过测试、学习和评估来获取基准。当我们审查了这些基准示例并评估了错误原因后，就可以开始利用我们的杠杆了：

• 上下文优化：当 1) 模型因训练集中缺少相关信息而缺乏上下文知识，2) 其知识已过时，或 3) 需要专有信息时，您需要优化上下文。此维度最大限度地提高响应准确性。
• LLM 优化：当 1) 模型产生格式不正确的、不一致的结果，2) 语气或风格不正确，或 3) 推理过程不连贯时，您需要优化 LLM 本身。此维度最大限度地提高行为一致性。

实际上，这演变成了一系列优化步骤：评估、对如何优化提出假设、应用优化、再次评估，并为下一步重新评估。以下是一个相当典型的优化流程示例：

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

• 从一个提示词开始，然后评估其表现。
• 添加静态少样本 (Few-shot) 示例，这应能提高结果的一致性。
• 添加检索步骤，以便根据问题动态调入少样本示例——这通过确保每个输入都有相关背景信息来提升性能。
• 准备一个包含 50 个以上示例的数据集，并对模型进行微调，以提高一致性。
• 调整检索过程并添加事实核查步骤，以发现幻觉并实现更高的准确性。
• 在包含增强后的 RAG 输入的新训练示例上，重新训练该微调模型。

对于棘手的商业问题，这是一个相当典型的优化流水线——它帮助我们决定是需要更相关的上下文，还是需要模型表现出更一致的行为。一旦做出决定，我们就知道应该从哪个杠杆开始进行优化。

既然我们有了心智模型，让我们深入研究如何在这些领域采取行动的方法。我们将从左下角的“提示工程”开始。

提示词工程

提示工程通常是最佳起点。对于摘要、翻译和代码生成等用例，它通常是唯一所需的方法，通过零样本 (Zero-shot) 方法即可达到生产级的准确性和一致性。

这是因为它迫使您定义该用例中“准确性”的具体含义——您通过提供输入从最基础的层面开始，因此您需要有能力判断输出是否符合预期。如果不是您想要的，那么其中的原因将揭示您接下来应该使用什么方法来推动进一步优化。

为实现这一点，您应始终从一个简单的提示词和预期的输出开始，然后通过添加上下文、指令或示例来优化提示词，直到它给出您想要的结果。

优化

为了优化您的提示词，我主要参考 OpenAI API 文档中提示工程指南的策略。每种策略都能帮助您调整上下文、LLM 或两者兼顾：

这些可能有点难以直观理解，所以我们将通过一个实际案例来测试它们。让我们使用 gpt-4-turbo 来纠正冰岛语句子，看看它是如何工作的。

SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.

# Examples
USER: "Stofnendurnir séu margir og eru fulltrúar hennar frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."
ASSISTANT: "Hann segir að stofnendur leynireglunnar séu margir og að fulltrúar hennar séu frá Englandi, Grikklandi, Rússlandi, Svíþjóð og fleiri löndum Evrópu."

USER: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstormar (fræðiheiti: Polychatete)."
ASSISTANT: "Helsta fæða bjúgorma eru hægfara lífverur sem eru á sama búsvæði og bjúgormarnir, oft smærri ormar eins og burstaormar (fræðiheiti: Polychatete)."

USER: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjótsti."
ASSISTANT: "Sörvistölur eru nær hálsi og skartgripir kvenna á brjósti."

USER: [input user query here]

我们已经看到，提示工程是一个很好的起点，通过正确的调优方法，我们可以大大提升性能。

然而，提示工程最大的问题是它通常无法扩展——我们要么需要输入动态上下文，让模型处理比仅仅增加上下文内容所能处理的范围更广的问题，要么需要比少样本示例所能达到的更一致的行为。

那么，提示工程到底能走多远？答案是取决于具体情况，而您做出决定的方式是通过评估。

评估

这就是为什么一个好的带有评估问题集和真值答案的提示词是该阶段的最佳输出。如果我们有一组 20 个以上的问题和答案，并且深入分析了失败的原因并提出了假设，那么我们就有了采取更高级优化方法的正确基准。

在进入更复杂的优化方法之前，考虑如何自动化此评估以加快迭代速度也是值得的。我们发现一些行之有效的常见做法包括：

• 使用诸如 ROUGE 或 BERTScore 等方法来进行快速判断。这与人类评审员的相关性并不十分紧密，但可以提供一个快速有效的度量标准，衡量某次迭代改变了多少模型输出。
• 使用 GPT-4 作为评估者，如 G-Eval 论文中所述，即为 LLM 提供评分卡，尽可能客观地评估输出。

如果您想深入了解这些，请查看此 cookbook，它将引导您在实践中完成所有这些操作。

了解工具

现在您已经完成了提示工程，拥有了评估集，但模型仍然达不到您的要求。最重要的一步是诊断它在何处失败，以及什么工具最能改进它。

这是一个基本框架：

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

• 您在过去 6 个月中一直上课，反复接触了特定概念如何运作的示例。这就是学习到的记忆——在 LLM 中，您通过向模型展示提示词示例和预期的响应，让模型从中学习来解决这个问题。
• 您随身带着课本，可以查找正确的信息来回答问题。这就是上下文内记忆——在 LLM 中，我们通过将相关信息填充到上下文窗口中来解决这个问题，无论是通过提示工程以静态方式，还是通过 RAG 以工业化方式。

这两种优化方法是累加的，而非互斥的——它们可以叠加，有些用例需要您将它们结合使用才能达到最佳性能。

假设我们面临的是短时记忆问题——为此我们将使用 RAG 来解决。

检索增强生成 (RAG)

RAG 是在生成答案之前，检索 (Retrieving) 内容以增强 (Augmenting) LLM 提示词的过程。它用于为模型提供特定领域的上下文访问权限，从而完成任务。

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

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

RAG 应用程序引入了一个我们需要优化的新维度，即检索。为了使 RAG 有效，我们需要为模型提供正确的上下文，然后评估模型是否回答正确。我在这里将其放在一个网格中，以展示一种思考 RAG 评估的简单方法：

您的 RAG 应用程序可能会在两个领域出现故障：

这里要领会的核心在于，原则与我们最初的心智模型保持一致——您通过评估找出错误所在，并采取优化步骤进行修复。RAG 的唯一区别在于，现在您需要考虑检索维度。

虽然有用，但 RAG 只能解决我们的上下文内学习问题——对于许多用例，问题在于确保 LLM 能够学习一项任务，从而持续、可靠地执行它。针对这个问题，我们转向微调。

微调

为了解决学习到的记忆问题，许多开发者会在较小、特定领域的数据集上继续 LLM 的训练过程，以针对特定任务进行优化。此过程称为微调 (Fine-tuning)。

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

• 提高特定任务的模型准确性：通过向模型展示许多正确执行该任务的示例，利用特定任务的数据进行训练，以解决学习记忆问题。
• 提高模型效率：以更少的 Token 或使用更小的模型实现相同的准确性。

微调过程从准备训练示例数据集开始——这是最关键的一步，因为您的微调示例必须完全代表模型在现实世界中将看到的情况。

一旦有了这个干净的数据集，您就可以通过执行训练运行来训练微调模型——根据您使用的训练平台或框架，您可能有一些可以调整的超参数，类似于任何其他机器学习模型。我们始终建议保留一个独立集用于训练后的评估，以检测过拟合。有关如何构建良好训练集的提示，您可以查看我们微调文档中的指南。训练完成后，新的微调模型即可用于推理。

对于微调优化，我们将重点关注我们在 OpenAI 模型定制服务中观察到的最佳实践，但这些原则同样适用于其他提供商和开源方案。此处需要遵循的关键实践是：

• 从提示工程开始：拥有一个可靠的、来自提示工程的评估集，您可以将其作为基准。在您确信基础提示词效果之前，这是一种低投入的方法。
• 从小处着手，注重质量：在基础模型之上进行微调时，训练数据的质量比数量更重要。从 50 个以上的示例开始，进行评估，如果尚未达到准确度要求，且导致错误答案的原因是由于一致性/行为而非上下文，则再增加训练集规模。
• 确保示例具有代表性：我们看到的最常见陷阱之一是缺乏代表性的训练数据，即用于微调的示例在格式或形式上与 LLM 在生产中看到的有细微差别。例如，如果您有一个 RAG 应用程序，请使用带有 RAG 示例的数据对模型进行微调，这样它就不会试图学习如何零样本使用上下文。

结合所有方法

这些技术是叠加的——如果您的早期评估显示上下文和行为都存在问题，那么最终的生产解决方案很可能需要结合微调 + RAG。这没问题——它们通过相互补充来弥补彼此的弱点。一些主要好处包括：

• 使用微调来最小化提示工程中使用的 Token，因为您可以用大量的训练示例来取代指令和少样本示例，从而将一致的行为植入模型中。
• 通过大规模微调教授复杂的行为。
• 使用 RAG 来注入上下文、最新的内容或您的用例所需的任何其他专用上下文。

# One training example
SYSTEM: The following sentences contain Icelandic sentences which may include errors. Please correct these errors using as few word changes as possible.
USER: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum í heiminum."
ASSISTANT: "Hið sameinaða fyrirtæki verður einn af stærstu bílaframleiðendum heims."

现在您应该对 RAG 和微调有了更深的理解，以及何时使用它们。关于这些工具，您最后应该了解的是，一旦引入它们，迭代速度就会面临权衡。

• 对于 RAG，您不仅需要调整检索，还需要调整 LLM 行为。
• 对于微调，当您进行额外调整时，需要重新运行微调过程并管理训练和验证集。

这两者都可能是耗时且复杂的过程，当您的 LLM 应用程序变得更加复杂时，可能会引入回归问题。如果您从本文中只能记住一件事，那就是在追求更复杂的 RAG 或微调之前，尽量利用基础方法榨取尽可能多的准确性——让准确性目标成为目标，而不是因为 RAG 和微调被认为“最先进”就盲目追求它们。

多少准确性才“足以”投入生产

针对准确性进行调优对于 LLM 来说可能是一场永无止境的战斗——使用现成的方法，它们不太可能达到 99.999% 的准确度。本节旨在决定何时达到准确度目标即足够——您如何让自己对将 LLM 投入生产感到安心，以及如何管理您发布方案的风险。

我认为在商业和技术背景下考虑这一点很有帮助。我将描述管理这两者的高级方法，并使用客户服务帮助台用例来说明我们在两种情况下如何管理风险。

商业

对于企业来说，在经历了基于规则或传统机器学习系统（甚至是人类！）的相对确定性之后，很难信任 LLM！一个失败结果不确定且不可预测的系统是一个难以调和的矛盾。

我看到的一种在客户服务用例中取得成功的管理方法如下：

首先，我们识别主要的成功和失败案例，并为它们分配预计成本。这清晰地阐述了根据试点表现，该解决方案可能节省或花费的成本。

• 例如，一个 AI 解决的案例，如果之前由人工解决，可能会节省 20 美元。
• 如果某人本不该升级给人工却升级了，可能花费 40 美元。
• 在最坏的情况下，客户对 AI 感到失望而流失，损失我们 1000 美元。我们假设这种情况在 5% 的情况下发生。

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

• 纯人工交互与 AI 交互的 CSAT（客户满意度）分数。
• 对回顾性审查案例进行的人工与 AI 的决策准确性。
• 人工与 AI 的解决时间。

在客户服务示例中，这帮助我们在进行了几次获得清晰数据的试点后，做出了两个关键决定：

1. 即使我们的 LLM 解决方案升级到人工的比例比预想的要多，它在运营成本上也比现有解决方案节省了巨大开支。这意味着即使 85% 的准确率也可以接受，如果那 15% 主要是早期的升级。
2. 对于失败成本非常高的场景，例如欺诈案例处理错误，我们决定由人工主导，AI 作为辅助。在这种情况下，决策准确性统计数据帮助我们决定不支持完全自主处理。

技术

在技术层面，这就更清晰了——现在业务部门清楚了他们预期的价值和潜在的成本，您的职责就是构建一个能优雅地处理失败，且不破坏用户体验的解决方案。

让我们再次使用客户服务示例来说明这一点，假设我们有一个在确定意图方面准确率为 85% 的模型。作为技术团队，这里有几种我们可以最大限度减少那 15% 错误影响的方法：

• 我们可以对模型进行提示工程，要求它在信心不足时提示客户提供更多信息，因此我们的初次准确率可能会下降，但给予 2 次尝试机会后，确定意图的准确率可能会更高。
• 我们可以给二线助手提供回到意图确定阶段的选项，这让用户体验具备了一种自我修复能力，代价是额外的一点用户延迟。
• 如果意图不明确，我们可以对模型进行提示工程，要求其转接给人工，这在短期内消耗了一些运营节省，但可能在长期内抵消了客户流失风险。

这些决定随后反馈到我们的用户体验设计中：速度变慢以换取更高的准确性，或者进行更多人工干预，这些都反馈到上述商业部分的成本模型中。

您现在拥有一种拆解商业和技术决策的方法，能够设定基于商业现实的准确性目标。

继续前行

这是一个关于如何思考最大化 LLM 准确性、可使用的工具以及如何决定生产环境准确度的高级心智模型。您已经具备了持续投入生产所需的框架和工具，如果您想从他人的成功案例中获得灵感，请看看我们的客户故事，像 Morgan Stanley 和 Klarna 等用例展示了通过利用这些技术所能取得的成就。

祝您好运，我们期待看到您用它构建出精彩的作品！