2026年最新AI agent面试（06）_RAG文档与检索

大家好，我是浩哥，这是我输出AI agent面试专题第六章，后面还有四期。建议加入粉丝，后面粉丝可见。

导语：本题型考察 RAG 的工程底座------文档切割(Chunking)、Embedding、向量 vs 关键词检索、多路召回、向量/图数据库、检索优化与复杂 RAG 范式。这是 RAG 系统质量的天花板所在，检索层优化的投入产出比高于生成层，是面试高频且区分度极高的板块。

总目录可见 2026年最新AI agent面试（0）概述篇

Q1. 文档如何切割（Chunking）？粒度怎么定？如何规避语义被切断？［来源：京东 + 字节一面 + 阿里二面］

核心答案 ：RAG 入库的第一步绝非整篇存库，而是必须先把文档切成 chunk（片段）再分别向量化存储。整篇直存有两个致命问题：其一，Embedding 模型有输入长度上限，长文档根本塞不进去；其二，即便支持超长输入，把整篇压缩成单一向量会将细节「平均掉」，检索时只能命中文档级而非语句级的模糊结果。每条 chunk 记录由三部分构成且缺一不可------向量（用于相似度检索的「索引卡」）、原文（LLM 真正阅读的「书页」）、metadata（来源/页码/章节等「书签」，用于过滤与溯源）。向量负责「找到」，原文负责「阅读」，二者角色互补。

切割粒度的本质是「检索精度」与「上下文完整」的取舍：chunk 太大则语义被稀释、易超长且检索噪声多；太小则语义残缺、LLM 看不懂、噪声也多。实践中 500～1000 token 是合理起点，但更关键的是按文档类型选择策略------普通文本用固定大小+重叠，有标题结构的按语义边界切，代码按函数切，表格整块保留，既要检索精度又要上下文完整则用父子切割（小块检索、大块返回）。
关键点 / 展开：
1. 固定大小切割 + 重叠（overlap）：最保底方案，按 token/字符切块，相邻 chunk 重叠 10--20%（如 chunk_size=800、overlap=150）缓解边界截断；但只能保证跨边界文字不丢，无法根治「完整语义被拆散」。
2. 语义边界切割：按段落/句子/标题层级等天然断点切，优先在段落或标题边界切；有标题结构的 Markdown/HTML 可自动带上「章节 > 小节」metadata，语义独立且便于过滤溯源。可用 spaCy/nltk 识别句子边界，以句为单位填充 chunk 不在句中截断。
3. 特殊内容专项处理：代码按函数/类切（用 AST 识别边界，函数是最小语义完整单元）；表格整块保留为 Markdown（按行截断会丢失列含义与行对比关系）。
4. 父子切割（Parent-Child / Small-to-Big）：同一内容存两份------小块（如 200 token）建索引用于精准检索，大块（如 1000 token）通过 parent_id 关联，命中后返回大块给 LLM，做到「检索用小的、阅读用大的」，兼顾精度与上下文完整。
5. 进阶「补上下文」方案：① 句子窗口检索（单句建向量精准检索，命中后返回前后 N 句上下文窗口）；② 命题化切割（LLM 把文档拆成自包含独立命题，语义密度最高但成本高）；③ Contextual Retrieval（Anthropic 2024，向量化前让 LLM 为 chunk 生成背景说明拼接后再向量化，从根上补回孤立 chunk 缺失的语境）。
常见追问：
1. overlap 设多大？为什么不是越大越好？（10--20%；过大重复内容干扰 LLM 阅读且增存储/成本，过小覆盖不了跨边界语义。）
2. 既要检索精度又要上下文完整，你用什么方案？（父子切割 / Small-to-Big，或摘要索引、多粒度分层索引。）
2026 延伸：Contextual Retrieval（Anthropic, 2024）已成为高质量 RAG 的标配思路；命题化切割与摘要索引在长文档问答中被广泛验证；多粒度分层索引（章节/段落/句子三级按需选粒度）是「检索粒度自适应」的工程化落地。

Q2. Embedding 究竟是什么？算法经历几代演进？如何选型与评估？［来源：百度二面 + 鹅厂二面］

