大模型客服微调实战：从数据准备到客服机器人上线的完整流程

知识分享

2026-10-19 03:00

12 阅读

想把客服问答做成一个能跑在自己服务器上的模型，核心路径是：准备一批客服对话数据，用 LoRA 方式微调一个开源基础模型，再把训练好的权重部署成 HTTP 接口，最后用真实问题做验证。
这个过程不需要从零训练模型，对零基础用户来说，重点在数据清洗和显存配置上。

先判断你的场景适不适合微调

微调适合客服话术相对固定、希望模型按公司话术回答的场景，比如退换货规则、产品参数、常见故障排查。
如果只是想让模型知道最新活动或库存，用检索增强（RAG）比微调更合适，因为微调不会自动更新知识。

一个简单的判断标准：

问题答案有固定模板、需要统一口径：优先微调。
答案依赖实时数据、频繁变化：优先 RAG 或接口查询。
两者都有：先微调语气和格式，再接检索补充事实。

本文按微调路线展开，适合有一台带 GPU 的服务器、能通过命令行操作 Linux 的读者。

环境准备与数据整理

服务器与软件环境

建议使用 Ubuntu 22.04 或更新版本，显卡显存至少 16GB（7B 模型 LoRA 微调的经验值，实际受序列长度和批次大小影响）。
先确认驱动和 CUDA 可用：

nvidia-smi

输出中能看到显卡型号和 CUDA Version 即可。
然后创建 Python 虚拟环境，安装训练框架。
以 LLaMA-Factory 为例：

git clone https://github.com/hiyouga/LLaMA-Factory.git
cd LLaMA-Factory
python3 -m venv venv
source venv/bin/activate
pip install -r requirements.txt
pip install -e .

如果 pip 安装较慢，可以配置国内镜像源，但不要随意升级 torch 版本，优先使用框架要求的版本。

客服数据格式

微调数据通常用 JSON 行格式，每条一个样本。
客服场景建议整理成多轮对话形式：

{"conversations": [{"role": "user", "content": "订单发货后多久能到？"}, {"role": "assistant", "content": "普通快递一般 3 到 5 天送达，偏远地区可能延长 1 到 2 天。"}]}

数据量方面，几百到几千条高质量样本通常就能看到效果，关键是覆盖真实问题。
整理时注意：

同一个问题保留多种问法，比如“多久到”“几天能收到”“发货后几天到”。
答案统一口径，不要出现互相矛盾的话术。
去掉包含手机号、订单号等敏感信息的样本。

把数据保存为 data/customer_service.json，并在框架的 dataset_info.json 中注册数据集名称。

开始微调与关键参数

在 LLaMA-Factory 目录下，可以用命令行启动 LoRA 微调。
下面是一个 7B 模型的示例配置，实际参数按显存调整：

llamafactory-cli train \
  --model_name_or_path Qwen/Qwen2.5-7B-Instruct \
  --stage sft \
  --do_train \
  --dataset customer_service \
  --template qwen \
  --finetuning_type lora \
  --lora_target all \
  --output_dir saves/customer_service_lora \
  --per_device_train_batch_size 2 \
  --gradient_accumulation_steps 8 \
  --learning_rate 1e-4 \
  --num_train_epochs 3 \
  --cutoff_len 1024 \
  --fp16

几个容易出问题的地方：

per_device_train_batch_size 设得太大容易显存不足，先设 1 或 2，再逐步增加。
cutoff_len 是单条样本最大长度，客服对话一般 1024 足够，过长会明显增加显存占用。
num_train_epochs 不是越多越好，3 轮左右先看损失是否稳定，过拟合会让模型背答案。

训练开始后，终端会输出 loss 变化。
如果 loss 长期不下降，优先检查数据格式和 template 是否匹配模型。

部署接口与效果验证

训练完成后，output_dir 下会生成 LoRA 权重。
可以先用框架自带的推理命令做一次对话测试：

llamafactory-cli chat \
  --model_name_or_path Qwen/Qwen2.5-7B-Instruct \
  --adapter_name_or_path saves/customer_service_lora \
  --template qwen

确认回答符合预期后，再导出合并模型或启动 API 服务。
LLaMA-Factory 提供 llamafactory-cli api 启动 OpenAI 兼容接口，然后用 curl 验证：

curl http://127.0.0.1:8000/v1/chat/completions \
  -H "Content-Type: application/json" \
  -d '{"model":"customer_service","messages":[{"role":"user","content":"退货需要几天退款？"}]}'

验证时不要只看一两个问题，建议准备 20 到 30 条真实客服问题，检查三点：回答是否偏离话术、是否出现编造政策、多轮对话是否保持上下文。
发现异常时，优先回到训练数据补充对应样本，而不是反复调大训练轮数。

常见报错与避坑提醒

CUDA out of memory：降低 batch size、缩短 cutoff_len，或开启梯度检查点。
数据集加载失败：检查 dataset_info.json 中的文件名和格式字段是否与实际文件一致。
回答重复或胡言乱语：通常是学习率过高或数据量太少，先降低学习率，再补充样本。
模型不按客服话术回答：检查训练数据中是否混入了通用闲聊样本，客服数据要尽量聚焦业务。

另外，微调不会让模型记住实时价格和库存，涉及这类信息时，建议在接口层拼接查询结果，而不是指望模型自己记住。

上线前的检查清单

在把接口接到客服系统之前，至少确认：模型能稳定响应、超时时间设置合理、日志中不记录用户敏感信息、并发量不超过服务器承载。
如果使用云服务器承载推理服务，建议选择 GPU 规格与显存满足模型要求的实例，并提前压测。
对于需要长期稳定运行的客服场景，服务器带宽和显存余量比单次训练速度更重要。

整套流程跑通后，你会发现大模型客服微调真正的门槛不在命令本身，而在数据质量和验证环节。
先小批量跑通，再逐步扩充数据，是更稳妥的落地方式。

大模型电商微调实战：从数据到部署的零基础落地步骤

大模型K8s部署教程：从零搭建推理服务