这是一份近万字的技术复盘,记录了一个全栈开发者从放弃OCR、手撸框选校对,到攻克偏移量难题,再到自研白名单快取、最终压榨GPU性能的全部历程。
---
一、缘起:OCR翻车后,我选择让用户自己框
报纸校对系统的第一版,我想当然地上了OCR。结果版面复杂、字体多变,准确率惨不忍睹。
与其让AI猜错,不如让用户自己告诉它读哪里。
于是系统改成了纯手动框选模式:
· 前端用PDF.js渲染PDF
· 用户拖拽矩形框选择文字区域
· 前端直接提取选区内的文字(利用PDF内嵌文本,非OCR)
· 把文字发给Python后端,调用pycorrector进行校对
这一步让识别准确率直接飙到100%,毕竟PDF里的文字就是排版时的原文,不存在识别误差。
---
二、“一像素都不能错”:偏移量带来的血泪史
文字校对完了,返回了“哪里错、改成啥”,但前端怎么标记高亮?
最专业的做法是后端返回错误词的精确位置(偏移量),前端根据位置精准标红。
听起来简单,实则掉进了深坑:
· pycorrector返回的偏移量经常是0:因为返回的是字典而非元组,解析错了字段
· .NET代理层把偏移量弄丢了:DTO里没定义 start_offset 和 end_offset,反序列化时直接忽略
· 前端大小写不匹配:JSON里的 start_offset 对不上C#的 StartOffset
三层连环坑,排查了整整4个小时。最终解决方案:
1. Python端直接保留pycorrector返回的偏移量,不再清零
2. .NET端不反序列化Python响应,原样转发JSON字符串给前端
3. 前端配置 PropertyNameCaseInsensitive = true
至此,同一个词在文中出现多次时,系统也只会高亮真正错误的那一处。
---
三、偷懒的艺术:让系统学会“跳过”
报纸语言有个特点:大量短句反复出现,比如“弘扬伟大长征精神”“不忘初心、牢记使命”。每次都跑一遍深度学习模型,纯属浪费算力。
我设计了白名单快取机制:
· 把历史正确句子存进SQL Server,按字符数分表(1~40字各一张表)
· 校对时,先把框选的文本拆成短句(按标点分割、去空格)
· 逐句去对应长度的表里查哈希值
· 命中了就直接跳过,只有没见过的句子才发给Python
效果:80%以上的短句都能命中缓存,校对时间从0.5秒直接降到几毫秒。
为了让缓存可控,我加了一个投喂页面,可以把PDF全文粘贴进去,系统自动拆句入库。还做了一个缓存开关,随时可以关闭缓存,所有句子都走深度学习校对。
---
四、AI不够,规则来凑:11类辅助校对规则
深度学习擅长找错别字,但标点、日期、单位这些格式化错误,模型根本不懂。于是我给系统装了“规则大脑”:
· 标点全半角自动检测、括号配对、重复标点报警
· 日期逻辑检查(2月30日?直接标出来)
· 单位标准化(“平米”→“平方米”,“5km”→“5 km”)
· 领导人姓名保护、排序核查、重要讲话引用核对
· 敏感词、禁用词检测
· 引号嵌套检查(“‘xxx’”是对的,“‘xxx”’立即报警)
全部规则只检测不修改文本,确保偏移量不受影响。错误类型都转换成中文显示,编辑一看就懂。
---
五、GPU加速:从0.5秒到0.05秒的压榨
服务器上有NVIDIA显卡,CUDA也装了,但pycorrector就是不用GPU——因为PyTorch装成了CPU版(+cpu)。
解决过程:
1. 彻底卸载CPU版PyTorch
2. 安装CUDA 12.1对应的GPU版本
3. 在代码里手动遍历Corrector的属性,找到所有 torch.nn.Module,调用 .to('cuda') 迁移到GPU
校对速度直接提升5~10倍,CPU终于不再呼呼转了。
---
六、最终架构一览
层 技术栈 职责
前端 Blazor + PDF.js PDF渲染、框选交互、高亮显示
代理 .NET Core 转发请求、词典管理、缓存查询
校对 Python + FastAPI + pycorrector (MacBERT) 深度学习纠错 + 规则检查
缓存 SQL Server (按长度分表) 白名单快取,跳过已知正确句子
部署 Windows + IIS + NSSM 内网服务器,开机自启
---
七、未来规划
· 批量投喂历史PDF,让缓存命中率冲击95%
· 优化词典管理页面,实现一键同步
· 考虑引入Redis二级缓存,进一步提升并发能力
· 增加校对结果的多格式导出(Word/PDF/JSON)
---
从“OCR翻车”到“GPU加速”,这套系统已经迭代了十几个版本。独立开发的魅力就在于,每一个坑都得自己填,但每填完一个坑,系统就强一分。
报纸校对,从手工到AI,这条路终于走通了。