✅派聪明 RAG 系统的聊天助手模块设计方案

请围绕下面这段划线内容回复："系统的第一步是由客户端主动发起一个 WebSocket 连接请求" 为什么要使用websocket连接，sse接口明明更加简单通用 当前模型还在开发当中，请右上角下拉框切换到其他模型

这是我从文章中选择的一段文本："系统的第一步是由客户端主动发起一个 WebSocket 连接请求" 为什么要使用websocket连接，sse接口明明更加简单通用 当前模型还在开发当中，请右上角下拉框切换到其他模型

这是我从文章中选择的一段文本："服务端收到请求后，会先验证用户的身份和权限，确认无误后，就会和客户端建立一个稳定的 WebSocket 长连接，用于后续的实时对话。" 为什么要使用websocket连接，sse接口明明更加简单通用 当前模型还在开发当中，请右上角下拉框切换到其他模型

根据参考资料中的 **Redis 结构设计** 部分，派聪明系统确实对对话历史记录进行了长度限制——**最多保存 20 条消息**，超出部分会被自动截断，只保留最近的 20 条。 具体说明如下： 1. **限制机制**：对话历史 Key 为 `conversation:{conversationId}`，存储的 JSON 数组中的 `messages` 字段限制最多保存 20 条消息（包含用户提问和系统回答），超出时旧消息会被移除。 2. **实现示意**：从参考资料中的 `getConversationHistory` 方法可以看出，系统从 Redis 中读取整个历史记录数组，然后交由后续的 Prompt 构建流程处理，而 Redis 存储时就已经做了条数限制。 3. **目的**：这种设计主要是为了**控制 Prompt 的输入长度**，避免因多轮对话积累过多上下文导致超出大语言模型（如 DeepSeek）的 Token 限制，同时也能保证对话的连贯性和响应速度。 因此，你的理解基本正确——系统会限制最多保留最近 20 条消息（约 10 轮完整对话），超出部分自动丢弃，确保每次请求的上下文长度在可控范围内。

根据参考资料中的设计，目前派聪明的**聊天助手模块确实只在 Redis 中保存会话和对话历史，没有往数据库（如 MySQL）中进行持久化**。 从 Redis 结构设计可以看出： | Redis Key | 用途 | TTL | |-----------|------|-----| | `user:{userId}:current_conversation` | 用户当前会话 ID 映射 | 7 天 | | `conversation:{conversationId}` | 对话历史记录（最多 20 条消息） | 7 天 | | `user:{userId}:conversations` | 用户的历史会话 ID 列表 | 7 天 | | `prompt_templates:{templateName}` | Prompt 模板缓存 | 无/较长时间 | 所有的历史记录查询接口（如 `/api/v1/users/conversation` 和 `/api/v1/admin/conversation`）也都是直接从 Redis 中读取数据，没有涉及数据库持久化。 ### 补充说明 这种设计属于**缓存即存储**模式，优点是读写性能高、开发简单，但存在以下局限： 1. **数据有丢失风险**：TTL 过期（7 天）后数据自动清理，无法长期保留历史会话。 2. **不支持复杂查询**：Redis 对按时间范围、关键词等条件检索的支持有限。 3. **内存成本**：随着会话量增长，Redis 内存消耗会持续上升。 如果后续需要**长期归档对话数据**、**支持更复杂的检索/分析**或**满足合规审计要求**，将历史会话持久化到数据库（如 MySQL/PostgreSQL/ES）是一个合理的演进方向。不过当前版本的设计更侧重于**高性能实时对话体验**，所以选择了纯 Redis 的方案。

根据参考资料，**“支持多种 Prompt 模板配置与调优”** 主要是通过一套**自研模板引擎** + **Redis 缓存** + **动态变量替换**机制实现的。具体来说，分为以下几个层面： ### 1. 模板定义与管理 系统将 Prompt 模板作为结构化数据存储，每个模板包含以下核心字段（以 Redis 缓存为例）： ```json { "name": "knowledge_qa", "template": "你是派聪明...\n参考信息：{{context}}\n对话历史：{{history}}\n用户问题：{{query}}", "variables": ["context", "history", "query"], "max_tokens": 4000 } ``` - **Redis Key**：`prompt_templates:{templateName}` - **支持多个模板**：可根据不同场景（如知识问答、日常闲聊、业务咨询）配置不同的模板名称。 ### 2. 动态变量替换（核心实现） 系统通过自研模板引擎完成以下步骤： 1. **根据问题类型选择合适的模板**（例如知识类问题选中 `knowledge_qa` 模板）。 2. **填充变量**：将检索到的知识片段（`{{context}}`）、对话历史（`{{history}}`）、用户问题（`{{query}}`）等动态注入模板。 3. **上下文长度管理**：自动截断或压缩过长的历史记录，确保不超出模型的最大 Token 限制。 4. **系统指令拼接**：在模板中嵌入预设的规则（如“优先基于参考信息回答”、“引用来源使用[文档X]格式”等）。 ### 3. 调优支持 - **模板可配置**：通过修改 Redis 中的模板内容即可调整模型的行为风格（如严谨/活泼、详细/简洁）。 - **变量可扩展**：可根据业务需求新增变量（如 `{{user_name}}`、`{{language}}`），模板引擎自动适配。 - **参数可调**：每个模板可独立设置 `max_tokens` 等生成参数，针对不同场景精细化控制。 ### 总结 这套机制的本质是：**将 Prompt 视为可配置的模板资源**，通过**模板引擎**动态拼接检索结果+上下文+系统指令，再配合 **Redis 缓存**实现模板的快速读取和灵活调整。这就实现了你提到的“支持多种 Prompt 模板配置与调优”，也是派聪明实现 RAG（检索增强生成）的关键保障。