04-Embedding与向量检索：从文本向量到 ANN 索引和向量库选型

上一篇讲 chunking 时，重点是文档以什么粒度进入索引。chunk 决定了知识块的边界，决定了检索系统后面能找回什么样的证据。

到了这一篇，chunk 会继续往下走一步：被转成向量，进入向量索引。

在 RAG 里，embedding 和向量检索经常被放在最显眼的位置。很多最小 demo 也是从“文档转向量、存向量库、问题转向量、查相似 chunk”开始的。这个流程很直观，也容易让人形成一种印象：只要选一个 embedding 模型，再接一个向量数据库，RAG 的检索层就完成了。

真实系统里，embedding 和向量检索需要看的东西更多。文本如何被压缩成向量，相似度如何计算，索引如何在速度和召回之间取舍，向量数据库如何和 metadata、权限、版本、更新结合，这些都会影响最终答案质量。

这一篇的核心判断可以先放在前面：

embedding 决定系统如何理解文本相似，向量索引决定系统如何在大规模数据里找到相似文本。

两者共同构成 RAG 检索层的基础，但它们只解决“语义相似”的一部分问题。真正的答案相关性，还要依赖 query 改写、关键词检索、metadata 过滤、Rerank 和上下文工程继续补齐。

embedding 在 RAG 链路里的位置

经过文档处理和 chunking 后，系统手里已经有了一批相对干净、带 metadata 的文本块。embedding 要做的事情，是把这些文本块映射成向量。

简化链路可以这样看：

chunk 文本
  -> embedding 模型
  -> dense vector
  -> 向量索引
  -> 用户 query 转向量
  -> 相似度检索
  -> 召回候选 chunk

向量可以理解成文本在语义空间里的坐标。语义接近的文本，向量距离也应该更近。用户提问时，系统把 query 也转成向量，再到向量索引里找距离更近的 chunk。

这个过程让 RAG 能够处理“表达不同但意思接近”的情况。用户说“怎么恢复账号”，文档里写的是“忘记登录凭证后的账户找回流程”，关键词未必完全一致，但 embedding 有机会把它们映射到接近的位置。

这也是向量检索相比单纯关键词检索的优势。它不只看词面重合，也尝试捕捉语义相似。

embedding 模型决定语义空间

embedding 不是一个中立的转换器。不同 embedding 模型会形成不同的语义空间。

一个中文能力弱的模型，可能无法很好表达中文业务文档。一个通用 embedding 模型，在客服、医疗、法律、金融、代码这类强领域语料里也可能不够稳定。一个最大输入长度很短的模型，会让长 chunk 被截断。一个维度很高的模型，可能带来更高存储和检索成本。

所以，embedding 模型选型不能只看榜单。榜单能提供参考，但 RAG 最终服务的是具体业务问题。更稳的方式，是用自己的文档和真实问题构造一批评测集，看正确 chunk 是否能进入 topK，看不同模型在召回率、延迟、成本和稳定性上的表现。

选模型时通常要关注几个维度。语言能力决定它能不能理解当前语料，领域适配决定它能不能抓住专业表达，向量维度会影响存储和检索成本，最大输入长度会影响 chunk 设计，推理延迟会影响入库和在线查询，部署方式会影响数据安全和成本控制。

维度	为什么重要
语言能力	决定中文、英文或混合语料能不能被稳定表达
领域适配	决定模型能不能理解业务术语、代码、表格和缩写
向量维度	影响存储成本、索引大小和检索开销
最大输入长度	影响 chunk 长度设计和截断风险
推理延迟	影响入库速度和在线查询体验
部署方式	影响数据安全、成本和运维复杂度

如果业务文档主要是中文，中文 embedding 能力要优先验证。如果文档里有大量代码、表格、英文术语和缩写，还要测试模型对混合语料的处理能力。如果系统需要本地部署，开源 embedding 模型和推理成本就会变成重要因素。

embedding 模型一旦确定，还要管理版本。后面更换 embedding 模型时，新旧向量通常不能直接混用，因为它们属于不同语义空间。生产系统里，embedding 模型版本应该写进 metadata 或索引版本里，方便后续重建、灰度和回滚。

从词向量到句向量

embedding 的发展可以粗略理解为从词到句、从静态到上下文、从通用表示到检索优化。

早期的 Word2Vec、GloVe 更偏词向量。它们能表达词之间的相似关系，但同一个词在不同上下文里的含义很难区分。BERT 之后，上下文表示变得更强，同一个词在不同句子里可以得到不同表示。再往后，SBERT、SimCSE、BGE 这类模型更关注句子或文本片段级别的语义表示，也更适合 RAG 里的相似度检索。

对 RAG 来说，重点不在于背模型历史，而在于理解一件事：

RAG 需要的是适合检索的文本表示。

