不同类型的作业评分

by @HarryChen

书面作业评分

通常是繁重、乏味的任务，但也是教学环节和助教工作的重要部分。目前大模型还不能代劳。

非技术性建议：

• 经常轮换题目（如可能），防止学生直接抄写往年公开作业
• 在题量较大时，可选择性评分，但不能“电风扇”给分或 strlen 给分
• 在作业结束后，及时公布尽量详细的解答
• 开展习题课或者提供错误整理，帮助学生复习

技术性建议：

• 要求学生提交通用的电子格式（如 PDF），使用扫描全能王类软件处理手写的纸张，避免混乱和丢失
• 尽量引入自动评分：如要求学生以尽量结构化的方式书写答案

编程作业评分

编程作业的评分通常可以划分为客观和主观两部分。

客观评分（黑盒）有客观功能性标准，（通常）可以进行自动测试，学生可以有明确的指标参考。

主观评分（白盒）非功能性标准，人工评判，助教有更大的发挥空间。

黑盒评分

通常占较大部分的分数组成（70%-90%）

有标准答案，或可以进行自动化的测试评分，作为作业的功能性评价

关键选择：是否公开测试用例/数据？

• 如果公开，学生可能面向答案编程，容易过拟合
• 如不公开，可能导致学生的畏惧心理

推荐做法：公开部分测例，设计隐藏测试，或正式评分使用不同数据 、 部分课程还在正确性外，设置性能分数

如：黑盒部分再分为正确性 80%，排名 20%,可按照相对排名/绝对性能赋分。谨慎设置机制，防止无意义“内卷”消耗时间精力。

黑盒部分的自动化评分可以有多层级的方案(推荐有条件的情况下尽量提供靠后的方案)

• 同学只提交代码，完全由助教测试
• 提供含测试的代码框架，不提供数据/用例
• 提供含测试的代码框架，提供（可能不完整的）测试/用例
• 提供含测试的代码框架，提供（可能不完整的）测试/用例+测试环境

具体来说,

• 自动化测试：可使用 Tsinghua GitLab CI
• 测试框架：尽量使用通用的测试框架（如语言自带 / Googletest 等）
• 测试结果：尽量详细，并以结构化形式输出，方便收集评分

白盒评分

通常分数占比较少（10%-30%），作为作业的非功能性评价，如：作业报告、代码风格与 taste、项目管理（Git）。助教可进行适度的自主裁定。

尽管人工裁定，也应该有明确的评分项目和标准，避免多个助教的评分出现较大偏离。在培养学生良好习惯的同时减少困惑。

选做与必做

无论是黑盒还是白盒，在规模较大时，都可以设置选做项目（分数）

如：黑盒 80%，其中基础要求 60%，提高要求 20%（提供 ~50% 的可选分内容）。白盒选做可以作为加分形式（如：代码风格明显优秀）。

必做项目着重考察课程基础内容，详细描述要求、控制难度，给学生提供成就感。

注意内容的递进和依赖关系，防止学生“卡住”。

选做项目作为提高要求，可适当发挥，提供多个不同方向，根据难度赋予不同的分数。

可留出开放内容，给感兴趣的同学探索空间（谨慎提供分数奖励），但必须严格控制总分，不要留下内卷空间！

评分标准的制定与公布

必须预先确定并使用统一的评分标准

应当对于每个赋分的作业要求详尽规定给分情况

不推荐主动抹平区分度：后期可以再行调整，否则损害学习效果

推荐根据课程情况决定是否公布详细评分标准

• 过于含糊：学生很难评价自己的完成情况，对分数没有预期
• 过于详细：容易过拟合，且太死板，学生和助教都失去自主空间

可以给学生一个简单版的评分标准, 助教评分使用详细版的评分标准。

评分反馈/评语

评分反馈应当及时且详细，课程初期未能及时反馈可能导致学生的错误或不良习惯延续，而语焉不详的评分没有指导意义。

一种推荐做法：

• 将所有可能的评分点列举出来，批阅/检查时详细标注
• 事后根据规则计算分数，并生成对应评语，包括各部分的得分（至少应该与文档一样详细）
• 包括额外的评价（如扣分理由、做的好和应该改进的地方）
• 善用工具减少工作量：如公式 / Python 脚本
• 自动化生成重复部分（如事先准备一些常见问题的评语），内置检查规则，快速减少差错。

作业迟交处理

对迟交作业（尤其是大作业）的处理需要把握好度。

• 过于宽松（很少扣分甚至不扣分）→ 同学倾向于拖延，不按时完成作业
• 过于严苛（扣分很多甚至不得分）→ 同学灵活性不够，并可能冒险抄袭

折中方案：基于迟交时间长度衰减赋分

\[ S' = S \times \min(0.8, 0.95^D) \]

其中 S 是原始得分，D 是向上取整的迟交天数（即截止后立刻记为迟交一天）

实践中此方案（通过调整两个系数）能够在多门课程中取得平衡

无论采取何种方案，都应该在课程开始时（至少是任何作业开始前）确定并明确告知学生。

组队作业评分

组队的不同方式：

• 自行组队：大部分人愿意，但对部分同学不友好，很容易落单
• 助教随机分配：容易发生组内工作量不均和积极性不高的问题
• 助教手工分配：可形成一些平衡，但助教负担较大

组间评分原则：

• 如有组员数量不同，评分标准不宜改变，但可考虑分数按比例折扣
• 如：一人组 1.03x，二人组 1.00x，三人组 0.95x
• 不应鼓励为分数主动“孤军奋战”

“组内工作量不均”的问题依旧是开放性的，可能的应对：

• 在验收时逐个提问达到考核工作量的目的
• 通过全过程评价、学生反馈与及时干预缓解问题

组队评分相关参考:

组内互评+逐个口试：

Evaluating Group Work in (too) Large CS Classes with (too) Few Resources: An Experience Report. (SIGCSE 2023).

用每周问卷追踪小组合作情况：

Identifying Struggling Teams in Software Engineering Courses Through Weekly Surveys （SIGCSE 2022）

CATME peer evaluation

https://info.catme.org/features/peer-evaluation/

https://info.catme.org/features/catme-five-dimensions/