派聪明 RAG 真实面经参考，已累计 27 家，700 道题目（不断更新中）

1.快手快 star

描述一下上传文件，提问到显示答案整个数据流以及涉及到的模块/技术栈

后端服务是基于 Spring Boot 3 构建的，文件上传时会用到 MinIO 和 Kafka，MinIO 用来存储文件，Kafka 用来做文件异步解析。

消费者会从 MinIO 中拉取文件，然后使用 Tika 解析分块后调用 embedding 模型生成向量，并且文本、向量存入到 ElasticSearch 中。

用户提问后会先对问题向量，然后在 ElasticSearch 中执行混合检索，一方面做向量的相似度检索、语义召回，另一方面结合 BM25 做关键词检索。

然后将检索到的上下文拼接到 prompt 一并发给大模型生成答案。后端通过 webflux 的 SSE 进行流式返回，前端实时进行渲染。

怎么 chunk 的，为什么这么做？

我采用了基于语义边界的递归切分策略。具体做法是先按照段落进行切分，如果某一块超过了设计的分块大小，就用降级的句号进行拆分，直到每个 chunk 都控制在规定的范围内，通常在 500 个字内。

同时我还引入了 overlap，设置为 10%，这样相邻的 chunk 会有一小段内容重叠，避免关键语义被切断。

这么做主要有三个原因，embedding 模型本身有输入长度限制，分块是向量化的前提；语义集中的 chunk 在混合检索时也会更容易被精准召回；重叠的 overlap 能提供更好的上下文信息。

用的什么模型，有对比过吗

向量这块一开始用的豆包，但后来不向下兼容 2048 维，于是就切换到阿里的 embedding 模型。

LLM 这块一直用的 DeepSeek。

检索结果不符合预期怎么办

先搞清楚问题发生在哪个阶段：

相关内容有没有被召回，如果没有，多半是分块或者向量时的问题；
如果召回了但排序靠后，那就是混合检索时排序的问题了。

第一步，调整 chunk_size 和 overlap，强化语义边界的递归切分；

第二步，更换 embedding 模型，看看其他模型是否会更好。

第三步，调整 BM25 与向量检索的权重，把最相关的 3 到 5 条上下文喂给 LLM。

第四步，用 MRR 这类指标做对比验证。

ES 里怎么存的

ElasticSearch 的索引名为 knowledge_base，会存三个字段：内容、向量、权限。

首先是内容字段，我们定义为 textContent，它的类型是 text，底层配的是 ik 中文分词器。这个字段用来支持关键词检索的，像 BM25、match 查询都是作用在这个字段上。

然后是向量字段，名叫 vector，我们定义为 dense_vector 类型，维度是 2048，这个维度要和 embedding 模型匹配。这个字段用来做语义检索。当用户发起查询时，我们会把查询的内容转成向量，再用 KNN 算法去比相似度。

接着是权限相关的字段，在做 B 端多租户场景时要非常重视的一块。主要有三个字段：userId、orgTag 和 isPublic。

userId 标记这个文档片段属于哪个用户，用于实现私有文档的权限隔离；
orgTag 表示文档所属的组织标签，用来控制组织内的授权访问；
isPublic 标记文档是否对所有人公开。

分片上传是怎么做的？断点续传？你这个场景有意义吗？

对于大文件，派聪明采用的是‘分片上传 + 断点续传’的方式。我们会在前端先把大文件切成小的分片，比如 5MB 一块，然后并发地上传到后端。后端每收到一个分片，就存到 MinIO 中，同时会用 Redis 的 bitmap 去记录哪些分片已经上传成功。这样的好处就是，即使上传过程中断了，前端可以根据 Redis 状态判断哪些分片已经上传，不用从头开始，用户体验会比较好。

