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

之前我们详细介绍了空气小猪 AI 客服是如何一步步做出来的但后续无论学员还是粉丝都依旧有很多的问题所以最近几天我们在连续做 RAG 的课题。今天的话我们会上点更硬的货会结合空气小猪这个案例讲清楚我们如何从 0 到 1 搭建一套 AI 客服包括为什么值得做目标边界如何确定如何选择技术路线如何知识整理怎么做意图识别选择什么检索策略如何观测全链路以及怎样设计数据飞轮系统为什么值得做AI 客服是一直企业降本增效的刚需我们的创业产品空气小猪也不例外从上线之后客服工作一直是创始人在做。一开始没啥问题也是必须的毕竟产品刚上线需要了解用户哪里用得不爽、卡点在哪里收集用户的真实反馈以便优化。但时间一长问题就出来了。客服工作每天消耗他 2-3 小时的时间这种状态持续了半年多占用了大量时间。对我们这种小团队来说这个成本不小而且创始人的时间应该更多放在产品方向、功能设计、用户增长上。到这里就有小伙伴好奇了既然你们本身就对 AI 那么熟悉为什么不一开始就上 AI 客服而还要等这么久原因很简单初期我们没有优质语料也是在这半年多的时间里沉淀了大量真实、高质量的对话语料这为我们提供了很宝贵的数据基础。有了这些背景我们才开始认真考虑做 AI 客服换个说法没有很好的数据基础是没办法做好 AI 客服的并不是所有客服场景都适合一上来就做 AI 客服。如果产品问题强依赖人工判断、涉及复杂售后和权益处理这些场景接入AI客服风险会很高。而空气小猪这个场景比较适合主要有几个原因一、问题重复度高新用户进来问的问题虽有差异但大多集中在产品定位、功能使用、学习效果、账号登录、推送、翻译、社交关系这些范围内。只要知识整理得好大部分问题都能被覆盖。二、历史语料质量高过去半年多都是创始人在回复用户这批客服记录本身就是高质量知识来源。里面不只有标准答案还有很多对用户疑惑的解释方式。这比从零开始写 FAQ 要有价值很多。三、产品理念需要被反复解释空气小猪的产品理念比较反主流甚至是超前的很多用户会带着传统语言学习软件的预期来看它所以客服里有大量解释产品为什么这样做的工作四、反馈对产品迭代很重要用户在客服里提到的故障、建议、困惑本身就是产品迭代的重要输入。如果依靠人工回复、反馈、然后记录这种方式这些信息很容易被漏掉而AI 客服可以顺手把这些信息结构化收集起来。换句话说初期产品一定要由一号位做客服可以收集到很多信息这些都是后续迭代的重要材料明确目标和边界在做之前首先我们要明确这个AI客服的目标边界能做什么、不能做什么这个一定要先定好。比如要做的事情用户问产品问题时能基于已有知识给出准确回答用户反馈故障时能把问题收集完整并记录到后台用户提出建议时能判断这个建议是否符合产品方向如果不符合则拒绝符合则记录用户闲聊时能保持自然互动不要太冰冷问题回答不上来时要把这个问题记录下来后续补充知识既然有能做要做的事就一定有不做的事情不处理任何数据库操作等高风险事项不做任何用户承诺比如某个功能一定会做用了我们产品一定会怎样不强行回答用户问题比如知识不足时就不回答。…AI 客服最致命的就是一本正经的胡说八道这会直接影响用户对这个产品的印象甚至产生错误的引导所以宁可让它少答也不能让它乱答。可控性是核心技术方案我们考虑过两个选择一个是直接使用智能体开发平台比如 Dify、Coze、FastGPT、n8n 这一类工具另一个是自己做工程化代码开发。从结果上看两种方式都能做出一个 AI 客服。尤其是 Dify能力比较均衡工作流、知识库、模型接入、企业应用开发都做得比较完整。如果只是快速验证Dify 是一个很不错的选择。但是最终我们没有选择Dify而是用了工程化方案主要是基于以下几个方面考虑一、不只是对错做AI 客服不仅要看最后答得对不对还要看回答之前每个关键环节是否正确比如问题怎么改写、意图识别是否正确、召回了哪些知识、排序为什么这样排、哪些内容被拼进上下文、低置信度怎么判断、后续怎么补知识。如果使用Dify很难完全掌控…二、检索复杂度我们对知识库检索能力有较高要求希望在召回策略、排序逻辑、上下文拼接等环节进行深度优化。这部分是 AI 客服的核心能力我们更希望逻辑完全自主可控。三、成本问题私有化部署也需要额外的服务器的成本和运维成本对我们当前阶段而言是没有必要的。四、效率问题在实际测试中我们发现 Dify 的执行链路相对较长尤其在知识检索节点整体响应时间偏长不完全符合我们对实时性的要求。五、定制化问题真正接入业务数据库、后台管理、反馈系统时还是需要写不少定制代码在AI Coding的加持下使用工程化代码实现的难度和成本其实大大降低了远没有想象的那么复杂。而且好处也很直接检索、排序、上下文、日志、数据飞轮这些核心环节都能自己控制。PS其实从这里也可以看出了AI Coding 对 Coze、Dify、n8n 等的伤害真的很大另一个架构选择是采用 Workflow 还是 AgentAgent 的优势是自主性更强可以自己规划步骤、调用工具、判断下一步动作。但客服系统不是一个适合一开始就完全交给 Agent 的场景客服回答需要稳定、可解释、可复盘不能让模型自由发挥太多。所以第一版我们采用更稳妥的 Workflow 方式每一步做什么、输入是什么、输出是什么、失败时怎么处理都由系统显式控制。这种设计牺牲了一部分Agent的自主性但换来了更强的确定性和更低的生产风险。从现在复盘来看我们当时采取的决策是很正确的先追求稳定可控、再谈自主。整体流程及功能设计接下来进入具体的流程设计了也是大家比较关心的问题很多同学一旦涉及到怎么做就一头雾水了。如果把 AI 客服压缩成一句话它的链路是这样的用户发来一句话系统先理解这句话到底在问什么再判断它属于哪类问题然后检索相关知识最后在知识约束下生成回答同时把整个过程记录下来真正做系统实现时这条链路会拆成若干个功能节点整个系统链路大概是这样知识入库链路则是另一条离线链路从功能上看可以拆成四个部分用户端客服负责接收消息和展示回答知识库系统负责知识整理、入库、向量化和检索问答工作流负责编排模型调用和业务逻辑后台管理系统负责链路追踪、系统观测、提示词维护、问题审核、建议反馈展现技术栈选择方案的核心技术栈如下模块选型服务开发Python FastAPI向量检索FAISS业务数据存储MySQLEmbedding 模型Qwen text-embedding-v4全文检索BM25多路结果融合RRF候选结果重排Reranker意图识别与回答生成Qwen-plus 为主GPT-4.1/Qwen3-max 作为效果参考这里选择 FAISS 的原因很简单轻量、成熟、部署成本低足够支撑当前阶段的知识检索需求业务数据则放在 MySQL 中保证知识原文、分类、状态、向量 ID、审核信息等字段都可以结构化管理。这套架构也保留了后续替换空间。FAISS 只负责向量存储和相似度检索业务数据不和向量库强绑定。未来如果数据规模或检索需求变化可以替换为 Milvus、Weaviate、pgvector 等方案而不需要重构业务数据模型。第一步意图识别意图分类至关重要它是整个逻辑链路的第一步如果这步出错后面将全错。用户的问题是无限发散的但是系统一定要有边界那我们就要对用户的意图做收敛收敛的目的是为了匹配到我们有限的知识和预先设计的流程。一开始我们只把意图分成产品咨询和闲聊后面发现不够。真实客服里有大量反馈类问题功能异常、打不开、卡顿、收不到通知、希望增加某个功能、觉得某个体验不顺。这些内容不能只回答一句就结束它们应该进入后台变成产品和技术团队可以处理的数据。所以后来我们把一级意图扩展为三类意图处理方式产品咨询回答用户关于产品定位、使用方式、价格、功能、学习效果等问题用户反馈处理故障报告、功能建议、体验优化建议并结构化入库闲聊处理问候、寒暄、轻松交流同时保持产品人格和陪伴感三类意图对应的处理逻辑完全不同产品咨询要走 RAG需要检索知识库并基于知识回答用户反馈要判断功能是否已存在、是故障还是建议并写入业务数据库闲聊则不走知识库检索而是需要利用大模型自然、有温度地回应。这里有一个很重要的实践经验意图分类不要只给模型三个标签标签太粗模型很容易误判。我们需要给每个一级意图补充二级意图和判断标准让模型知道什么情况下应该归到哪个意图。我们从两个角度进行了意图梳理从产品本身出发梳理出我们提供了什么、主要解决什么问题从用户视角出发梳理用户最关心什么、经常问什么、容易误解什么。然后进行了融合整理出的高频意图如下一级意图二级分类产品咨询产品定位产品原则产品理念使用场景产品价格竟品比较产品功效用户账号、登录消息推送、免打扰下载安装、版本更新支持平台数据安全添加好友单聊\群聊播客模式兴趣设置、好友推荐语音播放翻译、语种小猪伴聊、AI智能体对话小猪客服Memo词卡用户反馈故障报告增加功能体验优化闲聊一级意图有了评判标准这样意图识别就非常准确了。具体提示词大致如下## 角色空气小猪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 的标题层级天然适合表达知识结构非常方便后续按照标题进行切分。空气小猪的知识来源主要有两部分第一部分是人工整理的产品知识。包括产品定位、核心理念、功能说明、使用场景、价格、数据安全、哪些功能会做、哪些功能明确不做。第二部分是历史客服记录。这里面有大量真实用户问法也有创始人过去的真实回答。这两部分需要结合起来看人工整理的知识更系统但不一定覆盖用户真实表达历史客服记录更贴近真实但内容比较散需要清洗和去重二次整理。知识内容大致形式如下另一方面我们导出了所有历史客服对话数据这里主要根据会话维度进行分析因为数据较多不太可能人工整理因此借助AI分析提取每个会话中有效的问答记录。当然这里也不能一次性把所有的数据给到大模型整理有两个原因一是数据太多会超出大模型上下文限制二是数据太多幻觉增加准确率会降低。处理的策略是拆分为多个批次进行整理比如每个10个会话为一个批次再通过 Coze 工作流批量提取有效问答对提取后的结果写入飞书多维表格再进行去重、合并和人工校验。通过这两种方式我们就得到了最终的产品知识数据这一步非常重要也非常耗费精力并且需要真正懂这个产品的人来做才能取得好的效果。检索策略优化做 RAG会自然想到向量检索把用户问题向量化再去知识库里找相似内容但在客服场景里只做向量检索不够。原因是用户问题里经常有明确关键词比如Memo 词卡、播客模式、小猪伴聊、免打扰、语音播放等。这种情况下向量检索就会把看起来语义相近实际不是一个功能的知识召回来。所以我们用了混合检索向量检索 BM25。向量检索解决表达差异比如“对英语有没有帮助”和“能不能提升英语能力”关键词不完全一样但语义接近。BM25 解决关键词命中比如用户明确问 Memo 词卡BM25 很容易把包含 Memo 词卡的知识找出来。这部分我们当前用的是 LangChain 的BM25Retrieverbm25_retriever BM25Retriever.from_documents(splitsDoc)bm25_retriever.k 3bm25_docs bm25_retriever.invoke(query)这个方案足够轻量适合当前阶段如果后面知识规模变大再考虑换成更专业的搜索引擎。为了提升知识召回率我们还会对用户问题做多路改写。比如用户问这个 app 到底对学英语有没有用系统会改写成几条更适合检索的问题空气小猪对英语学习有什么帮助空气小猪如何提升英语能力空气小猪适合什么英语学习场景空气小猪和传统英语学习方式有什么不同空气小猪的核心学习价值是什么然后每条问题分别走向量检索和 BM25 检索这样会得到一批候选结果但候选结果还不能直接用。因为多路检索之后结果会比较多也会有重复和弱相关内容。那我们应该如何处理呢首先会对相同检索方式的结果使用RRF进行合并得到两类候选结果分别为向量检索结果、BM25检索结果由于混合检索后的查找范围很大单纯依赖原始相似度分数难以直接过滤结果因此需要引入重排模型进行精细排序。重排模型reranker对候选结果重新评分并根据相关度重新排序绝大多数情况下可以有效提高搜索结果的准确率。重排后可以得到一个0-1得分代表着搜索内容与问题的相关度该分数通常比向量的得分更加精确可以根据得分进行过滤。最后使用RRF对重排结果、向量搜索结果、BM25检索结果进行合并得到最终的搜索结果。生成回答时检索出知识之后并不是直接把知识丢给模型让它自由回答我们在生成阶段做了比较强的约束。产品咨询类问题的原则是所有回答必须在知识中有依据宁可不答也不要错答。所以提示词里有一个很关键的字段useful。模型需要判断召回的知识是否真的能回答用户问题。如果可以就usefultrue正常回答。如果知识不相关或者不足以回答就usefulfalse回复用户暂时不能回答。这个设计看起来只是多了一个字段但实际很重要。因为检索结果永远不可能百分百准确。哪怕召回了 TopK也可能只是弱相关。如果不让模型再次判断知识是否可用它很容易基于一点点相关内容硬编。我们希望客服系统有一个基本底线不知道就是不知道。产品咨询的输出大致是{ useful: true, content: 空气小猪主要通过真实聊天内容帮你建立外语环境让学习更贴近日常而不是额外增加刷题任务。, translation: ...}如果是usefulfalse这条问题还会进入低置信度问题池后续用于补充知识库。对话上下文管理AI客服是连续多轮对话不是单轮问答。因此每次让调用大模型我们除了把用户最新的消息传进去之外还需要把历史会话消息传递进去这样才能确保大模型理解对话上下文。那么问题来了应该携带多少条历史消息合适呢太少的话会大概率会丢失上下文信息大模型回答会偏携带太多速度会慢、token消耗会变大干扰信息太多还会产生幻觉。我们这里也做了一个策略对记忆进行了分层分为短期记忆和长期记忆。短期记忆就是最近 N 条原始消息保持原样不压缩保证当前对话的连续性。长期记忆是把更早的对话异步压缩成摘要存到业务数据库里比如每满 50 条消息生成一条摘要后续再按需携带最近几条摘要即可。摘要里只保留事实和诉求比如用户关心什么、遇到什么问题、已经提供过哪些信息、还有什么未解决。通过这种策略在成本和上下文完整性之间取得一个平衡。我们在让大模型做意图识别、问题改写以及回答问题时我们携带的消息上下文构成如下当然除了上面这种按照固定条数进行压缩之外我们也可以根据达到一定的token数量才进行压缩。这里根据具体场景进行选择。全链路可观测AI 客服最难调的地方是它看起来答了但答得不对。传统系统出问题可能会报异常、状态码错误、数据库写入失败。AI 客服系统出问题却是另一种形态可能是意图识别错了、问题改写偏了、知识召回不足、或者召回的知识根本不相关、提示词不正确等等。如果只看最终回答很难知道问题出在哪所以我们把全链路的关键节点日志都记录下来用户原始消息指代消解后的问题意图识别结果和理由问题改写结果向量召回列表和分数BM25 召回列表Reranker 重排结果最终使用的知识生成回答和useful判断每次模型调用的耗时和成本在后台管理系统中可以看到全流程关键节点的输入和输出信息可以直观地观测整个 AI 客服的运行状态。当用户反馈回答不准我们可以回头看到底是意图识别错了还是召回没召到还是知识本身缺了还是模型没有按知识回答。这些问题对应的优化方向完全不同没有这些日志就只能靠猜。数据飞轮数据飞轮本质上是一种持续反馈的闭环机制通过从用户交互中不断收集数据 → 处理 → 优化 → 再反哺系统 让 AI 在真实业务中越用越准我们初始知识库一定是不完整的哪怕我们已经整理了人工知识也处理了历史客服记录真实用户还是会问出很多知识库没有覆盖的问题。所以从第一版开始我们就设计了低置信度问题池。当召回分数低于阈值或者生成阶段返回usefulfalse这条问题就会进入低置信度池。但这里有一个原则不是所有问题都应该进知识库。用户随便发一句情绪、一个无意义输入、一个极低频问题、一个强时效问题都不适合沉淀成正式知识。如果全部自动入库知识库很快就会变脏。所以低置信度问题进入后台之后先做问题标准化。比如用户原话是我在日本用 81 的手机号能不能注册啊不行我就换国内的标准化之后应该是国外手机号是否支持注册空气小猪账号这个过程会去掉情绪、口语和无关信息只保留真实意图利于后续知识检索。同时系统会判断它是否和已有低置信度问题相似。如果多个用户都在问同一个问题就合并到同一个标准问题下面并记录出现次数根据出现次数判断这个问题是否高频是否是需要即时补足。后台审核时人工也会再次判断这是不是正常业务问题现有知识库是否其实已经覆盖是不是垃圾信息或无意义输入是否低频到不值得沉淀是否需要补充成正式 FAQAI 给出的初步答案是否可靠。审核通过之后再由人工补充正式答案重新走知识入库和向量化流程。这样下一次用户问类似问题时系统就能命中新知识这就是数据飞轮。结语做完这个项目之后对我比较重要的几个启发明确系统边界能做什么不能做什么AI客服的原则是宁可不答也不要错答RAG 的核心是知识工程这块不能偷懒建立观测基础设施和知识迭代机制对持续运营和优化至关重要学AI大模型的正确顺序千万不要搞错了2026年AI风口已来各行各业的AI渗透肉眼可见超多公司要么转型做AI相关产品要么高薪挖AI技术人才机遇直接摆在眼前有往AI方向发展或者本身有后端编程基础的朋友直接冲AI大模型应用开发转岗超合适就算暂时不打算转岗了解大模型、RAG、Prompt、Agent这些热门概念能上手做简单项目也绝对是求职加分王给大家整理了超全最新的AI大模型应用开发学习清单和资料手把手帮你快速入门学习路线:✅大模型基础认知—大模型核心原理、发展历程、主流模型GPT、文心一言等特点解析✅核心技术模块—RAG检索增强生成、Prompt工程实战、Agent智能体开发逻辑✅开发基础能力—Python进阶、API接口调用、大模型开发框架LangChain等实操✅应用场景开发—智能问答系统、企业知识库、AIGC内容生成工具、行业定制化大模型应用✅项目落地流程—需求拆解、技术选型、模型调优、测试上线、运维迭代✅面试求职冲刺—岗位JD解析、简历AI项目包装、高频面试题汇总、模拟面经以上6大模块看似清晰好上手实则每个部分都有扎实的核心内容需要吃透我把大模型的学习全流程已经整理好了抓住AI时代风口轻松解锁职业新可能希望大家都能把握机遇实现薪资/职业跃迁这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】