3 文本、向量、关键词索引、元数据之间是什么关系
P1 · rag
🏷 标签：hybrid-search, keyword, vector, metadata
1️⃣ 考察意图
面试官想考察你对 RAG 系统中多模态索引协同工作的理解深度，而非单纯背诵概念。这是典型的“系统设计 + 工程取舍”题，刁钻点在于：候选人常把四者割裂看待，无法说清“何时用谁、如何组合、代价是什么”。答好了能展示你对检索整条链路的掌控力——从原始文本到最终召回，能根据场景（如电商、法律、医疗）灵活设计混合检索策略，并量化 trade-off（如召回率 vs 延迟）。这是 P1 进阶题，区分“会用框架”和“能调优系统”的候选人。
2️⃣ 标准答
核心关系：四者构成检索系统的四层架构，从粗到细、从语义到精确，协同工作。
- 文本（原始内容）：是检索的“原料”，不可跳过。所有索引都从文本派生。坑：直接对全文做向量化会丢失结构信息（如段落边界），导致检索噪声。解法：先做 chunking（按段落/语义窗口切分，如 256 tokens 重叠 32 tokens），再分别构建索引。
- 向量索引（语义表示）：负责“模糊匹配”，解决同义词、近义词问题。常用模型：bge-large-en-v1.5 或 text-embedding-3-large。索引结构：HNSW（Hierarchical Navigable Small World），参数 efConstruction=200, M=16 平衡构建速度与召回。Trade-off：向量维度越高（如 1024 vs 768），检索精度上升但延迟线性增长，且内存占用翻倍。实际落地：对长文档（>512 tokens）用 ColBERT 的 late interaction 替代 DPR，避免压缩信息损失。
- 关键词索引（精确匹配）：负责“精确命中”，如产品型号、人名、法律条款。核心算法：BM25（默认 k1=1.5, b=0.75），或 TF-IDF 变体。坑：中文场景下，分词器（如 jieba）的词典质量直接影响召回。解法：对专业领域（如医疗）构建自定义词典，并启用 n-gram（2-4 gram）兜底。Trade-off：BM25 对长文档有偏（倾向于召回长文档），需配合 length normalization 或截断。
- 元数据（结构化过滤）：负责“缩小搜索范围”，如时间、价格、类别。典型实现：Elasticsearch 的 filter context（不参与评分，只做布尔过滤）。坑：元数据字段类型错误（如日期存为字符串）会导致范围查询失效。解法：严格定义 mapping（如
"timestamp": {"type": "date"}），并利用 doc_values 加速排序。
组合策略（以电商搜索“红色连衣裙 200-500元”为例）：
- 元数据过滤：先通过
price:[200 TO 500]过滤掉 80% 无关商品，减少后续计算量。 - 混合检索：关键词索引（BM25）匹配标题中的“红色”“连衣裙”，向量索引（HNSW）匹配语义相似的“酒红长裙”“夏季碎花裙”。
- 融合排序：用 RRF（Reciprocal Rank Fusion） 或 线性加权（如 0.3 * BM25_score + 0.7 * vector_score）合并结果。坑：权重需根据业务调优，电商场景关键词权重可更高（0.5-0.6），因为用户常输入精确型号。
- 最终排序：对 top-100 结果用 reranker（如 Cohere Rerank v3 或 bge-reranker-v2-m3）做二次排序，提升 NDCG@10 约 5-10%。
实际落地的坑 + 解法：
- 索引同步延迟：文本更新后，向量和关键词索引需异步重建。解法：用 CDC（Change Data Capture） 监听数据库 binlog，触发增量索引（如 Elasticsearch 的 _update_by_query）。
- 存储成本：向量索引占用内存大（100 万条 768 维向量约 3GB）。解法：对低频数据用 磁盘索引（如 FAISS IVF），或降维至 256 维（牺牲 2-3% 召回率换 4 倍内存节省）。
3️⃣ 答题模板（30 秒电梯版）
“这个问题我从三个层面回答：第一，四者的角色——文本是原料，向量管语义，关键词管精确，元数据管过滤。第二，组合策略——先元数据过滤缩小范围，再向量+关键词混合检索，最后用 reranker 精排。第三，工程取舍——向量维度高精度好但延迟大，BM25 对长文档有偏需调参，元数据字段类型错误会导致查询失效。总结一句：四者互补，设计时需根据场景（如电商 vs 法律）动态调整权重和索引结构。”
4️⃣ 高频追问 & 应对
追问 1：如果用户搜索“苹果”，如何区分是水果还是手机？
应对策略：利用元数据字段（如
category: electronics）做上下文过滤。同时，在关键词索引中引入 实体链接（如用 spaCy 识别“苹果”后，查询同义词库判断是否匹配“Apple Inc.”）。更激进的做法：对 query 做 query rewriting，用 LLM 生成多个意图（如“苹果 水果 食谱”“苹果 手机 价格”），分别检索后合并结果。
追问 2：混合检索时，RRF 和线性加权哪个更好？
应对策略：RRF 对分数分布不敏感，适合异构分数（如 BM25 和向量分数量级不同），但会丢失分数绝对值信息。线性加权需要调参（如网格搜索 0.1-0.9 步长 0.1），但可解释性强。实际建议：先用 RRF 快速上线，再通过 A/B 测试对比 NDCG@10，若线性加权提升 > 2% 则切换。注意：RRF 的 k 参数（默认 60）影响平滑程度，k 越小对高分项越敏感。
追问 3：元数据过滤放在检索前还是检索后？
应对策略：放在检索前（pre-filter）可减少向量检索的候选集，降低延迟，但可能漏掉跨类别的语义相似结果（如“连衣裙”在“女装”和“童装”类别都有）。放在检索后（post-filter）保证召回率，但计算量大。工程取舍：如果元数据过滤条件能排除 > 50% 数据，用 pre-filter；否则用 post-filter。折中方案：用 两阶段过滤——先 coarse filter（如价格范围），再 fine filter（如品牌列表）。
5️⃣ 避坑 · 常见错误答法
- ❌ 说“四者独立工作，各管各的” → ✅ 正确切入：强调协同关系，用具体场景（如电商搜索）展示如何组合，并给出 trade-off（如 pre-filter vs post-filter）。
- ❌ 说“向量索引永远比关键词好” → ✅ 正确切入：指出关键词在精确匹配（如产品型号、法律条款）中不可替代，并举例说明 BM25 在短文本上的优势（如标题匹配）。
- ❌ 说“元数据只是附加信息，不重要” → ✅ 正确切入：元数据能减少 80% 的检索噪声，是系统性能优化的关键，并给出具体数字（如过滤后延迟降低 50%）。
6️⃣ 简历呼应
- 如果你有 RAG 项目：从“混合检索系统设计”切入，强调你如何用 Elasticsearch + Milvus 实现四层索引，并给出 NDCG@10 对比数据（如混合检索比纯向量提升 12%）。
- 如果你只做过传统 NLP：用“信息检索中的多字段搜索”类比，说明文本是 document，向量是 embedding，关键词是 inverted index，元数据是 filter，并迁移到 RAG 场景。
- 如果你是校招无项目：聚焦“论文复现”，引用 DPR + BM25 的经典论文（如《Dense Passage Retrieval for Open-Domain Question Answering》），并说明你如何用 HuggingFace 实现混合检索 demo。
- 《Dense Passage Retrieval for Open-Domain Question Answering》（Karpukhin et al., 2020）
- 《ColBERT: Efficient and Effective Passage Search via Contextualized Late Interaction over BERT》（Khattab & Zaharia, 2020）
- 《Hybrid Search: Combining Sparse and Dense Retrieval》（Elasticsearch 官方博客）
- 《FAISS: A Library for Efficient Similarity Search》（Johnson et al., 2019）
- 《Reciprocal Rank Fusion: A Simple and Effective Method for Combining Search Results》（Cormack et al., 2009）