关注公众号
原创
派聪明 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 字段用于语义搜索。关键词...

8人已点赞

杠精派
派聪明
0/512

热门评论

liligox@foxmail.com 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）。
点赞
回复 取消回复

4 条评论

sparks11 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、**二面核心考点）。
点赞
回复 取消回复
liligox@foxmail.com 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）。
点赞
回复 取消回复

目录