完整题目
在RAG系统中，如何根据任务需求选择合适的文本嵌入模型？将文本chunk向量化后存入向量数据库的完整流程是什么？
本文目录
一、Embedding模型选型策略
核心原则：任务驱动选型
| 任务场景 | 推荐方向 | 典型模型 |
|---|---|---|
| 通用语义检索 | 双塔编码器，MTEB高分 | BGE、GTE、E5系列 |
| 代码/技术文档 | 代码预训练模型 | CodeBERT、CodeT5+ |
| 多语言场景 | 多语言对比学习 | multilingual-e5、BGE-M3 |
| 长文档理解 |
页面加载中…
面试题 · 文档处理
搜索「HNSW」匹配到口述回答，相关段落已展开。查看匹配内容 ↓
在RAG系统中，如何根据任务需求选择合适的文本嵌入模型？将文本chunk向量化后存入向量数据库的完整流程是什么？
核心原则：任务驱动选型
| 任务场景 | 推荐方向 | 典型模型 |
|---|---|---|
| 通用语义检索 | 双塔编码器，MTEB高分 | BGE、GTE、E5系列 |
| 代码/技术文档 | 代码预训练模型 | CodeBERT、CodeT5+ |
| 多语言场景 | 多语言对比学习 | multilingual-e5、BGE-M3 |
| 长文档理解 |
学习内容与项目面试，在同一条路上。
| 支持长上下文的模型 |
| Jina Embeddings v2（8K） |
关键考量点：
原始文档 → 文本清洗 → 智能分块 → 向量化 → 元数据绑定 → 索引构建 → 入库各阶段要点：
分块（Chunking）
向量化
元数据关联
{
"vector": [...], # 稠密向量
"sparse_vector": {...}, # 可选，BM25权重
"metadata": {
"doc_id": "xxx",
"chunk_index": 3,
"source": "技术规范_v2.pdf",
"timestamp": "2024-01-15"
}
}索引与入库
生产注意： 建立版本管理机制，模型更新时需全量重刷向量。
建议系统学习该知识点
场景切入
假设你在做电商客服的RAG系统，用户问的退货政策需要从一堆文档里找。你会怎么选文本嵌入模型？是把整段政策文本直接存向量，还是先分块？具体流程走一遍看看。
层层追问
RAG里文档检索那步，文本嵌入模型怎么挑？……如果文档特别长或者多语言呢？……选好模型后，原始文本怎么处理成向量存进数据库？每一步的关键点是什么？
直球架构
在RAG系统中，根据任务需求选择文本嵌入模型的策略是什么？文本chunk向量化后存入向量数据库的完整流程，从分块到索引构建，详细说一下。
这道题其实是在问，[[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迭代。