派聪明 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月03日 10:08

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

回复1 取消回复

派聪明 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承担了文件处理、用户交互等核心异步任务，是系统高可用的关键组件。

忧伤的雨 2026年02月28日 15:19

引用原文：我看你用过 elasticsearch，主要用来干嘛的？里面存的什么数据？

派聪明 2026年02月28日 15:20

在派聪明项目中，ElasticSearch 主要用于构建企业级知识库，支持混合检索功能。它存储三类关键数据： 1. **文本内容字段(textContent)**：使用text类型，配置ik中文分词器，支持关键词检索(BM25、match查询等) 2. **向量字段(vector)**：使用dense_vector类型，维度2048，存储文本的向量化表示，用于语义检索和KNN算法相似度比较 3. **权限字段**：包括userId(用户ID)、orgTag(**标签)和isPublic(是否公开)，实现多租户权限隔离通过这种设计，ElasticSearch 能够同时支持关键词检索和语义检索，为用户提供精准的知识问答服务。

忧伤的雨 2026年02月28日 15:18

引用原文：ES 里面存的是什

派聪明 2026年02月28日 15:21

根据参考资料，ElasticSearch（ES）在派聪明项目中存储以下核心数据： ### 1. **索引结构** - **索引名称**：`knowledge_base` - **主要字段**： - **textContent** - **类型**：`text` - **用途**：存储文档分块后的原始文本，支持关键词检索（如BM25、match查询）。 - **分词器**：使用中文分词器`ik`优化中文检索效果。 - **vector** - **类型**：`dense_vector` - **维度**：2048（与阿里embedding模型匹配） - **用途**：存储文本向量化后的向量，用于语义相似度检索（KNN算法）。 - **权限字段** - **userId**：标记文档所属用户，实现私有文档隔离。 - **orgTag**：**标签，控制**内权限。 - **isPublic`**：是否公开访问。 ### 2. **存储逻辑** - **文本处理**：上传文件经MinIO存储、Kafka异步解析后，通过Tika提取内容 → 递归分块（按段落→句号拆分，控制块大小≤500字，10%重叠）→ 调用embedding模型生成向量 → 存入ES。 - **检索流程**：用户提问 → 问题向量化 → ES混合检索（向量相似度+BM25关键词）→ 拼接上下文 → LLM生成答案。 ### 3. **技术选型原因** - **ES的dense_vector**：支持高维向量存储与KNN检索，满足语义搜索需求。 - **ik分词器**：优化中文关键词检索效率。 - **权限字段**：适配B端多租户场景，保障数据安全。 > 示例数据结构： > ```json > { > "textContent": "文档分块内容...", > "vector": [0.1, 0.2, ..., 0.9], // 2048维向量 > "userId": "user123", > "orgTag": "orgA", > "isPublic": false > } > ```

忧伤的雨 2026年02月28日 15:15

引用原文：deepseek 在这里承担的角色

派聪明 2026年02月28日 15:16

根据参考资料中的描述，DeepSeek 在“派聪明”项目中承担以下核心角色： ### 1. **答案生成的核心模型** - 用户提问后，系统通过 ElasticSearch 检索相关知识片段（向量+关键词混合检索），并将检索到的上下文与用户问题拼接成 **Prompt**，最终提交给 DeepSeek 生成答案（见虾皮一面、快手快星描述）。 - 例如： > "将用户的原始问题和找到的相关知识片段一起交给大型语言模型（比如 DeepSeek），让这个‘大脑’基于给定的上下文生成精准答案。"（虾皮一面） ### 2. **处理复杂语义与上下文** - DeepSeek 负责理解用户问题的语义，结合检索到的知识片段生成连贯、符合逻辑的回答。其能力体现在： - 处理多轮对话**（存储在 Redis 中，最多保留 20 条）； - 对检索结果进行引用标注（如 `来源#1`）； - 处理无检索结果时的兜底策略（如回复“暂无相关信息”）（快手快星）。 ### 3. **与 RAG 流程的协同** - **输入**：用户问题 + 检索到的知识片段（通过 `<<REF>>` 分隔符隔离）； - **输出**：结构化答案（含引用编号）或兜底回复； - **优化点**：Prompt 中明确要求标注引用来源，避免生成幻觉（快手快星）。 ### 4. **技术选型原因** - 早期使用豆包模型，后因兼容性问题（豆包停止向下兼容 2048 维向量）切换至阿里 Embedding 模型，但 LLM 始终使用 DeepSeek（快手快星）。 --- ### 总结 DeepSeek 在项目中是 **答案生成的核心引擎**，负责将检索到的知识片段转化为用户可读的精准回答，并通过 Prompt 设计确保回答的引用透明性和逻辑性。其角色贯穿 RAG 流程的最终环节，直接影响答案质量。