一个模型生成的向量如果更适合分类、聚类或其他任务，不一定在检索场景里表现最好。RAG 要关心的是 query 和 chunk 能不能在同一个语义空间里对齐。

比如用户 query 往往很短，chunk 往往更长。短 query 和长 chunk 的语义表达本来就不完全对称。有些 embedding 模型会区分 query embedding 和 document embedding，有些模型在训练时就针对检索任务做了优化。选型时要注意模型是否适合“问题到文档片段”的匹配，而不只是“文本到文本”的通用相似度。

相似度计算：向量靠什么判断接近

向量检索需要一个距离或相似度函数。

常见的有余弦相似度、内积和欧氏距离。余弦相似度关注向量方向，适合衡量语义方向是否接近。内积常用于向量已经归一化或模型训练目标匹配内积检索的场景。欧氏距离关注几何距离，在一些索引和向量空间里也会使用。

这里最容易忽略的是一致性。embedding 模型的训练方式、向量是否归一化、向量数据库使用的距离函数，需要保持一致。模型适合用 cosine，相似度却按 inner product 算，结果可能会变差。向量是否归一化，也会影响 cosine 和 inner product 的关系。

相似度方式	关注点	常见注意事项
余弦相似度	向量方向是否接近	常用于语义相似度，通常关注归一化
内积	向量方向和模长共同影响分数	要看模型训练目标是否匹配
欧氏距离	几何距离	依赖具体向量空间和索引实现

RAG 系统里，相似度分数还不能直接等同于答案可信度。一个 chunk 和 query 在语义上相似，只能说明它可能相关。它是否真的包含答案，是否来自正确版本，是否有权限，是否足够完整，还要结合 metadata、Rerank 和后续生成阶段判断。

所以，向量相似只是候选召回的第一步。它负责把可能相关的内容拉进候选池，后面还要继续筛选。

Flat 检索和 ANN 索引

向量库最直接的检索方式是 Flat，也就是对所有向量逐个计算相似度，再排序返回 topK。

Flat 的结果最精确，理解也最简单。但当向量数量变大时，逐个计算会越来越慢。企业知识库、代码库、客服记录、日志文档一旦规模上来，Flat 很难满足在线查询延迟。

这时就需要 ANN，Approximate Nearest Neighbor，近似最近邻检索。

ANN 的核心思想是在速度、内存和召回率之间做取舍。系统不再保证每次都找到绝对精确的最近邻，而是用更快的结构找到高度接近的候选。只要召回率足够高，再配合 Rerank 和后续过滤，整体效果往往更适合生产。

这也是向量索引存在的原因。它的重点在于提升大规模向量检索效率，让系统更快找到近似相似项。

HNSW、IVF 和 PQ 的取舍

常见向量索引里，HNSW 和 IVF 系列很有代表性。

HNSW 可以理解成构建一张多层近邻图。查询时从高层快速导航，再逐步进入底层精细搜索。它的查询速度快，召回率通常也不错，适合很多中高规模检索场景。代价是内存占用较高，索引构建也有成本。参数上，ef_search 会影响查询时探索范围，范围越大召回越好，延迟也会增加。

IVF 的思路是先把向量空间划分成多个聚类区域，查询时只搜索和 query 更接近的一部分区域。它能减少搜索范围，适合更大规模的数据。nprobe 这类参数会影响查询时扫描多少个聚类，扫描越多，召回越高，延迟也越高。

PQ 更进一步关注压缩。它通过量化方式减少向量存储和计算成本，适合数据规模很大、内存压力明显的场景。代价是精度会有损失，调参和评估也更重要。

这些索引没有绝对优劣。HNSW 更常被用在追求较高召回和较低延迟的场景，IVF 和 PQ 更适合规模继续扩大后的成本控制。真正的选择要看数据规模、延迟要求、内存预算、更新频率和召回目标。

索引方式	更适合	主要取舍
Flat	小规模、高精度验证、离线评测	精确但慢，规模上来后延迟高
HNSW	中高规模、追求低延迟和较高召回	内存占用和构建成本较高
IVF	更大规模、需要减少搜索范围	聚类和 nprobe 参数会影响召回
PQ	超大规模、内存压力明显	压缩带来精度损失，需要评测

对 RAG 来说，索引参数会直接影响用户答案。ef_search 太低、nprobe 太小，正确证据可能进不了候选池。参数调高后召回改善，延迟和成本也会上升。这里的取舍需要通过评测集验证，而不是只凭经验。

向量数据库选型要看系统位置

向量数据库不只是存向量。生产 RAG 里，它通常还要支持 metadata 过滤、索引构建、增量更新、删除、版本管理、权限过滤、混合检索和观测排查。

如果是 demo 或小规模实验，Chroma 这类轻量工具足够快速。如果团队已经深度使用 PostgreSQL，pgvector 的优势在于工程栈简单，数据和业务系统更容易放在一起管理。数据规模继续变大，Milvus、Qdrant、Weaviate 这类专门向量数据库会在索引能力、过滤能力、扩展能力和服务化运维上更有优势。Pinecone 这类托管服务则更偏向降低运维成本。

