FAQ机器人上线三个月就没人用了——问题出在你只答不问
一个反例开局
很多独立开发者和小团队接到“做个客服机器人”的需求时，第一反应是：把FAQ文档整理成问答对，往向量库里一塞，接一个大模型做检索增强，齐活。
这个方案在Demo阶段效果惊人：客户问“怎么退货”，机器人秒答；问“运费多少”，也对答如流。于是团队信心满满地上了线。
三个月后，数据很难看：
- 用户问“我上周买的订单怎么还没到”，机器人返回了“物流时效说明”的标准答案，因为检索只命中了“订单”和“物流”两个关键词；
- 用户说“那不是我要的”，机器人开始重复输出同一个答案；
- 真正高价值的咨询——投诉、退款纠纷、多条件组合查询——全部转人工，客服吐槽“机器人接的全是简单问题，麻烦的全留给我”。
问题的根源不是模型不够强，而是架构上只有“一问一答”，没有“对话状态”。单轮FAQ是一个检索问题，多轮对话是一个状态管理问题，两者的技术路径完全不同。
先讲常见的失败做法
在给出正确路径前，把这些坑列清楚：
失败做法一：用更大的模型硬扛。 换成旗舰模型后，闲聊体验确实好了，但用户追问“那我那个订单呢”时，模型依然不知道在问哪个订单——因为上下文里根本没有订单信息。成本翻了几倍，问题没解决。
失败做法二：把所有历史消息原样塞进Prompt。 表面上是“多轮”了，实际上每次调用都带着几十条历史，token费用暴涨，而且无关历史会稀释关键信息，答案质量反而下降。
失败做法三：每接一个渠道就写一套调用代码。 微信公众号一套、网页挂件一套、App内一套，每套代码各自处理模型调用、超时重试、密钥管理。三个渠道三份密钥、三份重试逻辑、三份日志格式，改一个功能要改三处。小团队根本养不起这种维护量。
失败做法四：全链路用同一个模型。 意图识别、答案生成、摘要压缩这些任务难度差异巨大，统一用旗舰模型，月底账单比人工客服工资还高。
正确路径：分层架构
把机器人拆成四层，各司其职：
用户消息
│
▼
┌─────────────┐
│ 意图识别层 │ ← 小模型，判断：闲聊/FAQ/业务办理/投诉
└─────────────┘
│
├─ 闲聊 → 轻量模型直接回复
│
├─ FAQ → 检索增强（RAG）：向量库召回 + 重排 → 生成答案
│
└─ 业务/多轮 → 进入对话状态机 ↓
┌──────────────────┐
│ 对话管理层 │
│ - 会话状态槽位 │
│ (订单号/日期/诉求) │
│ - 缺槽追问 │
│ - 澄清歧义 │
└──────────────────┘
│
▼
工具调用：查订单API、发起退款等
│
▼
统一AI API网关 → 按任务路由到不同模型核心思想：单轮问题走检索，多轮问题走状态机，工具调用解决“机器人不知道事实”的问题。
关键实现步骤
第一步：意图分层，别让所有消息都进大模型。 用一个便宜的小模型（或规则+嵌入相似度）先做分流。实践中70%以上的消息是FAQ和闲聊，根本不需要昂贵模型参与完整流程。
第二步：设计对话状态槽位。 以“查物流”场景为例：
SLOTS = {
"query_logistics": {
"required": ["order_id"],
"optional": ["time_range"],
"ask_rules": {
"order_id": "请问是哪个订单呢？可以提供订单号或下单手机尾号。",
}
},
"refund": {
"required": ["order_id", "reason"],
"ask_rules": {
"reason": "方便说下退款原因吗？未收到货、质量问题还是其他？"
}
}
}
def process_turn(state, user_msg, llm):
# 1. 用LLM抽取本条消息中的槽位值
extracted = llm.extract_slots(user_msg, SLOTS[state.intent].keys())
state.slots.update(extracted)
# 2. 检查必填槽位，缺了就追问，不硬答
for slot in SLOTS[state.intent]["required"]:
if not state.slots.get(slot):
return SLOTS[state.intent]["ask_rules"][slot], state
# 3. 槽位齐了，调工具拿事实，再生成答案
facts = call_tool(state.intent, state.slots)
return llm.generate_answer(user_msg, facts, state.history_summary), state这段伪代码的关键在于第2步：缺信息就问，而不是硬编一个通用答案。这是FAQ机器人和对话机器人的分水岭。
第三步：历史压缩而不是全量携带。 每轮结束后用小模型把对话压缩成一句话摘要存入状态，传给下一轮的只有摘要+槽位+最近两轮原文。token消耗降一个数量级，关键信息不丢失。
第四步：设定转人工规则。 连续两次澄清失败、用户情绪负面、涉及金额纠纷，直接转人工并带上完整会话摘要。机器人不是用来替代人工的，是用来过滤人工的。
为什么统一AI API网关能降低维护成本
这是小团队最容易忽视、又最能省力气的一环。
前面提到失败做法三：多渠道各写一套调用代码。即使只有一个渠道，只要你在意图识别用A模型、答案生成用B模型、摘要压缩用C模型，就意味着管理三套SDK、三份密钥、三种错误码格式、三条计费账单。
统一AI API网关的价值在于：
- 一套代码访问所有模型。 网关提供统一接口规范，换模型、加模型只是改一个模型名参数，不动业务代码。A/B测试新模型变成十分钟的事。
- 密钥和限流集中管理。 密钥泄露风险收敛到一处，配额管理不用在五个后台之间切换。
- 天然的观测和成本控制点。 所有调用经过同一网关，按意图、按渠道的token消耗一目了然，哪一层该降级模型、哪一层被滥用，数据说话。
- 故障兜底。 上游模型超时，网关层配置自动降级到备用模型，用户端无感知。
对小团队来说，这相当于把“平台工程”外包给了网关，你只需要专注业务逻辑。
上线节奏建议
不要追求一步到位：第一周只上FAQ检索，验证召回质量；第二周加意图分流和槽位追问；第三周接入工具调用；每一步都留着回滚开关。客服机器人是运营出来的，不是一次开发出来的。
如果你正准备动手，模型调用这一层可以先跑通再说——注册一个统一AI API网关账号，几分钟就能拿到多模型调用能力，从FAQ原型开始验证你的第一个多轮对话场景：https://api.thistoken.ai/register
---
不想折腾多家供应商的接入差异？在 https://api.thistoken.ai/register 注册，用一个 base_url 调用所有模型。