简介一套基于PaddleNLP的web端文本纠错系统完整源码包面向自然语言处理初学者、Web全栈开发者及备战软件设计竞赛的学生。项目以后端PaddleNLPFastAPI、前端VueElement UI实现前后端分离的文本纠错应用支持直接输入文本或上传word文档输出并保存纠错结果同时提供从模型训练到web部署的完整链路便于迁移复用到其他NLP任务。压缩包共103个文件约457KB包含17个Vue组件、39个JavaScript脚本、6个Python后端文件以及svg、scss、json、yml、markdown、txt等配置与说明文档目录结构清晰兼顾开发与生产环境配置。当前已有530人学习下载适合作为完整项目实战参考尤其能帮助读者掌握一套简易通用的模型web端部署方案在后续课程设计或竞赛中快速搭建演示系统。1. 为什么 web 端文本纠错不能只靠正则和词典在做 web 端文本纠错系统时最常见的误区是先堆一个词典。词不达意、同音字、形近字翻来覆去补不完而且没法告诉前端“哪里错了、为什么改”。换成基于 PaddleNLP 的纠错模型之后输入“我吃完饭在楼低下溜达”返回的不只有修正后的句子还有错误偏移量和建议片段。这个标题所指的源码项目就是把 PaddleNLP 的文本纠错能力封装成 web 接口再配一个可交互页面。适合接到该需求的一线开发、想给产品增加智能校对功能的前端以及需要做文本数据清洗的算法工程师。读完至少能搭出一套可运行的服务也能知道参数怎么调、部署时会在哪里翻车。2. 基于 PaddleNLP 的纠错模型选型与 Taskflow 调用2.1 text_correction 在 PaddleNLP 中的定位这里先说结论真正干活的是一个Taskflow它把分词、特征编码、预测和后处理都收在一个入口里。paddlenlp.Taskflow(text_correction)会按任务名自动下载匹配的中文纠错模型不需要自己处理 label 和 tokenizer 的对齐。相比直接用预训练模型接口做序列标注用 Taskflow 至少省掉三类繁琐操作输入规范化为 token id、模型输出到错别字标签的映射、以及把标签还原成可读的修改建议。因此这个 web 源码项目里最核心的依赖实际只有一百多行代码剩下的是接口和页面。2.2 两个可选模型ERNIE-CSC 和 MacBERT4CSCTaskflow 的 text_correction 默认加载的模型一般落在 ERNIE-CSC 系列上比如ernie-csc-base-zh。这个系列对同音字和常见字形混淆有较好覆盖适合新闻、评论、合同等通用文本纠错。如果你在 CPU 上给小型 web 项目提供纠错能力可以换macbert4csc-base-chinese它对长句的还原度不错模型体积也处在可接受范围。选型时建议按照你的部署环境来做不在 GPU 上强行跑大模型用户体验反而更好。部署环境推荐模型CPU 下表现32G 内存无 GPUmacbert4csc-base-chinese句子短时可以勉强在线响应8G 显存 GPUernie-csc-base-zh延迟明显低于 CPU需要处理长文本ernie-csc-base-zh长句效果更好显存占用更高实际上选型只有“短文本在线高吞吐”和“长文本离线质量优先”两种场景web 端在线请求建议优先保证单句延迟。如果你用 Django 搭建 web 项目也可以把同样的选择逻辑放到一个配置类里方便日后切换。2.3 Taskflow 最小调用代码与参数表from paddlenlp import Taskflow # 加载文本纠错任务首次运行会下载模型 corrector Taskflow( text_correction, devicecpu, batch_size1 ) sentences [我吃完饭在楼低下溜达, 这道菜未道不错] results corrector(sentences) for r in results: print(r[source], , r[target]) print(r.get(errors, []))第一行 import 只在启动时执行一次Taskflow(...)会创建模型实例如果当前环境没有缓存权重它会从 PaddleNLP 的模型仓库下载。把batch_size固定为 1 是最稳妥的 web 端起步设置因为在线请求长短不一大 batch 容易把最长请求的推理时间拖到所有请求上。device参数用来切换 CPU 和 GPU不需要修改业务代码。参数默认值一般建议task无固定为 text_correctionmodel按 task 决定显存不足时换 macbert4csc-base-chinesedevicegpu无 GPU 时设成 cpubatch_size1在线接口保持 1 或 2这样做的另一个好处是返回的errors里已经带了修改位置。如果直接用模型 API你需要自己把预测标签和字符索引对应起来这在中英混排文本里非常容易出错。Taskflow 帮你算好 offset前端可以直接消费这一点减少了后续开发量。3. 用 FastAPI 封装 PaddleNLP 纠错接口3.1 源码目录先从“模型实例”与“路由”分开开始接到类似“文本纠错系统”的 web 项目时我习惯先把目录分成 app、static 和外部依赖而不是把模型和路由写进同一个文件。项目结构大致是这样correction-web/ ├── app/ │ ├── __init__.py │ ├── main.py │ ├── corrector.py │ └── static/ │ └── index.html ├── requirements.txt └── README.mdcorrector.py放模型实例的全局缓存main.py只放 FastAPI 实例和路由。这样的结构方便测试也方便以后扩展批量纠错接口。3.2 请求体和响应体用 Pydantic 来做约束from pydantic import BaseModel, Field, validator class CorrectRequest(BaseModel): text: str Field(..., min_length1, max_length512, description待纠错文本) validator(text) def clean_text(cls, v): v v.strip() if not v: raise ValueError(text 不能为空) return v class CorrectResponse(BaseModel): source: str target: str errors: list[dict] latency_ms: floatField(..., max_length512)是为了防止单条文本过长把模型推理拖挂validator把首尾空格去掉也避免空字符串进入模型。errors用list[dict]而不是强类型结构是因为不同版本 Taskflow 返回字段可能略有差异保持字典可以向后兼容。3.3 corrector 用单例避免重复加载模型# app/corrector.py from paddlenlp import Taskflow _corrector None def get_corrector(): global _corrector if _corrector is None: _corrector Taskflow(text_correction, devicecpu) return _corrector模型一次初始化可能消耗几秒到十几秒如果每个请求都新建实例web 端会直接超时。用模块级变量缓存后只有第一次请求需要加载模型后续请求复用同一份权重。这种方式配合 Gunicorn 多进程时每个 worker 会有自己的一份实例显存占用需要按 worker 数估算。3.4 路由和 CORS 配置import time from fastapi import FastAPI, HTTPException from fastapi.middleware.cors import CORSMiddleware from app.corrector import get_corrector app FastAPI(title文本纠错服务) app.add_middleware( CORSMiddleware, allow_origins[http://localhost:8080], allow_methods[POST], allow_headers[*], ) app.post(/api/correct, response_modelCorrectResponse) def correct_text(req: CorrectRequest): t0 time.time() try: result get_corrector()(req.text)[0] return CorrectResponse( sourceresult[source], targetresult[target], errorsresult.get(errors, []), latency_msround((time.time() - t0) * 1000, 2), ) except Exception as exc: raise HTTPException(status_code500, detailstr(exc))先记录t0调用模型后计算耗时并返回给前端。get_corrector()(req.text)返回一个列表这里取第 0 项。异常处理必须做否则 Taskflow 在内存不足、模型文件损坏时抛出的堆栈直接透传给前端既不安全也不易读。3.5 用 uvicorn 启动并验证接口依赖写在requirements.txt中paddlenlp2.4 fastapi0.100 uvicorn0.23启动命令cd correction-web pip install -r requirements.txt uvicorn app.main:app --host 0.0.0.0 --port 8000启动后用 curl 验证curl -X POST http://127.0.0.1:8000/api/correct \ -H Content-Type: application/json \ -d {text: 我吃完饭在楼低下溜达}如果一切正常返回 JSON 会包含source、target、errors和latency_ms。这里--host 0.0.0.0表示监听所有网卡方便本地局域网调试如果只在服务器本机访问可以改成127.0.0.1避免暴露多余端口。提示首次请求触发模型初始化耗时几十秒很正常不是服务卡死。可以先跑一个短文本等第一次响应后再压测。4. 前端 web 页面调用纠错接口4.1 用原生 HTML 实现一个可粘贴文本的 web 网页很多 web 前端开发教程会直接建议用 Vue 或 React但这个源码项目最关心的是把模型能力演示出来。原生 HTML 文件放到 FastAPI 的app/static下既减少构建步骤也方便部署时维护。页面核心只有三个元素多行输入框、触发按钮、结果展示区。如果你习惯用 Django 搭建 web 项目也可以把页面交给 Django 的模板引擎接口地址保持一致即可。4.2 页面代码与 fetch 请求!DOCTYPE html html langzh-CN head meta charsetUTF-8 meta nameviewport contentwidthdevice-width, initial-scale1.0 title基于 PaddleNLP 的中文文本纠错/title style body { max-width: 760px; margin: 32px auto; font-family: system-ui, sans-serif; } textarea { width: 100%; height: 100px; } button { margin-top: 12px; padding: 8px 24px; } #output { margin-top: 16px; } /style /head body h1中文文本纠错/h1 textarea idinput placeholder例如我吃完饭在楼低下溜达/textarea br button idbtn纠错/button div idoutput等待输入/div script const $ (id) document.getElementById(id); function render(result) { let html pstrong修改前/strong${result.source}/p; html pstrong修改后/strong${result.target}/p; html p耗时${result.latency_ms} ms共 ${(result.errors || []).length} 处修改/p; html ul; (result.errors || []).forEach(e { html li第 ${e.offset 1} 位开始长度 ${e.length}建议改为「${e.correction}」/li; }); html /ul; return html; } async function doCorrect() { const textValue $(input).value.trim(); if (!textValue) return; $(btn).disabled true; $(output).innerText 正在纠错...; try { const resp await fetch(/api/correct, { method: POST, headers: { Content-Type: application/json }, body: JSON.stringify({ text: textValue }) }); if (!resp.ok) { const err await resp.json(); $(output).innerText 接口错误 (err.detail || resp.statusText); return; } const data await resp.json(); $(output).innerHTML render(data); } catch (err) { $(output).innerText 网络异常 err.message; } finally { $(btn).disabled false; } } $(btn).addEventListener(click, doCorrect); /script /body /htmlfetch使用相对路径保证页面由 FastAPI 托管时不需要维护域名。按钮禁用状态放在finally里恢复避免请求抛错后按钮一直不可用。渲染错误修改列表时e.offset 1是给用户看的从 1 开始的展示方式模型内部是 0 起始。如果想高亮最终文本需要根据 errors 里的位置在 target 上插入span。字段含义展示建议source用户原始文本直接回显target纠错后的完整文本作为最终结果errors错误位置数组用于高亮和提示latency_ms推理耗时调试时展示4.3 挂载静态页面并注意路由顺序在main.py里加两行from fastapi.staticfiles import StaticFiles app.mount(/, StaticFiles(directoryapp/static, htmlTrue), namestatic)这行必须加在/api/correct路由定义之后否则静态文件托管会覆盖所有路径导致 API 请求被当成文件请求。同理如果你把页面交给 Nginx 或单独的前端服务也要保证/api/*能到达后端服务而不是由前端路由接管。5. 用 Gunicorn 多进程部署并调控显存与超时5.1 为什么在线服务不建议只跑 UvicornUvicorn 开发模式方便但单个进程处理模型推理时遇到长文本会阻塞后面所有请求。Gunicorn 可以启动多个 worker 进程每个 worker 持有自己的 Taskflow 实例相当于把并发能力从 1 提高到 N。代价是每个 worker 都会加载一份模型内存和显存都按倍数增长。因此worker 数不是越大越好而是要看机器资源。5.2 用 Gunicorn 以 ASGI 模式启动 FastAPI安装依赖pip install gunicorn启动命令gunicorn app.main:app \ -k uvicorn.workers.UvicornWorker \ -w 2 \ --bind 0.0.0.0:8000 \ --timeout 120 \ --preload-k指定 ASGI worker 类型FastAPI 是异步框架必须用 UvicornWorker 而不是默认的同步 Gunicorn worker。-w 2表示 2 个 worker 进程如果你只有 8G 内存且使用 CPU 推理建议从 1 个 worker 开始。--timeout 120是因为模型推理在冷启动时可能很慢被 Gunicorn 判定为超时并杀掉120 秒只是一个保守起点。--preload让 master 进程先导入应用代码再 fork 出 worker这样模型加载动作可以只做一次但显存依然每个 worker 各占一份。注意--preload与某些依赖 GPU 的库兼容性不佳如果 fork 后报CUDA error: initialization error去掉--preload让每个 worker 各自加载模型。5.3 显存、batch_size 与并发参数的关系资源情况worker 数batch_size建议8G 内存纯 CPU11优先保证不 OOM16G 内存纯 CPU21并发请求仍然会排队8G 显存 GPU21模型约占用 3-4G32G 显存 GPU42需要配合并发队列这里的batch_size是指 Taskflow 内部推理批大小不是 HTTP 并发数。在线接口中batch_size一旦大于 1一般需要业务侧把多个请求攒成一个列表再送进来否则没有意义。普通 web 端用途下保持 1 最稳延迟曲线也更线性。5.4 三个高频部署问题与排查方法第一个是端口被占用。uvicorn或gunicorn启动时报address already in use用lsof -i:8000找到占用进程再 kill。第二个是 GPU 显存不足。报错文本里有CUDA out of memory。除了降低 worker 数还可以设置 PaddlePaddle 的分配器策略export FLAGS_allocator_strategyauto_growth gunicorn app.main:app -k uvicorn.workers.UvicornWorker -w 1 --bind 0.0.0.0:8000 --timeout 120PaddlePaddle 默认预分配大块显存auto_growth让它按需增长虽然速度稍慢但在多服务共存的 web 项目里更安全。第三个是接口首次请求超时。检查--timeout设置并确认模型没有在请求里重复初始化。也可以在 gunicorn 启动后主动 curl 一次把冷启动时间消耗掉。6. 进阶批量纠错、自定义词典与效果评估6.1 增加批量纠错接口如果 web 端要处理整段文章可以让前端先把文本按句号切分再统一提交。后端增加一个/api/correct_batchclass BatchCorrectRequest(BaseModel): texts: list[str] Field(..., max_length32) app.post(/api/correct_batch) def correct_batch(req: BatchCorrectRequest): results get_corrector()(req.texts) return [{ source: r[source], target: r[target], errors: r.get(errors, []) } for r in results]get_corrector()接受列表后内部会按当前 batch_size 处理。前端拿到结果后按对应顺序渲染可以明显减少 HTTP 往返次数。6.2 用白名单保护专有名词模型在纠错时会把一些专有名词误改。常见做法是在返回结果前对errors中的每个错误位置检查原文片段如果命中自定义白名单就丢弃这条修改并从 target 中还原。WHITELIST {氪金, 布洛芬, Opus} def filter_whitelist(source, target, errors): new_errors [] for e in errors: start e[offset] end start e[length] if source[start:end] in WHITELIST: continue new_errors.append(e) return new_errors这里直接用 source 切片而不是 target因为 target 可能已经发生偏移。errors过滤完以后还需要重新构建 target。简单做法是每次只替换被允许的错误再生成新 target。对白名单较短的情况该方法可以快速见效。6.3 用编辑距离和抽检脚本验证纠错效果不论是自己微调模型还是直接使用 Taskflow上线前都要固定一批验证句子。给一个可用的对比脚本from difflib import SequenceMatcher gold 我吃完饭在楼下溜达 prediction 我吃完饭在楼底下溜达 ratio SequenceMatcher(None, prediction, gold).ratio() print(f相似度: {ratio:.2%})SequenceMatcher.ratio()返回 0 到 1 之间的相似度值越高说明预测结果越接近标准答案。人工抽检时同样用这个指标记录平均分同时单独记录白名单名词被误改的次数。评估脚本建议放在源码包的tests/目录里模型升级后直接跑回归避免引入新的误伤。本文还有配套的精品资源点击获取