派聪明 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
消息队列，消息如何不丢失？

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

4.未知公司

面经：

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

5.tengxun二面

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

6.合合信息一二面

一面面经

拷打项目

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

聊 mydb 项目是自己做的吗？（go 改的）最大收获是...

28人已点赞

325 条评论

喜羊祥 2026年09月29日 14:35

引用原文：RAG 里的“重要性重排序”是怎么判断哪个内容更“重要”的？

回复1 取消回复

派聪明 2026年09月29日 14:35

这是我从文章中选择的一段文本："RAG 里的“重要性重排序”是怎么判断哪个内容更“重要”的!" 请围绕这段划线内容进行回复。当前模型还在开发当中，请右上角下拉框切换到其他模型

嘿嘿 2026年09月01日 20:54

引用原文：3.说说 g1 和 cms

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

**G1 和 CMS 的区别（垃圾回收器对比）** **CMS（Concurrent Mark Sweep）** - 目标：最短停顿时间，大部分标记工作与用户线程并发执行- 过程：初始标记（STW）→ 并发标记 →重新标记（STW）→ 并发清除-缺点： 1. 采用标记-清除算法，会产生内存碎片2. 无法处理浮动垃圾，需预留空间，可能触发 Serial Old 的 Full GC（停顿很长） 3. CPU敏感，并发阶段影响吞吐量**G1（Garbage First）** -面向服务端应用，JDK9 后的默认回收器-核心思想：将堆划分为多个大小相等的 Region，每个 Region 可动态扮演 Eden、Survivor、Old 或 Humongous（大对象）区- 特点： 1. 可预测停顿时间模型，能通过 `-XX:MaxGCPauseMillis` 设定目标2.优先回收垃圾最多的 Region（"Garbage First" 名字的由来） 3.整体基于标记-整理，Region之间是复制算法，基本不产生内存碎片- 过程：初始标记（STW）→ 并发标记 → 最终标记（STW）→筛选回收（STW，并行高效） **核心区别总结** | 维度 | CMS | G1 | |---|---|---| |算法 |标记-清除 |标记-整理+复制 | |碎片 | 有 |基本无 | |堆布局 | 传统分代 | Region 分区 | |停顿控制 |尽量短但不可预测 | 可设定目标停顿 | | 适用场景 | 小中型堆 | 大堆（4GB+）、低延迟要求 | 面试时建议再补充：G1 是 JDK9+默认，CMS 已在 JDK14被移除。

嘿嘿 2026年09月01日 20:53

引用原文：hashmap 的底层，红黑树会退化回链表吗，长度为什么是 8。

派聪明 2026年09月01日 20:53

这是字节客户端二面被问到的经典问题，考察 HashMap底层实现，可以从三个层面回答： **1.红黑树会退化回链表吗？** 会。当链表长度超过8 且数组长度达到64 时，链表才会树化（treeifyBin）。反之，在扩容（resize）或移除元素时，如果红黑树节点数减少到 **6 个或更少**，就会退化（untreeify）回链表。 **2. 为什么树化阈值是8，退化阈值是6？** - **8 的来源**：HashMap源码注释中说明，在理想的哈希分布下，节点落在同一个桶的概率遵循**泊松分布**，链表长度达到8 的概率约为 **0.00000006**（千万分之六），几乎不可能发生。所以树化是一种兜底手段，只在哈希严重冲突（如恶意构造 key 或劣质 hashCode）时才触发，正常情况下仍是链表，保证插入效率。 - **为什么不直接用红黑树**：树节点（TreeNode）占用空间约是普通节点（Node）的2倍，链表在长度较短时遍历效率也够用，没必要默认用树。 - **为什么退化阈值是6而不是8**：留出一个缓冲带（6、7、8），避免节点数在7~8之间频繁增删时，链表和红黑树**反复互相转换**，造成性能抖动。 **3.补充要点** - 数组长度小于64 时，即使链表到8也不树化，而是优先扩容（resize），因为小容量下冲突多半是容量问题； -链表查找 O(n)，红黑树查找 O(log n)，树化本质是防止极端情况下退化成 O(n) 的查询。这样回答既覆盖了“会不会退化”，也能讲清阈值设计的数学依据，是面试官期待的完整答案。

嘿嘿 2026年09月01日 20:40

引用原文：redis 在项目中的的作用

@派聪明作用是什么

派聪明 2026年09月01日 20:40

Redis 在该项目中的作用主要有以下几点： **1. 分片上传的断点续传记录** 大文件分片上传时，后端用 Redis 的 **bitmap**记录哪些分片已上传成功。上传中断后，前端可凭文件 MD5查询 Redis中的分片状态，跳过已上传的分片，只传未完成的部分。所有分片合并完成后，再清理对应的 Redis记录。 **2.存储多轮对话历史（会话上下文）** 用户的对话历史存在 Redis 中，采用 **Hash** 结构：用户 id → 会话 uuid → 会话记录，方便后续多轮对话时拼接上下文给大模型。同时做了长度控制，最多保留最近20 条，超过自动裁剪，防止上下文膨胀，保证性能和响应效率。总结来说，Redis 在项目中主要承担两类职责： - 利用其**临时状态存储**能力（bitmap）支撑断点续传； - 利用其**高性能读写**能力（Hash）支撑多轮会话上下文管理。

