大模型应用优化最佳路径：提示工程、RAG还是微调？

在上一篇文章《GitHub Copilot产品经理和微软MVP告诉你：企业是否需要训练自己的代码大模型？》中，我们以GitHub Copilot为案例，梳理了企业进行私有化模型训练的六个基本要素。但说实话，那个话题聊得并不完整。 企业内部沉淀了大量私域数据，这是客观现实。从代码生成的角度看，私有框架、公共代码组件、内部编码规范、接口定义、业务逻辑——这些内容真实存在，即便不适合走私有化训练这条路，也必须找到有效的方式来应对。 这一篇，我们来聊聊大模型领域里三个高频词汇：**提示词工程、RAG（检索增强式生成）和模型微调**。重点不是单纯解释它们是什么，而是理清三者之间的关系。对于企业技术管理者而言，更重要的是：如何构建一套机制，让企业具备对大模型应用这种全新类型进行持续改进的能力。 这篇文章的内容，延续了与几位关键人物的对话——微软全球副总裁Julia Liuson（潘正磊）、GitHub Copilot产品经理Ryan J. Salva、GitHub Next团队负责人Idan Gazit。同时也参考了OpenAI DevDay的部分视频资料和技术文档，文末会一并列出。除此之外，大量内容源自团队在AISE和SmartCode开发过程中的一手经验。希望对大家有所启发。 企业引入AI能力，已经是所有管理者绕不开的话题。但很多人没有意识到：AI能力不是独立存在的，它需要融入现有的管理和工程场景，用全新的方式去重构这些场景，最终演化出我们从未见过的新形态。 延续上一篇中“电和电器”的比喻：大模型是电，企业应用就是各式各样的电器。 这意味着，大模型应用不会是独立的系统，而是为现有系统注入新能力。它的影响会从一些显而易见的场景开始，逐步蔓延到那些我们现在还想象不到的领域。这个过程几乎需要企业里所有人的参与。对管理者来说，真正的关键问题在于：如何构建一套适合AI时代的企业IT系统演进策略与路线图。 --- ## 大模型应用工程能力建设（SE4AI） 回到大模型应用系统的构建问题。即便企业不符合那六个私有化训练的基本要求，让模型适配企业私有代码，依然是我们必须解决的问题。 企业需要的是定制化的大模型应用方案，模型训练只是其中一条路径。只有对所有可行技术路线有充分认知，才能找到更高效、可扩展、经济可行的方案。 下图整理的是**大模型应用的工程能力建设**整体思路： （图片：SE4AI框架图） 构建大模型应用，本质上是一个典型的迭代过程。要从应用场景出发，先搞清楚“我们要做什么”，再去优化性能、质量和用户体验。企业引入大模型也是一样——不能只把电缆拉到家里，却没有电器。当前市场最大的问题是，真正能落地的大模型应用太少。因为“电压”不稳定（模型输出不稳定），“发电厂”也不够（GPT国内用不了，开源模型和国内商用模型在部署时又缺算力），很多应用场景还停留在探索阶段。 在众多应用中，**AI智能编码**是少数已被证明可以落地的场景。GitHub Copilot是全球第一款真正拥有百万级付费用户的大模型应用，它证明了AI编码确实能大幅提升开发效率、解决实际问题。以下数据来自2022年的开发者调研： （图片：调研数据图） 与其他类型的大模型应用不同，GitHub Copilot在ChatGPT出现之前就已经正式投入使用，到现在迭代了近三年。微软和GitHub在这个过程中积累了大量的实践经验。在这次与GitHub产品总监Ryan J. Salva沟通后，对GitHub Copilot如何同时利用提示词工程、RAG和模型微调三种方法，持续优化代码生成效果的过程有了更深的理解。下面是对这三种方法的优缺点及综合运用方式的总结。 --- ## 两个优化维度 如果你用过任何大模型应用，会发现这类应用有两个显著特点： 1. **不确定性**：和传统应用不同，模型的输出是不确定的。即便输入完全一样，它也会给出不同的回答。日常聊天场景下这没什么，但要用在企业里处理具体业务，就必须提升稳定性。 2. **静态性**：模型一旦训练完成，就无法再补充数据。所以模型不会知道你公司内部的年假规定、代码规范。如何让大模型掌握这些数据，是另一个需要解决的问题。 针对这两点，参考开头的路线图，大模型应用的优化有两个关键维度。基于这两个维度的综合优化，可以持续改进应用的性能、质量和用户体验。 - **行为优化**：关注模型的行为，教会它按我们希望的方式做事——包括输出内容的格式、语气、偏好，甚至生成固定格式的请求以便调用其他服务。这个维度主要解决输出形式上的稳定性。 - **上下文优化**：关注私域数据，让模型知道它所不知道的事情——比如训练中从未见过的内部代码、文档、规范、策略。这个维度主要解决输出内容上的相关性。 --- ## 三个优化方法 提示词工程、RAG和模型微调，分别能解决输出形式稳定性和内容相关性的问题，但各自的侧重点不同。 ### 方法1 - 提示词工程（Prompt Engineering） 这是最经济可行、见效最快的方式。在生成式AI领域，常听到的**零样本/多样本学习**或**上下文引导学习**，其实都是提示词工程中的具体技巧。 在实际应用中，应该优先考虑使用提示词工程来优化大模型应用——成本最低，见效最快。**提示词工程可以同时为模型补充上下文（上下文优化）和优化模型行为（行为优化）**，因此在两个维度上都能帮助我们提升性能、质量和用户体验，更快达成目标。对任何应用场景，都不建议在还没尝试提示工程的情况下，就直接引入RAG或微调。 在AISE和SmartCode的研发过程中，团队已经形成了一套标准化的优化流程：先定义应用场景，然后优先调试提示词——只有当提示工程无法达到预期效果时，才会引入RAG或微调。 另外，由于大模型应用场景众多，用户会不断提出各种场景需求，最好的做法是把提示工程的能力直接交给用户。简单说，就是提供用户可以自助创建的提示词模板功能模块，允许他们在内部互相分享模板，最后监控模板的使用情况，把那些有共性的模板升级为系统级甚至内置的模板。很多时候，用户经过摸索，很快就能构建出高效的提示词解决自己的问题。作为应用系统，我们需要提供这种能力，而不是把各种提示词都封装起来，不让用户触碰。提示词模板本身就是一种和大模型沟通的工具，用户在问题驱动下构建出的模板，往往简单又高效。 当然，提示词模板也可能变得非常复杂。当你发现模板越来越长、越来越复杂，却仍然无法满足要求时——这就是引入RAG或微调的信号。 ### 方法2 - 检索增强式生成（RAG） **RAG不是某种系统、工具或产品，而是一种为模型补充知识的方法。** 任何大模型一旦训练完成，就变成了一个静态文件，只存储了训练过程中提供给它的知识。所以当你问ChatGPT自己公司内部年假的相关规定，它必然无法准确回答，甚至可能给出误导性答案。 解决这个问题的最简单方式，就是先告诉大模型这些规定，再让它回答——这就是提示词工程中的**多样本学习**。同时，**大模型是没有记忆的**，你提出的每一个问题，对它来说都是全新的。你可能会觉得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） 业界有各种不同的说法：迁移训练、再训练、微调。甚至有人把数据嵌入也叫作“训练”，这其实是种误导。**微调之所以叫微调，是因为它不是在零基础上开始的——而是基于一个预训练好的基础模型，通过继续训练来调整模型行为。** 这个过程所使用的数据量，远小于预训练模型所需的数据量（大约是基础训练量的1%左右），只需要能在一定程度上改变模型的行为就够了。**微调主要用于调整模型的行为，虽然也能通过这个过程为模型补充数据，但并不能保证模型一定会按照补充的数据回答问题——因为模型不是一个确定性系统。** 这种调整需要建立在模型本身已经具备的能力之上，这个过程和我们说的“熟能生巧”“举一反三”很像。 举个例子：小学生学习二元一次方程的解法。要学二元一次方程，首先得学会基本的数字、大小的概念和基本的运算能力。这个获得基础能力的过程，就像预训练基础模型。当小朋友做了足够多的基础运算题后，会对基础运算产生认知能力。有了这个基础认知能力，再通过一些例子帮小朋友建立对未知数的认知，同时配合练习，把未知数和整数、小数、分数这些基础数字混合起来运算，这样小朋友就会产生对二元一次方程的认知能力——后面这个过程其实就是微调。我们在学习数学时也会发现，掌握更复杂运算方式所需要的练习量会逐步减少。但无论如何，即使数学基础再好，要掌握一种新运算，都需要一定的练习量。 机器学习技术作为生成式AI的基础，本质上是建立在模仿人类认知基础上的。 （图片：微调示意图） 对模型进行微调，最重要的就是数据的准备和处理。你需要对自己的微调目标有清晰认知，微调工程师需要充分理解每一条数据应该得到怎样的结果——因为所有训练数据都是为了让模型去模仿，以便在生成下一个token时，增强你所希望生成内容的概率。从这个角度看，仅仅具备数据科学背景的工程师，不足以完成特定领域的模型微调。团队必须同时具备数据科学背景和微调相关的领域知识，才能有效完成微调。比如在AI辅助智能编码领域，就需要数据科学工程师和软件工程/DevOps工程师的配合。 --- ## 如何选择提示工程、RAG或微调 这三种方法不是非此即彼的关系，而是相互配合的关系。 对任何问题，我们都建议从提示工程开始。经过一段时间的优化后，如果发现提示词已经变得非常复杂，甚至模板内容都快占满整个模型输入窗口，但仍然无法获得稳定的输出，那就该考虑用微调或RAG来解决问题了。 判断后续路线的标准其实不复杂，只需要关注提示工程产出的提示词模板的一些特性： - 如果模板中大部分内容是模型不知道的知识，这些知识来自其他数据源，而且内容在不停变动，以至于你不得不创建多个不同模板来应对不同场景——那么该引入RAG进行下一步优化了。 - 如果模板中大部分是各种格式的示例，你的目的是让模型模仿这些示例来输出内容，但即便示例占满了模板，模型输出仍然不够稳定——那么该引入微调进行下一步优化了。 提示工程可以同时解决知识和行为的问题，但受限于模型的数据窗口大小。RAG擅长补充知识，但不擅长改变模型行为。微调可以改变模型行为，但不适合补充知识。 复杂的提示词还会消耗大量token，降低模型响应速度（如果使用按token收费的模型服务，成本也会增加）。采用微调方式，可以将特定任务固化在模型中，后续调用速度大幅提升，也更节省token。不过，微调过程会产生一次性的较大成本投入，更适合那些高频的固定任务。在**AI辅助智能编码**领域，我们通常针对代码解释、代码纠错、单元测试生成这些场景进行微调，以实现更优的性能、输出稳定性和更友好的输出格式。 在具体应用场景的实践中，应根据实际需要组合使用三种方法。具体是否要走到RAG、微调，或RAG+微调，取决于应用验证的结果。对日常使用来说，用户感觉好用，往往就可以作为完整结果了。但对于企业应用的工程化方法，我们需要可评估的量化标准。 --- ## 大模型应用验证（测试） 大模型应用效果的验证，和传统软件的评估方式很不一样。因为大模型本身的通用性和非确定性，即便是一个特定场景，我们无法穷举所有输入可能性；对于同样的输入，也无法确定模型的标准化输出。这种通用性和不确定性，决定了传统测试方法对大模型应用无法直接使用，我们必须探索适合大模型应用的验证/测试方式。 （图片：验证对比图） 以下图这个场景为例，我们给模型输入了完全一样的提示词：“如何计算等边三角形的面积，请使用Python代码生成一个计算方法”。但模型的输出却不完全一致。如果仔细阅读输出，会发现虽然格式、内容有所区别，但关键部分和核心含义是一致的。注意：这个测试使用的是同一个模型。 简单来说： - **传统应用是确定性的**：同样的输入一定有同样的输出。 - **大模型应用是不确定性的**：同样的输入不一定有同样的输出，不同的输入也可以有同样的输出。输出的内容虽然不相等，但含义一致。 充分认识到这种差异，我们才能有针对性地重构传统测试和验收方式，以适应大模型应用的特点。传统软件工程中的自动化测试、CI/CD流水线、单元测试等实践，对大模型应用仍然有效。但我们需要重构这些流程中所使用的工具和方法。比如针对大模型应用的单元测试，我们仍然可以采用define-exec-eval的模式进行用例设计，但define和eval步骤的实现方式都需要重构： - **Define**：测试目标的定义，传统上是尽量穷举所有测试场景，这在确定性系统中是可行的。但大模型应用面对的场景与传统应用截然不同。比如“大模型应用帮我们分析软件需求”这个场景，传统方法根本无法穷举。同样，传统软件应用中也不会提出这类场景，因为常识告诉我们它不可行。 - **Eval**：测试验证环节的差异更明显。由于大模型输出的不确定性，同样的输入会产生每次都不一致的输出，这些输出在形式、用词、格式上有所区别，但语义上存在联系。传统的基于等式的验证方式，显然无法适应这种输出特性。 大模型的应用验证，是AI时代带来的全新软件工程问题。业界普遍有三种实现路径：**基于统计学算法的验证方式、基于模型的验证方式、人工验证。** - **基于统计的验证方式**：使用一些算法来验证模型输出与预期结果的相似度。代表性方法包括：BLEU、ROUGE、METEOR、Levenshtein distance等。 - **基于模型的验证方式**：用大模型来验证大模型的输出。相比统计方法，普适性更好，但在系统构建、运行效率和成本上会带来更大挑战。代表性框架包括：RAGUS、DeepEval等。 - **人工验证**：让测试人员或用户直接对模型输出进行反馈和打分。虽然效率最低，但却是目前最准确的评估方式——毕竟大模型应用的最终用户是人，人的智能足以应对模型输出的不确定性。 另外，针对RAG和微调两种路径，验证的方式和采用的指标也有所不同。以下列出一些常见验证指标供参考： - 相关性 - 总结能力 - 偏见度 - 毒性 - 友好度 - 伤害性 - 遵从性 - 幻觉程度 大模型应用验证，是SE4AI领域一个比较有代表性的工程问题。在面向大模型应用的交付流水线中，还有很多其他环节也需要用同样的思路进行重构。 --- ## 小结 本文延续模型私有化训练的话题，对当前常见的大模型应用优化方式——提示词工程、RAG和模型微调的优缺点进行了分析和比较。需要明确的是，这三种方式不是孤立的、互斥的，而是相互推动的。企业大模型应用的最终形态，往往是这三种方法综合使用的结果。