✅派聪明 RAG 聊天助手面试题预测，针对 WebSocket 和 prompt

1.我们来聊聊这个聊天助手。它最吸引人的特点之一就是像真人聊天一样，答案一个字一个字地蹦出来。这种‘流式响应’或‘打字机效果’，在技术上是如何实现的？

我先从整体的流程说起：当前端用户开始一次对话时，浏览器会通过 WebSocket 与后端建立一个长连接。这是一种双向的、长时间保持的连接，非常适合实时交互的场景，比如流式响应、打字机效果。

一旦用户在前端发出提问，这个消息就会通过 WebSocket 通道发送到后端。后端接收到消息后会去调用知识库去做一次混合检索，找出相关的文本内容后，再拼接上用户的历史上下文，构建一个完整的 Prompt。

接着去调用 DeepSeek，我们调用的是流式响应的 API。这一步是实现打字机效果的关键：我们用 Spring WebFlux 的 WebClient 作为 HTTP 客户端，在请求 LLM 的时候也以流式的方式订阅返回的数据流。也就是说，LLM 一边生成内容，一边把内容分成一小段一小段地推给我们，我们这边就一边接收一边处理。

每接收一段内容，就通过 WebSocket 立刻推送给前端。前端收到一小段字符后，就直接追加到聊天窗口中，给用户的感觉就是“打字机一点一点显示”的效果。

2.既然用到了WebSocket，那它和我们更常用的HTTP请求相比，有什么本质区别？为什么在这个场景下，必须用WebSocket？

WebSocket 能够支持服务端主动、实时地向客户端推送数据，而 HTTP 不具备这个能力。

具体来说，HTTP 是一种无状态、单向的请求-响应协议，它的工作机制决定了只能由客户端发起请求，服务端只是被动响应。哪怕我们用长...

热门评论

阿白 2026年01月27日 09:54

引用原文：首先，在检索这层，我们会给 Elasticsearch 设置一个相关性评分的门槛。比如我们会把低于 0.3 分的结果全部过滤掉。也就是说，如果一个文档跟用户的问题只有一点点关联关系，分数达不到要求，它就根本不会进入到下一步的上下文构建中。

@派聪明我们不是相似性检索和关键词检索综合评分吗？这个最后的0.3过滤是根据什么分数过滤的？

回复3 取消回复

派聪明 2026年01月27日 09:54

根据参考资料，系统在Elasticsearch检索层采用**混合检索策略**（结合相似性检索和关键词检索），最终生成的相关性评分是一个**综合得分**。0.3分是系统设定的**最低相关性阈值**，具体依据如下： --- ### 1. **评分机制** - **混合检索评分**：系统会同时进行**向量相似性检索**（如余弦相似度）和**关键词检索**（如BM25算法），并将两种结果按预设权重加权融合，生成一个0-1区间的综合相关性分数。 - **阈值过滤**：低于0.3分的文档被视为与用户问题关联度不足，直接排除，避免低质量信息进入后续上下文构建。 --- ### 2. **0.3阈值的设定依据** - **经验性平衡**： 0.3是系统通过多轮测试确定的平衡点： - **查全率 vs. 查准率**：过低阈值（如0.1）可能召回过多无关文档，导致LLM混淆；过高阈值（如0.5）可能遗漏有效信息，降低回答覆盖率。 - **业务场景需求**：专业领域（如技术文档）要求更高相关性，而通用场景可适当放宽阈值。 - **动态调整可能性**：阈值可根据不同知识库特性或用户反馈微调（如高敏感领域采用更高阈值）。 --- ### 3. **为什么过滤低分文档？** - **避免LLM“胡说八道”**：参考资料明确要求，若上下文无足够信息，LLM需回答“无法回答”。低分文档可能包含错误或无关信息，干扰模型判断。 - **优化性能**：减少冗余数据传递，降低大模型处理负担和响应延迟。 --- ### 总结： 0.3分是**混合检索后的综合相关性阈值**，用于筛选与问题强相关的文档。这一数值通过平衡查全率、查准率及业务需求确定，确保进入LLM的上下文信息既相关又可靠。

回复取消回复

展开剩余 2 条回复

89 条评论

庸碌 2026年05月02日 22:34

引用原文：1.我们来聊聊这个聊天助手。它最吸引人的特点之一就是像真人聊天一样，答案一个字一个字地蹦出来。这种‘流式响应’或‘打字机效果’，在技术上是如何实现的？