核心答案 ：Embedding 是把文本「语义压缩」成固定长度浮点数向量的过程，其最关键的性质是「语义相近的文本，向量余弦相似度越高」------这正是 RAG 语义检索的底层基础，而非关键词匹配。例如「苹果手机怎么截图」与「iPhone 如何截屏」字面零重叠，但向量相似度可达 0.95；而「苹果手机」与「苹果汁」因语义相远被拉开距离。向量检索是从「意思」层面匹配，能跨越同义词、近义词与不同表达方式。

Embedding 算法历经三代演进：第一代静态词向量 （Word2Vec/GloVe/FastText）一词一向量、处理不了多义词；第二代上下文向量 （ELMo/BERT）解决多义但检索需把 query 与每个候选 doc 两两拼接跑模型，百万 doc 即百万次前向、速度不可用；第三代句子级对比学习（SBERT/SimCSE/BGE/E5）用 bi-encoder 让两段文本各自独立编码，可离线算好所有文档向量、查询时只算一次，是 RAG 场景的标配。
关键点 / 展开：
1. 选型三维度 ：① 中英文比例（中文首选 bge-large-zh，中英混合选 bge-m3，纯英文/求省事用 OpenAI text-embedding-3-small）；② 数据合规（不可出境必须本地部署开源模型，BGE 系列最优）；③ 向量维度（越高越准但存储/检索成本越大，百万级 1024 维是平衡点，text-embedding-3 支持降维至 256 维省存储）。
2. 评估不能盲信 MTEB 通用排行榜 ：通用数据集分布与你的业务（医疗/法律/客服）差异大，状元不一定擅长你的专业考试。正确做法是在自有业务数据 上做 Hit@K------准备「问题 + 正确 chunk」对，看正确 chunk 是否进前 K；Hit@5 < 0.7 即应考虑换模型或改 Chunking，0.8 以上较优。
3. 各代局限与代表：Word2Vec 多义失效，FastText 用子词 n-gram 缓解未登录词；BERT 语义强但检索须拼接跑百万次不可行；SBERT bi-encoder 牺牲部分精度换取数量级提速；SimCSE 用 dropout 对比学习解决向量「各向异性」（分布挤在窄锥区）。
4. 主流模型对比 ：text-embedding-3-small（1536 维可降维，英文好，API 有费用/出境风险）、bge-large-zh（1024 维，中文首选、开源）、bge-m3（1024 维，多语言）、E5（英文对比学习代表）。
常见追问：
1. 为什么不直接用 BERT 做检索？（query 须与每个候选 doc 拼接跑一次，百万 doc 即百万次前向，延迟小时级，用户等不起。）
2. Hit@K 是什么？多少算合格？（前 K 条结果含正确答案的比例；Hit@5 一般需 ≥0.7，0.8 以上较优。）
2026 延伸：Matryoshka Representation Learning（MRL，OpenAI text-embedding-3 支持降维）可在精度损失极小下大幅降存储；BGE 系列持续在中英文 MTEB 领先；bi-encoder（召回）与 Cross-Encoder reranker（精排）的双塔/单塔分工已成标准范式。

Q3. 向量数据库：原理、索引算法、核心能力与生产选型/性能实战［来源：快手一面 + 阿里一面］

核心答案 ：向量数据库是专门存储与检索高维向量的数据库，核心能力是近似最近邻搜索（ANN） ------在百万至亿级向量中毫秒级找出最相似的 K 条，这正是 RAG「检索」步骤的底层支撑。它与「MySQL 加个向量字段」有本质区别：关系库擅长精确匹配（WHERE id=123），向量库擅长语义相似（「找最相近的」）。普通 B-tree 只处理一维有序索引，对高维向量的距离搜索基本失效，暴力遍历 O(N)（百万条即百万次余弦计算）延迟不可接受，必须靠专用索引把查询压到约 O(log N)。

