客服机器人上线三个月就没人管了——我复盘了那些踩坑的搭法
先说几个常见的失败现场
不少独立开发者和小团队接到“做个客服机器人”的需求时，第一反应是：找个开源框架，把FAQ文档一灌，上线收工。结果通常是这几种下场：
下场一：关键词匹配硬扛。 上线第一周回复准确率看着还行，第二周用户开始问“退款流程是啥”“怎么退货”“我不想要了怎么办”——同一个意图三种问法，关键词库直接漏接。运营同学手动补关键词补到怀疑人生，三个月后知识库变成没人敢动的屎山。
下场二：直接裸调大模型。 换个思路，把全部FAQ文档塞进prompt，让大模型自由发挥。短期效果惊艳，但很快发现：模型会一本正经地编造不存在的退货政策，回答口径和人工客服对不上；而且每条消息都带着几万token的上下文，月底账单直接翻倍。
下场三：多轮对话全靠if-else。 为了处理“查订单→追问物流→再问退款”这种连续对话，写了满满一屏的分支判断。每加一个新场景就要重构一遍状态机，最后代码没人看得懂，需求排期排到下个季度。
这些做法的共同问题是：把“能回答一次问题”当成了目标，而客服场景真正难的是意图识别准确、回答可控、上下文连贯、成本可预期这四件事同时成立。
正确的路径：意图识别 + RAG + 受控生成的三层结构
复盘之后，我给团队定的架构是分层的，每层只干一件事：
用户消息
│
▼
┌─────────────────────────────────────┐
│ 第一层：意图分类（小模型，便宜快速） │
│ 输出：意图标签 + 置信度 │
│ - 高置信 + FAQ命中 → 直接返回标准答案 │
│ - 低置信 / 业务操作类 → 进入第二层 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 第二层：RAG 检索增强 │
│ 知识库切片 → 向量检索 top-k │
│ → 组装带引用的上下文 │
└─────────────────────────────────────┘
│
▼
┌─────────────────────────────────────┐
│ 第三层：受控生成（强模型） │
│ 系统提示词限定：只基于给定资料回答， │
│ 资料里没有就说不知道并转人工 │
│ 携带多轮对话历史（滑动窗口管理） │
└─────────────────────────────────────┘这个结构的关键取舍：
- 意图分类用便宜的小模型。大部分请求其实是高频FAQ，命中后直接返回缓存的标答，一分钱生成费用都不花。
- RAG只在需要时触发。只有低置信度或业务操作类问题才走向量检索和生成，token消耗可控。
- 多轮对话靠对话历史管理而不是状态机。维护一个滑动的对话窗口，把最近N轮摘要塞进上下文，模型自己理解“它”指的是什么，不用写一行if-else。
- 兜底转人工。受控生成的提示词里明确要求“资料未覆盖时引导转人工”，避免编造。这一条上线后，客服口径不一致的投诉基本消失。
关键实现步骤（流程清单）
- [ ] 整理FAQ，按“一个意图一个条目”拆分，写清楚标准答案和同义问法（这是效果的地基，比选模型重要）
- [ ] 意图分类：把意图标签和少量示例写进系统提示词，用小模型输出结构化JSON
- [ ] 知识库处理：长文档按语义段落切片（300-500字），向量化入库，条目带元数据（更新时间、适用范围）
- [ ] 检索与生成：top-k取3-5条，拼进提示词，明确“只依据资料回答”
- [ ] 多轮管理：会话内维护消息数组，超过窗口做摘要压缩
- [ ] 埋点与评测：记录每次请求的意图命中、检索命中、是否转人工，每周跑一批标注样本回归
- [ ] 上线灰度：先对10%流量开放，对比机器人与人工的解决率
为什么我要过统一AI API网关
架构定了，落地时还有个现实问题：意图分类想用便宜模型，生成想用强模型，后面可能还要加embedding和内容审核——每加一个能力就多一套SDK、一串密钥、一套限流和计费逻辑。独立开发者的时间不该耗在这上面。
接入统一AI API网关后，我只维护一个endpoint和一把密钥，通过参数切换模型。带来的维护成本下降是实打实的：
- 换模型不用改代码。意图分类那个小模型哪天性价比不行了，改个模型名就切走，不用重新对接鉴权和SDK。
- 统一计费和监控。所有调用走同一个网关，成本报表、失败率、延迟一眼看清，做成本复盘不用拼凑各家的账单。
- 一套降级和重试逻辑。模型超时自动fallback到备用模型，这段逻辑写在网关配置里，业务代码保持干净。
三个模型各配三套密钥三套SDK的日子，我是不想再回去了。
结语
客服机器人不是“灌个FAQ就能跑”的玩具，也不是“裸调大模型”的魔法。分层架构 + 统一网关，让小团队也能用维护一个项目的精力，撑起一套多模型协作的对话系统。
如果你也准备动手搭一套，可以从一个支持多模型切换的网关开始注册起：https://api.thistoken.ai/register，先把地基打对，后面的路会顺很多。
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。