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

根据参考资料中的设计，目前派聪明的**聊天助手模块确实只在 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（检索增强生成）的关键保障。

根据参考资料，当用户想要查看**之前其他会话**的历史记录时，系统的响应流程和数据流如下： --- ### **响应流程** 1. **发起查询请求** - 客户端向服务端发送 `GET /api/v1/users/conversation` 请求，携带用户的 JWT 认证信息。 2. **身份验证** - 服务端验证用户身份合法性。 3. **获取历史会话列表** - 服务端从 Redis 中读取用户的历史会话列表： - **Key**: `user:{userId}:conversations` - **Value**: 用户所有 `conversationId` 的 JSON 数组（按时间倒序排列）。 - 示例数据： ```json ["conv_20250526_1", "conv_20250525_3", "conv_20250520_2"] ``` 4. **定位目标会话** - 客户端需指定目标 `conversationId`（通过前端交互让用户选择会话）。 - 服务端根据提供的 `conversationId`，从 Redis 读取对应对话历史： - **Key**: `conversation:{conversationId}` - **Value**: 包含 `role`、`content`、`timestamp` 的消息数组（最多保存 20 条）。 - 示例数据： ```json { "messages": [ {"role": "user", "content": "问题A", "timestamp": "2025-05-26T10:30:15"}, {"role": "assistant", "content": "回答A", "timestamp": "2025-05-26T10:30:15"} ] } ``` 5. **返回历史记录** - 服务端格式化数据并返回给客户端，前端渲染为对话列表。 --- ### **数据流图示** ```mermaid sequenceDiagram participant Client participant Service participant Redis Client->>Service: GET /api/v1/users/conversation (JWT) Service->>Redis: GET user:{userId}:conversations Redis-->>Service: 返回历史会话ID列表 [conv_1, conv_2...] Service-->>Client: 返回会话ID列表（前端展示） Client->>Service: GET /api/v1/users/conversation?conversationId=conv_1 Service->>Redis: GET conversation:conv_1 Redis-->>Service: 返回对话历史消息 Service-->>Client: 返回格式化历史记录 ``` --- ### **关键点说明** 1. **多会话管理** - 系统通过 `user:{userId}:conversations` 存储用户的所有会话 ID，支持跨会话历史查询。 2. **数据隔离** - 每个会话的历史记录独立存储于 `conversation:{conversationId}`，避免混淆。 3. **性能优化** - Redis 的 TTL（7天）自动清理过期会话，防止数据堆积。 4. **前端交互** - 客户端需先获取会话列表，再由用户选择具体会话查询历史（参考资料未提供批量接口）。 > ⚠️ 注意：参考资料中未提供直接按 `conversationId` 查询的接口，实际实现需扩展 `/api/v1/users/conversation` 支持查询参数（如 `?conversationId=xxx`）。

根据参考资料，`userId` 的生成流程如下： 1. **用户身份认证** 用户首次登录时，系统通过 **JWT（JSON Web Token）** 进行身份验证。JWT 中包含用户的唯一标识（如用户ID、用户名等），由服务端在用户成功登录后生成并返回给客户端。 2. **客户端携带 JWT** 在后续操作中（如创建会话、发起对话），客户端需在请求头中携带有效的 JWT（例如 `Authorization: Bearer {JWT_TOKEN}`），用于证明用户身份。 3. **服务端解析 JWT** 服务端收到请求后，解析 JWT 获取其中的 `userId` 字段（或其他唯一标识字段）。例如： ```json // JWT 示例载荷（Payload） { "userId": "12345", // 用户唯一标识 "username": "test", "exp": 1703123456 } ``` 4. **构建 Redis 键名** 服务端将解析出的 `userId` 直接嵌入到 Redis 键名模板中，生成完整的键名： ```json Key: user:{userId}:current_conversation 示例: user:12345:current_conversation ``` ### 关键点总结： - **`userId` 来源**：JWT 中的用户唯一标识（如数据库主键、用户名等）。 - **生成场景**：用户登录时由服务端生成 JWT，后续操作通过 JWT 传递 `userId`。 - **用途**：用于管理用户会话（如当前会话映射、历史记录存储）。 > 注：系统未明确说明 `userId` 的具体生成规则（如是否为自增ID、UUID等），但核心机制是通过 **JWT 传递用户身份标识** 来动态构建 Redis 键名。

根据参考资料中的技术选型（WebSocket + Spring WebSocket + JWT），建立稳定 WebSocket 长连接的代码实现如下： --- ### 1. **WebSocket 配置类** ```java @Configuration @EnableWebSocketMessageBroker public class WebSocketConfig implements WebSocketMessageBrokerConfigurer { @Override public void registerStompEndpoints(StompEndpointRegistry registry) { // 注册 WebSocket 端点，支持 STOMP 子协议 registry.addEndpoint("/chat/{token}") // {token} 为 JWT 令牌 .setAllowedOriginPatterns("*") // 生产环境需配置具体域名 .withSockJS(); // 兼容浏览器 } @Override public void configureMessageBroker(MessageBrokerRegistry registry) { // 启用简单消息代理，广播前缀 /topic，点对点前缀 /user registry.enableSimpleBroker("/topic", "/user"); registry.setApplicationDestinationPrefixes("/app"); } } ``` --- ### 2. **JWT 认证拦截器** ```java @Component public class JwtChannelInterceptor implements ChannelInterceptor { @Override public Message<?> preSend(Message<?> message, MessageChannel channel) { StompHeaderAccessor accessor = MessageHeaderAccessor.getAccessor(message, StompHeaderAccessor.class); // 握手请求时校验 JWT if (StompCommand.CONNECT.equals(accessor.getCommand())) { String token = accessor.getFirstNativeHeader("Authorization"); if (token == null || !validateToken(token)) { throw new AuthenticationCredentialsNotFoundException("JWT 无效"); } } return message; } private boolean validateToken(String token) { // 实现 JWT 解析和校验逻辑 return JwtUtil.validate(token); // 假设的校验方法 } } ``` --- ### 3. **注册拦截器** ```java @Configuration public class WebSocketSecurityConfig implements WebSocketMessageBrokerConfigurer { @Autowired private JwtChannelInterceptor jwtInterceptor; @Override public void configureClientInboundChannel(ChannelRegistration registration) { // 注册 JWT 拦截器 registration.interceptors(jwtInterceptor); } } ``` --- ### 4. **连接建立后的处理** ```java @Controller public class ChatController { @MessageMapping("/chat.message") @SendTo("/topic/chat") // 广播消息到订阅者 public String handleMessage(String message, Principal principal) { // 处理用户消息（principal 包含已认证的用户信息） return "处理结果: " + message; } @EventListener public void handleWebSocketDisconnect(SessionDisconnectEvent event) { // 处理连接断开事件 System.out.println("用户断开连接: " + event.getUser()); } } ``` --- ### 关键点说明： 1. **稳定连接保障**： - 使用 `withSockJS()` 兼容浏览器 WebSocket 断线重连 - 通过 STOMP 协议实现消息可靠性传输 - Spring 自动管理 WebSocket 会话生命周期 2. **安全认证**： - JWT 令牌通过 `Authorization` 头传递 - 拦截器在连接握手时校验令牌有效性 - 已认证用户通过 `Principal` 对象获取身份信息 3. **连接管理**： - `SessionDisconnectEvent` 监听连接断开事件 - 可结合 Redis 实现分布式会话管理（参考资料中提到的会话存储） > 实际部署时需注意：Nginx 反向代理需配置 WebSocket 代理（如 `proxy_http_version 1.1`），并调整超时参数（`proxy_read_timeout`）以维持长连接稳定性。