关注公众号
原创
派聪明 RAG 真实面经参考，已累计 27 家，700 道题目（不断更新中）

1.快手快 star

  • 描述一下上传文件，提问到显示答案整个数据流以及涉及到的模块/技术栈，
  • 怎么 chunk 的，为什么这么做？
  • 用的什么模型，有对比过吗
  • 检索结果不符合预期怎么办
  • ES 里怎么存的
  • 分片上传是怎么做的？断点续传？你这个场景有意义吗

2.小红书一面

AI & RAG 相关

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

Java 基础 & 并发

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

算法手撕

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

3.某对标亚信公司一面

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

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

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 代替，你会怎么设计呢？
  • 多人会话历史的窗口怎么设计的？
  • 考虑过怎么优化吗？（我提到可以压缩历史上下文然后拼接） 压缩如何实现呢？
  • 大文件上传优化是一开始就这样考虑的吗？还是遇到了什么问题才这样设计的？
  • 文件完整性怎么保证的？ 项目上线了吗？

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

  • 你提到了 mvcc，mysql 里面的 mvcc 实现细节讲一下？
  • 什么隔离级别会导致这样的问题？
  • 你是把数据库完整实现了吗？（简单实现）
  • B+树的索引是怎么实现的？

拷打八股 tcp 建立和连接 阻塞控制怎么控制的？

  • 选一个细致讲一下（我说了慢启动）
  • tcp 和 udp 的区别 https 的建立过程
  • 进程和线程的区别和联系
  • 进程的调度策略
  • 进程间的通信方式
  • socket 编程用在什么时候（有点记不得了 刚刚不该提 socket 的）
  • socket 最大优势是什么？
  • 他是如何防止网络阻塞的？
  • io 多路复用原理 select 和 epoll 区别 页面置换算法有哪些？
  • lru 原理？（这个时候快一小时了，我还以为他会让我手写 lru，累了）
  • 虚拟内存？
  • 磁盘调度算法有哪些？
  • c++里面栈快点还是堆快点（我就不该说本科学过 c++ 我记得我报的 java 岗） 分为哪些区？
  • python 用过吗？和 java 区别在哪里？
  • 常见的垃圾回收算法？ 说一下 cms 和 g1 区别 cms 缺点
  • 有接触过分布式系统吗？

二面面经

60min 拷打项目

  • 派聪明 prompt 是如何构造的?
  • 大文件上传优化是怎么做的？
  • 解析文档用的是什么？
  • chunk 是怎么切割的？
  • 是否可以优化？
  • 用的哪个大模型？

mydb

  • mvcc 基本原理（直接吟唱）
  • B+树和 B 树的区别

手撕 leetcode 621 （改了一下题目 第一问是原题，第二个求排列组合数没写出来，不过面试官说目前还没人写出来 我感觉再调半小时能写出来）

7.虾皮一面

一道生产者消费者的题 acm

派聪明 讲一下主要模块和功能

派聪明是一个企业级的 AI 知识库管理系统 。它的核心功能是对用户上传的私有文档（比如 Word、PDF、txt 等），进行语义解析和向量处理，然后存储到 ElasticSearch 中以供后续的关键词检索和语义检索。

它的主要模块和功能包括：

  1. 文档处理 ：用户上传文档后，系统会像图书管理员一样，自动将文档内容拆分成一个个小的知识片段。
  2. 知识向量化 ：接着，派聪明会利用豆包/阿里的向量模型为每个知识片段生成一个独特的“语义指纹”，并存入 Elasticsearch 中。
  3. 智能检索 ：当用户提出问题时，系统会先将问题转换成“语义指纹”，然后在 ES 中寻找与问题意图最匹配的几个知识片段。
  4. 生成答案 ：最后，派聪明会将用户的原始问题和找到的相关知识片段一起交给大型语言模型（比如 DeepSeek ），让这个“大脑”基于给定的上下文，生成一个精准、流畅、人性化的回答。

es 怎么存的

我们在 ElasticSearch 中新建了一个名 knowledge_base 的索引，它将为每一条数据存储两种关键信息。

其中，textContent 字段用于关键词搜索，vector 字段用于语义搜索。关键词...

9人已点赞

杠精派
派聪明
0/512

热门评论

