从零开始搭建RAG智能客服系统的实战指南，深度解析技术选型与落地避坑经验。核心内容：1. 主流RAG方案全面对比：LangChain、Dify等工具优劣势剖析2. 数据预处理关键技巧：结构化说明书与百万级聊天记录处理方法3. 多智能体协作架构设计：基于阿里云百炼的实战解决方案
目录
- 项目背景
- 技术选型对比：LangChain、Dify、Coze、百炼全测评
- 数据预处理：说明书与聊天记录处理方法
- Prompt设计要点：像编程一样重要
- Agent流程设计：多机器人协作才算靠谱
- 测试与评估：效果如何？问题在哪？
- 遇到的坑与后续改进方向
1️⃣ 项目背景：我们为什么要做这个？
春节前后DeepSeek爆火，年后老板果断拍板启动智能客服项目。说白了，大模型API价格持续下降，中小企业也能入场尝试，这波机会不容错过。
2️⃣ 技术选型与工具链
项目启动初期，我们调研了几种主流方案，各有各的特点：
- LangChain：这个框架专为复杂AI应用设计，提供开箱即用的RAG全链路支持——从知识库构建、向量检索优化到多智能体编排，都能通过模块化组件快速实现。听起来很诱人，但实际调试成本较高。
- Dify：支持API/代码调用和可视化拖拽两种方式编排智能体。可视化workflow操作直观，但一旦涉及多智能体协作，拖拽式操作变得笨重，调试和异常处理都比较棘手。
- 模型微调：公司新品迭代速度快，知识库和客服数据频繁更新。频繁微调成本太高，或者微调后再加上RAG增强，部署和API费用叠加，训练数据标注的时间成本更是难以承受。
- Coze：主打低门槛、强对话体验，适合C端用户，但复杂任务扩展性较弱，与项目需求不太匹配。
- 阿里云百炼：提供Agent SaaS服务，数据库集成能力强，支持API调用方式组织智能体。这一点让人眼前一亮。
最终我们选择了阿里云百炼的Assistant API + 自主代码调度方案，理由很实在：
- 团队已在用阿里云数据库，数据同步更加顺畅；
- 百炼支持灵活控制智能体编排，适合复杂逻辑场景；
- 默认接入通义千问模型，中文理解、知识检索效果和费用控制都表现不错（知识库和检索免费，仅收模型token费用）；
- 试用可视化工作流后发现，多智能体协作这种逻辑复杂的场景，直接写代码比拖拽更高效可控，调试和异常处理也更灵活。
3️⃣ 数据预处理：说明书与聊天记录如何处理？
说明书数据预处理
首先将说明书整理为结构化数据，大致格式如下：
| 设备型号 | 功能标题 | 内容详情 |
|---|---|---|
| AT01 / BT02 | 2.4G 模式连接 | 将设备底部开关拨至 2.4G 模式后长按连接键3秒… |
| M001 | 灯不亮了 | 操作步骤扩展说明。。。 |
| M002 | 无法连接 | 操作步骤扩展说明 |
这种结构化方式便于后续切片，也能实现关键词 + 向量双重匹配，检索效率明显提升。
客服聊天记录的挑战与策略
聊天记录处理比说明书复杂得多，几个难点摆在面前：
- 超过百万条记录，人工标注不现实；
- 问题重复度高，用户表达五花八门；
- 部分对话中断、答非所问、语义不清；
- 夹杂用户隐私信息（手机号、订单号等）；
- 部分客服回答本身不准确。
针对这种情况，我们采用了“弱监督 + 大模型协助”的方案：
- 清洗数据：剔除异常对话、乱码、特殊字符和低质量样本。
- 隐私脱敏：正则规则配合模型辅助识别敏感字段。
- 编写 Prompt，批量传入大模型，提取成结构化问答数据：
| 问题描述 | 解决方案 | 相关设备型号 | 问题分类 | 用户满意度 |
|---|---|---|---|---|
| 设备无法通过2.4G模式连接 | 将开关拨至2.4G模式后长按连接键5秒，重启路由器 | AT01、BT02、CT03 | 网络连接类 | 满意 |
| 2.4G模式连接后频繁断连 | 检查设备与路由器距离是否超过10米，更换信道 | BT02、DT04 | 信号稳定性 | 适中 |
| 连接键长按无反应 | 检查电池电量是否低于20%，清洁按键触点 | AT01、ET05 | 硬件故障类 | 不满意 |
大模型批量数据处理方面，推荐使用阿里云百炼的批处理接口，在非高峰时段提交任务，成本低廉，特别适合对时效性要求不高但成本敏感的场景。
4️⃣ Prompt设计：像编程一样，但更靠猜！
Prompt 设计这件事，跟写代码有些相似，但更依赖“猜测”和反复尝试。踩过的坑不少，总结出一些实用技巧：
- 让模型输出思考过程，观察它是否在编造。
- 提供高质量示例，尽量在短小的示例中覆盖全部需求。
- 模型适配 Prompt：比如GPT-4擅长英文结构化提示，通义千问处理中文口语类表达更有优势。
- 用伪代码表示复杂逻辑，清晰明确。
- Prompt要版本管理，方便对比优化效果。
- 分工协作：复杂任务拆分成多个机器人串联处理。
- 指令不生效时，多换几种表述方式，越简单越好。
- 复杂句换成直白口语，命中率更高。
- 指定风格和语气：通过token联想来控制语调（比如“俏皮”风格）。
- 任务说明必须明确，让模型知道你要“提取”、“摘要”还是“判断”。
- 角色设定要清晰，角色决定语言风格和知识背景。
- 格式控制要写死，不然模型输出容易走偏。
- 添加反向约束，比如“不要解释，不要重复问题”，防止模型加戏。
实际体会是，即便最优设计的Prompt，在实际调用中也不一定稳定——同样的输入，有时生效有时不生效。这跟大模型服务商的底层实现有关，推测部分平台在负载均衡时会调用不同版本或权重参数的模型实例，导致表现不一致。
5️⃣ Agent流程设计：多个机器人一起干活才靠谱！
我们采用多智能体分工协作的设计，结合阿里云百炼提供的API服务，构建了一套可控、可维护的智能体系统。
智能体划分如下：
- 型号与问题收集智能体：提取用户输入中的设备型号；若未明确给出型号，引导用户描述型号和遇到的问题。
- 指定型号问题解答智能体：每个型号绑定独立知识库，避免多型号混用（比如ML和ML Pro的蓝牙问题混淆）。
- 意图识别智能体：判断用户意图（闲聊/追问/投诉/质疑/发图/情绪波动等），指派对应子智能体处理或触发人工客服。
- 状态控制器/状态机：控制上下文状态、Agent调用顺序，决定是否开启新线程、是否重复回答、是否触发人工。
这种架构既保证了知识隔离，又能应对复杂的对话逻辑，是一种比较可靠的组合方案。
6️⃣ 测试流程 & 效果评估：模拟测试中
系统尚未对外正式上线，目前通过人工测试模拟用户行为：
测试方法：
- 回放历史对话，模拟用户提问
- 设计边界场景（乱码、模糊表达、恶意发言）
- 验证模型调用、Agent分工、状态维护是否正常
评估维度：
| 维度 | 说明 |
|---|---|
| 回答准确性 | 是否命中正确知识片段 |
| 语气自然性 | 回复是否像“人说的” |
| 意图识别率 | 模糊输入能否正确分类 |
| 上下文连贯性 | 多轮问答是否通顺 |
| 异常应对能力 | 是否及时切换到人工 |
| 用户误识别率 | 用户是否察觉是机器人 |
当前问题：
- 回复不够稳定，同一句问法表现不同
- 转人工率高，尤其是图片、链接、情绪波动场景
- 上下文衔接欠佳，追问处理不连贯
下一步，计划开放一个“智能客服入口”，在用户界面中与人工客服区分，逐步引导用户试用，降低用户预期，积累真实反馈。
7. 项目中遇到的问题与改进方向
以下是项目推进中暴露的一些待解决问题：
- 问题同义表述处理：比如“失灵”“没反应”“按了没反应”等是否统一为一条？计划采用关键词聚类方式归并。
- 型号识别准确性：用户可能拼错型号名、一次提多个型号，需要合理的兜底与策略分发。
- 模糊问题处理策略：比如“设备灯不亮了”是否需要反复追问？是个别灯不亮还是所有灯不亮，什么情况下不亮？
- 非文本交互问题：发图片、截图、链接等场景，目前只能转人工，限制了自动化水平。
- 大模型响应不稳定：可能与底层服务商模型负载调度有关，影响线上表现的一致性。
这些坑踩过之后，后续的改进方向也渐渐清晰了。一步一步来，问题总能解决的。