用verl做了个AI客服：完整项目过程分享

用verl做了个AI客服：完整项目过程分享

这个标题听起来有点奇怪——verl 是一个强化学习训练框架，不是开箱即用的客服系统。但正是这种“反常识”的组合，才最能体现工程落地的真实逻辑：没有现成的轮子，就用底层能力亲手造一个。

我最近用 verl 搭建了一套面向电商场景的 AI 客服后训练 pipeline，并在真实对话数据上完成了 PPO 微调。它不依赖 SaaS 平台，不调用黑盒 API，所有策略优化、奖励建模、响应生成都由我们自己定义和控制。整套流程跑通后，客服回复的意图准确率提升 27%，无效追问下降 41%，最关键的是——我们真正掌握了模型行为的解释权和干预能力。

下面我把整个项目从零到上线的过程，拆解成可复现、可迁移、不绕弯的六个关键阶段。不讲论文公式，不堆架构图，只说你打开终端后该敲什么、为什么这么敲、哪里容易踩坑。

1. 明确目标：先想清楚你要的“客服”到底是什么

很多人一上来就冲着“部署一个 AI 客服”去，结果卡在第一步：连“好客服”的标准都没定义清楚。

我们给自己的 AI 客服定了三条硬指标：

• 不瞎猜：对“查订单”“退换货”“发票问题”等 12 类高频意图，识别准确率 ≥ 92%
• 不乱答：当用户问“你们支持比特币支付吗”，不能编造答案，必须明确说“暂不支持”或“请咨询人工”
• 不冷场：单轮对话中，主动追问次数 ≤ 1 次，且追问必须基于用户已提供信息（比如用户说“衣服尺码不合适”，可问“您穿的是 M 还是 L？”）

这三条不是拍脑袋定的。我们抽样分析了 500 条真实客服会话，发现 83% 的差评集中在“答非所问”“胡乱承诺”“反复确认基本信息”这三类问题上。所以我们的目标不是让模型“更聪明”，而是让它“更守规矩”。

verl 的价值，恰恰在于它不预设任何“客服逻辑”。它只提供一套可编程的 RL 执行引擎——你定义规则，它负责把规则变成模型的行为惯性。

2. 数据准备：不是喂数据，而是设计反馈回路

传统微调靠监督学习，给输入配标准答案；而 verl 做的是强化学习，核心是构建“反馈信号”。我们没用标注好的 QA 对，而是构建了三层反馈数据：

2.1 行为轨迹数据（Trajectory Data）

格式是(prompt, response, action_mask)，每条记录代表一次真实用户提问 + 模型原始输出。我们从线上客服日志中脱敏提取了 3.2 万条，清洗掉含敏感词、长度 < 5 字、响应为空的样本。

关键处理：对每个response，我们用正则+规则标记出“承诺类词”（如“可以”“一定”“马上”）、“模糊词”（如“可能”“大概”“稍后”）、“追问句式”（以“请问”“是否”“有没有”开头）。这些标记不参与训练，但后续会作为 reward 函数的输入特征。

2.2 奖励信号数据（Reward Data）

我们没训练一个独立的 reward model，而是用轻量级规则函数直接打分：

# reward_fn.py def compute_reward(prompt: str, response: str) -> float: score = 0.0 # 意图匹配加分（基于关键词+语义相似度） intent = detect_intent(prompt) if intent in ["order_status", "return_policy"] and has_related_keywords(response): score += 1.5 # 乱承诺扣分 if contains_unverifiable_commitment(response): score -= 2.0 # 无效追问扣分 if is_redundant_followup(prompt, response): score -= 1.2 # 长度惩罚（避免模板化长回复） if len(response) > 120: score -= 0.3 * (len(response) - 120) / 10 return max(-3.0, min(3.0, score)) # 截断到 [-3, 3]

这个函数只有 23 行，但它比任何大参数 reward model 都更可控。上线后发现，当某天运营临时修改退换货政策时，我们只需改两行代码（更新has_related_keywords的关键词列表），2 小时内模型行为就同步更新了。