星野 2026年08月21日 10:14

引用原文：都说 Java 线程“重”，Go 协程“轻”，这个“重”具体体现在哪？

派聪明 2026年08月21日 10:14

这是我从文章中选择的一段文本："都说 Java 线程“重”，Go 协程“轻”，这个“重”具体体现在哪!" 请围绕这段划线内容进行回复。当前模型还在开发当中，请右上角下拉框切换到其他模型

权志龙的少年啊🌼 2026年08月03日 15:29

引用原文：底层配的是 ik 中文分词器

这个有什么用@派聪明

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

小派正在努力回答中, 耐心等待一下吧...

etovo 2026年07月21日 13:12

引用原文：MYDB

@派聪明 mydb是什么

派聪明 2026年07月21日 13:13

# MYDB 是什么？ MYDB 是一个**简化版的关系型数据库实现项目**，主要用于学习数据库底层核心原理。从面试面经中可以提炼出这些关键信息： ## 项目背景 - 参考了知名 Go 语言实现的数据库项目（如 Tidis、MiniRedis 类项目），用 **Java** 重新改写实现。 - 属于**学习型项目**，帮助深入理解数据库底层运作机制。 ## 涵盖的核心技术点面经中面试官反复拷打的内容包括： | 知识点 | 说明 | |-------|------| | **MVCC（多版本并发控制）** | 事务隔离级别的底层实现机制 | | **B+树索引** | 数据的组织结构、与 B 树的区别 | | **事务管理** | 事务的开始、提交、回滚 | | **隔离级别** | 不同隔离级别下会出现的问题 | | **两阶段提交** | 保证分布式事务的一致性 | | **覆盖索引** | 索引优化的典型场景 | | **SQL 执行流程** | 一条 SQL 语句从解析到返回结果的全链路 | ## 面试中常被问到的点 > “一条语句在 MYDB 中执行的流程是什么？” > “B+树是如何设计的？数据在 B+树中怎么存放？” > “MVCC 基本原理说一下” > “压力测试怎么做？QPS 提升多少？” ## 一句话总结 **MYDB 是一个用 Java 从零手写的迷你数据库项目**，通过造轮子的方式吃透 MySQL 的事务、索引、MVCC 等核心原理。很多面试官看到这个项目会认为你有**扎实的底层功底**，所以拷打得也比较深。

冰桃姚姚乌龙 2026年07月18日 20:06

引用原文：追问，那会话记录是生成一句存一句吗

派聪明 2026年07月18日 20:06

我们来聊聊这个问题。这句话出自**美的线下终面**中对派聪明项目的追问。面试官的核心疑问是：**Redis 中存的会话记录，是每次 AI 生成完一句话就立刻存一句吗？** 答案是：**通常是整轮对话（一次用户提问 + 一次 AI 回答）作为一个完整单元去存储的，而不是“生成一句存一句”。** 在派聪明里，Redis 存储会话记录使用的是 **Hash 结构**，大致结构如下： ``` key: user:{userId}:session:{sessionUuid} field: 消息顺序号（如 1, 2, 3...） value: 单轮对话内容（JSON 格式，包含 role 和 content） ``` **为什么不是“生成一句存一句”？** 因为大模型是流式返回的（SSE 逐 token 输出），如果每收到一个 token 或一句中间结果就往 Redis 写一次，会产生大量无意义的小写入，既浪费性能，又容易造成 Redis 的频繁写压力。正确的做法是： 1. 前端把用户提问一次性发给后端。 2. 后端调大模型后，**等待整个流式返回结束**，拿到完整的 AI 回答文本，再**整体**拼成一条消息，写入 Redis。 3. 也就是说，**每次写入 Redis 的是一条完整的 user 消息 + 一条完整的 assistant 消息**，而不是生成过程中的中间碎片。 **那如果要实时显示呢？** 那是前端的渲染逻辑——后端通过 SSE 把流式内容实时推送给前端展示，但**落盘到 Redis 是等流结束才做的**。这样既保证了用户体验（实时显示），又保证了存储的合理性（减少写次数，避免碎片化）。 **补充细节：** - 会话历史长度一般会做限制（比如最多保留最近 20 轮），避免 Redis 占用过大。 - 当多轮对话时，新的一轮（user + assistant）追加到 Hash 中，超过限制则裁剪最早的记录。所以，回答这个问题时可以说：**不是生成一句存一句，而是等整轮对话完成后，把用户问题和完整 AI 回答一起作为一个整体存入 Redis，用 Hash 结构按轮次组织，并配合长度限制来管理上下文窗口。**

冰桃姚姚乌龙 2026年07月18日 20:05