忧伤的雨 2026年02月28日 14:52

引用原文：是否可以优化？

派聪明 2026年02月28日 14:53

基于参考资料中派聪明项目的文档分块策略，以下是优化方向及具体建议： --- ### **当前分块策略的局限性** 1. **语义完整性不足** - 当前按段落→句号递归切分，可能切断关键语义单元（如法律条款、技术步骤）。 - **优化建议**：引入**语义边界检测**（如使用BERT模型识别句子相关性），优先在语义完整处切分。 2. **固定大小限制** - 500字硬限制可能**长文档逻辑结构（如论文章节）。 - **优化建议**：**动态分块**，根据文档类型自适应调整（如技术文档按章节，合同按条款）。 3. **重叠率单一** - 10%重叠可能无法覆盖多级语义关联。 - **优化建议**：**分层重叠**（核心段落20%重叠，背景段落5%），平衡冗余与效率。 --- ### **检索效果优化** 1. **分块与检索协同** - 当前问题：检索结果中关键信息排在第21位（Top-K=20时丢失）。 - **优化建议**： - **混合检索权重调整**：提升BM25关键词权重，强化精确匹配（如法律条款中的专有名词）。 - **多级分块**：生成**粗粒度块**（章节级）和**细粒度块**（段落级），双路径检索后合并结果。 2. **向量模型优化** - 当前：阿里Embedding模型（2048维）。 - **优化建议**： - **对比测试**：尝试OpenAI text-embedding-3-large（3072维）或本地模型（如BGE-M3），评估召回率。 - **量化压缩**：使用FP16或INT8量化向量，降低ES存储压力，提升检索速度。 --- ### **工程层面优化** 1. **处理效率提升** - 当前：Kafka异步解析+Tika分块。 - **优化建议**： - **流式分块**：边解析边分块（如PDF流式读取），减少内存占用。 - **GPU加速**：向量化改用CUDA推理，吞吐量提升3-5倍（实测参考）。 2. **缓存机制** - 重复文档（如多人上传相同合同）重复解析。 - **优化建议**： - **Redis缓存分块结果**，以文件MD5为Key，TTL设为7天。 - **增量更新**：仅处理新增/修改段落（通过文档版本号控制）。 --- ### **效果验证方法** 1. **离线评测** - 构建测试集（标注问题-答案对），对比优化前后的： - **召回率**（Recall@K） - **准确率**（答案引用正确率） - **MRR**（Mean Reciprocal Rank） 2. **A/B测试** - 灰度发布新策略，监控线上指标： - **用户停留时长**（答案相关性） - **重复提问率**（信息缺失导致二次提问） --- ### **总结** 优化核心在于**语义完整性**（动态分块+边界检测）、**检索精准度**（权重调整+多级分块）和**工程效率**（缓存+加速）。通过迭代测试验证效果，平衡召回率与资源消耗。

17799176100 2026年02月25日 21:55

引用原文：Java 里写 for 循环有几种方式（比如用索引 i，用迭代器），它们有什么区别？

派聪明 2026年02月25日 21:56