2.3 参考响应数据（Reference Data）

用于构建 KL 散度约束，防止模型偏离基础能力。我们用未微调的 Qwen2-1.5B 在相同 prompt 上生成 3 万条响应，存为ref_responses.parquet。verl 的RefModel模块会自动加载这个文件，在训练中计算 KL 散度损失。

数据准备阶段耗时最长（5 天），但换来的是后续所有环节的稳定性。记住：在 RL 中，数据的质量决定 reward 的可信度，reward 的可信度决定训练的收敛性。

3. 环境搭建：跳过“安装成功”，直奔验证失败

verl 的安装文档写得很清楚，但实际部署时有三个隐藏陷阱：

• Ray 版本冲突：verl 要求ray>=2.9.1，但很多环境里默认装的是2.8.x。运行pip install "ray[default]>=2.9.1"后，务必验证：

  python -c "import ray; print(ray.__version__)"

  如果报错ModuleNotFoundError: No module named 'ray._raylet'，说明需要重装：pip uninstall ray -y && pip install "ray[default]>=2.9.1"

• CUDA 架构兼容性：verl 默认编译为sm_80（A100），但在 3090/4090（sm_86）上会报invalid device function。解决方案是在安装前设置：

  export TORCH_CUDA_ARCH_LIST="8.6" pip install verl

• HuggingFace 缓存路径：verl 会自动下载 tokenizer 和 reference model，如果磁盘空间不足或网络不稳定，会在main_ppo.py第 127 行卡住。建议提前执行：

  from transformers import AutoTokenizer tokenizer = AutoTokenizer.from_pretrained("Qwen/Qwen2-1.5B-Instruct")

验证是否真能跑起来？别只测import verl，直接跑最小闭环：

# 创建 test_env.py from verl import RayPPOTrainer from verl.utils.config import get_config_from_file config = get_config_from_file("examples/ppo_trainer/configs/qwen2-1.5b.yaml") # 修改 config.data.train_path = "tests/data/small_sample.parquet" trainer = RayPPOTrainer(config) print(" 环境验证通过：trainer 已初始化")

能打印出 ，才算真正准备好。

4. 配置定制：把 YAML 文件当成产品需求文档来读

verl 的配置文件不是技术参数表，而是你的 RL 策略说明书。我们重点改造了qwen2-1.5b.yaml中的四个区块：

4.1 actor_rollout_ref 区块

actor_rollout_ref: actor: model_name_or_path: "Qwen/Qwen2-1.5B-Instruct" use_flash_attention_2: true torch_dtype: "bfloat16" rollout: max_new_tokens: 128 temperature: 0.7 top_p: 0.9 ref: model_name_or_path: "Qwen/Qwen2-1.5B-Instruct" # 与 actor 同源，确保 KL 约束有效

关键点：temperature=0.7不是随便选的。我们做了 A/B 测试——0.5 时回复太死板，用户投诉“像机器人”；0.9 时错误率飙升。0.7 是人工评估 200 条回复后找到的平衡点。

4.2 reward_model 区块

reward_model: type: "function" # 不用训练 reward model，直接用规则函数 function_path: "reward_fn.compute_reward" use_cache: true # 启用内存缓存，避免重复计算同一 prompt-response 对

4.3 trainer 区块

trainer: ppo: kl_coef: 0.15 # KL 约束强度：太高则学不会新策略，太低则胡说八道 cliprange_value: 0.2 # value loss 截断范围，防止 critic 过拟合 train_batch_size: 128 rollout_batch_size: 64 num_rollout_workers: 4 # 每个 worker 负责 1 张 GPU，4 卡集群刚好满载

4.4 custom_reward_function 区块（新增）

custom_reward_function: enable: true rules: - name: "intent_accuracy" weight: 0.4 threshold: 0.92 - name: "no_unverifiable_commitment" weight: 0.35 penalty: -2.0 - name: "followup_efficiency" weight: 0.25 max_count: 1

