Embedding 与向量检索：RAG 真正的技术底座

很多人把 RAG 的效果问题归咎于「模型不够强」，但真实情况往往是：检索这一关就没过。模型拿到的材料，要么是错的，要么是碎的。这篇聊聊检索侧真正该懂的工程细节。

Embedding 不是越强越好，而是越「贴场景」越好

通用大模型 embedding（如 text-embedding-3）在通用语义上很稳，但一旦进入垂直领域（法律、医疗、代码），领域模型（如 BGE-M3、multilingual-e5）往往更准。选型的第一个问题不是「哪个分最高」，而是「我的语料长什么样」。

• 长文档（>512 token）：优先选支持长上下文的模型（BGE-M3 支持 8192）。
• 多语言：选 multilingual 系列，否则跨语言召回会塌。
• 维度：1024 维和 1536 维在多数业务上差异有限，但存储与索引成本差很多。

归一化：被忽略的「准确率刺客」

如果你用余弦相似度，就必须先对向量做 L2 归一化。不做归一化，点积会被向量模长带偏，长文本和短文本的得分不再可比。很多「召回莫名其妙」的 bug，根子就在这。

import numpy as np

# 归一化后再入库 / 再查询，保证 cosine == dot product
v = vec / np.linalg.norm(vec)
# 之后用点积即可，数据库侧也能用内积索引加速

ANN 索引：召回率与延迟的权衡

百万级以上的向量不可能做暴力全量扫描。近似最近邻（ANN）是必选项，核心是选索引类型：

• HNSW：召回高、查询快，但内存占用大，适合「内存够、要快」的场景。
• IVF_PQ：压缩率高、省内存，但召回略低，适合「亿级、成本敏感」的场景。
• pgvector 的 HNSW：能用 SQL 直接查，运维成本最低，中小规模首选。

Java 侧怎么落地（pgvector 示例）

String sql = """
  SELECT doc_id, 1 - (embedding <=> ?::vector) AS score
  FROM knowledge_chunk
  ORDER BY embedding <=> ?::vector
  LIMIT 5""";
// <=> 是 pgvector 的余弦距离算子，已自动处理归一化逻辑

检索是 RAG 的地基。地基不牢，模型再聪明也只能「胡诌得很有条理」。

给面试官的加分点

如果你能讲清「为什么归一化影响召回」「HNSW 和 IVF 怎么取舍」，面试官会立刻把你从「用过 RAG」归类为「理解 RAG」。这就是技术含量和求职竞争力的区别。