派聪明RAG面试题解析：腾讯QQ一面真经

大家好，我是二哥。

相信大家也都发现了，今年和去年有很大的不同，不管是你面Java后端，还是其他岗位，AI 的浓度那是相当的高。

接下来就给大家分享一些真实的面经，冲大厂暑期实习的小伙伴可以拿来作为参考。

全文非常肝，系好安全带，我们粗粗粗发啦。

项目拷打

01、给你5分钟，介绍RAG项目整体流程，说出1-2个设计难点

派聪明的整体流程是这样的：用户上传文档后，系统会先对文档进行分片处理，把长文档切成若干个 chunk，每个 chunk 生成对应的向量（embedding），然后和原始文本一起存入 ElasticSearch。

用户提问时，系统对问题向量化，在 ES 中执行混合检索（向量检索 + BM25 关键词检索），把召回的相关 chunk 拼接进 prompt，交给大模型生成答案，最后通过 WebSocket 流式返回给前端。

两个比较值得说的难点：

第一个是分片策略。文档分片不是随便切的，切太短会丢失上下文，切太长会超出 embedding 模型的 token 限制，而且会稀释语义。

派聪明采用的是固定大小分片加上 overlap（重叠），保证相邻 chunk 之间有一定内容重叠，避免关键信息刚好落在切割边界上。

第二个是对话上下文管理。多轮对话时需要把历史记录带入 prompt，但上下文越来越长会超出大模型的 context window。如何在保留足够上下文的前提下控制 token 数，是 RAG 项目里很实际的工程问题。

02、除了分片上传，有做断点续传吗？、

断点续传的核心思路是：把大文件切成多个分片（chunk），每个分片单独上传，上传成功后记录该分片的状态，如果上传中断，下次只上传还没完成的分片，最后在服务端把所有分片合并。

派聪明用 Redis 的 Bitmap 来存储分片的上传状态。每个分片对应 Bitmap 中的一个 bit，上传成功就设置为 1，没上传就是 0。

前端发起上传前先查一下 Bitmap，知道哪些分片已经上传过，哪些还没有，只传缺失的部分。

为什么要这样设计？

因为在实际场景里，用户上传大文档（比如 PDF、Word）时，网络抖动、页面刷新都可能中断上传，如果每次都要重头来，用户体验很差，而且服务端资源也浪费了。

断点续传加上 Bitmap 记录进度，成本低、实现简单，效果很好。

值得一提的是，合并操作是在所有分片都上传完成后，由 MinIO 进行合并。

派聪明在合并完成后会...