开源智能客服机器人：知道何时转人工

dev.to · AI#客服机器人#RAG#开源

Editor brief · 编辑速览

支持Web/Discord/WhatsApp多渠道，集成HITL、情感检测判断转人工时机，六阶段RAG+FAISS检索提升回答准确性。

文章思维导图

Knowledge map

拖拽缩放

Full translation

完整中文译文

每个人都遇到过那种客服机器人——它一遍遍说"抱歉，我没听懂"，而你却越来越火大。

我想做的是相反的东西：一个能回答它能回答的问题、在需要真人时安静退出的机器人。它运行在 Web、Discord 和 WhatsApp 上，代码开源：github.com/Shahzaib30/ai-support-agent

这个系统有四层。客户从任意渠道与它对话，一个 FastAPI 后端处理所有事务，一些服务存储状态和发送告警，监控则监视着一切。

FastAPI 核心中，答案引擎前面有三重关卡：HITL 关卡（human-in-the-loop，检查是否已经有客服在处理对话）、显式升级检查，以及情绪升级检查。PostgreSQL 记录对话历史，Redis 缓存答案，一切通过一条 Docker Compose 命令即可运行。

Bot 如何查找答案

大多数 RAG 机器人搜一次就完事。我的系统把每个问题过六道关：

问题进来后，首先经过一个查询压缩器（query condenser）重写它。客户会说"那打折商品呢？"这样的话，单独看毫无意义。一个 DeepSeek 步骤先把后续问题转成独立问题。

然后两个搜索同时跑。FAISS 配合 BGE-small 嵌入模型按语义查找段落。BM25 按精确词汇查找。每个返回各自的前 20 条。

Reciprocal Rank Fusion 将它们合并成一个 20 条候选的列表。

交叉编码器（cross-encoder）重新排序。它把问题和每个段落一起读取，只有前 5 条通过。

DeepSeek 用这 5 个片段、聊天历史和长期记忆来撰写答案。

为什么要两个搜索？向量搜索理解语义，但在精确内容上弱——比如价格、邮箱、电话号码。问"Pro 方案多少钱？"它可能返回一段讲定价策略的好话，而不是带具体数字的那条。BM25 恰恰相反。两者合在一起互补，对于固定事实类问题，混合搜索明显优于单独使用向量搜索。

Bot 何时放弃

这里有两个触发器，而且我有意用不同方式实现。

1. 客户明显不高兴了（由 LLM 检查）

每条消息都会以一个严格 prompt 发给 DeepSeek API，回复必须是 JSON 格式，包含一个标签和 -1.0 到 1.0 的分数：

Rules:
- negative: customer is CLEARLY angry, frustrated, or complaining
- neutral: casual phrases, short responses, confusion, greetings
- positive: happy, satisfied, thankful

"oh no" → neutral
"wtf" → neutral (not clearly angry enough)
"this is terrible I want a refund NOW" → negative

Reply ONLY with JSON: {"label": ..., "score": ...}

这些示例才是让这套机制生效的关键。人们会随口说"oh no"和"wtf"，所以它们算中立。只有明确的愤怒才算负面。

一条愤怒消息不会触发任何操作。Bot 需要连续三条负面消息才会升级，所以冷静下来的客户不会因为早期的坏情绪而受罚。

2. 客户要求人工（纯代码，不用 LLM）

def wants_human(text: str) -> bool:
    text = text.lower()
    return any(p in text for p in HUMAN_REQUEST_PHRASES)

# "talk to a human", "real person", "live agent", ...

如果消息中包含"talk to a human"或"real person"这样的短语，Bot 立即升级。要调用 API 来理解"I want a human"既费钱又费时间，所以一个简单的短语列表免费搞定。

这成了我的主要原则：需要判断时用 LLM，规则清晰时用纯代码。