生产实战（以 Milvus 为例）：150 万条 chunk、1024 维、HNSW 索引，P50 延迟约 20ms、P99 约 60ms、100 QPS 稳定 。单条原始数据 150万×1024×4B≈6GB，进程实测需 10--12GB 内存；开启 SQ8 标量量化 （float32→int8）后内存降到约 3GB、精度损失 <1%，是最划算的优化；还可 mmap 把原始向量放磁盘、仅索引留内存进一步省内存。
关键点 / 展开：
1. 主流索引算法 ：① HNSW （多层图，从顶层稀疏图导航逐层收窄到底层，召回率 95%+，内存消耗大，Qdrant/Milvus/Chroma 默认；关键参数 M=16_{32、ef_construction=100}200、ef=50~200，ef 越大越准越慢）；② IVF（先聚类分桶，查询只搜最相关桶，内存小、适合超大规模，精度略低，需调 nlist/nprobe）。取舍：HNSW 精度高但内存随数据量线性增长，亿级可能扛不住；IVF 用聚类换内存。
2. 生产核心能力 ：① Metadata 过滤 （先过滤再 ANN，避免 Top-K 大量不满足条件白白浪费名额）；② 实时增量更新 （主流库支持在线写、不重建索引）；③ 与 BM25 关键词融合做混合检索。
3. 选型维度（规模/部署/混合检索） ：Chroma（本地嵌入，零配置，开发测试，勿上生产）、Qdrant（Rust，百万级，性能好 API 简）、Milvus（分布式，亿级，功能最全但运维复杂）、Pinecone（全托管 SaaS，按量付费但费用高且数据出境）、pgvector（PostgreSQL 插件，零运维、可 SQL JOIN）。
4. 踩坑与瓶颈 ：① 内存不足触发 swap，延迟 20ms→2s+，用 SQ8 量化 + mmap 解决；② 大批量写入触发后台 Segment 合并 （小增量段合并为封存段并建索引），P99 从 60ms 抖到 300ms+，解法为错峰（业务低峰期写）+ 分批（每批 500--1000 条、间隔几秒），把一次大冲击拆成多次小冲击。
常见追问：
1. 为什么不用 Elasticsearch 做向量检索？（ES 向量能力是后加补丁，非原生 ANN 设计，数据量大性能扛不住。）
2. HNSW 和 IVF 怎么选？（中小规模要精度选 HNSW；超大规模/内存受限选 IVF 系列。）
2026 延伸：主流库普遍支持「向量 + 标量(metadata) + 稀疏(BM25)」统一混合索引；Milvus/Qdrant 持续增强磁盘索引（DiskANN）以降本；量化（SQ8/PQ）已成为大规模部署默认手段。

Q4. 向量检索 vs 关键词检索（BM25）有什么区别？为什么需要混合检索？［来源：美团二面 + 字节一面］

核心答案 ：关键词检索（以 BM25 为代表）基于词频统计与倒排索引，擅长精确词命中 （产品型号、专有名词、缩写、代码），但遇到同义词/不同表达就束手无策；向量检索基于 Embedding 的语义空间距离，天然擅长跨同义词、近义词的语义匹配 ，却对精确词（如「M4 Pro」「GPT-4o」）不敏感------这是它「只看语义不看字面」的固有局限，换模型也无法根除。二者盲区恰好互补，谁也替代不了谁，因此生产 RAG 普遍采用混合检索（Hybrid Search）：两路并行召回，再用 **RRF（Reciprocal Rank Fusion）**按排名融合。
关键点 / 展开：
1. BM25 原理 ：倒排索引（记录「词 → 哪些文档」而非「文档有哪些词」）；打分看词频 TF （出现越多越相关）与稀缺度 IDF（罕见词权重高，给「的/是」等常见词降权），并加饱和度限制防权重无限叠加；中文需先 jieba 分词再建索引。
2. 向量检索原理：文本经 Embedding 转高维向量，ANN 在库里找最近 Top-K，百万级数十毫秒返回；语义强但精确词易漏。
3. 核心区别：匹配方式（词汇重叠 vs 语义距离）、索引（稀疏倒排 vs 稠密向量）、同义词（无法 vs 天然支持）、精确词（极好 vs 易漏）、可解释性（统计可解释 vs 黑盒）。
4. 混合检索实现 ：向量 + BM25 两路并行（总延迟取 max 而非相加，几乎零额外代价），各自召回后 RRF 融合------只用排名不看原始分数（余弦相似度 0~1 与 BM25 任意正数量纲不可比，归一化不稳定），公式 score += 1/(rank+k)，k 通常 60，两路都靠前则综合分高、排最前。
常见追问：
1. 为什么不把两路分数直接加权平均？（量纲不同，归一化效果不稳定；RRF 绕开分数只比排名，无需训练、计算量极小。）
2. 向量检索对精确词真的不行吗？换个好模型能解决吗？（这是「只看语义不看字面」的固有局限，换模型无法根除，必须用关键词路补。）
2026 延伸：Hybrid Search 已成为 RAG 默认范式；SPLADE 等「学习型稀疏向量」可让关键词路具备一定语义能力；ColBERT 的 Late Interaction 在检索端兼顾细粒度词级交互。

