软件工程3.0实践之路（二）：实施策略和技术路线图
（5步实施LLM）
软件工程3.0实践之路（一） 是开篇，描述了软件工程3.0的开发范式、大模型（LLM）赋能软件工程的技术框架，侧重呈现了LLM在软件研发中的应用状况和带来的效率提升。这一篇继续讨论如何实施软件工程3.0，主要体现在实施策略和技术路线图上，而针对需求、设计、编程、测试、运维等各项具体工作中如何运用LLM，将从第3篇开始讨论。
1. 实施策略
开始将LLM应用于软件研发过程中，除了先在一些项目进行试点成功之后再铺开，我们还需要考虑自己企业所处的行业、企业规模、人才储备、模型训练能力等因素，制定适合自己企业的实施策略。这里就不考虑从基础模型开始建自己的AI基础设施，基础大模型只适合几个有实力的企业，在过去1-2年竞争者，形势比较明朗了，如华为、百度、阿里、讯飞、智谱等训练出来的大模型。对绝大多数的企业，都不需要从基础模型开始，而是选择基础模型（国内商用的或开源的），在此基础上训练贴近自己业务的研发大模型（包括代码大模型、测试大模型等）。
在讨论实施策略前，先打消人们对LLM技术应用的安全风险的担心。人们谈到AI/LLM安全和伦理风险时，往往是指AI/LLM应用的问题（如AI造假、应用被攻击/越狱等），而不是指软件研发中应用LLM技术的风险。当我们使用的是第3方LLM API服务时，安全风险的确存在，但是，数据资产的泄漏并不是像许多人说得耸人听闻的事情。我们需要注意保护关键业务的数据，而许多应用场景还是相对比较安全的，例如我们使用openAI GPT服务时，而OpenAI专注做自己的事情，不会关注到或使用某个中小企业的数据，而且大模型输出的数据是进行加工的，而不是像搜索引擎那样直接把原始数据推给其他用户。如果觉得国外的服务不敢用，那就使用国内的服务。安全风险总是存在的，如果因为风险存在，就不敢用新的AI技术，那您为什么办企业呢？创办一家企业的道路上，风险不是更大吗？开发一个创新产品，失败的概率也很高，难道我们就不创新了？一个产品经过测试之后，上线后还会存在缺陷，难道产品就永远不上线了？关键还是知道有哪些风险、如何控制风险，将风险降到最低点。如果我们私有化部署LLM，再应用于软件研发中，安全风险是不存在的。
下面就开始讨论软件工程3.0的实施策略。
1）从行业看，如金融行业是强监管行业，那首先就要考虑私有化部署大模型及其应用工具，可以包括国内的商业LLM及其工具、开源的LLM及其工具。如果一般中小企业不在强监管行业，如果想以低成本应用LLM技术或是通过试用了解LLM技术的价值，可以大胆地在软件研发中使用值得信赖的第3方LLM API服务。为了利用已有的数据资产和贴近自己的业务，最终，我们都是要将LLM及其工具进行私有化部署的，这样才能更好地用自己的语料训练出贴合我们业务的领域大模型，也可以绑定我们已有的数据资产，应用RAG（检索增强生成）技术。
（详细可见：技术动态 | 模块化（Modular）RAG 和 RAG Flow、 大模型RAG问答技术架构及核心模块回顾）
2）从企业规模看，大企业有实力构建自己的研发大模型，有完整的一套基于大模型的开发平台，如软件工程3.0实践之路（一）阐述的框架。但未来某些LLM的规模会变小，对算力的要求也不高，推理成本低，中小企业也可以部署自己的应用。
LLM可能会存在两个方向，一个方向是向更大规模（几千亿、甚至几万亿参数）方向发展；另一个方向是向更小规模（几十亿、几亿参数）方向发展。像最近发布的MiniCPM-2B的整体性能超越 Llama2-13B、MPT-30B、Falcon-40B 等模型。经过 DPO 后，MiniCPM 在当前最接近用户体感的评测集 MTBench上，MiniCPM-2B 甚至超越了 Llama2-70B-Chat、Vicuna-33B 等开源大模型。像MiniCPM-2B可以在手机端部署，一台机器就可可持续训练 MiniCPM，断崖式地降低了训练和推理的算力。
所以不久的将来，每家企业都会有能力训练和部署自己的专有模型。
3）人才储备成为企业应用LLM技术的关键因素，有AI方面的人才储备也就具备模型训练能力、模型精调/微调的能力，再加上过去我们已经拥有的知识工程能力、软件工程能力和平台工程能力，然后就可以在原有开发平台、DevOps工具链中集成强大的AI/LLM能力，让LLM在软件研发中的应用顺利落地实施。
概括起来，LLM的应用策略相对比较简单，完成基础大模型的私有化部署，在此基础上训练出（精调/微调）贴合自己业务的研发大模型（代码大模型、测试大模型），并和已有的数字资产集成起来。如果自己缺乏人才储备、缺乏LLM训练和部署的能力，那就寻求外部公司的服务，国内有一些企业可以提供这类服务。如果没有这方面的能力储备且在经济上很难有较大的投入，那就在合规条件下直接使用第三方提供LLM API接入的服务。
（来源：https://llmapi.io/）
2. 技术路线图
在介绍技术路线图前，我们先了解一下LLM在软件研发中究竟能做哪些事情。虽然LLM技术可以在软件研发的各项工作都能发挥作用，但由于目前LLM的能力局限性，根据之前大家的实践经验，我们知道哪些领域更适合LLM发挥作用，而有些领域LLM难以发挥很好的作用。下面这张图，来自信通院云大所的秦老师在“智能化软件工程创新发展论坛”上的分享。从图中可以看出，需求分析和需求文档生成、需求拆分、API/UI设计、代码补全和生成、单元测试、代码解释和检查、测试用例生成、测试分析、测试文档生成等工作上提效显著。
那么我们从哪里开始呢？答案是不是就比较明显了？
如果我们团队从接入LLM API服务开始，相对简单。我们首先需要完成提示工程的建设规划，完成人员基本的培训，设计常用的提示模板，搜集和列出一些典型的例子，然后一面应用、一面提升团队的提示工程能力。(可以参考：https://realpython.com/practical-prompt-engineering/)
如果需要基于自己的研发大模型（含代码大模型、测试大模型）来应用LLM技术，那么我们首先要做的事情是：准备语料、清洗和优化数据，训练和部署贴合自己业务的领域大模型。这样场景正符合软件工程3.0范式，也是几年后一种常见的软件研发场景。
（来自WakeData的钱勇老师在AiDD的分享）
同时要开发相应的工具或IDE插件（像chatGPT、GitHub copilot那样），以支持LLM的应用。在有基本工具或IDE插件支持下，我们就可以在工作中应用起来，同时DevOps平台工程团队可以把这种能力和DevOps工具链集成起来，也可以引入类似LangChain这样的框架和RAG技术，集成已有的数字资产，并解决或缓解tokens 受限、短记忆、幻觉等问题。
（来源：https://www.langchain.com）
之后，我们就可以全力在需求定义、编程、测试等活动中使用。考虑到上一篇文章所介绍的调查数据看，开发、测试的效率提升更明显，而且测试效率更高一些（43%），生成测试计划、测试用例或测试脚本，也相对安全，毕竟不是产品代码。基于过去的经验，我们也知道测试人员相对比较少但任务重，常常是持续交付的瓶颈，所以首先在测试工作中应用LLM。如果可能，我们优先训练出适合自己的测试大模型，主要语料来源于需求文档、测试计划文档、测试用例、测试脚本、缺陷报告、测试报告等。
（LLM赋能测试：来自信通院云大所秦老师的分享）
第二步就扩展到编程相关的活动，包括代码补全和生成、单元测试、代码解释和检查。毕竟代码数据质量高，而且研发主体中开发人员是最多的，所以在开发上应用LLM是关键性战役，我们必须打赢。具体实施，后续会有专门写1-2篇文章介绍。
在完成了“编程、测试”两项最具价值的任务之后，第3步、第4步、第5步就扩展到需求、设计和运维等工作中去，可以理解为 “LLM左移”、“LLM右移”，完成端到端的全面应用。
第3篇就开始讨论“LLM赋能测试”，然后再讨论 “LLM赋能开发”、“LLM赋能需求工程”、“LLM赋能设计”、“LLM赋能运维”。