完整题目
请解释向量召回的基本原理，包括向量嵌入、相似度计算、索引构建等关键技术环节，并说明在大规模检索系统中的实现方式。
答案要点
- 向量嵌入将文本/数据映射到语义空间
- 相似度计算常用余弦相似度或内积
- ANN索引（HNSW、IVF）解决高维向量检索效率问题
- 大规模系统采用分片、量化、缓存等工程优化
- RAG中需平衡召回率与延迟
向量召回核心流程
1. 向量嵌入（Embedding）
- 用预训练模型（BERT、Sentence-BERT、OpenAI Embedding等）将文本编码为稠密向量
- 关键：语义相似的文本在向量空间中距离相近
- 维度通常 256-1536 维，需权衡表达能力与存储成本
2. 相似度计算
- 余弦相似度：衡量向量夹角，归一化后等价于内积
- 欧氏距离：适合语义空间均匀分布的场景
- 实际系统常做向量归一化，将相似度搜索转为最近邻搜索
3. 索引构建（ANN近似最近邻）
| 索引类型 | 原理 | 特点 |
|---|---|---|
| HNSW | 分层导航小世界图 | 召回率高、构建慢、内存大 |
| IVF | 聚类+倒排 | 内存友好、需调nlist参数 |
| PQ/OPQ | 向量量化压缩 | 大幅降低存储，有损召回 |
4. 大规模系统实现
- 数据分片：按doc ID或向量聚类分片，分布式检索后归并
- 量化压缩：PQ将向量压缩4-32倍，降低内存和IO
- 缓存策略：热点查询结果缓存，高频向量常驻内存
- 混合检索：向量召回 + BM25关键词召回，RRF融合排序
RAG场景关键点
- 召回率优先：宁可多召不能漏召，靠后续重排序精排
- 延迟敏感：通常P99控制在100-200ms内
- 动态更新：增量索引更新避免全量重建
换一种问法，检查是否真正理解
场景切入
假设你在做电商搜索，用户搜'黑色连衣裙'，你打算用向量召回补充关键词召回的结果。那从输入文本到拿到候选商品，中间有哪些关键环节？比如怎么把文本变成向量、怎么算相似、怎么建索引才能快？
层层追问
你平时做检索用向量召回吗？……那文本怎么变成向量的？……算相似度用什么距离？……如果库里有1亿条，怎么在几十毫秒内召回？索引结构怎么设计？
直球架构
请解释向量召回的基本原理，包括向量嵌入、相似度计算和索引构建这几个关键环节，并说明在大规模检索系统中是怎么实现的。
练习口述回答 · 约4分钟
- 本质是语义检索，不是关键词匹配
- 嵌入：BERT类模型把文本映射到向量空间
- 相似度：归一化后内积等价于余弦，工程上选内积
- 索引：HNSW高召回但吃内存，IVF-PQ省内存但掉点，实际常混合
- 大规模：分片+量化+缓存，RAG场景召回率优先
这道题本质问的是，怎么把非结构化的文本变成计算机能高效检索的语义空间。说白了，向量召回就是用向量距离代替关键词匹配，来找语义相似的内容。
先说[[嵌入]]。我用 BERT 或者 Sentence-BERT 这类模型，把一段文本变成一个稠密向量，维度一般在 256 到 1536 之间。这里有个前提：模型必须在你业务数据上微调过，否则通用模型对专业术语的语义区分很差。举个例子，客服场景里“退款”和“退货”在通用模型里可能很近，但在业务里一个涉及资金一个涉及物流，必须分开。如果不微调，召回就会混。
相似度计算，最常用的是余弦相似度。但实际工程里，我一般先做向量归一化，这样余弦就等价于内积，计算更快。归一化之后，找最近邻就是找内积最大的，直接调 [[Faiss]] 的 inner product 搜索就行。欧氏距离也有用，但前提是你的向量空间分布均匀，比如用 [[CLIP]] 做的[[多模态]]嵌入，否则内积更稳定。
索引这块是核心。暴力搜索不可能，必须用 [[ANN]] 近似最近邻。主流方案两个：[[HNSW]] 和 [[IVF]]-[[Product Quantization]]。HNSW 召回率高，但构建慢、内存大，适合几百万级别的库。[[IVF-PQ]] 把向量量化压缩，内存能省 4 到 32 倍，但召回会掉。真正落地往往是两者结合：比如用 IVF 做粗分，每个桶里再跑 HNSW，或者用 HNSW 做索引，但向量做了 PQ 量化来省内存。
大规模系统里，光一个索引不够。我会做数据分片，按 doc ID 或者向量聚类分到多台机器，查询时广播到所有分片再归并。量化压缩必须上，否则 1536 维向量存一亿条就要 600G 内存，压到 128 维量化之后只要 50G。热点查询结果要缓存，这能扛住 80% 的重复流量。还有就是[[混合检索]]，向量召回 + [[BM25]] 关键词召回，用 RRF 融合排序。因为向量对罕见词、精确数字、订单号这类不敏感，关键词正好补上。比如搜“订单 12345 退款”，关键词能把那条记录精确捞出来，向量只能捞语义相似的退款场景。
这里有个常见的失败场景：很多人以为向量召回可以完全替代关键词，结果上线后发现长尾 query 召回率暴跌。所以我的做法是，先分析 query 类型，如果是实体类、精确匹配类，走关键词；如果是意图类、同义改写类，走向量。两条路并行，靠融合排序兜底。
总结一下，我会把向量召回看成召回层的语义通道，它和关键词通道互补，不能互相替代。我更倾向用 HNSW 做主力索引，配合 IVF-PQ 压缩内存，再根据业务 query 分布动态调整混合比例。