RAG面试题4

6. 在 RAG 中 Embedding 究竟是什么如何选择和评估一个 Embedding 模型Embedding 我理解就是把一段文本转成一串数字向量的过程。它有一个很关键的特性就是语义相近的文本转出来的向量在数学空间里的距离也近。RAG 里的语义检索就是靠这个实现的不是关键词匹配而是看两段内容的意思相不相近。选模型的话我主要看三个维度第一是中文支持中文场景我会优先选 BGE 系列效果其实比 OpenAI 的模型还要好第二是向量维度维度越高精度越好但存储成本也越大第三是最大输入长度这个决定了能处理多长的 chunk。评估这块我的建议是不要只看通用排行榜一定要在自己的业务数据上跑召回测试那个才是真正有参考价值的。Embedding 是什么?Embedding 模型做的事情本质上是「语义压缩」把一段自然语言文本映射成一个固定长度的浮点数向量。比如一个 1024 维的 Embedding 模型不管输入的文本是 10 个字还是 500 个字输出都是一个长度为 1024 的数字列表。这个映射最关键的性质是语义相近的文本向量的余弦相似度高。为什么衡量相似度要用「余弦」而不是直接算两个向量的直线距离因为在高维空间里两段文本的向量长度模长会受文本长度、表达强度等非语义因素影响直接比距离会把「长短」和「语义」混在一起。而余弦只看两个向量的方向也就是夹角方向越一致余弦值越接近 1正好把「意思相近」从「文本长短」里剥离出来。你可以把它理解成两段话如果「指向同一个意思」它们的向量箭头就朝着同一个方向至于箭头多长无所谓。你可能会觉得这没什么了不起的关键词搜索不也能找到相关内容吗还真不一样。比如「苹果手机怎么截图」和「iPhone 如何截屏」这两句话一个字都不一样关键词搜索根本匹配不上但经过 Embedding 之后两个向量的余弦相似度可能高达 0.95而「苹果手机」和「苹果汁」虽然都有「苹果」但语义相差很远向量距离也会拉开。这就是语义检索比关键词匹配强的核心原因它能处理同义词、近义词和不同的表达方式。很多人以为向量检索就是高级的关键词匹配其实完全不是一回事它是从「意思」层面在做匹配。常见 Embedding 模型对比理解了 Embedding 的原理接下来就是选模型了。Embedding 模型这两年迭代很快目前主流的选择大概分几类。第一类是OpenAI 的 text-embedding 系列text-embedding-3-small是性价比最高的1536 维支持降维到 256 维来节省存储调用方便英文效果非常好缺点是 API 调用有费用而且数据要发到 OpenAI 服务器有些企业有数据出境合规问题。第二类是BGE 系列北京智源研究院出品bge-large-zh-v1.5是经典的中文开源模型1024 维可以本地部署数据不出境。不过要注意的是BGE 虽然仍然是很好的选择但已经不是中文场景的唯一首选了。bge-m3是 BGE 的多语言版本同时支持中英日等多种语言1024 维而且支持三种检索模式稠密向量、稀疏向量、ColBERT 式多向量适合中英文混排的场景。第三类是新一代高性能模型这两年涌现了一批在 MTEB 排行榜上超过 BGE 的模型。Qwen3-Embedding阿里通义出品在多语言基准上表现突出中文效果很强Voyage-3-large在英文检索上精度超过 OpenAI 的模型Cohere embed-v4支持 128K 超长上下文适合长文档场景Gemini EmbeddingGoogle 出品在多个评测中表现均衡。如果你在 2025-2026 年做新项目建议关注这些新模型在自己的数据上做测评后再选型。如何选择 Embedding 模型聊完了模型分类具体到你自己的项目该怎么选选模型的时候主要看这几个判断点。第一是中英文比例知识库以中文为主可以选bge-large-zh-v1.5或者更新的Qwen3-Embedding中英混合选bge-m3纯英文或追求省事选text-embedding-3-small。第二是数据合规要求数据不能出境就必须用可以本地部署的开源模型BGE 系列和 Qwen3-Embedding 都是很好的选择。第三是向量维度对存储和检索速度的影响维度越高精度越好但存储空间和检索时间都会增加。百万量级的知识库1024 维是个合理的平衡点如果规模很小1536 维也无所谓。有些新模型如 text-embedding-3-small支持 Matryoshka 降维可以灵活调整维度来平衡精度和成本。如何评估 Embedding 模型这里有一个常见的误区很多人拿 MTEB 这类通用排行榜的分数来选模型觉得分数高就一定好。MTEB 是一个权威的文本 Embedding 通用排行榜用多种标准数据集评测模型的语义搜索能力是好的参考。但它用的是通用数据集你的业务场景比如医疗问诊、法律文档、客服知识库和通用数据分布差异很大排行榜第一的模型不一定适合你。就好比高考状元不一定擅长你那个行业的专业考试测评的数据分布不对分数就没有参考意义。正确的评估方法是在自己的业务数据上测准备几百条业务相关的「问题 正确答案 chunk」对分别用候选模型做检索看正确的 chunk 有没有出现在前 K 条结果里。这个指标叫 HitKHit5 0.8 的意思就是80% 的问题它对应的答案都出现在了检索结果的前 5 条里。通常 Hit5 低于 0.7 就要考虑换模型或者改进 Chunking 策略了。这种贴近真实场景的评估比排行榜分数更有参考价值。回答要讲清三点。第一Embedding 不只是「文本变向量」关键是语义相近的文本向量距离近这才是语义检索的基础。第二选模型要看场景中文场景 BGE 和 Qwen3-Embedding 都是很好的开源选择中英混合用 bge-m3有数据合规要求就用开源模型本地部署。第三评估模型不要只看 MTEB 排行榜要在自己的业务数据上跑 HitK 测试这才是真正有参考价值的。如果面试官追问「你用的什么模型为什么选它」你可以说「中文场景用 bge-large-zh-v1.5 或 Qwen3-Embedding在自己的业务数据上 Hit5 达到 0.8 以上最终根据测评结果选的」这个回答有理有据。7. Embedding 有哪几种算法你了解过吗Embedding 算法大致经历了三代演进。第一代是静态词向量以 Word2Vec 和 GloVe 为代表把每个词映射成固定向量但同一个词不管上下文是什么向量永远不变处理不了多义词。第二代是以 BERT 为代表的上下文相关向量同一个词在不同语境下有不同的向量表达能力大幅提升但 BERT 本身输出的是 token 级别的向量两个句子要比较相似度就必须拼在一起跑百万条文档就要跑百万次检索速度完全不可接受。第三代是以 SBERT、SimCSE、BGE 为代表的句子级对比学习 Embedding专门为「两段文本有多相似」这个任务优化能提前把所有文档向量算好存起来查询时只需算一次是 RAG 场景的标配。为什么 Embedding 算法要一代代演进要理解各代算法的设计动机先想一个最简单的问题怎么让计算机理解「苹果手机怎么截图」和「iPhone 如何截屏」是同一个问题关键词匹配完全没用因为这两句话没有一个共同的词。早期 NLP 系统为了解决这个问题走向了「把词变成向量」这条路向量空间里的距离代表语义距离这就是 Embedding 的核心出发点。你可能会想既然都是把文本变成向量搞一套方案不就行了为什么还要一代一代演进原因很简单每一代方案解决了一类问题的同时都暴露出了新的短板。第一代处理不了多义词第二代处理了多义词但在检索场景下慢得无法实用第三代才真正把「语义检索」这件事做到既能用又好用。理解了这个「每一代在补上一代的坑」的逻辑后面三代算法的设计思路就很好懂了。第一代静态词向量Word2Vec / GloVe / FastText先来看第一代算法。它们的核心思路非常朴素用一个词周围的词来预测这个词或者反过来用这个词来预测周围的词。通过大量文本训练语义相近的词自然就会在向量空间里被推到一起。Word2Vec是这一代最有影响力的代表2013 年 Google 提出。它有两种训练方式CBOW用周围词预测中心词和 Skip-gram用中心词预测周围词。为什么 Skip-gram 更常用因为它从一个词能产生多个训练样本用这个词预测周围每一个词样本利用率更高对低频词尤其友好CBOW 在大数据集上收敛更快但两者最终效果通常比较接近细节上 Skip-gram 对生僻词表现更好所以更常作为默认选项。训练完之后每个词对应一个固定的向量「国王 - 男人 女人 ≈ 女王」这个著名的类比就是用 Word2Vec 向量做到的当时整个 NLP 圈都为之兴奋。GloVeGlobal Vectors for Word Representation是斯坦福提出的思路和 Word2Vec 类似但更系统直接对整个语料库的词共现矩阵做分解对全局统计信息的利用更充分。实际效果和 Word2Vec 差不多很多场景两者可以互换。FastText是 Facebook 提出的改进解决了一个很实际的问题Word2Vec 处理不了「未登录词」也就是训练集里从没见过的词。你可能会觉得这有什么大不了的但在真实业务里新词、专有名词、网络流行语不断冒出来处理不了新词就意味着检索直接断链。FastText 的解法很巧妙——把词拆成字符级别的 n-gram 子词比如「苹果」会被拆成「苹」「果」「苹果」等子片段每个子片段有自己的向量一个词的向量是其子片段向量的平均。这样遇到没见过的新词只要子片段见过就还能估算出一个合理的向量。这一代算法的共同局限性是两个字静态。每个词只有一个固定向量不管上下文如何。「我吃了苹果」里的「苹果」和「苹果手机发布了」里的「苹果」向量完全相同。很多人以为 Word2Vec 已经理解了语义其实它只是记住了「哪些词经常一起出现」真正的语义理解还差得远。这个致命缺陷直接催生了第二代算法。第二代上下文相关向量ELMo / BERT理解了第一代「一个词永远只有一个向量」的局限第二代算法的改进方向就很明确了让词的向量随上下文动态变化同一个词在不同句子里有不同的向量表示。ELMo2018 年Allen NLP 提出用双向 LSTM 来建模同时从左往右和从右往左扫描句子把两个方向的隐藏状态拼起来作为词的上下文向量。ELMo 是第一个实用的上下文 Embedding当时在多个 NLP 任务上大幅刷新了成绩。BERT2018 年Google 提出用 Transformer 替代 LSTM引入了 Masked Language Model 预训练任务效果全面超越 ELMo成为 NLP 领域最重要的里程碑之一。BERT 用 [CLS] token 来表示整个句子同时看到前后文双向表达能力远超单向模型。但问题来了BERT 这么强为什么 RAG 检索不用它很多人以为 BERT 效果好就万事大吉其实不是。BERT 有一个在检索场景下极其致命的缺陷要比较两个句子的相似度必须把两个句子拼在一起喂给 BERT让 [CLS] 来做判断。这意味着每次检索都要把查询和每一个候选 chunk 拼在一起跑 BERT百万条文档的知识库就要跑百万次。你可能觉得百万次也不算多吧别忘了 BERT 一次前向传播就要几十毫秒百万次就是好几个小时用户根本等不起。这个问题直接导致了第三代的诞生。第三代句子级对比学习 EmbeddingSBERT / SimCSE / BGE第二代 BERT 虽然语义理解能力强但「必须两两拼接」这个限制让它在检索场景下完全没法用这就引出了第三代的核心理念能不能让每个句子独立生成一个向量然后直接用余弦相似度来比较第三代专门针对「句子相似度」和「语义检索」这个任务优化是 RAG 系统的标配。SBERTSentence-BERT2019 年就是用这个思路解决了 BERT 在检索场景下用不了的问题。它用 bi-encoder 结构两个句子分别独立过 BERT各自得到一个句子级向量然后只用余弦相似度来衡量两个向量的距离。你可能会问这样精度不会下降吗确实会一点因为两个句子是分开编码的模型在编码阶段看不到两句话 token 之间的交叉关系Cross-Encoder 那种「每个 token 都能和另一句的每个 token 互相注意到」的深度交互就被牺牲掉了所以在特别微妙的匹配上会不如 Cross-Encoder。但换来的是速度提升了几个数量级知识库里所有文档的向量可以提前算好存起来每次检索时只需要算一次查询向量然后做余弦相似度就行毫秒级返回。在 RAG 这种「速度优先」的场景里这个取舍完全值得。from sentence_transformers import SentenceTransformer model SentenceTransformer(all-MiniLM-L6-v2) # 查询和文档分别独立编码不需要拼在一起 query 苹果手机怎么截图 doc iPhone 截屏方法 query_vec model.encode(query) # 检索时实时算 doc_vec model.encode(doc) # 提前算好存向量库 # 余弦相似度衡量语义距离 from sklearn.metrics.pairwise import cosine_similarity score cosine_similarity([query_vec], [doc_vec])SimCSE2021 年普林斯顿提出进一步提升了句子 Embedding 的质量。核心思路是对比学习把同一句话做两次 dropout 得到两个不同的向量把这两个向量作为正样本对让模型学会把它们拉近同时把同一个 batch 里其他句子的向量作为负样本把它们推远。这个方法训练非常简单不需要人工标注但效果很好。它解决了一个很多人不知道的问题BERT 原生的句子向量存在「各向异性」也就是说向量分布是扭曲的都挤在一个窄小的锥形区域里没有充分利用向量空间。SimCSE 通过对比学习把向量「撑开」了让语义空间变得更均匀。BGEBAAI General Embedding北京智源研究院是中文 RAG 场景非常流行的开源模型基于对比学习在大规模中英文数据上训练同时支持 bi-encoder 和 reranker 两种形态专门为检索场景优化。E5微软是另一个常用的英文对比学习 Embedding效果同样优秀。值得一提的是第三代模型还在持续进化。2025-2026 年出现了几个重要的新趋势。指令感知 Embedding比如 Qwen3-Embedding模型能根据检索指令动态调整向量表示同一段文本在「找相似问题」和「找答案」两种意图下会产生不同的向量。Matryoshka 表示学习MRL模型训练时让向量的前 N 维就能表达有意义的语义这样你可以灵活地截断维度来平衡精度和存储成本。多模态 Embedding同一个模型既能编码文本也能编码图片让 RAG 可以做到文本和图片的跨模态检索。这些新趋势不是独立的第四代而是在第三代对比学习的基础上做的增强但面试时如果能提到会显示你对最新进展有关注。8. 什么是向量数据库有没有做过向量数据库的对比选型向量数据库是专门用来存储和检索高维向量的数据库核心能力是近似最近邻搜索也叫 ANN能在百万甚至亿级的向量里快速找出最相似的几条。普通关系型数据库的索引结构对高维向量基本上是失效的所以需要专门的数据库来处理这个场景。我自己做过一些选型本地开发阶段我用 Chroma零配置上手极快生产环境的中小规模我推荐 Qdrant性能不错、API 也比较简洁如果到了超大规模就要考虑 Milvus 了字节和小米都在用不想自己运维的话 Pinecone 是一个云托管的选项如果项目里已经有 PostgreSQL也可以直接用 pgvector 插件不用引入新组件。什么是向量数据库向量数据库就是专门用来存储和检索「向量」的数据库。这里的向量指的是嵌入模型Embedding Model把文本、图片、音频这些内容转换成的一串浮点数比如一句话可能被转换成 [0.12, -0.87, 0.34, ... ] 这样一个 768 维或 1024 维的数组。每一个向量代表了这段内容的「语义含义」语义越相近的内容它们的向量在高维空间里的距离就越近。向量数据库支持的核心操作叫做近似最近邻搜索ANNApproximate Nearest Neighbor给你一个查询向量在库里找出和它最相似的 K 个向量返回对应的原始内容。这正是 RAG 里「检索」那一步的底层支撑——用户问了一个问题先把问题转成向量再去向量数据库里找最相关的文档片段最后喂给大模型生成回答。很多人会把向量数据库和「MySQL 加个向量字段」混为一谈其实这两者有本质区别。用一句话概括就是MySQL 擅长精确匹配WHERE id 123向量数据库擅长语义相似「找和这个意思最接近的内容」。两者解决的是完全不同的问题不是互相替代的关系。为什么需要专门的向量数据库理解了向量数据库是干什么的接下来自然会问为什么不直接在 MySQL 或者 ES 里存向量非要引入一个新的数据库普通的关系型数据库MySQL、PostgreSQL在存储结构化数据时靠 B-tree 索引查询WHERE id 123这种精确匹配效率极高。但向量检索要做的事完全不同——不是找「等于」的而是找「最相近」的没有精确匹配只有相似度排序。高维向量比如 1024 维的相似度搜索如果暴力遍历把查询向量和库里每一条向量都算一遍余弦相似度百万条数据就要算一百万次延迟完全不可接受。那为什么不用 B-tree 加速因为 B-tree 只能处理一维的有序索引对高维向量这种「多个维度同时要考虑距离」的场景基本是失效的。你不可能对一个 1024 维的向量建一个 B-tree然后说「帮我找和它最近的」因为「近」本身是一个高维空间的综合判断不是某一个维度上的排序。向量数据库的价值就在于用专门的索引结构把这个搜索加速在可接受的精度损失下把延迟降到毫秒级。理解了这个核心价值接下来我们看它是怎么做到的。核心索引算法HNSW 和 IVF向量数据库之所以能做到毫秒级检索秘密全在索引算法上。目前主流的索引算法有两种先说HNSWHierarchical Navigable Small World这是目前召回率最高的 ANN 算法之一。它构建的是一个多层图结构查询时从最上层的稀疏图开始导航逐层收窄范围最终在底层找到最近邻。你可以把它想象成在地图上找最近的餐厅不是把全国所有餐厅都遍历一遍而是先在全国层面找到大致方向再锁定到省、市、区一层一层缩小效率极高。HNSW 的优点是召回率高通常在相同延迟下能到 95% 的召回率、查询速度快缺点是建索引时内存消耗大不适合内存极度受限的场景。Qdrant、Milvus、Chroma 默认都用 HNSW。IVFInverted File Index是另一种思路它先对向量做聚类把相似的向量分进同一个「桶」里查询时只搜最相关的几个桶而不是全量遍历。这就像图书馆的分类体系找一本编程书不需要把整个图书馆翻一遍先找到「计算机科学」那个区域再在里面找范围大幅缩小。IVF 的优点是内存占用小、适合超大规模缺点是精度比 HNSW 略低需要调参聚类数量 nlist、搜索桶数量 nprobe。Milvus 在超大规模场景下会用 IVF 系列索引。你可能会问HNSW 精度高、速度快为什么还需要 IVF原因很简单HNSW 的内存消耗和向量数量成正比到了亿级规模内存可能扛不住。IVF 用聚类换内存牺牲一点精度就能处理超大规模数据两者各有适用场景。向量数据库的核心能力搞清楚了索引算法这个底层核心再来看向量数据库在工程层面需要具备哪些能力。光有 ANN 搜索还不够生产级系统还要支持几个关键特性第一个是Metadata 过滤也叫混合检索。实际业务里知识库往往有多个部门、多个产品线的文档用户查的时候只想搜「技术部的文档」或者「2024 年更新的内容」。向量数据库支持给每个向量挂上 metadata 字段检索时加过滤条件只在符合条件的子集里做 ANN 搜索。你可能会想为什么不先 ANN 搜完再过滤因为那样可能搜出来的 Top-K 结果大部分都不满足条件白白浪费了检索名额。先过滤再 ANN 搜索能保证召回的每一条都是真正想要的。第二个是实时更新。RAG 的知识库经常需要新增、修改、删除文档向量数据库需要支持增量更新。很多人以为向量索引建好就不能动了其实主流的向量数据库都支持在线写入新数据进来后增量构建索引不需要停服重建。第三个是与关键词检索融合。纯向量检索对一些精确词语比如产品型号「GPT-4o」、专有名词的效果不好有些向量数据库同时支持向量检索 BM25 关键词检索做混合召回效果更好。选型建议了解了向量数据库的核心原理和能力之后最后来看一个很实际的问题到底选哪个选向量数据库主要看三个维度数据规模、部署方式、是否需要混合检索。中小到大规模、团队小、快速上线首选Qdrant性能好、API 设计简洁、文档完善Docker 一条命令就能部署Rust 写的性能很稳。Qdrant 现在也支持分布式模式分片 副本实际已经有亿级规模的生产案例覆盖面比较广。很多团队一开始用 Chroma 做原型后来上生产就切到 Qdrant这个路径很常见。说到Chroma它确实是上手最快的选项Python 直接pip install本地内存运行零配置配合 LangChain/LlamaIndex 原生集成非常方便。Chroma 现在也支持了 Client-Server 模式和 Chroma Cloud 托管服务不再只是本地嵌入式了而且在 2025 年还加入了 BM25/SPLADE 稀疏向量的混合检索支持。不过要注意的是Chroma 的分布式能力还在成熟中对于超大规模千万级以上的生产场景它的稳定性和性能还不如 Milvus 和 Qdrant 这些专门为大规模设计的方案。总结来说Chroma 适合快速原型验证和中小规模的生产使用超大规模就要考虑其他选项了。数据规模在千万到亿级需要分布式选Milvus国内大厂用得最多支持多种索引类型有完整的集群方案但部署运维复杂度也高团队需要有足够的人力来维护。不想运维数据在云上用Pinecone全托管 SaaS按用量付费适合快速验证商业化产品。不过要注意数据出境的问题如果业务数据有合规要求Pinecone 就不合适了。已经在用 PostgreSQL数据量不是特别大可以直接用pgvector插件不用引入新组件查询可以和业务数据做 SQL JOIN运维成本为零。向量数据库是专门为高维向量的相似度搜索设计的核心能力是 ANN近似最近邻搜索普通关系型数据库的 B-tree 索引对高维向量检索基本是失效的这不是加个字段就能解决的问题。面试官追问选型标准的时候你要从数据规模、部署方式、是否需要混合检索三个维度来回答。快速原型验证用 Chroma中小到大规模生产环境推荐 Qdrant超大规模选 Milvus 做分布式不想运维就上 Pinecone已有 PostgreSQL 的项目直接用 pgvector 插件就够了。每个选项的适用场景和优劣势都要说清楚千万别拿 GitHub Star 数量当选型依据。另外索引算法至少要能讲清楚 HNSW 和 IVF 的区别和适用场景这是向量数据库的核心技术面试官一定会问。