当所有分片上传完成后，前端会调用后端的合并接口。这里我们用的是 MinIO 提供的 composeObject 功能，直接在存储端完成分片的合并，合并完成后，系统会把文件状态在 MySQL 里更新为‘已完成’，并且清理掉对应的分片文件和 Redis 记录。

非常有意义，等到网络恢复后，前端会带着这个文件的 MD5 去后端的 Redis 里查所有分片的状态，前端拿到分片状态后，在重新上传的时候，就会跳过那些已经上传成功的分片，只上传那些还没传的。这样就避免了重复上传。

2.小红书一面

AI & RAG 相关

RAG 怎么解决 LLM 上下文窗口有限的问题？
RAG 里的“重要性重排序”是怎么判断哪个内容更“重要”的？
流式对话支持多轮吗？怎么实现的？
提示词做了哪些优化？如果多轮对话关联性不强，怎么抓住新问题的重点？
OpenAI 协议里，上下文的角色有哪几种？
system, user, assistant 这几个角色在使用上有什么区别？

Java 基础 & 并发

讲讲 Java 不同更新版本的区别，特别是关键版本。
为什么 Spring Boot 3.x 要用 Java 17+的版本？项目里用了哪些新特性？
Lambda 表达式和 Stream API，跟传统的 for 循环比，优缺点是什么？
parallelStream()为什么性能好？底层是什么实现的？
如果不用 parallelStream，用传统 for 循环自己写并发提交任务，代码大概分几块？
都说 Java 线程“重”，Go 协程“轻”，这个“重”具体体现在哪？
为什么 Java 线程实际只用很少的栈，但 JVM 却要给它分配那么大的栈空间？
协程到底是个什么东西？
Java 里写 for 循环有几种方式（比如用索引 i，用迭代器），它们有什么区别？

算法手撕

实现一个函数，找出字符串里所有长度大于 1 的子回文串。

3.某对标亚信公司一面

面了一家听说对标亚信的公司，面试官口头和我说过了，下一轮 boss 面让我瞎聊就行
java 基础和集合查缺补漏面经：
embedding 用什么模型？
混合检索？怎么评估准确性？
大模型的选择
上下文管理？
redis 的击穿，雪崩，穿透
AOP
MySQL binlog 监听通过主从复制原理
ThreadLocal
消息队列，消息如何不丢失？

要我现场跑跑派聪明，没跑起来。。。很悲催，我没改前端也不怎么熟悉流程。

4.未知公司

面经：

1、介绍项目从数据上传到最后存入数据库的流程、RAG 流程
2、切块的步骤、如何评价优化前后的 RAG 的好坏
3、针对用户不同的提问：提问语句长短不同，分别怎么检索？
4、向量化的数据有做处理吗？

5.腾讯二面

1.派聪明技术选型，如为什么用 minio 做文件存储、选择 es 等
2.rag 的准确率如何优化
3.语块如何分片
4.es 相关
5.大文件也可以断点续传为什么要分片？
6.从用户体验上来说，一个文档也没有很大，分片上传的提升并不大，这里如何考虑的？

6.合合信息一二面

一面面经

拷打项目

讲一下自己的 rag 这一套流程的理解
在里面采取了哪些技术
对接大模型用的什么
文件拆分是怎么分割的
用户提交问题后的流程
中间过程纯手工编的吗？（我答的没用 langchain4j 或者 Spring ai）
如果有充足时间优化会优化哪些点
怎么解决检索过程中的权重误差？
如何优化检索来提高回答准确性？
了解过 agent 和 mcp 吗？
可以把整个流程让大模型自动弄吗？
如果用 agent 代替，你会怎么设计呢？
多人会话历史的窗口怎么设计的？
考虑过怎么优...

10 条评论

微信用户 2026年03月07日 23:32

引用原文：怎么测试检索准确率

回复1 取消回复

派聪明 2026年03月07日 23:32

