2024 秋 · 作业评分与代码查重
课件 by 陈晟祺。
选做与必做
- 无论黑盒还是白盒，在规模较大时都可设置选做项目（分数）。例如黑盒 80%（基础要求 60% + 提高要求 20%），提供合计约 50% 的可选分；白盒选做可作为加分（如代码风格明显优秀）。
- 必做项目着重考察课程基础内容；详细描述要求、控制难度，给学生成就感；注意内容的递进和依赖关系，防止学生 "卡住"。
- 选做项目作为提高要求，可适当发挥；提供多个不同方向，按难度给分；可留出开放内容，给感兴趣的同学探索空间（谨慎提供分数奖励）。
- 必须严格控制总分，不要留下内卷空间！
评分标准的制定与公布
- 必须：预先确定并使用统一的评分标准。
- 应当：对每个赋分的作业要求详尽规定给分情况。
- 不推荐：主动抹平区分度（后期可再调整，否则损害学习效果）。
- 推荐：根据课程情况决定是否公布详细评分标准——过于含糊，学生很难评价自己的完成情况、对分数没有预期；过于详细，容易过拟合、太死板，学生和助教都失去自主空间。
评分反馈
- 应当及时且详细：课程初期未及时反馈可能导致学生的错误或不良习惯延续；语焉不详的评分没有指导意义。
- 一种推荐做法：将可能的评分点列举出来，批阅/检查时详细标注；事后根据规则计算分数并生成对应评语，包括各部分的得分（至少与文档一样详细）以及额外的评价（扣分理由、做得好与应改进的地方）。
- 善用工具减少工作量：公式 / Python 脚本自动化生成重复部分（如事先准备一些常见问题的评语）；内置检查规则，快速减少差错。
作业迟交处理
- 对迟交作业（尤其是大作业）的处理需把握好度：过于宽松（很少扣分）→ 同学倾向拖延；过于严苛（扣很多分）→ 同学灵活性不够、可能冒险抄袭。
- 折中方案：基于迟交时间长度衰减赋分（S 为原始得分，D 为向上取整的迟交天数，即截止后立刻记为迟交一天）。实践中通过调整系数能在多门课程中取得平衡。
- 无论何种方案，都应在课程开始时（至少任何作业开始前）确定并明确告知学生。
组队作业与评分
- 组队方式：自行组队（大部分人愿意，但对部分同学不友好、易落单）；助教随机分配（易出现组内工作量不均、积极性不高）；助教手工分配（可形成平衡，但助教负担较大）。
- 组间评分原则：组员数量不同时评分标准不宜改变，但可考虑按比例折扣（如一人组 1.03x，二人组 1.00x，三人组 0.95x）；不应鼓励为分数主动"孤军奋战"。
- 组内工作量不均仍是开放问题，可能的应对：验收时逐个提问考核工作量；通过全过程评价、学生反馈与及时干预缓解。
- 参考：组内互评 + 逐个口试 (Evaluating Group Work in (too) Large CS Classes, SIGCSE 2023)；用每周问卷追踪小组合作 (Identifying Struggling Teams in Software Engineering Courses Through Weekly Surveys, SIGCSE 2022)；CATME 同伴互评 及其五个维度。
例子：程序设计训练 Rust 课堂
编程作业 20 分 + 大作业 80 分 + 课堂参与 5 分。小作业由 OJ 完成；大作业共两个、每个 40 分（均为黑盒 80% + 白盒 20%）。黑盒均提供 GitLab CI，验收时增加隐藏测试：大作业一基础 60% + 提高 20%（提供共 65% 的选项），大作业二基础 40% + 提高 40%（提供共 135% 的选项）。白盒提供评分点，评阅时采取扣分制；验收后 1 周左右给出成绩，评语从评分表格自动生成，包含黑盒给分点和白盒扣分点。
作业查重
- 为什么要查重？查重不是不相信同学，而是帮助建立和维护学术诚信意识的必要手段。
- 典型案例：DDL 后把往年同学公开在 GitHub 的代码原样复制提交；没搞懂就让同学给代码并直接提交；对着讲解录像逐字摘抄提交；两人用 GitHub Copilot 生成了一样的代码。
- 查重工具：Stanford MOSS（依赖远端、不支持新语言如 Rust）；mossum 辅助分析 MOSS；Study in Scarlet；JPlag（Java，算法有时结果奇怪）；JiePlag（@jiegec 重写，类 MOSS 体验、支持 C/C++/CUDA/Rust/Verilog/Python 等，Rust 编写、支持本地/服务器运行，已在计算机系私有部署）。
- 查重流程：自动分析 → 阅读结果找可疑重复对（大篇幅重复、核心控制流相同、都用小众语法结构/奇怪空白字符等）→ 约谈同学询问作业完成过程并与 honor code 交叉对比（不给学生太大压力，但严肃告知可能后果）→ 教学团队基于主观陈述和客观事实判断，核心准则是"代码相似程度是否超出了（不交流具体代码的）正常范围"。
书面作业与编程作业的评分
- 书面作业：常是繁重乏味的任务，但也是重要环节。非技术性建议——经常轮换题目防止抄往年作业；题量大时可选择性评分，但不能"电风扇"给分或 strlen 给分；作业结束后及时公布尽量详细的解答；开展习题课或提供错误整理。技术性建议——要求提交通用电子格式（如 PDF），用扫描全能王类软件处理手写纸张；尽量引入自动评分，要求学生以尽量结构化的方式书写答案。
- 书面作业 + LLM：数学相关目前识别和理解都比较困难；纯文本需要大量 prompt 才能良好工作；领域相关知识可能难以喂给模型；模型似乎还不太会算分数。
- 编程作业分数划分：客观评分（黑盒，功能性、可自动测试、学生有明确指标）与主观评分（白盒，非功能性、人工评判、助教有更大发挥空间）。
- 黑盒评分：通常占 70%-90%，有标准答案或可自动化测试。关键选择是否公开测试用例：公开可能导致学生面向答案编程、容易过拟合；不公开可能导致学生畏惧。推荐公开部分测例、设计隐藏测试，或正式评分用不同数据。部分课程在正确性之外设置性能分数（如正确性 80% + 排名 20%），可相对排名或绝对性能赋分，但谨慎设置机制防止无意义"内卷"。
- 自动化评分方案（由简到繁）：同学只提交代码完全由助教测试；提供含测试的代码框架但不提供数据/用例；提供测试并用例；提供测试+用例+测试环境。推荐尽量提供靠后的方案。自动化测试可用 Tsinghua GitLab CI；尽量用通用测试框架（如语言自带 / Googletest）；测试结果尽量详细、结构化输出方便收集评分。
- 白盒评分：通常占 10%-30%，评价作业报告、代码风格与 taste、项目管理（Git）；助教可适度自主裁定，但也要有明确评分项目和标准，避免多个助教评分偏离过大。