智能客服Agent：知识库变成自动应答
架构：FAQ 精确匹配优先，RAG 兜底，人工接住
很多人以为智能客服就是"用户问问题 → RAG 检索 → LLM 生成答案"。太天真了。
真实流量里，大部分问题是重复的、有标准答案的。用 RAG 走一遍，慢、贵、还可能答歪。正确做法是三层分流：
代码块
Plain Text
用户消息
│
├─ ① FAQ 精确匹配（阈值 0.92）→ 命中？→ 直接返回预设答案（毫秒级，零成本）
│
├─ ② RAG 检索 + 生成（复用第 2、3 篇的 Pipeline）
│ └─ 置信度低？→ 转人工
│
└─ ③ 人工接住：转人工时带上对话摘要和 AI 的初步判断
✅
•
第一层 FAQ 匹配不是玄学。FAQ 数量一般几百条，用向量相似度匹配，命中阈值设高点，宁可漏过也不要误命中。命中就直接返回标准答案，不走 LLM。
•
第二层才轮到 RAG。检索置信度低于阈值就转人工，不要硬答。
•
第三层是很多团队忽略的：转人工不是简单地把会话丢给客服。AI 先把对话总结好，客服接手时不用从头读，效率完全不一样。
核心代码
代码块
Python
# ai_support.py - 智能客服三层分流
from dataclasses import dataclass
@dataclass
class SupportConfig:
faq_threshold: float = 0.92 # FAQ 命中阈值，宁可漏不可错
rag_threshold: float = 0.60 # RAG 置信度下限，低于则转人工
model: str = "qwen-plus" # 生成模型，按成本可换小模型
class AISupport:
def __init__(self, faq_store, rag_retriever, llm, config: SupportConfig):
self.faq_store = faq_store # FAQ 向量索引，问题->标准答案
self.rag = rag_retriever # 第 2、3 篇的检索 Pipeline
self.llm = llm
self.config = config
def handle(self, message: str, user_id: str, history: list) -> dict:
"""处理一条用户消息，返回回答或转人工指令"""
# ① FAQ 精确匹配优先：快、准、零成本
faq = self.faq_store.match(message, threshold=self.config.faq_threshold)
if faq:
return {"action": "answer", "reply": faq.answer,
"source": "faq", "confidence": faq.score}
# ② RAG 检索 + 生成
FAQ 阈值设 0.92 是故意的。 误命中比漏命中可怕。漏了最多多花一次 RAG 调用，误命中了直接给用户一个驴唇不对马嘴的标准答案，信任感瞬间归零。我们上线初期故意调高阈值，宁可让更多问题走 RAG，也不让 FAQ 乱答。
转人工带摘要。 客服接到会话时先看到"用户想升级套餐，但企业版报价需要人工确认"这种摘要，而不是 20 条原始消息。第一次上线这个功能，客服团队主动过来问"这个摘要能不能再详细点"。需求是不是被接住了，看这个反应就够了。
上线节奏：灰度三步走
我们没有一步到位。按流量灰度，每步观察 24 小时：
每天人工抽 10 条 AI 回答过的对话核对质量，发现问题当天修。不是"上线了就不管了"，前两周我们基本每天都要调 FAQ 和补检索词。
上线一个月后的数据（灰度期间统计）：
需要说明的是，这些数字是我们这个场景的灰度数据，不同产品差异会很大。客服问答类产品的"自动解决率"和问题复杂度强相关，别拿别人的数字当自己的 KPI。
踩坑：AI 答错比不答更伤信任
最大的坑是"硬答"。
一开始 RAG 置信度低于阈值时，我们也让 LLM 硬着头皮答。结果用户问了个文档里没有的问题，AI 编了一个像模像样的答案，用户信了，照着操作，系统报错。用户回来投诉，比不回答更生气。
从此我们立了一条规矩：置信度不够就转人工，宁可让用户等，不能让他信错。 这条规矩后来救了第二个场景的命。
另一个坑是"自动率"这个指标。
有同事提议看"AI 自动回复率"，说这个数字高就说明效果好。我们算了算：把简单问题全自动、难问题全转人工，自动率能刷到很高，但用户感知的提升有限。真正有用的指标是自动解决率：AI 回答后，用户没有追问、没有转人工、没有差评。这个指标才反映"问题真的被解决了"。