【实践教程】真实AI客服落地全流程：意图识别、混合检索到数据飞轮

书接上文：《实践：AI客服实战方法论》

之前我们详细介绍了空气小猪 AI 客服是如何一步步做出来的，但后续无论学员还是粉丝都依旧有很多的问题，所以最近几天我们在连续做 RAG 的课题。

今天的话，我们会上点更硬的货，会结合空气小猪这个案例，讲清楚我们如何从 0 到 1 搭建一套 AI 客服，包括：

1. 为什么值得做
2. 目标边界如何确定
3. 如何选择技术路线
4. 如何知识整理
5. 怎么做意图识别
6. 选择什么检索策略
7. 如何观测全链路
8. 以及怎样设计数据飞轮系统

为什么值得做？

AI 客服是一直企业降本增效的刚需，我们的创业产品空气小猪也不例外，从上线之后，客服工作一直是创始人在做。

一开始没啥问题也是必须的，毕竟产品刚上线，需要了解用户哪里用得不爽、卡点在哪里，收集用户的真实反馈以便优化。

但时间一长，问题就出来了。客服工作每天消耗他 2-3 小时的时间，这种状态持续了半年多，占用了大量时间。

对我们这种小团队来说，这个成本不小，而且创始人的时间应该更多放在产品方向、功能设计、用户增长上。

到这里就有小伙伴好奇了：既然你们本身就对 AI 那么熟悉，为什么不一开始就上 AI 客服，而还要等这么久？

原因很简单，初期我们没有优质语料，也是在这半年多的时间里，沉淀了大量真实、高质量的对话语料，这为我们提供了很宝贵的数据基础。

有了这些背景，我们才开始认真考虑做 AI 客服

换个说法，没有很好的数据基础，是没办法做好 AI 客服的，并不是所有客服场景都适合一上来就做 AI 客服。

如果产品问题强依赖人工判断、涉及复杂售后和权益处理，这些场景接入AI客服，风险会很高。而空气小猪这个场景比较适合，主要有几个原因：

一、问题重复度高

新用户进来问的问题虽有差异，但大多集中在产品定位、功能使用、学习效果、账号登录、推送、翻译、社交关系这些范围内。只要知识整理得好，大部分问题都能被覆盖。

二、历史语料质量高

过去半年多都是创始人在回复用户，这批客服记录本身就是高质量知识来源。里面不只有标准答案，还有很多对用户疑惑的解释方式。这比从零开始写 FAQ 要有价值很多。

三、产品理念需要被反复解释

空气小猪的产品理念比较反主流，甚至是超前的，很多用户会带着传统语言学习软件的预期来看它，所以客服里有大量解释产品为什么这样做的工作

四、反馈对产品迭代很重要

用户在客服里提到的故障、建议、困惑，本身就是产品迭代的重要输入。

如果依靠人工回复、反馈、然后记录这种方式，这些信息很容易被漏掉，而AI 客服可以顺手把这些信息结构化收集起来。

换句话说：初期产品一定要由一号位做客服，可以收集到很多信息，这些都是后续迭代的重要材料

明确目标和边界

在做之前，首先我们要明确这个AI客服的目标边界，能做什么、不能做什么，这个一定要先定好。

比如，要做的事情：

1. 用户问产品问题时，能基于已有知识给出准确回答
2. 用户反馈故障时，能把问题收集完整，并记录到后台
3. 用户提出建议时，能判断这个建议是否符合产品方向，如果不符合则拒绝，符合则记录
4. 用户闲聊时，能保持自然互动，不要太冰冷
5. 问题回答不上来时，要把这个问题记录下来，后续补充知识

既然有能做要做的事，就一定有不做的事情：

1. 不处理任何数据库操作等高风险事项
2. 不做任何用户承诺，比如某个功能一定会做，用了我们产品一定会怎样
3. 不强行回答用户问题，比如知识不足时，就不回答。
4. …..

AI 客服，最致命的就是一本正经的胡说八道，这会直接影响用户对这个产品的印象，甚至产生错误的引导，所以宁可让它少答，也不能让它乱答。

可控性是核心