引用原文：为什么用的这一套技术栈感觉很奇怪回答的是是面向企业内部的知识库，因为这个项目是分了三期完成，首先是知识库搭建，后期还要集成 mcp 最后还要加智能体，所以用的自研方便集成。面试官好像也不太满意，说当时你们对接的人懂这个 rag 吗（对不起二哥哈哈哈哈哈我包的实习）

派聪明 2026年07月18日 20:05

这段对话还是挺有代表性的，我帮你拆一拆问题出在哪，以及怎么答会更好。 --- ## ❌ 你当时的回答有什么问题？你说“**用自研方便集成**”，这句话本身没错，但问题在于： 1. **太笼统**——面试官要听的是“为什么选这套具体的技术栈”，不是“自研”这个结论。每个中间件你都得说出选它的理由。 2. **“分三期”这个说法时机不对**——面试官问的是技术选型原因，你回答的是项目规划，答非所问，他自然觉得你不懂。 3. **“对接的人懂RAG吗”**——这句话是在质疑你的项目深度。说明他觉得你的回答不像自己做过，更像背的。 --- ## ✅ 应该怎么回答技术栈选型？面试官问“为什么用这一套技术栈”，本质是想听你的**技术判断力**，你得每样都说出个所以然。参考派聪明的真实选型逻辑： > **MinIO**：为什么不用OSS？因为我们要做**分片上传+断点续传**，MinIO原生支持`composeObject`合并分片，而且兼容S3协议，后期上云也很方便。 > > **Kafka**：文件解析是耗时操作（Tika解析+Embedding向量化），不能让用户干等，所以用Kafka做**异步解耦**。而且Kafka吞吐量高、自带分区和偏移量机制，方便做重试和死信队列，保证文件最终一定会被处理。 > > **Elasticsearch**：我们需要**混合检索**——既要关键词匹配（BM25），又要语义相似度检索（向量KNN）。ES原生支持`dense_vector`和`text`字段共存，一个查询就能搞定两种召回，不用额外维护一套向量数据库。 > > **DeepSeek**：性价比高，中文场景表现好，而且兼容OpenAI协议，方便切换。这样每个中间件都能说出它**解决了什么具体问题**，面试官一听就知道你是真的做过。 --- ## 💡 关于MCP和智能体你提到后面要集成MCP和智能体，面试官追问“你对接的人懂RAG吗”，其实是在**质疑你对MCP的理解深度**。如果下次被问到，可以这样接： > MCP（Model Context Protocol）本质上是让大模型能够**动态调用外部工具**。我们后续规划是把文件检索、权限校验、甚至数据库查询都封装成MCP工具，让智能体根据用户意图自动编排调用，不再依赖固定的RAG流水线。能说出这句话，面试官就不会觉得你只是“包了个实习”。

冰桃姚姚乌龙 2026年07月18日 19:53

引用原文：问派聪明 IK 分词器为什么用这个，为什么不用 xxx（没听过

派聪明 2026年07月18日 19:53

从你提供的面试场景来看，面试官追问“为什么用 IK 分词器，为什么不用 xxx”，其实是在考察你做技术选型时是否有清晰的依据，而不是拍脑袋决定的。结合派聪明（Paismart）项目中的实际设计，原因主要有以下几点： --- ### 1. 匹配中文分词场景派聪明处理的是**企业私有文档**（Word、PDF、txt 等），内容以**中文**为主。ElasticSearch 的默认分词器（如 Standard Analyzer）对中文是按单个字切分的，检索效果很差。而 **IK 分词器**专门为中文设计，支持**细粒度切分**（最大词）和**智能切分**（最细粒度），能正确识别“知识库”、“语义检索”等中文词汇，大幅提升关键词检索（BM25/match 查询）的召回精度。 ### 2. 实际项目中的验证派聪明的 ElasticSearch 索引（`knowledge_base`）中，`textContent` 字段的类型是 `text`，**底层配的就是 ik 中文分词器**。这个字段专门用于关键词检索和 BM25 排序——如果分词器选错了，关键词检索就基本废掉了。 ### 3. 生态成熟、使用广泛 IK 分词器在 Java/Spring Boot + ES 的技术栈中是非常成熟的选择，社区活跃、文档齐全、坑少。相比其他中文分词方案（如 HanLP、jieba 的 ES 插件、THULAC 等），IK 的集成最简单，直接装插件就能用，与 ES 的契合度最高。 --- ### 如果面试官继续追问“为什么不用 xxx” 你可以坦诚说明：**“当时做选型时，我们主要对比了 IK 和 HanLP 的 ES 插件。IK 的优点是开箱即用、性能稳定、词库可扩展；HanLP 功能更强大（支持词性标注、命名实体识别等），但集成复杂度更高。对于我们项目早期以文档检索为核心的需求，IK 已经足够满足要求，并且后续如果需要扩展自定义词典维护成本也很低。”** 这样既体现了你做技术选型时有横向对比，也展示了知道取舍的工程思维。