在前面的博客中分别介绍了大模型评估过程不同指标的含义,以及如何通过代码,实现指标的收集。如果对如何运行代码生成结果和收集pass@k指标不清楚,可以参考这两篇博客。
Pass@k的来源
代码的生成模型主要是通过将样本与参考方案进行匹配来衡量的,其中的匹配可以是精确的,也可以是模糊的(如BLEU分数)。匹配的代码指标存在缺陷。例如,Ren等人(2020年)发现,BLEU在捕捉代码特有的语义特征方面存在问题,并建议对该分数进行若干语义修改。更为根本的是,基于匹配的指标无法解释在功能上等同于参考解决方案的庞大而复杂的程序空间。因此,在无监督代码翻译(Lachaux等人,2020年)和伪代码到代码翻译(Kulal等人,2019年)方面的工作已经转向功能正确性,如果一个样本通过了一组单元测试,就认为它是正确的。我们认为,这种衡量标准也应适用于docstringconditional代码生成。
评估功能正确性的最有说服力的理由是,人类开发者用它来判断代码。一个被称为"测试驱动开发"的框架规定,在任何实施开始之前,软件需求要转化为测试用例,而成功的定义是通过这些测试的程序。虽然很少有组织采用完全的测试驱动开发,但新代码的集成通常取决于创建和通过单元测试。
&nbs

最低0.47元/天 解锁文章
2000

被折叠的 条评论
为什么被折叠?