测试检索准确率需结合自动化工具与人工评估，具体方法如下： --- ### **1. 构建测试集** - **标注数据**：人工标注问题与对应的标准答案文档ID（或关键内容片段），形成测试集（如1000组问答对）。 - **覆盖场景**：包含简单查询、模糊语义、专业术语、多轮对话等典型场景。 --- ### **2. 自动化评估** - **指标计算**： - **召回率（Recall）**：检索结果中包含标准答案的比例。 - **精确率（Precision）**：检索结果中正确答案的比例。 - **MRR（倒数排名）**：标准答案在检索结果中的排名倒数平均值（排名越前，分数越高）。 - **工具使用**：用LangChain、Ragas等框架的评估器自动计算指标（如`ragas.evaluate()`），避免人工统计偏差。 --- ### **3. 人工校验** - ***样验证**：随机**测试结果（尤其低分案例），人工**： - 检索结果是否语义相关（即使未命中标准答案）。 - 排序是否合理（关键信息是否*前）。 - **错误分类**：分析失败原因（如分块不当、向量偏差、关键词遗漏），针对性优化。 --- ### **4. 持续监控** - **A/B测试**：上线前对比新旧方案（如调整chunk策略或更换模型）的指标变化。 - **日志分析**：记录用户反馈（如“答案无关”），反推检索问题并迭代。 > **关键点**：自动化工具提升效率，人工校验确保质量，两者结合才能全面评估检索效果。

qingisq 2026年03月07日 20:41

引用原文：上下文管理

@派聪明回答一下

派聪明 2026年03月07日 20:42

在“派聪明”项目中，上下文管理主要体现为**多轮对话**的管理**，具体实现如下： ### 1. **存储与长度控制** - **存储位置**：用户对话**存储在 **Redis** 中，以用户ID或会话UUID为键，**记录为值。 - **长度限制**：仅保留最近 **20 条** 对话记录，避免上下文过长导致性能下降或模型处理超时。 - **裁剪策略**：当**记录超过阈值时，自动裁剪最旧的记录，保留最新内容。 ### 2. **上下文拼接与优化** - **Prompt构造**：每次用户提问时，系统将**记录与当前问题拼接，形成完整上下文，并添加特殊分隔符（如 `<<REF>>`）区分知识库引用与对话**。 - **压缩处理**：若上下文过长，可对**记录进行**语义压缩**（如提取关键句），减少冗余信息，同时保留核心语义。 ### 3. **权限与隔离** - **多租户隔离**：通过 `userId` 和 `orgTag` 字段在ElasticSearch中隔离不同用户/**的文档，确保上下文仅包含用户有权访问的内容。 - **引用标注**：知识库片段在上下文中标注来源（如 `来源#1`），避免混淆对话**与外部知识。 ### 4. **效果保障** - **兜底机制**：若检索结果为空，上下文标记为“（无检索结果）”，**模型基于自有知识回答，避免幻觉。 - **流式响应**：通过 **SSE（Server-Sent Events）** 实时返回生成内容，提升交互体验。 ### 优化方向 - **动态调整**：根据问题相关性动态调整**记录权重（如关联性强的**保留优先级更高）。 - **压缩算法**：探索更高效的上下文压缩方法（如LLM微调压缩）。 **总结**：上下文管理通过Redis存储、长度裁剪、权限隔离和语义拼接，平衡了多轮对话的连贯性与系统性能。

引用原文：大模型的选择

