字节后端研发实习一面：向量索引与混合检索
本场面试题
- 常见向量索引有什么取舍，如何比较向量检索库？
- 混合检索为什么有用，RRF 怎样融合两路排名？
面经与参考答法
字节后端研发实习一面：向量索引与混合检索
字节后端研发实习生、AI Agent方向的一面记录，标题中的业务描述为安全与风控；不据此认证正式部门名称。面试年月未注明，以下选录向量索引和混合检索两组。
以下短答、详解和示例均为编辑教学补充，不代表候选人现场回答、实际项目实现或企业标准答案。
（1）常见向量索引有什么取舍，如何比较向量检索库？
可以先用全量精确搜索建立召回基线，再比较 HNSW 的图搜索与 IVF 的分桶搜索：HNSW 以额外内存和构建成本换查询效率，IVF 依赖代表性训练数据及探测桶数。比较检索库还需看过滤、更新删除、持久化与部署能力，不能把索引算法和完整数据库混为一层。
详解
先固定 embedding 版本、向量维度和距离定义，再评估索引；否则距离变化与索引变化会混在一起。下表以常见的未量化索引为例，具体 API 能力取决于实现版本。
| 方法 | 怎样找候选 | 主要代价与调节点 |
|---|---|---|
| Flat 精确搜索 | 对合法候选计算距离 | 计算量随候选数量及维度增长，可作为 ANN 召回基准 |
| HNSW | 多层邻接图中逐步逼近，再扩展搜索 | 图边占内存；连接度和搜索宽度影响构建、召回与时延 |
| IVF Flat | 先找聚类桶，再在选中的桶里计算距离 | 需训练合适聚类；探测桶越多通常覆盖越高，也增加计算 |
这些类型与参数可以在Faiss 索引表及选型指南核对。它们是教学例子，原文没有列出候选人用过的具体索引名。
例如文档检索有租户过滤时，无过滤的 ANN 跑分不能代表真实效果：若先取全局近邻再丢掉其他租户，可能只剩少量结果。测试应使用相同授权集合的精确近邻作基准，报告 Recall@K、尾延迟、索引内存和构建时间。
Faiss 提供相似度检索库与索引组件；把它嵌入服务后，仍须自行安排持久化、元数据、并发更新和故障恢复。完整向量数据库可能提供这些服务能力，但也要核对实际部署与一致性语义。不要泛称“HNSW 都支持删除”：例如 Faiss 的特定 HNSW 实现存在删除限制，其他系统可能采用墓碑和重建。
（2）混合检索为什么有用，RRF 怎样融合两路排名？
关键词检索有利于保留错误码、编号等精确线索，向量检索补充同义表达。RRF 按各列表的名次求倒数和，避免直接相加量纲不同的原始分数；融合后可对有限候选重排，候选深度与模型规模要用同一业务评测集和时延预算选择。
详解
教学例子是用户同时输入错误码和口语描述。词法链路可能准确找到错误码，语义链路可能找到用另一种说法写出的故障解释；两路互补是否真的有用，应和各自单路结果比较。
RRF 的一项典型定义是：
$\mathrm{RRF}(d)=\sum_i\frac{1}{c+r_i(d)}$
其中每条列表的名次从 1 开始，文档未出现在某条列表就没有该路贡献；同一路先按稳定文档 ID 去重。这里用 c 表示排名平滑常数，避免与返回结果数量 K 混淆。它不要求 BM25 分数和向量相似度处在同一尺度，但也丢掉了原分数差距的信息；排名常数和候选窗口仍需验证。Elastic RRF 文档给出了公式和这些参数。
若两个候选列表分别为 A、B 与 B、C，B 在两路都有贡献，而 C 只得到第二路贡献。这解释了融合机制，不能证明任意查询都因此更准。
控制重排开销时，先冻结召回候选池，比较不同候选数、输入长度、批大小和重排器的排序质量及尾延迟；再固定生成模型看答案与引用。若正确证据根本没召回，换更大的重排器也补不回来。权限、版本和时效条件须在检索路径执行，不能交给融合分数决定。