提示工程、RAG和微调 - 哪个才是大模型应用优化的最佳路径？丨IDCF

共 13981字，需浏览 28分钟

· 2024-04-18

点这里👇星标关注，获取最新资讯！

IDCF DevOps

在上一篇文章【GitHub Copilot产品经理和微软MVP告诉你：企业是否需要训练自己的代码大模型？- 微软MVP全球峰会纪行】中，我以GitHub Copilot作为案例，和大家分析了企业进行私有化模型训练的6个基本要素。但这其实是一个未完成的话题。

企业内部存在大量的私域数据是客观事实，从代码生成角度来看，私有的框架、公用代码组件、内部编码规范、内部接口定义和说明以及内部业务逻辑这些内容客观存在；即便不适合采用私有化训练的方式，我们也必须找到解决这些问题的有效方式。

在本篇中，我将延续这个话题和大家聊一聊几个大家在大模型领域经常听到的技术：提示词工程、RAG（检索增强式生成）和模型微调，分析一下这3个技术之间到底是怎样的一种关系。更重要的是，对于企业技术管理者来说，如何构建一种机制，让企业内部具备应对大模型应用这种全新应用类型的持续改进机制。本篇的内容仍然是基于我和前文提到的三位重要人物的对话，包括：微软全球副总裁Julia Liuson 潘正磊，GitHub Copilot的产品经理 Ryan J. Salva，GitHub Next 团队的负责人 Idan Gazit ；我也参考了OpenAI DevDay上的一些视频和其他一些技术资料，都列在本文的结尾，供大家翻阅；除了这些参考，本文的大部分内容也是基于我和我的团队在AISE和SmartCode开发过程中的经验整理而成。希望对大家有所帮助。

GitHub Copilot产品经理和微软MVP告诉你：企业是否需要训练自己的代码大模型？丨IDCF

IDCF DevOps

在企业中引入AI能力是当前所有企业管理者都在考虑的问题，但并不是所有人都意识到，AI能力不是独立的，它需要融入到企业现有的管理和工程场景中，用全新的方式重构这些场景，最终演化出我们从未见过的新场景。

延续上一篇中有关电和电器的比喻，大模型是电，企业应用就是各种电器。

因此，大模型应用不会是独立的系统，而是为现有的系统注入新的能力，它的影响面会从一些当前显而易见的场景逐渐蔓延到那些我们现在还想不到的部分。这个过程需要企业内几乎所有人都参与其中。对于企业管理者而言，如何构建一套AI时代下适合企业IT系统演进的全新策略和路线图，才是真正的关键问题。

大模型应用工程能力建设（SE4AI）

回到大模型应用系统制定问题。即便企业不符合上文中提到的 6个私有训练的基本要求，让模型能够适应企业的私有代码仍然是我们需要解决的问题。

企业需要的是定制化大模型应用方案，而模型训练只是其中一条路径而已，我们需要对所有可行的技术路线有充分认知，才能找到更加高效、可扩展、经济可行的最适合企业的方案。

下图我们整理的 大模型应用的工程能力建设 整体思路：

构建大模型应用是一个典型的迭代过程，这个构建过程需要从应用场景出发，先搞清楚我们要做什么，然后再去优化大模型应用系统的性能、质量和用户体验。企业引入大模型更是如此，不能只把电缆接到家里，没有电器设备，电没有任何价值。当前市场最大的问题是，真正能够落地的大模型应用太少，因为“电压”不稳定（大模型的输出不稳定），“发电厂太少”（GPT国内用不了，开源模型和国内商用模型在内部部署又缺少算力），所以很多应用场景还处于探索阶段。

在众多应用中，AI智能编码是少数已经被证明的可落地的应用场景，GitHub Copilot实际上就是全球第一款真正具备百万级付费用户量的大模型应用，它本身就已经证明了AI智能编码确实可以大幅提高开发者的工作效率，解决实际问题。以下数据来自2022年的开发者调研 [2]

与市场上其他类型的大模型应用不同，GitHub Copilot 在 ChatGPT 出现之前就已经正式投入使用，到现在为止已经迭代了近3年的时间，微软和GitHub在这个过程中积累大量的实践经验 [3]。在这次和GitHub产品总监Ryan J. Salva沟通之后，对GitHub Copilot 是如何同时应用提示词工程、RAG和模型微调三种方法持续改进代码生成效果的过程有了深入了解，以下是对这三种方法的优缺点以及如何综合利用三种方法的一些总结。

两个优化维度

