1.1 评测目标与核心问题
我平时做代码补全模型效果评测，最怕一上来就堆指标。功能正确性肯定要看，模型补出来的代码能不能跑、能不能过单测，这是硬门槛。补全可用性也躲不开，代码不光是正确，还得让开发者愿意用，补全片段放在光标处是否顺手，上下文是否接得上，这些体验层面的东西我会单独拎出来。工程效率和安全合规同样要放进评测边界里，首Token时延、吞吐量、漏洞引入率、许可证风险，这些指标会直接影响团队是否敢把模型放进研发流程。我的经验是，评测边界不清，后面指标越多越乱。
从团队负责人视角看，评测目标不只是排个榜单。我会问三个问题：模型在真实任务里能不能帮上忙，帮上忙的代价有多大，出了问题能不能追溯。功能正确性回答“能不能用”，补全可用性回答“好不好用”，工程效率回答“用得起吗”，安全合规回答“敢不敢用”。这几个问题合在一起，才构成代码补全模型效果评测的核心问题。我常提醒自己，评测不是给模型打分就结束，分数要能对应到研发决策。
1.2 评测对象与任务场景
我区分评测对象时，习惯按补全粒度切。行级补全像输入法联想，块级补全更像补一小段逻辑，函数级补全要求模型理解签名和意图，仓库级补全得跨文件找依赖。不同粒度的难度差很多，拿行级指标去衡量仓库级补全，结论容易失真。我会在评测方案里明确写清楚，这次测的是哪一种或哪几种粒度，避免读者误读。
单轮交互和多轮交互也要分开看。单轮补全像一次提问一次回答，评测相对干净。多轮交互里，开发者会改提示、补上下文、拒绝建议，模型要跟得上对话状态。我作为开发者时，特别在意多轮场景下模型会不会“忘掉”前面的约束。评测任务场景覆盖单轮和多轮，结果才更接近日常编码。场景不说明白，排行榜上的高分很容易变成实验室里的热闹。
1.3 评测体系总体框架
我搭评测体系时，喜欢用一个闭环：评测指标、基准数据集、实验方法、结果报告。指标回答“看什么”，数据集回答“在哪看”，实验方法回答“怎么看”，结果报告回答“看完怎么用”。这四个环节缺一个，评测就容易变成一次性活动。我见过指标很漂亮但数据集泄漏的实验，也见过数据集很新但实验设置不可复现的报告，这些问题都要在框架层面提前约束。
闭环体系的好处是能持续迭代。指标会随任务变化调整，数据集会随仓库演进更新，实验方法要控制随机种子和提示设置，结果报告要能追踪版本。我作为评测工程师，会在框架里留出复现说明和局限性分析的位置。团队负责人看报告时，不只看平均分，还会看置信区间和失败案例。评测体系总体框架稳了，后面的指标展开和数据集实验才有落点。
1.4 关键词需求界定
围绕“代码补全模型评测指标有哪些”这个搜索意图，我会把指标分成功能正确性、生成质量、上下文利用、用户体验与工程效率、鲁棒安全合规几组。读者搜这个问题，通常想要一张可操作的指标清单，不是一堆术语。我会在内容里解释每个指标解决什么问题，适合什么场景，避免把Exact Match和Pass@k混着用。指标清单要能帮助读者做选择。
“代码补全模型评测基准数据集”这个搜索意图更偏实操。读者想知道HumanEval、MBPP、RepoBench、CrossCodeEval、CodeXGLUE这些数据集分别适合测什么，语言覆盖和许可合规怎么样，仓库级场景怎么采样。我会把数据集按任务类型、编程语言、补全粒度分类梳理。搜索意图梳理清楚，评测关注点才不会散。我常跟团队说，关键词不是堆在标题里，是要对应读者的真实问题。
1.5 总分式结构说明
这一章走总分路线。开篇把评测总框架搭起来，让读者知道评测目标、评测对象、评测体系和关键词需求怎么连在一起。后面分别展开指标体系和数据集实验方法，指标部分讲清楚每类指标的含义和选择策略，数据集部分讲清楚基准、实验设计和结果解读。总分结构能让读者先看地图，再看细节。
我写总论时会刻意控制细节密度。总论不展开每个指标的计算公式，也不逐条介绍数据集，这些留给后续章节。总论的任务是界定边界、统一语言、说明结构。读者看完总论，应该能判断自己的评测需求属于哪一类，该关注哪些指标和数据集。总分式结构说明放在这里，也是给后续内容定调。
第2章 代码补全模型效果评测的关键维度与指标体系
2.1 功能正确性指标
我评功能正确性，最直接的办法就是看模型补出来的代码能不能跑。Exact Match这指标特别轴，补全结果跟参考答案一字不差才算过。我拿它看过一些行级补全场景，短片段还行，函数级补全基本被它判死，同一个功能实现路径太多了，非得字面一样就有点不讲理。Pass@k就宽松不少，让模型生成k个候选，有一个能过测试就算赢。我平时设k=1、k=10、k=100看趋势，k越大分数越好看，可工程上真让开发者从一百个候选里挑，谁受得了。我盯得最多的是Pass@1和Pass@10之间那道缝，缝太宽说明模型稳定性有问题。
编译通过率算个门槛指标。语法都错了，后面聊啥都白搭。我见过一些模型Exact Match分数不赖，编译通过率却很难看，补出来的代码看着有模有样，一编全是红。单元测试通过率比编译硬气，能跑通测试才算真把功能做对了。修复成功率我一般放在带bug修复任务的评测里，塞给模型一段有毛病的代码，看它改不改对。这几个指标得搭着看，单拎一个出来都容易误判。
2.2 生成质量与语义匹配指标
BLEU和CodeBLEU我扔在辅助席。BLEU原本是给机器翻译用的，拿来看代码补全只能说凑合，它数的是n-gram重合度，代码里换个变量名，意思没变，BLEU分数嗖地掉下去。CodeBLEU加了语法树和数据流，比BLEU懂点代码，我拿它做过生成质量的横向对比，同一批用例下不同模型的相对排序还算稳。这俩指标适合快速筛查，当最终结论就有点不够看。
编辑距离我拿来瞅补全片段跟参考答案差多远。差一两个字符和差几十行，背后的模型毛病完全不同。语义相似度我习惯拿代码嵌入模型算，不求字面一致，看功能语义近不近。代码结构一致性这个我单独拎出来说，函数级补全里有些模型逻辑对、结构乱，嵌套深得离谱，重复代码一堆，开发者读着都费劲。我作为评审者看生成质量，字面匹配、语义接近、结构合理这三层分开聊，混一起说容易糊。
2.3 上下文利用与仓库级补全指标
仓库级补全评测里，跨文件检索命中率是我最上心的指标之一。模型要补的代码依赖另一个文件里的函数或者类型定义，它能不能找到、能不能正确引用，这能力直接决定仓库级补全能不能落地。我观察过不少模型，单文件场景表现亮眼，一跨文件就露怯，检索命中率掉得厉害。上下文覆盖率看的是模型实际用了多少可用的上下文信息，给了它十个相关文件，它只碰了两个，覆盖率就低得可怜。
长上下文稳定性这指标容易被漏掉。上下文窗口拉到几万token，模型注意力散不散，补全质量会不会随上下文变长往下走，我会专门设计不同长度上下文的对比实验来盯。依赖感知能力更细一些，模型不光要找到依赖，还得吃透调用关系、参数类型、返回值约束。我作为开发者，仓库级补全最怕模型引用了不存在的函数或者参数类型传错。这几个指标合一块，才看得出模型有没有真本事做仓库级补全。
2.4 用户体验与工程效率指标
补全接受率和采纳率是产品侧天天盯的指标。接受率看开发者有没有按Tab键把建议收下来，采纳率看接下的代码最终有没有留在提交里。我见过接受率漂亮、采纳率难看的模型，开发者图省事按了接受，回头又手动改掉，这种补全对工程效率没半点帮助。两个指标得绑着看，单看接受率容易让表面数字给骗了。
首Token时延和端到端延迟直接决定开发者愿不愿意等。行级补全首Token超过几百毫秒，开发者心思就飘了。端到端延迟对块级和函数级补全更要命，等好几秒才出结果，大多数人早自己敲完了。吞吐量和资源消耗是团队负责人该看的指标，模型单次补全延迟低，并发一上来扛不住，研发团队大规模用照样卡。我会在评测里模拟并发场景，盯吞吐量和GPU内存占用。工程效率指标不能只看平均值，尾延迟才是开发者真正肉疼的东西。
2.5 鲁棒性、安全与合规指标
对抗扰动稳定性我一般用变量名替换、代码格式调整、注释干扰这些法子来测。模型在干净数据上表现好不算本事，输入稍微一变就崩，实际用起来风险大得吓人。漏洞引入率是条硬杠杠，模型补出来的代码带不带SQL注入、路径穿越、空指针这些毛病，我拿静态分析工具扫过一些模型输出，结果不太乐观。安全合规这块，漏洞引入率必须单独列，不能藏在平均分底下。
许可证合规看的是模型补全片段跟训练数据里受版权保护的代码有多像。相似度太高，法务那边根本过不去。隐私泄露风险我会关注模型会不会把训练数据里的密钥、内部地址这些东西补出来。偏见风险评估在代码补全里提得少，变量命名、注释生成里确实存在。这几个指标不是每次评测都跑，面向企业落地的方案里我会加上，准备进生产环境之前更是要过一遍。
2.6 指标选择与综合评价策略
指标不是越多越好。行级补全评测，我重点看Exact Match、编辑距离、接受率和首Token时延。函数级补全加上Pass@k、单元测试通过率和CodeBLEU。仓库级补全必须把跨文件检索命中率、上下文覆盖率和依赖感知能力放进去。任务场景定指标权重，拿一套指标打天下，结论很容易跑偏。
多指标加权权衡这事，我的做法是先设硬门槛再算综合分。编译通过率、漏洞引入率这类指标搞成一票否决，不过线就不进综合评分。过了门槛的模型，再按场景调权重算加权分。统计显著性我每次都看，Pass@k差两个点，置信区间一重叠，这差距就不能当结论用。置信区间分析能帮我判断评测结果稳不稳、样本量够不够。我常跟团队说，评测报告里没有置信区间的数字，说服力得打个折扣。
第3章 代码补全模型效果评测的基准数据集、实验方法与结果解读
3.1 主流评测基准数据集梳理
我刚开始做代码补全评测那会儿，翻来覆去就那几个数据集能打。HumanEval是最早进我视野的一批，OpenAI放出来的，一百六十多道Python函数题，给定签名和注释让模型补函数体。我拿它跑过好几个模型，出分快、口径统一，适合快速摸底。这数据集偏函数级生成，行级补全场景它管不了，题量也不大，模型之间分数咬得紧的时候，统计显著性就不太够用。我一般把它当开胃菜，不当主菜。
MBPP跟HumanEval差不多同期，几百道入门级Python题，每题配一个测试用例。它比HumanEval稍微接地气一点，题目描述更像开发者平时提需求的口吻。我有时候两个数据集对打，看模型分数在两边排位稳不稳，稳的话说明模型泛化还可以，一边高一边低就得翻样本找原因。这两个数据集都是Python单语言，语言覆盖面窄，多语言模型在它们身上看不出真实水平差异。
RepoBench和CrossCodeEval是我做仓库级评测的主力。RepoBench从真实GitHub仓库采数据，补全时要跨文件找上下文，任务粒度比HumanEval高一大截。我第一次跑仓库级模型的时候，单文件分数明明好看，RepoBench一上就露馅，模型找不着跨文件依赖，补出来的调用十有八九是编的。CrossCodeEval在跨文件场景上更严格一些，上下文检索和补全质量绑一起评。这两个数据集我建议做仓库级补全的团队都过一遍，光看函数级分数容易自我感觉良好，一上仓库级就现原形。
CodeXGLUE是另一个路子，它是个多任务集合，代码补全只是其中一块，还包括代码翻译、缺陷检测这些任务。我拿它主要是看模型在多语言、多任务下的综合表现，语言覆盖从Java到C#再到JavaScript都有。做多语言补全的团队用CodeXGLUE能看出模型语言间的偏科程度，有些模型Python上猛得不行，换Java就掉两个档。我按任务类型、编程语言、补全粒度、仓库级场景这四个维度把数据集分好类，评测的时候按需取用，比抱着一堆数据集乱跑强得多。
3.2 数据集构建与使用要点
数据去重这事我踩过坑。早期我没在意，拿了一份公开数据集直接开跑，模型分数高得邪门，回头一查才发现测试集跟训练集有大量重叠，模型见过原题。现在我评测前必做泄漏检测，n-gram重叠、精确匹配、代码嵌入相似度三道筛子一起上。去重不彻底，评测结论就是自欺欺人，团队按这个分数做决策，后果比不评测还糟。
难度分层是我做评测时特别在意的一环。一个数据集里题目难度不均，简单题占比太高，模型分数虚高，真到复杂场景就崩。我一般按代码长度、依赖深度、语法结构复杂度把样本分到易中难三档，分档看模型表现。有些模型简单题满分，难题及格线都摸不着，这种偏科放在综合分里看不出来，分层看就一目了然。我还会盯每个难度档的样本量够不够，小样本档的分数波动大，别拿来下结论。
真实仓库采样这块，我坚持用生产环境的代码分布来校准公开数据集。公开数据集再全，跟特定团队的代码风格、依赖栈、业务领域也差着一截。我一般从团队自己的仓库里采一批真实补全点，做内部评测集，跟公开数据集的结果对照看。语言覆盖和许可合规也不能马虎，商业项目里用的数据集得逐条看许可证，GPL污染的代码片段进了评测集，法务那边不好交代。我采内部数据时会跑一遍许可证扫描，把有风险的仓库剔掉。
3.3 评测实验设计方法
基线模型选择直接决定评测结论有没有参考价值。我一般挑三类基线：通用大模型、代码专用模型、团队自研模型。三类放一块跑，才知道新模型是真进步还是在原地打转。基线模型版本得锁死，我见过有人拿半年前的基线成绩跟新模型比，这不是评测，是讲笑话。每次评测我都在实验记录里写清基线模型名称、版本号、评测日期，换基线就重新跑全部实验。
提示和上下文设置是实验设计里最容易糊弄的地方。同一个模型，零样本、一样本、少样本提示下分数能差出十几个点。我评测时固定提示模板，上下文截断策略也写清楚，是按行截、按token截还是按语法单元截。跨文件补全实验里，检索回来的相关文件顺序也会影响结果，我一般按相关度排序，也做过乱序对照实验，看模型是不是真在学习依赖关系。
消融实验我每次出新模型必做。上下文长度、检索策略、微调数据配比，这些变量一个个拆开看贡献度。不做消融，评测报告只能告诉你模型行不行，告诉不了你为什么行、哪块行。随机种子控制容易被忽略，Pass@k这类采样指标对种子敏感，我一般跑五个种子取均值，报均值和标准差。实验流程我要求可复现，环境配置、依赖版本、评测脚本全部进版本库，换台机器一键重跑，结果对不上就查到底。
3.4 评测结果分析与可视化
拿到分数先别急着下结论，按语言拆开看。我评测多语言模型的时候，Python、Java、JavaScript、Go各算各的分数，经常看到模型总分离谱，拆开一看是Python一枝独秀撑着，其他语言全在及格线附近晃。按场景拆也是一个道理，单行补全分数高不代表函数级补全行，函数级行不代表仓库级行。我习惯做一张按语言、场景、难度三个维度的热力图，哪个格子发红一眼就能看到。
错误类型归因比分数本身更有信息量。我把补全错误分成几类：语法错误、逻辑错误、跨文件引用错误、上下文遗漏、冗余生成。每类错误占多大比例，直接指向模型改进方向。我做过一个案例研究，某模型编译通过率很高，单元测试通过率却上不去，翻样本发现它补的代码语法没问题，但把边界条件全漏了。这种结论光看总分数一辈子都看不出来。
典型案例研究我一般挑三到五个代表性样本做深度剖析，展示模型输入、上下文、输出和错误点。报告里放几个真实案例，评审那边理解起来快得多。可视化我偏好箱线图看分数分布，均值相同、分布不同的模型实际用起来差别很大。尾部分数差的模型在真实场景里出问题的概率高，我一般会把P10、P90分位数也标出来，光看均值不够。
3.5 评测报告与落地建议
评测报告的可复现性我放在第一位。报告里必须包含数据集版本、模型版本、评测脚本链接、随机种子、硬件环境，缺一项我都打回去重写。我见过太多报告只写个分数，别人想复现都无从下手。排行榜上的数字我从来不当真理用，榜单数据集跟真实业务场景的差距，有时比模型之间的差距还大。我一般建议团队把榜单分数当参考，真正的决策依据来自内部评测集的结果。
持续评测机制得有，模型迭代速度这么快，评测跑一次就束之高阁，三个月后结论就过期了。我一般把评测挂到CI流程里，模型每次合入前自动跑核心指标，分数掉超阈值就卡住。研发流程的改进闭环我也在推，评测结果不能只停在报告里，得反哺到训练数据筛选、提示模板优化、检索策略调整这些环节上去。评测发现问题，改进措施落下去，下一轮评测验证效果，这个循环转起来，评测才算真正在干活。
落地建议这块，我一般按团队成熟度分档给。刚起步的团队先把HumanEval、MBPP跑通，建立基线认知就够了。有仓库级需求的团队把RepoBench、CrossCodeEval加上，重点盯跨文件检索命中率。面向生产环境的方案得把安全合规指标、尾延迟、并发吞吐量全塞进去。我常跟团队说，评测不是为了一份好看的报告，是为了知道模型在哪儿会翻车，提前把坑填上。
