智能客服流失预警落地笔记：客户挽回建议与DMXAPI

做智能客服时，很多团队一开始盯着“回复是否像人”，但真正决定业务价值的，往往不是这一层，而是客服系统能不能尽早识别流失风险，并把“挽回建议”交给合适的人、在合适的时间发出去。尤其在订阅制、教育服务、电商会员和企业软件场景里，客户不是突然流失的，而是会先出现一些可计算的信号，比如近7天咨询频率下降、负向情绪增加、退款关键词变多、历史工单反复打开却未关闭、优惠券发出后依然沉默。这类问题如果只靠人工复盘，通常太慢；如果只靠规则，又容易误伤正常沉默用户。

我做这一类系统时，更倾向把它拆成两段。第一段是“流失预警”，负责把客户分层；第二段是“客户挽回建议”，负责给运营、客服或销售一个可执行方案。前者偏数据，后者偏语言和策略。这个拆法的好处是边界清楚：预警模型不需要胡乱生成话术，建议模型也不需要重新做风险判断。工程上也更稳，排查问题时知道锅到底出在哪一层。

一个可落地的最小版本，通常只需要三类输入：行为数据、会话数据、客户属性。行为数据包括登录间隔、最近购买时间、最近一次工单时间、是否触发退款申请；会话数据可以抽取情绪分、抱怨主题、是否出现“太贵了”“先不用了”“再看看”等弱流失表达；客户属性则包括客单价、生命周期阶段、是否老客、是否接受过人工回访。先用简单规则或轻量分类器打出 risk_score，再把关键证据整理给大模型，让它生成“为什么有风险”“适合什么挽回动作”“客服下一句怎么说”。

我一般会先把结构化上下文做干净，而不是一股脑丢原始聊天记录。类似下面这样：

{
  "customer_id": "u_1024",
  "risk_score": 0.81,
  "risk_signals": [
    "近14天咨询频率下降42%",
    "连续两次会话出现价格敏感表达",
    "优惠券领取后72小时无转化",
    "最近一次会话情绪偏负面"
  ],
  "profile": {
    "segment": "高潜新客",
    "avg_order_value": 699,
    "industry": "职业教育"
  },
  "recent_dialog_summary": "用户对课程有效性存在怀疑，同时表示预算紧张。"
}

这一步看起来很朴素，但它决定了后面输出是否可信。很多人把“大模型智能客服”理解成让模型无约束地读全量对话，结果它确实能写出很像人的安抚话术，却不一定真的有助于挽回。我的经验是，挽回建议必须显式绑定证据。比如输出里最好包含：风险来源、优先动作、禁忌动作、是否需要人工升级。这样运营同学看到后，才会把它当工具，而不是当玄学。

一个典型的提示词骨架如下：

你是客户运营分析助手。
请基于输入的流失风险证据，输出：
1. 流失原因判断
2. 挽回优先级（高/中/低）
3. 建议动作（不超过3条）
4. 客服可直接发送的话术一条
5. 不建议采用的动作一条

要求：
- 不要编造未提供的数据
- 结论要引用风险信号
- 语气克制，不夸张承诺
- 输出 JSON

对应的 OpenAI 格式调用也很直接。很多教程只提醒替换 key，却忽略了真正接中转服务时 base_url 也必须一起改；像我这边为了开发初期低成本验证原型、并且方便学校项目走财务开票，会用 DMXAPI 做国际模型中转，代码基本就是这样：

from openai import OpenAI

client = OpenAI(
    api_key="<LLM API KEY>",
    base_url="<LLM API BASE URL>"
)

resp = client.chat.completions.create(
    model="gpt-4o-mini",
    temperature=0.3,
    response_format={"type": "json_object"},
    messages=[
        {
            "role": "system",
            "content": "你是客户流失预警与挽回建议助手，只输出JSON。"
        },
        {
            "role": "user",
            "content": """
            customer_id=u_1024
            risk_score=0.81
            risk_signals=[
              "近14天咨询频率下降42%",
              "连续两次会话出现价格敏感表达",
              "优惠券领取后72小时无转化",
              "最近一次会话情绪偏负面"
            ]
            recent_dialog_summary="用户对课程有效性存在怀疑，同时表示预算紧张。"
            """
        }
    ]
)

