优化 LLM 准确性

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

优化 LLM 并不容易。

我们与许多来自初创公司和大型企业的开发者合作过，发现优化的难点始终集中在以下几个问题上：

• 知道 如何着手 优化准确性
• 何时使用哪种 优化方法
• 准确性达到什么水平才 足以满足 生产环境的要求

本文提供了一个心智模型，帮助您理解如何优化 LLM 的准确性和行为。我们将探讨提示工程、检索增强生成（RAG）和微调等方法，也会重点介绍各项技术的使用方式和适用时机，并分享一些常见误区。

阅读时，请结合您的具体使用场景中对准确性的定义来理解这些原则。这看起来可能显而易见，但生成一份需要人工修改的劣质文案，与本应向客户退款 $100 却退了 $1000，后果截然不同。在讨论 LLM 准确性之前，您应该大致了解：LLM 每失败一次会带来多少成本，每成功一次又能节省多少成本或创造多少收益。本文结尾讨论准确性达到什么水平才足以满足生产环境要求时，会再次谈到这个问题。

LLM 优化的整体框架

许多优化操作指南将其描述为一个简单的线性流程：先做提示工程，再做检索增强生成，最后做微调。但实际情况往往并非如此。这些方法解决的是不同问题，要沿着正确的方向优化，就需要选对方法。

将 LLM 优化看作一个矩阵，会更有助于理解：

典型的 LLM 任务会从左下角的提示工程开始，通过测试、学习和评测建立基线。审查这些基线示例并分析出错原因后，我们就可以选择以下一种优化手段：

• 上下文优化： 在以下情况下，您需要优化上下文：1）模型的训练集不包含相关知识，导致模型缺乏所需的背景知识；2）模型的知识已经过时；或 3）任务需要专有信息。这一维度旨在最大限度地提高 回答准确性。
• LLM 优化： 在以下情况下，您需要优化 LLM：1）模型生成的结果不一致，且格式有误；2）语气或表达风格不符合要求；或 3）模型无法始终遵循所需的推理过程。这一维度旨在最大限度地提高 行为一致性。

在实践中，这会形成一系列优化步骤：先评测，再提出优化假设并付诸实施，然后再次评测，根据结果重新判断下一步该怎么做。下面是一个较为典型的优化流程示例：

在这个示例中，我们会执行以下步骤：

• 从一个提示开始，然后评测其效果
• 添加静态少样本示例，这应该能提高结果的一致性
• 添加检索步骤，根据问题动态引入少样本示例，确保每次输入都获得相关上下文，从而提升效果
• 准备一个包含 50 个以上示例的数据集，并微调模型以提高一致性
• 调整检索，并添加事实核查步骤来发现幻觉，从而提高准确性
• 使用包含改进后 RAG 输入的新训练示例，重新训练已微调的模型

这是解决复杂业务问题时较为典型的优化流程，有助于我们判断：需要的是更多相关上下文，还是更一致的模型行为。做出判断后，我们就知道该选择哪种手段作为优化的第一步。

有了这个心智模型，接下来我们将详细介绍如何在各个方面开展优化。先从左下角的提示工程开始。

提示工程

提示工程通常是最佳起点**。对于摘要、翻译和代码生成等使用场景，零样本方法就能在准确性和一致性上达到生产环境要求，因此往往只需使用提示工程。

这是因为提示工程要求您明确使用场景中对准确性的定义：您从最基本的输入开始，因此必须能够判断输出是否符合预期。如果输出不符合要求，找出 原因 就能帮助您确定接下来该用什么方法优化。

为此，您应该始终从一个简单的提示开始，并明确预期输出，然后通过添加 上下文、 指令或 示例 来优化提示，直到获得所需的结果。

优化

在优化提示时，我将主要采用 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 等方法进行粗略判断。这些方法的结果与人工评审的相关性并不算高，但可以快速、有效地衡量一次迭代使模型输出发生了多大变化。
• 按照 G-Eval 论文介绍的方法，使用 GPT-4 作为评估器，向 LLM 提供评分表，让它尽可能客观地评估输出。

如果您想进一步了解这些方法，请参阅这篇 Cookbook，其中通过实践逐一介绍了这些方法。

了解工具

您已经做了提示工程，也有了评测集，但模型仍然无法满足需求。接下来最重要的是诊断它在哪些方面出了问题，以及哪种工具最适合改善这些问题。

下面是一个基本的分析框架：

您可以尝试将每个回答错误的评估问题归为 上下文 记忆问题或 习得 记忆问题。打个比方，假设您正在参加考试。要确保答对题，您可以采取两种方式：

• 您在过去 6 个月里一直上课，反复接触了许多说明某个概念如何运作的示例。这就是 习得 记忆。对于 LLM，解决这类问题的方式是向模型展示提示和预期回复的示例，让它从中学习。
• 您随身带着教科书，可以查找答题所需的正确信息。这就是 上下文 记忆。对于 LLM，我们通过将相关信息放入上下文窗口来解决这类问题：既可以用提示工程静态添加，也可以用 RAG 实现规模化处理。

这两种优化方法 可以叠加，并不互斥 。它们能够配合使用，而且有些使用场景需要将两者结合才能获得最佳效果。

假设我们面临的是短期记忆问题，接下来我们将用 RAG 来解决它。

检索增强生成（RAG）

RAG 是指先 检索内容，用它来 增强 LLM 的提示，再 生成答案的过程。它让模型能够 获取特定领域的上下文 ，以完成任务。

RAG 是提高 LLM 准确率和一致性的有力工具。在 OpenAI，许多规模最大的客户部署仅使用提示工程和 RAG 就已实现。

在这个例子中，我们已将一个统计数据知识库转换为嵌入向量。当用户提问时，我们将问题也转换为嵌入向量，然后从知识库中检索最相关的内容。这些内容会被提供给模型，由模型回答问题。

RAG 应用引入了一个新的优化维度：检索。要让 RAG 发挥作用，我们需要向模型提供正确的上下文，然后评估模型是否回答正确。下面我用一个矩阵来展示思考 RAG 评估的一种简单方式：

您的 RAG 应用可能在两个环节出问题：

这里的关键在于，原则与开头的思维模型一致：通过评估找出问题，再采取优化措施加以解决。采用 RAG 后，唯一的区别是您还需要考虑检索这一维度。

RAG 虽然有用，但只能解决上下文学习方面的问题。在许多使用场景中，真正的问题是如何确保 LLM 学会一项任务，并能一致、可靠地执行它。对于这类问题，我们采用微调。

微调

为了解决习得记忆问题，许多开发者会在规模较小的领域专用数据集上继续训练 LLM，针对特定任务进行优化。这个过程称为 微调。

微调通常出于以下两个目的之一：

• 提高模型在特定任务上的准确率： 使用特定任务的数据训练模型，向它展示大量正确执行该任务的示例，以解决习得记忆问题。
• 提高模型效率： 使用更少的 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 + FT 被认为是最先进的方法就急于采用。

准确率达到多少才足以用于生产环境

提高 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 等案例展示了运用这些技术能够取得的成果。

祝您一切顺利，我们期待看到您运用这些方法构建的成果！