Q5. 什么是多路召回？具体怎么做？［来源：字节一面］

核心答案 ：多路召回（Multi-Recall）是同时用多种检索方式并行捞取候选、再合并排序交给 LLM，而不是只靠单路向量检索。其出发点是单路有天花板：向量检索对精确词（如「RTX 4090 显卡功耗」里的型号）召回差，BM25 对同义/不同表达无能为力，用户提问角度与文档表述角度不一致时两路都覆盖不到。把多路组合互相补盲区，总召回质量显著高于单路。常见组合为「向量检索 + BM25 + 多 Query 扩展」三路，RRF 融合后再接 Reranker 精排。
关键点 / 展开：
1. 三路组合 ：① 向量检索 （语义覆盖，同义词/近义命中）；② BM25 关键词检索 （精确词/专有名词/数字，中文先 jieba 分词）；③ 多 Query 扩展（LLM 把原问题改写 3--5 个角度版本分别检索再合并去重，召回覆盖率 +10~20%）。
2. 结果融合用 RRF ：各路分数不可比，只用排名融合（1/(rank+k), k=60）；RRF 是粗排，适合在 Rerank 之前合并候选集。
3. 精排接 Reranker ：RRF 之后接 Cross-Encoder 精排模型 （如 bge-reranker-v2-m3）做深度打分，把真正相关的内容筛到最前，这是融合后必要的一步。
4. 实战选型：电商/IT 文档（大量型号数字）向量+BM25 双路是标配；客服问答（提问风格多变）加多 Query 扩展；质量极致场景三路全上 + Rerank。
5. 实现细节 ：多 Query 扩展务必保留原始问题在检索列表（改写可能丢原始细节）；各路并行执行，延迟取最大。
常见追问：
1. RRF 之后为什么还要 Rerank？（RRF 只看排名属粗排，精度有限；Cross-Encoder 双塔交互细排才能把最相关顶到前。）
2. 多 Query 扩展的代价怎么控？（多了几次 LLM 调用，靠保留原 query、控制 3--5 个变体、命中即合并去重来平衡成本与收益。）
2026 延伸：Query 改写/扩展已成为检索前标准工序；Reranker 从 Cross-Encoder 向更轻量、支持长上下文与多语言多任务（如 bge-reranker-v2-m3）演进；RRF 之外「Learned Fusion」在部分场景被探索。

Q6. 在什么场景下用图数据库增强传统向量检索？［来源：阿里三面］

