规则引擎解决了80%的消息分类，剩下20%的模糊地带，才是真正折磨运营的地方。
“这个买家是想退款还是只是问问？”——这种判断，规则写不出来，但大模型可以试一试。
我们在前面的文章里建起了规则引擎，把买家消息的自动分类和回复策略搞定了大部分常规场景。但总有一些消息让规则引擎“犯难”——买家说“你们这个衣服我穿上去和图片不太一样啊”，到底是投诉质量要退款，还是只是随口评价一下？规则引擎的关键词匹配可能会把这条消息标为“退款意向”，但实际上买家只是吐槽一句，并没有退款诉求。
这类模棱两可的消息，靠关键词和正则表达式很难准确判断。如果全部扔给人工处理，数量一多，客服人力根本不够。如果硬要自动化处理，很可能用错话术，反而激化矛盾。
大语言模型的出现给了我们一个新选择。从去年开始，我们在合规框架内，谨慎地引入了大模型来辅助消息理解和规则优化。这篇文章就是这项实践的完整复盘——所有内容都围绕合规使用、隐私保护和工程落地，不涉及任何违规操作。
一、传统规则引擎的边界
规则引擎在消息分类上的表现，取决于规则库的完善程度。我们花了大量精力维护关键词列表、正则表达式、优先规则，覆盖了“查询物流”、“申请退款”、“商品咨询”、“投诉举报”等几十个类别。
但有几类消息，规则引擎的准确率始终提不上去。
第一类：情绪化表达。 买家说“你们效率真高，呵呵”，字面上是夸奖，实际可能是嘲讽。规则引擎看到“效率高”就归到“好评”，但这句话需要结合上下文甚至文化语境来理解。
第二类：隐含诉求。 买家说“我在别家买的同款才30块”，这句话可能只是比价，也可能是在砍价，也可能是要退款。规则引擎很难区分意图。
第三类：长文本混合意图。 买家发一大段话，前半段问物流，后半段抱怨质量差，结尾又说“赶紧给我处理”。一条消息里混了三个意图，规则引擎只能匹配到一个。
在这些场景里，规则引擎的准确率只有60%~70%。剩下的误判，要么导致错误回复引发买家不满，要么生成大量人工工单抵消了自动化的效率。
规则是人写的，它的边界就是人的归纳能力的边界。
而语言是活的，总有人在规则覆盖不到的地方说话。
二、大模型用于消息理解的合规边界
引入大模型，第一个问题不是怎么调用API，而是哪些数据能送给模型。
买家消息里包含用户名、联系方式、订单号、地址等敏感信息。把这些直接丢给云端模型服务，违反数据安全和隐私合规。我们必须做到数据脱敏在本地完成，大模型只看到经过处理的文本。
具体做法是：在调用模型之前，本地Python脚本先对消息文本做脱敏处理，把手机号、订单号、地址、姓名替换为占位符。
import re
def mask_sensitive_info(text: str) -> str:
# 替换手机号
text = re.sub(r'1[3-9]\d{9}', '[PHONE]', text)
# 替换订单号（示例格式）
text = re.sub(r'PO\d{10,}', '[ORDER_ID]', text)
# 替换地址中的门牌号等信息
text = re.sub(r'\d{1,5}号', '[ADDR_NUM]', text)
return text
模型收到的输入是脱敏后的文本，返回的结果也是基于脱敏文本的。本地再将结果映射回原始消息上下文。整个过程里，敏感信息没有离开我们的服务器。
同时，我们自建了模型推理服务，部署在公司内网GPU服务器上，使用开源模型，不经过公网API。这让数据主权完全可控，也避免了外部API调用次数限制和费用问题。
三、模型选型与服务化部署
在模型选择上，我们没有追求最大最前沿。店群消息分类这个任务，不需要1750亿参数，一个小而快的模型足够了。
我们测试了几个开源7B~13B参数的模型，在本地标注的2000条消息样本上评估，最终选了一个分类准确率高、推理延迟在200毫秒以内的模型。部署方式是用FastAPI包装成HTTP服务，运行在内网，供Python插件调用。
from fastapi import FastAPI
from pydantic import BaseModel
import torch
app = FastAPI()
class MessageRequest(BaseModel):
text: str
context: dict = {}
@app.post("/classify")
def classify_message(req: MessageRequest):
# 脱敏已在调用方完成
prompt = build_prompt(req.text, req.context)
inputs = tokenizer(prompt, return_tensors="pt")
outputs = model.generate(**inputs, max_new_tokens=64)
result = tokenizer.decode(outputs[0], skip_special_tokens=True)
return {"intent": parse_intent(result), "sentiment": parse_sentiment(result)}
Prompt设计很关键。我们不要求模型输出长篇分析，只需要返回结构化的分类结果，降低推理耗时和不确定性。
你是一个电商客服消息分类助手。请对以下买家消息分类，输出JSON格式，包含：
- intent: 主要意图（logistics/refund/complaint/inquiry/praise/chitchat）
- sentiment: 情绪（positive/neutral/negative）
- urgency: 紧急程度（low/medium/high）
买家消息：{脱敏后的消息文本}
只返回JSON，不要其他内容。
四、大模型与规则引擎的协同
大模型不是替代规则引擎，而是和它互补。我们设计了一个两级分类架构。
第一级：规则引擎快速分流。 规则引擎先对消息做初筛。高置信度匹配（关键词明确、模式清晰）的消息直接由规则引擎处理，不经过模型。这部分占总量的60%~70%，响应时间不到1毫秒。
第二级：大模型兜底分类。 规则引擎置信度低于阈值的消息，转给大模型做深度理解。模型返回分类结果后，结合店铺上下文（买家历史、订单状态）做最终决策。
def classify_message_hybrid(message: str, context: dict) -> dict:
# 第一级：规则引擎
rule_result = rule_engine.evaluate("message_intent", {"message": message})
if rule_result and rule_result.get("confidence", 0) > 0.85:
return rule_result
# 第二级：大模型
masked = mask_sensitive_info(message)
model_result = call_model_service(masked, context)
# 融合上下文
final_intent = merge_with_context(model_result, context)
return final_intent
这套架构让大模型只处理真正需要深度理解的“硬骨头”，控制了推理成本和延迟。高优先级消息（P0实时回复）仍然能获得毫秒级的快速响应，低优先级或模糊消息才走模型。
五、模型输出的人机协同
大模型的分类结果不是100%可靠的。对于置信度较低的预测，我们仍然交给人工判断。
模型返回结果时会带一个置信度分数。低于0.7的分类结果，流程不会直接使用，而是生成工单推送给人工客服。人工确认或修正后，分类结果被记录，用于后续反馈。
if model_result["confidence"] < 0.7:
create_human_review_ticket(message, model_result)
use_fallback_template(message)
else:
apply_reply_strategy(model_result["intent"])
这个机制确保了即使模型犯错，也不会直接导致错误回复。在人工介入之前，流程会用最保守的通用话术过渡（“您的消息已收到，客服稍后回复您”），避免不当回复。
六、模型反馈与规则自进化
这套体系里最有价值的一环，是人工修正的结果会反哺规则引擎。
当人工客服把一条被模型误判为“退款”的消息修正为“物流查询”时，这个修正记录被存入反馈库。累积到一定量后，系统会自动分析：这些被修正的样本里，有没有频繁出现的模式是规则引擎没有覆盖到的？
如果有，系统会自动生成一条规则建议——比如“当消息包含‘物流’和‘怎么还没到’但订单状态为‘运输中’时，优先归类为物流查询”——推送给规则维护者审核。审核通过后，这条规则被加入规则引擎。
def suggest_new_rules(feedback_records):
patterns = extract_common_patterns(feedback_records)
suggestions = []
for pattern in patterns:
if not rule_engine.has_rule_for(pattern):
suggestion = {
"conditions": pattern["conditions"],
"action": pattern["correct_intent"],
"evidence_count": pattern["count"],
"source": "auto_generated_from_feedback"
}
suggestions.append(suggestion)
return suggestions
这就形成了一个闭环：规则引擎处理不了的消息，由模型辅助理解。模型不确定的消息，由人工确认。人工修正的结果，反过来优化规则引擎。规则引擎变强了，模型需要处理的模糊消息就变少了，整体效率持续提升。
运行半年后，规则引擎的准确率从最初的78%上升到了91%，模型调用量下降了约30%——不是因为模型变差了，而是规则引擎不断在“吃掉”原来需要模型处理的case。
好的系统不是靠某一个智能组件撑着，而是让规则、模型和人形成一个互补的进化飞轮。
七、延迟与并发优化
大模型推理的延迟是实时消息处理场景最大的挑战。即使部署在内网，单次推理200毫秒，高峰期并发几十条消息同时到达，推理服务的响应时间可能涨到秒级。
我们做了几项优化。
批量推理：不是一条消息调一次模型，而是把短时间窗口内（200毫秒）到达的多条消息打包成一个batch，一次推理处理多请求。这充分利用了GPU的并行计算能力。
优先级队列：P0实时消息优先推理，P1/P2消息排队等待。即使在高峰期，需要即时回复的消息也不会被批量查询拖慢。
模型缓存：对于语义高度相似的重复消息（如“在吗？”“你好？”“客服在吗？”），对输入文本做哈希缓存，命中缓存的直接返回已有结果，不重复推理。
这三项优化把高峰期推理延迟的P99从3.2秒压到了0.8秒。
八、合规与隐私保护红线
大模型在自动化中的应用，有几条红线我们坚决不碰。
不把买家个人信息送到模型。 脱敏是硬性要求，代码里强制校验，测试用例里有专门的敏感信息泄漏测试。
不用模型生成面向买家的自由文本。 模型只输出结构化分类结果和话术模板ID，实际的回复内容由模板渲染引擎根据模板ID生成，模板内容是人工审核过的。模型不直接“写”买家能看到的文字，避免生成不当内容。
模型推理日志不保留原始消息。 推理服务的日志只记录脱敏后的文本哈希值和分类结果，不落盘原始消息。
人工复核的工单里，展示给客服的也是脱敏消息。 只有确认需要查看原始消息时，才有权限脱敏查看，且操作留痕。
九、效果与反思
引入大模型辅助消息理解之后，我们统计了几组数据：
- 消息自动分类的准确率从78%提升到93%
- 需要人工介入的模糊消息占比从22%降到7%
- 因错误分类导致的不良回复投诉下降了约60%
- 规则引擎每月自动新增2~5条优化规则，维护成本下降
但也有一些我们没有预料到的代价。模型服务的GPU资源占用让内网服务器的电费和散热压力增加了。模型偶尔的“幻觉”——把一条普通消息过度解读为紧急投诉——需要在工程上加多道保险。推理延迟的抖动在某些时候仍然会影响回复时效。
最大的收获是验证了一个思路：自动化的智能化升级，不一定要追求“全自动”。 用模型辅助人，用人的反馈优化规则，用规则替代模型处理常规问题，这个正向循环比一步到位的“AI替代人工”更务实、更安全、也更可持续。
智能不是一蹴而就的。
它是在规则、模型和人的三角协作里，一天一天磨出来的。
作者：林焱
一个谨慎地在自动化系统里引入AI、但始终把合规和安全放在首位的工程师