最近在做一个智能客服系统的升级项目之前用规则引擎和简单匹配问题太多了。用户问个稍微复杂点的问题或者知识库一更新就得手动调整规则响应也慢。后来研究了一下发现用 Dify 这个低代码平台结合 RAG检索增强生成技术来搞效率提升不是一点半点。今天就把从架构设计到实际上线踩过的一些坑整理成笔记分享给大家。1. 为什么传统客服系统不够用了最开始我们用的就是那种很常见的客服系统用户提问系统去知识库里做关键词匹配匹配上了就返回预设好的答案。这套东西在初期问题简单的时候还行但业务一复杂短板就全暴露出来了。响应慢且不智能关键词匹配太死板了。比如用户问“怎么重置密码”知识库里只有“密码找回步骤”这就匹配不上了只能转人工。而且对于“这个服务怎么收费”和“你们的收费标准是什么”这种同义问题得预设好几套规则维护起来头大。知识更新严重滞后产品功能、政策一变运营同学就得去后台一条条改问答对或者加新规则。经常出现新功能上线一周了客服机器人还回答不上来的尴尬情况。多轮对话是噩梦几乎无法实现上下文关联。用户先问“订单A的物流”再问“那能改地址吗”系统根本不知道“那”指的是订单A对话体验支离破碎。冷启动和扩展成本高每接入一个新的业务领域比如从电商客服扩展到技术支持几乎要从头构建一套规则开发周期长效果还不好评估。所以我们的核心诉求变成了能不能有一个系统能理解自然语言能利用最新的知识库能进行连贯的对话并且开发和维护还不能太复杂这时候RAG 技术进入了视野。2. 技术选型为什么是 Dify RAG解决“利用最新知识”和“理解自然语言”这两个问题主要有几种思路规则引擎、微调Fine-Tuning大模型和RAG。规则引擎上面说了维护成本高不智能最先被排除。微调大模型把我们的客服问答数据拿去训练一个专属模型。效果可能会很好但问题也不少1) 成本极高训练一次贵且耗时2) 知识更新困难每次更新都得重新训练或增量训练3) 容易产生“幻觉”模型可能会编造一些不在我们知识范围内的答案。RAG检索增强生成这个方案巧妙地拆解了问题。它让大语言模型LLM专注于自己最擅长的“理解与生成”而把“事实依据”交给检索系统。具体流程是用户提问 - 从向量知识库中检索相关文档片段 - 将片段和问题一起交给 LLM 生成答案。这样答案既有 LLM 的流畅性和逻辑性又牢牢锚定在我们提供的知识上知识更新也只需要更新向量数据库即可。那么为什么选择 Dify 呢因为 Dify 是一个开源的 LLM 应用开发平台它把 RAG 的整个流程知识库管理、工作流编排、模型集成、对话界面等都可视化、模块化了。我们不需要从零开始搭建检索、构建 API 服务可以更专注于业务逻辑和优化。它相当于为我们提供了 RAG 应用的“基础设施”和“装配线”。3. 系统架构设计这是我们的智能客服系统核心架构图基于 Dify 的能力进行了扩展[用户] - [前端应用/API网关] - [Dify 核心引擎] | [对话管理 工作流] | ------------------------------- | | [向量检索模块] [大语言模型(LLM)] | | [向量数据库] [模型API (如 OpenAI, 文心一言)] | [知识文档存储]各组件交互流程用户通过 Web、App 或 API 发起查询。前端/API网关接收请求进行初步的鉴权、限流和日志记录然后将请求转发给 Dify 引擎。Dify 工作流被触发。这是核心控制逻辑它首先调用向量检索模块。向量检索模块将用户问题转换为向量Embedding然后在向量数据库我们选用 Milvus中进行相似度搜索返回最相关的几个知识片段Context。工作流将检索到的知识片段和原始用户问题组合成一个精心设计的提示词Prompt发送给LLM例如 GPT-4 或国内合规的模型。LLM基于提示词生成最终的回答返回给工作流。工作流将回答返回给 API 网关最终呈现给用户。同时对话管理模块会维护本次会话的上下文用于后续的多轮对话。4. 核心实现步骤4.1 知识库构建与向量化处理知识库的质量直接决定检索效果。我们的文档包括产品手册、FAQ、历史工单、政策文件等。首先我们需要一个预处理和向量化的脚本import os from typing import List from langchain.text_splitter import RecursiveCharacterTextSplitter from langchain_community.document_loaders import DirectoryLoader, TextLoader from langchain_community.embeddings import OpenAIEmbeddings from pymilvus import connections, Collection, FieldSchema, CollectionSchema, DataType # 1. 加载文档 def load_documents(data_dir: str) - List: 加载指定目录下的所有文本文档 loader DirectoryLoader(data_dir, glob**/*.txt, loader_clsTextLoader) documents loader.load() print(f已加载 {len(documents)} 个文档) return documents # 2. 分割文本 def split_documents(documents: List, chunk_size500, chunk_overlap50) - List: 将长文档分割成适合检索的小片段 text_splitter RecursiveCharacterTextSplitter( chunk_sizechunk_size, chunk_overlapchunk_overlap, length_functionlen, separators[\n\n, \n, 。, , , , , , ] ) splits text_splitter.split_documents(documents) print(f文档被分割成 {len(splits)} 个片段) return splits # 3. 生成向量并存入 Milvus def create_and_insert_vector_db(document_splits: List, embedding_model): 连接 Milvus创建集合并插入向量数据 # 连接 Milvus connections.connect(aliasdefault, hostlocalhost, port19530) # 定义集合字段id, 向量 文本内容 元数据来源 fields [ FieldSchema(nameid, dtypeDataType.INT64, is_primaryTrue, auto_idTrue), FieldSchema(nameembedding, dtypeDataType.FLOAT_VECTOR, dim1536), # OpenAI embedding 维度 FieldSchema(namecontent, dtypeDataType.VARCHAR, max_length65535), FieldSchema(namesource, dtypeDataType.VARCHAR, max_length255), ] schema CollectionSchema(fields, description客服知识库) collection_name customer_service_kb if collection_name in utility.list_collections(): utility.drop_collection(collection_name) # 生产环境慎用这里演示用 collection Collection(namecollection_name, schemaschema) # 创建索引 index_params { metric_type: IP, # 内积相似度也可以用 L2 index_type: IVF_FLAT, params: {nlist: 128} } collection.create_index(field_nameembedding, index_paramsindex_params) # 准备批量插入的数据 contents [split.page_content for split in document_splits] sources [split.metadata.get(source, unknown) for split in document_splits] # 批量生成向量 (注意OpenAI API 调用有频率限制生产环境需要做批处理和错误重试) print(正在生成文本向量...) embeddings embedding_model.embed_documents(contents) # 插入数据 entities [ embeddings, # 向量列表 contents, # 文本内容列表 sources # 来源列表 ] insert_result collection.insert(entities) print(f已插入 {insert_result.insert_count} 条向量数据) # 将集合加载到内存 collection.load() return collection # 主流程 if __name__ __main__: data_path ./knowledge_base embedding_func OpenAIEmbeddings(modeltext-embedding-3-small, openai_api_keyyour-key) docs load_documents(data_path) splits split_documents(docs) kb_collection create_and_insert_vector_db(splits, embedding_func)这个脚本完成了知识库的自动化处理。关键点在于文本分割的粒度要合适太短失去上下文太长则检索不精准。4.2 Dify 工作流配置示例在 Dify 的图形化界面中我们可以这样搭建工作流开始节点接收用户输入的问题。知识库检索节点配置连接我们上面建好的 Milvus 向量库。将用户问题作为查询输入输出 Top-K例如3个最相关的知识片段。提示词编排节点这是核心。我们在这里构造给 LLM 的指令。例如你是一个专业的客服助手。请严格根据以下提供的已知信息来回答问题。如果已知信息不足以回答问题请明确告知用户“根据现有资料我无法回答该问题”不要编造信息。 已知信息 {context} 用户问题{question} 请用友好、专业、简洁的语气回答Dify 会自动将{context}和{question}替换成实际内容。大语言模型节点选择并配置 LLM如 GPT-4将上一步的提示词发送给它。结束节点输出 LLM 生成的答案。整个过程无需编写后端代码通过拖拽和配置即可完成。对于高级需求Dify 也支持通过“代码节点”插入自定义 Python 逻辑。4.3 对话状态管理实现Dify 内置了基础的会话记忆功能。但对于复杂的多轮对话比如需要澄清订单号、记录用户偏好我们需要在外部维护一个对话状态机。这里给出一个简单的内存型实现思路from typing import Dict, Any, Optional import uuid import time class ConversationStateManager: def __init__(self): self.sessions: Dict[str, Dict[str, Any]] {} # session_id - state def create_or_get_session(self, session_id: Optional[str] None) - tuple[str, Dict]: 创建或获取一个会话状态 if not session_id or session_id not in self.sessions: new_id session_id or str(uuid.uuid4()) self.sessions[new_id] { created_at: time.time(), history: [], # 存放历史对话记录 [{role:user,content:...}, {role:assistant,content:...}] slots: {} # 存放需要收集的信息如 {‘order_id’: ‘12345’ ‘issue_type’: ‘billing’} } return new_id, self.sessions[new_id] return session_id, self.sessions[session_id] def update_history(self, session_id: str, role: str, content: str): 更新对话历史 if session_id in self.sessions: self.sessions[session_id][history].append({role: role, content: content}) # 可选限制历史记录长度防止上下文过长 if len(self.sessions[session_id][history]) 20: self.sessions[session_id][history] self.sessions[session_id][history][-10:] def get_context_for_llm(self, session_id: str, current_question: str) - str: 构建包含历史上下文的提示词片段 if session_id not in self.sessions: return current_question history self.sessions[session_id][history][-5:] # 取最近5轮历史 context_lines [] for msg in history: prefix 用户 if msg[role] user else 助手 context_lines.append(f{prefix}: {msg[content]}) context_lines.append(f用户: {current_question}) return \n.join(context_lines) # 在 Dify 的“代码节点”或你的后端服务中使用 state_manager ConversationStateManager() session_id request.cookies.get(session_id) sid, session_state state_manager.create_or_get_session(session_id) # 将带有历史的上下文传入 Dify 工作流 llm_context state_manager.get_context_for_llm(sid, user_question) # ... 调用 Dify API传入 llm_context ... # 得到回答后 state_manager.update_history(sid, user, user_question) state_manager.update_history(sid, assistant, ai_response)5. 性能优化实战系统上线后随着流量增长我们做了以下几方面优化向量检索缓存对于高频、通用问题如“营业时间”、“客服电话”其检索结果在短时间内是稳定的。我们在检索模块前加了一层 Redis 缓存键为问题的 Embedding 向量哈希值值为检索到的知识片段 ID 列表。缓存时间设为 5-10 分钟大幅降低了向量数据库的查询压力。Embedding 模型优化初期使用 OpenAI 的text-embedding-ada-002虽然效果好但延迟和成本是问题。我们测试了开源的BGE-M3模型在本地部署针对中文场景进行微调后精度接近但延迟从几百毫秒降到几十毫秒且没有外部 API 成本。异步与批处理在用户提问的预处理如纠错、敏感词过滤和后续的日志记录等非关键路径上全部改为异步操作。同时对于知识库的定期更新和向量化任务采用批处理模式避免频繁的小数据操作。LLM 调用优化设置超时与重试配置合理的请求超时时间如 10s并实现指数退避的重试机制应对 LLM API 的不稳定。流式输出对于长回答启用 Dify 和 LLM 的流式响应Server-Sent Events让用户能尽快看到第一个字提升体验感。备用模型降级当主模型如 GPT-4响应慢或不可用时自动降级到更快、更便宜的模型如 GPT-3.5-Turbo保障服务可用性。6. 生产环境避坑指南冷启动延迟问题首次提问时加载向量索引、初始化模型等会导致响应很慢。解决方案采用“预热”机制。在服务启动后主动用几个标准问题如“你好”、“有什么功能”触发一次完整的流程让相关组件完成初始化。对于容器化部署可以在健康检查通过后执行预热脚本。向量检索准确率波动有时检索到的文档片段不相关。解决方案a) 优化文本分割策略尝试按语义句子、段落而非单纯按字符数分割。b) 采用“混合检索”结合基于关键词的 BM25 检索和向量检索综合排序Dify 企业版支持。c) 在检索后加入一个“重排序Re-ranking”模型对 Top-N 的结果进行精排提升最相关片段的位置。LLM 的“幻觉”与胡言乱语即使提供了上下文LLM 有时也会忽略或编造。解决方案强化提示词工程。在提示词中明确指令“严格根据已知信息回答”并采用“引用”格式要求 LLM 在答案中指明依据来源的哪部分例如“根据《用户协议》第3.2条...”。也可以在输出层加入一个后处理校验检查答案中的关键事实是否能在提供的上下文中找到。知识更新不及时业务部门上传了新文档但客服机器人还是用旧知识回答。解决方案建立自动化流水线。知识文档一旦在协同办公平台如 Confluence或指定目录更新通过 Webhook 触发一个流水线任务自动完成文本处理、向量化、更新 Milvus 集合索引的全过程并通知相关方。高并发下的稳定性大量用户同时提问可能导致 LLM API 限流、数据库连接耗尽。解决方案a) 在 API 网关层实施严格的速率限制Rate Limiting。b) 对 LLM 的请求进行队列管理控制并发数。c) 数据库连接使用连接池并监控其使用情况。d) 做好服务的熔断和降级当某个组件如向量数据库故障时能暂时切换到基于 ES 的关键词检索模式。7. 必须考虑的安全与隐私数据隐私保护这是重中之重。我们选择私有化部署的 Milvus 和本地化微调的开源 Embedding 模型确保用户问题和公司知识库数据不出内网。如果必须使用云端 LLM如 OpenAI则通过代理网关并在发送前对敏感信息如手机号、订单号进行脱敏处理。输入过滤与审核在请求进入 Dify 工作流之前部署一个过滤层。使用正则表达式和关键词库过滤明显的恶意攻击、辱骂、政治敏感等内容。对于生成的内容也可以接入内容安全审核 API 进行二次校验。权限控制Dify 本身有用户和权限管理。我们根据角色客服、管理员、运营严格控制其对知识库、对话记录、系统配置的访问和操作权限。API 访问安全为 Dify 的 API 配置强认证如 JWT Token并记录所有 API 调用的详细日志便于审计和溯源。写在最后通过 Dify 和 RAG 来构建智能客服确实是一条快速验证和落地的路径。它把复杂的 AI 工程问题模块化、可视化让我们团队甚至非算法同学都能参与到智能客服的优化迭代中。目前这个系统已经稳定运行了几个月客服团队的平均问题解决率提升了约40%人工转接率大幅下降。当然这套系统还有很大的优化空间。最后留三个问题也是我们团队正在思考的供大家探讨在多轮复杂对话中如何更智能地管理对话状态和进行主动提问比如反问以澄清用户意图而不仅仅是依赖历史消息当知识库非常庞大时百万级文档片段如何进一步优化检索速度和精度近似最近邻搜索ANN算法的参数调优有哪些实践经验如何建立一个有效的闭环学习系统即如何利用被人工客服接管的对话、用户的“不满意”反馈自动定位是检索问题、提示词问题还是知识缺失问题并驱动系统自我优化希望这篇笔记对正在考虑或正在实施类似项目的朋友有所帮助。这条路虽然还有不少挑战但看到机器能真正帮上忙节省人力感觉折腾的这些都值了。