根据参考资料中“大模型的选择”相关内容，派聪明项目的技术选型如下： ### 大模型选择：DeepSeek - **核心原因**：项目中大型语言模型（LLM）**全程使用 DeepSeek**，主要基于其稳定性和性能表现（参考资料1、7）。 - **对比与迁移**： - 最初尝试使用豆包模型，但因豆包停止向下兼容 2048 维向量，最终切换为阿里提供的 embedding 模型（用于向量生成）。 - **LLM 始终未更换**，DeepSeek 作为答案生成的核心引擎（参考资料1）。 ### 选型考量 1. **稳定性与兼容性**： DeepSeek 的 API 接口稳定，支持流式输出（通过 WebFlux 的 SSE 实现），适合实时渲染场景（参考资料1）。 2. **成本与效果平衡**：未提及具体成本数据，但选择 DeepSeek 是在“豆包不兼容”后的务实选择，确保向量维度与 Elasticsearch 的 2048 维向量字段匹配（参考资料1、7）。 3. **业务适配性**： DeepSeek 能高效处理拼接后的检索上下文（用户问题 + Top-K 知识片段），生成符合要求的答案（参考资料1、16）。 ### 其他技术补充 - **Embedding 模型**：因豆包的兼容性问题，最终采用阿里 embedding 模型生成 2048 维向量，存储于 Elasticsearch 的 `vector` 字段（参考资料1、7）。 - **Prompt 设计**：通过配置文件动态调整 DeepSeek 的提示词（如引用标注、无结果兜底策略），增强输出可控性（参考资料7、16）。 > 总结：项目在 LLM 层面 **固定使用 DeepSeek**，而向量模型因兼容***从豆包迁移至阿里模型。选型核心围绕 **稳定性、维度兼容性及业务落地效率** 展开。

微信用户 2026年03月07日 16:42

引用原文：说说分代回收

派聪明 2026年03月07日 16:43

分代回收是JVM垃圾回收的核心策略，基于对象生命周期将堆内存分为**新生代**（Young Generation）和**老年代**（Old Generation）： 1. **新生代**（占比约1/3） - **Eden区**：新对象分配区域。 - **Survivor区**（S0/S1）：存放经过一次Minor GC后仍存活的对象（比例默认8:1:1）。 - **回收算法**：复制算法（高效，存活对象少）。 2. **老年代**（占比约2/3） - 存放**存活对象（经历多次Minor GC后晋升）。 - **回收算法**：标记-清除/标记-整理（避免内存碎片）。 3. **触发机制** - **Minor GC**：Eden区满时触发，仅回收新生代。 - **Major GC/Full GC**：老年代空间不足时触发，可能伴随新生代回收（STW时间长）。 4. **对象晋升** - 对象在Survivor区中每经历一次Minor GC，年龄（age）+1，达到阈值（默认15）后晋升至老年代。 **优势**：针对不同生命周期对象采用不同算法，大幅提升回收效率，减少STW时间。

微信用户 2026年03月07日 16:02

引用原文：.说一下调用 LLM 的角色分类？使用哪种角色会更好？

派聪明 2026年03月07日 16:03

根据参考资料中多个面试场景（如菜鸟一面、慧科讯飞实习等）的提问，LLM角色分类及最佳选择如下： ### 1. **LLM角色分类** - **System角色**：定义全局规则、系统指令和约束（如输出格式、行为准则）。 *示例*：`"必须标注引用来源，如'来源#1'；若检索不到结果，回复'暂无相关信息'"`（派聪明项目实践）。 - **User角色**：承载用户输入，包含当前问题、**对话上下文或检索到的知识片段。 *示例*：用户提问 + 检索到的`<<REF>>知识片段<<END>>`。 - **Assistant角色**：记录模型生成的回复，用于多轮对话的上下文延续。 ### 2. **最佳实践：System + User组合** - **优先使用System角色**： - 通过**硬性约束**确保模型遵循规则（如引用标注、避免幻觉），减少对提示词的重复依赖。 - *案例*：派聪明项目在System中强制要求标注引用编号，提升回答可信度。 - **User角色灵活承载动态内容**： - 结合**对话（存储于Redis）和检索结果（如ES返回的上下文），实现多轮对话的语义连贯性。 - **慎用Assistant角色**： - 仅在长对话场景中用于**记录，避免冗余信息干扰当前推理。 ### 3. **关键优化点** - **隔离检索内容**：用特殊符号（如`<<REF>>`）包裹知识片段，明确区分用户输入与系统知识，防止混淆（派聪明Prompt设计）。 - **兜底机制**：若检索结果为空，在User中设置`"（本轮无检索结果）"`，**模型用自有知识回答或声明无法回答。 - **上下文压缩**：通过配置限制**对话长度（如Redis保留最近20条），避免超长上下文导致性能下降。 ### 总结 **System + User组合是最佳选择**：System角色提供稳定的行为框架，User角色灵活适配动态输入，两者结合能最大化控制模型输出质量，同时支持复杂的多轮对话场景。

