简介这份PDF文档面向政务信息化从业者、数据分析人员及希望将大模型落地于公共服务的开发者聚焦民生诉求数据的智能分类难题。文档以DeepSeek模型为核心系统讲解从数据采集、清洗、标注到模型训练、优化、部署及系统集成的完整链路并给出政务热线与社区服务平台等真实案例的效果评估。资源包共1个PDF文件大小约1.9MB内容完整、目录清晰涵盖背景意义、数据预处理、模型训练与优化、部署方案、系统集成测试、应用效果与挑战应对等十个章节图表与文字显示正常。已有109人学习关注。读者可借此掌握DeepSeek在政务场景中的部署思路、接口设计与监控维护方法获得可复用的分类模型实践框架与排错参考适合作为政务智能化项目的技术选型与实施指南。1. 政务热线工单堆成山DeepSeek 做民生诉求分类到底能不能落地某区级 12345 热线中心日均进线工单 3000 到 5000 条人工坐席按「市容环境、物业管理、交通出行、教育医疗、劳动保障」等十几大类逐条打标一条工单平均耗时 40 秒以上高峰期积压到第二天才能分派。这是很多政务数据团队的日常。民生诉求分类模型要解决的就是把这段人工打标变成模型自动打标坐席只做复核。DeepSeek 在这里的价值不是「什么都能聊」而是它能在本地部署、能通过 API 批量调用、能在少量标注样本下把分类准确率拉到可用区间。这篇文章面向的是政务信息化团队里真正要动手部署的人你手上有工单数据有 GPU 服务器或一台能跑推理的机器需要一套从数据清洗到模型上线、从参数调到踩坑排查的完整路径。下面按「先想清楚为什么这么选再动手跑通最后知道哪里会翻车」的顺序展开。2. 民生诉求分类为什么选 DeepSeek 而不是传统文本分类2.1 工单文本的三个特点决定了模型选型政务工单不是标准短文本。第一条特点是口语化严重「楼下那个卖早点的天天五点钟就吵得人睡不着」这种表述里没有任何一个词直接对应「噪音扰民」这个类别。第二条特点是类别边界模糊「小区门口乱停车」既可以归到交通出行也可以归到物业管理人工标注时不同坐席的判断都不一致。第三条特点是长尾类别多除了十几个大类还有大量低频诉求传统分类模型在样本少于 50 条的类别上基本失效。传统方案一般走 TF-IDF 加 XGBoost 二分类模型或者 TextCNN 多分类。这条路在类别清晰、样本均衡的场景下够用但面对上面三个特点特征工程要花大量时间做同义词扩展和规则兜底而且每加一个新类别就要重新标注、重新训练。DeepSeek 这类大模型走的是另一条路它本身具备语义理解能力你给它一段工单文本和类别定义它直接输出类别不需要为每个类别单独准备大量训练样本。这就是选它的核心理由。2.2 本地部署和 API 调用怎么选这是部署实践里第一个要做的决策。两条路各有适用场景不能拍脑袋。对比项本地部署Ollama / vLLMAPI 调用数据不出内网满足需要评估合规单条推理成本电费硬件折旧按 token 计费并发吞吐取决于 GPU 显存取决于配额模型版本控制完全自主跟随服务方运维复杂度需要 GPU 运维能力几乎为零适合场景数据敏感、量大、长期跑验证阶段、量小、无 GPU政务数据大概率涉及个人信息和诉求内容本地部署是更稳妥的选择。常见做法是用 Ollama 做快速验证确认效果后用 vLLM 做生产级部署因为 vLLM 的连续批处理continuous batching在高并发下吞吐明显更好。如果团队没有 GPU 服务器先用 API 跑通流程、验证准确率再申请硬件这个顺序比较务实。2.3 分类任务的 prompt 设计比模型选择更影响结果很多人以为换个更大的模型就能提升准确率实际在分类任务里prompt 的设计对结果的影响往往比模型参数量更大。民生诉求分类的 prompt 要包含四个要素角色设定、类别定义、输出格式约束、边界处理规则。类别定义不能只写类别名要写清楚每个类别的包含范围和排除范围。输出格式必须强制为 JSON否则后续解析会出各种意外。边界处理规则是告诉模型遇到无法判断的工单时输出「待人工复核」而不是硬猜一个类别。# 民生诉求分类的 prompt 模板 # 关键点类别定义带包含/排除说明输出强制 JSON兜底类别明确 CLASSIFY_PROMPT 你是一个政务热线工单分类助手。请根据以下类别定义对工单内容进行分类。 类别定义 - 市容环境包含垃圾清运、占道经营、广告牌破损、公厕管理。不包含小区内部卫生归物业管理。 - 物业管理包含小区内设施维修、物业费纠纷、业委会问题、小区内停车。不包含市政道路停车归交通出行。 - 交通出行包含公交线路、道路破损、交通信号灯、市政道路违停。不包含小区内部道路。 - 教育医疗包含学校管理、培训机构、医院服务、医保报销。 - 劳动保障包含欠薪、社保缴纳、劳动合同纠纷。 - 待人工复核以上类别均不匹配或内容不足以判断时使用。 工单内容 {content} 请只输出一个 JSON 对象格式为{{category: 类别名, confidence: high/medium/low, reason: 一句话理由}} 不要输出任何其他内容。这段 prompt 里{content}是工单文本的占位符实际调用时替换。confidence字段让模型自评置信度后续可以只对 high 的自动分派、medium 和 low 的转人工这样能控制误分类的风险。reason字段在排查误分类时非常有用能看出模型是理解错了类别定义还是文本本身有歧义。3. 从零跑通数据清洗、模型部署、批量分类的完整链路3.1 工单数据清洗的四个必做步骤原始工单数据不能直接喂给模型。常见的问题是包含大量个人信息手机号、身份证号、详细地址包含坐席的内部备注包含重复工单包含超长文本。清洗流程按以下顺序做第一步脱敏。用正则把手机号、身份证号、银行卡号替换为占位符。这一步必须在本地做不能把原始数据发到任何外部服务。import re def desensitize(text: str) - str: # 手机号11位1开头 text re.sub(r1[3-9]\d{9}, [手机号], text) # 身份证18位 text re.sub(r\d{17}[\dXx], [身份证], text) # 银行卡16-19位连续数字 text re.sub(r\d{16,19}, [银行卡], text) # 详细门牌号X栋X单元X室 text re.sub(r\d栋\d单元\d[室号], [地址], text) return text脱敏正则的顺序有讲究先匹配长模式再匹配短模式否则身份证号可能被手机号规则截断。[手机号]这类占位符保留在文本里让模型知道这里原本有信息比直接删除更利于理解语义。第二步去重。同一诉求可能被多次提交用文本相似度去重保留最早的一条。第三步截断。工单正文超过 2000 字的截断到 2000 字因为分类只需要核心诉求超长文本反而引入噪声。第四步过滤。去掉纯表情、纯标点、字数少于 5 个字的无效工单。3.2 用 Ollama 在本地把 DeepSeek 跑起来验证阶段用 Ollama 最省事。安装完成后拉取模型、启动服务、测试一条工单三步就能确认环境是否可用。# 安装 Ollama 后拉取 DeepSeek 模型具体 tag 根据实际可用版本选择 ollama pull deepseek-r1:7b # 启动服务默认监听 11434 端口 ollama serve # 测试一条工单分类 curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 请判断以下工单属于哪个类别小区3号楼电梯坏了三天没人修。类别市容环境/物业管理/交通出行/教育医疗/劳动保障, stream: false }ollama pull的模型 tag 要根据实际可用的版本选择7B 版本在 16GB 显存的机器上能跑但并发能力有限。stream: false表示一次性返回结果批量分类时用这个模式方便解析。如果返回结果里包含思考过程DeepSeek-R1 系列会输出thinking标签需要在解析时去掉。3.3 批量分类脚本并发控制与结果解析单条测试通过后要写批量处理脚本。核心要处理三件事并发控制、超时重试、结果解析。import json import requests from concurrent.futures import ThreadPoolExecutor, as_completed OLLAMA_URL http://localhost:11434/api/generate MODEL deepseek-r1:7b MAX_WORKERS 4 # 根据 GPU 显存调整显存小就调低 def classify_one(content: str, max_retry: int 2) - dict: prompt CLASSIFY_PROMPT.format(contentcontent[:2000]) for attempt in range(max_retry 1): try: resp requests.post(OLLAMA_URL, json{ model: MODEL, prompt: prompt, stream: False, options: {temperature: 0.1} # 分类任务用低温度 }, timeout60) raw resp.json().get(response, ) # 去掉 DeepSeek-R1 的思考标签 raw re.sub(r thinking.*?, , raw, flagsre.DOTALL).strip() # 提取 JSON match re.search(r\{.*\}, raw, re.DOTALL) if match: return json.loads(match.group()) except Exception as e: if attempt max_retry: return {category: 待人工复核, confidence: low, reason: f调用失败: {e}} return {category: 待人工复核, confidence: low, reason: 解析失败} def batch_classify(contents: list) - list: results [None] * len(contents) with ThreadPoolExecutor(max_workersMAX_WORKERS) as executor: future_map {executor.submit(classify_one, c): i for i, c in enumerate(contents)} for future in as_completed(future_map): idx future_map[future] results[idx] future.result() return resultstemperature设为 0.1 是因为分类任务需要稳定输出温度越高模型越容易「发挥」。MAX_WORKERS不能设太大Ollama 默认单模型实例并发太高会导致请求排队甚至 OOM一般设为 GPU 能同时处理的请求数。重试机制必须有本地推理偶尔会因为显存碎片导致单次失败。结果解析用正则提取 JSON 而不是直接json.loads因为模型有时会在 JSON 前后加解释文字。3.4 用 vLLM 替换 Ollama 做生产级部署当工单量上来之后Ollama 的吞吐会成为瓶颈。vLLM 的连续批处理能把吞吐提升数倍适合日均万条以上的场景。# 安装 vLLM pip install vllm # 启动 OpenAI 兼容的 API 服务 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-classify \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000--max-model-len设为 4096 足够覆盖工单文本加 prompt 的长度设太大浪费显存。--gpu-memory-utilization 0.9表示用 90% 显存做 KV cache留 10% 给其他开销。启动后接口地址变成http://localhost:8000/v1/completions请求格式和 OpenAI 兼容批量脚本里把 URL 和请求体格式改一下即可。4. 分类效果调优准确率从 70% 拉到 90% 的五个动作4.1 先建评估集再调优不要凭感觉没有评估集的调优就是盲调。从历史工单里随机抽 500 条人工标注正确类别作为评估集。每次改 prompt 或换模型都在这 500 条上跑一遍算准确率和混淆矩阵。混淆矩阵能告诉你哪些类别之间容易混比如「物业管理」和「市容环境」经常互相误判那就针对这两个类别的边界在 prompt 里加更明确的区分规则。from sklearn.metrics import classification_report # y_true 是人工标注y_pred 是模型输出 print(classification_report(y_true, y_pred, digits3))classification_report会输出每个类别的 precision、recall、f1-score。重点关注 recall 低的类别说明漏判多precision 低的类别说明误判多。根据这两个指标决定是补充类别定义还是增加 few-shot 示例。4.2 few-shot 示例怎么选才有用在 prompt 里加几个标注示例能显著提升准确率但示例的选择有讲究。不要选太简单的要选边界模糊的、容易混淆的。比如「小区门口占道经营」这种既涉及市容又涉及物业的工单给出正确分类和理由模型就能学到边界规则。示例数量 3 到 5 个足够太多会占用上下文长度且边际收益递减。4.3 置信度阈值怎么定模型输出的confidence字段可以用来做分流。统计评估集上不同置信度的准确率high 的准确率可能是 95%medium 是 80%low 是 50%。那么策略就是 high 自动分派medium 和 low 转人工。阈值定在哪里取决于业务能接受的误分类率一般自动分派的比例控制在 60% 到 70% 比较稳妥剩下的转人工复核整体效率仍然比全人工高很多。4.4 长尾类别用规则兜底模型在低频类别上表现差是必然的。对样本量少于 30 条的类别用关键词规则做兜底命中特定关键词的直接归入对应类别不经过模型。规则和模型的结果冲突时以规则为准。这样能保证长尾类别的基本准确率。4.5 定期用新数据做增量评估政务诉求的分布会随季节和政策变化比如冬季供暖投诉集中、开学季教育类工单增多。每月抽一批新工单做评估如果准确率下降超过 5 个百分点就要检查是不是出现了新的诉求类型必要时更新类别定义和 prompt。5. 部署民生诉求分类模型踩过的坑5.1 模型输出 JSON 解析失败现象批量跑的时候大约 3% 到 5% 的请求返回的结果无法解析成 JSON报json.decoder.JSONDecodeError。原因DeepSeek-R1 系列会输出thinking思考过程思考过程里可能包含花括号导致正则提取到错误的 JSON 片段。另外模型偶尔会在 JSON 后面追加解释文字。解决先用re.sub(r thinking.*?, , raw, flagsre.DOTALL)去掉思考标签再用re.search(r\{[^{}]*\}, raw)提取最内层花括号内容。如果还失败退回到「待人工复核」而不是让整个批次中断。5.2 并发调高后 GPU 显存溢出现象MAX_WORKERS从 4 调到 8 之后Ollama 服务报 OOM部分请求超时。原因Ollama 默认只加载一个模型实例并发请求会在服务端排队但每个请求的 KV cache 都占显存并发数超过显存容量就会 OOM。解决MAX_WORKERS不要超过 GPU 能同时容纳的请求数。7B 模型在 16GB 显存上并发 4 是安全值。如果要更高并发换 vLLM 并开启--tensor-parallel-size多卡并行。5.3 脱敏不彻底导致个人信息泄露现象抽查模型输出时发现reason字段里出现了完整的手机号。原因脱敏正则只处理了工单正文没有处理模型生成的reason字段。模型在解释理由时可能复述原文中的信息。解决对模型输出的所有字段做二次脱敏或者在 prompt 里明确要求「不要在 reason 中复述任何数字」。更稳妥的做法是脱敏在数据入库前就完成模型接触到的文本本身就不含个人信息。5.4 类别定义歧义导致系统性误判现象评估集上「物业管理」类别的 recall 只有 60%大量小区内停车纠纷被分到了「交通出行」。原因prompt 里「交通出行」的包含范围写了「停车」没有排除小区内部。模型看到「停车」关键词就归过去了。解决在每个类别的定义里同时写包含和排除。比如「交通出行包含市政道路违停。不包含小区内部道路停车归物业管理」。加了排除规则后该类别 recall 提升到 85% 以上。5.5 模型版本升级后效果回退现象换了一个新版本的 DeepSeek 模型后整体准确率反而下降了 8 个百分点。原因不同版本的模型对同一 prompt 的响应风格不同新版本可能更倾向于输出解释文字而不是纯 JSON或者对类别定义的理解有偏移。解决每次换模型版本都要在评估集上重新跑一遍不要假设新版本一定更好。如果新版本效果差要么回退版本要么针对新版本重新调 prompt。模型版本要记录在配置文件里方便回滚。6. 把分类模型接进工单系统的三个进阶技巧第一个技巧是用异步队列解耦。不要让工单系统直接调模型接口中间加一层消息队列比如 Redis 或 RabbitMQ。工单入库后发一条消息到队列分类服务消费消息、调模型、把结果写回工单表。这样模型服务重启或升级时不会影响工单系统的正常运转积压的工单会在服务恢复后自动处理。第二个技巧是做 A/B 对比验证。新 prompt 或新模型上线前不要直接全量替换。让 10% 的工单走新版本90% 走旧版本对比两组的准确率和人工复核率。跑一周后如果新版本确实更好再逐步扩大比例。这个习惯能避免「上线才发现效果变差」的尴尬。第三个技巧是建一个误分类反馈闭环。坐席在复核时如果发现分类错误点一下「纠正」按钮把正确类别写回数据库。每周把这些纠正数据汇总加入评估集同时挑出典型的误分类案例补充到 prompt 的 few-shot 示例里。这样模型的效果会随着使用时间逐步提升而不是上线即巅峰然后慢慢退化。# 误分类反馈的存储结构示例 feedback { ticket_id: 12345-20240101-001, original_text: 工单正文..., model_category: 交通出行, correct_category: 物业管理, operator_note: 小区内部道路不是市政道路, created_at: 2024-01-01T10:30:00 } # 每周导出 feedback 表人工筛选后加入评估集和 few-shot 池这个反馈表的关键字段是model_category和correct_category的对比以及operator_note里坐席写的纠正理由。理由比类别本身更有价值因为它解释了「为什么分错了」这些理由整理后可以直接变成 prompt 里的边界规则。我自己在这个方向上最大的教训是一开始总想着换更大的模型来提升效果后来发现把类别定义写清楚、把边界规则补全、把 few-shot 示例选对这三件事带来的提升远比换模型大。模型是引擎prompt 是方向盘方向不对引擎再好也到不了目的地。希望帮到你。本文还有配套的精品资源点击获取
简介这份PDF文档面向政务信息化从业者、数据分析人员及希望将大模型落地于公共服务的开发者聚焦民生诉求数据的智能分类难题。文档以DeepSeek模型为核心系统讲解从数据采集、清洗、标注到模型训练、优化、部署及系统集成的完整链路并给出政务热线与社区服务平台等真实案例的效果评估。资源包共1个PDF文件大小约1.9MB内容完整、目录清晰涵盖背景意义、数据预处理、模型训练与优化、部署方案、系统集成测试、应用效果与挑战应对等十个章节图表与文字显示正常。已有109人学习关注。读者可借此掌握DeepSeek在政务场景中的部署思路、接口设计与监控维护方法获得可复用的分类模型实践框架与排错参考适合作为政务智能化项目的技术选型与实施指南。1. 政务热线工单堆成山DeepSeek 做民生诉求分类到底能不能落地某区级 12345 热线中心日均进线工单 3000 到 5000 条人工坐席按「市容环境、物业管理、交通出行、教育医疗、劳动保障」等十几大类逐条打标一条工单平均耗时 40 秒以上高峰期积压到第二天才能分派。这是很多政务数据团队的日常。民生诉求分类模型要解决的就是把这段人工打标变成模型自动打标坐席只做复核。DeepSeek 在这里的价值不是「什么都能聊」而是它能在本地部署、能通过 API 批量调用、能在少量标注样本下把分类准确率拉到可用区间。这篇文章面向的是政务信息化团队里真正要动手部署的人你手上有工单数据有 GPU 服务器或一台能跑推理的机器需要一套从数据清洗到模型上线、从参数调到踩坑排查的完整路径。下面按「先想清楚为什么这么选再动手跑通最后知道哪里会翻车」的顺序展开。2. 民生诉求分类为什么选 DeepSeek 而不是传统文本分类2.1 工单文本的三个特点决定了模型选型政务工单不是标准短文本。第一条特点是口语化严重「楼下那个卖早点的天天五点钟就吵得人睡不着」这种表述里没有任何一个词直接对应「噪音扰民」这个类别。第二条特点是类别边界模糊「小区门口乱停车」既可以归到交通出行也可以归到物业管理人工标注时不同坐席的判断都不一致。第三条特点是长尾类别多除了十几个大类还有大量低频诉求传统分类模型在样本少于 50 条的类别上基本失效。传统方案一般走 TF-IDF 加 XGBoost 二分类模型或者 TextCNN 多分类。这条路在类别清晰、样本均衡的场景下够用但面对上面三个特点特征工程要花大量时间做同义词扩展和规则兜底而且每加一个新类别就要重新标注、重新训练。DeepSeek 这类大模型走的是另一条路它本身具备语义理解能力你给它一段工单文本和类别定义它直接输出类别不需要为每个类别单独准备大量训练样本。这就是选它的核心理由。2.2 本地部署和 API 调用怎么选这是部署实践里第一个要做的决策。两条路各有适用场景不能拍脑袋。对比项本地部署Ollama / vLLMAPI 调用数据不出内网满足需要评估合规单条推理成本电费硬件折旧按 token 计费并发吞吐取决于 GPU 显存取决于配额模型版本控制完全自主跟随服务方运维复杂度需要 GPU 运维能力几乎为零适合场景数据敏感、量大、长期跑验证阶段、量小、无 GPU政务数据大概率涉及个人信息和诉求内容本地部署是更稳妥的选择。常见做法是用 Ollama 做快速验证确认效果后用 vLLM 做生产级部署因为 vLLM 的连续批处理continuous batching在高并发下吞吐明显更好。如果团队没有 GPU 服务器先用 API 跑通流程、验证准确率再申请硬件这个顺序比较务实。2.3 分类任务的 prompt 设计比模型选择更影响结果很多人以为换个更大的模型就能提升准确率实际在分类任务里prompt 的设计对结果的影响往往比模型参数量更大。民生诉求分类的 prompt 要包含四个要素角色设定、类别定义、输出格式约束、边界处理规则。类别定义不能只写类别名要写清楚每个类别的包含范围和排除范围。输出格式必须强制为 JSON否则后续解析会出各种意外。边界处理规则是告诉模型遇到无法判断的工单时输出「待人工复核」而不是硬猜一个类别。# 民生诉求分类的 prompt 模板 # 关键点类别定义带包含/排除说明输出强制 JSON兜底类别明确 CLASSIFY_PROMPT 你是一个政务热线工单分类助手。请根据以下类别定义对工单内容进行分类。 类别定义 - 市容环境包含垃圾清运、占道经营、广告牌破损、公厕管理。不包含小区内部卫生归物业管理。 - 物业管理包含小区内设施维修、物业费纠纷、业委会问题、小区内停车。不包含市政道路停车归交通出行。 - 交通出行包含公交线路、道路破损、交通信号灯、市政道路违停。不包含小区内部道路。 - 教育医疗包含学校管理、培训机构、医院服务、医保报销。 - 劳动保障包含欠薪、社保缴纳、劳动合同纠纷。 - 待人工复核以上类别均不匹配或内容不足以判断时使用。 工单内容 {content} 请只输出一个 JSON 对象格式为{{category: 类别名, confidence: high/medium/low, reason: 一句话理由}} 不要输出任何其他内容。这段 prompt 里{content}是工单文本的占位符实际调用时替换。confidence字段让模型自评置信度后续可以只对 high 的自动分派、medium 和 low 的转人工这样能控制误分类的风险。reason字段在排查误分类时非常有用能看出模型是理解错了类别定义还是文本本身有歧义。3. 从零跑通数据清洗、模型部署、批量分类的完整链路3.1 工单数据清洗的四个必做步骤原始工单数据不能直接喂给模型。常见的问题是包含大量个人信息手机号、身份证号、详细地址包含坐席的内部备注包含重复工单包含超长文本。清洗流程按以下顺序做第一步脱敏。用正则把手机号、身份证号、银行卡号替换为占位符。这一步必须在本地做不能把原始数据发到任何外部服务。import re def desensitize(text: str) - str: # 手机号11位1开头 text re.sub(r1[3-9]\d{9}, [手机号], text) # 身份证18位 text re.sub(r\d{17}[\dXx], [身份证], text) # 银行卡16-19位连续数字 text re.sub(r\d{16,19}, [银行卡], text) # 详细门牌号X栋X单元X室 text re.sub(r\d栋\d单元\d[室号], [地址], text) return text脱敏正则的顺序有讲究先匹配长模式再匹配短模式否则身份证号可能被手机号规则截断。[手机号]这类占位符保留在文本里让模型知道这里原本有信息比直接删除更利于理解语义。第二步去重。同一诉求可能被多次提交用文本相似度去重保留最早的一条。第三步截断。工单正文超过 2000 字的截断到 2000 字因为分类只需要核心诉求超长文本反而引入噪声。第四步过滤。去掉纯表情、纯标点、字数少于 5 个字的无效工单。3.2 用 Ollama 在本地把 DeepSeek 跑起来验证阶段用 Ollama 最省事。安装完成后拉取模型、启动服务、测试一条工单三步就能确认环境是否可用。# 安装 Ollama 后拉取 DeepSeek 模型具体 tag 根据实际可用版本选择 ollama pull deepseek-r1:7b # 启动服务默认监听 11434 端口 ollama serve # 测试一条工单分类 curl http://localhost:11434/api/generate -d { model: deepseek-r1:7b, prompt: 请判断以下工单属于哪个类别小区3号楼电梯坏了三天没人修。类别市容环境/物业管理/交通出行/教育医疗/劳动保障, stream: false }ollama pull的模型 tag 要根据实际可用的版本选择7B 版本在 16GB 显存的机器上能跑但并发能力有限。stream: false表示一次性返回结果批量分类时用这个模式方便解析。如果返回结果里包含思考过程DeepSeek-R1 系列会输出thinking标签需要在解析时去掉。3.3 批量分类脚本并发控制与结果解析单条测试通过后要写批量处理脚本。核心要处理三件事并发控制、超时重试、结果解析。import json import requests from concurrent.futures import ThreadPoolExecutor, as_completed OLLAMA_URL http://localhost:11434/api/generate MODEL deepseek-r1:7b MAX_WORKERS 4 # 根据 GPU 显存调整显存小就调低 def classify_one(content: str, max_retry: int 2) - dict: prompt CLASSIFY_PROMPT.format(contentcontent[:2000]) for attempt in range(max_retry 1): try: resp requests.post(OLLAMA_URL, json{ model: MODEL, prompt: prompt, stream: False, options: {temperature: 0.1} # 分类任务用低温度 }, timeout60) raw resp.json().get(response, ) # 去掉 DeepSeek-R1 的思考标签 raw re.sub(r thinking.*?, , raw, flagsre.DOTALL).strip() # 提取 JSON match re.search(r\{.*\}, raw, re.DOTALL) if match: return json.loads(match.group()) except Exception as e: if attempt max_retry: return {category: 待人工复核, confidence: low, reason: f调用失败: {e}} return {category: 待人工复核, confidence: low, reason: 解析失败} def batch_classify(contents: list) - list: results [None] * len(contents) with ThreadPoolExecutor(max_workersMAX_WORKERS) as executor: future_map {executor.submit(classify_one, c): i for i, c in enumerate(contents)} for future in as_completed(future_map): idx future_map[future] results[idx] future.result() return resultstemperature设为 0.1 是因为分类任务需要稳定输出温度越高模型越容易「发挥」。MAX_WORKERS不能设太大Ollama 默认单模型实例并发太高会导致请求排队甚至 OOM一般设为 GPU 能同时处理的请求数。重试机制必须有本地推理偶尔会因为显存碎片导致单次失败。结果解析用正则提取 JSON 而不是直接json.loads因为模型有时会在 JSON 前后加解释文字。3.4 用 vLLM 替换 Ollama 做生产级部署当工单量上来之后Ollama 的吞吐会成为瓶颈。vLLM 的连续批处理能把吞吐提升数倍适合日均万条以上的场景。# 安装 vLLM pip install vllm # 启动 OpenAI 兼容的 API 服务 python -m vllm.entrypoints.openai.api_server \ --model deepseek-ai/DeepSeek-R1-Distill-Qwen-7B \ --served-model-name deepseek-classify \ --max-model-len 4096 \ --gpu-memory-utilization 0.9 \ --port 8000--max-model-len设为 4096 足够覆盖工单文本加 prompt 的长度设太大浪费显存。--gpu-memory-utilization 0.9表示用 90% 显存做 KV cache留 10% 给其他开销。启动后接口地址变成http://localhost:8000/v1/completions请求格式和 OpenAI 兼容批量脚本里把 URL 和请求体格式改一下即可。4. 分类效果调优准确率从 70% 拉到 90% 的五个动作4.1 先建评估集再调优不要凭感觉没有评估集的调优就是盲调。从历史工单里随机抽 500 条人工标注正确类别作为评估集。每次改 prompt 或换模型都在这 500 条上跑一遍算准确率和混淆矩阵。混淆矩阵能告诉你哪些类别之间容易混比如「物业管理」和「市容环境」经常互相误判那就针对这两个类别的边界在 prompt 里加更明确的区分规则。from sklearn.metrics import classification_report # y_true 是人工标注y_pred 是模型输出 print(classification_report(y_true, y_pred, digits3))classification_report会输出每个类别的 precision、recall、f1-score。重点关注 recall 低的类别说明漏判多precision 低的类别说明误判多。根据这两个指标决定是补充类别定义还是增加 few-shot 示例。4.2 few-shot 示例怎么选才有用在 prompt 里加几个标注示例能显著提升准确率但示例的选择有讲究。不要选太简单的要选边界模糊的、容易混淆的。比如「小区门口占道经营」这种既涉及市容又涉及物业的工单给出正确分类和理由模型就能学到边界规则。示例数量 3 到 5 个足够太多会占用上下文长度且边际收益递减。4.3 置信度阈值怎么定模型输出的confidence字段可以用来做分流。统计评估集上不同置信度的准确率high 的准确率可能是 95%medium 是 80%low 是 50%。那么策略就是 high 自动分派medium 和 low 转人工。阈值定在哪里取决于业务能接受的误分类率一般自动分派的比例控制在 60% 到 70% 比较稳妥剩下的转人工复核整体效率仍然比全人工高很多。4.4 长尾类别用规则兜底模型在低频类别上表现差是必然的。对样本量少于 30 条的类别用关键词规则做兜底命中特定关键词的直接归入对应类别不经过模型。规则和模型的结果冲突时以规则为准。这样能保证长尾类别的基本准确率。4.5 定期用新数据做增量评估政务诉求的分布会随季节和政策变化比如冬季供暖投诉集中、开学季教育类工单增多。每月抽一批新工单做评估如果准确率下降超过 5 个百分点就要检查是不是出现了新的诉求类型必要时更新类别定义和 prompt。5. 部署民生诉求分类模型踩过的坑5.1 模型输出 JSON 解析失败现象批量跑的时候大约 3% 到 5% 的请求返回的结果无法解析成 JSON报json.decoder.JSONDecodeError。原因DeepSeek-R1 系列会输出thinking思考过程思考过程里可能包含花括号导致正则提取到错误的 JSON 片段。另外模型偶尔会在 JSON 后面追加解释文字。解决先用re.sub(r thinking.*?, , raw, flagsre.DOTALL)去掉思考标签再用re.search(r\{[^{}]*\}, raw)提取最内层花括号内容。如果还失败退回到「待人工复核」而不是让整个批次中断。5.2 并发调高后 GPU 显存溢出现象MAX_WORKERS从 4 调到 8 之后Ollama 服务报 OOM部分请求超时。原因Ollama 默认只加载一个模型实例并发请求会在服务端排队但每个请求的 KV cache 都占显存并发数超过显存容量就会 OOM。解决MAX_WORKERS不要超过 GPU 能同时容纳的请求数。7B 模型在 16GB 显存上并发 4 是安全值。如果要更高并发换 vLLM 并开启--tensor-parallel-size多卡并行。5.3 脱敏不彻底导致个人信息泄露现象抽查模型输出时发现reason字段里出现了完整的手机号。原因脱敏正则只处理了工单正文没有处理模型生成的reason字段。模型在解释理由时可能复述原文中的信息。解决对模型输出的所有字段做二次脱敏或者在 prompt 里明确要求「不要在 reason 中复述任何数字」。更稳妥的做法是脱敏在数据入库前就完成模型接触到的文本本身就不含个人信息。5.4 类别定义歧义导致系统性误判现象评估集上「物业管理」类别的 recall 只有 60%大量小区内停车纠纷被分到了「交通出行」。原因prompt 里「交通出行」的包含范围写了「停车」没有排除小区内部。模型看到「停车」关键词就归过去了。解决在每个类别的定义里同时写包含和排除。比如「交通出行包含市政道路违停。不包含小区内部道路停车归物业管理」。加了排除规则后该类别 recall 提升到 85% 以上。5.5 模型版本升级后效果回退现象换了一个新版本的 DeepSeek 模型后整体准确率反而下降了 8 个百分点。原因不同版本的模型对同一 prompt 的响应风格不同新版本可能更倾向于输出解释文字而不是纯 JSON或者对类别定义的理解有偏移。解决每次换模型版本都要在评估集上重新跑一遍不要假设新版本一定更好。如果新版本效果差要么回退版本要么针对新版本重新调 prompt。模型版本要记录在配置文件里方便回滚。6. 把分类模型接进工单系统的三个进阶技巧第一个技巧是用异步队列解耦。不要让工单系统直接调模型接口中间加一层消息队列比如 Redis 或 RabbitMQ。工单入库后发一条消息到队列分类服务消费消息、调模型、把结果写回工单表。这样模型服务重启或升级时不会影响工单系统的正常运转积压的工单会在服务恢复后自动处理。第二个技巧是做 A/B 对比验证。新 prompt 或新模型上线前不要直接全量替换。让 10% 的工单走新版本90% 走旧版本对比两组的准确率和人工复核率。跑一周后如果新版本确实更好再逐步扩大比例。这个习惯能避免「上线才发现效果变差」的尴尬。第三个技巧是建一个误分类反馈闭环。坐席在复核时如果发现分类错误点一下「纠正」按钮把正确类别写回数据库。每周把这些纠正数据汇总加入评估集同时挑出典型的误分类案例补充到 prompt 的 few-shot 示例里。这样模型的效果会随着使用时间逐步提升而不是上线即巅峰然后慢慢退化。# 误分类反馈的存储结构示例 feedback { ticket_id: 12345-20240101-001, original_text: 工单正文..., model_category: 交通出行, correct_category: 物业管理, operator_note: 小区内部道路不是市政道路, created_at: 2024-01-01T10:30:00 } # 每周导出 feedback 表人工筛选后加入评估集和 few-shot 池这个反馈表的关键字段是model_category和correct_category的对比以及operator_note里坐席写的纠正理由。理由比类别本身更有价值因为它解释了「为什么分错了」这些理由整理后可以直接变成 prompt 里的边界规则。我自己在这个方向上最大的教训是一开始总想着换更大的模型来提升效果后来发现把类别定义写清楚、把边界规则补全、把 few-shot 示例选对这三件事带来的提升远比换模型大。模型是引擎prompt 是方向盘方向不对引擎再好也到不了目的地。希望帮到你。本文还有配套的精品资源点击获取
详细教程：TaoToken 统一 Key 配置与 settings.json 骨)
