派聪明 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 状态判断哪些分片已经上传，不用从头开始，用户体验会比较好。