安好 2025年11月11日 13:12
引用原文：ES 里怎么存的
@派聪明
点赞
回复1 取消回复
派聪明 2025年11月11日 13:12
根据参考资料，ElasticSearch（ES）中的存储结构如下： ### ES 存储方案（以 `knowledge_base` 索引为例）： 1. **索引名称**：`knowledge_base` 2. **核心字段**： - **`textContent`**： - 存储文档分块后的原始文本内容（如 PDF、Word 解析后的文本）。 - 使用 **IK 分词器** 进行关键词分词，支持关键词检索（如 `match` 查询）。 - **`vector`**： - 存储文本分块通过 **Embedding 模型**（如豆包/阿里向量模型）生成的**高维向量**（如 768 维）。 - 用于 **语义检索**（如 KNN 查找相似向量）。 ### 示例数据结构： ```json { "textContent": "企业级知识库管理系统支持多文档上传...", "vector": [0.12, -0.05, 0.**, ...], // 768维向量 "metadata": { // 其他元数据（如文件名、分块ID等） "fileId": "doc123", "chunkId": 1 } } ``` ### 存储逻辑： - **关键词检索**：对 `textContent` 字段使用 IK 分词器，倒排索引快速匹配关键词。 - **语义检索**：对 `vector` 字段计算向量相似度（如余弦相似度），召回相关文本分块。 - **混合检索**：结合关键词权重和向量相似度排序结果（参考资料4、5、17）。 > 注：该设计支持 RAG 流程，用户问题先转为向量，在 ES 中召回相似文本片段，再喂给 LLM 生成答案（参考资料7）。
点赞
回复 取消回复

8 条评论

