大家好我是浩哥这是我输出AI agent面试专题第六章后面还有四期。建议加入粉丝后面粉丝可见。导语本题型考察 RAG 的工程底座——文档切割(Chunking)、Embedding、向量 vs 关键词检索、多路召回、向量/图数据库、检索优化与复杂 RAG 范式。这是 RAG 系统质量的天花板所在检索层优化的投入产出比高于生成层是面试高频且区分度极高的板块。2026年最新AI agent面试01_Agent基础与推理范式2026年最新AI agent面试02_MultiAgent与记忆2026年最新AI agent面试03_工具协议MCP_A2A_FC2026年最新AI agent面试04__工具工程网关外部2026年最新AI agent面试05_RAG基础应用2026年最新AI agent面试06_RAG文档与检索2026年最新AI agent面试07_大模型架构基础2026年最新AI agent面试08_大模型训练评测2026年最新AI agent面试09_AI编程ClaudeCode2026年最新AI agent面试10_通信与行业动态总目录可见 2026年最新AI agent面试0概述篇Q1. 文档如何切割Chunking粒度怎么定如何规避语义被切断来源京东 字节一面 阿里二面核心答案RAG 入库的第一步绝非整篇存库而是必须先把文档切成 chunk片段再分别向量化存储。整篇直存有两个致命问题其一Embedding 模型有输入长度上限长文档根本塞不进去其二即便支持超长输入把整篇压缩成单一向量会将细节「平均掉」检索时只能命中文档级而非语句级的模糊结果。每条 chunk 记录由三部分构成且缺一不可——向量用于相似度检索的「索引卡」、原文LLM 真正阅读的「书页」、metadata来源/页码/章节等「书签」用于过滤与溯源。向量负责「找到」原文负责「阅读」二者角色互补。切割粒度的本质是「检索精度」与「上下文完整」的取舍chunk 太大则语义被稀释、易超长且检索噪声多太小则语义残缺、LLM 看不懂、噪声也多。实践中5001000 token 是合理起点但更关键的是按文档类型选择策略——普通文本用固定大小重叠有标题结构的按语义边界切代码按函数切表格整块保留既要检索精度又要上下文完整则用父子切割小块检索、大块返回。关键点 / 展开固定大小切割 重叠overlap最保底方案按 token/字符切块相邻 chunk 重叠 10–20%如 chunk_size800、overlap150缓解边界截断但只能保证跨边界文字不丢无法根治「完整语义被拆散」。语义边界切割按段落/句子/标题层级等天然断点切优先在段落或标题边界切有标题结构的 Markdown/HTML 可自动带上「章节 小节」metadata语义独立且便于过滤溯源。可用 spaCy/nltk 识别句子边界以句为单位填充 chunk 不在句中截断。特殊内容专项处理代码按函数/类切用 AST 识别边界函数是最小语义完整单元表格整块保留为 Markdown按行截断会丢失列含义与行对比关系。父子切割Parent-Child / Small-to-Big同一内容存两份——小块如 200 token建索引用于精准检索大块如 1000 token通过 parent_id 关联命中后返回大块给 LLM做到「检索用小的、阅读用大的」兼顾精度与上下文完整。进阶「补上下文」方案① 句子窗口检索单句建向量精准检索命中后返回前后 N 句上下文窗口② 命题化切割LLM 把文档拆成自包含独立命题语义密度最高但成本高③ Contextual RetrievalAnthropic 2024向量化前让 LLM 为 chunk 生成背景说明拼接后再向量化从根上补回孤立 chunk 缺失的语境。常见追问overlap 设多大为什么不是越大越好10–20%过大重复内容干扰 LLM 阅读且增存储/成本过小覆盖不了跨边界语义。既要检索精度又要上下文完整你用什么方案父子切割 / Small-to-Big或摘要索引、多粒度分层索引。2026 延伸Contextual RetrievalAnthropic, 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 场景的标配。关键点 / 展开选型三维度① 中英文比例中文首选bge-large-zh中英混合选bge-m3纯英文/求省事用 OpenAItext-embedding-3-small② 数据合规不可出境必须本地部署开源模型BGE 系列最优③ 向量维度越高越准但存储/检索成本越大百万级 1024 维是平衡点text-embedding-3支持降维至 256 维省存储。评估不能盲信 MTEB 通用排行榜通用数据集分布与你的业务医疗/法律/客服差异大状元不一定擅长你的专业考试。正确做法是在自有业务数据上做HitK——准备「问题 正确 chunk」对看正确 chunk 是否进前 KHit5 0.7 即应考虑换模型或改 Chunking0.8 以上较优。各代局限与代表Word2Vec 多义失效FastText 用子词 n-gram 缓解未登录词BERT 语义强但检索须拼接跑百万次不可行SBERT bi-encoder 牺牲部分精度换取数量级提速SimCSE 用 dropout 对比学习解决向量「各向异性」分布挤在窄锥区。主流模型对比text-embedding-3-small1536 维可降维英文好API 有费用/出境风险、bge-large-zh1024 维中文首选、开源、bge-m31024 维多语言、E5英文对比学习代表。常见追问为什么不直接用 BERT 做检索query 须与每个候选 doc 拼接跑一次百万 doc 即百万次前向延迟小时级用户等不起。HitK 是什么多少算合格前 K 条结果含正确答案的比例Hit5 一般需 ≥0.70.8 以上较优。2026 延伸Matryoshka Representation LearningMRLOpenAI text-embedding-3 支持降维可在精度损失极小下大幅降存储BGE 系列持续在中英文 MTEB 领先bi-encoder召回与 Cross-Encoder reranker精排的双塔/单塔分工已成标准范式。Q3. 向量数据库原理、索引算法、核心能力与生产选型/性能实战来源快手一面 阿里一面核心答案向量数据库是专门存储与检索高维向量的数据库核心能力是近似最近邻搜索ANN——在百万至亿级向量中毫秒级找出最相似的 K 条这正是 RAG「检索」步骤的底层支撑。它与「MySQL 加个向量字段」有本质区别关系库擅长精确匹配WHERE id123向量库擅长语义相似「找最相近的」。普通 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把原始向量放磁盘、仅索引留内存进一步省内存。关键点 / 展开主流索引算法①HNSW多层图从顶层稀疏图导航逐层收窄到底层召回率 95%内存消耗大Qdrant/Milvus/Chroma 默认关键参数 M1632、ef_construction100200、ef50~200ef 越大越准越慢②IVF先聚类分桶查询只搜最相关桶内存小、适合超大规模精度略低需调 nlist/nprobe。取舍HNSW 精度高但内存随数据量线性增长亿级可能扛不住IVF 用聚类换内存。生产核心能力①Metadata 过滤先过滤再 ANN避免 Top-K 大量不满足条件白白浪费名额②实时增量更新主流库支持在线写、不重建索引③与 BM25 关键词融合做混合检索。选型维度规模/部署/混合检索Chroma本地嵌入零配置开发测试勿上生产、QdrantRust百万级性能好 API 简、Milvus分布式亿级功能最全但运维复杂、Pinecone全托管 SaaS按量付费但费用高且数据出境、pgvectorPostgreSQL 插件零运维、可 SQL JOIN。踩坑与瓶颈① 内存不足触发 swap延迟 20ms→2s用 SQ8 量化 mmap 解决② 大批量写入触发后台Segment 合并小增量段合并为封存段并建索引P99 从 60ms 抖到 300ms解法为错峰业务低峰期写分批每批 500–1000 条、间隔几秒把一次大冲击拆成多次小冲击。常见追问为什么不用 Elasticsearch 做向量检索ES 向量能力是后加补丁非原生 ANN 设计数据量大性能扛不住。HNSW 和 IVF 怎么选中小规模要精度选 HNSW超大规模/内存受限选 IVF 系列。2026 延伸主流库普遍支持「向量 标量(metadata) 稀疏(BM25)」统一混合索引Milvus/Qdrant 持续增强磁盘索引DiskANN以降本量化SQ8/PQ已成为大规模部署默认手段。Q4. 向量检索 vs 关键词检索BM25有什么区别为什么需要混合检索来源美团二面 字节一面核心答案关键词检索以 BM25 为代表基于词频统计与倒排索引擅长精确词命中产品型号、专有名词、缩写、代码但遇到同义词/不同表达就束手无策向量检索基于 Embedding 的语义空间距离天然擅长跨同义词、近义词的语义匹配却对精确词如「M4 Pro」「GPT-4o」不敏感——这是它「只看语义不看字面」的固有局限换模型也无法根除。二者盲区恰好互补谁也替代不了谁因此生产 RAG 普遍采用混合检索Hybrid Search两路并行召回再用 **RRFReciprocal Rank Fusion**按排名融合。关键点 / 展开BM25 原理倒排索引记录「词 → 哪些文档」而非「文档有哪些词」打分看词频 TF出现越多越相关与稀缺度 IDF罕见词权重高给「的/是」等常见词降权并加饱和度限制防权重无限叠加中文需先 jieba 分词再建索引。向量检索原理文本经 Embedding 转高维向量ANN 在库里找最近 Top-K百万级数十毫秒返回语义强但精确词易漏。核心区别匹配方式词汇重叠 vs 语义距离、索引稀疏倒排 vs 稠密向量、同义词无法 vs 天然支持、精确词极好 vs 易漏、可解释性统计可解释 vs 黑盒。混合检索实现向量 BM25 两路并行总延迟取 max 而非相加几乎零额外代价各自召回后 RRF 融合——只用排名不看原始分数余弦相似度 0~1 与 BM25 任意正数量纲不可比归一化不稳定公式score 1/(rankk)k 通常 60两路都靠前则综合分高、排最前。常见追问为什么不把两路分数直接加权平均量纲不同归一化效果不稳定RRF 绕开分数只比排名无需训练、计算量极小。向量检索对精确词真的不行吗换个好模型能解决吗这是「只看语义不看字面」的固有局限换模型无法根除必须用关键词路补。2026 延伸Hybrid Search 已成为 RAG 默认范式SPLADE 等「学习型稀疏向量」可让关键词路具备一定语义能力ColBERT 的 Late Interaction 在检索端兼顾细粒度词级交互。Q5. 什么是多路召回具体怎么做来源字节一面核心答案多路召回Multi-Recall是同时用多种检索方式并行捞取候选、再合并排序交给 LLM而不是只靠单路向量检索。其出发点是单路有天花板向量检索对精确词如「RTX 4090 显卡功耗」里的型号召回差BM25 对同义/不同表达无能为力用户提问角度与文档表述角度不一致时两路都覆盖不到。把多路组合互相补盲区总召回质量显著高于单路。常见组合为「向量检索 BM25 多 Query 扩展」三路RRF 融合后再接 Reranker 精排。关键点 / 展开三路组合①向量检索语义覆盖同义词/近义命中②BM25 关键词检索精确词/专有名词/数字中文先 jieba 分词③多 Query 扩展LLM 把原问题改写 3–5 个角度版本分别检索再合并去重召回覆盖率 10~20%。结果融合用 RRF各路分数不可比只用排名融合1/(rankk), k60RRF 是粗排适合在 Rerank 之前合并候选集。精排接 RerankerRRF 之后接Cross-Encoder 精排模型如bge-reranker-v2-m3做深度打分把真正相关的内容筛到最前这是融合后必要的一步。实战选型电商/IT 文档大量型号数字向量BM25 双路是标配客服问答提问风格多变加多 Query 扩展质量极致场景三路全上 Rerank。实现细节多 Query 扩展务必保留原始问题在检索列表改写可能丢原始细节各路并行执行延迟取最大。常见追问RRF 之后为什么还要 RerankRRF 只看排名属粗排精度有限Cross-Encoder 双塔交互细排才能把最相关顶到前。多 Query 扩展的代价怎么控多了几次 LLM 调用靠保留原 query、控制 3–5 个变体、命中即合并去重来平衡成本与收益。2026 延伸Query 改写/扩展已成为检索前标准工序Reranker 从 Cross-Encoder 向更轻量、支持长上下文与多语言多任务如 bge-reranker-v2-m3演进RRF 之外「Learned Fusion」在部分场景被探索。Q6. 在什么场景下用图数据库增强传统向量检索来源阿里三面核心答案当业务问题涉及「多个实体之间的关联推理」时应考虑引入图数据库增强。向量检索本质是「单跳」——每次只找与问题直接相关的内容没有「实体/关系」概念无法沿关系链多跳推理。例如「A 公司的投资方和 B 公司有什么交集」「小米竞争对手的 CEO 是谁」「治 A 病的药和治 B 病的药有无相互作用」答案不在某一文档里而藏在多节点关系路径上向量检索答不上来。图数据库以「节点(实体) 边(关系)」存储世界可做图遍历沿边一跳跳收集关联信息正好补上这个短板。关键点 / 展开典型适用场景企业关系分析股权/任职网络、医疗知识图谱疾病-基因-药物多层关联、代码知识库函数调用/依赖链、供应链溯源原料→供应商→成品→分销层级关系。组合用法向量检索做「入口」定位实体如从「小米」相关片段识别节点→ 图数据库接力做「关系遍历」沿竞争/CEO 等边收集沿途节点→ 合并向量结果与图遍历结果一起喂 LLM。类比向量是导航定位图遍历是沿路线一站站走。图库的局限与互补传统图查询Cypher擅长精确关系遍历不擅长模糊语义匹配「手机充电慢怎么办」这类无明确实体关系的问题图库帮不上向量检索更合适。两者互补非替代现代图库如 Neo4j 加向量索引本质是把向量检索嫁接进图非图遍历本身。何时不值得上实体抽取/关系抽取靠 LLM成本高易错图结构维护比向量库复杂得多多数「查某概念解释/某功能怎么用」的描述性问题向量检索 Rerank 已够强行上图是过度设计。判断原则问题是否同时出现「多个具体实体名」且问「它们之间有什么关系/通过关系能找到什么」是则考虑图增强。常见追问多检索几次能不能替代图遍历不能。多跳前提是知道下一步搜什么向量检索没有「关系」概念不知道该沿哪条边走。图里的实体和关系怎么来用 LLM 做实体抽取与关系抽取把非结构化文档转成图需权衡成本与质量。2026 延伸GraphRAGMicrosoft, 2024将知识图谱的社区发现 层次摘要用于增强全局/总结性问答是图增强 RAG 的代表性范式LightRAG 等轻量化方案降低图谱构建成本。Q7. RAG 检索优化策略有哪些——四层系统框架来源阿里二面核心答案检索是 RAG 的命脉——LLM 只能基于召回的 context 作答检索召回的内容就是系统天花板检索层优化的投入产出比高于生成层生成层优化是锦上添花检索层是从根本上抬升能力上限。系统性回答应落在四层框架索引层决定知识「怎么存」、查询层决定问题「怎么转」、召回层决定「从哪些路径找」、重排序层决定「谁最相关进 prompt」。单独优化一层往往有限线上通常组合先靠索引优化 多路召回保覆盖率再用 Rerank 保精度若用户提问质量差再叠加查询优化。关键点 / 展开索引层Small-to-Big 矛盾小 chunk 检索准但内容碎大 chunk 完整但语义稀释① 父子切割子 chunk 150 token 建索引、父 chunk 500 token 通过 parent_id 返回② 摘要索引LLM 生成摘要建向量命中后返回原文③ 多粒度分层索引章节/段落/句子三级按问题类型选粒度。查询层弥合提问与知识库表述鸿沟尤其口语 vs 书面语短文本距离被放大①Query 改写口语/歧义转正式精准结合对话历史消歧②多 Query 扩展3~5 角度保留原始问题防细节丢失③HyDE先生成假设答案再用其向量检索文体更接近文档④Step-back Prompting具体问题抽象成通用背景问题先检索再结合背景答具体。召回层突破单条路径盲区向量 BM25 混合、多 Query 扩展、必要时图检索多路并行互补。重排序层对粗召候选用Cross-Encoder Reranker如bge-reranker-v2-m3精排保证进 prompt 的都是真正相关的内容过滤噪声。常见追问索引层为什么不能直接把 chunk 切小切小检索准但 LLM 拿碎片答不好需 Small-to-Big 兼顾检索精度与阅读完整。HyDE 有什么风险若 LLM 生成的假设答案方向错会把检索带偏适合领域明确的场景。2026 延伸Reranker 从 Cross-Encoder 向支持更长上下文、多语言多任务演进Late InteractionColBERT在召回端部分恢复词级交互Agentic 检索可动态决定四层策略的启用见 Q8。Q8. 复杂的 RAG 范式有哪些经历了怎样的演进来源百度一面核心答案RAG 范式即「用户提问到生成答案」整条链路的组织方式与决策逻辑本质是在「检索与生成之间如何协调、决策、处理异常」。其演进经历了三代Naive RAG检索生成无优化两天能上线 Demo→Advanced RAG检索前后加 Query 改写、Rerank、混合检索等工序工程改动小效果明显当前多数生产系统形态→Modular RAG把各环节拆成可替换模块按需组合如 LlamaIndex Workflow、LangGraph。在此基础上针对朴素 RAG 的痛点演化出多个高级范式。关键点 / 展开Naive RAG 三大痛点催生高级范式① 检索质量参差、低质上下文致幻觉② 所有问题走同一死板流程该省不省、该深挖不深挖③ 知识库覆盖盲区时编造答案。Self-RAG让 LLM 自主决策「要不要检索 / 召回相关否 / 有无幻觉 / 答案质量」通过 4 类reflection tokenRetrieval/Relevance/Support/Utility控制需在专门数据集上微调基础模型开源基于 Llama2-7B/13B通用 GPT 不能直接套用好处是省检索开销、识别不相关避免幻觉。CRAGCorrective RAG检索后加质量评估质量高正常走质量低自动降级到 Web 搜索居中则知识库 网络搜索并用专门解决知识库盲区。GraphRAGMicrosoft用知识图谱的社区发现 层次摘要增强全局/总结性理解适合跨文档宏观问答。Agentic RAG把 RAG 做成 Agent支持多轮动态检索、根据中间结果决定下一步解决「复杂问题需多跳动态检索」的痛点可在通用 LLM 上直接跑。常见追问Self-RAG 和 CRAG/Agentic RAG 最大区别Self-RAG 需微调带 reflection token 的模型后两者可在通用 LLM 上直接跑。什么场景用 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 选型看中英文、合规、维度评估用自有数据 HitKHit50.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(多轮动态)。
大家好我是浩哥这是我输出AI agent面试专题第六章后面还有四期。建议加入粉丝后面粉丝可见。导语本题型考察 RAG 的工程底座——文档切割(Chunking)、Embedding、向量 vs 关键词检索、多路召回、向量/图数据库、检索优化与复杂 RAG 范式。这是 RAG 系统质量的天花板所在检索层优化的投入产出比高于生成层是面试高频且区分度极高的板块。2026年最新AI agent面试01_Agent基础与推理范式2026年最新AI agent面试02_MultiAgent与记忆2026年最新AI agent面试03_工具协议MCP_A2A_FC2026年最新AI agent面试04__工具工程网关外部2026年最新AI agent面试05_RAG基础应用2026年最新AI agent面试06_RAG文档与检索2026年最新AI agent面试07_大模型架构基础2026年最新AI agent面试08_大模型训练评测2026年最新AI agent面试09_AI编程ClaudeCode2026年最新AI agent面试10_通信与行业动态总目录可见 2026年最新AI agent面试0概述篇Q1. 文档如何切割Chunking粒度怎么定如何规避语义被切断来源京东 字节一面 阿里二面核心答案RAG 入库的第一步绝非整篇存库而是必须先把文档切成 chunk片段再分别向量化存储。整篇直存有两个致命问题其一Embedding 模型有输入长度上限长文档根本塞不进去其二即便支持超长输入把整篇压缩成单一向量会将细节「平均掉」检索时只能命中文档级而非语句级的模糊结果。每条 chunk 记录由三部分构成且缺一不可——向量用于相似度检索的「索引卡」、原文LLM 真正阅读的「书页」、metadata来源/页码/章节等「书签」用于过滤与溯源。向量负责「找到」原文负责「阅读」二者角色互补。切割粒度的本质是「检索精度」与「上下文完整」的取舍chunk 太大则语义被稀释、易超长且检索噪声多太小则语义残缺、LLM 看不懂、噪声也多。实践中5001000 token 是合理起点但更关键的是按文档类型选择策略——普通文本用固定大小重叠有标题结构的按语义边界切代码按函数切表格整块保留既要检索精度又要上下文完整则用父子切割小块检索、大块返回。关键点 / 展开固定大小切割 重叠overlap最保底方案按 token/字符切块相邻 chunk 重叠 10–20%如 chunk_size800、overlap150缓解边界截断但只能保证跨边界文字不丢无法根治「完整语义被拆散」。语义边界切割按段落/句子/标题层级等天然断点切优先在段落或标题边界切有标题结构的 Markdown/HTML 可自动带上「章节 小节」metadata语义独立且便于过滤溯源。可用 spaCy/nltk 识别句子边界以句为单位填充 chunk 不在句中截断。特殊内容专项处理代码按函数/类切用 AST 识别边界函数是最小语义完整单元表格整块保留为 Markdown按行截断会丢失列含义与行对比关系。父子切割Parent-Child / Small-to-Big同一内容存两份——小块如 200 token建索引用于精准检索大块如 1000 token通过 parent_id 关联命中后返回大块给 LLM做到「检索用小的、阅读用大的」兼顾精度与上下文完整。进阶「补上下文」方案① 句子窗口检索单句建向量精准检索命中后返回前后 N 句上下文窗口② 命题化切割LLM 把文档拆成自包含独立命题语义密度最高但成本高③ Contextual RetrievalAnthropic 2024向量化前让 LLM 为 chunk 生成背景说明拼接后再向量化从根上补回孤立 chunk 缺失的语境。常见追问overlap 设多大为什么不是越大越好10–20%过大重复内容干扰 LLM 阅读且增存储/成本过小覆盖不了跨边界语义。既要检索精度又要上下文完整你用什么方案父子切割 / Small-to-Big或摘要索引、多粒度分层索引。2026 延伸Contextual RetrievalAnthropic, 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 场景的标配。关键点 / 展开选型三维度① 中英文比例中文首选bge-large-zh中英混合选bge-m3纯英文/求省事用 OpenAItext-embedding-3-small② 数据合规不可出境必须本地部署开源模型BGE 系列最优③ 向量维度越高越准但存储/检索成本越大百万级 1024 维是平衡点text-embedding-3支持降维至 256 维省存储。评估不能盲信 MTEB 通用排行榜通用数据集分布与你的业务医疗/法律/客服差异大状元不一定擅长你的专业考试。正确做法是在自有业务数据上做HitK——准备「问题 正确 chunk」对看正确 chunk 是否进前 KHit5 0.7 即应考虑换模型或改 Chunking0.8 以上较优。各代局限与代表Word2Vec 多义失效FastText 用子词 n-gram 缓解未登录词BERT 语义强但检索须拼接跑百万次不可行SBERT bi-encoder 牺牲部分精度换取数量级提速SimCSE 用 dropout 对比学习解决向量「各向异性」分布挤在窄锥区。主流模型对比text-embedding-3-small1536 维可降维英文好API 有费用/出境风险、bge-large-zh1024 维中文首选、开源、bge-m31024 维多语言、E5英文对比学习代表。常见追问为什么不直接用 BERT 做检索query 须与每个候选 doc 拼接跑一次百万 doc 即百万次前向延迟小时级用户等不起。HitK 是什么多少算合格前 K 条结果含正确答案的比例Hit5 一般需 ≥0.70.8 以上较优。2026 延伸Matryoshka Representation LearningMRLOpenAI text-embedding-3 支持降维可在精度损失极小下大幅降存储BGE 系列持续在中英文 MTEB 领先bi-encoder召回与 Cross-Encoder reranker精排的双塔/单塔分工已成标准范式。Q3. 向量数据库原理、索引算法、核心能力与生产选型/性能实战来源快手一面 阿里一面核心答案向量数据库是专门存储与检索高维向量的数据库核心能力是近似最近邻搜索ANN——在百万至亿级向量中毫秒级找出最相似的 K 条这正是 RAG「检索」步骤的底层支撑。它与「MySQL 加个向量字段」有本质区别关系库擅长精确匹配WHERE id123向量库擅长语义相似「找最相近的」。普通 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把原始向量放磁盘、仅索引留内存进一步省内存。关键点 / 展开主流索引算法①HNSW多层图从顶层稀疏图导航逐层收窄到底层召回率 95%内存消耗大Qdrant/Milvus/Chroma 默认关键参数 M1632、ef_construction100200、ef50~200ef 越大越准越慢②IVF先聚类分桶查询只搜最相关桶内存小、适合超大规模精度略低需调 nlist/nprobe。取舍HNSW 精度高但内存随数据量线性增长亿级可能扛不住IVF 用聚类换内存。生产核心能力①Metadata 过滤先过滤再 ANN避免 Top-K 大量不满足条件白白浪费名额②实时增量更新主流库支持在线写、不重建索引③与 BM25 关键词融合做混合检索。选型维度规模/部署/混合检索Chroma本地嵌入零配置开发测试勿上生产、QdrantRust百万级性能好 API 简、Milvus分布式亿级功能最全但运维复杂、Pinecone全托管 SaaS按量付费但费用高且数据出境、pgvectorPostgreSQL 插件零运维、可 SQL JOIN。踩坑与瓶颈① 内存不足触发 swap延迟 20ms→2s用 SQ8 量化 mmap 解决② 大批量写入触发后台Segment 合并小增量段合并为封存段并建索引P99 从 60ms 抖到 300ms解法为错峰业务低峰期写分批每批 500–1000 条、间隔几秒把一次大冲击拆成多次小冲击。常见追问为什么不用 Elasticsearch 做向量检索ES 向量能力是后加补丁非原生 ANN 设计数据量大性能扛不住。HNSW 和 IVF 怎么选中小规模要精度选 HNSW超大规模/内存受限选 IVF 系列。2026 延伸主流库普遍支持「向量 标量(metadata) 稀疏(BM25)」统一混合索引Milvus/Qdrant 持续增强磁盘索引DiskANN以降本量化SQ8/PQ已成为大规模部署默认手段。Q4. 向量检索 vs 关键词检索BM25有什么区别为什么需要混合检索来源美团二面 字节一面核心答案关键词检索以 BM25 为代表基于词频统计与倒排索引擅长精确词命中产品型号、专有名词、缩写、代码但遇到同义词/不同表达就束手无策向量检索基于 Embedding 的语义空间距离天然擅长跨同义词、近义词的语义匹配却对精确词如「M4 Pro」「GPT-4o」不敏感——这是它「只看语义不看字面」的固有局限换模型也无法根除。二者盲区恰好互补谁也替代不了谁因此生产 RAG 普遍采用混合检索Hybrid Search两路并行召回再用 **RRFReciprocal Rank Fusion**按排名融合。关键点 / 展开BM25 原理倒排索引记录「词 → 哪些文档」而非「文档有哪些词」打分看词频 TF出现越多越相关与稀缺度 IDF罕见词权重高给「的/是」等常见词降权并加饱和度限制防权重无限叠加中文需先 jieba 分词再建索引。向量检索原理文本经 Embedding 转高维向量ANN 在库里找最近 Top-K百万级数十毫秒返回语义强但精确词易漏。核心区别匹配方式词汇重叠 vs 语义距离、索引稀疏倒排 vs 稠密向量、同义词无法 vs 天然支持、精确词极好 vs 易漏、可解释性统计可解释 vs 黑盒。混合检索实现向量 BM25 两路并行总延迟取 max 而非相加几乎零额外代价各自召回后 RRF 融合——只用排名不看原始分数余弦相似度 0~1 与 BM25 任意正数量纲不可比归一化不稳定公式score 1/(rankk)k 通常 60两路都靠前则综合分高、排最前。常见追问为什么不把两路分数直接加权平均量纲不同归一化效果不稳定RRF 绕开分数只比排名无需训练、计算量极小。向量检索对精确词真的不行吗换个好模型能解决吗这是「只看语义不看字面」的固有局限换模型无法根除必须用关键词路补。2026 延伸Hybrid Search 已成为 RAG 默认范式SPLADE 等「学习型稀疏向量」可让关键词路具备一定语义能力ColBERT 的 Late Interaction 在检索端兼顾细粒度词级交互。Q5. 什么是多路召回具体怎么做来源字节一面核心答案多路召回Multi-Recall是同时用多种检索方式并行捞取候选、再合并排序交给 LLM而不是只靠单路向量检索。其出发点是单路有天花板向量检索对精确词如「RTX 4090 显卡功耗」里的型号召回差BM25 对同义/不同表达无能为力用户提问角度与文档表述角度不一致时两路都覆盖不到。把多路组合互相补盲区总召回质量显著高于单路。常见组合为「向量检索 BM25 多 Query 扩展」三路RRF 融合后再接 Reranker 精排。关键点 / 展开三路组合①向量检索语义覆盖同义词/近义命中②BM25 关键词检索精确词/专有名词/数字中文先 jieba 分词③多 Query 扩展LLM 把原问题改写 3–5 个角度版本分别检索再合并去重召回覆盖率 10~20%。结果融合用 RRF各路分数不可比只用排名融合1/(rankk), k60RRF 是粗排适合在 Rerank 之前合并候选集。精排接 RerankerRRF 之后接Cross-Encoder 精排模型如bge-reranker-v2-m3做深度打分把真正相关的内容筛到最前这是融合后必要的一步。实战选型电商/IT 文档大量型号数字向量BM25 双路是标配客服问答提问风格多变加多 Query 扩展质量极致场景三路全上 Rerank。实现细节多 Query 扩展务必保留原始问题在检索列表改写可能丢原始细节各路并行执行延迟取最大。常见追问RRF 之后为什么还要 RerankRRF 只看排名属粗排精度有限Cross-Encoder 双塔交互细排才能把最相关顶到前。多 Query 扩展的代价怎么控多了几次 LLM 调用靠保留原 query、控制 3–5 个变体、命中即合并去重来平衡成本与收益。2026 延伸Query 改写/扩展已成为检索前标准工序Reranker 从 Cross-Encoder 向更轻量、支持长上下文与多语言多任务如 bge-reranker-v2-m3演进RRF 之外「Learned Fusion」在部分场景被探索。Q6. 在什么场景下用图数据库增强传统向量检索来源阿里三面核心答案当业务问题涉及「多个实体之间的关联推理」时应考虑引入图数据库增强。向量检索本质是「单跳」——每次只找与问题直接相关的内容没有「实体/关系」概念无法沿关系链多跳推理。例如「A 公司的投资方和 B 公司有什么交集」「小米竞争对手的 CEO 是谁」「治 A 病的药和治 B 病的药有无相互作用」答案不在某一文档里而藏在多节点关系路径上向量检索答不上来。图数据库以「节点(实体) 边(关系)」存储世界可做图遍历沿边一跳跳收集关联信息正好补上这个短板。关键点 / 展开典型适用场景企业关系分析股权/任职网络、医疗知识图谱疾病-基因-药物多层关联、代码知识库函数调用/依赖链、供应链溯源原料→供应商→成品→分销层级关系。组合用法向量检索做「入口」定位实体如从「小米」相关片段识别节点→ 图数据库接力做「关系遍历」沿竞争/CEO 等边收集沿途节点→ 合并向量结果与图遍历结果一起喂 LLM。类比向量是导航定位图遍历是沿路线一站站走。图库的局限与互补传统图查询Cypher擅长精确关系遍历不擅长模糊语义匹配「手机充电慢怎么办」这类无明确实体关系的问题图库帮不上向量检索更合适。两者互补非替代现代图库如 Neo4j 加向量索引本质是把向量检索嫁接进图非图遍历本身。何时不值得上实体抽取/关系抽取靠 LLM成本高易错图结构维护比向量库复杂得多多数「查某概念解释/某功能怎么用」的描述性问题向量检索 Rerank 已够强行上图是过度设计。判断原则问题是否同时出现「多个具体实体名」且问「它们之间有什么关系/通过关系能找到什么」是则考虑图增强。常见追问多检索几次能不能替代图遍历不能。多跳前提是知道下一步搜什么向量检索没有「关系」概念不知道该沿哪条边走。图里的实体和关系怎么来用 LLM 做实体抽取与关系抽取把非结构化文档转成图需权衡成本与质量。2026 延伸GraphRAGMicrosoft, 2024将知识图谱的社区发现 层次摘要用于增强全局/总结性问答是图增强 RAG 的代表性范式LightRAG 等轻量化方案降低图谱构建成本。Q7. RAG 检索优化策略有哪些——四层系统框架来源阿里二面核心答案检索是 RAG 的命脉——LLM 只能基于召回的 context 作答检索召回的内容就是系统天花板检索层优化的投入产出比高于生成层生成层优化是锦上添花检索层是从根本上抬升能力上限。系统性回答应落在四层框架索引层决定知识「怎么存」、查询层决定问题「怎么转」、召回层决定「从哪些路径找」、重排序层决定「谁最相关进 prompt」。单独优化一层往往有限线上通常组合先靠索引优化 多路召回保覆盖率再用 Rerank 保精度若用户提问质量差再叠加查询优化。关键点 / 展开索引层Small-to-Big 矛盾小 chunk 检索准但内容碎大 chunk 完整但语义稀释① 父子切割子 chunk 150 token 建索引、父 chunk 500 token 通过 parent_id 返回② 摘要索引LLM 生成摘要建向量命中后返回原文③ 多粒度分层索引章节/段落/句子三级按问题类型选粒度。查询层弥合提问与知识库表述鸿沟尤其口语 vs 书面语短文本距离被放大①Query 改写口语/歧义转正式精准结合对话历史消歧②多 Query 扩展3~5 角度保留原始问题防细节丢失③HyDE先生成假设答案再用其向量检索文体更接近文档④Step-back Prompting具体问题抽象成通用背景问题先检索再结合背景答具体。召回层突破单条路径盲区向量 BM25 混合、多 Query 扩展、必要时图检索多路并行互补。重排序层对粗召候选用Cross-Encoder Reranker如bge-reranker-v2-m3精排保证进 prompt 的都是真正相关的内容过滤噪声。常见追问索引层为什么不能直接把 chunk 切小切小检索准但 LLM 拿碎片答不好需 Small-to-Big 兼顾检索精度与阅读完整。HyDE 有什么风险若 LLM 生成的假设答案方向错会把检索带偏适合领域明确的场景。2026 延伸Reranker 从 Cross-Encoder 向支持更长上下文、多语言多任务演进Late InteractionColBERT在召回端部分恢复词级交互Agentic 检索可动态决定四层策略的启用见 Q8。Q8. 复杂的 RAG 范式有哪些经历了怎样的演进来源百度一面核心答案RAG 范式即「用户提问到生成答案」整条链路的组织方式与决策逻辑本质是在「检索与生成之间如何协调、决策、处理异常」。其演进经历了三代Naive RAG检索生成无优化两天能上线 Demo→Advanced RAG检索前后加 Query 改写、Rerank、混合检索等工序工程改动小效果明显当前多数生产系统形态→Modular RAG把各环节拆成可替换模块按需组合如 LlamaIndex Workflow、LangGraph。在此基础上针对朴素 RAG 的痛点演化出多个高级范式。关键点 / 展开Naive RAG 三大痛点催生高级范式① 检索质量参差、低质上下文致幻觉② 所有问题走同一死板流程该省不省、该深挖不深挖③ 知识库覆盖盲区时编造答案。Self-RAG让 LLM 自主决策「要不要检索 / 召回相关否 / 有无幻觉 / 答案质量」通过 4 类reflection tokenRetrieval/Relevance/Support/Utility控制需在专门数据集上微调基础模型开源基于 Llama2-7B/13B通用 GPT 不能直接套用好处是省检索开销、识别不相关避免幻觉。CRAGCorrective RAG检索后加质量评估质量高正常走质量低自动降级到 Web 搜索居中则知识库 网络搜索并用专门解决知识库盲区。GraphRAGMicrosoft用知识图谱的社区发现 层次摘要增强全局/总结性理解适合跨文档宏观问答。Agentic RAG把 RAG 做成 Agent支持多轮动态检索、根据中间结果决定下一步解决「复杂问题需多跳动态检索」的痛点可在通用 LLM 上直接跑。常见追问Self-RAG 和 CRAG/Agentic RAG 最大区别Self-RAG 需微调带 reflection token 的模型后两者可在通用 LLM 上直接跑。什么场景用 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 选型看中英文、合规、维度评估用自有数据 HitKHit50.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(多轮动态)。
