★ FEATURED ARTICLE 前阵子我们团队做了一个“AI大模型之旅——智能客服实战”项目算是把大模型从一个“聊着玩的玩具”真真切切推进到了“能顶一班岗的业务系统”阶段。这个项目表面上是在做客服实际上是在解决一个很扎心的问题业务的知识散落在文档、工单、群聊和同事脑子里用户的问题五花八门人工客服累到脱发老板又天天催着提质增效。我们想用大模型把这块硬骨头啃下来。这篇文章就是这次实战的完整复盘包括方案怎么选、坑怎么踩、效果怎么评估。如果你正在规划智能客服或者手里有大量知识文档想做成问答形式这篇文章应该能帮你少走不少弯路。我尽量把每一步为什么这么做讲清楚而不只是贴一堆代码。1. 项目定位与整体架构1.1 客服场景的真实痛点先说背景。我们这边是某内容平台的运营团队日常面对的用户问题集中在账号、订单、活动和产品使用几个方向。人工客服每天处理几百个重复问题老客服闭着眼睛都能背答案但新客服培训一个月还是容易答错。早期的FAQ系统勉强能用但用户体验很差——用户说一句话系统只能按关键词粗暴匹配稍微换个说法就答非所问最后用户还是选择“转人工”。我在项目启动前蹲点了客服工单系统整整两天发现几个关键现象重复问题占比超过六成其中大量是“同一个问题的不同问法”。老客服回答问题时习惯引用内部文档但文档分散在多个系统检索本身就很费时间。很多问题是组合型的比如“我买了会员为什么在另一个设备上看不了”这需要把会员规则、设备绑定逻辑、常见原因串起来回答。客服的回复风格高度依赖个人经验同一问题不同人的口径不完全一致。这些痛点决定了项目的目标不是做一个人工智能聊天机器人来替代客服而是做一个能消化内部知识、给用户准确答案、必要时顺利转人工的辅助系统。这个定位直接决定了后面的技术路线。1.2 为什么选RAG而不是微调大模型项目立项时团队内部有过一次很激烈的讨论要不要微调一个开源模型。我们甚至给某实验室的大模型尝试过LoRA微调但结果并不理想。核心原因有几点。第一客服回答要求的是“知识准确性”而微调模型本质上是在学习“说话风格”和“特定任务模式”它对知识本身的掌握并不牢固特别是低频、冷门的业务规则。第二业务知识更新太快今天刚上线的活动规则明天就要能回答微调的训练链路根本来不及。第三合规和安全层面业务数据不能随意进训练集微调后模型参数里“记住”了什么谁也说不清出了问题很难排查。所以最终方案确定为RAG也就是检索增强生成。用大白话讲用户问一个问题我们先去知识库里把最相关的片段捞出来把这些片段和问题一起塞给大模型让它基于这些素材来组织回答。这样模型的“记忆能力”被检索系统替代它只负责“阅读理解和表达”准确率、可追溯性、更新效率都大大提升。这里我个人的强烈建议是能用RAG解决的场景不要轻易碰微调。RAG相当于开卷考试微调相当于闭卷背诵客服场景明显是开卷更合适。1.3 技术方案选型与团队分工在技术选型上我们画了一张很朴素的架构图不需要花哨的东西数据层业务文档、FAQ、历史工单沉淀出的标准问答对统一入库。索引层文档清洗、切片、向量化存入向量数据库。检索层对用户问题做向量检索配合关键词检索再加一个重排环节。生成层大模型API接收“问题 检索片段 历史对话”生成最终回答。应用层一个封装好的服务接口对接客服工作台和用户端对话框。模型选择上我们优先采用了大模型API而不是自部署开源模型。原因很现实客服并发有高峰比如活动期间咨询量翻倍自部署要处理扩容、显存、稳定性一堆问题API按量付费起步更快。效果方面当时主流的商用模型对中文理解已经非常成熟直接调用它们能把前期成本集中在数据工程上。后期如果流量稳定、成本敏感再考虑蒸馏或私有化部署。团队分工大致是数据工程师负责清洗切片算法工程师负责检索链路后端同学负责接口编排和会话管理。关键是数据和算法不能割裂知识库的质量直接决定效果上限算法只是把上限尽量兑现。2. 知识库构建数据是一切的起点2.1 数据摸底与清洗是第一道坎很多团队做RAG项目习惯先研究模型选型回头才发现数据一团糟。我们这次特意把数据工程放在最前面而且实践证明这个顺序非常正确。先摸底。我们把客服系统的历史工单导出来把产品帮助中心的文档爬下来把面向内部的知识库文章整理了一遍发现几个问题有些文档内容过期了写着旧版功能的操作路径有些FAQ答案是错的回答口径跟最新规则不一致还有些文档排版混乱大段大段的内容里面混杂着说明、示例和注意事项。清洗规则基本是这几条过期内容标记归档不进入向量库避免污染检索结果。明显错误的FAQ直接修正或删除。HTML标签、Markdown语法、多余空行统一清理保证切片输入干净。短文本补全上下文避免碎片化信息没头没尾。有一件事特别提醒千万别把Excel里的单元格直接当文档片段塞进向量库必须转成完整句子。比如某个单元格写“退款时效3个工作日”如果不加主语模型检索到之后也可能不确定这是指“审核时效”还是“到账时效”容易答偏。2.2 切片策略既能捞得着又别捞太碎RAG系统里切片Chunk大小这个参数最容易被忽略但它对回答质量的影响非常直接。片切大了检索结果里冗余信息多大模型容易被带偏片切小了上下文断裂模型找不到完整的逻辑。我们试验了几种切法固定字数切分比如512字一刀切实现简单但经常把一句话拦腰切断检索出来的片段语义不完整。按段落切分对结构良好的文档效果不错但长段落还是很长。按标题层级切分 固定窗口重叠先按文档结构切块如果某块仍然太长再按句子边界切并且每个切块保留前后一部分重叠内容。这个方案我们实测效果最好。具体实现时重叠窗口设为大约50到100字。这个重叠非常重要它能避免检索命中的内容正好落在切片边界上导致漏掉关键信息。另一个经验不同来源的文档建议分开切片配置。FAQ问题通常一句话就能答完适合小切片操作指南类文档步骤多适合按步骤块切。统一用一套参数会牺牲不少效果。2.3 向量化模型和向量库的选择向量化是把文本变成一串数字语义相近的文本在数字空间里也相近。我们对比过几款主流的Embedding模型包括当时很火的开源中文模型最后选了一个中文效果稳定、维度适中比如768维、支持私有化部署的模型。为什么强调中文效果因为客服场景大量问法口语化比如“我买完咋不能用了”和“购买后无法使用”其实是同一个意思英文语料训练出来的模型对这种口语化表达的理解明显弱一些。向量数据库方面我们从Chroma起步做原型验证后来迁移到了Milvus。如果是个人项目或者团队数据量在百万条以下Chroma、SQLite-Vec、Qdrant都能对付数据量上来了、需要高并发检索和动态过滤Milvus这类分布式向量库会省心很多。不过向量库的选择不要早期就纠结先跑通全链路再说。插入一条实战心得向量化后的数据建议把原文、来源链接、业务分类ID一起存进元数据字段。这样后续做“引用溯源”非常方便用户收到回答时能看到依据也能快速回溯是哪条知识出了问题。3. 检索与生成核心链路搭建3.1 别迷信纯向量检索混合检索更稳一开始我们天真地以为向量检索能解决所有匹配问题。测了几轮发现向量检索对“语义相似但表达完全不同”的问题确实强比如“账号被盗怎么办”和“我的号好像被登了”能匹配上但它对“精确关键词”不够敏感比如用户问“iOS 17.2 无法登录”如果知识库里只有“IOS系统登录异常”这种泛化表述向量检索的得分会被拉低而纯关键词检索却能轻松命中。所以最终用了混合检索向量检索负责语义扩展BM25关键词检索负责精确匹配两边结果做融合再一起送进重排模型。融合策略可以简单粗暴向量检索召回Top50BM25召回Top50去重后按融合分数取Top10。融合分数一般是加权相加权重根据实际效果调整我们用的比例大约向量0.6、关键词0.4。重排环节是效果提升的隐藏神器。我们先用粗排召回几十条候选再用一个重排序模型也可用大模型本身做rerank但成本高一些对这些候选做精排最后只取Top3到Top5喂给生成模型。这么做最大的收益是把真正相关的内容顶到前面把那些“似相关实无关”的片段压下去。实际体验下来重排之后回答准确率有明显提升强烈建议不要省这一步。3.2 提示词工程让模型“基于材料回答”很多人以为提示词只是写几句话其实它是整个系统里唯一能直接驾驭模型行为的地方值得反复打磨。我们的系统提示词大概压了这几个要求角色设定你是某平台的智能客服助手需要礼貌、简洁、准确地回答用户问题。知识限定只能依据“参考资料”里的内容回答参考资料不够时明确说明“未找到相关信息”绝不编造。格式要求先给出结论性回答再列出操作步骤或原因必要时用编号列表。溯源要求回答末尾附上参考文档标题方便用户和客服核对。这里给一个实际用过的Prompt结构示例你是[某内容平台]的智能客服助手。请严格依据下方给出的参考资料回答用户的问题。 要求 1. 如果参考资料包含答案请直接给出准确、完整的回答可结合多个片段综合整理。 2. 如果参考资料不包含答案请回复“抱歉这个问题我还无法准确回答可以转人工处理”不要自行推测。 3. 回答要口语化、清晰步骤可用编号列出。 4. 回答结束后换行用“参考文档”列出引用到的资料标题。 参考资料 {retrieved_chunks} 用户问题{question} 历史对话{chat_history}注意我把历史对话放在最下面而不是跟参考资料混在一起是为了让模型区分“用户说了什么”和“文档说了什么”。系统提示词每次请求都会带上检索到的片段直接填进占位符。这里有一个真实踩过的坑如果你把“如果不知道就回答不知道”送给大模型它确实会照做但有时候会过度保守——明明资料里有答案它却因为表达方式不完全匹配而选择了“不知道”。解决办法是提示词里加上一句“参考资料和问题可能并非完全字面匹配请结合语义判断是否包含答案”模型的理解力足够处理这个约束。3.3 上下文管理与流式输出客服对话不是一问一答就结束用户经常追问“那如何退款呢”“电脑端也能操作吗”所以我们必须管理多轮上下文。多轮对话的典型问题是上下文爆炸。我们早期把全部历史对话都塞进请求很快就把上下文窗口撑满了而且模型容易被早期闲聊带偏。后来改成策略性截断只保留最近三到五轮同时在每轮前判断当前用户问题是否需要历史信息。比如用户说“好的谢谢”我们就知道这是结束语不需要带入历史用户说“那怎么操作呢”代词“那”明显指向上一轮的话题必须带上历史。这里有个小技巧做一问一答时我们在检索前会把“多轮问题”改写成一个“独立问题”比如“那怎么操作”改写成“会员在另一台设备上登录怎么操作”改写后的查询再去检索命中率会提升不少。流式输出这块我建议直接把大模型API的流式返回接到前端。客服场景里如果用户要等上10秒钟才看到一整段文字体验会差很多。逐字输出能制造“正在思考”的错觉而且用户可以边看边判断要不要打断。后端用SSEServer-Sent Events把增量token推到前端代码并不复杂。4. 效果评估与持续优化4.1 怎么评价客服回答质量智能客服上线前团队内部对“什么是好的回答”争论了很久。有人说回答正确就行有人说用户满意度更重要但我们很快意识到正确率是最底层的及格线用户感知到的“服务质量”还包含响应速度、语气、是否有耐心、是否给出了后续操作路径。最后我们定了一套组合评估维度准确性回答内容是否与标准答案一致是否存在知识性错误。完整性用户问题的各个子需求是否都被覆盖。友好度语气是否自然有没有冷冰冰的机器感。可操作性操作步骤是否清晰用户看了是否知道下一步做什么。合规性是否出现不该说的敏感内容或过度承诺。线上监控主要看四个指标首次解决率用户问完一个问题后没再追问、转人工率、用户点赞点踩率、平均响应时长。我们每周拉一次数据转人工率从初期的接近五成逐步降到了两成出头这个下降趋势就是系统优化的方向标。4.2 离线评测集怎么搭才知道效果好坏优化过程中最怕的事情是“感觉变好了但说不清哪里变好”。所以在项目初期我们就从历史工单里抽了300条真实问题人工写好标准答案做成固定评测集。每次修改提示词或者换模型都用同一套评测集跑一遍对比前后效果。评测集的设计有几个细节覆盖高频问题也要包含10%左右的低频、刁钻问题防止系统只会做高频。每个问题标注难度等级和所属业务分类方便看薄弱环节。部分问题设计成开放式的没有唯一答案评测时判断“是否合理、是否提到了关键点”。评测集里的问题定期扩充尤其是把线上新增的、用户问得多但系统答不好的问题加进去。我们跑评测的方式是批量调用接口把回答保存下来然后人工逐条打分。这个过程很枯燥但非常必要。后来我们尝试过用大模型当自动裁判跟人工评分的重合度大概在80%左右只能做初筛最终仍以人工为准。为了让评测更高效我们把打分维度简化成三个等级好可以直接对外展示、中方向对但是可以更好、差错误或答非所问。这样两个人分别打分不一致的地方拿出来讨论很快就知道短板在哪里。4.3 三个有代表性的优化案例举三个我们在优化过程中遇到的真实案例可能对你有启发。第一个是关于“口语化问法”的问题。用户问“我昨天买的东西怎么还没发”知识库里只有“发货时效说明”向量检索能关联上一些但回答很生硬直接贴了规则原文。我们通过提示词加了引导“请结合用户提到的场景如已购买/未发货给出针对性回答”然后模型就会先识别“已购买未发货”的场景组织出更有人情味的回复。第二个是关于“多问题复合”的问题。用户问“我误购了年度会员能退吗退款多久到账”这是一个知识库片段无法回答的复合问题。我们的解法是在检索前做一次问题拆分先用大模型判断是否包含多个子问题如果是就把子问题拆开分别检索再合并结果一起送给生成模型。这个功能上线后复合问题的答非所问率显著下降。第三个是关于“用户情绪”的问题。用户带着情绪咨询“你们的会员也太坑了吧我要退钱”直接给标准规则回答会让用户火上浇油。我们在提示词里加了“如果用户表达不满先表达理解与安抚再给出解决方案”的规则实测转人工率下降的同时用户好评率反而提升了。这就是把“拟人化”落实到提示词层面的价值。5. 常见问题排查与避坑记录5.1 检索侧召回结果不对答案当然错如果你遇到“该答对的答不对答非所问”大概率问题在检索侧而不在生成侧。我们排查检索效果时先单独看检索链路把用户问题输入检索模块人工判断召回的Top3片段是不是真的相关。如果片段不相关大模型再聪明也没用。典型的“召回不中”原因有这几类用户问题太口语化或夹杂错别字原始查询向量化效果差。对策是做一个查询改写模块先把口语转书面语再做检索。知识库切片太小检索到的片段只包含部分信息不足以支撑完整回答。对策是适当增大切片重叠窗口。关键词检索和向量检索的结果没有很好融合导致某一路的强信号被淹没。对策是调融合权重或者用RRFReciprocal Rank Fusion这种简单有效的方式融合。排查时有一个好习惯把所有检索结果都打到日志里。用户问什么、召回了哪些片段、每个片段多少分、最终选了哪几个全都记录下来。出了问题直接翻日志五分钟定位到是检索还是生成的问题。5.2 生成侧幻觉是怎么一步步压下去的大模型幻觉是智能客服系统最头疼的问题。我们试过很多方法最有效的是下面这几条组合拳。第一知识约束。提示词里明确说“只能依据参考资料回答”并且不是简单说一句而是反复强调“如果资料没有相关内容必须说不知道”。这条最基础也最重要。第二引用溯源。要求模型在回答末尾标注引用的文档标题。这样做倒不完全是给用户看的而是给审核人员看的。一旦某一批回答被点踩我们能马上追溯到是哪份文档的问题而不是把锅都甩给模型。第三低置信度拦截。我们对生成结果做一个后置校验如果检索到的片段跟问题的相关性得分都很低宁可让系统转人工也不要硬答。这个“宁可不说”的策略对用户体验的提升非常明显。早期我们追求回答率什么都要回答结果错误答案满天飞后来改成低分拒答总体满意度反而上来了。第四定期知识库审计。业务规则更新后旧知识不撤就会出现新旧口径打架的情况。我们每个月做一次知识库清理并且把元数据里的“生效时间”字段用起来检索时过滤掉失效文档。5.3 工程侧并发、延迟与稳定性上线初期我们遇到过一次线上事故活动期间咨询量突增调用大模型API的并发飙升直接打满了后端的连接池导致大量请求超时。后来做了三件事一是异步化处理。用户请求进来先返回“正在排队”的提示后台排队调用模型完成后通过WebSocket推送结果。这个方案牺牲了一点实时性但大大缓解了压力。二是缓存复用。高频、重复的问题比如“怎么改密码”答案基本是稳定的我们在Redis里做了一层缓存命中缓存的请求根本不调用大模型既省钱又快。三是降级方案。如果大模型API连续失败或超时系统直接推荐“转人工”而不是给用户一个空白页面。流式输出也带来一个问题客户端连接中途断开后端还在生成怎么办。我们用了一个简单的信号机制前端断开时通知后端取消生成任务避免白白消耗token。稳定性的核心就一句话大模型是系统的一个组件不是上帝的化身。所有依赖大模型的环节都要有降级预案否则它一次抽搐客服系统就全瘫。5.4 上下文会话管理中的“记忆丢失”还有一个经常被忽视的细节用户在多轮对话中途去查了一下网页回来继续聊这时系统如何理解上下文我们的做法是给每个会话窗口设置一个有效期比如30分钟内有连续对话则视为同一会话超过30分钟则开启新会话。这个功能看起来简单但能避免很多会话串台导致的问题。另外一个实际场景是“打断式追问”——用户先问会员价格又追加“那学生有没有优惠”。我们的上下文改写模块会把“学生有没有优惠”补全为“学生购买会员有没有优惠”然后单独检索再结合上一轮的会员价格信息一起回答。这里的经验是改写后的独立问题不仅用于检索最好也展示给用户看比如“为您查询学生购买会员优惠问题”让用户知道系统理解对了有助于建立信任感。6. 写在最后的体会做完这个“AI大模型之旅——智能客服实战”我最深的体会是大模型项目真正的技术壁垒不在于模型本身而在于你如何把业务知识喂给模型如何约束模型不说错话如何评估效果并持续改进。我们踩过不少坑最核心的几个建议浓缩如下先做好数据清洗和切片再谈模型选型知识库的底子决定效果上限。检索链路不要省混合检索加精排比单纯换更大的模型效果提升更明显。提示词要像产品需求文档一样迭代每次只改一个变量用评测集验证效果。对不确定的问题让系统学会“认怂”转人工比硬答更被用户认可。上线前一定要做好降级方案大模型接口的抖动你是控制不了的但你的系统可以兜底。如果你也要做类似的项目不用追求一开始就搞一个多庞大的系统。先把一条最小链路跑通取50条真实问题、搭一个简单的向量索引、调用模型接口、自己手动测二十个问题感受一下哪里别扭再逐步添砖加瓦。这条路我们已经替你走通了你按着这个节奏来大概率能做得比我们更快。
阅读完成 · 觉得有帮助？
