1、 进群可咨询基于LLM的CodeReview实践陈超宇字节跳动质量技术团队,模型算法专家录CONTENTSCodeReview现状0102 智能CR的标和挑战智能CR探索与实践03总结与规划04Q整体案智能CR:基于LLM的CodeReview是研发测Agent的核Agent之PART01CodeReview现状CodeReview现状01在程实践中,审查的响应延迟已形成显著瓶颈。均数万次的代码提交量使得评审队列积压成为常态,程师往往需要等待数时才能获得评审反馈,拖累持续交付节奏0203时效低效果不稳定分析具困局评审质量的波动性与评审者的认知负荷形成恶性循环:资深程师的隐性知识难以有效沉淀为团
2、队共识,初级开发者受限于经验盲区,可能遗漏缺陷,导致产环境事故现有技术路线往往割裂处理各质量维度,导致安全检测具与性能分析具各为政,缺乏统的知识表征体系。同时各种具也很难对代码的语义进审查智能CR的标随着语模型技术的快速发展,LLM的各能都有了显著的提升。其中,代码领域已经逐渐从相对的垂直领域变成了LLM的基本能,各种SOTA模型层出不穷,并且在代码成和代码理解有了质的跃,因此也给CodeReview领域带来了更多的机遇。解决问题LLM为核对代码变更提供智能CR能,检查代码中的潜在bug,提供可操作的修复建议,并提升代码质量和性能。准召准确率,召回率使成本低,评论价值可扩展性持多代码语,持定义
3、评审标准智能CR标LLM带来的机遇智能CR的落地场景IDECI/CDPipeline智能CR的挑战如何才能让模型更好的理解代码上下,上下程如何做好。模型的上下窗有限,模型的注意(Attention)有限,因此更好的上下程可以保证信息完备的同时,提信息密度,进提升代码理解1.代码理解在CR场景中,检测出的bug或者问题会形成评论。那么如何成价值的评论是CR是否有价值的主要挑战2.评论成当前以LLM为核的系统,幻觉是不可避免的。因此,评论成过程中,除了价值的评论,必然也有低价值的评论,甚错误的评论。如何采后置的验证技术,将正确价值评论透出,错误低价值评论过滤掉,是个重要挑战3.评论验证如何好已有的
4、代码分析具。如何设计具系统。如何新增必要的具给LLM使。当智能CR逐渐向Agent向迭代的过程中,具系统的设计是重要挑战4.具系统PART02智能CodeReview的探索与实践初期探索:基于规则的智能CR1.0早期思考早期探索试图沿着静态扫描的思路,希望继承内部各种静态扫描具及其规则的知识与经验。因此,智能CR1.0是个基于静态分析盒化,语义化的尝试流程设计经过对动化CodeReview的法调研,我们认为CodeReview的最佳流程的细节可能有待探索,但其整体流程的最佳案应该是:成-验证-修复基于“规则”知识库将静态扫描等分析具中采纳率的类别进提取,形成了CR规则本体树,并于评审。基于CR
5、规则本体树+LLM的评审评论成后,验证部分要采相同的规则,并且需要使规则的细节和正反例来进验证010302智能CR1.0:评审规则知识库评审规则知识库包括两个部分:评审规则本体树,评审规则详细信息(包括规则定义,正反例,CoT)智能CR1.0:Workflow评测驱动的智能CR评测集构建动化评测准确性:为了评测案的平,评测集的case需要够准确多样性:为了评测案的泛化能,评测集的case需要具备多样性价值:为了引导案迭代成更多价值评论,评测集的case应该是价值的。保证评测效率程预判断+模型评审的混合评审端到端能的整体评测+局部功能的单独评审能LLM为核的智能CR需要以评测驱动迭代,形成优化-
6、评测-反馈的迭代轮智能CR1.0:数据流程智能CR1.0:效果与问题基于规则知识库的CR1.0能很好的识别规则体系内的问题,但法识别其它类型问题。如果需要检测新类型的问题,需要补充本体树已经规则详情,将LLM解决问题转化成了的问题。没有充分利LLM的主性泛化性差基于规则知识库的CR1.0,对多语的持依赖增加各个语的规则知识本体树和规则库。没有充分利LLM天的多语能。多语问题通过训练或者ContextEngineering的式,评论成的召回率低,法召回更多代码缺陷.同时规则知识本体树也限制其召回能。召回率低CR1.0的单次评审粒度是函数级,个的MR需要批处