选型时，不建议只看“支持多少向量”这一项。RAG 系统更关心的是综合能力：查询延迟是否稳定，metadata filter 是否高效，删除和更新是否可靠，索引重建是否方便，是否支持多租户隔离，能否和关键词检索结合，监控和排查是否好做。

能力	为什么影响 RAG
metadata filter	支持权限、版本、产品线和时间范围过滤
更新和删除	避免旧知识残留，支持文档增删改
索引版本管理	支持 embedding 升级、重建、灰度和回滚
混合检索	方便结合关键词检索和向量检索
观测排查	方便分析召回、过滤、延迟和失败样本

还有一个很现实的问题是更新。知识库不是一次性构建。文档会新增、修改和删除，embedding 模型也可能升级。向量数据库需要支持可靠的增量写入、删除旧向量、索引版本切换和回滚。否则系统很容易出现旧知识残留。

所以，向量库选型要放回 RAG 全链路里看。它承担的是检索基础设施，而不只是一个向量数组仓库。

metadata filter 和向量检索要一起设计

上一篇讲 metadata 时提到，chunk 需要来源、业务、时间、权限、质量等信息。到了向量检索阶段，这些 metadata 会真正参与查询。

用户提问后，系统可能先根据用户权限筛掉不能看的文档，再根据产品线、文档类型、发布时间范围缩小候选集合，然后再做向量检索。也可以先做向量召回，再用 metadata 做过滤。不同顺序会影响性能和召回，需要根据数据规模和权限要求设计。

权限场景里，metadata filter 尤其重要。RAG 的答案可能引用企业内部文档，如果检索阶段没有权限过滤，模型就有机会看到不该看的内容。即使最终不展示原文，模型也可能把信息泄露到答案里。

时间和版本也一样。某份接口文档已经废弃，如果 metadata 没有失效时间或版本信息，旧 chunk 仍然可能被召回。用户看到的就是过期答案。

向量相似负责找语义接近，metadata filter 负责让候选范围符合业务约束。两者组合起来，检索结果才更接近真实可用的证据。

向量检索的局限

向量检索擅长语义相似，但它和答案相关之间仍然有距离。

一个 chunk 可能和问题表达相似，却没有真正包含答案。一个包含答案的 chunk，可能因为关键词、编号、专有名词或短 query 表达不充分，没有被向量召回。对于产品型号、错误码、接口名、法规条文、精确标题，关键词检索和结构化过滤经常更可靠。

这也是后续要讲 Hybrid Search 的原因。向量检索提供语义召回，关键词检索提供精确匹配，多路召回提高覆盖面，Rerank 再对候选证据做更精细排序。

这一篇先把向量检索的基础讲清楚，后面再进入在线检索链路时，会继续把 Query Rewrite、BM25、Hybrid Search、多路召回和 Rerank 串起来。

embedding 和向量索引也需要评测

embedding 模型和向量索引不能只靠感觉选。

评测时可以准备一批真实问题，并标注每个问题应该命中的标准文档或标准 chunk。然后观察不同 embedding 模型、不同 chunk 策略、不同索引参数下，正确证据是否能进入 topK，排名是否靠前，最终答案是否忠实使用证据。

检索层可以关注 Hit@K、Recall@K、MRR、NDCG。系统层还要关注延迟、吞吐、内存、索引构建时间和更新成本。生成层则要看答案相关性和忠实度。一个 embedding 模型如果召回率高但延迟过大，未必适合在线系统；一个索引参数如果提升了少量召回却显著增加延迟，也要结合业务权衡。

评测层次	关注指标
检索效果	Hit@K、Recall@K、MRR、NDCG
系统成本	延迟、吞吐、内存、索引构建时间、更新成本
生成结果	答案相关性、忠实度、引用是否正确

评测还要保留失败样本。向量检索失败的样本很有价值，它们能暴露模型不理解的表达、chunk 设计的问题、metadata 缺失的问题，也能提示是否需要引入关键词检索或 query 改写。

小结

embedding 和向量检索是 RAG 检索层的基础。

embedding 决定文本如何进入语义空间，相似度函数决定向量之间如何比较，ANN 索引决定系统如何在大规模数据里快速找到近似相似项，向量数据库则承担存储、过滤、更新、版本和工程运维能力。

这篇最重要的判断是：

向量检索负责把可能相关的证据拉进候选池，后续还需要关键词检索、metadata filter、Rerank 和上下文工程继续筛选和组织。

下一篇会进入在线链路。用户问题进入系统后，query 如何处理，向量检索如何触发，召回结果如何进入 Rerank 和上下文拼接，这些会一起决定一次 RAG 请求最终能不能产出可靠答案。