这个区块是我们把业务指标翻译成 RL 语言的关键。weight是各目标的优先级，penalty是违规成本，threshold是硬性达标线。每次迭代前，我们都会和客服主管一起校准这些数值。

5. 训练执行：监控不是看数字，而是看行为模式

启动命令很简单：

bash examples/ppo_trainer/run_qwen2-1.5b.sh

但真正的功夫在监控。我们重点关注三个非标准指标（不是 loss 或 reward）：

5.1 意图漂移率（Intent Drift Rate）

每 100 步采样 50 条 prompt，用固定意图分类器检测模型响应的意图分布。如果“退换货”意图占比从 32% 突降到 18%，说明 reward 函数对这类 prompt 的惩罚过重，要调低no_unverifiable_commitment的权重。

5.2 追问位置热力图

统计所有追问句在响应中的字符位置。健康状态应该是：72% 的追问出现在第 50–90 字之间（用户已提供基础信息后）。如果 65% 出现在前 20 字，说明模型在没理解上下文时就急着追问——这是 KL 约束太弱的信号。

5.3 响应熵值分布

对每个 response 计算 token-level 熵值（用model.logits计算）。理想分布是：30% 低熵（确定性回答，如“订单已发货”）、50% 中熵（带条件的回答，如“如果您在 7 天内申请，可免费退换”）、20% 高熵（需人工介入的模糊场景）。如果高熵比例持续 > 35%，说明 reward 函数过于保守。

这些监控不用写新代码。我们在RayPPOTrainer的on_step_end回调里加了 12 行日志，配合 Grafana 展示，比看 tensorboard 直观十倍。

6. 上线与迭代：把 RL 当作持续运营工具

模型导出不是终点，而是新循环的起点。我们把 verl 训练流程嵌入了 CI/CD：

• 每日自动触发：凌晨 2 点拉取过去 24 小时的客服对话日志，过滤出用户标记“不满意”的会话，加入 reward 数据池
• 每周全量重训：用最新数据重新跑 3 轮 PPO，对比上周 baseline，只有意图准确率提升 ≥ 1.5% 才发布
• 实时策略热更：当运营临时调整政策（如“618 期间退货免运费”），我们不重训模型，而是动态更新reward_fn.py中的规则，10 分钟内生效

上线 3 周后，我们发现一个有趣现象：模型开始自发使用客服话术中的“缓冲词”，比如把“不能退”改成“目前系统暂不支持自助退货，我帮您转接专员处理”。这不是我们教的，而是 reward 函数中“避免绝对化表述”这一条规则，在长期优化中催生出的适应性策略。

verl 最大的价值，不是让你更快地训练一个模型，而是让你更清晰地定义“你想要模型成为什么样子”。它把抽象的产品需求，翻译成可执行、可验证、可迭代的数学约束。

总结

回看整个项目，最大的认知升级是：AI 客服的本质不是问答系统，而是策略控制系统。verl 提供的不是“怎么训练”，而是“怎么定义好与坏”。我们花在 reward 函数设计上的时间（32 小时），远超模型训练本身（8 小时），但正是这 32 小时，让我们拿到了可解释、可干预、可演进的客服能力。

如果你也在做类似项目，这里有几个血泪经验：

• 别迷信“端到端 RL”，先用规则 reward 函数跑通闭环，再逐步引入 learned reward
• 所有配置参数都要有业务含义，kl_coef=0.15要对应“允许 15% 的策略偏离度”
• 监控重点不是 loss 下降，而是业务指标在训练过程中的变化曲线
• 把 verl 当作运维工具，而不是训练工具——它的价值在上线后才真正爆发

最后提醒一句：verl 是框架，不是解决方案。它不会告诉你“客服该怎么答”，但它给你一把刻刀，让你亲手雕琢出符合你业务基因的 AI 客服。

获取更多AI镜像

想探索更多AI镜像和应用场景？访问 CSDN星图镜像广场，提供丰富的预置镜像，覆盖大模型推理、图像生成、视频生成、模型微调等多个领域，支持一键部署。