技术方案我们考虑过两个选择，一个是直接使用智能体开发平台，比如 Dify、Coze、FastGPT、n8n 这一类工具，另一个是自己做工程化代码开发。

从结果上看，两种方式都能做出一个 AI 客服。尤其是 Dify，能力比较均衡，工作流、知识库、模型接入、企业应用开发都做得比较完整。如果只是快速验证，Dify 是一个很不错的选择。

但是最终我们没有选择Dify，而是用了工程化方案，主要是基于以下几个方面考虑：

一、不只是对错

做AI 客服不仅要看最后答得对不对，还要看回答之前每个关键环节是否正确：比如问题怎么改写、意图识别是否正确、召回了哪些知识、排序为什么这样排、哪些内容被拼进上下文、低置信度怎么判断、后续怎么补知识。

如果使用Dify，很难完全掌控…

二、检索复杂度

我们对知识库检索能力有较高要求，希望在召回策略、排序逻辑、上下文拼接等环节进行深度优化。

这部分是 AI 客服的核心能力，我们更希望逻辑完全自主可控。

三、成本问题

私有化部署也需要额外的服务器的成本和运维成本，对我们当前阶段而言是没有必要的。

四、效率问题

在实际测试中，我们发现 Dify 的执行链路相对较长，尤其在知识检索节点，整体响应时间偏长，不完全符合我们对实时性的要求。

五、定制化问题

真正接入业务数据库、后台管理、反馈系统时，还是需要写不少定制代码

在AI Coding的加持下，使用工程化代码实现的难度和成本其实大大降低了，远没有想象的那么复杂。

而且好处也很直接：检索、排序、上下文、日志、数据飞轮这些核心环节都能自己控制。

PS：其实从这里也可以看出了，AI Coding 对 Coze、Dify、n8n 等的伤害真的很大

另一个架构选择是采用 Workflow 还是 Agent？

Agent 的优势是自主性更强，可以自己规划步骤、调用工具、判断下一步动作。但客服系统不是一个适合一开始就完全交给 Agent 的场景，客服回答需要稳定、可解释、可复盘，不能让模型自由发挥太多。

所以第一版我们采用更稳妥的 Workflow 方式：每一步做什么、输入是什么、输出是什么、失败时怎么处理，都由系统显式控制。

这种设计牺牲了一部分Agent的自主性，但换来了更强的确定性和更低的生产风险。从现在复盘来看，我们当时采取的决策是很正确的，先追求稳定可控、再谈自主。

整体流程及功能设计

接下来进入具体的流程设计了，也是大家比较关心的问题，很多同学一旦涉及到怎么做就一头雾水了。如果把 AI 客服压缩成一句话，它的链路是这样的：

用户发来一句话，系统先理解这句话到底在问什么，再判断它属于哪类问题，然后检索相关知识，最后在知识约束下生成回答，同时把整个过程记录下来

真正做系统实现时，这条链路会拆成若干个功能节点，整个系统链路大概是这样：

知识入库链路则是另一条离线链路：

从功能上看，可以拆成四个部分：

1. 用户端客服，负责接收消息和展示回答
2. 知识库系统，负责知识整理、入库、向量化和检索
3. 问答工作流，负责编排模型调用和业务逻辑
4. 后台管理系统，负责链路追踪、系统观测、提示词维护、问题审核、建议反馈展现

技术栈选择

方案的核心技术栈如下：

这里选择 FAISS 的原因很简单：轻量、成熟、部署成本低，足够支撑当前阶段的知识检索需求；业务数据则放在 MySQL 中，保证知识原文、分类、状态、向量 ID、审核信息等字段都可以结构化管理。

这套架构也保留了后续替换空间。FAISS 只负责向量存储和相似度检索，业务数据不和向量库强绑定。未来如果数据规模或检索需求变化，可以替换为 Milvus、Weaviate、pgvector 等方案，而不需要重构业务数据模型。

第一步：意图识别

意图分类至关重要，它是整个逻辑链路的第一步，如果这步出错，后面将全错。

用户的问题是无限发散的，但是系统一定要有边界，那我们就要对用户的意图做收敛，收敛的目的是为了匹配到我们有限的知识和预先设计的流程。

