面试题 · 检索
搜索「RAG架构」匹配到追问内容，相关段落已展开。查看匹配内容 ↓
请解释向量检索（向量召回）的基本原理，包括向量化、索引构建和相似度计算等关键步骤
向量检索把文档和查询编码到同一表示空间，再按照与模型训练方式匹配的距离或相似度寻找近邻。效果不仅取决于索引，还取决于语料、分块、embedding 版本和距离度量是否一致。
按学习路线查看教程、项目和面试题。
查询编码后进入 ANN 搜索，得到候选，再结合元数据过滤、重排或业务规则返回 Top-K。用精确搜索作为基线评估 ANN Recall@K，并同时看最终证据召回、延迟、内存、构建时间和更新成本。
结论：向量检索是 embedding、度量、索引和重排共同组成的链路，索引参数不能弥补表示或分块错误。
场景切入
假设你做一个电商搜索，用户搜“红色连衣裙”，你打算怎么从几百万商品里快速找到语义最匹配的那一批？能讲讲从文本到向量再到检索的完整思路吗？
层层追问
搜过关键词召回吧？那如果要从语义层面做召回……比如用户说“舒适的运动鞋”，你怎么把“柔软”“透气”的鞋子也找出来？……具体怎么把文本变成向量？那么多商品向量怎么建索引才能快？最后怎么算相似度？
直球架构
解释一下向量检索的基本原理，包括向量化、索引构建和相似度计算这三个关键步骤。比如，怎么从文本得到向量？大规模下用什么索引？相似度度量怎么选？
我理解向量检索的核心，是把文本之间的“语义接近”变成向量空间里的“距离接近”。传统关键词检索看的是词有没有命中，比如用户问“怎么退款”，文档里写的是“退费流程”，关键词可能匹配不上；向量检索会先把两段文本编码成向量，只要语义相近，距离就会比较近，所以更适合问答、推荐、[[RAG]] 这类场景。
整个链路我一般按三段看：先[[向量化]]，再建索引，最后算相似度并排序。
向量化就是用 Embedding 模型把 query 和文档块都转成固定维度的稠密向量。这里最关键的不是“转成多少维”，而是这个向量空间是否真的学到了业务里的语义关系。比如“退款”“退费”“售后申请”在客服场景里应该靠得很近，但“苹果”在水果场景和手机场景里可能对应完全不同的语义，所以 Embedding 模型的领域适配很重要。
有了向量以后，如果数据量很小，可以直接暴力算距离；但线上通常是百万、千万甚至更大规模，不可能每次查询都扫全库，所以要建[[近似最近邻]]索引，也就是 ANN。常见的 [[HNSW]] 是图结构，查询时先从高层快速靠近目标区域，再逐层下沉到更细的位置，优点是召回高、延迟稳，缺点是比较吃内存。[[IVF-PQ]] 更偏大规模压缩检索，能把存储和计算成本降下来，但会牺牲一部分精度。工程上选哪种，不是看哪个算法更高级，而是看数据规模、延迟要求、更新频率和硬件成本。
相似度计算通常用余弦、点积或者欧氏距离。文本 Embedding 里最常见的是余弦相似度，如果向量已经做了归一化，余弦和点积基本等价，线上常用点积是因为算得更快。这里我会特别注意一点：训练或评估 Embedding 时用的相似度口径，最好和线上检索保持一致，不然离线效果和线上排序会有偏差。
所以完整流程就是：文档先[[切块]]，跑 Embedding，写入向量索引；用户问题进来后也转成向量，到索引里找 TopK 候选，再结合相似度、元数据过滤或者 reranker 做最后排序。
真正落地时，核心权衡是召回、延迟和成本。比如 HNSW 召回好但内存贵，IVF-PQ 成本低但精度有损；TopK 取大一点召回会好，但后面的[[重排]]和生成成本也会变高。
我还会补一句：很多人一开始会疯狂调索引参数，但实际排查下来，问题往往出在 Embedding 模型和文档切块上。向量空间本身没把语义学好，再好的索引也只是更快地找错东西。这个点在 RAG 项目里特别常见。
