杠精派
派聪明
0/512

热门评论

Taodada 2026年03月20日 22:32
引用原文:服务端接收到消息后,会优先解析 JWT,获取用户身份,并为其确定当前会话 ID
@派聪明 这个会话id是怎么生成的?
点赞
回复5 取消回复
派聪明 2026年03月20日 22:33
根据参考资料中描述的流程,会话ID的生成机制如下: ### 会话ID生成逻辑: 1. **首次请求**(无历史会话): - 服务端解析JWT获取用户身份后,**自动生成一个新的会话ID**(具体算法未明确说明,但通常为**随机唯一标识符**,如UUID或时间戳+随机数)。 - 该ID与用户身份绑定,并写入Redis存储,作为当前会话的标识。 2. **后续请求**(已有会话): - 服务端从Redis中查询该用户是否**存在未过期的会话ID**。 - 若存在,则**复用该会话ID**,继续追加对话历史到Redis中对应的会话记录。 ### 关键设计点: - **唯一性**:会话ID需确保每个用户会话独立(通过用户身份+会话ID双重隔离)。 - **持久化**:会话ID及其对话历史存储在Redis中,支持多轮对话连续性。 - **生命周期**:会话记录有TTL(7天),超时自动失效(资料中提到“TTL重置为7天”)。 - **上下文隔离**:不同会话ID对应独立的对话历史,避免信息混淆。 > 注:资料未明确ID生成算法,但结合企业级系统实践,通常采用**高随机性UUID**或**用户ID+时间戳+随机数组合**,确保安全性与唯一性。
点赞
回复 取消回复
展开剩余 4 条回复

24 条评论

etovo 2026年07月20日 15:58
@派聪明 派聪明维护上下文过长时,会保留最近的20轮对话。那20轮之前的呢?会做摘要处理,合并到message发送给LLM吗,还是直接舍弃20轮之前的
点赞
回复1 取消回复
派聪明 2026年07月20日 15:58
根据派聪明的**当前实现**,超过20轮之前的对话历史是 **直接裁剪舍弃**,并不会做摘要合并。 具体的实现逻辑如下: 1. **当前做法**:系统从 Redis 中拉取会话历史时,最多只保留最近 20 条。如果超出,就自动裁剪掉更早的记录,以此来防止上下文爆炸,保持性能和响应效率。 2. **为什么没有做摘要**:因为摘要本身需要额外调用一次大模型来生成,会增加延迟和成本。目前派聪明优先保证响应速度和简洁性,所以选择直接舍弃较早的历史。 不过,**后续规划中已经明确了这项优化**——在"上下文智能摘要"方案中,当会话历史超过20条阈值时,系统会调用大模型对早期内容进行自动摘要,将冗长的上下文浓缩为精炼摘要,保留引用编号与核心要点,再合并到 Prompt 中发送给 LLM,这样既能兼顾上下文连贯性,又能控制 token 成本。 简单总结就是:**现阶段直接舍弃,未来计划做智能摘要后合并发送。**
点赞
回复 取消回复
心平气和 2026年04月12日 18:07
引用原文:模型调用的核心逻辑部分
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:06
引用原文:配置对象随后被注入到 DeepSeekClient 中,在构造模型请求 prompt 时直接读取。
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:05
引用原文:配置模型的采样参数,比如 temperature、top_p 和 max_tokens
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:05
引用原文:ai.prompt,用于存放系统提示词规则、引用段落的分隔符、无检索时的占位文本
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:04
引用原文:临时编号
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:04
引用原文:支持连续对话
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:04
引用原文:没有匹配内容
1
点赞
回复 取消回复
心平气和 2026年04月12日 18:03
引用原文:系统规则始终放在最前面,并用中文直接声明几件关键事情,比如:回复必须标注引用编号(例rulai源#1),如果检索不到结果也必须礼貌告知“暂无相关信息”
11
点赞
回复 取消回复
心平气和 2026年04月12日 18:03
引用原文:整个 Prompt 逻辑,包括提示词、引导规则、分隔符、温度参数
11
点赞
回复 取消回复

目录