本文详细介绍了空气小猪语言学习App的AI客服系统构建全流程包括技术选型、知识库整理与构建、意图识别、问题泛化、混合检索策略及生成阶段。文章强调数据是AI客服的灵魂通过RAG技术与数据飞轮机制实现客服系统的持续优化与迭代最终实现降本增效的目标。系统采用向量检索与全文检索相结合的方式并利用重排模型提高检索准确性为AI客服系统提供了完整的实践方案。AI训练营26-1期3月初开班欢迎咨询之前我们说过23年是模型初年主要行业主要着眼于模型史称百模大战然后很快大家发现确实卷不动于是开始冷静下来找切实的落地场景所以24年都在做应用AI应用三巨头依次是AIGC窗口生成文案、工作流AI、然后就是AI客服了。而后25年在AI视觉这块需求变多、成熟的AI Coding异军突起但复杂的AI客服依旧有很大的需求AI客服这个也被认为是RAG类的应用看上去简单只不过很多公司却做不好。所以我们这里以一个生产案例作为课件带大家深入浅出的了解一个AI客服是怎么打磨好的unsetunset案例说明unsetunset这个AI客服案例来源于我们去年AI 2C的创业项目空气小猪。他是一款基于社交的语言学习App从上线之后一直是我们自己在做客服工作每天都会消耗2-3小时的时间这种状态已经持续了半年多了占用了大量时间。这期间我们也尝试找过兼职客服做过一段时间发现效果很差。一方面兼职人员不太上心另一方面由于对产品理念和定位理解不够深入往往无法准确、有效地回应用户问题整体服务质量难以保障。其实用户的问题基本都是重复的高频问题就那些每天去人工重复回答这些问题确实挺费时间的既低效也不具备可持续性。所以关于简单AI客服的系统我们之前就形成了一套方法论简单场景照着做就行虽然最后证明其他同学会在其他地方掉坑里复杂场景的话又有另外一套方法论由此我们也几乎可以得出一个结论客服工作无论简单复杂在未来大概率会被AI替换在线客服工作本身具有较强的重复性因此**“降本增效”**始终是客服系统演进的核心目标。基于大模型的AI客服可同时显著提升产品能力和用户体验还能大幅降低运维成本。随着 AI Agent 的成熟应用AI客服系统在成本、效率和可扩展性方面进一步优化逐渐会成为最优解。那么这里又有同学会有疑问为什么不一开始就上AI客服还要每天花几小时去自己做答案很简单我们也需要积累原始数据啊…在这半年多的时间里创始人与用户之间沉淀了大量真实、高质量的对话语料这为我们提供了宝贵的数据基础。在基础问题开始不断重复的时候就是构建一套 AI 客服系统的时机了。这里目标就简单了**把我们从每天2小时的人工客服时间释放出来**这也是整体项目背景了下面我们将详细的介绍空气小猪AI客服从0到1 的整个实践过程以及落地的关键步骤。unsetunset技术选型unsetunset在实现环节我们面临一个选择是采用智能体低代码开发平台还是直接进行工程化代码开发从技术角度来看这两种方式都可以实现目标但真的要做肯定是直接选择工程化代码方案啊好处很多最重要的是对这块有更深入的技术实践所有这一切都会体现在自主可控性这点但也可以将选型过程简单说下各位可以考虑看看在智能体开发平台的选型中主要考虑的是Dify前面我们介绍过coze、dify、fastgpt、n8n的技术选型。整体来看Dify的能力算是这些平台中最均衡的没有明显的短板尤其适合企业场景下的智能体开发、工作流的编排以及知识库驱动型应用。但是最终没有选择Dify主要是基于下面几个方面考虑我们对知识库检索能力有较高要求希望在召回策略、排序逻辑、上下文拼接等环节进行深度优化。这部分是 AI 客服的核心能力我们更希望逻辑完全自主可控。私有化部署也需要额外的服务器的成本和运维成本对我们当前阶段而言是没有必要的真实使用你们才知道开源版本会少了什么。在实际测试中我们发现 Dify 的执行链路相对较长尤其在知识检索节点整体响应时间偏长不完全符合我们对实时性的要求。即使使用Dify实际落地过程中依然会涉及系统对接、数据适配和定制开发等工作并非零成本集成。综合这些因素我们最终决定自己写代码从底层能力开始搭建虽然前期投入更高但在可控性、性能优化空间以及长期演进能力方面更有优势。并且自己写代码事实上成本也并不高…解决了第一个问题很多同学第二个问题也就出现了那么我们的AI客服要不要直接用Agent模式呢Workflow还是Agent项目开始阶段除了要决定使用Dify还是工程化代码开发模式也需要在Workflow和Agent中做出选择。Agent是具有高度自主性的智能体但是结果的确定性、性能等都不占优势通常客服场景会选择比较保守的做法先按照Workflow的方式搭建稳定的流程来追求确定的、能控制的结果。从工作流程入手逐步引入并解决每一个遇到的问题同时兼顾效果、成本和可控制程度。至于后期要不要“升级”Agent版本完全看业务需要业务上几乎不追求这些时髦的东西。基础流程设计在确定基础技术选型后就可以进行流程设计了在第一个版本中我们把意图分为产品咨询和闲聊大致的流程如下但是很快我们发现用户除了咨询常见的产品功能问题还会反馈一些产品建议以及程序故障等问题。而这一部分内容的处理逻辑与单纯的产品咨询其实是不太一样的用户反馈的问题是需要存入数据库并且根据问题的严重程度划分等级方便我们及时跟进修复处理。在初版的基础上面我们增加了优化建议、故障反馈的意图处理流程。具体流程如下这也就是我们方法论中所述的整理大表了在基础意图整理差不多后就可以进入最重要的知识梳理环节了unsetunset知识整理unsetunset要做AI知识库的同学一定要注意数据才是灵魂如果有人说做AI项目不深度聊数据那么他大概率是没做过的…产品知识是AI客服的基础这也是为什么我们非要等半年才做客服的原因只有提供优质的知识才能让AI输出优质的回答否则就是垃圾进垃圾出。在数据不全的情况下不管做再多的工程化优化都是无用功所以说RAG的本质是个数据工程大家一定要去理解这到底是在说撒。具体在做AI客服知识梳理时理论上来说要求是很高的它最好来自这个产品最有解释权的人但是知识的完备性需要持续的迭代更新才能覆盖完全。真实情况是所有知识库应用初始阶段都存在类似的情况所以允许知识覆盖不全在迭代中逐步补齐知识并且后面用数据飞轮的策略来自动化的完善知识不足的问题变成了主流。具体到这个项目我们的知识来源于两部分内容一部分内容是人工整理的另外一部分是历史客服数据。在进行知识整理时就需要考虑如何组织知识才能有更好的检索效果而检索的效果很大程度是取决于数据处理是否正确比如每个分块的语义是否完整独立。因此输出的知识一定要能够单独成块可以利用Markdown格式进行结构的化层级进行整理在分块时可以根据标题进行分割知识内容大致形式如下另一方面我们导出了所有历史客服对话数据这里主要根据会话维度进行分析因为数据较多不太可能人工整理可借助AI分析提取每个会话中有效的问答记录。当然这里也不能一次性把所有的数据给到大模型整理有两个原因一是数据太多会超出大模型上下文限制二是数据太多幻觉增加准确率会降低处理的策略是拆分为多个批次进行整理比如每10个会话为一个批次我们借助Coze搭建了一个自动化处理工作流流程如下PS这里也可以看出来我们其实也使用Coze但一般是来做一些自动化小操作用完就走从数据库导出会话记录时每10个会话导出为一个会话记录文件最终会导出若干个会话记录文件然后把这些文件上传到coze工作流上进行批量处理生成的问答对内容都会被写入飞书多维表格中。最终表格中的内容必定会存在重复的内容再把表格中整个内容给到大模型进行分析把内容去重处理形成最终的问答对。通过这两种方式我们就得到了最终的产品知识数据这一步非常重要也非常耗费精力并且需要真正懂这个产品的人来做才能取得好的效果。可以认为这一步没做好那么AI客服的效果一定会差在数据整理结束后就进入了知识库构建环节unsetunset知识库构建unsetunset这里技术实现Python FAISS MYSQL qwen(text-embedding-v4)向量库选择Meta公司开源的FAISS非常轻量嵌入模型使用千问的text-embedding-v41024维度它在中文场景下表现更好。数据存储的结构整个知识库由库、集合和数据 3 部分组成。集合可以简单理解为一个文件一个库中可以包含多个集合一个集合中可以包含多组数据最小的搜索单位是库也就是说知识库搜索时是对整个库进行搜索而集合仅是为了对数据进行分类管理与搜索效果无关。向量存储的结构使用 Faiss 作为向量检索引擎使用 MySQL 作为业务数据存储数据库实现知识入库与向量召回的分离式架构设计。这里Faiss只负责向量存储与相似度检索MySQL负责原始知识数据与业务字段存储向量检索引擎可独立替换为其它向量数据库比如Milvus、Weaviate等不影响业务数据库结构。而这两者间的关系通过向量ID进行关联在MySQL的dataset.datas表中会存储向量原数据的信息同时有一个vectorId字段会记录其对应的向量ID。知识入库是一个离线过程大致流程如下先加载知识文档对文档进行分块然后把分块存入到mysql业务数据库中此时向量化状态为待向量化向量ID字段为null然后通过异步事件驱动把每一个分块chunk使用向量模型进行向量化得到向量坐标之后存入Faiss向量库中存入向量库完成后会生成向量ID然后在把这个向量ID存入到mysql对应的chunk中的vectorId字段并且将向量化状态更新为已向量化知识检索流程如下使用向量模型对用户的问题进行向量化得到向量然后使用 Faiss 执行相似度搜索召回TopK个向量ID同时得到相似度得分拿到召回结果后根据向量ID去MySQL数据库中查询该向量ID对应的原始文档chunk数据知识入库在知识整理完之后使用代码对markdown格式的知识按照结构层级进行分块得到结构化的JSON数据然后存入业务数据库和向量库中。把一级标题设置为category字段把最后一级标题设置为questions段落内容设置为answer字段如果存在三级以上的层级把1到n级标题通过“-”链接设置为category字段n级标题设置为questions字段。我们得到的分块内容如下结构这里只列举核心字段{ category: 产品概念, questions: [ 空气小猪解决的核心问题是什么? ], answer: 很多用户长期学外语遇到的真实问题包括\n外语只存在于“学习时间”无法进入日常生活\n输入和输出被割裂学到的语言很难迁移到真实使用\n听力和阅读材料与个人生活无关难以长期坚持\n空气小猪并不通过增加学习任务来解决这些问题而是通过重用已经发生的聊天内容为用户建立一个长期、低成本、真实相关的外语环境。, keywords: [] }得到若干上述分块结构之后按照前面的流程把每个分块存入mysql数据库并存入向量库中。需要注意的是向量化的文档内容并不是直接把这个JSON进行向量化这里JSON结构主要是为了拿到文档分块的结构化信息方便元信息获取及存储。向量化的真正文本内容为categoryquesionsanswer的拼接内容。在这一步我们最初犯了一个错误我们把生成的原始chunk使用大模型针对问题进行了泛化处理泛化后的结构为{ category: 产品概念, questions: [ 空气小猪解决的核心问题是什么?, 空气小猪主要解决了什么问题? 空气小猪的核心价值是什么? ], answer: 很多用户长期学外语遇到的真实问题包括\n外语只存在于“学习时间”无法进入日常生活\n输入和输出被割裂学到的语言很难迁移到真实使用\n听力和阅读材料与个人生活无关难以长期坚持\n空气小猪并不通过增加学习任务来解决这些问题而是通过重用已经发生的聊天内容为用户建立一个长期、低成本、真实相关的外语环境。, keywords: [] }也就是把一个问题泛化为多个可能的问题以提升召回命中率并且在存储时按照一问一答的结构进行储存也就是把问题1 答案、问题2 答案、问题3 答案 分别进行存储。最后在知识召回时就出现问题了同一个问题很大概率会召回相同的文档信息并且这部分的得分还比较高于是取Top-K时召回的数据都是一样的只是问题不一样这就导致其它可能更相关的内容被挤掉。接下来是检索流程unsetunset检索过程unsetunsetRAG系统在检索这里比较重要的是意图识别。所以前置的意图分类这一步就至关重要真实用户的问题是非常发散的第一步就需要对用户的意图进行收敛收敛的目的是为了匹配后续的流程以及更好的匹配到我们知识库中的知识。我们在把第一级大类意图拆分为产品咨询、故障反馈、闲聊然后通过代码进行路由分发分别走不同的处理流程但是这里要让大模型准确判断是哪一个意图需要继续细化用户的二级意图比如什么情况下应该匹配到产品咨询上什么情况匹配到故障反馈上你需要给大模型一个明确的评价标准这个二级意图就是用来辅助大模型判断一级意图的标准。否则在意图识别这一步很可能就直接出错后续的回答肯定就不准确了。这里整理的思路也跟大家简单分享一下一是从产品本身梳理我们提供了什么、主要解决什么问题二是从用户的角度进行梳理我能得到什么、对我英语有没有提升怎么用然后对两者进行融合通过客服历史问答数据我们提炼了用户的高频问题这里给了非常大的参考价值。下面是我们梳理的一些高频问题类别这里再摘抄部分意图识别的提示词## 角色 你是 空气小猪 App 智能客服系统的专业意图识别器。 你的输出将被直接用于自动路由和客服决策请严格遵循规则不得自由发挥。 ## 总体目标 基于【对话历史】和【用户最新消息】完成以下 两个任务 1. 指代消解必须先完成 2. 意图识别基于指代消解后的问题 ## 任务一指代消解 目标 结合【对话历史】对【用户最新消息】中的所有指代性表达进行消解你需要生成一条单句、语义完整、无任何模糊指代的用户问题 处理规则 1.必须结合【对话历史】进行还原 2.如果用户问题本身已经明确不要强行改写 3.不得引入对话中不存在的新信息 4.输出必须是一个完整问题句 输出字段 resolved_question ## 任务二意图识别 基于 resolved_question结合【对话历史】信息进行理解将其准确分类到以下三个意图之一并且按照顺序依次判断 1. **产品咨询(SUPPORT)** , 判断标准为 { 空气小猪小猪相关问题 产品功能介绍/产品价值/能解决什么问题 使用方法/操作步骤/使用教程 下载安装/注册登录/账号相关 产品定价/会员/付费 与竞品的比较 翻译/语言支持/语言学习相关 播放/播客/朗读 聊天/加好友/社交/翻译对话相关 任何“如何用空气小猪做某事”的问题 } 2. **问题反馈(FEEDBACK)**, 判断标准为 { 用户明确提出对空气小猪产品功能优化建议、希望增加功能、优化建议、故障反馈比如功能异常、报错、打不开、点不动、卡顿、无法使用等 } 3. **闲聊(CHAT)**判断标准为 { 当不属于以上两类时一律归为 CHAT例如问候、寒暄、玩笑、调侃、情感倾诉、模糊无意义输入 } ## 输入信息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用户输入的翻译翻译为%s 2. **必须**使用以下JSON格式返回不得包含任何其他文本 { confidence: 0.0-1.0, intent: SUPPORT | FEEDBACK | CHAT, resolved_question: 指代消解后的明确问题, translation:用户输入的翻译, reason: 简要分类理由说明上下文如何影响判断 }从提示词的设计可以看出我们不仅对用户的提问进行了意图识别还在这之前增加了指代消解的处理步骤。也就是说在完成指代消解之后才进入意图识别阶段。PS事实上也可以将这个提示词再拆分以符合提示词原子性的要求我们这里因为是做案例讲解就不麻烦了至于之所以需要进行指代消解是因为在实际使用过程中我们发现用户往往会将一个完整的问题拆分成两句话或者在后续提问中使用上下文中的指代词例如用户先问“空气小猪是干什么的”接着又问“它怎么用”如果将第二句话直接用于检索很可能无法获得有效结果而真正符合用户意图的检索语句应该是“空气小猪怎么使用”。因此我们借助大模型结合上下文语境对用户最新的问题进行指代消解将其中的指代词还原为具体对象。这样可以提高意图识别、以及检索的准确性使整体流程更加连贯和高效。在意图识别这个环节中模型经历了从GPT-4.1到Qwen-plus-latest、Qwen-max-latest再到Qwen3-max、Qwen-plus的选择过程。GPT-4.1作为效果标杆Qwen系列则需要通过提示词优化或节点拆分来提升表现。值得一提的是Qwen-plus在未修改提示词的情况下即有提升整体效果还可以。我们这里场景不算复杂为了均衡成本和效果我们模型最终选择了Qwen-plus, 如果需要更好的效果可以考虑Qwen3-max或GPT4.x等模型。模型的选择可以根据项目阶段来确定项目初期选择参数较大的模型进行验证并快速上线后期则在保证意图识别准确率不下降的前提下逐步替换为成本更低的模型以实现效果与成本的平衡。总之我们每个项目做的时候都会用最好的模型后续实际上线都是各种成本考虑…问题泛化在正式进入检索阶段之前需要先对用户问题进行一系列语义预处理最大程度提升后续检索的召回率与覆盖面。首先通过指代消解技术对问题中的代词、模糊指称和上下文依赖表达进行还原。例如将“他”“这个”“那个”等模糊表达结合上下文明确为具体的名称从而避免检索阶段因语义歧义而遗漏关键信息。其次我们基于原始问题进行多问题生成Query Expansion Multi-Query Generation。利用大模型的语义理解和重写能力从不同角度、不同表达方式对同一问题进行改写扩展。比如同义词替换与表达重构、从不同维度拆解子问题、将抽象问题转化为更具体、可检索的表达语句。通过这种方式可以将一个单一问题扩展为多个语义相关但表达不同的查询语句。这种多路查询策略能够覆盖更多潜在的匹配结果以提升召回率同时减少因表达方式单一或者口语化而导致的信息遗漏。## 角色 你是“空气小猪”智能客服系统的查询优化专家专门处理**产品咨询**类查询的泛化改写任务把用户问题泛化成检索友好的中文查询用于知识库向量检索 ## 改写规则 1. 如上下文中出现了关键实体产品名、功能名、版本、平台、错误码、按钮文案等改写需保持一致。 2. 不要引入上下文里不存在的具体数值、版本号、错误码、功能名。 3. 生成的每条查询都要尽量短、包含关键关键词、便于命中知识库。 4. 若用户输入不是中文请先理解其含义再用中文生成改写查询。 5. 改写要有多样性每条改写应有不同侧重点 ## 输入信息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 - rewritten_queries 严格 5 条每条为 string。 - **必须**使用以下JSON格式返回不得包含任何其他文本 { original_query: string, rewritten_queries: [ string, string, string, string, string ] }上下文管理每次让大模型进行意图识别、问题泛化、回答问题时除了把用户最新的消息传进去之外还需要把历史会话消息传递进去这样才能确保大模型理解对话语境。但是这里存在一个问题应该携带多少条历史消息合适呢太少的话大概率会丢失上下文信息大模型回答会偏携带太多速度会慢、token消耗会变大干扰信息太多会产生幻觉。如果简单固定携带10条-20条历史消息在大多数情况下是可以的但仍然存在明显的缺陷更早的关键对话信息就丢失了。因此单纯使用“固定条数”的策略没法在上下文完整性和资源成本之间取得比较好的平衡。为此这里也做了一个优化策略对记忆进行了分层分为短期记忆和长期记忆。短期记忆比较好理解就是每次携带N条最新的会话消息这部分信息保持原始表达不做信息压缩尽量保证对话语境的连续性和即时性。除此之外还会携带历史消息的摘要信息历史摘要信息的生成规则是每满N条消息就会进行一轮异步压缩并把摘要信息存入业务数据库中持久化保存。需要注意的是这里的历史摘要信息携带数量并不是全量的也完全没有必要全量携带举例说明比如我们每30条消息进行一轮压缩如果携带10条摘要信息那这里就是300条历史消息的摘要信息了用户最新的聊天可能早已跳出之前的对话语境。下面是历史消息摘要生成的示例提示词# 角色 你是一个对话总结助手任务是把下面的对话片段总结为一条可用于后续意图识别的“历史摘要”要求尽量节省token但保留关键信息。 # 规则 1. 只总结事实与诉求用户关心点、问题、偏好、已给出的关键信息、未解决点 2. 不要杜撰不要引入对话中没有的信息 3. 输出长度建议 120-220 字/词左右按语言自然长度 # 对话片段 { %s } # 输出要求 返回如下JSON格式不要返回多余内容 { summary: string }我们在让大模型意图识别、问题泛化以及回答问题时我们携带的消息上下文构成如下当然除了上面这种按照固定条数进行压缩之外我们也可以根据达到一定的token数量才进行压缩。这里根据具体场景进行选择。检索方案前面我们针对用的问题进行了泛化处理把一个问题改写为多种不同的表达方式利用多路查询提升知识召回率然后对于每个问题我们又使用了混合检索策略进行搜索。这里的混合检索就是语义检索和全文检索的组合使用之所以采用这种方式是因为这两者在能力上具有互补性语义检索擅长理解语义层面的相似性而全文检索则擅长精确关键词匹配从而弥补单一检索策略各自的局限。语义检索是通过向量距离计算用户问题与知识库内容的距离从而得出“相似度”。需要注意的是这并不是语言学上的相似而是数学空间中的距离相近。它的优势就是能够找到语义相近的知识但是它的精度较低会受到关键词和句子完整度影响。而全文检索我们采用BM25算法BM25主要基于词频和逆文档频率TF-IDF的加权搜索模型来对文档进行排序和检索。它特别适用于处理较为简单的匹配任务尤其是当查询和文档中的关键词有直接匹配。为此通过“多问题查询 混合检索”我们会获得一批候选知识。但此时的结果集合规模较大、质量参差不齐因此还需要进一步筛选才能得到真正符合需求的内容。那我们应该如何处理呢首先对相同检索方式的结果使用RRF进行合并得到两类候选结果分别为向量检索结果、BM25检索结果由于混合检索后的查找范围很大单纯依赖原始相似度分数难以直接过滤结果因此需要引入重排模型进行精细排序。重排模型reranker对候选结果重新评分并根据相关度重新排序绝大多数情况下可以有效提高搜索结果的准确率。重排后可以得到一个0-1得分代表着搜索内容与问题的相关度该分数通常比向量的得分更加精确可以根据得分进行过滤。最后我们会使用 RRF 对重排结果、向量搜索结果、全文检索结果进行合并得到最终的搜索结果。单个问题的向量检索流程与前面讲解的流程一致这里多问题并行向量检索的流程如下我们使用的Faiss向量库以及MySQL并不直接支持BM25检索我们采用的策略是先拿到所有的知识分块片段并结合用户的问题利用LangChain提供的BM25Retrieve进行计算核心代码逻辑如下# 使用 BM25Retriever bm25_retriever BM25Retriever.from_documents(splitsDoc) bm25_retriever.k 3 # 返回前3个最相关的文档 # 使用 bm25_doc bm25_retriever.invoke(query) print(fbm25_retriever检索到 {len(bm25_doc)} 个相关文档块:)至此其实AI客服的核心流程都被覆盖了剩下的也就是最后的生成环节反而简单了unsetunset生成阶段unsetunset我们把大的意图分为了三个分别是产品咨询、故障反馈、闲聊进入每个意图后处理的逻辑是存在差异的因此大模型生成回答的提示词是不同的。提示词的重点是构造上下文信息拼装召回的知识、最新的N条对话历史消息、更旧的历史摘要消息以及用户最新的问题。下面是具体的提示词需要注意的是知识召回后在大模型真正生成回答时会让他再次判断召回的知识是否可以回答用户问题如果没用则拒绝回答并且把useful字段设置为false否则设置为true。这个字段的用处在于我们会对大模型回答的问题进行标记不能回答的问题会进入低置信度问题池列表便于后续知识补足和复盘是为后面的数据飞轮做准备的## 角色 你是空气小猪产品客服助手你需要根据对话历史、用户最新消息、以及知识回答用户问题 ## 回复原则 1. **简洁明确**直接回答不绕弯不要超过100字 2. **友好专业**保持礼貌体现专业性 3. **客观公正**遵循客观事实不要胡编乱造所有回答的内容都需要在【知识】内容中有迹可循宁可不答也不要错答 4. 如果知识库资料与用户反馈高度相关给出可执行的解决/排查步骤或替代方案并将 usefultrue 5. 如果资料不相关或不足以解决将 usefulfalse并回复用户暂时不能回答这个问题 ## 知识 { %s } ## 上下文消息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用中文回复不超过100字 2. 给出回复内容的%s翻译 3. **必须**使用以下JSON格式返回不得包含任何其他文本 { useful: boolean, content: string, translation: string }当用户意图匹配为“故障反馈”或“功能建议”时需先确认用户反馈的问题内容并检查相关功能是否已存在如果功能已存在引导用户正确使用或提供解决方案。如果功能不存在需要评估用户需求是否符合产品原则以及是否属于明确“不做”范围如果属于“不做”范围明确说明并予以拒绝如果不属于则继续收集信息。 在信息不足的情况下需要引导用户补充详细描述随后对用户的反馈进行数据清洗并判断反馈类型故障或优化建议再分类存入业务数据库便于后续跟进与处理。## 角色 你是空气小猪产品客服助手专门负责处理用户建议和产品故障反馈。 ## 产品核心理念 { %s } ## 处理流程 仔细阅读【产品核心理念】、【知识】、【上下信息】按照如下要求进行处理 ### 1. 功能建议处理流程 #### 第一步功能状态判断 首先判断用户建议的功能是否**已经存在** - **已存在**明确告知用户该功能已支持并提供简要使用指引 - **不存在**进入下一步评估 #### 第二步原则性评估 检查建议是否符合 - **产品核心原则**符合空气小猪产品定位和核心价值观 - **明确不做清单**是否属于已明确排除的功能范畴 评估结果处理 - **符合原则且不在排除清单** - 回复**“感谢您的宝贵建议我已经记录并反馈给产品团队进行评估我们会认真考虑这个功能的可行性。”** - 无需承诺具体实现时间 - **不符合原则或在排除清单** - 友好、明确地拒绝 - 回复示例**“感谢您的建议。不过这个功能目前不符合我们的产品方向。期待您提出其他改进建议”** ### 2. 故障反馈处理 - 引导用户详细描述问题现象 - 告知用户已反馈给技术团队 ## 回复原则 1. **简洁明确**直接回答不绕弯不要超过100字 2. **友好专业**保持礼貌体现专业性 3. **不过度承诺**不承诺功能上线时间或具体解决方案 4. **客观事实**不要胡编乱造必须要从知识中拿到可靠的依据 ## 知识 { %s } ## 上下文消息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用中文回复不超过100字 2. 给出回复内容的%s翻译 3. **必须**使用以下JSON格式返回不得包含任何其他文本 { content: string, translation: string }对于严肃型产品服务场景如电商、医疗、金融等通常不建议提供闲聊功能应优先保证回答的准确性和可靠性在无法确认答案时宁可不回答也不应提供可能误导用户的信息。但在语言学习类应用中我们有意引入“闲聊意图”目标是让 AI 客服具有更自然、有温度的互动体验而不是仅提供机械式回复。通过适度的闲聊能力可以增强用户参与感与陪伴感从而提升整体使用体验与产品黏性## 角色 你是空气小猪产品客服助手擅长陪伴用户进行轻松有趣的闲聊。你的核心任务是在自然对话中传递产品价值并收集有助于改进的用户反馈。 ## 产品核心理念 { %s } ## 对话风格 - 亲切、自然像朋友聊天一样 - 避免推销感注重倾听和共鸣 - 根据用户回答灵活调整不强行推进问题 - 在解释产品理念时尽量用口语化的例子或场景说明 ## 引导反馈顺势、递进、不要一次问完 1. 你是怎么了解到我们产品的呀 2. 最近使用起来感觉怎么样有没有特别喜欢的部分 3. 如果让你提一个建议你会希望我们改进什么 4. 方便问一下你现在是学生还是已经工作了吗 ## 输入信息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用中文回复不超过50字。 2. 给出回复内容的%s翻译 3. **必须**使用以下JSON格式返回不得包含任何其他文本 { content: string, translation: string }unsetunset再说可观测性unsetunset前面的内容整个客服的流程就已经拉通了从知识整理、知识入库到问答流程。现在我们需要进一步调优就要观察关键的环节是否符合我们的预期比如意图识别准不准、指代消解对不对、问题改写质量如何、知识召回质量高不高、提示词有没有问题我们需要对每个环节的耗时进行观测。为此我们在流程关键节点对核心信息进行了结构化存储包括指代消解、用户问题改写意图识别结果向量召回的候选结果列表及置信度最终命中的知识内容及回复结果大模型调用日志在后台管理系统中可以看到全流程关键节点的输入和输出信息可以直观地观测整个 AI 客服的运行状态。比如意图识别轨迹列表、客服向量召回结果列表、问题改写列表…通过对这些核心节点的持续监测、分析可以将原本不可见的系统运行过程由“黑盒”转变为“透明”从而实现问题可定位、效果可评估、策略可优化支撑整体能力的持续迭代与提升。unsetunset数据飞轮unsetunset这里必须说清楚我们搭建的客服系统知识现在仍然不是很完备无法覆盖用户所有的问题除了人工补齐的方案我们也增加数据飞轮系统功能。数据飞轮本质上是一种持续反馈的闭环机制通过从用户交互中不断收集数据 → 处理 → 优化 → 再反哺系统 让 AI 在真实业务中越用越准当然这里并不是把所有的问题都放进知识库而是识别哪些问题值得沉淀持续补全真正有价值的知识缺口下面结合实际系统设计介绍在 AI 客服中如何对低置信度问题进行收集并持续优化知识库。置信度在前文我们提到过AI 客服的第一步是 意图识别。当用户提问后系统会先给问题打标签例如产品咨询在对应标签下进行向量召回每条召回结果都会有一个 置信度score这个置信度代表的是用户问题 与 知识库内容 的语义匹配程度分值越高说明命中越精准分值越低往往意味着知识库存在缺失或覆盖不足在系统中我将置信度阈值设置为 0.5。当召回置信度 ≥ 0.5时直接走正常回答流程当召回置信度 0.5时认为当前知识库匹配度较低此时系统会异步处理这条问题数据进入数据飞轮流程。问题标准化模型会基于下面的提示词完成两件关键事情将用户的原始提问进行标准化处理生成一个示例答案作为后续处理与参考依据例如 用户原话 “我在日本用 81 的手机号能不能注册啊不行我就换国内的” 整理后的标准问题国外手机号非中国大陆是否支持平台注册这一步在信息检索领域中通常被称为 Question Canonicalization问题规范化因为用户的表达通常是口语化、上下文依赖很强并不适合用于直接存储或检索在进入数据飞轮流程前需要先将问题转化为结构清晰、语义稳定的标准形式以提升后续召回、匹配与分析效果。你是智能客服的知识运营助手。你要把“用户原话”整理成可入库的标准问题并尝试与候选问题合并。 目标 1) 去噪去掉情绪、口语、无关碎片只保留核心诉求 2) 标准化输出“真实意图”的标准问题用中文尽量像FAQ标题 3) 合并判断是否与候选问题同一意图如果是返回 matched_question_id否则返回 null 4) 初步解答基于标准问题给出一段中文初步解答如果信息不足说明需要用户补充哪些信息 约束 - normalized_question 必须是单行文本长度不超过 120 字 - 如果候选列表里没有同一意图的问题matched_question_id 必须为 null - 只返回严格 JSON不要输出多余内容 候选问题JSON数组 { %s1 } 用户原话 { %s2 } 输出JSON { normalized_question: string, matched_question_id: 123, ai_suggested_answer: string }数据入库与前后台分工处理完成后的数据会进入入库流程用户端负责数据采集低置信度问题自动进入待处理队列后台管理端人工审核决定是否写入知识库问题审核不是所有问题都值得沉淀在后台中人工需要先对问题进行审核当看到某条问题的召回置信度低于 0.5 时需要判断是否为正常业务问题是否存在垃圾信息、无意义输入或不当言论…同时也并不是所有问题都适合入库低频问题不值得沉淀强时效性问题会自然过期模型误判为“低置信度”的情况一定存在只有审核通过的问题才会进入向量化流程。这里系统也设置了相似问题出现的次数可以根据问题出现次数判断重要性效果验证完成向量化后知识库中会新增一条元数据当下次出现语义相近的问题时向量检索会命中这条新数据AI 客服能够给出更贴合的回答。通过数据飞轮的设计能够让AI客服越用越准。unsetunset结语unsetunset通过空气小猪 AI 客服项目的实践相信各位对于什么是简单AI知识库以及AI知识库如何落地会有更深的理解了。最后文章篇幅已经很长了这里就不再赘述只是再强调下数据才是AI客服的灵魂…如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
【万字】半年人工喂出来的AI客服：从0到1打磨生产级RAG系统
发布时间：2026/7/13 20:14:12
本文详细介绍了空气小猪语言学习App的AI客服系统构建全流程包括技术选型、知识库整理与构建、意图识别、问题泛化、混合检索策略及生成阶段。文章强调数据是AI客服的灵魂通过RAG技术与数据飞轮机制实现客服系统的持续优化与迭代最终实现降本增效的目标。系统采用向量检索与全文检索相结合的方式并利用重排模型提高检索准确性为AI客服系统提供了完整的实践方案。AI训练营26-1期3月初开班欢迎咨询之前我们说过23年是模型初年主要行业主要着眼于模型史称百模大战然后很快大家发现确实卷不动于是开始冷静下来找切实的落地场景所以24年都在做应用AI应用三巨头依次是AIGC窗口生成文案、工作流AI、然后就是AI客服了。而后25年在AI视觉这块需求变多、成熟的AI Coding异军突起但复杂的AI客服依旧有很大的需求AI客服这个也被认为是RAG类的应用看上去简单只不过很多公司却做不好。所以我们这里以一个生产案例作为课件带大家深入浅出的了解一个AI客服是怎么打磨好的unsetunset案例说明unsetunset这个AI客服案例来源于我们去年AI 2C的创业项目空气小猪。他是一款基于社交的语言学习App从上线之后一直是我们自己在做客服工作每天都会消耗2-3小时的时间这种状态已经持续了半年多了占用了大量时间。这期间我们也尝试找过兼职客服做过一段时间发现效果很差。一方面兼职人员不太上心另一方面由于对产品理念和定位理解不够深入往往无法准确、有效地回应用户问题整体服务质量难以保障。其实用户的问题基本都是重复的高频问题就那些每天去人工重复回答这些问题确实挺费时间的既低效也不具备可持续性。所以关于简单AI客服的系统我们之前就形成了一套方法论简单场景照着做就行虽然最后证明其他同学会在其他地方掉坑里复杂场景的话又有另外一套方法论由此我们也几乎可以得出一个结论客服工作无论简单复杂在未来大概率会被AI替换在线客服工作本身具有较强的重复性因此**“降本增效”**始终是客服系统演进的核心目标。基于大模型的AI客服可同时显著提升产品能力和用户体验还能大幅降低运维成本。随着 AI Agent 的成熟应用AI客服系统在成本、效率和可扩展性方面进一步优化逐渐会成为最优解。那么这里又有同学会有疑问为什么不一开始就上AI客服还要每天花几小时去自己做答案很简单我们也需要积累原始数据啊…在这半年多的时间里创始人与用户之间沉淀了大量真实、高质量的对话语料这为我们提供了宝贵的数据基础。在基础问题开始不断重复的时候就是构建一套 AI 客服系统的时机了。这里目标就简单了**把我们从每天2小时的人工客服时间释放出来**这也是整体项目背景了下面我们将详细的介绍空气小猪AI客服从0到1 的整个实践过程以及落地的关键步骤。unsetunset技术选型unsetunset在实现环节我们面临一个选择是采用智能体低代码开发平台还是直接进行工程化代码开发从技术角度来看这两种方式都可以实现目标但真的要做肯定是直接选择工程化代码方案啊好处很多最重要的是对这块有更深入的技术实践所有这一切都会体现在自主可控性这点但也可以将选型过程简单说下各位可以考虑看看在智能体开发平台的选型中主要考虑的是Dify前面我们介绍过coze、dify、fastgpt、n8n的技术选型。整体来看Dify的能力算是这些平台中最均衡的没有明显的短板尤其适合企业场景下的智能体开发、工作流的编排以及知识库驱动型应用。但是最终没有选择Dify主要是基于下面几个方面考虑我们对知识库检索能力有较高要求希望在召回策略、排序逻辑、上下文拼接等环节进行深度优化。这部分是 AI 客服的核心能力我们更希望逻辑完全自主可控。私有化部署也需要额外的服务器的成本和运维成本对我们当前阶段而言是没有必要的真实使用你们才知道开源版本会少了什么。在实际测试中我们发现 Dify 的执行链路相对较长尤其在知识检索节点整体响应时间偏长不完全符合我们对实时性的要求。即使使用Dify实际落地过程中依然会涉及系统对接、数据适配和定制开发等工作并非零成本集成。综合这些因素我们最终决定自己写代码从底层能力开始搭建虽然前期投入更高但在可控性、性能优化空间以及长期演进能力方面更有优势。并且自己写代码事实上成本也并不高…解决了第一个问题很多同学第二个问题也就出现了那么我们的AI客服要不要直接用Agent模式呢Workflow还是Agent项目开始阶段除了要决定使用Dify还是工程化代码开发模式也需要在Workflow和Agent中做出选择。Agent是具有高度自主性的智能体但是结果的确定性、性能等都不占优势通常客服场景会选择比较保守的做法先按照Workflow的方式搭建稳定的流程来追求确定的、能控制的结果。从工作流程入手逐步引入并解决每一个遇到的问题同时兼顾效果、成本和可控制程度。至于后期要不要“升级”Agent版本完全看业务需要业务上几乎不追求这些时髦的东西。基础流程设计在确定基础技术选型后就可以进行流程设计了在第一个版本中我们把意图分为产品咨询和闲聊大致的流程如下但是很快我们发现用户除了咨询常见的产品功能问题还会反馈一些产品建议以及程序故障等问题。而这一部分内容的处理逻辑与单纯的产品咨询其实是不太一样的用户反馈的问题是需要存入数据库并且根据问题的严重程度划分等级方便我们及时跟进修复处理。在初版的基础上面我们增加了优化建议、故障反馈的意图处理流程。具体流程如下这也就是我们方法论中所述的整理大表了在基础意图整理差不多后就可以进入最重要的知识梳理环节了unsetunset知识整理unsetunset要做AI知识库的同学一定要注意数据才是灵魂如果有人说做AI项目不深度聊数据那么他大概率是没做过的…产品知识是AI客服的基础这也是为什么我们非要等半年才做客服的原因只有提供优质的知识才能让AI输出优质的回答否则就是垃圾进垃圾出。在数据不全的情况下不管做再多的工程化优化都是无用功所以说RAG的本质是个数据工程大家一定要去理解这到底是在说撒。具体在做AI客服知识梳理时理论上来说要求是很高的它最好来自这个产品最有解释权的人但是知识的完备性需要持续的迭代更新才能覆盖完全。真实情况是所有知识库应用初始阶段都存在类似的情况所以允许知识覆盖不全在迭代中逐步补齐知识并且后面用数据飞轮的策略来自动化的完善知识不足的问题变成了主流。具体到这个项目我们的知识来源于两部分内容一部分内容是人工整理的另外一部分是历史客服数据。在进行知识整理时就需要考虑如何组织知识才能有更好的检索效果而检索的效果很大程度是取决于数据处理是否正确比如每个分块的语义是否完整独立。因此输出的知识一定要能够单独成块可以利用Markdown格式进行结构的化层级进行整理在分块时可以根据标题进行分割知识内容大致形式如下另一方面我们导出了所有历史客服对话数据这里主要根据会话维度进行分析因为数据较多不太可能人工整理可借助AI分析提取每个会话中有效的问答记录。当然这里也不能一次性把所有的数据给到大模型整理有两个原因一是数据太多会超出大模型上下文限制二是数据太多幻觉增加准确率会降低处理的策略是拆分为多个批次进行整理比如每10个会话为一个批次我们借助Coze搭建了一个自动化处理工作流流程如下PS这里也可以看出来我们其实也使用Coze但一般是来做一些自动化小操作用完就走从数据库导出会话记录时每10个会话导出为一个会话记录文件最终会导出若干个会话记录文件然后把这些文件上传到coze工作流上进行批量处理生成的问答对内容都会被写入飞书多维表格中。最终表格中的内容必定会存在重复的内容再把表格中整个内容给到大模型进行分析把内容去重处理形成最终的问答对。通过这两种方式我们就得到了最终的产品知识数据这一步非常重要也非常耗费精力并且需要真正懂这个产品的人来做才能取得好的效果。可以认为这一步没做好那么AI客服的效果一定会差在数据整理结束后就进入了知识库构建环节unsetunset知识库构建unsetunset这里技术实现Python FAISS MYSQL qwen(text-embedding-v4)向量库选择Meta公司开源的FAISS非常轻量嵌入模型使用千问的text-embedding-v41024维度它在中文场景下表现更好。数据存储的结构整个知识库由库、集合和数据 3 部分组成。集合可以简单理解为一个文件一个库中可以包含多个集合一个集合中可以包含多组数据最小的搜索单位是库也就是说知识库搜索时是对整个库进行搜索而集合仅是为了对数据进行分类管理与搜索效果无关。向量存储的结构使用 Faiss 作为向量检索引擎使用 MySQL 作为业务数据存储数据库实现知识入库与向量召回的分离式架构设计。这里Faiss只负责向量存储与相似度检索MySQL负责原始知识数据与业务字段存储向量检索引擎可独立替换为其它向量数据库比如Milvus、Weaviate等不影响业务数据库结构。而这两者间的关系通过向量ID进行关联在MySQL的dataset.datas表中会存储向量原数据的信息同时有一个vectorId字段会记录其对应的向量ID。知识入库是一个离线过程大致流程如下先加载知识文档对文档进行分块然后把分块存入到mysql业务数据库中此时向量化状态为待向量化向量ID字段为null然后通过异步事件驱动把每一个分块chunk使用向量模型进行向量化得到向量坐标之后存入Faiss向量库中存入向量库完成后会生成向量ID然后在把这个向量ID存入到mysql对应的chunk中的vectorId字段并且将向量化状态更新为已向量化知识检索流程如下使用向量模型对用户的问题进行向量化得到向量然后使用 Faiss 执行相似度搜索召回TopK个向量ID同时得到相似度得分拿到召回结果后根据向量ID去MySQL数据库中查询该向量ID对应的原始文档chunk数据知识入库在知识整理完之后使用代码对markdown格式的知识按照结构层级进行分块得到结构化的JSON数据然后存入业务数据库和向量库中。把一级标题设置为category字段把最后一级标题设置为questions段落内容设置为answer字段如果存在三级以上的层级把1到n级标题通过“-”链接设置为category字段n级标题设置为questions字段。我们得到的分块内容如下结构这里只列举核心字段{ category: 产品概念, questions: [ 空气小猪解决的核心问题是什么? ], answer: 很多用户长期学外语遇到的真实问题包括\n外语只存在于“学习时间”无法进入日常生活\n输入和输出被割裂学到的语言很难迁移到真实使用\n听力和阅读材料与个人生活无关难以长期坚持\n空气小猪并不通过增加学习任务来解决这些问题而是通过重用已经发生的聊天内容为用户建立一个长期、低成本、真实相关的外语环境。, keywords: [] }得到若干上述分块结构之后按照前面的流程把每个分块存入mysql数据库并存入向量库中。需要注意的是向量化的文档内容并不是直接把这个JSON进行向量化这里JSON结构主要是为了拿到文档分块的结构化信息方便元信息获取及存储。向量化的真正文本内容为categoryquesionsanswer的拼接内容。在这一步我们最初犯了一个错误我们把生成的原始chunk使用大模型针对问题进行了泛化处理泛化后的结构为{ category: 产品概念, questions: [ 空气小猪解决的核心问题是什么?, 空气小猪主要解决了什么问题? 空气小猪的核心价值是什么? ], answer: 很多用户长期学外语遇到的真实问题包括\n外语只存在于“学习时间”无法进入日常生活\n输入和输出被割裂学到的语言很难迁移到真实使用\n听力和阅读材料与个人生活无关难以长期坚持\n空气小猪并不通过增加学习任务来解决这些问题而是通过重用已经发生的聊天内容为用户建立一个长期、低成本、真实相关的外语环境。, keywords: [] }也就是把一个问题泛化为多个可能的问题以提升召回命中率并且在存储时按照一问一答的结构进行储存也就是把问题1 答案、问题2 答案、问题3 答案 分别进行存储。最后在知识召回时就出现问题了同一个问题很大概率会召回相同的文档信息并且这部分的得分还比较高于是取Top-K时召回的数据都是一样的只是问题不一样这就导致其它可能更相关的内容被挤掉。接下来是检索流程unsetunset检索过程unsetunsetRAG系统在检索这里比较重要的是意图识别。所以前置的意图分类这一步就至关重要真实用户的问题是非常发散的第一步就需要对用户的意图进行收敛收敛的目的是为了匹配后续的流程以及更好的匹配到我们知识库中的知识。我们在把第一级大类意图拆分为产品咨询、故障反馈、闲聊然后通过代码进行路由分发分别走不同的处理流程但是这里要让大模型准确判断是哪一个意图需要继续细化用户的二级意图比如什么情况下应该匹配到产品咨询上什么情况匹配到故障反馈上你需要给大模型一个明确的评价标准这个二级意图就是用来辅助大模型判断一级意图的标准。否则在意图识别这一步很可能就直接出错后续的回答肯定就不准确了。这里整理的思路也跟大家简单分享一下一是从产品本身梳理我们提供了什么、主要解决什么问题二是从用户的角度进行梳理我能得到什么、对我英语有没有提升怎么用然后对两者进行融合通过客服历史问答数据我们提炼了用户的高频问题这里给了非常大的参考价值。下面是我们梳理的一些高频问题类别这里再摘抄部分意图识别的提示词## 角色 你是 空气小猪 App 智能客服系统的专业意图识别器。 你的输出将被直接用于自动路由和客服决策请严格遵循规则不得自由发挥。 ## 总体目标 基于【对话历史】和【用户最新消息】完成以下 两个任务 1. 指代消解必须先完成 2. 意图识别基于指代消解后的问题 ## 任务一指代消解 目标 结合【对话历史】对【用户最新消息】中的所有指代性表达进行消解你需要生成一条单句、语义完整、无任何模糊指代的用户问题 处理规则 1.必须结合【对话历史】进行还原 2.如果用户问题本身已经明确不要强行改写 3.不得引入对话中不存在的新信息 4.输出必须是一个完整问题句 输出字段 resolved_question ## 任务二意图识别 基于 resolved_question结合【对话历史】信息进行理解将其准确分类到以下三个意图之一并且按照顺序依次判断 1. **产品咨询(SUPPORT)** , 判断标准为 { 空气小猪小猪相关问题 产品功能介绍/产品价值/能解决什么问题 使用方法/操作步骤/使用教程 下载安装/注册登录/账号相关 产品定价/会员/付费 与竞品的比较 翻译/语言支持/语言学习相关 播放/播客/朗读 聊天/加好友/社交/翻译对话相关 任何“如何用空气小猪做某事”的问题 } 2. **问题反馈(FEEDBACK)**, 判断标准为 { 用户明确提出对空气小猪产品功能优化建议、希望增加功能、优化建议、故障反馈比如功能异常、报错、打不开、点不动、卡顿、无法使用等 } 3. **闲聊(CHAT)**判断标准为 { 当不属于以上两类时一律归为 CHAT例如问候、寒暄、玩笑、调侃、情感倾诉、模糊无意义输入 } ## 输入信息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用户输入的翻译翻译为%s 2. **必须**使用以下JSON格式返回不得包含任何其他文本 { confidence: 0.0-1.0, intent: SUPPORT | FEEDBACK | CHAT, resolved_question: 指代消解后的明确问题, translation:用户输入的翻译, reason: 简要分类理由说明上下文如何影响判断 }从提示词的设计可以看出我们不仅对用户的提问进行了意图识别还在这之前增加了指代消解的处理步骤。也就是说在完成指代消解之后才进入意图识别阶段。PS事实上也可以将这个提示词再拆分以符合提示词原子性的要求我们这里因为是做案例讲解就不麻烦了至于之所以需要进行指代消解是因为在实际使用过程中我们发现用户往往会将一个完整的问题拆分成两句话或者在后续提问中使用上下文中的指代词例如用户先问“空气小猪是干什么的”接着又问“它怎么用”如果将第二句话直接用于检索很可能无法获得有效结果而真正符合用户意图的检索语句应该是“空气小猪怎么使用”。因此我们借助大模型结合上下文语境对用户最新的问题进行指代消解将其中的指代词还原为具体对象。这样可以提高意图识别、以及检索的准确性使整体流程更加连贯和高效。在意图识别这个环节中模型经历了从GPT-4.1到Qwen-plus-latest、Qwen-max-latest再到Qwen3-max、Qwen-plus的选择过程。GPT-4.1作为效果标杆Qwen系列则需要通过提示词优化或节点拆分来提升表现。值得一提的是Qwen-plus在未修改提示词的情况下即有提升整体效果还可以。我们这里场景不算复杂为了均衡成本和效果我们模型最终选择了Qwen-plus, 如果需要更好的效果可以考虑Qwen3-max或GPT4.x等模型。模型的选择可以根据项目阶段来确定项目初期选择参数较大的模型进行验证并快速上线后期则在保证意图识别准确率不下降的前提下逐步替换为成本更低的模型以实现效果与成本的平衡。总之我们每个项目做的时候都会用最好的模型后续实际上线都是各种成本考虑…问题泛化在正式进入检索阶段之前需要先对用户问题进行一系列语义预处理最大程度提升后续检索的召回率与覆盖面。首先通过指代消解技术对问题中的代词、模糊指称和上下文依赖表达进行还原。例如将“他”“这个”“那个”等模糊表达结合上下文明确为具体的名称从而避免检索阶段因语义歧义而遗漏关键信息。其次我们基于原始问题进行多问题生成Query Expansion Multi-Query Generation。利用大模型的语义理解和重写能力从不同角度、不同表达方式对同一问题进行改写扩展。比如同义词替换与表达重构、从不同维度拆解子问题、将抽象问题转化为更具体、可检索的表达语句。通过这种方式可以将一个单一问题扩展为多个语义相关但表达不同的查询语句。这种多路查询策略能够覆盖更多潜在的匹配结果以提升召回率同时减少因表达方式单一或者口语化而导致的信息遗漏。## 角色 你是“空气小猪”智能客服系统的查询优化专家专门处理**产品咨询**类查询的泛化改写任务把用户问题泛化成检索友好的中文查询用于知识库向量检索 ## 改写规则 1. 如上下文中出现了关键实体产品名、功能名、版本、平台、错误码、按钮文案等改写需保持一致。 2. 不要引入上下文里不存在的具体数值、版本号、错误码、功能名。 3. 生成的每条查询都要尽量短、包含关键关键词、便于命中知识库。 4. 若用户输入不是中文请先理解其含义再用中文生成改写查询。 5. 改写要有多样性每条改写应有不同侧重点 ## 输入信息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 - rewritten_queries 严格 5 条每条为 string。 - **必须**使用以下JSON格式返回不得包含任何其他文本 { original_query: string, rewritten_queries: [ string, string, string, string, string ] }上下文管理每次让大模型进行意图识别、问题泛化、回答问题时除了把用户最新的消息传进去之外还需要把历史会话消息传递进去这样才能确保大模型理解对话语境。但是这里存在一个问题应该携带多少条历史消息合适呢太少的话大概率会丢失上下文信息大模型回答会偏携带太多速度会慢、token消耗会变大干扰信息太多会产生幻觉。如果简单固定携带10条-20条历史消息在大多数情况下是可以的但仍然存在明显的缺陷更早的关键对话信息就丢失了。因此单纯使用“固定条数”的策略没法在上下文完整性和资源成本之间取得比较好的平衡。为此这里也做了一个优化策略对记忆进行了分层分为短期记忆和长期记忆。短期记忆比较好理解就是每次携带N条最新的会话消息这部分信息保持原始表达不做信息压缩尽量保证对话语境的连续性和即时性。除此之外还会携带历史消息的摘要信息历史摘要信息的生成规则是每满N条消息就会进行一轮异步压缩并把摘要信息存入业务数据库中持久化保存。需要注意的是这里的历史摘要信息携带数量并不是全量的也完全没有必要全量携带举例说明比如我们每30条消息进行一轮压缩如果携带10条摘要信息那这里就是300条历史消息的摘要信息了用户最新的聊天可能早已跳出之前的对话语境。下面是历史消息摘要生成的示例提示词# 角色 你是一个对话总结助手任务是把下面的对话片段总结为一条可用于后续意图识别的“历史摘要”要求尽量节省token但保留关键信息。 # 规则 1. 只总结事实与诉求用户关心点、问题、偏好、已给出的关键信息、未解决点 2. 不要杜撰不要引入对话中没有的信息 3. 输出长度建议 120-220 字/词左右按语言自然长度 # 对话片段 { %s } # 输出要求 返回如下JSON格式不要返回多余内容 { summary: string }我们在让大模型意图识别、问题泛化以及回答问题时我们携带的消息上下文构成如下当然除了上面这种按照固定条数进行压缩之外我们也可以根据达到一定的token数量才进行压缩。这里根据具体场景进行选择。检索方案前面我们针对用的问题进行了泛化处理把一个问题改写为多种不同的表达方式利用多路查询提升知识召回率然后对于每个问题我们又使用了混合检索策略进行搜索。这里的混合检索就是语义检索和全文检索的组合使用之所以采用这种方式是因为这两者在能力上具有互补性语义检索擅长理解语义层面的相似性而全文检索则擅长精确关键词匹配从而弥补单一检索策略各自的局限。语义检索是通过向量距离计算用户问题与知识库内容的距离从而得出“相似度”。需要注意的是这并不是语言学上的相似而是数学空间中的距离相近。它的优势就是能够找到语义相近的知识但是它的精度较低会受到关键词和句子完整度影响。而全文检索我们采用BM25算法BM25主要基于词频和逆文档频率TF-IDF的加权搜索模型来对文档进行排序和检索。它特别适用于处理较为简单的匹配任务尤其是当查询和文档中的关键词有直接匹配。为此通过“多问题查询 混合检索”我们会获得一批候选知识。但此时的结果集合规模较大、质量参差不齐因此还需要进一步筛选才能得到真正符合需求的内容。那我们应该如何处理呢首先对相同检索方式的结果使用RRF进行合并得到两类候选结果分别为向量检索结果、BM25检索结果由于混合检索后的查找范围很大单纯依赖原始相似度分数难以直接过滤结果因此需要引入重排模型进行精细排序。重排模型reranker对候选结果重新评分并根据相关度重新排序绝大多数情况下可以有效提高搜索结果的准确率。重排后可以得到一个0-1得分代表着搜索内容与问题的相关度该分数通常比向量的得分更加精确可以根据得分进行过滤。最后我们会使用 RRF 对重排结果、向量搜索结果、全文检索结果进行合并得到最终的搜索结果。单个问题的向量检索流程与前面讲解的流程一致这里多问题并行向量检索的流程如下我们使用的Faiss向量库以及MySQL并不直接支持BM25检索我们采用的策略是先拿到所有的知识分块片段并结合用户的问题利用LangChain提供的BM25Retrieve进行计算核心代码逻辑如下# 使用 BM25Retriever bm25_retriever BM25Retriever.from_documents(splitsDoc) bm25_retriever.k 3 # 返回前3个最相关的文档 # 使用 bm25_doc bm25_retriever.invoke(query) print(fbm25_retriever检索到 {len(bm25_doc)} 个相关文档块:)至此其实AI客服的核心流程都被覆盖了剩下的也就是最后的生成环节反而简单了unsetunset生成阶段unsetunset我们把大的意图分为了三个分别是产品咨询、故障反馈、闲聊进入每个意图后处理的逻辑是存在差异的因此大模型生成回答的提示词是不同的。提示词的重点是构造上下文信息拼装召回的知识、最新的N条对话历史消息、更旧的历史摘要消息以及用户最新的问题。下面是具体的提示词需要注意的是知识召回后在大模型真正生成回答时会让他再次判断召回的知识是否可以回答用户问题如果没用则拒绝回答并且把useful字段设置为false否则设置为true。这个字段的用处在于我们会对大模型回答的问题进行标记不能回答的问题会进入低置信度问题池列表便于后续知识补足和复盘是为后面的数据飞轮做准备的## 角色 你是空气小猪产品客服助手你需要根据对话历史、用户最新消息、以及知识回答用户问题 ## 回复原则 1. **简洁明确**直接回答不绕弯不要超过100字 2. **友好专业**保持礼貌体现专业性 3. **客观公正**遵循客观事实不要胡编乱造所有回答的内容都需要在【知识】内容中有迹可循宁可不答也不要错答 4. 如果知识库资料与用户反馈高度相关给出可执行的解决/排查步骤或替代方案并将 usefultrue 5. 如果资料不相关或不足以解决将 usefulfalse并回复用户暂时不能回答这个问题 ## 知识 { %s } ## 上下文消息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用中文回复不超过100字 2. 给出回复内容的%s翻译 3. **必须**使用以下JSON格式返回不得包含任何其他文本 { useful: boolean, content: string, translation: string }当用户意图匹配为“故障反馈”或“功能建议”时需先确认用户反馈的问题内容并检查相关功能是否已存在如果功能已存在引导用户正确使用或提供解决方案。如果功能不存在需要评估用户需求是否符合产品原则以及是否属于明确“不做”范围如果属于“不做”范围明确说明并予以拒绝如果不属于则继续收集信息。 在信息不足的情况下需要引导用户补充详细描述随后对用户的反馈进行数据清洗并判断反馈类型故障或优化建议再分类存入业务数据库便于后续跟进与处理。## 角色 你是空气小猪产品客服助手专门负责处理用户建议和产品故障反馈。 ## 产品核心理念 { %s } ## 处理流程 仔细阅读【产品核心理念】、【知识】、【上下信息】按照如下要求进行处理 ### 1. 功能建议处理流程 #### 第一步功能状态判断 首先判断用户建议的功能是否**已经存在** - **已存在**明确告知用户该功能已支持并提供简要使用指引 - **不存在**进入下一步评估 #### 第二步原则性评估 检查建议是否符合 - **产品核心原则**符合空气小猪产品定位和核心价值观 - **明确不做清单**是否属于已明确排除的功能范畴 评估结果处理 - **符合原则且不在排除清单** - 回复**“感谢您的宝贵建议我已经记录并反馈给产品团队进行评估我们会认真考虑这个功能的可行性。”** - 无需承诺具体实现时间 - **不符合原则或在排除清单** - 友好、明确地拒绝 - 回复示例**“感谢您的建议。不过这个功能目前不符合我们的产品方向。期待您提出其他改进建议”** ### 2. 故障反馈处理 - 引导用户详细描述问题现象 - 告知用户已反馈给技术团队 ## 回复原则 1. **简洁明确**直接回答不绕弯不要超过100字 2. **友好专业**保持礼貌体现专业性 3. **不过度承诺**不承诺功能上线时间或具体解决方案 4. **客观事实**不要胡编乱造必须要从知识中拿到可靠的依据 ## 知识 { %s } ## 上下文消息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用中文回复不超过100字 2. 给出回复内容的%s翻译 3. **必须**使用以下JSON格式返回不得包含任何其他文本 { content: string, translation: string }对于严肃型产品服务场景如电商、医疗、金融等通常不建议提供闲聊功能应优先保证回答的准确性和可靠性在无法确认答案时宁可不回答也不应提供可能误导用户的信息。但在语言学习类应用中我们有意引入“闲聊意图”目标是让 AI 客服具有更自然、有温度的互动体验而不是仅提供机械式回复。通过适度的闲聊能力可以增强用户参与感与陪伴感从而提升整体使用体验与产品黏性## 角色 你是空气小猪产品客服助手擅长陪伴用户进行轻松有趣的闲聊。你的核心任务是在自然对话中传递产品价值并收集有助于改进的用户反馈。 ## 产品核心理念 { %s } ## 对话风格 - 亲切、自然像朋友聊天一样 - 避免推销感注重倾听和共鸣 - 根据用户回答灵活调整不强行推进问题 - 在解释产品理念时尽量用口语化的例子或场景说明 ## 引导反馈顺势、递进、不要一次问完 1. 你是怎么了解到我们产品的呀 2. 最近使用起来感觉怎么样有没有特别喜欢的部分 3. 如果让你提一个建议你会希望我们改进什么 4. 方便问一下你现在是学生还是已经工作了吗 ## 输入信息 ### 对话历史 { %s } ### 用户最新消息 { %s } ## 输出要求 1. 用中文回复不超过50字。 2. 给出回复内容的%s翻译 3. **必须**使用以下JSON格式返回不得包含任何其他文本 { content: string, translation: string }unsetunset再说可观测性unsetunset前面的内容整个客服的流程就已经拉通了从知识整理、知识入库到问答流程。现在我们需要进一步调优就要观察关键的环节是否符合我们的预期比如意图识别准不准、指代消解对不对、问题改写质量如何、知识召回质量高不高、提示词有没有问题我们需要对每个环节的耗时进行观测。为此我们在流程关键节点对核心信息进行了结构化存储包括指代消解、用户问题改写意图识别结果向量召回的候选结果列表及置信度最终命中的知识内容及回复结果大模型调用日志在后台管理系统中可以看到全流程关键节点的输入和输出信息可以直观地观测整个 AI 客服的运行状态。比如意图识别轨迹列表、客服向量召回结果列表、问题改写列表…通过对这些核心节点的持续监测、分析可以将原本不可见的系统运行过程由“黑盒”转变为“透明”从而实现问题可定位、效果可评估、策略可优化支撑整体能力的持续迭代与提升。unsetunset数据飞轮unsetunset这里必须说清楚我们搭建的客服系统知识现在仍然不是很完备无法覆盖用户所有的问题除了人工补齐的方案我们也增加数据飞轮系统功能。数据飞轮本质上是一种持续反馈的闭环机制通过从用户交互中不断收集数据 → 处理 → 优化 → 再反哺系统 让 AI 在真实业务中越用越准当然这里并不是把所有的问题都放进知识库而是识别哪些问题值得沉淀持续补全真正有价值的知识缺口下面结合实际系统设计介绍在 AI 客服中如何对低置信度问题进行收集并持续优化知识库。置信度在前文我们提到过AI 客服的第一步是 意图识别。当用户提问后系统会先给问题打标签例如产品咨询在对应标签下进行向量召回每条召回结果都会有一个 置信度score这个置信度代表的是用户问题 与 知识库内容 的语义匹配程度分值越高说明命中越精准分值越低往往意味着知识库存在缺失或覆盖不足在系统中我将置信度阈值设置为 0.5。当召回置信度 ≥ 0.5时直接走正常回答流程当召回置信度 0.5时认为当前知识库匹配度较低此时系统会异步处理这条问题数据进入数据飞轮流程。问题标准化模型会基于下面的提示词完成两件关键事情将用户的原始提问进行标准化处理生成一个示例答案作为后续处理与参考依据例如 用户原话 “我在日本用 81 的手机号能不能注册啊不行我就换国内的” 整理后的标准问题国外手机号非中国大陆是否支持平台注册这一步在信息检索领域中通常被称为 Question Canonicalization问题规范化因为用户的表达通常是口语化、上下文依赖很强并不适合用于直接存储或检索在进入数据飞轮流程前需要先将问题转化为结构清晰、语义稳定的标准形式以提升后续召回、匹配与分析效果。你是智能客服的知识运营助手。你要把“用户原话”整理成可入库的标准问题并尝试与候选问题合并。 目标 1) 去噪去掉情绪、口语、无关碎片只保留核心诉求 2) 标准化输出“真实意图”的标准问题用中文尽量像FAQ标题 3) 合并判断是否与候选问题同一意图如果是返回 matched_question_id否则返回 null 4) 初步解答基于标准问题给出一段中文初步解答如果信息不足说明需要用户补充哪些信息 约束 - normalized_question 必须是单行文本长度不超过 120 字 - 如果候选列表里没有同一意图的问题matched_question_id 必须为 null - 只返回严格 JSON不要输出多余内容 候选问题JSON数组 { %s1 } 用户原话 { %s2 } 输出JSON { normalized_question: string, matched_question_id: 123, ai_suggested_answer: string }数据入库与前后台分工处理完成后的数据会进入入库流程用户端负责数据采集低置信度问题自动进入待处理队列后台管理端人工审核决定是否写入知识库问题审核不是所有问题都值得沉淀在后台中人工需要先对问题进行审核当看到某条问题的召回置信度低于 0.5 时需要判断是否为正常业务问题是否存在垃圾信息、无意义输入或不当言论…同时也并不是所有问题都适合入库低频问题不值得沉淀强时效性问题会自然过期模型误判为“低置信度”的情况一定存在只有审核通过的问题才会进入向量化流程。这里系统也设置了相似问题出现的次数可以根据问题出现次数判断重要性效果验证完成向量化后知识库中会新增一条元数据当下次出现语义相近的问题时向量检索会命中这条新数据AI 客服能够给出更贴合的回答。通过数据飞轮的设计能够让AI客服越用越准。unsetunset结语unsetunset通过空气小猪 AI 客服项目的实践相信各位对于什么是简单AI知识库以及AI知识库如何落地会有更深的理解了。最后文章篇幅已经很长了这里就不再赘述只是再强调下数据才是AI客服的灵魂…如何学习大模型 AI 由于新岗位的生产效率要优于被取代岗位的生产效率所以实际上整个社会的生产效率是提升的。但是具体到个人只能说是“最先掌握AI的人将会比较晚掌握AI的人有竞争优势”。这句话放在计算机、互联网、移动互联网的开局时期都是一样的道理。我在一线互联网企业工作十余年里指导过不少同行后辈。帮助很多人得到了学习和成长。我意识到有很多经验和知识值得分享给大家也可以通过我们的能力和经验解答大家在人工智能学习中的很多困惑所以在工作繁忙的情况下还是坚持各种整理和分享。但苦于知识传播途径有限很多互联网行业朋友无法获得正确的资料得到学习提升故此将并将重要的AI大模型资料包括AI大模型入门学习思维导图、精品AI大模型学习书籍手册、视频教程、实战学习等录播视频免费分享出来。第一阶段10天初阶应用该阶段让大家对大模型 AI有一个最前沿的认识对大模型 AI 的理解超过 95% 的人可以在相关讨论时发表高级、不跟风、又接地气的见解别人只会和 AI 聊天而你能调教 AI并能用代码将大模型和业务衔接。大模型 AI 能干什么大模型是怎样获得「智能」的用好 AI 的核心心法大模型应用业务架构大模型应用技术架构代码示例向 GPT-3.5 灌入新知识提示工程的意义和核心思想Prompt 典型构成指令调优方法论思维链和思维树Prompt 攻击和防范…第二阶段30天高阶应用该阶段我们正式进入大模型 AI 进阶实战学习学会构造私有知识库扩展 AI 的能力。快速开发一个完整的基于 agent 对话机器人。掌握功能最强的大模型开发框架抓住最新的技术进展适合 Python 和 JavaScript 程序员。为什么要做 RAG搭建一个简单的 ChatPDF检索的基础概念什么是向量表示Embeddings向量数据库与向量检索基于向量检索的 RAG搭建 RAG 系统的扩展知识混合检索与 RAG-Fusion 简介向量模型本地部署…第三阶段30天模型训练恭喜你如果学到这里你基本可以找到一份大模型 AI相关的工作自己也能训练 GPT 了通过微调训练自己的垂直大模型能独立训练开源多模态大模型掌握更多技术方案。到此为止大概2个月的时间。你已经成为了一名“AI小子”。那么你还想往下探索吗为什么要做 RAG什么是模型什么是模型训练求解器 损失函数简介小实验2手写一个简单的神经网络并训练它什么是训练/预训练/微调/轻量化微调Transformer结构简介轻量化微调实验数据集的构建…第四阶段20天商业闭环对全球大模型从性能、吞吐量、成本等方面有一定的认知可以在云端和本地等多种环境下部署大模型找到适合自己的项目/创业方向做一名被 AI 武装的产品经理。硬件选型带你了解全球大模型使用国产大模型服务搭建 OpenAI 代理热身基于阿里云 PAI 部署 Stable Diffusion在本地计算机运行大模型大模型的私有化部署基于 vLLM 部署大模型案例如何优雅地在阿里云私有部署开源大模型部署一套开源 LLM 项目内容安全互联网信息服务算法备案…学习是一个过程只要学习就会有挑战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】战。天道酬勤你越努力就会成为越优秀的自己。如果你能在15天内完成所有的任务那你堪称天才。然而如果你能完成 60-70% 的内容你就已经开始具备成为一名大模型 AI 的正确特征了。这份完整版的大模型 AI 学习资料已经上传CSDN朋友们如果需要可以微信扫描下方CSDN官方认证二维码免费领取【保证100%免费】
)
