接手这个项目的时候业务方刚把一坨从旧系统里导出的脏数据拍到我桌上——OCR扫描件、手工录入、输入法选错字混在一起错得五花八门但要求只有一个在下游系统跑规则之前把这批文本里该修的错都修掉别把原来写的对的地方动坏。当时最省事的方案确实是直接调大模型API但算了一笔账之后发现这条路走不通一是文本量级大按字符计费的费用一个月顶得上半台GPU服务器二是这些文本里带业务字段和内部编号甲方明确说不能出内网三是那些通用大模型太聪明了经常顺手把句子润色一遍第3季度给改成第三季度客户觉得这不算错但下游规则引擎恰恰依赖这种格式。于是就有了这个实践项目用一个只有0.8B参数的轻量模型内部代号qwen3.5 0.8B就是一个小底座模型专门做文本纠正任务。折腾了两周之后效果超出预期纠错准确率稳定在95%以上在CPU上跑批量处理也毫无压力。这篇博文把整个过程拆开写清楚从数据构造、微调配置、推理部署到效果评估和踩坑记录给准备在低资源环境下做文本纠错的同学一个可以照着抄的作业。1. 项目背景与需求拆解1.1 纠正任务到底在解决什么问题纠正这个词边界其实很宽不同人理解完全不一样。业务方说的纠正很多时候并不是要求模型像语文老师那样重写句子而是要把文本中的错别字、OCR识别错字、标点误用、数字格式不统一、术语不统一这类硬伤修掉。本质上这是一种局部修复不是重新创作。我接手的数据里最常见的几类问题包括扫描件经过OCR之后形近字认错巳和已、晴和睛、同音字选错账和帐、字符断裂导致的多余空格还有录入员手滑打出的重复字和漏字。这类错误有一个共同特点只在局部几个字符范围内发生不涉及全局语义重构。这就是小模型能干的根本原因。纠正任务需要的不是长篇大论的世界知识和规划能力而是对上下文局部的敏感度以及对什么该改什么不该改的判断力。0.8B参数量的模型训练数据喂够了这些能力完全够用。生活里比较好理解的一个类比是大模型像一位什么书都看过的专业编辑你给他一篇文章他恨不得帮你把所有句子都理顺而小模型像一个严格的校对员只盯着错别字和格式其他一律不动。做纠正任务你恰恰需要后者这种克制。1.2 技术选型背后的三笔账选这个规模的模型不是拍脑袋而是算了三笔账之后得出的结论。第一笔是成本账。0.8B模型在单张消费级显卡上做LoRA微调绰绰有余推理阶段跑到CPU上也能跑出不错的吞吐。相比按月付费的大模型API服务自部署的模型跑满十万级文本边际成本几乎可以忽略。对于批量处理场景这是实打实的节省。第二笔是数据安全账。业务方很多文本涉及内部编号、人员信息明文送到外部API是不合规的。自部署小模型最大的优势就是数据不出内网所有的数据清洗、微调、推理都在自己的环境里完成合规上没有任何问题。第三笔是效果可控账。大模型做纠正任务有一个让人头疼的毛病过度改写。训练它的数据里包含了太多润色信号它天然倾向于把句子改得更通顺但这对纠正任务来说就是灾难。小模型用专门构造的纠错数据微调之后行为边界清晰得多改动的幅度和方向都更容易把控。1.3 项目目标拆解把纠正定义清楚项目开工前我花了整整一天和业务方对齐纠正的定义这是整个项目里我认为最值得做的一件事。口头说的把错的改对没法工程化落地必须拆成可执行的标准。最终我们约定了一个三级目标分类必须改错别字、OCR识别错误、明显语序颠倒、标点符号错误、数字格式错误可以改中英文之间空格不统一、全半角混用、行业术语内部不一但只能改成指定范本严禁改人名、地名、机构名、编号、日期、金额数字、引用内容。评估口径也按改动点来算而不是按整句算对不对。一个句子如果只有一处错字模型改对了这一处整句准确率就是100%如果模型顺手把第3季度改成第三季度就算句子读起来更顺也照样记为一次误改。这个口径非常重要它直接影响后续数据构造和评测方式。2. 数据工程纠错样本是成败的关键2.1 先把错误类型学做透做数据之前我先对抽样数据里的错误做了摸底发现表面看起来五花八门的错误归纳下来主要就六类错误类型典型表现示例同音/形近字选字错误、OCR认错字账目写成帐目柿子写成杮子多字/少字录入重复、OCR漏识别的的、需要要完成任务漏成完成任务的上一字语序颠倒词序错误较罕见正确无误写成误正确无标点与符号全半角混用、英文逗号中文句号混合你好world。混杂中英混排与空格缺空格、多空格使用API调用写成使用API调用术语不一致同一实体多种写法B超与B 超、彩超与彩超混用每一类错误标注规范里都要写清楚怎么改、改成什么样、什么情况下不改。比如形近字巳和已要结合上下文判断不能见已就改术语不一致则必须用项目产出的专用词表做标准答案不允许模型自由发挥。2.2 训练数据怎么造质量和多样性是关键一开始我天真地以为可以纯靠人工标注但标注了500条之后就放弃了——速度慢且不说不同标注员的判断标准经常打架数据质量根本没法保证。结合实践我最终采用的策略是规则构造为主 真实OCR噪声为辅 质量清洗兜底。规则构造的核心是建立混淆集。拼音混淆集覆盖常见同音字形近混淆集覆盖OCR常见的认错字对再按一定概率通常控制在10%到25%之间在一句话的随机位置替换、插入或删除字符。概率不能太高否则造出来的错误样本全是坏句模型学不到真实场景里那种只有一个地方错的形态。真实OCR噪声这招是偶然试出来的但效果出奇好。我把一批干净文本分别用不同字体、不同分辨率渲染成图片再降质加噪最后用OCR系统识别一遍得到的文本天然带有真实世界的识别错误分布和线上几乎一致。这类样本虽然数量占比不大但对提升模型泛化能力帮助极大我强烈建议有OCR场景的团队都试试。数据造完之后还有一个关键步骤——用一支质量较高的大模型对样本打分把置信度低的伪样本过滤掉。不要求它逐条改对只是让它判断这句的错是否贴切。另外还从全量数据里抽了800条做人工校验单独存为黄金校验集不出现在训练数据里。这个黄金集是后续所有评估的基准线。2.3 训练/验证划分与数据配比数据划分这里有一个很容易踩的坑如果按句子级别随机切分同一份文档里的句子会同时出现在训练集和验证集导致验证指标虚高。我改成按文档级别切分保证验证集里出现的文档在训练集里完全没出现过评估出的指标才真实反映模型的泛化能力。数据配比上也做了刻意设计。六类错误按线上实际分布比例来调配而不是平均分配。因为如果平均分配模型会对低频但重要的错误类型过度敏感反而挤占了高频错误的学习空间。训练过程中还会做难例挖掘——把模型当前做错的样本加进下一轮训练数据里相当于让模型反复刷错题这个技巧对提升纠错精度效果非常明显。3. 微调配置与训练细节3.1 基座模型与微调方式选择基座选的就是0.8B参数量的qwen3.5变体内部实验代号微调方式用LoRA不碰全参数微调。原因很简单维护成本低、显存占用小、可以同时挂多个任务适配器。业务后续还可能新增其他NLP任务每个任务训练一个独立的LoRA adapter切换零成本互不干扰。LoRA的关键参数我是这么设的lora_rank: 16 lora_alpha: 32 lora_dropout: 0.05 target_modules: - q_proj - k_proj - v_proj - o_proj - gate_proj - up_proj - down_projrank取16而不是更大的值是因为纠错任务本质比较简单不需要太高的表达容量alpha取rank的两倍是经验值效果比一比一更好收敛。目标模块里把MLP的投影层也加上了实验下来比只改注意力层稳定一些。3.2 指令模板与训练数据格式在指令模板这个问题上我踩过不少坑。最初试过很花哨的提示词详细描述你是一个文字编辑请纠正以下文本中的错别字、标点符号之类的长篇模板结果训练出来的模型表现反而不稳定经常会输出解释性文字。最终定下来的是一个极简风格的模板|im_start|system 你只负责纠正文本中的错别字、标点、格式和术语错误保持其他内容不变。仅输出纠正后的文本。 |im_end| |im_start|user {原始句子} |im_end| |im_start|assistant {纠正后句子} |im_end|指令越短模型越容易理解我只是一个校对工具不是内容创作者。训练数据构建时严格遵循这个格式推理阶段也使用完全相同的模板和分隔符。模板一致性这一点很多人会忽略但它的影响是实打实的——训练用A模板推理用B模板效果直接降一个档次。3.3 训练超参与过程观察训练超参我跑了几组对比实验后定下来这样一套learning_rate: 1.5e-4 batch_size: 8 gradient_accumulation_steps: 4 warmup_ratio: 0.03 lr_scheduler: cosine num_epochs: 3 max_length: 256max_length设256是经过权衡的数据里绝大多数句子不超过一百字256足够覆盖同时避免把太长的半截句子喂进模型导致乱改。学习率选1.5e-4而不是默认的1e-4是因为LoRA本身的参数空间小稍微大一点的学习率收敛更快实测也不会发散。训练过程中有一个很重要的观察习惯不要只看loss曲线。loss从0.8降到0.4的时候看起来一切正常但验证集上的改动点准确率可能已经开始掉点了。这是因为模型在过拟合训练数据里的噪声形态。我在训练每个epoch结束时会计算一次验证集指标以这个指标为准决定是否提前停止而不是机械地跑满所有epoch。4. 推理部署与性能优化4.1 部署框架选型部署方案需要根据并发量和硬件条件来定。我这边做了一个简单的对比环境推荐方案内存/显存说明单机CPU批量处理llama.cpp q4_k_m量化约1GB单条文本延迟几百毫秒适合离线清洗单卡GPU 中等并发Transformers直接推理约2GB显存简单直接改代码最少多卡GPU / 高并发vLLM2GB吞吐提升数倍支持动态批处理边缘设备ONNX Runtime 静态量化约800MB适合嵌入式或容器限制严格的场景我这边线下批量任务多、并发要求不高拿了llama.cpp量化后的模型跑CPU跑了几天很稳。后来业务方要求上线实时接口又加了一个vLLM的部署实例。4.2 推理参数设置推理阶段有几个参数必须严格控制。首先要明确一点纠错任务不是创作不需要多样性和随机性解码方式直接选greedy最多加一点可控的温度。实际用的参数temperature: 0.1 top_p: 0.5 max_new_tokens: 128 repeat_penalty: 1.05max_new_tokens设128是动态的——在输入提示词里要求模型只输出纠正后的文本输入多长输出通常就多长128足够覆盖绝大多数场景同时防止模型开启话痨模式。repeat_penalty设1.05是为了避免模型出现重复字符的异常输出纠错任务里这个现象偶尔会出现尤其在纯数字或纯标点输入时。还有一个省算力的小技巧在调用模型之前先用几条简单规则判断句子是不是明显没有错误——比如不含任何常见混淆字、标点正常、长度正常。判断无错的句子直接跳过模型调用结果原样返回。这个前置过滤器帮我省掉了大约六成的模型调用量对批量处理场景提升非常明显。4.3 吞吐量优化的两个思路对于批量处理最常见的问题不是模型太慢而是padding浪费太多算力。句子长度参差不齐时给一批样本统一pad到最大长度短句就被白白拖慢了。我用的是分桶策略按长度统计分布分成几个长度区间每个区间一个batch分别推理实测吞吐提升了30%到40%。第二个思路是prompt缓存。system提示和指令部分在每次调用时都一样可以预先做完tokenize并缓存推理时只处理新增的文本片段。在Transformers框架里做这个优化就是多手配置tokenizer的问题但收益很客观。CPU部署时量化等级的选择也值得一提。纠错任务本质上是把输入字符重写到输出序列不涉及大量概率分布的精细采样量化后的影响非常小。我实测q4_k_m量化和fp16原始模型在黄金校验集上的指标几乎一致差异在误差范围之内。放心量化能省内存就省。5. 效果评测与错误画像5.1 测评指标怎么选纠正任务的评测指标直接用文本生成任务的BLEU、ROUGE都有问题。BLEU主要是给机器翻译设计的对只改几个字符的纠正任务过于严苛——哪怕只改错一个字整句的n-gram匹配度都可能被大幅拉低。这类任务的更合理评测方式是改动点维度。我实际用了三个指标缺一不可改动点准确率模型产生的所有改动中正确改动的比例改动点召回率标注中所有应改之处模型正确找到并修改的比例黄金集通过率在人工校验的那800条上整句完全正确的比例。三者的意义不同。准确率低说明模型在乱改召回率低说明模型漏改黄金集通过率则是综合水平的面试题。上线之前我给自己定的标准是改动点准确率不低于95%召回率不低于90%黄金集通过率不低于93%。达不到这个线就继续调数据不出包。5.2 错误画像与反哺数据模型第一版跑出来各项指标不差但人工看图时发现一个很典型的问题对可改可不改的格式它经常倾向去改好。比如API接口中间的空格时有时无模型会主动补空格B超室会改成B 超室。从指标上看这不是错——补空格确实是格式正确但业务方对术语格式有一套固定规范这就算误改。我把这类错误单独拉出来分析之后做了两件事一是把术语规范做成一张受保护词表规则层在不命中词表前禁止任何修改二是给训练数据里增加格式本可改但选择不改的负样本让模型学到宁可漏改不要瞎改的边界。错误画像还有一个重要价值它告诉我哪一类错误是模型学不会的。比如形近字错误模型总是漏改而且不是数据量的问题。后来分析的结论是这类错误对上下文依赖极大0.8B模型单靠Transformer注意力确实吃力。解决方案是把这类错误单独拆出来配合一个基于混淆集的规则过滤器做前置匹配命中高概率疑似错的直接改掉模型只负责上下文判断。规则模型的组合拳比单用模型效果好得多。5.3 封板标准与上线检查清单项目上线前我给自己列了一份封板检查清单每一条都过完才有底气对业务方说可以上检查项标准通过情况黄金校验集准确率不低于93%94.7%误改率人工抽检不高于3%2.1%受保护词表零误伤0条0条长文本200字抽查无结构破坏通过批量处理耗时每千条不超过10分钟通过这个封板标准可以说相当保守但对文本纠错这类不影响人读的任务保守不是坏事。宁可让少量错误漏过去也不能让大量对的内容被改错。6. 常见问题与排查实录6.1 高频问题速查表整个项目踩过的坑我整理成一份速查表按现象-原因-解法来记录这个表格后来也成了团队新人培训的教材。现象原因解法模型把本来对的句子改错训练数据中标签噪声过高清洗数据增加正确样本降低学习率输出丢标点尤其是句尾标点标注时全半角混用模型学混了统一标点标注规范训练数据加入全角标点样本输出比输入长很多出现扩写解码参数控制不足严格设max_new_tokens确认训练数据无扩写样本专有名词被改数据里缺少专名保护样本加受保护词表规则层先拦截长句后半段不动长度截断导致上下文丢失提升max_length或先分句再纠正CPU上吞时严重单条逐条推理分桶batch推理配合量化6.2 一个典型的“误改”排查过程有一次业务方反馈大批文本里的第3季度被模型改成了第三季度。从语言角度这两种写法都没有错但客户下游的报表工具只认前一种格式这就成了事故。排查过程分三步。第一步我在黄金校验集里翻找类似案例发现有大约7%的中文数字和阿拉伯数字混用场景会被模型统一成中文数字这是训练数据本身的偏见。第二步检查训练数据的来源发现构造数据时为了造格式统一样本大量把数字统一成了中文数字写法模型学到的规则是数字格式不统一就改成中文数字。第三步修复方式是在指令模板里加了一句保持原有数字和字母的书写格式并在训练数据里增加了大量保持原样的数字格式样本问题解决。这个案例让我意识到纠正模型学到的不只是错的改对还会统计性地学到非标准格式要向标准格式看齐。而这恰恰是纠错任务最危险的隐性行为。6.3 非共识实操心得最后分享几条我在这个项目里形成的、不一定写在教科书里的经验。第一做纠错任务错误样本和正确样本必须一起进训练数据。我第一版只喂了错误样本模型学到的全是见到类似格式就想改误改率居高不下。加入一半比例的完全正确句子之后误改率几乎下降了一半。第二单独训练一个是否有错的分类器比直接让纠正模型判断要不要改更可靠。一个小分类器判断句子是否需要纠正准确率很容易做到98%以上而且计算成本比生成模型低几个量级。它先过滤一遍真正需要纠正的句子才调用生成模型既省算力又让纠正模型专注在自己的强项上。第三规则层永远放在模型前面做兜底而不是放在后面做修补。预先拦截掉受保护词、专有名词、固定格式再用模型处理剩余的错误这个顺序一旦反了模型容易在规则层已经处理的文本上反复折腾。实践下来这个顺序能让最终准确率再提升1到2个百分点。在已经稳定运行的两周里这个0.8B的小模型把批量纠正任务处理得干净利落。后面如果要扩展我计划在同样的底座上再挂几个针对不同行业的adapter数据不变、代码不变换一个adapter就能服务新客户这就是当初选LoRA而不是全参微调给我留的灵活余地。项目做完回头看最值钱的不是那套微调代码而是那段把纠正从模糊要求拆成可量化标准的定义过程建议任何做这类任务的同学都把时间花在这个上面。
