阿里飞猪一面（RAG），9道高频RAG高频面试题

老王透明的茶杯里，泡满了枸杞，我就瞅了一眼，少说也有 100 颗。

没等我回过来神，老王就直入主题：“你做 RAG 检索用的什么数据库？”

“MySQL。”

老王差点没把刚抿到嘴里的水喷到我帅气的脸上：“就 MySQL？向量检索你用 MySQL？”

“咋了王哥，MySQL 不配拥有向量吗？100 万条 chunk 我照样给它安排得明明白白。”

看老王气急败坏的样子，我笑了：“王哥，逗逗你啦，活跃活跃气氛嘛，这下我不紧张了。向量这块我用的是 ElasticSearch 了，既能做语义，又能做关键字存储，混合检索轻松搞定。😄”

老王真是个好人啊，愣是没生气，仍然和颜悦色。问出了下一题：“你这个 RAG 系统，检索精确率怎么评估的？具体怎么测试？”

（内心 OS：这下面试有了，天底下所有的面试官都能像老王一样就好了呀。）

PS：以下题目来自派聪明 RAG 项目的真实面试题目，如上图所示，阿里飞猪一面。

content

01、检索精确率怎么评估的？具体怎么测试？

我说：“王哥，我在派聪明 RAG 里专门做过一轮评估。”

“评估检索质量，业界常用的指标有三个：精确率（Precision）、召回率（Recall）和 MRR（Mean Reciprocal Rank）。”

精确率看的是检索出来的文档里有多少是真正相关的。比如检索返回了 10 个 chunk，其中 7 个和问题相关，精确率就是 70%。

召回率看的是所有相关文档里，有多少被检索出来了。比如知识库里一共有 15 个相关 chunk，检索返回了 7 个，召回率就是 46.7%。

MRR 看的是第一个正确结果的排名，排名越靠前分越高。用户最关心的其实是“第一条结果是不是我要的”，MRR 就是衡量这个的。

具体怎么测试呢？

“我的做法是构建一个评估数据集。”

“先标注 200 到 500 组 QA 对，每组包含一个问题和对应的标准答案 chunk。然后把这些问题批量放到检索模块，拿到返回结果，和标注结果做对比，算上面三个指标。”

“派聪明 RAG 上线前我们跑了一轮评估，精确率从最初的 68% 优化到了 89%，主要靠两个手段：一个是换了更好的 embedding 模型，另一个是加了重排模型对检索结果做二次排序。”

老王追问：“重排模型用的哪个？”

“用的 bge-reranker-v2-m3，这个模型对中文语义的理解比较好，而且推理速度能接受，P95 延迟在 50ms 以内。”

老王点点头：“评估体系搭得还可以。”

02、上传文件的数量上限多少？

老王接着问：“上传文件的数量上限是多少？文件大小多少？”

我说：“这个要分两层来说——业务层限制和系统层限制。”

“业务层面，我们限制单次上传不超过 20 个文件，单文件不超过 50MB。大部分用户上传的是 PDF 和 Word，50MB 基本覆盖了 99% 的文档。”

“系统层面，真正的瓶颈在文档解析和向量化。一个 50MB 的 PDF 可能有几百页，解析成文本、切分成 chunk、逐个向量化，整个流程下来可能要几分钟。如果用户一次上传 20 个这种大文件，后台任务队列会堆积。”

“所以我做了异步处理。用户上传后立刻返回成功，后台用 Kafka 慢慢消化。前端有个进度条，处理完了会通知用户。”

老王追问：“如果有人恶意上传大量垃圾文件呢？”

“做了限流。按用户维度限制每天上传总量不超过 500MB，按 IP 维度限制并发上传数，以及做了每天的 Embedding 额度限制。另外文...

9人已点赞

9 条评论

柒眠 2026年06月10日 16:32

引用原文：“ES 的存储优化有几个思路。第一，用稠密向量索引。ES 8.x 之后支持 HNSW 索引，向量检索不需要暴力遍历，建了索引之后检索速度能提升 10 倍以上。

@派聪明详细讲一下这个

派聪明 2026年06月10日 16:33

这段文本描述了 ElasticSearch（ES）在处理海量向量数据时的一项核心性能优化技术。详细拆解如下： **1. 为什么需要 HNSW索引？（暴力遍历的痛点）** 在 RAG系统中，文本会被切分成 chunk 并转化为高维向量（如2048 维）。当用户提问时，系统需要将问题转为向量，并在数据库中找出最相近的结果。在 ES8.x 引入原生 HNSW索引之前，如果没有专门的向量索引，数据库通常只能采用“暴力遍历”（即 Flat索引或暴力计算）。这意味着每次检索都要把数据库里成百上千万条向量和查询向量逐一计算相似度（复杂度为 O(N)）。当数据量达到百万级时，这种全库扫描不仅极其消耗 CPU，而且查询延迟极高，根本无法满足实时问答的需求。 **2. 什么是 HNSW索引？** HNSW（Hierarchical Navigable Small World，分层可导航小世界）是目前业界最主流的高效近似最近邻（ANN）检索算法之一。它的核心思想是**“以空间换时间”**： * **图结构**：它会把所有的向量节点连接起来，构建成一张多层级的“关系网”。 * **分层检索**：就像看地图一样，查找目标时先在最上层的“宏观图层”快速定位大致区域，然后逐层向下钻取，直到最底层的“微观图层”找到最精确的相邻节点。通过这种机制，检索复杂度大幅降至对数级别 **O(log N)**。正如文章中提到的，在处理5000 万条向量时，P99延迟能稳稳控制在100ms 以内。 **3.带来的具体提升** * **检索速度呈指数级飞跃**：文章提到“提升10倍以上”，甚至在海量数据下实际差距更大。HNSW 能让 ES 在亿万级向量中实现毫秒级检索，真正满足生产环境要求。 * **精度与资源的极佳平衡**：HNSW 是一种“近似”算法，它不保证100%找到绝对最完美的那条结果，但在实际应用中，它能以极小的精度损耗（通常几乎无感知）换取成百上千倍的速度提升。 * **参数可调优**：正如项目中实际调优的那样，

