在很多 RAG 系统里，有一个默认假设：
只要语义“相似”，就能找到“正确答案”。
但如果你真的做过系统，很快就会发现一个问题：
很多“很相似”的内容，其实一点都不相关。
一、从一个错误开始
假设用户问：
“公司的报销流程是什么？”
Embedding 检索返回：
- “费用审批制度说明”
- “预算管理规范”
- “财务报表解读”
这些内容：
看起来都“相关”
但没有一个是“真正答案”
二、Embedding 到底在做什么？
很多人理解为：
“把文本转成向量”
但更本质的理解是：
把语义“投影”到向量空间中。
可以抽象成：
文本 → 语义压缩 → 向量空间坐标
关键点：
- 这是一个降维过程
- 也是一个有损过程
三、一个直观理解（非常关键）
你可以把 Embedding 想象成：
把复杂语义，压缩成一个“位置”。
语义空间示意
在这个空间中：
- 距离近 → 相似
- 距离远 → 不相似
但问题来了：
“近”不代表“对”。
四、为什么会出现“相似但不相关”？
核心原因有三个。
1. 语义压缩导致信息丢失
Embedding 不会保留全部信息：
- 细节被丢掉
- 结构被弱化
- 关系被模糊
举个例子：
“报销流程”
“费用审批”
“预算控制”
在向量空间中：
可能会被压得很近。
但实际：
报销流程 ≠ 预算控制
2. 模型只学“统计共现”，不是“逻辑关系”
Embedding 模型本质上学的是：
哪些词经常一起出现。
而不是：
它们之间的因果关系 / 逻辑关系
所以：
- “医生” 和 “医院” → 很近
- “报销” 和 “审批” → 很近
但：
并不代表它们能互相替代
3. Query 本身是模糊的
用户输入往往：
- 简短
- 不完整
- 带歧义
例如：
“报销流程”
可能指：
- 差旅报销
- 日常费用
- 特殊审批流程
Embedding 无法判断真实意图
五、中文 Embedding 为什么更难？
这一点很多人没意识到，但非常关键。
原因：
1. 分词不稳定
- 英文：天然有空格
- 中文：需要分词
问题在于：
向量就错了
2. 语义更依赖上下文
例如：
- “审批通过”
- “通过审批”
顺序不同，含义可能不同。
但 embedding 可能认为接近
3. 训练数据差异
- 英文语料更多
- 中文领域数据更碎片化
结果：
中文 embedding 更容易“漂”
六、Embedding 模型怎么选？（工程重点）
常见模型类型
1. 通用模型
特点：
- 适配广
- 泛化强
但：
- 行业理解弱
2. 领域模型
- 针对金融 / 医疗 / 企业
优点：
- 精准
缺点：
- 泛化差
工程建议：
不要拍脑袋选模型，要做评估。
七、如何评估 Embedding？（实战方法）
方法一：Recall@K
给定 Query：
看 Top-K 是否包含正确答案。
方法二：相似度对比
Query vs 正确文档 → 相似度 A
Query vs 干扰文档 → 相似度 B
理想情况：
A >> B
如果差距不明显：
说明 embedding 区分能力不足。
方法三：人工构造测试集（强烈推荐）
你可以：
- 收集 50~100 个真实问题
- 标注正确答案
- 对比不同模型
这一点如果你做了：
直接拉开和 90% 人的差距
八、一个关键优化：Query Rewrite
既然 Query 本身不可靠：
可以改写它
示例：
原始：
“报销流程”
改写：
“公司差旅报销的完整审批流程是什么？”
效果：
- 语义更明确
- 检索更稳定
九、再往前一步：多向量检索（高级）
一个 Query → 多个向量
Query
↓
多种表达
↓
多个 Embedding
↓
合并召回
作用：
- 提升 Recall
- 对抗语义偏差
十、重要认知
Embedding 不是在“理解语义”，
而是在“压缩语义并放入空间”。
收尾
如果你发现：
- 检索结果“看起来很像”
- 但总是“答不到点上”
那很可能不是模型问题，而是：
你的语义空间，本身就是“歪的”。
下一篇预告
下一篇我们进入核心：
检索系统设计：向量、ES、Hybrid 怎么选？
