微众银行大模型助效研发实践——AI为主角、人为助手的协作模式

微众银行大模型助效研发实践 AI为主角、人为助手的协作模式微众银行：黄叶飞 研发流程面临的主要问题 大模型在研发效能上的初步探索 大模型辅助研发遇到的困难 目录 Agent离不开的RAG Multi-Agents实现研发流程提效 让AI成为主角的人机交互方式 研发流程面临的主要问题？ 复杂 内部研发效率主要体现在其复杂性上：人员、产品、监管事情应接不暇。 研发复杂性所带来人力成本逐步变大，如何解决？ 需求变化 应对快速市场变化，需求变化快，要求交付速度快 复杂流程 银行面对的流程相对来说更复杂，更严格 个人效率 较多相似工作，不同工具使用导致个人效率的差异 沟通成本 岗位和角色分工清晰，所带来的是沟通成本的提升 知识沉淀 产品迭代、人员迭代产生大量的知识 不同岗位工作内容的复杂性占用不少研发成本 产品 产品文档设计稿交互稿 开发 架构文档 系统流程图 表结构文档 接口文档 Coding 单测 联调 流程组件 负载均衡微服务治理文件接入CDN …… 测试 接口测试功能测试性能测试 测试环境Bugs 运维 版本发布线上运维系统监控 大模型在研发效能上的初步探索 初试 在ChatGPT出来后，大模型似乎能辅助研发效能的提升。 AI辅助编程初步提升开发效率 代码Review 提前发现代码变更引入bug、对有可能出现问题代码进行警告 代码解读 支持系统级别和方法全链路代码解读，并生成相关逻辑图、时序图等 行/函数级实时续写 在编程时，系统会根据你写的内容和语法规则，自动推荐可能的代码片段 代码注释 快速生成方法和行内注释，减少编 写注释所需时间，提高代码可读性 自然语言转代码 通过自然语言描述需求，在编辑器区域直接生成代码 微调模型的试验之路是否可行 一个团队内的所有代码 一个小JAVA开发团队的代码量在2-3G大小（前端开发团队也有在做微调，但只针对公共组件的使用上） 单元测试案例及代码 提取代码中的单元测试案例、以及单元测试的代码，更精准的做代码微调 公共组件使用文档 真正的组件文档大小并不大，在700多M，在开发过程中便于模型能理解公司内部的基本组件并知道如何使用；同时将公共组件调用生成问答对更进准 的让模型理解 代码解释及关联代码 首先把所有代码把无注释的代码先生成一份代码注释、然后将代码注释及代码用于做微调 大模型辅助研发遇到的困难 困难 前期辅助编程方案并无法在研发流程中解决开发太多的痛点。 研发人员在软件开发中的时间投入 统计约60人的团队情况：编码占研发工作时间比例并不高，进而需要更全面的提效方案 代码编写37% 开发人员实际做代码编写的工作占比并不高 需求分析10% 其他22% 代码编写 37% 方案设计 8% 需求分析 10% 联调及测试 23% 好的需求分析工作对后期的研发有极大帮助 联调及测试23% 复杂的环境及多服务串联所带来的联调及测试问题也多 方案设计8% 方案设计是系统稳定性、健壮性、可扩展性、安全性等非功能的重要环节 其他 还有线上问题以及各种其他工作 模型终归不是我们理解的那么简单 2024-04-17 Mistral8X22B 2024-04-24 Qwen-1.5110B 2024-05-13 Yi-1.56B,9B,34B 开源模型迭代速度快几乎每个月都有新模型�来 研发知识迭代影响几乎每周都有版本更新 2024-03-27 DBRX132B 2024-04-18 LLaMA-38B,70B 2024-05-06 DeepSeek-V2236B 模型Token数限制尤其是代码上下文数据巨大 微调服务器成本高昂微调需要独占GPU资源，且巨大 Agent离不开的RAG 方法 RAG可以解决模型微调中的不少问题。 Answer Agent离不开的RAG 生成 Prompt LLM RAG处理流程-提升Agent能力 数据处理 文件处理 结构化解析 代码分析 图像识别 检索 代码检索 专业术语检索 功能检索 数据关系检索 研发知识库 需求文档 接口文档 组件使用说明 数据库表结构 产品说明 测试案例 系统设计文档 代码信息 Question 知识存储 问题分析 向量化存储 Multi-Query 图数据存储 Step-back 结构化存储 KV数据存储 RAG-Fusion HyDE Multi-Agents实现研发流程提效 实践 从集成基础工具到不同业务场景的Agent实现。 一个升级Jar包的工单Agent实现 需求分析Agent CodingAgent CIAgent 1⃣根据工单号拉取详情 组件Agent 通过模型识别需要升级的组件 1⃣根据流水编译打包 2⃣根据详情识别需要升级的组件 版本号Agent 分配系统需要发布的版本 2⃣异常判断 GitTool Git操作 CodeAgent 生成新的代码操作 输出：标准Json FileTool 文件编辑、修改操作 异常处理Agent 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 集成开发工具以实现基础的Agents 通过简单Agents实现研发所需的基础Agent 集成基础的开发工具 约定Agent之间的协议 实现一个相对闭环的能力 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 从CURD入手，实现简单代码的生成 以表驱动实现后端代码的Agents 通过RAG识别表个性化支持包名根据表生成相关 代码 大模型推荐命名 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 以接口驱动实现多环节的Agents-文档生成 ❖需求文档对字段要求文本化❖支持接口文档系统上导入需求直 出接口 ❖结合RAG识别字段的常用命名 测试 TestCase 参数 算法 后台 ServerCode 模版 RAG 如意 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 以接口驱动实现多环节的Agents-代码及测试 接口文档 前端 WEBSITE Prompt 风格 Letgo 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 以需求文档驱动实现全流程Agents 需求分析 需求文档做字段抽取、接口抽取、逻辑抽取、结合RAG拆分需求 接口定义 根据需求分析产�的字段生成接口 表结构创建 需求功能点+现有表RAG确定新表创建SQL 代码定位 根据功能+代码库信息确定代码所实现的位置 测试 单测+SIT测试并根据错误及异常生成新的Issues 编译部署 以工具为主 代码Review 代码Review判断生成代码的完整性、是否合理等 代码生成 拆分代码任务生成每段代码，并更新到相关文件 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 需求分析Agent 抽取名词 抽取字段 确认功能点 拆分需求 ReGen 表生成Agent RAG 表规范Agent 抽取字段规则校验 Tools 生成表结构 LLM_1 Planning Memory Task1 Task1Task1 Memory …… Agent多样性 不同的Task定义不同Agent Agent通过Memory串联 RAG和Tools是个性化的条件 RAG LLM_1 需求文档 PromptTemplate 以需求文档驱动实现全流程Agents 01基础Agents 02简单Agent 03多环节Agent 04全流程Agent 实现从需求到代码自动生成 让AI成为主角的人机交互方式 优化 大量的Agent需要人工参与才能实现完整的功能。 React：无法识别你的工具 不允许返回XXX，还是返回了XXX 要求返回XXX，就是没返回XXX 理解Prompt的能力有限 让AI成为主角的人机交互方式 模型能力对于Agent的影响导致无法自动化 无法完整返回你要的内容 不是你想要的Planning Agents完成主要工作 人人可用 不是人人都去写Agent，但目标是人人都能用上Agent，而Agent做执行的工作只能完成部分，故Agent能优先执行，人去调整Agent执行的结果。 人工调整Agent制定的Planning Tool Reflection Action1 Tool Planning Self-critics Action2 ……Chainofthought Action3 Action1 Confirm Action2 Action4 Action5 Reasoning AskforInput Add/ModifyTool 每个Agent的设计可由人参与并做调整 Planning调整 人工调整Planning的任务，并让LLM重新确认 Prompt调整 复杂的Prompt的会导致LLM生成有偏差 人工参与完成任务 每个任务都有可能Agent执行失败，人工支持参与实现 Agent协议 上下游关联的Agent之间需要定义清晰的协议，在人工调整过程能让协议也自动生成正确 工具调整 工具的命名、描述会对LLM的识别有影响，需要支持人工随时介入调整 重新执行 Agent断点、重新执行、幂等 展望 未来 更多便利的工具； 更多人投入Agent开发；更稳定的环境； 更自动化的流程管理