🦅 🦅 🦅 2026年05月08日 15:46

引用原文：说到底，切片的目的是把长文档拆成‘语义单元’，每个单元表达一个相对独立的主题。这个粒度和存储大小无关，和语义有关。按字节切跟按句号切一样不靠谱，只有按语义切才有意义。”

这张图用的是 LangChain 最常用的RecursiveCharacterTextSplitter，它的切分逻辑是纯字符驱动，完全不理解文档结构：它不知道什么是标题、什么是段落、什么是章节它只认你给的分隔符列表：[段落分隔符(\n\n), 换行符(\n), 句号(。), 逗号(,), 空格( )] 它会按分隔符优先级从高到低尝试拆分，直到每个 Chunk 的 token 数小于等于chunk_size=512 这会导致什么致命问题？标题和正文被强行拆分：比如 "3.2 Redis 缓存层" 这个标题被拆到上一个 Chunk 的末尾，正文被拆到下一个 Chunk，检索时只能找到正文，不知道它属于哪个章节段落中间被截断：一个完整的法律条款被拆成两半，单独看任何一半都读不懂不同章节的内容被拼到同一个 Chunk：上一章的最后一段和下一章的第一段被拼在一起，语义完全混乱这就是为什么我们后面需要做上下文提取来补全章节信息 —— 因为基础切分把结构全拆碎了，只能事后补救。二、工业级正确做法：先识别标题段落，再做 Chunk 切分这是现在所有生产级 RAG 系统的标准流程，和图里的基础切分正好反过来： plaintext 原始文档 → 文档结构解析（识别标题/段落/表格） → 按结构切分大块 → 大块内递归切分小块 → 绑定结构元数据具体怎么结合标题段落？ 1. 第一步：先做文档结构解析（最关键）用专门的文档解析工具（如Ｕｎｓｔｒｕｃｔｕｒｅｄ．ｉｏ、PyMuPDF、Markdown 解析器），把原始文档解析成结构化的树状结构： plaintext 文档 ├─ H1: 第3章系统设计 │ ├─ H2: 3.1 整体架构 │ │ └─ 段落1: 系统分为三层... │ │ └─ 段落2: 各层职责... │ ├─ H2: 3.2 存储分层 │ │ ├─ H3: 3.2.1 ElasticSearch检索层 │ │ │ └─ 段落1: ES负责存储Chunk和向量... │ │ ├─ H3: 3.2.2 Redis缓存层 │ │ │ └─ 段落1: Redis负责缓存上下文... 这一步会识别出所有标题的层级、每个段落的起止位置、表格和图片的位置。 2. 第二步：按标题层级切分大块绝对不允许跨标题切分：每个 H2 章节作为一个独立的大块如果 H2 章节太长（超过 2048 token），再按 H3 子章节切分保证同一个大块内的内容都属于同一个标题下，语义是连贯的 3. 第三步：在大块内部用递归切分拆成小块在每个标题块内部，再用图里的递归切分方法，拆成 512 token 的小块：这样就不会出现跨标题、跨章节的 Chunk 小块之间的重叠也只在同一个标题内部，不会把不同章节的内容重叠在一起 4. 第四步：给每个小块绑定完整的标题元数据每个 Chunk 生成时，自动带上它所属的所有上级标题： json { "chunk_id": "doc_123_chunk_5", "text": "Redis负责缓存上下文和会话状态", "metadata": { "h1": "第3章系统设计", "h2": "3.2 存储分层", "h3": "3.2.2 Redis缓存层", "page": 16 } } 三、结合标题段落切分的 3 个核心优势（面试必说）从根源上解决断章取义不会出现标题和正文分离、跨章节拼接的问题，每个 Chunk 本身就带有完整的上下文背景，模型不用再猜它属于哪里。大幅提升检索准确率检索时可以直接按标题过滤，比如 "只查 3.2 存储分层的内容"，也可以在检索结果中优先展示标题匹配的 Chunk。简化后续的上下文提取工作不用再事后去解析章节信息，所有结构信息在切分阶段就已经提取好了，上下文提取只需要建立 Chunk 之间的前后关联即可。

山北雨夜漫步 2026年05月02日 13:41

引用原文：，5000 万条 2048 维向量，P99 延迟在 100ms 以内

@派聪明怎么样测的

山北雨夜漫步 2026年05月02日 13:18

引用原文：业务层面，我们限制单次上传不超过 20 个文件

@派聪明这个前端能实现吗

山北雨夜漫步 2026年05月02日 13:15

引用原文：“重排模型用的哪个

@派聪明代码中没用重排模型呀

liweihao 2026年04月15日 12:09

引用原文：ES 的存储优化有几个思路。第一，用稠密向量索引。ES 8.x 之后支持 HNSW 索引，向量检索不需要暴力遍历，建了索引之后检索速度能提升 10 倍以上

@派聪明详细讲解一下这条