派聪明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 进行合并。

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

18人已点赞

热门评论

Coos 2026年06月27日 15:39

引用原文：派聪明采用的是 512 token 左右的分片大小，是一个经过实测的合理值。

@派聪明 token是采用什么划分的，还有具体是怎么实测的

回复1 取消回复

派聪明 2026年06月27日 15:39

基于你提供的参考资料，我来为你拆解这两个问题。 --- ### 1️⃣ Token 是采用什么划分的？参考资料中虽然没有直说“派聪明”具体用的是哪个 Tokenizer，但结合上下文可以推断： RAG 项目中分片时所说的 **token 数量**，通常是按照 **大模型或 Embedding 模型所使用的 Tokenizer** 来计算的。 - 中文场景下，常见的 Tokenizer 有 **BERT 的 WordPiece**、**GPT 系列的 BPE（Byte Pair Encoding）**，或者是 **开源的 SentencePiece**。 - 参考资料中提到项目使用了 **IK 分词器**，但 IK 主要用于 **BM25 关键词检索**阶段的中文分词，**不是**用于计算 token 数量的划分方式。 - 所以，**分片时 512 token 的“token”**，大概率是项目使用的 Embedding 模型（如 `text2vec` 或 `bge` 系列）自带的 Tokenizer 来划分的，每个 token 对应一个子词（subword），而不是按纯汉字或纯 IK 词来切。 👉 **一句话总结**：分片时是按 **Embedding 模型自带的 Tokenizer（如 BPE/WordPiece）** 来划分 token 的，IK 分词器只用于检索阶段，不用于分片的 token 计数。 --- ### 2️⃣ 具体是怎么实测的？参考资料中没有展开实测的详细过程，但从工程实践角度，“经过实测的合理值”通常是按以下步骤验证的： **Step 1——设定候选值区间** 选取一组常见分片大小作为实验变量，例如：128、256、512、768、1024 token。 **Step 2——构建测试数据集** 准备一批覆盖不同类型文档的测试集（如长文档、技术手册、问答对话记录），并准备好对应的标准答案。 **Step 3——跑多组对比实验** 对每个候选分片大小，跑一遍完整的 RAG 流程（分片 → 向量化 → 检索 → 生成答案），统计关键指标： - **检索召回率**（Recall@K）：正确答案是否出现在召回的 chunk 中 - **回答准确率**：大模型基于召回内容是否能给出正确回答 - **响应延迟**：分片越大，检索和生成耗时越长 **Step 4——分析权衡** - 128～256 token：召回精度高，但上下文碎片化严重，回答连贯性差 - 512 token：召回率和回答质量达到较优平衡点 - 768～1024 token：语义稀释，精确匹配下降，且容易超出模型的输入限制最终选择 **512 token** 作为最佳折中——**既保留了足够上下文，又不超出 embedding 限制，检索精度和生成效果都较稳定**。 --- 所以，“512 token 是实测合理值”背后是一套完整的实验对比流程，而非拍脑袋决定的。

回复取消回复

8 条评论

冰桃姚姚乌龙 2026年07月08日 20:47

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

@派聪明如何在保留足够上下文的前提下控制token数

派聪明 2026年07月08日 20:47

在RAG项目的多轮对话中，控制token数同时保留足够上下文，有以下几种常用方案： **1. 滑动窗口（取最近N轮）** 最简单的方案，只保留最近几轮对话（比如最近10轮）。实现成本低，但缺点是如果用户很早之前提过关键信息，会被丢弃，模型无法感知。 **2. 摘要压缩（Summarization）** 当上下文超过阈值时，不是简单丢掉旧消息，而是用大模型把前面的对话总结成一段摘要。将摘要 + 最近几轮完整对话一起作为上下文。这样既保留了历史精华，又控制了token数。缺点是增加了一次大模型调用，有额外延迟和成本。 **3. 重要性打分（Importance Scoring）** 对历史消息按重要性排序，优先保留重要消息。比如用户说"记住我叫王二"这类信息，比一般闲聊更重要，应该优先保留。 **4. 外部记忆（External Memory）** 把重要信息（如用户偏好、关键事实）单独存到"记忆库"中，每次对话时先从记忆库里检索相关信息拼入prompt。这类似于RAG本身的思路，像MemGPT、LangChain的Memory模块都有类似实现。 **5. 动态token预算** 根据问题复杂度动态分配上下文长度。简单问题少给上下文、快速响应；复杂问题多给上下文，允许更长的推理链。在实际项目中，可以根据业务场景组合使用这些方案，平衡上下文保留和token成本。

祥 2026年04月23日 17:05

引用原文：ElasticSearch 8.x 以后原生支持 dense_vector 类型和 knn 查询，可以直接在 ES 里做向量检索，不需要额外引入 Milvus 这样的向量数据库。

@杠精派在项目中，，你的ES是怎么进行存储的，，，数据结构是怎么样的？，，采用了不同的索引吗？

祥 2026年04月23日 17:03

引用原文：ES 的 mapping 里定义 dense_vector 字段，索引文档时把 embedding 结果写入该字段，查询时用 knn 查询指定 query_vector 和 k 值即可。

@派聪明在项目中，，你的ES是怎么进行存储的，，，数据结构是怎么样的？，，采用了不同的索引吗？

liweihao 2026年04月15日 12:03

引用原文：08、用Redis存储对话上下文，具体用的哪种类型？

@派聪明用redis存储上下文，会不会出现大key问题

liweihao 2026年04月15日 12:01

引用原文：用Redis存储对话上下文，具体用的哪种类型？

用redis存储上下文，会不会出现大key问题