Embedding 模型选型 vs 落地流程?

回答与解析

一、Embedding模型选型策略

核心原则：任务驱动选型

关键考量点：

• 维度与效率权衡：1024维通常效果较好，但768维在速度和存储更优
• 指令微调：E5、BGE等支持指令模板（如"Represent this sentence for retrieval"），对特定任务有增益
• 实际验证：在业务数据上做召回率@K的离线评测，MTEB分数仅作初筛参考

二、向量存储完整流程

原始文档 → 文本清洗 → 智能分块 → 向量化 → 元数据绑定 → 索引构建 → 入库

各阶段要点：

1. 分块（Chunking）

   • 按语义边界：比较段落、句子和多组固定长度候选
   • 重叠策略：比较无重叠、短重叠和较长重叠，验证边界召回与冗余成本
   • 特殊处理：代码按函数/类分割，Markdown按标题层级分割

2. 向量化

   • 批量推理，GPU加速
   • 归一化向量（便于余弦相似度计算）

3. 元数据关联

   {
       "vector": [...],           # 稠密向量
       "sparse_vector": {...},    # 可选，BM25权重
       "metadata": {
           "doc_id": "xxx",
           "chunk_index": 3,
           "source": "技术规范_v2.pdf",
           "timestamp": "2024-01-15"
       }
   }
   

4. 索引与入库

   • 小数据量：Flat（精确搜索）
   • 大规模：HNSW（高召回）或 IVF（内存友好）
   • 混合检索：稠密向量 + 稀疏向量（如BGE-M3的unified embedding）

生产注意： 建立版本管理机制，模型更新时需全量重刷向量。

学习建议

建议系统学习该知识点

口语版讲法(约4分钟)

• 本质问技术选型与工程落地的平衡
• Embedding选型策略：任务驱动，混合使用
• 向量化入库流程：分块、向量化、元数据、索引
• 落地风险：模型更新与版本管理
• 延伸点：混合检索与重排的取舍

这道题其实是在问，RAG系统里怎么把文本转化成机器能理解并快速检索的向量表示。核心是两个层面：一是怎么选Embedding模型，二是从原始文档到向量库的工程流程怎么落地。

先说选型。很多人喜欢列一堆模型对比分数，但真正落地的时候，我的原则是任务驱动。通用语义检索场景，比如客服问答，我会优先考虑MTEB高分的双塔模型，像BGE、E5这些，它们在大规模语料上预训练过，泛化能力不错。但如果是代码或技术文档场景，比如企业内部SOP查询，我会换成CodeBERT这类在代码上预训练的模型，因为通用模型对代码语义的理解会差一些。多语言场景，比如跨国公司的合规文档，那就得上multilingual-e5或者BGE-M3。

这里有个重要的边界划分：不是非此即彼，真正落地常常是几个模型一起上。比如订单异常检索，我会用BGE做通用语义，同时保留BM25做关键词精确匹配，因为订单号、错误码这些精确信息，向量模型反而容易混淆。Hybrid Search才是更稳定的方案。

再一个，维度取舍。1024维效果通常好一些，但768维在速度和存储上更优。如果对延迟敏感，比如实时客服场景，我会倾向768维，配合IVF索引。

接下来说完整流程。从原始文档到向量库，我习惯按这个顺序走：文本清洗、智能分块、向量化、元数据绑定、索引构建、入库。

分块是最容易出问题的一环。固定 token 数切分简单，但照搬一个固定值容易切断语义。我会把多组 chunk size 与无重叠、短重叠、较长重叠组合放进同一评测集，比较边界召回、答案质量和成本后再选。如果是Markdown文档，按标题层级分；代码按函数或类分。举个例子，企业SOP里经常有“满100减20”这种政策，如果切分不当，可能把“满100”和“减20”分到两个块里，检索时就匹配不上了。

向量化阶段，批量推理用GPU加速，输出后一定要做归一化，这样算余弦相似度才正确。元数据绑定很重要，我会记录文档ID、块索引、来源、时间戳，这样检索后能追溯到原始文档，也方便做权限过滤。

索引构建，小数据量用Flat，精确搜索；大规模用HNSW，召回率高。如果要做混合检索，像BGE-M3支持同时输出稠密和稀疏向量，那就一起存。

这里有个坑：模型更新时，向量需要全量重刷。如果不做版本管理，新旧向量混在一起，检索质量会崩。所以上线前我会建立一个版本管理机制，每次模型更新，用同样的query集做回放测试，对比Recall@K和延迟，通过才切换。

说到混合检索，其实还有个权衡：什么时候用稠密向量，什么时候用稀疏向量？比如订单号检索，稀疏向量或者关键词匹配更准；而意图理解，稠密向量更好。真正稳定的RAG系统，往往是稠密加稀疏再加重排，但重排会增加延迟，所以需要根据业务场景做取舍。

所以整体上，我会把Embedding模型选型看成是工程和效果的平衡，没有银弹。我更倾向先用小规模数据做离线评测，选一个基线，然后根据线上bad case迭代。

关键一句:混合检索中稠密向量与稀疏向量的取舍，以及重排的引入时机

面试官还可能这样问

1. 问法 1 · 场景切入

   假设你在做电商客服的RAG系统，用户问的退货政策需要从一堆文档里找。你会怎么选文本嵌入模型？是把整段政策文本直接存向量，还是先分块？具体流程走一遍看看。

2. 问法 2 · 层层追问

   RAG里文档检索那步，文本嵌入模型怎么挑？……如果文档特别长或者多语言呢？……选好模型后，原始文本怎么处理成向量存进数据库？每一步的关键点是什么？

3. 问法 3 · 直球架构

   在RAG系统中，根据任务需求选择文本嵌入模型的策略是什么？文本chunk向量化后存入向量数据库的完整流程，从分块到索引构建，详细说一下。