微信用户 2026年03月07日 15:35

引用原文：混合检索的准确率怎么算，有没有考虑过从业务上去优化准确率。

派聪明 2026年03月07日 15:36

根据参考资料，混合检索的准确率计算及业务优化方案如下： ### **准确率计算方法** 1. **核心指标**：使用 **MRR（Mean Reciprocal Rank）** 评估检索质量，即首个相关结果在排序中的位置倒数（如首个相关结果排第3位，得分为1/3）。 2. **权重调整**：通过调整 **BM25（关键词检索）与向量检索的权重比例**，优化混合排序效果，确保高相关内容前置。 ### **业务优化策略** 1. **分块优化**： - 采用 **语义边界递归切分**（先按段落拆分，超限则按句号切分），控制chunk大小在500字内。 - 设置 **10%的overlap**，避免关键语义被切断，提升上下文完整性。 2. **Prompt设计**： - 在系统规则中明确要求标注引用来源（如“来源#1”），增强答案可信度。 - 对空检索结果设置兜底策略（如提示“暂无相关信息”），避免模型幻觉。 3. **模型与检索调优**： - 对比测试不同 **embedding模型**（如从豆包切换至阿里模型）。 - 动态调整 **top-K值**（如检索20条后仍无关键信息，可扩大范围或优化召回逻辑）。 ### **总结** 准确率通过MRR量化，业务优化聚焦分块语义完整性、Prompt约束及模型适配，确保检索结果既精准又符合用户场景需求。

思、凉 2026年03月07日 14:27

引用原文：怎么评估准确性？

派聪明 2026年03月07日 14:27

评估RAG系统准确性主要采用以下方法： 1. **量化指标评估**：使用MRR（平均倒数排名）等指标进行对比验证，衡量检索结果的相关性。 2. **分阶段评估**： - 检索阶段：评估相关内容是否被召回 - 排序阶段：评估召回内容排序是否合理 3. **业务场景测试**： - 构建测试集，包含各种典型问题 - 对比优化前后的检索效果 - 从业务角度评估回答质量 4. **人工评估**：由领域专家对检索结果和生成答案进行打分，判断相关性、准确性和完整性。 5. **A/B测试**：上线不同算法版本，通过用户反馈和点击率等指标评估实际效果。

凡尘 2026年03月03日 10:08

引用原文：混合检索？怎么评估准确性？

派聪明 2026年03月03日 10:10

混合检索评估准确性主要采用以下方法： 1. **指标评估**：使用MRR（平均倒数排名）、Precision（精确率）、Recall（召回率）、F1-score等指标量化评估检索质量，通过对比验证不同方案的效果。 2. **人工测试**：构建人工标注的测试集，评估检索结果的相关性和准确性，特别是针对关键信息是否被正确召回。 3. **参数调优**： - 调整BM25与向量检索的权重比例 - 优化chunk_size和overlap参数 - 尝试不同的embedding模型比较效果 4. **排序优化**：针对top-k结果中关键信息排在后面的问题，可以重新设计排序算法或调整检索策略，确保关键信息能出现在前列。 5. **分档分片**：对检索结果进行分档处理，提高不同类型信息的召回均衡性。评估时需结合业务场景，针对不同类型的问题（长短问题、主观/客观问题）分别测试，确保检索系统能在各种情况下保持高准确性。