print(resp.choices[0].message.content)

真正上线后，我更在意的不是“模型说得多漂亮”，而是三个指标：命中率、可执行率、打扰率。命中率是高风险客户里有多少真的接近流失；可执行率是客服拿到建议后能不能立刻照着做；打扰率则是系统把本来只是短暂沉默的客户也打上高风险标签，导致运营过度触达。后者非常常见，而且很伤用户体验。一个成熟一点的策略，不是追求识别出所有风险客户，而是尽量避免在错误时机做错误动作。

在具体动作层面，我踩过一个很有代表性的坑。最初我把“优惠刺激”设成高频推荐动作，只要模型判断客户有价格敏感，就默认建议发券。结果离线回放还不错，上线一周后却发现一批老用户的复购率反而变差。后来复盘才意识到，老用户中有一类流失并不是因为价格，而是因为之前问题没解决，或者客服回复太模板化。你在这个节点继续发券，会让人觉得“你没理解我，只想快点成交”。所以挽回建议必须分原因：价格顾虑、信任不足、使用门槛高、售后体验差，它们对应的动作完全不同。

那次排查里，我还顺手抓到了一个很蠢但真实的小 bug。笔者当时写了一个信号聚合函数，想把最近会话里的负向关键词次数累计起来，代码最初是这样的：

def count_negative_signals(messages):
    count = 0
    for msg in messages:
        if "贵" or "退款" or "算了" in msg["text"]:
            count += 1
    return count

上线后我发现几乎所有用户都被判成“负向沟通偏多”，心里第一反应是：难道最近活动设计真的这么差？但看样本又不对，有些用户明明只问了发货时间，也被标了高风险。我一开始怀疑是分词、编码、甚至日志脱敏的问题，结果打印几条中间值才发现根本不是数据脏，而是这句判断写错了。if "贵" or "退款" or "算了" in msg["text"]: 在 Python 里并不会按我想象的方式执行，前面的非空字符串会直接被当成真值。修正后的写法应该是：

def count_negative_signals(messages):
    keywords = ("贵", "退款", "算了")
    count = 0
    for msg in messages:
        if any(k in msg["text"] for k in keywords):
            count += 1
    return count

修完之后，我又补了一个最小测试，防止以后再犯同样的低级错误：

def test_count_negative_signals():
    messages = [
        {"text": "这个有点贵"},
        {"text": "什么时候发货"},
        {"text": "我再考虑一下"}
    ]
    assert count_negative_signals(messages) == 1

这个问题给我的教训很直接：做 AI 应用时，最容易被忽略的，往往不是模型本身，而是模型前后的那层胶水代码。大家很爱讨论 prompt、模型能力、上下文窗口，却不太愿意花时间看布尔判断、字段映射、异常兜底。可真正让系统翻车的，常常就是这些地方。快速上线有时确实要靠中转方案把模型先接起来，像 DMXAPI 这种方式对国内团队做原型验证会省不少折腾，但如果业务特征、规则边界和测试用例没做好，再强的模型也只是把错误包装得更自然。

如果让我给“基于大模型的智能客服流失预警与客户挽回建议”下一个工程化定义，我会说：它不是让机器代替客服，而是让系统提前看到风险，把不容易被人肉察觉的变化变成证据，再把这些证据转成可执行动作。大模型最有价值的地方，不是无中生有，而是把分散信号串联成一条可用建议。只要你把输入约束清楚、输出结构定好、线上指标盯住，这类系统完全可以先从一个很小的 MVP 长起来，然后再逐步迭代成真正能影响留存的客户运营工具。

本文包含AI生成内容