Embedding 算法三代演进：从 Word2Vec 到 BGE，RAG 检索为什么必须用第三代

文章目录

• • 前言
  • 一、为什么 Embedding 算法需要一代代演进
  • 二、第一代：静态词向量——Word2Vec / GloVe / FastText
  • • 1. Word2Vec：开山之作
    • 2. GloVe：更系统的全局视角
    • 3. FastText：解决 OOV 的工程救星
    • 4. 第一代的致命缺陷：静态
  • 三、第二代：上下文相关向量——ELMo / BERT
  • • 1. ELMo：第一个实用的上下文 Embedding
    • 2. BERT：更强的语义理解，但检索场景用不了
  • 四、第三代：句子级对比学习 Embedding——SBERT / SimCSE / BGE
  • • 1. SBERT：用 bi-encoder 解决检索速度问题
    • 2. SimCSE：用对比学习把向量空间「撑开」
    • 3. BGE：中文 RAG 场景的首选
    • 4. 三代演进一张表总结
  • 五、RAG 检索选型：为什么第三代是标配
  • • 选型决策树
  • 六、什么场景下该用 Reranker 而不是只靠 Embedding
  • 七、给做 RAG 项目的工程师几条实战建议
  • • 1. 不要在 Embedding 选型上花太多时间
    • 2. 文档切分比 Embedding 模型更影响检索质量
    • 3. 评估指标要同时看召回率和 MRR
    • 4. 向量数据库选型看两个硬指标
    • 5. 别忘了做 A/B 测试
  • 总结

前言

做 RAG 项目的工程师，大概率都会在某个时刻被问到一个问题——“你们用的什么 Embedding 模型？” 大部分人的第一反应是\”Word2Vec\”或者\”BERT\”，说完就觉得自己答上来了。

但这里面有个很致命的认知盲区：Word2Vec 的每个词只有一个固定向量，\”吃苹果\”和\”苹果手机\”里的\”苹果\”在向量空间里完全重合；BERT 虽然能根据上下文给\”苹果\”不同的向量，但拿它做语义检索时，查询和每条文档都得两两拼接跑一遍，百万级知识库直接变成百万次推理，用户根本等不起。

Embedding 算法不是一步到位的，它经历了三代演进——每一代都在补上一代挖的坑。搞不清楚这三代的演进逻辑，你在 RAG 项目里做的 Embedding 选型大概率是盲选。

这篇文章从一个做检索系统架构的视角，把 Embedding 算法三代演进的底层逻辑彻底拆清楚——不背术语，讲清楚每代方案解决了什么、留下了什么坑、为什么下一代不得不这么设计。

读完这篇文章，你能搞明白：

• 第一代静态词向量为什么处理不了多义词，FastText 是怎么兜住 OOV 的
• 第二代 BERT 为什么语义理解强但在检索场景完全用不了
• 第三代 SBERT / SimCSE / BGE 的核心设计——bi-encoder + 对比学习到底好在哪
• RAG 场景下 Embedding 选型的实操标准
• 什么时候该加 Reranker、什么时候不需要

不管你是正在做 RAG 项目需要做 Embedding 选型的工程师，