通用 AI 客服机器人的问题在于"不懂你的业务"。客户问"你们的 SaaS 专业版支持 SSO 吗"，通用模型只能说"建议咨询客服"。专属智能客服的价值就在这里——接了你的知识库，能直接答。这篇讲怎么从零打造一个企业专属的智能客服机器人。

一、专属和通用的区别

先搞清楚"专属"专属在哪：

维度	通用 AI 客服	专属 AI 客服
知识来源	通用训练数据	企业知识库
回复风格	通用语气	企业品牌语气
能力边界	什么都想答	只答能力范围内
数据安全	数据出企业	可控（本地部署/私有 API）
持续优化	靠模型升级	靠知识库和 prompt 调优

专属不是技术上多复杂，是数据和约束上多了一层。多出来的工作量在知识库建设和质量管控上，不在模型调用上。

二、知识库的构建

专属客服的核心是知识库。知识库不是把公司文档一股脑丢进去，要经过加工：

知识切片。一个大文档拆成小段落，每段一个知识点。切片太大检索不准、太小信息不全。建议每段 200-500 字，一个问答对应一个切片。

结构化标注。每个切片打标签：产品名、功能模块、适用版本。检索时按标签过滤，比纯语义检索准。客户问"专业版 SSO"，先按标签过滤到"专业版"的切片，再语义检索，比全库检索噪音少很多。

问答对形式。知识库不只有文档切片，最好还有标准问答对——"客户问什么→标准答什么"。问答对的检索准确率比文档切片高，因为问题和客户消息的语义更接近。

# 知识库结构
KNOWLEDGE = {
    "documents": [
        {"id": "doc_001", "product": "专业版", "module": "SSO",
         "content": "专业版支持 SSO 单点登录，需配置 SAML 2.0..."}
    ],
    "qa_pairs": [
        {"id": "qa_001", "product": "专业版", "question": "支持SSO吗",
         "answer": "专业版支持 SSO 单点登录，支持 SAML 2.0 和 OAuth 2.0 协议。配置路径：管理后台→安全设置→单点登录。"}
    ]
}

定期更新。产品迭代后知识库要同步更新。过时的知识比没有知识更危险——模型基于过时信息给错误回复。建议每两周做一次知识库巡检，标记和更新过期内容。

三、检索增强生成（RAG）

知识库建好后，用 RAG 让模型基于知识库回复：

def generate_reply(msg, session):
    # 1. 检索知识库
    docs = retrieve_knowledge(msg, session, top_k=3)
    if not docs:
        return transfer_human(session, "知识库未覆盖")
    
    # 2. 组装prompt
    prompt = f"""基于以下知识回答客户问题。
    如果知识中没有相关信息，说"这个问题我需要转人工确认"，不要编造。
    
    知识：
    {format_docs(docs)}
    
    客户问题：{msg}
    
    回复（不超过150字）："""
    
    # 3. 调模型
    reply = llm.generate(prompt)
    
    # 4. 质量检查
    if not quality_check(reply, docs):
        return transfer_human(session, "AI回复质量不足")
    
    return reply

几个关键设计：

检索策略。混合检索比纯语义好：先关键词过滤缩小范围，再语义检索排序。纯语义检索在知识量大时噪音多，关键词过滤先挡一道。

prompt 约束。明确告诉模型"知识里没有就说不知道"，别让它自由发挥。模型最大的风险是"编着答"，客户以为是真的事实，出了问题要追责。

回复长度限制。企微里没人愿意看长消息，限制 150 字以内。让模型学会精炼，而不是把检索到的知识全贴上去。

四、多轮对话的上下文管理

客户问题经常是多轮的："你们专业版多少钱"→"含实施费吗"→"能优惠吗"。第二轮"含实施费吗"脱离了上下文就没意义。

上下文管理的设计：

def generate_reply_with_context(msg, session):
    # 检索时带上会话历史
    context_msg = f"之前的对话：{session.last_3_messages()}\n当前问题：{msg}"
    docs = retrieve_knowledge(context_msg, top_k=3)
    
    prompt = f"""对话历史：
    {format_history(session.last_3_messages())}
    
    知识：
    {format_docs(docs)}
    
    客户最新消息：{msg}
    回复（不超过150字）："""
    
    return llm.generate(prompt)

上下文窗口控制 3-5 轮。超过的做摘要压缩——让模型把前 5 轮总结成一句话，放到上下文里。既保持记忆又控制 token 成本。

五、人机协同的边界

专属客服不是要替掉人工，是做"AI 先挡、人工兜底"的协同。边界设计：

AI 能答的：知识库覆盖的、事实型问题、高频标准问题。这类直接 AI 回。

AI 答不了的：知识库没覆盖的、涉及具体客户数据的（"我的账户余额"）、主观判断类（"适不适合我"）。这类转人工。

灰区：AI 有一定把握但不确定的。让 AI 先答，同时给客户一个"转人工"的选项。客户不满意可以一键转。

转人工时要带上上下文：这个客户之前问了什么、AI 答了什么、为什么转。客服接手时不用重问，直接接着聊。

六、持续优化机制

专属客服上线不是结束，是起点。优化机制：

• 收集"AI答不了"的问题。转人工的问题每周分析一次，高频的补进知识库

• 质检 AI 回复。每天抽 5% 人工评分，不合格的改进 prompt 或补充知识

• A/B 测试。知识库切片策略、prompt 措辞、检索参数，做 A/B 看哪个效果好

• 客户反馈。AI 回复后让客户点"有帮助/没帮助"，"没帮助"的记下来分析

七、上线前要验证的

专属客服上线前，用 100 条真实客户问题做一次评估：

• AI 回复的可用率：直接可用 / 需修改后可用 / 不可用

• 知识库覆盖率：100 条问题里多少知识库能检索到相关内容

• 转人工率：多少问题 AI 处理不了要转

可用率 60% 以上、覆盖率 70% 以上、转人工率 30% 以下，可以上线。达不到就先补知识库，别硬上线丢人。

接口对接在开发文档里有说明，先在Eyun平台开测试期验证链路。

写在最后

专属智能客服的价值不在"AI 多聪明"，在"知识库多扎实"。知识库建好、检索做准、prompt 约束住、质量兜底到位——四层保障做到位，专属客服才真正能替人挡活。这四层缺任何一层，AI 都可能闯祸。