要减肥的香菇 2025年12月09日 20:34
引用原文：怎么 chunk 的，为什么这么做？
@派聪明
点赞
回复1 取消回复
派聪明 2025年12月09日 20:35
在RAG（检索增强生成）系统中，文档分块（Chunking）是核心预处理步骤，具体实现及原因如下： --- ### **1. 分块实现方式** - **按语义边界切割**： 按段落、章节、标题等自然语义边界分割文档（如PDF的段落、Word的章节），确保每个Chunk包含完整语义单元。 - **固定长度+滑动窗口**： 对超长段落，按固定Token数（如256/512）切割，并设置滑动窗口（如重叠50%），避免上下文断裂。 - **特殊格式处理**： 保留表格、代码块等结构化内容，避免跨行/跨表切割（如用正则匹配``标签）。 --- ### **2. 分块原因** - **突破LLM上下文****： LLM上下文窗口有限（如4K/8K Token），分块将长文档拆解为可独立处理的单元（参考资料[2][4][7]）。 - **提升检索精度**： 细粒度Chunk更易匹配用户问题语义，避免冗余信息干扰（参考资料[4][16][25]）。 - **优化处理效率**： 并行向量化分块，加速索引构建；检索时只需加载相关Chunk，降低计算成本（参考资料[5][16]）。 - **支持混合检索**： 关键词检索（如Elasticsearch）需完整文本，向量检索需语义片段，分块兼顾两者需求（参考资料[4][7]）。 --- ### **3. 关键优化点** - **动态调整Chunk大小**： 技术文档用大Chunk（512+ Token），对话类用小Chunk（128 Token），平衡信息完整性与检索粒度（参考资料[25]）。 - **重叠窗口保留上下文**： 避免切割点丢失关键信息（如跨段落推理）（参考资料[16]）。 - **过滤低质量Chunk**： 剔除无意义片段（如页眉/页脚），提升索引质量（参考资料[7]）。 > **示例**：一篇PDF文档先按章节分割，每章按段落切分，超长段落用滑动窗口切为200 Token的块，重叠50%，确保语义连贯性（参考资料[7][25]）。
点赞
回复 取消回复
ooo 2025年12月09日 17:03
引用原文： 如果文件上传的内容有先后迭代顺序，比如婚姻法有前后两版，那么用户在提问时会返回什么？
@派聪明
点赞
回复1 取消回复
派聪明 2025年12月09日 17:04
根据参考资料中百度测开一面的面试问题，当用户上传的文档存在迭代顺序（如婚姻法新旧版本），系统会通过以下机制处理： ### 1. **版本标记与存储** - **元数据记录**：文档上传时，系统会附加版本信息（如`version: 2023`或`version: 2024`），并存入ElasticSearch（ES）的索引字段（如`metadata.version`）。 - **唯一标识**：文件名或ID包含版本号（如`婚姻法_********`），确保新旧版本在ES中作为独立条目存储。 ### 2. **检索逻辑** - **默认优先新版本**： 用户提问时，系统在ES中检索匹配内容，**按版本号降序排序**，优先返回最新版本的结果（如2024版婚姻法）。 - **兜底策略**： 若用户明确提及旧版本（如“旧版婚姻法”），系统通过关键词匹配（如`旧版`、`2023`）强制返回指定版本内容。 ### 3. **冲突处理** - **内容覆盖**：若同一文档多次上传，新版本会覆盖旧版本在ES中的记录（通过唯一ID或文件名+版本号组合）。 - **引用标注**：生成答案时，系统会明确标注引用来源（如“来源#1”），用户可点击跳转至具体版本原文。 ### 4. **实际效果** - **场景示例**： 用户问“**财产分割”，系统返回2024版婚姻法内容（最新版本）。 若用户问“2023版婚姻法对财产分割的规定”，则返回2023版内容。 - **避免混淆**：通过版本隔离和排序，防止新旧版本内容混合导致歧义。 ### 关键技术点 - **ES存储**：`knowledge_base`索引中`metadata`字段存储版本号，支持排序和过滤。 - **Prompt设计**：在构建提示词时，明确要求模型标注引用来源，增强答案可信度。 - **权限控制**：结合JWT鉴权，确保用户仅访问有权限的文档版本。 > 💡 **优化方向**：若需支持**版本查询，可增加版本**表（MySQL存储），或通过ES的`version`字段实现多版本快照检索。
点赞
回复 取消回复
ooo 2025年12月09日 16:35
引用原文：描述一下上传文件，提问到显示答案整个数据流以及涉及到的模块/技术栈，
@派聪明
点赞
回复1 取消回复
派聪明 2025年12月09日 16:36
## 派聪明系统数据流及技术栈 ### 整体数据流 1. **文件上传阶段**： - 用户上传文件到MinIO对象存储 - 大文件采用分片上传(5MB/片)，支持断点续传 - 上传完成后触发异步处理任务 2. **文档处理阶段**： - 文件解析器提取文本内容 - 文本切分为知识块(chunk) - 通过embedding模型向量化生成语义指纹 - 存储至ElasticSearch(含textContent和vector字段) 3. **检索阶段**： - 用户问题向量化 - ES混合检索(关键词+向量) - 结果重排序和评分归一化 - 提取Top-K相关知识片段 4. **答案生成阶段**： - 构建Prompt(含问题+上下文+引用规则) - 调用DeepSeek等大模型生成答案 - 返回结果并记录至Redis会话** ### 核心技术栈 - **存储**：MinIO(文件)、ElasticSearch(向量+文本)、MySQL(元数据)、Redis(缓存) - **消息队列**：Kafka(异步处理流水线) - **AI组件**：Embedding模型(豆包/阿里)、LLM(DeepSeek) - **文档处理**：PDF/Word解析器、IK分词器 - **框架**：Spring Boot、Spring MVC - **并发**：线程池、异步任务处理 关键设计亮点：分片上传优化大文件处理、双引擎检索提升召回率、Redis缓存会话**保证连续对话。
点赞
回复 取消回复
喵不可言· 2025年12月05日 20:46
引用原文：RAG 怎么解决 LLM 上下文窗口有限的问题？
@派聪明
点赞
回复1 取消回复
派聪明 2025年12月05日 20:47
RAG通过以下方式解决LLM上下文窗口有限的问题： 1. **检索关键信息而非全部内容**：RAG不将整个文档喂给LLM，而是通过向量检索找到与查询最相关的片段，只将这些相关内容提供给LLM，避免处理无关信息。 2. **分块处理**：将长文档切分成小块(chunk)，分别处理和向量化，使每个小块都在LLM的上下文窗口范围内。 3. **压缩技术**：如REFRAG方案，将无关上下文压缩成极短向量，只保留最相关的完整文本，减少90%的噪音内容，处理的token量减少2-4倍。 4. **交互式阅读**：如MEMWALKER方法，将长上下文处理成摘要节点树，模型可**树结构搜索相关信息，避免一次性处理全部内容。 5. **智能体策略**：RAG正演进为"智能体检索"，使用Agentic策略动态决定哪些信息对当前查询最重要。 6. **结合其他技术**：如RAG-MCP结合检索增强生成和模型上下文协议，更有效地利用外部工具和知识。 这些方法使LLM能在不扩展物理上下文窗口的情况下，处理远超其**的信息量，同时提高响应速度和准确性。
点赞
回复 取消回复
Sparks 2025年11月28日 15:57
引用原文：KNN 算法在高维向量匹配时，会遇到维度灾难的问题。请你解释并解决。
@派聪明
点赞
回复 取消回复
满意的身影 2025年11月19日 20:42
引用原文：为什么用 minio 做文件存储
@派聪明
点赞
回复1 取消回复
派聪明 2025年11月19日 20:43
根据参考资料中的项目描述（如“派聪明”），选择 **MinIO 做文件存储**的核心原因如下： --- ### 1. **支持大文件上传与分片处理** - **问题背景**：原始方案（如直接调用大模型 API）存在文件大小**（如参考资料18提到“DeepSeek 因文件过大拒绝上传”）。 - **MinIO 的作用**： - **分片上传**：将大文件拆分为小块（如 5MB/片）并行上传（参考资料5、18），突破单文件大小**。 - **断点续传**：若上传中断（如网络故障），可从断点恢复，避免重复上传（参考资料5、14）。 - **合并优化**：所有分片上传完成后，MinIO 可在服务端高效合并文件（参考资料7）。 --- ### 2. **企业级高可*性与扩展性** - **分布式架构**：MinIO 基于 Amazon S3 兼协议，支持分布式集群部署，提供数据冗余和容错能力（参考资料18）。 - **性能优势**：专为对象存储优化，适合存储非结构化数据（如文档、图片），读写性能高（参考资料18）。 --- ### 3. **简化存储管理与成本** - **统一存储方案**：替代本地文件系统或复杂自研方案，降低运维成本（参考资料5）。 - **生态兼容性**：与 Kafka、ElasticSearch 等组件无缝集成（如文件处理流水线），支持通过 HTTP/S3 协议访问（参考资料7、18）。 --- ### 4. **实际场景验证** - 在“派聪明”项目中，MinIO 解决了企业用户上传大文档（如 10GB+ PDF）的需求，保障了知识库构建流程的稳定性（参考资料5、18、25）。 --- ### 总结 MinIO 的核心价值在于 **突破文件大小****、**保障上传可*性** 和 **提供企业级扩展能力**，尤其适合需要处理海量非结构化数据（如文档、媒体）的 RAG 系统。其分片上传、断点续传和分布式特性，是技术选型的关键考量。
点赞
回复 取消回复
Goat 2025年11月17日 10:31
引用原文：大文件也可以断点续传为什么要分片？
@派聪明
点赞
回复1 取消回复
派聪明 2025年11月17日 10:33
分片上传的核心价值在于**提升大文件传输的可*性、并行性和可控性**，即使支持断点续传，分片仍有以下关键优势： ### 1. **降低单次失败成本** - **问题场景**：若不拆分，10GB文件上传至99%时中断，需全部重传。 - **分片解决**：每个分片（如5MB）可独立重传，仅重传失败分片而非整个文件（**二面追问点）。 ### 2. **实现并行加速** - **技术原理**：将文件拆分为多个分片，通过多线程/多连接并发上传（如1000线程并发）。 - **效果**：总耗时 ≈ 单个最大分片耗时，而非累加所有分片时间（阿里健康一面设计题）。 ### 3. **突破单次传输**** - **存储层****：MinIO等对象存储对单文件大小/上传时长有**（如**二面技术选型）。 - **网络层****：避免因网络超时、代理**导致大上传失败（合合信息一面追问）。 ### 4. **精细化断点续传** - **状态管理**：记录每个分片上传状态（如Redis存储分片进度），断点后精准恢复。 - **校验机制**：分片可独立校验MD5，确保数据完整性（合合信息一面文件完整性保证）。 ### 5. **资源灵活调度** - **动态分片**：根据网络状况调整分片大小（弱网时减小分片，强网时增大）。 - **流量控制**：避免单连接占用过多带宽（顺丰科技二面吞吐量优化）。 ### 用户体验视角 - **小文件无需分片**：如<10MB文件直接上传更高效（美团测开一面质疑点）。 - **大文件体验优化**：分片上传可显示实时进度（如“已上传80%”），而断点续传仅能提示“已恢复”（用户感知差异）。 > **总结**：分片是**为解决大文件传输的工程难题**，断点续传是其副产品。两者结合实现**高可*、高并发、可中断恢复**的企业级文件上传能力（快手快star、**二面核心考点）。
点赞
回复 取消回复
安好 2025年11月11日 13:12
引用原文：ES 里怎么存的
@派聪明
点赞
回复1 取消回复
派聪明 2025年11月11日 13:12
根据参考资料，ElasticSearch（ES）中的存储结构如下： ### ES 存储方案（以 `knowledge_base` 索引为例）： 1. **索引名称**：`knowledge_base` 2. **核心字段**： - **`textContent`**： - 存储文档分块后的原始文本内容（如 PDF、Word 解析后的文本）。 - 使用 **IK 分词器** 进行关键词分词，支持关键词检索（如 `match` 查询）。 - **`vector`**： - 存储文本分块通过 **Embedding 模型**（如豆包/阿里向量模型）生成的**高维向量**（如 768 维）。 - 用于 **语义检索**（如 KNN 查找相似向量）。 ### 示例数据结构： ```json { "textContent": "企业级知识库管理系统支持多文档上传...", "vector": [0.12, -0.05, 0.**, ...], // 768维向量 "metadata": { // 其他元数据（如文件名、分块ID等） "fileId": "doc123", "chunkId": 1 } } ``` ### 存储逻辑： - **关键词检索**：对 `textContent` 字段使用 IK 分词器，倒排索引快速匹配关键词。 - **语义检索**：对 `vector` 字段计算向量相似度（如余弦相似度），召回相关文本分块。 - **混合检索**：结合关键词权重和向量相似度排序结果（参考资料4、5、17）。 > 注：该设计支持 RAG 流程，用户问题先转为向量，在 ES 中召回相似文本片段，再喂给 LLM 生成答案（参考资料7）。
点赞
回复 取消回复

目录