核心答案 ：当业务问题涉及「多个实体之间的关联推理」时，应考虑引入图数据库增强。向量检索本质是「单跳」------每次只找与问题直接相关的内容，没有「实体/关系」概念，无法沿关系链多跳推理。例如「A 公司的投资方和 B 公司有什么交集」「小米竞争对手的 CEO 是谁」「治 A 病的药和治 B 病的药有无相互作用」，答案不在某一文档里，而藏在多节点关系路径上，向量检索答不上来。图数据库以「节点(实体) + 边(关系)」存储世界，可做图遍历沿边一跳跳收集关联信息，正好补上这个短板。
关键点 / 展开：
1. 典型适用场景：企业关系分析（股权/任职网络）、医疗知识图谱（疾病-基因-药物多层关联）、代码知识库（函数调用/依赖链）、供应链溯源（原料→供应商→成品→分销层级关系）。
2. 组合用法 ：向量检索做「入口」定位实体（如从「小米」相关片段识别节点）→ 图数据库接力做「关系遍历」（沿竞争/CEO 等边收集沿途节点）→ 合并向量结果与图遍历结果一起喂 LLM。类比：向量是导航定位，图遍历是沿路线一站站走。
3. 图库的局限与互补 ：传统图查询（Cypher）擅长精确关系遍历，不擅长模糊语义匹配；「手机充电慢怎么办」这类无明确实体关系的问题图库帮不上，向量检索更合适。两者互补非替代（现代图库如 Neo4j 加向量索引本质是把向量检索嫁接进图，非图遍历本身）。
4. 何时不值得上：实体抽取/关系抽取靠 LLM，成本高易错，图结构维护比向量库复杂得多；多数「查某概念解释/某功能怎么用」的描述性问题，向量检索 + Rerank 已够，强行上图是过度设计。
5. 判断原则：问题是否同时出现「多个具体实体名」且问「它们之间有什么关系/通过关系能找到什么」，是则考虑图增强。
常见追问：
1. 多检索几次能不能替代图遍历？（不能。多跳前提是知道下一步搜什么，向量检索没有「关系」概念，不知道该沿哪条边走。）
2. 图里的实体和关系怎么来？（用 LLM 做实体抽取与关系抽取，把非结构化文档转成图，需权衡成本与质量。）
2026 延伸：GraphRAG（Microsoft, 2024）将知识图谱的社区发现 + 层次摘要用于增强全局/总结性问答，是图增强 RAG 的代表性范式；LightRAG 等轻量化方案降低图谱构建成本。

Q7. RAG 检索优化策略有哪些？------四层系统框架［来源：阿里二面］

核心答案 ：检索是 RAG 的命脉------LLM 只能基于召回的 context 作答，检索召回的内容就是系统天花板，检索层优化的投入产出比高于生成层（生成层优化是锦上添花，检索层是从根本上抬升能力上限）。系统性回答应落在四层框架 ：索引层 决定知识「怎么存」、查询层 决定问题「怎么转」、召回层 决定「从哪些路径找」、重排序层决定「谁最相关进 prompt」。单独优化一层往往有限，线上通常组合：先靠索引优化 + 多路召回保覆盖率，再用 Rerank 保精度，若用户提问质量差再叠加查询优化。
关键点 / 展开：
1. 索引层（Small-to-Big 矛盾：小 chunk 检索准但内容碎，大 chunk 完整但语义稀释）：① 父子切割（子 chunk 150 token 建索引、父 chunk 500 token 通过 parent_id 返回）；② 摘要索引（LLM 生成摘要建向量，命中后返回原文）；③ 多粒度分层索引（章节/段落/句子三级，按问题类型选粒度）。
2. 查询层（弥合提问与知识库表述鸿沟，尤其口语 vs 书面语短文本距离被放大） ：① Query 改写 （口语/歧义转正式精准，结合对话历史消歧）；② 多 Query 扩展 （3~5 角度，保留原始问题防细节丢失）；③ HyDE （先生成假设答案再用其向量检索，文体更接近文档）；④ Step-back Prompting（具体问题抽象成通用背景问题先检索，再结合背景答具体）。
3. 召回层（突破单条路径盲区）：向量 + BM25 混合、多 Query 扩展、必要时图检索，多路并行互补。
4. 重排序层 ：对粗召候选用 Cross-Encoder Reranker （如 bge-reranker-v2-m3）精排，保证进 prompt 的都是真正相关的内容，过滤噪声。
常见追问：
1. 索引层为什么不能直接把 chunk 切小？（切小检索准但 LLM 拿碎片答不好，需 Small-to-Big 兼顾检索精度与阅读完整。）
2. HyDE 有什么风险？（若 LLM 生成的假设答案方向错，会把检索带偏，适合领域明确的场景。）
2026 延伸：Reranker 从 Cross-Encoder 向支持更长上下文、多语言多任务演进；Late Interaction（ColBERT）在召回端部分恢复词级交互；Agentic 检索可动态决定四层策略的启用（见 Q8）。

Q8. 复杂的 RAG 范式有哪些？经历了怎样的演进？［来源：百度一面］