如果你使用过任何大模型应用，就会发现这类应用有两个特点：1) 不确定性，与传统应用不同，模型的输出是不确定的，即使给它完全一样的输入，它也会给出不尽相同的答复。这种特性对于日常应用业务OK，但是如果要在企业内用来处理具体业务问题，就必须提高这个稳定性。2) 静态性，模型一旦训练好，就无法再补充数据，因此模型不会了解你自己组织内部的年假规定，代码规范。如何让大模型掌握这些数据是另外一个需要解决的问题。

针对这两个问题，参考本文开头的路线图，我们可以看到对于大模型应用的场景优化，有2个关键的优化维度。基于这两个维度的综合优化过程，最终可以推动我们持续改进大模型应用的性能，质量和用户体验。

行为优化：这个维度主要关注模型的行为，是教会模型去按照我们希望方式做事，包括：输出内容的格式、语气、偏好；甚至生成固定格式的请求以便调用其他服务。这个维度主要解决模型输出形式上的稳定性。

上下文优化：这个纬度主要关注私域数据，是让模型知道它所不知道的事情，包括：模型训练中从未见过的数据，比如内部代码、文档、规范、策略等。这个维度主要解决模型输出内容上的相关性。

科技一般指科学技术。社会上习惯于把科学和技术连在一起，统称为科学技术。统称为科学技术，简称科技。实际二者既有密切联系，又有重要区别。

三个优化方法

提示词工程，RAG和模型微调三种方法，可以分别解决输出形式上的稳定性和内容上的相关性问题，但是不同的方法对这两个问题也有不同的侧重点。以下分别解释说明。

方法1 - 提示工程（Prompt Engineering）
这是最经济可行，也是见效最快的方式；在生成式AI（GenAI）这个领域中大家经常听说的 零样本/多样本学习（Zero-short/Few-short learning）或者 上下文引导学习（in-context learnning）其实都是提示词工程中的一些具体方法和技巧。

在实际应用中，应该首先考虑使用提示工程的方式优化大模型应用，这是成本最低，见效最快的方式。提示词工程可以同时为模型补充上下文（上下文优化）和优化模型的行为（行为优化）。因此提示词工程可以同时在以上2个维度上帮助我们提升模型的性能、质量和用户体验，让我们可以更快达到目标。对任何应用场景，我们都不建议在还没有尝试提示工程的前提下就开始引入RAG或者微调。

在AISE和SmartCode系统的研发过程中，我们已经形成一个标准化的优化流程，那就是：先定义好一个应用场景，然后首先进行提示词的调试，只有当提示词工程无法达到预期效果时才会引入RAG和微调。另外，因为大模型的应用场景众多，用户会不停提出各种类型的场景需求，最佳的解决方案是将提示工程的能力直接赋予用户。简单来说，提供用户可自助创建的提示词模板的功能模块，并允许用户自己在内部进行分享这些模板，最后对模板的使用情况进行监控，将那些有共性的模板提升为系统级甚至内置的模板。很多时候，用户经过摸索可以很快构建出高效的提示词解决自己的问题。而作为应用系统来说，我们需要提供的是这种能力，而不是将各种提示词都封装起来不让用户去碰。提示词模板本身就是一种和大模型沟通的工具，用户在问题驱动下构建出的模板非常简单高效。

当然，提示词模板也可能变得非常复杂，当你发现自己构建的模板越来越长，越来越复杂，但是仍然无法满足要求。这就是引入RAG或者微调的信号。

方法2 - 检索增强式内容生成（RAG - Retrieval Augmented Generation）

RAG并不是某种系统/工具/产品，RAG是一种为模型补充知识的方法。首先，任何的大模型一旦训练完成就变成了一个静态的文件，它只存储了在训练过程中提供给它的知识（数据）。因此，当你问ChatGPT自己公司内部有关年假的相关规定，它必定无法准确回答，而且还会给出误导性的答案。

为了解决这个问题，最简单的方式就是先告诉大模型这些规定，然后再让它回答。这种方式就是提示词工程中的多样本学习（few-short learning）。同时，大模型是没有记忆的，你提出的每一个问题其实对他来说都是全新的问题。你可能会觉得ChatGPT是有记忆的，这是因为 ChatGPT 本身就是一个大模型应用（它背后的模型是GPT系列模型，包括：GPT 3.5， GPT4， DALL-E等）OpenAI本身在ChatGPT这个应用层上开发了大量的功能让用户可以更友好的和这些模型进行交互。因此，ChatGPT会帮助用户存储对话历史，并在你发送新的问题的时候将历史记录插入对话消息中，这样模型才知道你之前跟他说过的内容。在我们使用ChatGPT的过程中，它后面的大模型其实并不知道在和谁进行对话，而是机械快速的处理着一次次完全互不相干的请求。回到模型记忆的问题，ChatGPT的这种做法问题也很明显，当历史消息太多时，消息长度会超出模型能够处理的窗口大小，从而引发上下文丢失的问题，当你持续和ChatGPT对话时，会发现他会逐渐遗忘之前的信息，就是这个原因。

