1. 先把整个问题想清楚智能客服系统到底在解决什么1.1 它不是一个“会聊天的机器人”而是一套能理解、决策、执行、反馈的系统很多人一提客服系统就把重点全部放在大模型会不会回答上。但企业里真正的客服系统从来不只是一个问答框。它至少要完成四件事第一听懂用户到底想干什么第二判断下一步该问什么、查什么、做什么第三真的去执行比如查订单、走退款、调工单、查文档第四把失败案例、满意度和转人工原因再收回来持续改进系统。所以面试里如果被问“整个客服系统怎么做”最稳妥的答法不是先讲模型而是先讲链路输入清洗 → 意图识别 → 对话管理 → 执行层 → 反馈闭环。2. 其他可用框架有哪些为什么很多场景会考虑 Rasa Pro2.1 框架不止一个但业务形态会决定选型如果你只是快速搭一个演示型助手那么低代码平台、LangChain 类编排、甚至一个简单的 RAG 流水线都能做出来。但如果业务更偏任务型比如查单、退货、报修、改地址、预约、催单、投诉处理这些对“状态、分支、追问、规则、兜底”非常敏感那么选型逻辑就不一样了。Rasa Pro 的特点不在于单点大模型能力而在于它对对话管理和工作流的支持更偏企业化。官方文档里也强调了 security、analytics、observability 这些生产级能力。这意味着它更适合那些需要可控、可追踪、可治理的客服场景。2.2 为什么不是把一切都交给大模型因为客服业务里有大量“不能随便猜”的动作。比如用户要退款、改地址、取消订单、创建工单这些动作一旦执行错损失是直接的。所以更合理的做法是让大模型负责理解、改写、补全和解释让流程系统负责最终裁决和执行。这样既能用到大模型的灵活理解能力也能保住企业系统最重视的稳定性和可控性。3. 客服系统常见业务评价指标有哪些3.1 真正能打动面试官的是把指标分成三层第一层是业务指标比如首问解决率、转人工率、任务完成率、用户满意度、投诉率、复访率。第二层是模型和检索指标比如意图识别准确率、F1、FAQ 命中率、RAG 召回质量、答案准确率。第三层是工程指标比如平均时延、P95、失败率、并发吞吐、成本和缓存命中率。面试里如果只说准确率很容易显得不懂业务。因为客服系统的价值不是模型分高而是能不能少转人工、快解决问题、稳控制成本。4. 对话管理是怎么做的4.1 对话管理本质上是在回答一个问题下一步该做什么对话管理可以简单理解为“保存状态再决定动作”。状态里通常包括当前用户在哪个任务里、已经收集到哪些信息、还差哪些槽位、上一轮系统做了什么、当前置信度高不高。动作则可能是继续追问、查 FAQ、走 RAG、调 API、发工单、转人工。如果你想把这块讲得更像做过项目的人可以强调四个对象State、Slot、Policy、Executor。State 是当前会话状态Slot 是任务所需参数Policy 决定系统采取什么策略Executor 负责真正去执行接口、知识库或工作流。5. 意图识别怎么做如何接入大模型5.1 最好做成“分层识别”而不是单点分类一个实用的客服意图识别方案通常会先做文本清洗和标准化然后做粗分流比如先分成 FAQ、任务、闲聊、投诉、兜底再在子类内部继续做细分。与此同时还要抽取关键实体比如订单号、商品名、时间、地址等。5.2 大模型不一定是“替代者”更适合做“增强器”大模型最适合接在三个地方第一做 Query Rewrite把用户口语化描述改得更标准第二做难例裁决当小模型区分不清时让大模型在候选意图里做二次判断第三做意图发现从大量未命中样本中总结新标签。这样能最大化发挥大模型的理解优势同时不让整个系统变成黑盒。6. 意图的数量、评价指标和标注应该怎么设计6.1 意图数量不是越多越好而是要服务业务主流程很多团队一开始就把意图拆得特别细结果标签体系爆炸、数据标不动、模型也训不稳。更好的方式是先按业务主链路做一级分类比如查单、退款、投诉、报修、售后、账户再逐步往下细化成二级类和三级类。6.2 标注时除了意图还要标“可执行性”只标一个意图标签其实不够。实战里建议同时标意图标签、槽位实体、是否需要追问、是否需要转人工、最终处理路径。这样做的好处是后续你不仅能训练分类器还能训练更完整的任务决策模型。评估方面常规上会看准确率、召回率和 F1对多类别和长尾类别要看混淆矩阵避免被头部意图把整体分数“冲漂亮了”。7. 客服系统里的 FAQ 怎么做7.1 FAQ 适合“高频、稳定、标准答案明确”的问题FAQ 是客服系统里最快、最稳的一层。像运费规则、退款条件、发票说明、会员权益、常见物流时效这些问题都很适合做 FAQ。一个高质量 FAQ 不只是一个问题和一段答案还应该包含相似问法、适用范围、答案来源和更新时间。7.2 FAQ 不是和 RAG 对立而是可以成为 RAG 的高优先层很多工程上会先做 FAQ 命中命中就快速直出命不中再进入向量检索或 GraphRAG。这样既快又能保证常见问题的稳定性。8. 如果用户描述已经做了清洗但依然无法匹配正确工作流该怎么办8.1 不要一上来就怪模型先按链路排查最常见的原因有五类第一意图被分错了第二槽位没抽出来第三正确流程根本没被召回第四流程描述太像缺少有效重排第五置信度低时没有澄清系统硬猜了一个。所以更稳的处理方式是先补槽位再做候选流程召回然后结合流程说明、节点摘要、历史样例做重排如果仍然低置信度就主动追问用户连续失败则及时转人工。9. GraphRAG 为什么会用怎么用9.1 当知识之间“关系很重要”时GraphRAG 的价值就出来了普通 RAG 更擅长“从文档片段里找相关文本”。但客服里有些问题不是一个片段能说清的而是要把用户、订单、商品、规则、物流节点、工单状态关联起来。比如“为什么这个订单不能退货”答案往往需要同时看订单状态、商品类型、售后规则和时效限制。GraphRAG 的思路就是先从非结构化文本里抽出实体和关系形成图查询时除了走文本检索还能沿着图上的关系找上下文。这在多跳推理、跨文档关联和全局总结时很有帮助。10. 为什么对话模型会选 Qwen为什么会选择 8B10.1 选 Qwen常常是因为“中文、部署、生态、性价比”四点综合平衡中文客服场景里模型对中文口语、客服表达、指令跟随能力要求很高。Qwen 这类模型常被选用往往是因为它在中文任务、私有化部署、开源生态和工具接入上都比较友好。10.2 8B 常常是一个很务实的参数规模如果问题主要是理解、分类、标准问答、轻任务执行那么 8B 左右的模型通常已经能达到不错效果而且在显存、时延、吞吐和成本上更容易控住。更大的模型当然更强但如果每次都让大模型上场很多客服系统的成本和延迟会立刻变得不可接受。11. 对话任务执行的流程一般是什么样11.1 一个标准的任务执行闭环用户提问之后系统会先做清洗与理解然后判断意图和任务类型如果信息不足就追问收集槽位当信息足够时进入执行器调用知识库、FAQ、RAG、内部 API 或流程引擎执行结果返回后再由模型组织自然语言回复如果失败则做兜底或转人工。把这一段讲清楚很多“你真的做过系统吗”的疑问就会自然消失。12. 执行 RAG 工作流时如何平衡检索速度与答案准确性12.1 不要让所有问题都走最重的链路工程上最有效的做法通常是“问题分层”。高频简单问题先命中 FAQFAQ 没命中再走轻量向量检索只有复杂问题、低置信度问题、需要多跳推理的问题才升级到重排、多路检索或 GraphRAG。与此同时还要把检索候选数、上下文长度、缓存策略控制好。一个常用表达是简单问题走快链路复杂问题走精链路。这样才能在准确率和时延之间取得平衡。13. 模型训练的数据来源通常如何构建13.1 最有价值的数据往往来自真实业务训练数据的核心来源包括历史客服会话、FAQ、制度与产品文档、人工整理的标准问答、失败案例回流、以及强模型辅助生成的扩充样本。构建数据集时一定要先做脱敏、清洗、去重和质量筛选。一个成熟的数据集不光要覆盖高频场景还要覆盖边界场景、长尾场景和异常表达。否则系统上线后最容易在“没人预料到的表达方式”上出问题。14. 优化模型推理速度的方法有哪些14.1 先从“大头”下手模型规模、上下文长度、重复调用次数常见优化方法包括量化、KV Cache、批处理、并发调度、缩短 Prompt、裁剪上下文、多模型路由、缓存、减少不必要的工具调用以及使用更高效的推理框架。最重要的经验是不要把提速只理解成“换更快显卡”。真正有经验的团队会先优化系统路径再优化模型本身。因为很多时候慢不是慢在生成而是慢在检索太重、上下文太长、工具调用太多。15. 总结怎么把这组问题回答得又全又稳15.1 一个完整答案的主线你可以把整套系统概括为理解层做输入清洗、意图识别和实体抽取决策层做对话管理、槽位跟踪和策略选择执行层负责 FAQ、RAG、GraphRAG、API、工作流和转人工反馈层负责指标监控、错误分析和数据回流。框架层面之所以偏向 Rasa Pro是因为它更适合流程型客服模型层面之所以偏向 Qwen 和 8B是因为它们在中文效果、部署性、时延和成本之间比较均衡检索层面FAQ、RAG 和 GraphRAG 并不是互相替代而是应该按问题复杂度分层路由。如果你把这条主线讲顺面试官再怎么追问基本都能从这条主线上展开。16. 结尾总结智能客服系统真正难的地方不是“让模型会回答”而是“让系统稳定地把用户问题分对、流程走对、知识找对、动作做对”。框架、模型、知识库、工作流、评估指标和数据闭环缺一不可。从工程角度看一个好系统往往不是完全依赖某一个大模型而是规则、FAQ、RAG、工作流和大模型协同工作从面试角度看一个好回答也不是堆术语而是能解释清楚为什么这么设计、问题出在哪、如何排查、如何取舍。只要你把“理解—决策—执行—反馈”这条主线抓住再结合 Rasa Pro、GraphRAG、Qwen、8B、FAQ、RAG 优化这些关键点整套回答就会非常完整。附30 秒快答模板“我们把智能客服 Agent 系统拆成四层理解层负责输入清洗、意图识别和实体抽取决策层负责对话管理、槽位跟踪和策略选择执行层负责 FAQ、RAG、工作流、API 和转人工反馈层负责评估指标和数据回流。之所以会选 Rasa Pro是因为它更适合任务型和流程型客服状态管理、分支控制和企业可控性更强。模型上会优先选中文能力和部署性较好的 Qwen8B 往往是效果、时延和成本比较平衡的选择。知识层面简单问题优先命中 FAQ复杂问题再走 RAG 或 GraphRAG以平衡检索速度和答案准确性。”