一开始我们只把意图分成产品咨询和闲聊，后面发现不够。

真实客服里有大量反馈类问题：功能异常、打不开、卡顿、收不到通知、希望增加某个功能、觉得某个体验不顺。这些内容不能只回答一句就结束，它们应该进入后台，变成产品和技术团队可以处理的数据。

所以后来我们把一级意图扩展为三类：

三类意图对应的处理逻辑完全不同，产品咨询要走 RAG，需要检索知识库并基于知识回答；用户反馈要判断功能是否已存在、是故障还是建议，并写入业务数据库；闲聊则不走知识库检索，而是需要利用大模型自然、有温度地回应。

这里有一个很重要的实践经验：意图分类不要只给模型三个标签，标签太粗，模型很容易误判。我们需要给每个一级意图补充二级意图和判断标准，让模型知道什么情况下应该归到哪个意图。

我们从两个角度进行了意图梳理：

1. 从产品本身出发，梳理出我们提供了什么、主要解决什么问题
2. 从用户视角出发，梳理用户最关心什么、经常问什么、容易误解什么。

然后进行了融合，整理出的高频意图如下：

一级意图有了评判标准，这样意图识别就非常准确了。具体提示词大致如下：

## 角色
空气小猪App智能客服意图识别器

## 任务
结合对话历史，将用户问题分类为以下意图之一，并按照顺序依次判断：
1. **SUPPORT(产品咨询)** , 判断标准为 {
    产品定位、价格、数据安全.....
}
2. **FEEDBACK(问题反馈)**, 判断标准为 {
  故障、功能、优化.....
}
3. **CHAT(闲聊)**，判断标准为 {
  当不属于以上两类时，一律归为 CHAT，例如问候、寒暄、玩笑、调侃、情感倾诉、模糊无意义输入
}

## 输入

<对话历史>
....
</对话历史>

<用户问题>
....
</用户问题>

