如何让大语言模型（Large Language Model，LLM）发挥最大的性能？来自OpenAI的微调产品的工程主管人员的经验分享

尽管已经有非常多的人使用ChatGPT提高工作效率，但是在实际的产品中应用大语言模型解决问题还是面临非常多的挑战。如何使用不同的方法最大化利用大语言模型的能力是一种非常重要的技术。在2023年11月的OpenAI第一届DevDay上，OpenAI微调产品的工程主管John Allard分享了来自OpenAI的大模型优化经验。本文做一个总结供大家参考。

[TOC]

为什么大语言模型的优化很困难？

尽管大语言模型的能力很强，但是在不同场景下依然需要有不同的优化技术来提升大模型的效果。但是，优化LLM在实际中挑战很高，主要包括下面三个部分：

信号与噪声分离：在大量数据中识别出对解决特定问题有用的信息（信号），并忽略无关的信息（噪声）。这里主要是指实际情况中，识别什么才是影响大模型性能的关键因素是非常困难的，如何找到这其中的关键信息很难。
性能测量的抽象性：LLM的性能往往难以量化，尤其是在复杂的任务中，确定性能标准和衡量指标可能具有挑战性。这导致我们可能无法预知优化后的模型在实际应用中到底怎么样。
选择合适的方法：即使确定了问题和其严重程度，选择正确的优化方法也是复杂的。不同的问题可能需要不同的技术或方法。

以上三个因素就是影响我们优化大语言模型中最大的三个挑战。

大语言模型的优化流程

在正式介绍OpenAI的优化大模型的经验之前，Colin Jarvis还分享了一个传统的大模型线性优化的思路，如下图所示：

很多人都采用这种流程来优化大模型，即从Prompt工程开始，效果不好之后考虑使用检索增强生成（Retrieval-Augmented Generation， RAG，参考：检索增强生成技术合集——DataLearnerAI），再不行就考虑微调。

但是，Colin Jarvis认为，实际应用中，大语言模型的优化应该是一种反复和多方面考虑的流程，你可能需要同时使用一个或者多个技术一起提升。可以概况如下图所示：

大模型的优化方向主要是两个：一个是提升模型的回复效果，一个是提升模型的上下文长度。在实际的大语言模型优化流程中，应该从下面几个步骤进行：

创建一个Prompt，定义评估方法，然后确定你的基准是什么；
增加更多的案例，使用few-shot，给模型几个输入和输出的样例，告诉模型应该怎么输出，这一般也会大幅提高模型性能；
既然增加few-shot案例可以提升模型的性能，那么在工业界通常会考虑把这个过程自动化，所以一般会选择与知识库结合，也就是使用检索增强生成了。
接下来你可能会发现，虽然与知识库挂钩，但是比方说，它现在有了上下文，但并不是每次都能以我们想要的格式或风格输出，因此我们可能会对模型进行微调。
微调之后可能还会考虑继续优化RAG流程来提升末的性能。
……

以上就是大语言模型优化的一种非常典型的流程。简单概括就是在优化过程中，我们需要考虑尝试一些东西，然后评估，再继续重复这个流程即可。接下来我们详细描述每个阶段可以使用的一些技巧。

如何使用提升工程（Prompt Engineer）优化大模型

提示工程是开始优化LLM的最佳起点，它可以快速测试和学习，为后续优化提供基准。然而，这种方法在引入新信息和处理复杂任务方面有其局限性。正确和有效地使用提示工程是优化LLM过程中的一个关键步骤。

在提示工程中，优化策略主要分为两类，基本的优化策略有四个：即清晰的指令、复杂任务分解成子任务、给GPT思考的时间、系统化地测试变化。在做完这些基本操作之后，可以继续提供额外的知识和工具，让模型来提升效果。

提示工程的基本技巧

这里提到的几个技巧都是最基本的要求，可以有效提升模型的回复质量。主要包括四个：

指令清晰：明确清晰的指令可以帮助模型理解任务；
将复杂的任务分解成简单的子任务：如果任务过于复杂，分解成简单的小任务会有更好的效果；
给GPTs思考时间：经典的think step by step，这种提升会让模型采取更加合理的方式解决问题，提升效果；
系统性测试变化：经常看到客户在评估矩阵中随意更改一些事物，没有系统地测试变化，这是需要避免的。

下面有一个例子：

这是让大模型基于给定的新闻文章抽取有用的信息，但是实际上，这个指令很不清晰，对于什么是有用的信息，以及结构化有什么要求都没有明确，导致模型的输出具有很大的随机性。

经过优化后的Prompt如下：

优化后的Prompt有更加清晰的指令，并且把任务分解成更加简单的结果，给出详细的步骤。然后模型的输出的结果会更加一致和稳定。

提示工程适合和不适合做的事情

当然，提示工程虽然是大模型最开始尝试的事情，但是我们还是应该清楚，哪些事情适合提示工程，哪些不适合。

如下图所示：

提示工程适用（Good for）的情况：
早期测试和学习：提示工程非常适合于LLM项目的早期阶段，可以快速进行测试和学习。
提供性能基准：使用提示工程可以为后续的优化工作提供一个性能基准，帮助评估模型在不同配置下的表现。

提示工程不适用（Not good for）的情况：

需要引入新的大量信息：提示工程在需要大量引入新信息或上下文的情况下效果有限。也就是说，如果需要大量信息才可以让模型理解输出，这就不合适用提示工程。
复杂风格或方法的一致性：对于需要模型以复杂或特定风格一致性回应的任务，仅依赖提示工程可能达不到预期效果。例如，学习一种新的编程语言风格。
最小化tokens使用：在试图解决问题时，不断增加提示的复杂性可能会导致使用更多tokens，这会增加延迟和成本，提示工程在此方面可能不是最佳选择。

总的来说，提示工程是一个有效的工具，特别是在项目的初期阶段，但它在处理更复杂或需要引入大量新信息的任务时可能会遇到限制。在这些情况下，可能需要考虑其他优化方法，如微调（fine-tuning）或检索增强生成（Retrieval-Augmented Generation, RAG）。

提示工程之后的优化应该如何考虑

在这里，Colin Jarvis认为在提示工程不足以解决问题之后，我们还有两个方向来解决问题：一个是基于检索增强生成方法（RAG），一个是大模型微调。

这里举了一个非常简单的例子说明检索增强生成和微调的区别。Prompt工程相当于你让大模型考试。微调就像是你考试之前学习了解决问题的方法和框架，可以用来帮你解决问题。而RAG则像开卷考试，给你一本书，答案就在上面，你需要自己找到书中相关的内容回答问题。这就是两种方法的本质区别。没有方法或者信息，都不可能解决问题。

也有人把这个问题当作短期记忆和长期记忆。RAG是让模型短期有某个知识回答，而微调则是让模型有长期的记忆，有特殊的结构、风格，可以让模型最终可以复现的能力。