简介基于LLM的高中语文作文自动批改应用项目面向高中语文教师与教育技术开发者旨在解决传统作文批改耗时耗力的问题提供了一套完整可运行的代码示例便于教师或研究者快速验证自动批改效果。压缩包共18个文件以5个Python脚本承担核心批改逻辑xml/iml文件保存工程配置txt与md文件分别提供依赖清单和运行说明整体约21KB结构紧凑便于快速审阅。目前已有94人学习下载。该应用实现了自动评分、错误识别与标注、内容建议、数据分析和个性化反馈等主要功能核心脚本封装大模型调用逻辑批改任务模块负责流程组织测试脚本用于功能验证。关注LLM教育应用和智能作文批改的技术开发者可在本地直接运行代码结合文档理解模块设计与实现思路作为轻量参考进行二次开发或教学演示。1. 基于LLM的高中语文作文自动批改应用为什么这个zip值得解压连续批改一个班45篇作文再赶上两篇征文语文老师的晚自习基本就交代了。基于LLM的高中语文作文自动批改应用正是冲着这个痛点来的用大模型LLM当阅卷助手先把分项分数和点评初稿跑出来老师再复核效率能提一倍。但直接拿通用大模型“读一遍给个总分”是不行的分数忽高忽低还没有理由老师根本不敢用。这个zip里装的其实是一整套工程方案评分维度提示词、调用脚本、结果解析、本地部署配置解压之后顺着跑你就能得到一个“分数可解释、结果可复现”的批改流水线。适合两类人教育产品开发者以及有一定编程基础的语文老师。2. 从作文文本到分项得分批改系统的整体架构与提示词设计拿到这个zip后我的建议是先别急着看代码先想清楚一件事自动批改不是“让大模型读一遍作文然后给个分”而是要把作文按评分标准拆成可量化、可解释的维度再让LLM逐项输出。这一章先把架构讲透再给一组可以直接复制的提示词模板后面的代码都是围绕这套模板转的。2.1 先定评分维度高考作文评分标准如何转成LLM可执行的打分卡首先把高考作文评分标准转成“基础等级 发展等级”两个大块。基础等级包括内容题意、中心、内容、情感和表达语言、结构、文体、卷面发展等级看深刻、丰富、有文采、有创新。直接把这些文字塞给LLM它会给你一套正确的废话。所以落地前我会先把评分标准压成一张打分卡维度满分打分依据写入Prompt立意与中心20是否切题、中心是否突出、观点是否深刻素材与论证20素材是否贴切、论证是否充分、逻辑是否严密语言表达20用词是否准确、句式是否灵活、有无语病结构层次20层次是否清晰、过渡是否自然、首尾是否照应发展等级20是否有亮点文采、创意、思想深度为什么不直接让模型打总分直接输出总分看着很酷但你没办法向学生解释这个分数是怎么来的也没法定位一篇作文到底差在哪。分项打分的好处是哪怕总分算法有问题你也能看到“立意给了18分语言只有12分”这时候再让老师人工复核效率会高很多。所以这套系统里所有Prompt都围绕分项展开最后总分由分项相加。这个决策看似简单却是批改工具能不能被老师信任的分水岭。2.2 Prompt模板与输出约束让LLM输出结构化JSON而不是一堆废话LLM-as-Judge的常见翻车点是不约束输出格式让它自由发挥结果返回一千字点评程序没法解析。我一般会在Prompt里强行要求输出JSON并给出示例。下面这段模板是从这类工程里提炼出来的可以直接放进config或prompts.py里。# prompts.py SCORING_SYSTEM_PROMPT 你是一位有20年经验的高中语文阅卷教师熟悉高考作文评分标准。 请按以下维度对作文逐项打分每个维度满分20分 立意与中心、素材与论证、语言表达、结构层次、发展等级。 要求 1. 严格输出JSON不要输出任何其他文字。 2. JSON结构必须如下 { scores: {立意与中心: 0, 素材与论证: 0, 语言表达: 0, 结构层次: 0, 发展等级: 0}, total_score: 0, comments: {优点: , 不足: , 修改建议: } } 3. 每个分数必须结合作文原文中的具体句子给出理由理由放在comments中。 4. 如果作文有明显错别字或病句在不足中明确指出。 def build_user_prompt(essay_text: str, title: str) - str: return f请批改这篇以《{title}》为题的作文\n{essay_text}这段代码的逻辑分两层SCORING_SYSTEM_PROMPT固定给系统角色告诉模型“你是谁、要干什么、输出什么格式”build_user_prompt拼出用户角色那部分内容把作文原文塞进去。参数上最重要的一点是必须在系统提示词里用“严格输出JSON不要输出任何其他文字”来约束输出否则后面写解析代码会非常痛苦。如果模型硬是不按JSON来最常见的补救是加“few-shot示例”也就是在系统提示词里放一个已经填好的JSON例子。JSON_EXAMPLE {scores: {立意与中心: 16, 素材与论证: 14, 语言表达: 15, 结构层次: 16, 发展等级: 13}, total_score: 74, comments: {优点: …, 不足: …, 修改建议: …}}把JSON_EXAMPLE拼进SCORING_SYSTEM_PROMPT里格式错误率会明显下降。还有一个预处理技巧如果作文文本超过模型上下文长度先截断到前1000字再批改虽然会丢结尾但多数考场作文的立意在开头结构问题看段首句也能判断总比直接把上下文撑爆强。实践中我会在temperature上设0.2甚至0让同一个模型对同一篇作文的两次打分尽可能接近max_tokens要根据作文长度留够通常一篇800字作文完整JSON输出需要1500到2000个token只给512很容易被截断。2.3 选型理由为什么先试LLM as Judge而不是微调很多人拿到这个zip第一反应是“我要用这个数据去微调一个作文批改大模型”。我的建议是第一批先别微调。原因是作文批改的数据量很难攒够一线老师能给你标注两三百篇已经是极限这点数据去微调一个7B模型效果往往是灾难性的而且一旦微调评分标准改了就得重新训练迭代成本太高。更可靠的做法是先做LLM-as-Judge用通用大模型加结构化提示词完成批改再用规则去校正明显偏差。这套流程跑通后你会积累大量“作文文本 分项分数 评语”的三元组那时候再考虑用LoRA做轻量微调才有干净的数据基础。怎么判断模型批改靠不靠谱第一步是拿三五篇已经有人工评分的作文试跑看模型能不能复现老师的评分趋势第二步是算“相邻分差”看总分差多少。很多人忽略的是“相邻分差”比“绝对分数”更重要一个模型如果总是把三类文多给5分至少排名顺序是对的老师复核时心里有底如果顺序都乱了那说明提示词本身出了问题。选型结论先立在这里在没有高质量标注语料之前LLM-as-Judge加规则校正是单位成本最低、迭代最快的起点。3. 用Python搭起批改流水线从解析zip工程到跑通第一次批改如果说第2章是“动脑”这一章就是“动手”。跟着我把这个zip解压、看懂目录结构、改掉配置文件然后跑通第一次自动批改。所有代码都是Python依赖只有requests或openai、yaml、json这几个常用库新手也能跟下来。3.1 解压并理解工程结构config.yaml与数据目录一般的项目压缩包会按“配置、输入、输出、代码”四块组织。先执行下面的命令解压并查看结构mkdir -p essay_grader unzip 基于LLM的高中语文作文自动批改应用.zip -d essay_grader cd essay_grader tree -L 2 -I __pycache__解压后你通常会看到config.yaml、prompts.py、grader.py、data/input和data/output这类文件。tree命令的作用是把目录层级打印出来-L 2表示只显示两层-I用来排除缓存目录避免干扰视线。这个工程的核心就两个一个是config.yaml里写模型接入参数和评分权重另一个是grader.py里写批改主流程。先打开config.yaml看看默认配置# config.yaml model: api_base: https://api.openai.com/v1 api_key: ${OPENAI_API_KEY} model_name: gpt-4o-mini temperature: 0.2 max_tokens: 2000 scoring: dimensions: - 立意与中心 - 素材与论证 - 语言表达 - 结构层次 - 发展等级 each_full_score: 20 input: folder: data/input encoding: utf-8 output: folder: data/output save_json: true这里api_base和api_key用环境变量OPENAI_API_KEY来替换避免把密钥写进代码里temperature和max_tokens直接对应第2章说的两个关键参数。scoring部分定义了五个评分维度每个满分20分正好凑成100分。如果你要改成中考作文标准把dimensions列表和each_full_score改掉就行提示词会由代码自动拼接这是配置化设计的第一个好处。3.2 调用LLM进行分项批改requests与openai SDK的两种方式接下来写核心的批改调用。如果你用的是OpenAI官方SDK代码很短如果你用的是其他兼容接口换成requests也基本是同样格式。我把两种方式都放在下面你按自己的api_base选择。# grader.py import json, os, yaml import openai from prompts import SCORING_SYSTEM_PROMPT, build_user_prompt def load_config(pathconfig.yaml): with open(path, r, encodingutf-8) as f: return yaml.safe_load(f) def grade_with_sdk(cfg, essay: str, title: str) - dict: client openai.OpenAI(api_keyos.getenv(OPENAI_API_KEY), base_urlcfg[model][api_base]) resp client.chat.completions.create( modelcfg[model][model_name], temperaturecfg[model][temperature], max_tokenscfg[model][max_tokens], messages[ {role: system, content: SCORING_SYSTEM_PROMPT}, {role: user, content: build_user_prompt(essay, title)} ], response_format{type: json_object} # 适配OpenAI的JSON模式 ) return json.loads(resp.choices[0].message.content)这段代码的逻辑是load_config负责把YAML配置读进来grade_with_sdk创建OpenAI客户端、组装两段消息、发起请求最后把返回的字符串用json.loads解析成字典。参数说明里最重要的一项是response_format{type: json_object}这是OpenAI自带的JSON模式能在接口层就约束输出为JSON比靠提示词硬顶可靠很多。如果你的模型服务不支持这个参数就把它删掉然后依赖第2.2节里的“严格输出JSON”提示词加上后续解析兜底。# grader_requests.py import requests, json def grade_with_requests(cfg, essay: str, title: str) - dict: url cfg[model][api_base].rstrip(/) /chat/completions headers {Authorization: fBearer {os.getenv(OPENAI_API_KEY)}, Content-Type: application/json} payload { model: cfg[model][model_name], temperature: cfg[model][temperature], max_tokens: cfg[model][max_tokens], messages: [ {role: system, content: SCORING_SYSTEM_PROMPT}, {role: user, content: build_user_prompt(essay, title)} ] } resp requests.post(url, headersheaders, jsonpayload, timeout120) resp.raise_for_status() content resp.json()[choices][0][message][content] return json.loads(content)用requests方式的区别在于手动拼URL和Headers。这里要注意必须设置timeout120作文批改属于长文本生成30秒超时是常态不给足超时时间会频繁报错。两种方式的返回都是同一个dict结构后面解析和保存的逻辑可以完全复用这也是把“调用”和“业务”拆开的好处。3.3 打分校正与评语生成用规则修正LLM的分数漂移LLM打的分不能直接用。至少有两个问题它处理不好一是错别字和字数这类硬伤大模型经常“看漏”二是它对“离题”这种全局性问题的惩罚力度不够。所以我会在拿到JSON后再做一层规则校正。# postprocess.py import re def count_chinese_chars(text: str) - int: # 统计中文字符数量排除标点和空格 return len(re.findall(r[\u4e00-\u9fff], text)) def correct_scores(raw: dict, essay: str) - dict: chinese_len count_chinese_chars(essay) # 字数不足低于600字每少50字扣2分最多扣10分 word_deduction 0 if chinese_len 600: word_deduction min(10, ((600 - chinese_len) // 50) * 2) # 错别字每2个错别字扣1分最多扣5分这里用简单规则模拟 typo_deduction 0 comments raw[comments] if word_deduction 0: comments[不足] comments[不足] f 字数不足600字按规则扣{word_deduction}分 raw[total_score] max(0, min(100, sum(raw[scores].values()) - word_deduction - typo_deduction)) return rawcorrect_scores的作用是在LLM输出的基础上叠加“硬扣分”。count_chinese_chars用正则排除标点后统计中文字符数比直接len()准。字数不足时每缺50字扣2分、上限10分错别字检查这里留了接口实际工程可以用现成的纠错库也可以把错别字检测也交给LLM但要注意别让它自己改完作文再打分否则分数会被“美化”。这个规则层的设计意图是LLM负责“软评分”规则负责“硬扣分”两者互相补充最终分数才经得起老师复核。批改完成后把结果保存成JSON同时打印一行摘要这样批量跑作文时扫一眼就能发现问题。保存逻辑很简单建目录写文件文件名用作文序号加标题前十个字避免标题里的特殊字符把路径搞坏。日志同样重要每次调用记录“模型名、耗时、返回是否合法”批量跑完统计出“JSON解析失败率”这个数字就是后续调提示词最好的数据指标。4. 本地部署与模型量化把云端API换成GGUF模型的完整步骤云端API方便但有三道坎批量跑成本累计不小学生作文属于隐私数据往外发有合规压力还有外部模型服务可能随时变更导致依赖风险。所以等流水线跑通后我一般会再把它迁移到本地模型上。这一章讲的就是用GGUF量化模型替换云端API的完整路径也是这个zip里“离线运行”那部分的设计初衷。4.1 为什么选GGUF量化模型性价比与隐私GGUF是llama.cpp推出的模型格式它把模型权重量化成4bit或8bit大小能压到原来的四分之一甚至更小。以7B参数模型为例FP16权重约14GB量化成Q4_K_M后约4.4GB普通带8GB显存的消费级显卡就能跑CPU也能运行只是慢一些。对于作文批改这种“任务明确、长度中等”的场景7B级别模型配合第2章的强提示词效果已经能用。选型时我会优先看支持中文的Instruct类模型比如Qwen系列和Yi系列它们在中文长文本上明显比同规模的英文模型稳。隐私因素更直接学生作文放本地不出校门老师心理负担小也更容易通过学校的信息安全评估。模型文件从Hugging Face等社区下载文件名一般形如qwen2.5-7b-instruct-q4_k_m.gguf。下载完成后先检查文件哈希是否匹配防止下到半截损坏然后做个最小加载测试python -c from llama_cpp import Llama; mLlama(模型路径.gguf, n_ctx512); print(m(你好, max_tokens32)[choices][0][text])最小加载测试的意义是区分“模型文件坏了”和“业务代码有bug”。如果这行命令都跑不出来就不要去调业务代码了先重下模型或补齐依赖。这一步能省下后面至少半小时的排查时间。4.2 用llama-cpp-python加载GGUF并替换API本地推理最省事的方案是llama-cpp-python它把llama.cpp封装成Python库加载GGUF文件后可以沿用第3章的业务代码只需要把“调用API”换成“调用本地模型”。pip install llama-cpp-python --extra-index-url https://abetlen.github.io/llama-cpp-python/whl/cpu # 如果要GPU加速把extra-index-url换成对应CUDA版本或者从源码编译安装命令里--extra-index-url指定了预编译wheel源避免你本地编译时卡在CMake和C编译器上。安装完成后加载模型# local_grader.py from llama_cpp import Llama def load_local_model(model_path: str, n_gpu_layers: int -1): return Llama( model_pathmodel_path, n_ctx4096, # 上下文长度按最大作文长度输出长度预留 n_gpu_layersn_gpu_layers, # -1表示全部层放GPU0表示纯CPU verboseFalse ) def grade_local(llm, cfg, essay: str, title: str) - dict: prompt fsystem: {SCORING_SYSTEM_PROMPT}\nuser: {build_user_prompt(essay, title)}\nassistant: resp llm( prompt, max_tokenscfg[model][max_tokens], temperaturecfg[model][temperature], stop[\n\nuser:] ) return json.loads(resp[choices][0][text].strip())grade_local和grade_with_sdk最大的不同在于本地模型没有“系统消息”通道必须把系统提示词和用户提示词拼成一个字符串喂给模型并在末尾加assistant:提示模型开始输出。n_ctx4096要提前想好如果作文最长1000字输出JSON约2000字符那么4096是安全的如果批改长文可以调到8192但显存占用会翻倍。stop参数用来让模型在遇到下一个user:时停止生成防止模型自己给自己出题。4.3 参数微调context长度、n_gpu_layers、batch_size对批改质量的影响同样的GGUF模型参数不同批改体验天差地别。下面这张表是我调参时的基准值适合7B量化模型参数推荐值影响踩坑点n_ctx4096覆盖作文输出太小则长文被截断太大则显存不足n_gpu_layers-1全GPU推理速度显存不够时自动改部分层或退回CPUtemperature0.2分数一致性0.7会让同一篇作文两次差10分以上max_tokens2000评语是否完整小于1500经常截断JSONbatch_size512不影响单篇质量调大能提高吞吐但吃显存这里重点说n_gpu_layers很多人以为设成-1就万事大吉但显存只有6GB时把7B模型全放GPU会直接OOM。我一般先看显存大小用n_gpu_layers35这类值让部分层跑GPU其余层跑CPU速度比纯CPU快又不至于爆显存。batch_size只在批量跑作文时影响性能单篇调试时不用动它。调完参后要做一次“一致性自测”拿同一篇作文跑三遍看总分标准差标准差超过3分就说明参数太飘优先降temperature而不是改提示词。为了让代码在云端API和本地模型之间来回切我会在config.yaml里加一个runtime: local或runtime: cloud字段然后封装一个获取批改函数的接口def get_grader(cfg): if cfg[runtime] cloud: return lambda e, t: grade_with_sdk(cfg, e, t) else: llm load_local_model(cfg[local][model_path]) return lambda e, t: grade_local(llm, cfg, e, t)这样的好处是后续所有测试脚本、批量任务都不用关心底层用的是什么换运行时只改配置。这个设计也符合这个zip工程里“配置与代码分离”的思路把模型接入细节全隔离在config.yaml里业务代码只认配置将来换更好的模型只改一行路径。5. 避坑LLM自动批改的5个常见翻车现场与排查清单理论再好落地总会碰见各种玄学问题。这一章把我反复踩过的5个坑按“现象 → 原因 → 解决”写清楚。都是真实会遇到的不是凑数。每一条后面都跟一个排查思路方便你对着症状找药方。5.1 现象模型把满分范文判成三类文分数低得离谱现象就是模型对明显优秀的作文给了很低的分数评语还说得头头是道让人一度怀疑模型瞎了。原因分析不是模型智力问题是提示词里没有“评分细则”。我用第一版Prompt时只写了“按高考评分标准打分”模型对“基础等级50分、发展等级20分”的理解和真人不一致导致它把常见的议论文文风当成平庸。解决把评分标准拆成分项打分卡第2.1节并且每一维度的Prompt里加入“结合原文句子说明”逼着模型给出可追溯的扣分依据。还可以在系统提示词里加一句“不要因为文章风格与你偏好不同而扣分”能减少模型对叙述性散文的刻板偏见。总结先解决提示词可落地性再怀疑模型能力。5.2 现象模型返回的JSON不完整程序直接抛JSONDecodeError现象是批量任务跑了一多半突然整个脚本退出报错json.decoder.JSONDecodeError。原因分析两个来源一是max_tokens太小输出被截断JSON字符串没有闭合二是模型不遵循JSON指令在JSON后面又写了一段话或者字段名带了中文引号。解决第一步调大max_tokens到2000以上第二步用response_format开启接口层JSON模式第三步在代码里做容错解析——找到第一个{和最后一个}截取中间内容再json.loads。如果截出来的还不是合法JSON就返回一个固定错误结构记录日志跳过这篇作文而不是让整个批量任务崩溃。我一般会写一个safe_json_loads函数把这三种情况全部兜住。5.3 现象本地模型生成速度慢到没法用批改一篇要5分钟现象是换成GGUF本地模型后单篇批改耗时直线飙升老师那边根本等不住。原因分析最常见是n_gpu_layers0所有层都在CPU上跑其次是n_ctx设得过大导致KV Cache占满显存实际吞吐反而下降还有一种情况是量化等级太高模型虽然能跑但重复生成严重需要反复采样才能出结果。解决先检查显存把n_gpu_layers设为-1或按显存估算层数把n_ctx压缩到刚好够用用Q4_K_M这种主流量化等级不要为了省空间用Q2。如果CPU性能实在不够还有一个办法是“分点评”一次让模型只输出两个维度的分数分三次调用单次输出变短速度会快不少代价是总耗时没省太多但失败率大幅下降。5.4 现象同一篇作文两次批改总分差15分完全没法用现象是拿同一篇作文重复调用分数忽高忽低老师拿这个结果去找学生面谈都没底气。原因分析这锅90%由temperature背。作文批改是“评估任务”不是“创作任务”需要尽可能确定性输出。temperature0.7时模型采样路径不同输出差异极大。解决把temperature降到0到0.2之间。如果你已经降到0.2还是不稳定那问题就在提示词里某个指令有歧义比如“亮点”这个词模型每次的理解不一样改成“发展等级分仅当存在明显文采、创意、思想深度时才给高分否则给12分以下”锚定后稳定性会好很多。另一种做法是跑三次打分取中位数但这是治标先排除温度和提示词问题再考虑。5.5 现象评语写得天花乱坠但全是空话学生看完全不知道改哪里现象是评语里全是“语言流畅、结构清晰、中心突出”这类万能套话放到任何一篇作文上都成立。原因分析Prompt里没要求“结合原文引用”模型只能给通用评价。解决在生成评语前加一个中间步骤让模型先摘录作文中三句话作为依据再写评价。可以用这个思路def build_comment_prompt(essay, scores): return f学生作文如下已得分数{scores}。 请先摘录作文中3个具体句子分别代表优点、不足、需要改进处 然后针对每个句子给出修改建议要求具体到“把某个词换成什么”。 作文{essay}这个“摘录建议”的Prompt结构是作文批改里最有效的落地技巧。模型一旦被要求引用原文它就很难写空话。另外评语生成可以用单独的、温度稍高一点的调用比如0.4因为评语需要一点语言多样性不会影响打分稳定性。如果以上问题同时出现我建议按这个顺序查先看日志里JSON解析失败率失败率高于10%先走5.2的容错逻辑然后跑同一篇作文三次看标准差超过3分走5.4调温度和提示词再测单篇耗时超过60秒走5.3调设备参数最后人工抽查两条评语看有没有空话有就走5.5加引用步骤。这个顺序从“程序能不能跑”到“结果能不能用”一层层排除能省掉大量无头绪的试错。6. 让批改结果更可信一致性验证与回归测试的进阶做法做到这里你已经能批量批改作文了。但老师和学生真正信任一套自动批改系统靠的不是单次满意度而是“同一篇作文今天批和明天批结果是否接近两个老师人工复核是否认可分项”。这章讲两个能显著提升可信度的验证手段和一个轻量微调的启动时机判断。6.1 用Kappa系数把“批得好不好”变成数字先拿20篇作文每篇让LLM批三次记录总分。然后计算Cohens Kappa。下面是计算Kappa的最小代码# consistency_check.py from sklearn.metrics import cohen_kappa_score def rating_to_level(score: float) - int: if score 85: return 5 if score 75: return 4 if score 60: return 3 if score 45: return 2 return 1 def kappa_of_three_runs(scores: list) - float: run1 [rating_to_level(s[0]) for s in scores] run2 [rating_to_level(s[1]) for s in scores] return cohen_kappa_score(run1, run2)rating_to_level把连续分数切成五档因为Kappa适合有序分类数据。第一次跑时Kappa低于0.5很常见别急着调模型先看分数分布是不是集中在同一档。我的习惯是0.6以上算及格0.75以上算可靠。这个数字可以直接写进验收标准里。6.2 给批改系统加一道回归测试改提示词是最容易“改好了张三改崩了李四”的操作。我会把30篇有代表性的作文固定下来每次改动后跑一遍这30篇看“JSON解析成功率”和“与基准版本分数的平均绝对差”。这个思路和软件工程里的单元测试同源脚本结构很简单def run_regression(cfg, sample_essays: list): success 0 diffs [] for item in sample_essays: result get_grader(cfg)(item[text], item[title]) if scores not in result: continue success 1 diffs.append(abs(result[total_score] - item[baseline_score])) print(f成功率{success}/{len(sample_essays)}, 平均绝对差{sum(diffs)/len(diffs):.1f})跑回归测试要保存一份基准版本输出。我早期吃过亏没有基准改完提示词感觉不错跑了几天才发现某类文体全被压低了分但已经攒了一堆错误分数。后来养成“每改一版提示词就跑一次30篇回归”的习惯半小时能换来后面几个小时的返工。6.3 什么时候才值得上LoRA微调当你攒够500篇以上“原文 人工复核分数”的数据后才值得考虑把通用LLM微调成作文批改专用模型。首选LoRA而不是全参微调因为7B模型全参微调需要多张高显存显卡LoRA用一张消费级显卡就能跑。微调数据不是把作文和总分拼在一起就完而是要构造指令-问答对指令是“按五个维度批改以下作文”输出是那篇作文的五维分数和评语。训练完再跑一遍6.2的回归测试你会发现模型对提示词的依赖变小分数也更接近人工。但微调不是终点每次考试后新增的标注数据要继续洗进训练集这套“提示词 规则 微调”的组合才是自动批改真正能走出Demo的阶段。我自己走过一轮“先微调后失败、退回提示词工程”的弯路才明白数据量不足时不要急着上微调先把回归测试和一致性验证做好希望帮到你。本文还有配套的精品资源点击获取