完整题目
在RAG系统中，如何根据任务需求选择合适的文本嵌入模型？将文本chunk向量化后存入向量数据库的完整流程是什么？
本文目录
一、Embedding模型选型策略
核心原则：任务驱动选型
| 任务场景 | 推荐方向 | 典型模型 |
|---|---|---|
| 通用语义检索 | 双塔编码器，MTEB高分 | BGE、GTE、E5系列 |
| 代码/技术文档 | 代码预训练模型 | CodeBERT、CodeT5+ |
| 多语言场景 | 多语言对比学习 | multilingual-e5、BGE-M3 |
| 长文档理解 | 支持长上下文的模型 | Jina Embeddings v2（8K） |
关键考量点：
- 维度与效率权衡：1024维通常效果较好，但768维在速度和存储更优
- 指令微调：E5、BGE等支持指令模板（如"Represent this sentence for retrieval"），对特定任务有增益
- 实际验证：在业务数据上做召回率@K的离线评测，MTEB分数仅作初筛参考
二、向量存储完整流程
原始文档 → 文本清洗 → 智能分块 → 向量化 → 元数据绑定 → 索引构建 → 入库各阶段要点：
-
分块（Chunking）
- 按语义边界：比较段落、句子和多组固定长度候选
- 重叠策略：比较无重叠、短重叠和较长重叠，验证边界召回与冗余成本
- 特殊处理：代码按函数/类分割，Markdown按标题层级分割
-
向量化
- 批量推理，GPU加速
- 归一化向量（便于余弦相似度计算）
-
元数据关联
{ "vector": [...], # 稠密向量 "sparse_vector": {...}, # 可选，BM25权重 "metadata": { "doc_id": "xxx", "chunk_index": 3, "source": "技术规范_v2.pdf", "timestamp": "2024-01-15" } } -
索引与入库
- 小数据量：Flat（精确搜索）
- 大规模：HNSW（高召回）或 IVF（内存友好）
- 混合检索：稠密向量 + 稀疏向量（如BGE-M3的unified embedding）
生产注意： 建立版本管理机制，模型更新时需全量重刷向量。
学习建议
建议系统学习该知识点
换一种问法，检查是否真正理解
场景切入
假设你在做电商客服的RAG系统，用户问的退货政策需要从一堆文档里找。你会怎么选文本嵌入模型？是把整段政策文本直接存向量，还是先分块？具体流程走一遍看看。
层层追问
RAG里文档检索那步，文本嵌入模型怎么挑？……如果文档特别长或者多语言呢？……选好模型后，原始文本怎么处理成向量存进数据库？每一步的关键点是什么？
直球架构
在RAG系统中，根据任务需求选择文本嵌入模型的策略是什么？文本chunk向量化后存入向量数据库的完整流程，从分块到索引构建，详细说一下。
练习口述回答 · 约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和延迟，通过才切换。
说到混合检索，其实还有个权衡：什么时候用稠密向量，什么时候用稀疏向量？比如订单号检索，稀疏向量或者关键词匹配更准；而意图理解，稠密向量更好。，但重排会增加延迟，所以需要根据业务场景做取舍。