2 索引为什么不是“把文本存进去”这么简单
1️⃣ 考察意图
面试官想看的不是你会不会调FAISS API，而是你是否理解索引的本质是搜索优化而非存储。这道题属于工程取舍+系统设计型，刁钻点在于：很多人把“索引”等同于“存向量”，忽略了索引结构对召回率、延迟、内存的三角博弈。答好了能展示你对向量搜索底层原理（IVF、HNSW、PQ）的掌握，以及在实际RAG系统中平衡精度与速度的工程直觉。
2️⃣ 标准答
索引不是“把文本存进去”，因为存储和搜索是两套完全不同的系统目标。存储只关心数据持久化，而索引要解决的是如何在毫秒级从百万级向量中找到最相似的Top-K。这背后涉及三个核心挑战：
- 维度灾难与近似搜索向量维度通常768-1536（如text-embedding-3-small的1536维），暴力搜索（Flat）复杂度O(N×D)，百万级数据一次查询就要秒级。必须用近似最近邻（ANN）算法。常用方案：
- IVF（倒排文件）：用K-means聚类划分Voronoi单元，查询时只搜索最近几个单元。Trade-off：nlist越大，搜索范围越小、速度越快，但召回率下降。实际落地时nlist取sqrt(N)左右（如100万向量取1000），nprobe控制搜索单元数（典型值10-50）。
- HNSW（分层可导航小世界图）：构建多层图结构，上层长跳、下层细搜。参数efConstruction控制建图质量（越大越准但建图慢），efSearch控制查询精度。Trade-off：HNSW内存占用高（约向量的1.5-2倍），但延迟稳定在10ms内，适合在线服务。
- PQ（乘积量化）：将向量拆分子空间分别量化，压缩到1/4-1/8大小。典型配置M=8（拆8个子空间），每个子空间用256个中心点（8bit）。Trade-off：内存省了但精度损失明显，通常配合IVF使用（IVF+PQ）。
- 元数据过滤的工程坑纯向量搜索不够，RAG场景常需过滤时间、权限、类别等元数据。坑在于：先向量搜索再过滤，可能把符合条件的向量全过滤掉（比如只召回100条但过滤后剩0条）。解法：
- 预过滤：在索引层用bitmap或倒排链标记元数据，搜索时只扫描符合条件的分区。FAISS的IDSelector或Milvus的标量过滤就是这种思路。
- 后过滤+扩召回：搜索Top-200再过滤取Top-10，牺牲一点延迟保召回。实际项目里我们设过nprobe=50+召回300条，过滤后还剩50条，才够rerank用。
- 多向量关联与文档级索引一个文档可能被切多个chunk，每个chunk有独立向量。索引不能只存向量，还要维护chunk到文档的映射。坑：搜索时返回chunk级结果，但用户要的是文档级。解法：建两层索引——第一层向量索引搜chunk，第二层用倒排或哈希表聚合到文档，再按文档内最高分排序。FAISS的IDMap可以存自定义ID，但聚合逻辑得自己写。
总结：索引的本质是用数据结构+算法把搜索复杂度从O(N)降到O(logN)或O(sqrt(N))，同时用量化压缩内存，用元数据过滤保证结果可用。这不是“存进去”能解决的。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，索引的核心是搜索优化而非存储，必须用ANN算法（如IVF、HNSW）把O(N)复杂度降到亚线性；第二，实际落地要处理元数据过滤的坑，比如预过滤vs后过滤的取舍；第三，多向量关联需要两层索引结构。总结一句：索引是精度、速度、内存的三角博弈，不是简单的存储操作。”
4️⃣ 高频追问 & 应对
追问 1：你刚才提到IVF和HNSW，线上场景怎么选？
看延迟和内存预算。如果内存够（比如100万768维向量约1.2GB），HNSW优先，延迟稳定在5-10ms，召回率95%+。如果内存受限（比如边缘设备），用IVF+PQ，内存降到200MB，但延迟可能到20ms，召回率90%左右。实际项目里我们做过压测：HNSW的efSearch=128时召回率98%，但建图耗时30分钟；IVF的nlist=1000、nprobe=50时召回率92%，建索引只要5分钟。线上服务选HNSW，离线批处理选IVF。
追问 2：元数据过滤导致召回率暴跌，你怎么量化这个风险？
先做数据分布分析。比如时间过滤：如果90%数据是近3个月的，过滤后只搜10%的数据，召回率可能从95%掉到60%。解法是扩召回：搜索Top-K*10再过滤。具体数字：我们线上设K=100，扩到K=1000，过滤后还剩120条，再rerank取10条，召回率回升到90%。代价是查询延迟从10ms涨到30ms，但能接受。如果延迟敏感，用预过滤+bitmap，建索引时给每个向量打标签，搜索时只扫描匹配标签的单元。
追问 3：索引更新怎么做？比如新增文档要实时生效。
分两种场景。离线批量更新：每天重建一次索引，用FAISS的train_and_add，耗时可控。在线增量更新：HNSW支持动态插入（add_with_ids），但删除麻烦（只能标记无效）。实际坑是：增量插入后HNSW图结构会退化，召回率随时间下降。解法：每N次增量后触发一次重建，或者用IVF+增量聚类（如Faiss的IndexIVF支持add，但nlist固定）。我们线上用双缓冲：一个索引服务读，另一个后台重建，切换时用原子指针，保证零停机。
5️⃣ 避坑 · 常见错误答法
- ❌ “索引就是把文本转成向量存到数据库里。”→ ✅ “索引的核心是构建搜索结构，比如IVF的聚类中心或HNSW的图边，存储只是副产品。重点在如何用这些结构加速搜索。”
- ❌ “用Flat索引最准，所以线上用Flat。”→ ✅ “Flat是暴力搜索，百万级数据延迟秒级，线上不可用。必须用ANN算法，在召回率95%+的前提下把延迟压到10ms内。”
- ❌ “元数据过滤很简单，先搜向量再过滤就行。”→ ✅ “先搜后滤可能导致召回率暴跌，必须扩召回或预过滤。实际项目里我们遇到过过滤后结果为空的情况，后来改成预过滤+bitmap才解决。”
6️⃣ 简历呼应
- 如果你有RAG项目：从实际索引选型切入，比如“我在项目中对比了IVF和HNSW，发现HNSW在延迟上优于IVF但内存高30%，最终根据服务器内存选了IVF+PQ，召回率92%”。
- 如果你只做过传统NLP：用倒排索引类比，比如“传统ES的倒排索引是词到文档的映射，向量索引是向量到文档的映射，但多了维度灾难和近似搜索的挑战”。
- 如果你是校招无项目：聚焦FAISS官方教程或SIFT1M数据集实验，比如“我复现了FAISS的IVF+PQ在SIFT1M上的实验，分析了nlist和nprobe对召回率的影响，产出性能对比报告”。
- FAISS官方文档：IndexFlat、IndexIVFFlat、IndexHNSWFlat的API和参数说明
- 《Efficient and robust approximate nearest neighbor search using Hierarchical Navigable Small World graphs》（HNSW原论文）
- 《Product Quantization for Nearest Neighbor Search》（PQ原论文）
- Milvus官方博客：标量过滤与向量搜索的混合查询最佳实践
- 博客《Vector Indexing in RAG: A Practical Guide to Trade-offs》（作者：Pinecone工程师）