主观题 AI 智能阅卷：批量初评与教师复核如何协同
客观题可以自动判分，主观题却常常成为成绩发布前的等待环节。同一道论述题，几百名学员就对应几百次阅读、比对和打分；多位教师共同阅卷时，还要反复对齐评分口径。
对企业培训和教培机构来说，缩短阅卷周期只是一个目标。更关键的是：题目按什么标准给分，教师在哪里修正，批量处理失败后又该如何定位。
织码在线教育系统采用"AI 批量初评、教师逐卷复核"的方式，把重复性的初步比对交给模型，把最终评分判断留给教师。本文围绕阅卷入口、异步处理、评分材料和人工复核，梳理这套方案的实现思路与使用边界。
一 从待阅卷列表到教师复核
主观题阅卷位于考试数据管理模块，接口统一挂在 /resource/admin/exam/data 下。管理员先筛选答卷，再发起批量 AI 初评，最后进入单卷视图复核与修正，评分结果回到考试记录 ExamUserRecord。
图 1 阅卷链路中的自动处理与人工确认
| 接口 | 方法 | 职责 |
|---|---|---|
/evaluation/list |
GET | 按考试或学员筛选待阅卷答卷 |
/evaluation/ai/batch |
POST | 提交批量 AI 阅卷请求，返回受理响应 |
/evaluation/start |
GET | 载入单卷复核所需的试卷与作答材料 |
列表请求 AdminExamDataEvaluationListReq 包含 examType、relateId、userId，分别对应考试类型、关联考试和学员筛选。批量请求 AdminExamDataEvaluationAiBatchReq 则使用 recordIds 指定答卷记录。
三个接口承担的是查询、受理和载入。尤其需要注意，/evaluation/start 用于进入复核视图，不能把它等同于"保存教师评分"或"确认发布成绩"；后续提交动作应以实际评分保存流程为准。
二 异步批处理让提交与评分分开
模型评分耗时受答卷长度、模型响应和服务配额影响。若前端必须等待整批答卷完成后才拿到响应，容易出现长时间等待和请求超时。
AdminExamDataBiz.evaluationAiBatch 将受理与执行拆开：先对 recordIds 去重、形成受理计数，再通过 threadPoolTaskExecutor.execute(...) 启动后台处理，接口随即返回受理响应。
请求被受理，表示处理已经发起，并不表示答卷已经评分成功。 这一区分直接影响管理端如何提示状态，也影响运营人员什么时候可以开始复核。
图 2 提交受理与后台评分分别推进
1 先批量读取 再按答卷组织数据
后台方法 handleEvaluationAiBatch 先通过 examUserRecordDao.listByIds(recordIds) 批量读取答卷，再批量查询作答并按 recordId 分组，随后逐卷调用 AI 评分。
这种组织方式减少了逐卷反复查询数据库的开销。不存在的答卷记录可计入跳过数量，避免单个无效 ID 阻断其他答卷。它优化的是数据读取方式，并不意味着模型调用本身已经并行执行。
2 五个计数器应区分受理状态与处理结果
响应结构 AdminExamDataEvaluationAiBatchResp 包含以下字段：
| 字段 | 应如何理解 |
|---|---|
totalCount |
去重后的答卷总数 |
submittedCount |
本次受理的答卷数，不是完成数 |
successCount |
评分成功数量，应结合更新时点理解 |
skipCount |
跳过数量，例如记录不存在 |
failureCount |
处理失败数量 |
这些字段为批次统计提供了基础，但一次立即返回的 HTTP 响应不会自动携带后台后来更新的计数。要在前端持续展示进度，还需要能查询后台最新状态的机制，例如持久化批次状态并提供查询接口。
因此，仅凭响应中有这五个字段，不能断言系统已经具备实时进度、轮询查询或失败重试能力。管理端能否通过刷新看到结果，应结合实际状态落库与列表查询实现确认。
三 评分口径从参考答案开始
批量处理解决"怎么处理更多答卷"，评分材料则决定"模型依据什么给分"。平台通过 AiQuestionGradingReq 将题目和作答组织为统一请求：
| 字段 | 提供给评分过程的信息 |
|---|---|
questionId / questionType |
题目身份与题型 |
questionTitle |
题干与作答要求 |
questionAnswer |
参考答案或评分要点 |
questionScore |
本题满分 |
userAnswer |
学员实际作答 |
optionCount |
选择题场景的选项数，主观题不以此作为评分依据 |
其中，questionAnswer 是模型与教师对齐口径的重要载体。若只提供一段笼统的参考答案，模型仍可能对表达差异、部分正确和遗漏要点作出不同判断。
更适合落地的做法是，在参考答案中写清关键得分点、各点分值、可接受的等价表述及扣分条件。例如，一道 10 分的案例题，可以明确"问题识别 3 分、原因分析 3 分、改进措施 4 分"。这是评分标准的编写示例，不代表平台已经实现自动拆分评分点。
图 3 模型初评与人工复核使用一致的评分材料
多模型接入与调用限流
模型调用由 TextModelService 体系承接，实现包括 AnthropicMessagesTextModelImpl、OpenAiCompatibleTextModelImpl、OpenAiResponsesTextModelImpl，可按配置选择接入方式。
集中阅卷时，Redisson 限流用于控制调用节奏、减少触及模型配额的风险。限流不等于调用一定成功；切换接入方式也不等于评分结果天然一致。正式使用前，仍应使用同一组样卷检查模型与人工评分的差异。
四 教师复核决定最终评分
AI 初评后的答卷需要回到教师工作台。/evaluation/start 根据 recordId 返回 AdminExamDataEvaluationStartResp，将复核所需的考试信息、试卷结构和学员作答放在同一上下文中。
| 信息组 | 关键字段 | 复核用途 |
|---|---|---|
| 考试与答卷 | recordId、examType、examName |
确认复核对象 |
| 试卷身份 | paperId、paperName |
核对所关联试卷 |
| 时间信息 | submitTime、answerTime |
辅助了解作答过程 |
| 分值规则 | totalScore、passScore |
对照试卷满分与及格线 |
| 题目结构 | titles（ExamTitle 列表） |
对照题干、参考答案与学员作答 |
管理端页面位于 views/content/exam/record/evaluation/：index.vue 提供工作台入口，List.vue 承担列表和批量操作，Card.vue 展示答卷及考生信息，Question.vue 支持单题评分。
教师复核时应重点检查部分正确、等价表达和边界得分，确认模型是否漏看有效要点、误解作答含义，或给出超出本题满分的分数。AI 可以减轻初步阅读与比对的负担，最终成绩仍以教师复核结果为准。
现有字段说明中没有展示置信度指标或自动分流规则，因此不宜把"只复核低置信度答卷"作为现成功能对外描述。没有经过验证的筛选机制时，应保留必要的逐卷复核安排。
五 从小批样卷开始落地
建议先选一组覆盖完整作答、部分正确、空白答案和不同表达方式的样卷，由教师形成评分参照，再测试 AI 初评。确认主要偏差后，优先调整评分要点，而不是直接扩大处理规模。
| 场景 | 建议做法 |
|---|---|
| 客观题占主导 | 延续已有自动判分，按需要处理主观题 |
| 主观题集中考试 | 分批发起 AI 初评，安排教师复核后定分 |
| 多教师共同阅卷 | 提前统一得分点与扣分条件，减少宽严差异 |
| 处理失败或记录跳过 | 分别检查答卷数据、调用错误及配额状态，确认后再处理 |
| 成绩申诉 | 对照题干、参考答案、原始作答和复核结果进行解释 |
运营评估可以关注批次完成耗时、失败与跳过数量、人工修正比例和单卷复核用时。这些是建议观察的指标，不代表平台已经内置相应看板，也不应预设固定的提效比例。
与 AI 出题相比，两者使用相似的模型能力，但处理对象不同：出题将知识资料转成题目，需审核后入库；阅卷将题目、参考答案与作答转成初评结果，需复核后定分。人工确认应落在各自业务流程的关键位置。
总结
主观题 AI 阅卷的价值，来自批量处理能力与教师判断的配合。异步机制把提交等待与评分执行分开，批量读取减少重复查询，统一的评分材料为口径一致提供基础，单卷复核则让教师能够校正模型判断。
真正可用的阅卷流程，还需要把受理与完成、初评与定分、统计字段与进度查询区分清楚。评分标准越明确，处理状态越可追踪，教师复核越有依据，AI 辅助阅卷才能稳定融入考试管理。