当我们需要为模型提供更多上下文的时候，就需要用到RAG技术。RAG是在给模型发送消息之前首先进行内容检索，从其他数据源把相关的数据先提取出来，然后插入到当前对话消息中给到模型，这样就解决了既要让模型知晓大量它不知道的知识，又避免消息窗口不够的局限。

你可能会问，你这里没有提到数据嵌入（embedding）和向量数据库，也能叫做RAG吗？实际上，只要通过检索的方式为模型补充了上下文数据，就是一种RAG的实现。数据嵌入和向量数据库只是提供了一种基于语义搜索的数据检索方式，虽然这种方式和当前的生成式AI技术有很紧密的联系，但这并不是RAG技术的必要组成部分。

方法3 - 微调 (Fine-tuning）

现在业界有各种不同的说法，比如：迁移训练（Transfer training），再训练（re-training），微调（fine-tuning）。甚至很多人会将数据嵌入（embedding）也称为训练，这其实是一种误导。微调之所以称为微调，就是因为微调不是从零开始，是基于一个预训练好的基础模型通过继续训练来调整模型行为的方式来完成的。这个过程所使用的数据量远远小于预训练模型所需要的数据量（基本在基础训练量的1%左右 [5]），只需要能够可以在一定程度上改变模型的行为就够了。微调的作用主要是对模型的行为进行调整，虽然也可以通过这个过程为模型补充数据，但是并不能保证模型就一定会按照你补充的数据回答问题，因为模型并不是一个确定性系统。这种调整需要构建在模型本身已经具备的能力上，这个过程和我们所说的熟能生巧和举一反三的过程很像。

我们以小学生要学习二元一次方程的解法为例，要学习二元一次方程那么首先需要学会基本的数字，大小的概念和基本的运算能力。这个获得基础能力的过程有点像预训练基础模型，当小朋友做了足够多的基础运算题目以后，会对基础运算产生认知能力。有了这个基础认知能力，再通过一些例子帮助小朋友建立对未知数的认知，同时配合一些练习来使用未知数和整数、小数、分数这些基础数字混合以后进行运算，这样小朋友就会产生对二元一次方程的认知能力。后面这个过程其实就是微调过程。我们在学习数学的过程中会发现，自己在后来掌握更加复杂的运算方式所需要的练习数量会逐步减少。但是无论怎样，即使你的数学基础再好，要掌握一种新的运算都是需要一定练习量的。

机器学习技术作为生成式AI的基础，其实就是建立在模仿人类认知的基础上构建的。

对模型进行微调最重要的是数据的准备和处理，你需要对于自己的微调目标有清晰的认知，微调工程师需要充分理解每一条数据应该有怎样的结果，因为所有的训练数据都是为了让模型去模仿，以便可以在生成下一个token的时候增强你所希望生成内容的概率。从这个角度看，仅仅具备数据科学背景的工程师是不足以完成特定领域模型微调的，这个团队必须同时具备数据科学背景和微调相关的领域知识才能有效完成微调操作，比如：在 AI辅助智能编码领域，就需要数据科学工程师和软件工程/DevOps工程师配合。

如何选择提示工程，RAG或者微调

这3个方法不是非此即彼的关系，而是相互配合的关系。对于任何问题，我们都建议将提示工程的方式作为起点，当经过一段时间的优化以后，如果发现提示词已经变得非常复杂，甚至模板内容都已经快要占满整个模型输入窗口，但是仍然无法获得稳定的模型输出，那么就应该考虑采用微调或者RAG来解决问题了。

判断后续路线的标准其实也不复杂，我们只需要关注提示工程产出的提示词模板的一些特性就可以做出明确的判断

如果在模板中大部分的内容是模型不知道的知识，这些知识的内容又来自其他的数据源，知识内容不停变动，以至于你不得不创建多个不同模板来实现不同场景，那么应该开始引入RAG进行下一步的优化。
如果模板中的内容大部分是各种格式的示例，你的目的也是希望模型能够模仿这些示例来输出内容，但是即便这些示例已经占满了模板，模型输出仍然不够稳定，那么应该开始引入微调进行下一步的优化。

提示工程可以同时解决知识和行为的问题，但是会受限于模型数据窗口大小；RAG能解决知识补充问题但是不擅长改变模型行为，微调可以改变模型行为但是不适合为模型补充知识。

复杂的提示词还会消耗大量token，造成模型响应速度降低（如果使用按token收费的模型服务，还会造成成本增加），采用微调方式可以将特定任务固化在模型中，后续调用的速度会大幅提升，也更加节省token。不过，微调过程会一次性产生大额成本投入，更适合那些高频的固定任务。在 AI辅助智能编码 领域，我们一般会针对代码解释，代码纠错，单元测试生成这些场景进行模型微调以实现更优化的性能，输出稳定性和更友好的输出格式。

在具体应用场景的实践中，应该根据特定场景的需要组合使用3种方法，具体是否要走到RAG，微调或者RAG+微调哪个阶段才能达到目标，要根据应用验证的结果而定。对于日常使用来说，用户感觉好用往往就可以作为完整结果了。但对于企业应用的工程化方法，我们需要有可评估的量化标准才行。

大模型应用验证（测试）

大模型应用效果的验证和传统软件的评估效果不同，因为大模型本身的通用性和非确定性，造成即便是一个特定场景，我们无法穷举所有的输入可能性；对于同样的输入，我们也无法确定模型的标准化输出。类似这样的通用性和不确定的特点决定了传统的测试方法对大模型应用是无法直接使用的，我们必须探索一种适合大模型应用的验证/测试方式。

以下图这个场景为例，我们给模型输入了完全一样的提示词：“如何计算等边三角形的面积，请使用Python代码生成一个计算方法”。但是模型给出的输出却不完全一致，如果我们仔细阅读模型的输出，会发现虽然输出的格式，内容有所区别，但是关键部分和核心内容的含义却是一致的。注意：这个测试使用的是同一个模型。

简单来说：

传统应用是确定性的：同样的输入一定有同样的输出
大模型应用是不确定性的：同样的输入不一定有同样的输出，不同的输入也可以有同样的输出，输出的内容虽然不相等但是含义一致。

充分认识到大模型应用与传统应用的不同，我们才能有针对性的对传统测试、验收方式进行重构，以便适应大模型应用本身的特点。传统软件工程中的自动化测试，CI/CD流水线，单元测试等实践对大模型应用仍然有效。但是我们需要重构这些流程中所使用的工具和方法。比如：针对大模型应用的单元测试，我们仍然可以采用 define-exec-eval 的模式进行用例的设计，但是其中define和eval步骤的实现方式都需要进行重构：

Define - 测试目标的定义往往需要我们尽量穷举所有的测试场景，这一点在传统软件工程上是可行的，因为系统本身是确定性；但是在大模型应用上穷举法就是不可行的，因为大模型应用所面对的场景和传统应用场景有非常大的不同。比如：大模型应用可以帮助我们分析软件需求，这样一个场景就是无法通过传统软件工程方法来穷举的，我们必须寻求其他办法；同样，在传统软件应用上，我们也不会提出这类的应用场景，因为依靠常识就知道这种场景是不可行的。
Eval - 在测试验证环节上，这个区别更加明显。因为大模型输出不确定性属性，同样的输入会产生每次都不一致的输出，这些输出虽然在形式/用词/格式上有所区别，他们之间的语义上又存在联系。传统测试基于等式的验证方式明显无法适应这样的输出特性。

大模型的应用验证是AI时代带来的全新的软件工程问题，业界普遍有3种实现路径：基于统计学算法的验证方式，基于模型的验证方式和人工验证。基于统计的验证方式使用一些算法来验证模型输出与预期结果的相似度，有代表性的方法包括：BLEU (BiLingual Evaluation Understudy) ，ROUGE (Recall-Oriented Understudy for Gisting Evaluation) ，METEOR (Metric for Evaluation of Translation with Explicit Ordering)，Levenshtein distance 等等。基于模型的验证方法采用大模型来验证大模型的输出，相比基于统计的验证方法提供更好的普适性，但是在系统构建，运行效率和成本上会带来很大挑战，有代表性的框架包括：RAGUS，DeepEval 等。人工验证就是让测试人员或者用户直接对模型输出进行反馈和打分，虽然这种方法效率更低，实际上却是现在最准确的评估方式，毕竟大模型应用的最终用户是人，人本身的智能足以应对模型输出的不确定性。

另外，针对RAG和微调的两种路径，验证的方式和采用的指标也会有所不同，以下列出一些常见的验证指标，供大家参考：