背景与痛点传统客服系统的局限性智能客服的市场需求去年帮一家做 SaaS 的小公司做客服升级老系统用的是“工单人工排队”模式用户提交问题后先进入 MySQL 工单表客服在后台按时间顺序领取。高峰期并发一高客服界面直接卡死平均响应 8 分钟丢单率 18%。老板一句“能不能让机器人先挡 80% 重复问题”直接催生了这套基于 Django 的智能客服项目。中小团队最怕“一上来就堆大机器”所以目标很明确单机 QPS 先扛 200后续可横向扩容常见 FAQ 机器人秒回复杂问题无缝转人工一周上线代码可交接别让后人骂街技术选型Django vs Flask 性能对比NLP 引擎选择Django vs Flask基准环境4C8G 容器WSGIGunicorn Gevent同配 Redis 缓存一条 500 字节 JSON。空路由 Hello worldDjango 2.2 2 700 RPSFlask 2.0 3 100 RPS差距 12%可忽略。带 ORM 查询auth_user 表 10 万行索引命中Django 1 950 RPSFlask-SQLAlchemy 1 250 RPS。Django ORM 连接池与原生 QuerySet 优化反而更快。后台管理、权限、ORM 自带省掉“自己拼蓝图”时间对一周上线极友好。结论选 Django。NLP 引擎Rasa本地训练数据隐私好CPU 推理 50 ms但训练脚本重需要 GPU 机器。Dialogflow接入快中文支持尚可调用延迟 250 ms按量计费小团队怕账单失控。最终折中FAQ 用 Rasa 预训练模型兜底“转人工”走 Django 逻辑既省钱又可控。核心实现1. Django 模型设计对话记录、知识库# models.py from django.db import models from django.contrib.auth import get_user_model User get_user_model() class KBItem(models.Model): 知识库一问一答支持相似问法 question models.CharField(max_length256, db_indexTrue) answer models.TextField() category models.CharField(max_length64, db_indexTrue) created_at models.DateTimeField(auto_now_addTrue) class Meta: indexes [ models.Index(fields[category, -created_at]), ] class Dialogue(models.Model): 对话流水 CHANNELS ((web, Web), (wechat, WeChat), (app, APP)) user models.ForeignKey(User, on_deletemodels.CASCADE) channel models.CharField(max_length16, choicesCHANNELS) user_msg models.TextField() bot_answer models.TextField() intent models.CharField(max_length64, blankTrue, db_indexTrue) created_at models.DateTimeField(auto_now_addTrue) class Meta: indexes [models.Index((user, -created_at))] # 查用户历史2. 异步任务处理Celery RedisDjango 同步视图做意图识别会阻塞 50~250 ms高峰期并发一上来直接爆炸。用 Celery 把 NLP 推理拆出去视图立即返回“处理中”状态前端轮询即可。# tasks.py from celery import shared_task from rasa.nlu.model import Interpreter import os interpreter Interpreter.load(os.getenv(RASA_MODEL_PATH)) # 单例加载避免重复 IO shared_task def nlu_predict(text: str, dialogue_id: int): 异步意图识别 置信度过滤 result interpreter.parse(text) intent, conf result[intent][name], result[intent][confidence] if conf 0.5: intent fallback # 回写数据库 from .models import Dialogue Dialogue.objects.filter(pkdialogue_id).update(intentintent) return intent时间复杂度O(L) L文本长度空间复杂度O(V) V词表大小可接受。3. REST API 设计DRF# views.py from rest_framework import viewsets, status from rest_framework.response import Response from .models import Dialogue, KBItem from .serializers import DialogueSerializer, KBSerializer from .tasks import nlu_predict class ChatViewSet(viewsets.ViewSet): def create(self, request): user_msg request.data.get(msg) channel request.data.get(channel, web) if not user_msg: return Response({error: msg required}, statusstatus.HTTP_400_BAD_REQUEST) # 1. 先落库 dlg Dialogue.objects.create( userrequest.user, channelchannel, user_msguser_msg, bot_answer, intent, ) # 2. 触发异步预测 nlu_predict.delay(user_msg, dialogue.id) # 3. 立即返 token前端拿 token 轮询 /api/chat/id/result/ return Response({dialogue_id: dialogue.id}, statusstatus.HTTP_201_CREATED)代码示例意图识别、对话状态管理轮询接口def retrieve(self, request, pkNone): dlg get_object_or_404(Dialogue, pkpk, userrequest.user) if dlg.intent : return Response({status: processing}) if dlg.intent fallback: answer 转人工客服中请稍候... else: # 精准匹配知识库 kb KBItem.objects.filter(categorydlg.intent).first() answer kb.answer if kb else 抱歉暂无答案 return Response({answer: answer, intent: dlg.intent})状态机极简processing → fallback/hit → done前端根据 status 渲染不同气泡。性能优化负载测试工具Locust脚本 1 000 并发用户RPS 目标 200。瓶颈首次命中数据库KBItem 表 10 万行LIKE 查询 600 ms。解决加 GIN 索引PostgreSQLCREATE EXTENSION pg_trgm; CREATE INDEX CONCURRENTLY ON kbitem USING gin (question gin_trgm_ops);降到 30 ms。热点数据整表缓存 RedisTTL 300 sQPS 再提 35%。ORM 懒加载查对话历史时仅select_related(user)避免 N1列表页用only(user_msg, bot_answer, created_at)网络包大小降 60%。WSGI 优化Gunicorn 配 Gevent workergunicorn config.wsgi:application -k gevent -w 4 --worker-connections 1000同步 worker 在 200 并发直接 502Gevent 后 1 000 并发 CPU 65%仍有富余。生产环境指南日志监控配置Django 使用dictConfig拆分access.log/error.logJSON 格式方便 Loki 收集。关键字段request_id、user_id、intent、latency便于 Jaeger 全链路追踪。敏感信息过滤手机号、身份证走正则脱敏re.sub(r(\d{3})\d{4}(\d{4}), r\1****\2, text)日志 sink 前再跑一遍django-ratelimit的sensitive_post_processor防止 GDPR 罚款。限流策略单 IP 20 r/min用户 JWT 后 60 r/min用 Redis Lua 脚本保证原子性local c redis.call(incr, KEYS[1]) if c 1 then redis.call(expire, KEYS[1], 60) end if c tonumber(ARGV[1]) then return 1 else return 0 end超限返回 429前端回退排队页保护后端 NLP 推理资源。扩展思考如何集成多通道接入微信、Web、APP微信接企业微信回调XML 转 JSON统一入库 Dialogue.channelwechat。APP客户端带 JWT走 HTTPS REST同一套 ChatViewSet。WebSocketChannels 插件Django 原生异步支持客服主动推送“排队人数”。消息格式统一为{msg_id:, text:, channel:, user_id:}入库前加校验签名保证多端可追溯。踩坑小结Rasa 模型 300 M冷启动 8 sCelery worker 会超时。解决worker 启动时预加载保持心跳。PostgreSQL 索引膨胀知识库每日批量更新后未VACUUM查询计划走全表。加定时AUTOVACUUM解决。日志 JSON 字段顺序被 Python 3.9 字典打乱Grafana 解析失败。用orjson保证字段有序。上线两周机器人拦截率 72%平均响应 1.2 s人工坐席压力降一半老板终于不再深夜发“在吗”。如果你也在用 Django 堆智能客服不妨试试这套“先异步、再缓存、后限流”的小组合。下一步你会怎么实现对话上下文持久化让机器人记得用户三天前问过“发票抬头”欢迎留言实践。