基于 RAG 的客服机器人
使用场景: 在帮助中心文档之上构建聊天机器人的团队
渠道：网站组件 + 应用内聊天
对话管理把每条消息路由给 LLM
RAG 在生成前检索相关帮助文章
护栏：输入端 PII 脱敏，输出端引用校验
会话存储保持对话线程
这样组织的原因: RAG 客服机器人是最常见的生产模式——把每个答案建立在检索到的文档之上，是防止机器人自信地编造政策的关键，图表应展示检索发生在生成之前。
AI 聊天机器人架构图示例
以下聊天机器人示例展示了同样的「渠道—对话—LLM」骨架如何适配不同产品——基于 RAG 的客服机器人、经典意图机器人、多渠道助手和语音前端。
真实案例
基于意图的聊天机器人（经典 NLU）
使用场景: 有明确定义流程（预订、FAQ、状态查询）的团队
NLU 把消息分类到固定的意图集合
对话管理为每个意图运行脚本化流程
在执行操作前通过追问填充槽位
LLM 仅用于兜底 / 自由文本理解
调用后端 API 执行事务性操作
这样组织的原因: 基于意图的设计适合需要确定性流程的有界任务——图表以 NLU 分类器和脚本化对话为中心，LLM 作为兜底而非核心，用灵活性换取可控性。
多渠道助手
使用场景: 用一个机器人服务 Web、移动端和 Slack 的团队
一个对话管理位于多个渠道适配器之后
每个适配器规范化渠道特定的格式
跨渠道按用户键控的共享会话存储
无论哪个渠道都用同一个 LLM + RAG 核心
对最终回复做渠道感知的渲染
这样组织的原因: 多渠道助手把渠道适配器与核心分离——图表展示多个前端收拢进一个对话管理，业务逻辑只存在一次，每个渠道只处理自己的格式。
语音聊天机器人
使用场景: 添加语音交互界面的团队
语音转文字把音频转成消息
与文本一致的对话管理 + LLM + RAG 核心
文字转语音把回复转回音频
延迟预算更低——流式响应很重要
会话存储与文本机器人一致
这样组织的原因: 语音机器人在文本架构外面包一层 STT 和 TTS——图表清楚表明对话核心完全相同，变化的只是输入 / 输出的转换和延迟预算。
使用技巧
- 把请求路径自上而下绘制——用户 → 渠道 → 对话管理 → LLM/RAG → 回复——让流程朝一个方向读。
- 把护栏画成回复前的独立关卡，而非 LLM 框的一个属性。
- 把会话存储作为对话管理读写的独立节点；对话记忆不是模型的一部分。
- 如果使用 RAG，把它放在 LLM 旁边，让答案在生成完成前就有依据这点清晰可见。
在线开始编辑
回到模板页，直接替换成你的课程主题、章节和复习重点，就可以继续使用这套结构。
使用这个模板： /editor/new?template=ai-chatbot-architecture
编辑此 AI 聊天机器人模板