AI辅助编程真实测评与企业落地实践

AI辅助编程真实测评与企业落地实践 作者：蒋志伟 个人简要 蒋志伟 爱好技术的架构师 参与OpenTelemetry开源社区 曾0-1搭建美团APP的推荐、搜索服务 曾负责Qunar.com上亿用户机票搜索、低价推荐系统有旅游GDS(全球分销系统)的技术专利 开源项目 基于场景的AI编程测评集 https://github.com/laziobird/CodeLLMTEval CONTENTS 01 AI辅助编程的 背景和最新发展 02 测评集现状与全场景测评介绍 03 AI编程生成能力的可行性测评 04 企业提效的落地现状与解决方案 01 AI辅助编程的背景与发展 AI在自然语言处理NLP上的里程碑 Embedding 2003Bengio团队 嵌入技术，将高维稀疏的数据通过神经网络或其他算法映射到低维稠密的向量空间，尤其WordEmbedding词向量普遍用于NLP领域 Word2Vec 2013GoogleWord2Vec模型生成词向量成为自然语言处理的标配方法，通过上下文来预测当前词语的CBOW训练方法，为后来神经网络语言模型的发展奠定了基础 Transformer 2017GoogleOpenAITransformer模型在翻译任务上超过之前最优秀的循环神经网络模型采用AttentionLayers重点解决多义词问题，基于此的GPT模型让AIGC极大发展 CodeLLM（代码生成大语言模型）的发展 人工智能对自然语言的上下文推理、一词多义理解能力的加持。让场景契合的辅助编程领域 有了快速的发展 辅助编程相关场景任务一般有三大类： •代码-代码：包含代码补全、代码修复 •代码-文本：代码解释、代码优化、代码异常排查 •文本-代码：通过高级提示词Prompt做代码生成(单元测试、API、SQL、数据建模等) CodeLLM：代码生成大语言模型的发展 关键模型与项目 https://arxiv.org/pdf/2311.07989v1 •2024.7CodeGeeX4 https://github.com/THUDM/CodeGeeX4 •2024.6DeepSeek-V2 https://github.com/deepseek-ai/DeepSeek-V2 现有CodeLLM测评数据集问题 模型测试训练、测试数据不足 现有的CodeLLM测评工具通常使用有限的训练数据 以HumanEval、MBPP代表代码模型评测数据几年没更新 评估标准单一 现有的CodeLLM测评原理只关注代码结果的正确性，看不到代码的可读性、完整性、通用性等维度的信息 测评打分原理造假容易 各家公布自家测试结果，测评是黑盒的状态将测评集放到训练集中训练，好比 拿着标准答案答考题，测评分数会虚高 Github上公布的测评结果明显有水分 •同样大模型不同测评来源，评分不一样 代码大模型各家评测基数差异巨大 •MetaCodeLlama •DeepSeekCoderV2 •智谱CodeGeeX4 •基本常识性错误 •北大aiXcoder •阿里巴巴CodeQwen 代码大模型评测集工作原理 最常用的测评：HumanEval OpenAI发布的一个评估大型语言模型在代码生成方面表现的基准测试。它包含164个设计的Python编程任务，每个任务有多个单元测试，通过评估模型生成的代码是否能通过这些单元测试来评判模型的能力 用JSON格式定义好编程任务，保存测评集在文件中 1 2根据测评文件编程任务给出prompt，调用大模型生成完整代码，保存到一个样本文件的completion字段中 代码大模型评测集工作原理 3用程序读取样本文件，批量把任务生成中代码和任务的单元测试代码合并成一个完整的程序 4批量动态执行每个任务程序，如果单元测试用例通过，返回passed，最后调用pass@k的算法测评打分 pass@k打分算法 5假设样本文件叫samples.jsonl，调用叫evaluate_functional_correctness函数完成1-4的步骤 简单来造个假 1部署HummanEval测评环境准备编程任务、答案样本 简单用测试集和问题集运行打分效果，pass@k分值0.16 2 pass@k分值明显提高,达到0.4994 简单修改测试集数据，增加正确答案样本 3业界都自家测评打分 没有透明渠道 造假成本太低 02 基于场景功能的测评测试集 基于编程场景的测评 实际编程出发看到真正的价值 编程使用场景 从日常编程习惯，按频率和功能进行工具的对比测评，如代码补全、缺陷查找、代码调优、报错排查、代码解释等 提示词生成能力 提示词生成功能代码的能力，如API文档、单元测试、代码注释、参考模版编写新模块等能力的对比测评 业务建模能力 辅助编程能更多读懂我们的业务逻辑，参与框架设计，如数据库表设计、项目构建、根据数据模型生成Service代码 客观加主观判定 不能只局限程序对错简单打分，要加入更多判断标准：成熟度、完整度、易用性、语言特性等 代码补全提示 •上下文理解 从代码上下文补全的结果，对比其理解和输出的准确能力 •统一风格能力 基于已有的代码模版和示例，新的示例自动补全的准确性和代码风格的统一性能力 考虑国内的正常使用，测评基于国内辅助编程平台，同时参考GithubCopliot。我认为的第一梯队产品去比较为了避嫌，暂且A、B、C表示。最后有测评总结报告，列出第一梯队和测评产品完整对比结果 •统一风格能力 这是有关电商产品库的真实代码 代码补全提示 A 先设计好类目表LsCategory相关数据库操作模版示例 C优秀、体验非常棒，内容风格一致 差、几乎没法用 A 参考LsCategory模版，对比辅助生成电商Spu实例效果 B 补全一般，代码注解不一致 •上下文理解能力 代码补全提示 这是有关机票搜索的真实的代码，search方法根据入参搜索条件返回搜索结果 B 先输入文字注释，看看A、B、C各自代码补全效果： •B、C理解了注释的意图，拿了不存在的入参属性 •A理解想表达意图同时，给出了代码库中正确 方法，也秒懂打印日志的意图C 测评维度 •不同项目案例逐行提示、多行提示测评 A •代码补全总的代码采纳率作为测评标准 •长期统计，A代码采纳率略高，上下文能力一般，幻觉多 •常见致命缺陷 高频缺陷查找 导致CPU100%的死循环、各种严重的内存溢出、基本业务逻辑错误、线程并发死锁问题这类缺陷特点：常年高频发生、对业务影响大、往往花更多的精力进行线上排查和修复 •举个例子 导致CPU100%的死循环 高频缺陷查找 publicclassendlessLoop[ publicstaticvoidmain(String[]args)[intcount=0; while(count<10)[if(count==3)[continue; ] System.out.println(count);count++; ] ] ] CB A 左边是一个常见的死循环Case，A、B、C都没有发现这个致命问题，用 ChatGPT明确告知会导致无限循环和修复建议。这种程序往往导致线上服务无法工作 •测评维度 高频缺陷查找 •综合打分：借鉴HumanEval打分思路，根据高频缺陷查找场景分析有没有缺陷正确与否进行 •开源测评集：同时讲主观答案进行提示词模版优化转换成客观答案 https://github.com/laziobird/CodeLLMTEval 提示词模版Demo：测评集用代码大模型生成结果的客观答案 检查<java></java>标签里的Java代码，有没有死循环的情况。返回XML标签格式结果，格式’<status></status>’,如果有，status返回1，没有status返回0，不知道status返回-1 <java> ..........</java> •测评初步结论BA 测评集20+，A、B在70%识别缺陷，C不到60% 报错排查的测评 •测评维度：排查入口的友好性 产品体验 从产品角度看实用性编译错误阶段 运行失败阶段 B、C产品编译阶段排查功能实用 B A、GithubCopliot没有编译阶段报错排查的功能 报错排查的测评 •运行阶段的报错修复 多种典型场景测试和验证、排查多个运行失败的Case A、B、C插件在失败信息中异常排查的帮助链接 示例：配置错误的环境路径，找不到服务启动失败 AB GithubCopliot插件并不支持这项功能 A、C排查错误根因更高 辅助编程工具箱 编程过程中，常用到一些工具类过去本地实现，后来借助saas工具 •AI工具箱的集成，因为大模型具备 自定义提示词能力，工具类更通用更有效率 •C、A工具箱设计实用 CA 03 AI生成能力的可行性测评 高级功能生成能力 几乎零代码生成准确的API文档，文档可读性高、保持风格、规范统一 零代码生成可运行的单元测试用例，考虑测试边界，保持风格、规范统一 *代码注释 *版本控制提交注释 生成风格统一、可读性高 参考现有代码库模版 *仿写实例的能力 表设计和SQL生成低代码平台能力 API文档单元测试参考生成数据建模 •重要测评维度 单元测试生成能力 •代码采纳率：可用性，普遍生成单元测试编译不过 这个点比较不好评判，基于开销考虑，单元测试没有带上完备上下文 •更细粒度化的方法测试生成能力、测试边界能力产品上A有友好的方法粒度单元测试入口 A、B生产代码有更丰富的边界测试Case，C比较简单 •仿写支持的能力：A支持选择仿写模版文件 其它手动输入仿写文件的内容Token，非常不便利 单元测试生成能力 Token •测评的维度 生成API方法的PostmanCollection2的JSON文件模版其中指定了地址127.0.0.1和端口号8099 参考表结构'createtablels_category‘ •API级别单元测试可用性：比如A产品生产基本可用的Postman测试模版，B和C生成模版不可用 A A自动生成PostmanAPI请求模版 Postman调用添加商品类目的API请求 API测试用例验证成功 API文档生成能力 •相同提示词，文档的风格差异大 •不同用途性质的API文档，要清晰表达出来 •测评结果 选取5-6个项目的API服务 •API方法少，简单 A、B、C很好的生成了文档 •API方法多，入参出参复杂 A、B较好完整文档，C入参、出参不完整 Prompt 生成完整的API文档：带上入参、出参详细介绍，给出完整示例，格式markdown，给前端调用 C B A 参考现有代码模块仿写新实例 A •提示词设计非常重要 •RAG检索代码库的上下文能力 •友好的产品交互方式 根据模版，生成类似的实例代码 A •B、C仿写能力都很差、不准确 •A支持选择代码文件，仿写和参考代码高度一致，有很强的复用性 CB 数据建模能力 表设计 通过业务系统描述 数据库表字段、表结构关 系的理解能力和准确度 SQL生成 根据业务需求，表结构基础架构上，生成可运行SQL的能力 项目构建 根据技术需求，生成项目构建的能力 低代码能力 建模后，理解业务逻辑，0-1构建、部署、启动项目的文档能力 •测评维度 表设计和SQL •用技术语言输入提示词，生成表设计，包含表与表的关系，完整的SQL •多个实际项目，考验代码大模型业务场景理解能力和推理能力，同时考量正确率和完整度 A Prompt电商系统产品库表设计 设计一个商品库表：里面有sku表、spu表、类目category表spu和category关系：spu里面有一级、二级、三级类目信息spu和sku关系：一个spu对应多个sku，区别在于规格，规格多有个值，可以用JSON方式保存为一个字段。 sku包含第三级类目的信息 ; B •B在表设计、业务理解更完整：比如表字段描述、复杂字段业务示例 表设计和SQL •直接用业务语言输入提示词，看看对业务理解和代码更高要求的生成能力 A Prom