大模型编码提效场景选择的底层逻辑

文摘   2024-06-30 12:00   江苏  

    大模型在软件编码层面获得了广泛应用,基本上叫得出名的大厂,都开发了copilot、agent、智能体等应用;广大软件企业和个人开发者对这些也是趋之若鹜,基本也是正面评价居多。

    目前主流大模型辅助编码有chat(通过静态或动态prompt跟大模型交互生成代码等)、copilot(通过IDE自动感知用户意图,生成贴合语义的prompt,跟大模型交互生成代码等)、agent(整合大模型的prompt应用,通过感知、决策、执行、记忆等方式,通过感知和记忆生成动态prompt跟大模型多次交互,结果进行执行和记忆,形成综合应用)、智能体(多agent进行交互完成更加复杂的应用等)等拟人方式,种类繁多、眼花缭乱、更有厂商趁机贩卖焦虑,大有大模型要替代人之势。

    有选择就有痛苦,至于什么情况下以什么样的场景用大模型,到底是选择大模型辅助人,成为人的得力助手,即我们称之的低AI化呢?

    还是往更加智能的场景上走,以人辅助大模型甚至更进一步进化为Devin或0号员工之类拟人化应用(我们称之为高AI化)呢?

    要回答这个问题,一定要有一个清晰的底层逻辑,需要经过判断和推导,才能让大家心服口服,也能让自己忽悠领导、同事时更加有底气。

    大模型编码的底层逻辑我们可以从应用场景角度和模型能力角度两方面看。

    首先,从应用场景的角度看,场景最主要值得关注的维度是价值,即细分场景中最耗能的部分。

    其中,耗能可以从参与人数发生频度故障概率故障严重程度几个角度看。

    下面是我们梳理的编码相关的细分场景:

编码类型
(粒度)
研发比例占比(从xx项目 1-5月数据
gerrit单中变更数
载体目前方式
系统级极少
目录/构建
脚本
手工
模块级较少
目录IDE/手工创建
类/文件级
文件IDE/手工创建
函数级(含UT/FT)较多25%(<20且<150行,2500/10000)函数1、搜索相似代码
2、copy
3、行内添加、修改
行级极多64%(<20行,6400/10000)行代码行内添加、修改

    

    从表中可以看出,在git/gerrit提交这一系列原子过程中,行级代码编写、修改占比无论从参与人数、频度、问题出现概率出问题严重程度都最高,也就是耗能最高;函数级代码编写、修改居其次。

    那代码级/函数级编码是否就应该走向更加智能化或拟人化呢?

    还需要从大模型的角度来看,是否更加自动化或拟人化还取决以下维度:

    1、场景本身的风险程度

    即该场景如果引入bug造成的影响程度。

    2、大模型在该场景下生成物的准确度

    从以上两点,我们可以得出以下结论:

    1、风险程度越高,可AI化程度越低

    2、精度度越低,可AI化程度越低

    这样形成一系列的区域,具体分析如下

    1、在风险程度越高,准确度不高的区域

     风险程度越高,而大模型物生成准确率又不高的情况下,越是需要人工参与甚至主导,越是不能使用使用智能化或拟人化。

    例如在上表中代码级/函数级编码,属于风险程度高而大模型生成代码准确率相对不太高的高耗能场,恰恰适合copilot。

    该种场景下,大模型在IDE中补全代码,人去审核、去大模型生成的代码,以人为主,大模型为辅,即低AI化。

    另外,传统方式程序员写代码都是3步法(都是老司机了,谁也别不好意思聊驾驶技术):

    a、检索遗留代码或者老代码中相似功能或类似意图的函数/代码块

    b、拷贝大法

    c、进行行级修改/补充

    copilot实现跟人写代码的3步法非常一致,即先通过IDE对当前光标所处文件进行语法分析,然后抽取光标所在行上下的最小语义块,再通过IDE把当前光标所处文件、打开的文件、工程、知识库等进行检索,获取相似代码块;最后再加上代码信息(编程语言、文件路径等)、依赖项(数据结构、静态函数、全局变量、宏、三方库等)变成动态prompt给大模型,大模型进行填空,如果有相似代码填空填对的可能性就很大,也就是我们说的意图识别的准。

    你看就是一个模拟人的过程,主打一个丝滑。

    类似场景还有:

    故障修复、merge冲突处理、devops流水线失败处理等。内容域比如需求、方案生成也可以类似处理。

    2、在风险程度相对较低,准确度不太低的场景

    比如代码评审,即使代码走查评审没有发现全部的问题,后面还会有联调、集成测试、系统测试、冒烟测试等进一步的质量保证措施,只要大模型生成物准确度不是太低,哪怕只能给出了一条评审建议,也是可以参考的,同样有价值;另外大模型给出的修改建议即使不靠谱,不采用就是了。这种情况下,越是拟人化使用大模型,即agent、workspace、多agent应用,越是花活越好,即高AI化越好。

    类似的场景还有很多:试脚本生成、静态扫描告警处理等。

    同理,上述分析针对内容域(需求、设计、测试、运维、手册等)大模型生成也有同样的参考意义。

    综上,可以看出,大模型在编码域的应用具体选择哪些场景,哪些场景对应使用哪些大模型应用,都是需要判断和选择,都是要有思考和设计的过程。

    所谓一具体就深刻,说的就是这个过程。


    小结

    对于大模型的应用,可以积极参与,主动实践,但强烈不建议盲目跟风,生搬硬套。

    一定要有完整的底层逻辑,包括对自己业务细分打开,根据自己的细分场景的耗能、风险程度、大模型生成物的准确程度进行综合分析,从而得到自己大模型落地的合理路径。

    小马过河,老牛说水浅,松鼠说水深,小马只有自己过了一下,才能得到最深刻的感悟,希望大家顺势而为,谋定后动,共勉。

丁辉的软件架构说
代码匠艺,软件系统架构,AI平台和应用,生活趣事。
 最新文章