## 输出（严格JSON，无其他文本）
```json
{
  "confidence": 0.0-1.0,
  "intent": "SUPPORT" | "FEEDBACK" | "CHAT",
  "reason": "分类理由（含上下文影响）"
}

模型选择上，我们最初用 GPT-4.1 做效果标杆，然后测试 Qwen-plus-latest、Qwen-max-latest、Qwen3-max 和 Qwen-plus。最后综合成本、速度和准确率，意图识别主要使用 Qwen-plus。

如果项目初期不确定提示词是否可靠，可以先用更强模型把流程跑通。等分类标准稳定以后，再换成更低成本的模型，这样更稳。

知识如何整理？

知识是RAG项目的灵魂，唯有提供优质知识才能让AI输出优质的回答，否则不管我们做再多的工程化优化都是无用功，最终结果就是垃圾进垃圾出。

除了知识质量外，知识被正确的分块也非常重要，在知识整理的时候，我们就需要考虑如何组织知识才能被更好的分块，保证每个块的语义是独立完整的。

我们这里采用 Markdown 来整理知识，Markdown 的标题层级天然适合表达知识结构，非常方便后续按照标题进行切分。

空气小猪的知识来源主要有两部分：

1. 第一部分是人工整理的产品知识。包括产品定位、核心理念、功能说明、使用场景、价格、数据安全、哪些功能会做、哪些功能明确不做。
2. 第二部分是历史客服记录。这里面有大量真实用户问法，也有创始人过去的真实回答。

这两部分需要结合起来看，人工整理的知识更系统，但不一定覆盖用户真实表达；历史客服记录更贴近真实，但内容比较散，需要清洗和去重二次整理。

知识内容大致形式如下：

另一方面，我们导出了所有历史客服对话数据，这里主要根据会话维度进行分析，因为数据较多，不太可能人工整理，因此借助AI分析提取每个会话中有效的问答记录。

当然这里也不能一次性把所有的数据给到大模型整理，有两个原因：一是数据太多会超出大模型上下文限制，二是数据太多，幻觉增加，准确率会降低。

处理的策略是拆分为多个批次进行整理，比如每个10个会话为一个批次，再通过 Coze 工作流批量提取有效问答对，提取后的结果写入飞书多维表格，再进行去重、合并和人工校验。

通过这两种方式，我们就得到了最终的产品知识数据，这一步非常重要，也非常耗费精力，并且需要真正懂这个产品的人来做才能取得好的效果。

检索策略优化

做 RAG，会自然想到向量检索：把用户问题向量化，再去知识库里找相似内容，但在客服场景里，只做向量检索不够。

原因是用户问题里经常有明确关键词，比如Memo 词卡、播客模式、小猪伴聊、免打扰、语音播放等。这种情况下，向量检索就会把看起来语义相近，实际不是一个功能的知识召回来。

所以我们用了混合检索：向量检索 + BM25。

向量检索解决表达差异，比如“对英语有没有帮助”和“能不能提升英语能力”，关键词不完全一样，但语义接近。

BM25 解决关键词命中，比如用户明确问 Memo 词卡，BM25 很容易把包含 Memo 词卡的知识找出来。

这部分我们当前用的是 LangChain 的 BM25Retriever：

bm25_retriever = BM25Retriever.from_documents(splitsDoc)
bm25_retriever.k = 3
bm25_docs = bm25_retriever.invoke(query)

这个方案足够轻量，适合当前阶段，如果后面知识规模变大，再考虑换成更专业的搜索引擎。

为了提升知识召回率，我们还会对用户问题做多路改写。

比如用户问：

这个 app 到底对学英语有没有用？

系统会改写成几条更适合检索的问题：

空气小猪对英语学习有什么帮助？
空气小猪如何提升英语能力？
空气小猪适合什么英语学习场景？
空气小猪和传统英语学习方式有什么不同？
空气小猪的核心学习价值是什么？

然后每条问题分别走向量检索和 BM25 检索，这样会得到一批候选结果，但候选结果还不能直接用。因为多路检索之后，结果会比较多，也会有重复和弱相关内容。

那我们应该如何处理呢？

首先会对相同检索方式的结果使用RRF进行合并，得到两类候选结果，分别为向量检索结果、BM25检索结果，由于混合检索后的查找范围很大，单纯依赖原始相似度分数难以直接过滤结果，因此需要引入重排模型进行精细排序。

重排模型（reranker）对候选结果重新评分，并根据相关度重新排序，绝大多数情况下，可以有效提高搜索结果的准确率。

重排后可以得到一个0-1得分，代表着搜索内容与问题的相关度，该分数通常比向量的得分更加精确，可以根据得分进行过滤。

最后使用 RRF 对重排结果、向量搜索结果、BM25检索结果进行合并，得到最终的搜索结果。

生成回答时

检索出知识之后，并不是直接把知识丢给模型让它自由回答，我们在生成阶段做了比较强的约束。

产品咨询类问题的原则是：所有回答必须在知识中有依据，宁可不答，也不要错答。

所以提示词里有一个很关键的字段：useful。

模型需要判断召回的知识是否真的能回答用户问题。如果可以，就 useful=true，正常回答。如果知识不相关，或者不足以回答，就 useful=false，回复用户暂时不能回答。

这个设计看起来只是多了一个字段，但实际很重要。

因为检索结果永远不可能百分百准确。哪怕召回了 TopK，也可能只是弱相关。如果不让模型再次判断知识是否可用，它很容易基于一点点相关内容硬编。

我们希望客服系统有一个基本底线：不知道就是不知道。产品咨询的输出大致是：

{
  "useful": true,
  "content": "空气小猪主要通过真实聊天内容帮你建立外语环境，让学习更贴近日常，而不是额外增加刷题任务。",
  "translation": "..."
}

如果是 useful=false，这条问题还会进入低置信度问题池，后续用于补充知识库。

对话上下文管理

AI客服是连续多轮对话，不是单轮问答。

因此，每次让调用大模型，我们除了把用户最新的消息传进去之外，还需要把历史会话消息传递进去，这样才能确保大模型理解对话上下文。

那么问题来了，应该携带多少条历史消息合适呢？太少的话会大概率会丢失上下文信息，大模型回答会偏；携带太多，速度会慢、token消耗会变大，干扰信息太多还会产生幻觉。

我们这里也做了一个策略，对记忆进行了分层，分为短期记忆和长期记忆。

短期记忆就是最近 N 条原始消息，保持原样，不压缩，保证当前对话的连续性。长期记忆是把更早的对话异步压缩成摘要，存到业务数据库里，比如每满 50 条消息生成一条摘要，后续再按需携带最近几条摘要即可。

摘要里只保留事实和诉求，比如用户关心什么、遇到什么问题、已经提供过哪些信息、还有什么未解决。

通过这种策略，在成本和上下文完整性之间取得一个平衡。

我们在让大模型做意图识别、问题改写以及回答问题时，我们携带的消息上下文构成如下：

当然除了上面这种按照固定条数进行压缩之外，我们也可以根据达到一定的token数量才进行压缩。这里根据具体场景进行选择。

全链路可观测

AI 客服最难调的地方，是它看起来答了，但答得不对。

传统系统出问题，可能会报异常、状态码错误、数据库写入失败。AI 客服系统出问题，却是另一种形态，可能是意图识别错了、问题改写偏了、知识召回不足、或者召回的知识根本不相关、提示词不正确等等。

如果只看最终回答，很难知道问题出在哪，所以我们把全链路的关键节点日志都记录下来：

1. 用户原始消息；
2. 指代消解后的问题；
3. 意图识别结果和理由；
4. 问题改写结果；
5. 向量召回列表和分数；
6. BM25 召回列表；
7. Reranker 重排结果；
8. 最终使用的知识；
9. 生成回答和 useful 判断；
10. 每次模型调用的耗时和成本；

在后台管理系统中，可以看到全流程关键节点的输入和输出信息，可以直观地观测整个 AI 客服的运行状态。

当用户反馈回答不准，我们可以回头看：到底是意图识别错了，还是召回没召到，还是知识本身缺了，还是模型没有按知识回答。

这些问题对应的优化方向完全不同，没有这些日志，就只能靠猜。

数据飞轮

数据飞轮本质上是一种持续反馈的闭环机制：

通过从用户交互中不断收集数据 → 处理 → 优化 → 再反哺系统 让 AI 在真实业务中越用越准

我们初始知识库一定是不完整的，哪怕我们已经整理了人工知识，也处理了历史客服记录，真实用户还是会问出很多知识库没有覆盖的问题。

所以从第一版开始，我们就设计了低置信度问题池。当召回分数低于阈值，或者生成阶段返回 useful=false，这条问题就会进入低置信度池。

但这里有一个原则：不是所有问题都应该进知识库。

用户随便发一句情绪、一个无意义输入、一个极低频问题、一个强时效问题，都不适合沉淀成正式知识。如果全部自动入库，知识库很快就会变脏。

所以低置信度问题进入后台之后，先做问题标准化。

比如用户原话是：

我在日本，用 +81 的手机号能不能注册啊？不行我就换国内的

标准化之后应该是：

国外手机号是否支持注册空气小猪账号？

这个过程会去掉情绪、口语和无关信息，只保留真实意图，利于后续知识检索。

同时系统会判断它是否和已有低置信度问题相似。如果多个用户都在问同一个问题，就合并到同一个标准问题下面，并记录出现次数，根据出现次数判断这个问题是否高频，是否是需要即时补足。

后台审核时，人工也会再次判断：

1. 这是不是正常业务问题；
2. 现有知识库是否其实已经覆盖；
3. 是不是垃圾信息或无意义输入；
4. 是否低频到不值得沉淀；
5. 是否需要补充成正式 FAQ；
6. AI 给出的初步答案是否可靠。

审核通过之后，再由人工补充正式答案，重新走知识入库和向量化流程。

这样下一次用户问类似问题时，系统就能命中新知识，这就是数据飞轮。

结语

做完这个项目之后，对我比较重要的几个启发：

1. 明确系统边界，能做什么，不能做什么，AI客服的原则是：宁可不答也不要错答
2. RAG 的核心是知识工程，这块不能偷懒
3. 建立观测基础设施和知识迭代机制对持续运营和优化至关重要

以上就是我们做一个简单 AI 客服，整体实践的心路历程（除了最核心的部分，应该都差不多了），希望大家对有所启发，肯定有不足之处，望大家指正。