Java中主要有三种`for`循环写法，区别如下： ### 1. **传统`for`循环（索引遍历）** ```java for (int i = 0; i < *********(); i++) { Object item = ********(i); } ``` - **特点**：通过索引遍历，适用于数组或`List`。 - **优点**：可访问索引位置，支持修改集合（需谨慎）。 - **缺点**：代码冗长；对非索引集合（如`Set`）不适用。 --- ### 2. **增强`for`循环（`for-each`）** ```java for (Object item : list) { // 使用item } ``` - **特点**：Java 5+引入，自动迭代。 - **优点**：代码简洁，避免索引错误；支持所有`Iterable`对象（如`List`、`Set`、数组）。 - **缺点**：无法获取索引；**不能修改集合**（会抛出`ConcurrentModificationException`）。 --- ### 3. **迭代器方式** ```java Iterator<Object> it = list.iterator(); while (it.hasNext()) { Object item = *******(); *********(); // 安全删除当前元素 } ``` - **特点**：通过`Iterator`接口遍历。 - **优点**：**支持安全删除**元素；适用于所有`Iterable`集合。 - **缺点**：代码最繁琐；需手动处理迭代状态。 --- ### **核心区别总结** | **方式** | **可修改集合** | **获取索引** | **适用场景** | |----------------|--------------|------------|--------------------------------| | 传统`for`循环 | ✅（需谨慎） | ✅ | 数组或`List`，需索引或修改时 | | 增强`for`循环 | ❌ | ❌ | 遍历元素，不修改集合 | | 迭代器方式 | ✅（安全） | ❌ | 需要遍历中删除元素时 | > **实际开发建议**： > - 优先用`for-each`（简洁安全）。 > - 若需删除元素或操作索引，用传统`for`或迭代器。 > - 遍历`Set`/`Map`时，只能用`for-each`或迭代器。

17799176100 2026年02月25日 21:41

Lambda 表达式和 Stream API，跟传统的 for 循环比，优缺点是什么？@派聪明

派聪明 2026年02月25日 21:42

Lambda和Stream API与传统for循环的优缺点：优点： 1. 代码简洁：Lambda表达式用更少的代码实现相同功能，Stream API能链式操作，代码更紧凑 2. 可读性高：函数式风格更直观表达操作意图，如filter、map等 3. 并行处理：Stream API内置并行能力，通过parallelStream()轻松实现多核并行 4. 函数组合：可灵活组合多个操作，如filter().map().reduce() 缺点： 1. 性能开销：Stream操作有额外开销，简单场景下不如传统for循环高效 2. 调试困难：函数式代码执行流程不直观，调试时难以追踪状态变化 3. 学习成本：需要理解函数式编程概念，新手可能不熟悉 4. 资源消耗：并行流会创建额外线程，管理不当可能导致资源浪费适合场景：复杂数据处理、并行计算、函数式风格团队；简单迭代或性能敏感场景仍推荐传统for循环。

17799176100 2026年02月25日 21:38

引用原文：Lambda 表达式和 Stream API，跟传统的 for 循环比，优缺点是什么？

@聪明派

回复2 取消回复

17799176100 2026年02月25日 21:39

17799176100 2026年02月25日 21:46

Lambda和Stream API与传统for循环的优缺点：优点：代码简洁：Lambda表达式用更少的代码实现相同功能，Stream API能链式操作，代码更紧凑可读性高：函数式风格更直观表达操作意图，如filter、map等并行处理：Stream API内置并行能力，通过parallelStream()轻松实现多核并行函数组合：可灵活组合多个操作，如filter().map().reduce() 缺点：性能开销：Stream操作有额外开销，简单场景下不如传统for循环高效调试困难：函数式代码执行流程不直观，调试时难以追踪状态变化学习成本：需要理解函数式编程概念，新手可能不熟悉资源消耗：并行流会创建额外线程，管理不当可能导致资源浪费适合场景：复杂数据处理、并行计算、函数式风格团队；简单迭代或性能敏感场景仍推荐传统for循环。