竹紫 2026年03月01日 20:12

引用原文：JWT 是无状态的，那是不是只要有人拿到了这个 token，不管是谁，都可以拿着它去访问接口？

派聪明 2026年03月01日 20:12

JWT是无状态的，确实存在安全风险。如果攻击者获取了token，可以用来访问受保护的资源，因为JWT本身不包含身份验证信息，仅包含用户身份数据的签名。但可通过以下方式增强安全性： 1. 设置较短的有效期（如15-30分钟） 2. 使用HTTPS传输防止中间人攻击 3. 实现token刷新机制，避免**有效 4. 添加IP绑定或设备指纹等上下文验证 5. 服务端维护黑名单，可撤销已泄露的token 实际应用中，通常将JWT与服务器端会话管理结合使用，在关键操作时进行二次验证，平衡无状态便利性与安全性。

竹紫 2026年03月01日 19:57

引用原文：你觉得为什么要有 mq 这样的中间件

派聪明 2026年03月01日 19:58

MQ（消息队列）作为中间件的核心价值在于解决分布式系统中的**解耦、异步通信、削峰填谷和可*性保障**问题。以下是具体分析： --- ### 1. **系统解耦** - **问题场景**：系统模块间直接依赖（如业务服务直接调用文件解析服务），导致修改一方需同步修改另一方，扩展性差。 - **MQ解决方案**：模块通过消息队列通信，生产者（如上传服务）只管发送消息，消费者（如解析服务）独立处理，无需感知对方存在。 - **案例**：派聪明项目中，文件上传后通过Kafka发送任务，解析服务异步处理，两者完全解耦。 --- ### 2. **异步通信与性能提升** - **问题场景**：同步调用导致请求链路过长，响应延迟高（如用户上传文件后需等待解析完成才能返回）。 - **MQ解决方案**：非阻塞异步处理，主流程快速返回，耗时任务（如文件解析）由消费者异步执行。 - **效果**：用户体验提升，系统吞吐量增加（如美团项目中，Kafka异步处理文档解析）。 --- ### 3. **削峰填谷与流量控制** - **问题场景**：突发流量（如促销活动）导致服务过载（如数据库或CPU被打满）。 - **MQ解决方案**：消息队列作为缓冲层，将突发请求暂存，消费者按能力处理，避免系统崩溃。 - **案例**：百度测开项目中，MQ缓冲用户请求，防止大流量压垮后端服务。 --- ### 4. **可*性与容错** - **问题场景**：服务宕机或网络故障导致数据丢失（如文件解析失败后任务丢失）。 - **MQ解决方案**： - **持久化**：消息落盘存储（如Kafka的Topic持久化）。 - **重试机制**：消费失败后自动重试（如派聪明消费者重试4次）。 - **死信队列**：多次失败的消息转入DLT，避免阻塞主流程。 - **保障**：确保任务最终被处理（如顺丰科技强调Kafka消息不丢失）。 --- ### 5. **扩展性与负载均衡** - **问题场景**：单消费者处理能力不足，需水平扩展。 - **MQ解决方案**：多个消费者订阅同一队列，消息自动分配，实现并行处理（如Kafka消费者组）。 - **案例**：虾皮一面中，Kafka消费者组并行处理文件解析任务。 --- ### **对比其他方案** - **HTTP轮询**：效率低、资源浪费（频繁无效请求）。 - **直接RPC调用**：强耦合、同步阻塞，无法应对高并发。 - **WebSocket**：实时通信场景适用，但非持久化，不支持复杂路由和重试。 --- ### **总结** MQ是分布式系统的“润滑剂”，通过**解耦、异步、削峰、容错**四大能力，解决模块紧耦合、性能瓶颈和可*性问题。在派聪明、美团、百度等项目中，Kafka/RabbitMQ承担了文件处理、用户交互等核心异步任务，是系统高可用的关键组件。