核心答案 ：RAG 范式即「用户提问到生成答案」整条链路的组织方式与决策逻辑，本质是在「检索与生成之间如何协调、决策、处理异常」。其演进经历了三代：Naive RAG （检索+生成，无优化，两天能上线 Demo）→ Advanced RAG （检索前后加 Query 改写、Rerank、混合检索等工序，工程改动小效果明显，当前多数生产系统形态）→ Modular RAG（把各环节拆成可替换模块按需组合，如 LlamaIndex Workflow、LangGraph）。在此基础上，针对朴素 RAG 的痛点演化出多个高级范式。
关键点 / 展开：
1. Naive RAG 三大痛点催生高级范式：① 检索质量参差、低质上下文致幻觉；② 所有问题走同一死板流程（该省不省、该深挖不深挖）；③ 知识库覆盖盲区时编造答案。
2. Self-RAG ：让 LLM 自主决策「要不要检索 / 召回相关否 / 有无幻觉 / 答案质量」，通过 4 类 reflection token （Retrieval/Relevance/Support/Utility）控制；需在专门数据集上微调基础模型（开源基于 Llama2-7B/13B），通用 GPT 不能直接套用；好处是省检索开销、识别不相关避免幻觉。
3. CRAG（Corrective RAG）：检索后加质量评估，质量高正常走；质量低自动降级到 Web 搜索；居中则知识库 + 网络搜索并用，专门解决知识库盲区。
4. GraphRAG（Microsoft） ：用知识图谱的社区发现 + 层次摘要增强全局/总结性理解，适合跨文档宏观问答。
5. Agentic RAG：把 RAG 做成 Agent，支持多轮动态检索、根据中间结果决定下一步，解决「复杂问题需多跳动态检索」的痛点；可在通用 LLM 上直接跑。
常见追问：
1. Self-RAG 和 CRAG/Agentic RAG 最大区别？（Self-RAG 需微调带 reflection token 的模型；后两者可在通用 LLM 上直接跑。）
2. 什么场景用 Agentic RAG 而非固定流程？（问题需多轮、跨源、动态决策检索时，如复杂调研/多跳推理。）
2026 延伸：GraphRAG / LightRAG 把图谱引入全局问答；Agentic RAG 与 Modular RAG 结合成为可编排检索智能体；Self-RAG 的 reflection 思想被融入更多可控生成框架；Reranker 与检索器的联合训练是活跃方向。

📌 本题型速记 Checklist

文档必须切块（chunk）再向量化，不能整篇塞；每条记录 = 向量(索引卡) + 原文(书页) + metadata(书签)，向量负责「找到」、原文负责「阅读」。
粒度 500--1000 token 起步，按文档类型选策略；overlap 10--20% 仅兜底，根治语义截断靠语义边界切割 / 父子切割。
六大切割方案：固定+重叠、语义边界、代码按函数/表格整块、父子切割(Small-to-Big)、句子窗口、命题化、Contextual Retrieval。
Embedding = 语义压缩，相似度靠余弦；算法三代：静态词向量 → 上下文(BERT) → 句子级对比学习(SBERT/SimCSE/BGE)。
Embedding 选型看中英文、合规、维度；评估用自有数据 Hit@K（Hit@5<0.7 换模型），别盲信 MTEB 通用榜。
向量数据库核心是 ANN；索引 HNSW(精度高/内存大) vs IVF(聚类/省内存)；选型 Chroma(开发)/Qdrant(百万)/Milvus(亿级)/Pinecone(托管)/pgvector。
生产指标要能报：数据量、维度、P50/P99 延迟、QPS；瓶颈常是内存(swap → SQ8 量化/mmap)与写入 Segment 合并(错峰+分批)。
向量检索 vs BM25：语义强但精确词弱，关键词反之；二者互补，混合检索(RRF 融合)是默认做法。
多路召回 = 向量 + BM25 + 多 Query 扩展，RRF 融合后接 Reranker(bge-reranker-v2-m3)精排。
图数据库增强用于「多实体关联推理/多跳」场景；向量单跳、图多跳，组合为「向量入口定位 → 图遍历 → 合并」。
检索优化四层框架：索引层(Small-to-Big) → 查询层(改写/多Query/HyDE/Step-back) → 召回层(混合) → 重排序层(Reranker)。
RAG 范式演进：Naive → Advanced → Modular；高级范式 Self-RAG(微调自决)/CRAG(降级纠错)/GraphRAG(图谱)/Agentic RAG(多轮动态)。