@派聪明如果是使用sse实现怎么回答呢？

zhiwenfan 2026年04月20日 12:50

引用原文：conversationId

ID 生成机制，断联之后重连，如何确定这个ID号

回复1 取消回复

故意的香氛 2026年05月08日 10:24

从 redis 中获取： String key = "user:" + userId + ":current_conversation"; String conversationId = redisTemplate.opsForValue().get(key);

丰富的胡萝卜 2026年04月09日 16:41

引用原文：WebSocket 是一种有状态、全双工的协议，一旦连接建立，前后端就可以随时互相发送消息。

@派聪明接受大模型的流式回复是单队列接收吗，怎么避免多线程会造成的前端输出乱序呢

违规名称 2026年04月07日 09:54

引用原文：第二，我们在 Prompt 的 System 指令里给出了明确的规则，“如果你发现上下文里没有足够信息来回答用户的问题，请直接说‘无法回答’或者‘没有找到相关资料’，而不是强行输出。”

评分低的时候为什么不直接返回固定拒答文案，为什么还要调用llm回答

Akaina 2026年04月06日 19:45

@派聪明该项目从用户输入到得到响应需要多少时间

Akaina 2026年04月06日 19:42

该项目从用户输入到得到响应需要多少时间

借我 2026年04月03日 09:58

引用原文：然后在答案生成后还需要将新一轮的对话再次写入到历史记录中

每一次对话都会生成后直接写入还是在对话完全结束后再写入@派聪明

借我 2026年04月03日 09:03

引用原文：这一步是实现打字机效果的关键

智能对话时，到底是调用api还是本地Ollama部署呢@派聪明

过时的草莓 2026年04月01日 13:14

引用原文：前 N 个最相关

怎么确定这个N是多少

心已指南 2026年03月29日 15:04

@派聪明怎么理解这句话：基于 Redis 实现会话管理，支持 7 天对话历史存储，并在向量 API 调用失败时自动降级至文本搜索保障可用。

派聪明 2026年03月29日 15:04

这句话描述了一个智能对话系统的会话管理机制，核心要点如下： ### 1. **Redis 实现会话管理** - **存储方式**：使用 Redis 存储用户对话历史（参考资料第5、6、7节）。 - **数据结构**： - `user:{userId}:current_conversation_id` → 记录用户当前会话ID（UUID）。 - `conversation:{conversationId}` → 存储历史对话的JSON列表（包含用户消息和AI回复）。 - **优势**：Redis 内存读写速度快（微秒级），适合高频读写场景（参考资料第6节）。 ### 2. **7天对话历史存储** - **TTL 自动过期**：通过 Redis 的 `EXPIRE` 命令设置7天过期时间（参考资料第5节）。 - **数据清理**：过期后自动删除，无需手动维护（对比MySQL需定时任务）。 - **滑动窗口**：仅保留最近20条消息（参考资料第8节），避免上下文过长。 ### 3. **向量 API 失败时降级至文本搜索** - **正常流程**：优先调用向量 API 进行语义检索（如 Elasticsearch 向量搜索）。 - **降级机制**： - 当向量服务不可用时（如网络故障、服务宕机），自动切换到 **文本关键词搜索**（如 ES 的全文检索）。 - 确保核心功能（知识检索）仍可用，提升系统鲁棒性（参考资料第9节）。 --- ### 设计意图 - **性能与成本平衡**：Redis 高速读写支撑实时对话，7天TTL控制数据量。 - **容错能力**：降级机制保障服务可用性（参考资料第3、10节强调稳定性）。 - **上下文管理**：通过会话ID关联历史，实现多轮对话连贯性（参考资料第5节）。 > 示例流程： > 用户提问 → 检索知识（向量API → 失败 → 降级文本搜索） → 结合Redis历史 → 生成回答 → 存入Redis（7天后自动清除）。

1.我们来聊聊这个聊天助手。它最吸引人的特点之一就是像真人聊天一样，答案一个字一个字地蹦出来。这种‘流式响应’或‘打字机效果’，在技术上是如何实现的？

2.既然用到了WebSocket，那它和我们更常用的HTTP请求相比，有什么本质区别？为什么在这个场景下，必须用WebSocket？

热门评论

89 条评论

目录

划线评论