从0到1落地一个RAG智能客服系统

目录

1. 项目背景
2. 技术怎么选？LangChain、dify、Coze、百炼都试了
3. 数据预处理：说明书+聊天记录怎么搞
4. Prompt设计那些事：写得好像编程一样重要
5. Agent流程设计：多机器人协作才靠谱
6. 测试与评估：效果咋样？问题在哪？
7. 遇到的坑 & 接下来要干啥？

1️⃣ 项目背景：我们为啥要做这个？

过年的时候DeepSeek火了，年后老板提出要做智能客服的项目。（主要是大模型api价格降下来了，我们中小厂也能入场了）

2️⃣  技术选型与工具链

项目初期我调研了几种主流方案：

• LangChain：LangChain 是专为复杂AI应用设计的开发框架，提供开箱即用的RAG全链路支持——从知识库构建、向量检索优化到多智能体编排，均可通过模块化组件快速实现，也是个不错的选择。
• Dify：同时支持 API/代码调用和可视化拖拽的方式来实现智能体（Agent）编排，也是不错的选择。可视化的workflow不适合我们的多智能体编排场景，拖拽式在复杂逻辑下不好维护，也不好调试，异常处理也不友好。
• 模型微调：我们公司出新品频率高，知识库和客服数据需要经常更新，频繁微调成本太高不合适，或者微调之后再用RAG增强，但是那样成本也还是高，模型部署和api调用都有成本，训练数据标注的时间成本太高了。
• Coze：Coze主打低门槛、强对话体验，适合C端用户，但是复杂任务扩展性较弱，不适合我们的项目。
• 阿里云百炼：提供 Agent SaaS 服务、数据库集成能力强，支持以 API 调用的方式组织智能体。

最终我选择了 阿里云百炼的 Assistant API + 自主代码调度 方案，主要基于以下几点考虑：

• 我们已经在用阿里云数据库，同步数据方便；
• 百炼支持灵活控制智能体编排，适合我们这种复杂逻辑；
• 百炼默认接入通义千问（Qwen）模型，在中文理解、知识检索效果和费用控制方面都表现出色（知识库和检索免费，仅收模型 token 费用）。
• 试用了其可视化工作流后发现，对于我们这种多智能体协作、逻辑复杂的场景，可视化界面不如直接写代码更高效可控，调试与异常处理也更加灵活。

3️⃣ 数据预处理：说明书+聊天记录怎么处理？

📘 说明书数据结构化处理

我把说明书整理成结构化数据，结构大概是这样：

这种结构化方式便于后续切片，同时也能做关键词 + 向量双重匹配。

💬 客服聊天记录的挑战与策略

聊天记录处理远比说明书复杂，挑战包括：

• 超过百万条记录，无法人工标注；
• 问题重复度高，用户表达五花八门；
• 部分对话中断、答非所问、语义不清；
• 存在用户隐私（手机号、订单号等）；
• 部分客服回答本身不准确。

所以我用了“弱监督 + 大模型协助”的方式来处理：

1. 清洗数据：去除异常对话、乱码、特殊字符、低质量样本。
2. 隐私脱敏：正则规则 + 模型辅助识别敏感字段。
3. 编写 Prompt，批量传入大模型，提取成结构化问答数据：

在大模型批量数据处理方面，推荐使用阿里云百炼的批处理接口，在非高峰时段提交任务，降低成本，非常适合我们这种对时效性要求不高但成本敏感的业务场景。

4️⃣ Prompt设计：像编程一样，但更靠猜！

Prompt 设计就像写代码，但还得多试多改，以下是我踩过的坑总结👇

💡 小技巧合集：

1. 让模型输出思考过程，看看它是不是在瞎编。
2. 提供高质量示例，尽可能在短小的示例中命中你全部的需求。
3. 模型适配 Prompt：比如 GPT-4 更擅长理解英文结构化提示，通义千问在处理中文口语类表达上有优势。
4. 用伪代码表示复杂逻辑，清晰明确。
5. Prompt 要版本管理，以便对比优化效果。
6. 分工协作：复杂任务可拆分给多个机器人串联处理。
7. 指令不生效时，多换几种表述方式，越简单越好。
8. 复杂句换成直白口语，命中率更高。
9. 指定风格和语气：通过 token 联想来控制语调（如“俏皮”风格）。
10. 任务说明必须明确，让模型知道你要“提取”、“摘要”还是“判断”。
11. 角色设定要清晰，角色决定语言风格和知识背景。
12. 格式控制要写死，不然模型输出容易走偏。
13. 添加反向约束，如“不要解释，不要重复问题”等防止模型加戏。

此外，我的实际体会是，即便是最优设计的 Prompt，也可能在实际调用中不稳定——同样的输入，有时生效有时不生效。这跟大模型服务商的底层实现有关，我怀疑部分平台在负载均衡时会调用不同版本或权重参数的模型实例。

5️⃣ Agent流程设计：多个机器人一起干活才靠谱！

我采用了多智能体分工协作的设计，结合阿里云百炼提供的 API 服务，构建了一套可控、可维护的智能体系统。

智能体划分如下：

1. 型号与问题收集智能体：

• 提取用户输入中的设备型号
• 若未明确给出型号，引导用户描述型号和遇到的问题

• 指定型号问题解答智能体：

• 每个型号绑定独立知识库
• 避免多型号混用（如 ML 与 ML Pro 蓝牙问题混淆）

• 意图识别智能体：

• 判断用户意图（闲聊/追问/投诉/质疑/发图/情绪波动等）
• 指派对应子智能体处理或触发人工客服

• 状态控制器 / 状态机：

• 控制上下文状态、Agent调用顺序
• 是否开启新线程、是否重复回答、是否触发人工

这种架构既保证了知识隔离，又能应对复杂的对话逻辑。

---

6️⃣ 测试流程 & 效果评估：模拟测试中

系统尚未对外正式上线，当前主要通过人工测试模拟用户行为：

🧪 测试方法：

• 回放历史对话，模拟用户提问
• 设计边界场景（乱码、模糊表达、恶意发言）
• 验证模型调用、Agent 分工、状态维护是否正常

📊 评估维度：

维度	说明
回答准确性	是否命中正确知识片段
语气自然性	回复是否像“人说的”
意图识别率	模糊输入能否正确分类
上下文连贯性	多轮问答是否通顺
异常应对能力	是否及时切换到人工
用户误识别率	用户是否察觉是机器人

🚧 当前问题：

• 回复不够稳定，同一句问法表现不同
• 转人工率高，尤其是图片、链接、情绪波动场景
• 上下文衔接欠佳，追问处理不连贯

下一步，我们将开放一个**“智能客服入口”**，在用户界面中与人工客服区分，逐步引导用户试用，降低用户期望，积累真实反馈。

---

7. 项目中遇到的问题与改进方向

以下是项目推进中暴露的一些待解决问题：

• 问题同义表述处理：如“失灵”、“没反应”、“按了没反应”等是否统一为一条？计划采用关键词聚类方式归并。
• 型号识别准确性：用户可能拼错型号名、一次提多个型号，需要合理兜底与策略分发。
• 模糊问题处理策略：如“设备灯不亮了”是否需要反复追问？是个别灯不亮还是所有灯不亮，什么时候不亮？。
• 非文本交互问题：如发图片、截图、链接，目前仍然只能转人工，限制了自动化水平。
• 大模型响应不稳定：可能与底层服务商模型负载调度有关，影响线上表现一致性。