Embedding（向量嵌入）
把文本、图片等数据转成高维向量，让机器能通过向量距离衡量语义相似度——RAG、搜索、推荐的基础。
什么是 Embedding
Embedding（向量嵌入）是把文本、图片、音频等数据转换成一组数字（向量）的过程。这组数字保留了原始数据的语义信息——语义相近的内容，向量距离也近。
简单说：把"意思"变成"坐标"。
为什么需要 Embedding
计算机不能直接理解"猫和老虎比猫和桌子更像"。但如果把每个词映射到高维空间中的一个点，让"猫"和"老虎"的坐标接近、"猫"和"桌子"的坐标远离，计算机就能通过计算距离来判断语义相似度。
猫 → [0.21, -0.35, 0.88, ...] ← 768 维向量
老虎 → [0.19, -0.31, 0.91, ...] ← 与"猫"距离很近
桌子 → [-0.72, 0.55, -0.12, ...] ← 与"猫"距离很远
工作原理
1. 文本 → Token
先把文本切分成 token（与 LLM 一样的分词方式）。
2. Token → 向量
通过预训练的 Embedding 模型，把每个 token 映射到高维空间。
3. 聚合
把一段文本所有 token 的向量聚合成一个向量（通常用平均池化或特殊 CLS token）。
4. 存储 + 检索
把生成的向量存入向量数据库，查询时把问题也转成向量，找距离最近的。
常见 Embedding 模型
| 模型 | 维度 | 特点 | 价格 |
|---|---|---|---|
| OpenAI text-embedding-3-large | 3072 | 通用、稳定 | $0.13/M |
| OpenAI text-embedding-3-small | 1536 | 性价比高 | $0.02/M |
| BGE-large-zh-v1.5 | 1024 | 中文最佳（开源） | 免费 |
| Jina Embeddings v3 | 1024 | 多语言 | 免费（开源） |
| Cohere embed v4 | 1024 | 多语言+多模态 | $0.10/M |
| GTE-large | 1024 | 阿里出品（开源） | 免费 |
| voyage-code-3 | 1024 | 代码专用 | $0.18/M |
维度选择
- 512-768 — 精度低但速度快，适合大规模粗筛
- 1024 — 平衡，最常用
- 1536-3072 — 高精度，适合对召回质量要求高的场景
text-embedding-3 系列支持 Matryoshka：训练时就让前 N 维独立可用，需要时直接截断到 256 / 512 / 1024，不用重新 embed。省存储省检索时间。
相似度计算
两个向量之间的"距离"有几种计算方式：
| 方法 | 说明 | 适用 |
|---|---|---|
| 余弦相似度 | 最常用，衡量方向相似性 | 语义搜索（推荐） |
| 欧氏距离 | 衡量绝对距离 | 图像检索 |
| 点积 | 最快，但受向量长度影响 | 大规模检索（需归一化） |
推荐用余弦相似度，它对向量长度不敏感，适合文本语义匹配。
ANN 索引：百万向量怎么秒级查
数据量小时（< 10 万）暴力遍历就够。上百万级就必须用 ANN（Approximate Nearest Neighbor）索引：
| 索引 | 原理 | 适用 |
|---|---|---|
| HNSW | 多层图结构跳跃查找 | 通用首选，召回率最高 |
| IVF | 先聚类后局部搜索 | 上亿向量，内存敏感 |
| IVF-PQ | IVF + 乘积量化压缩 | 超大规模，能省 8-16x 内存 |
| Flat | 暴力扫描 | < 10 万向量，要求 100% 召回 |
经验值：100 万 1024 维向量，HNSW 单机能做到 <10ms 查询；上亿规模建议 IVF-PQ + 多机分片。
Chunk Size 的取舍
文档分块大小直接决定 RAG 质量，没有银弹，但有经验区间：
| chunk size | 优点 | 缺点 | 适合 |
|---|---|---|---|
| 128-256 token | 检索精度高 | 上下文不完整 | FAQ、短问答 |
| 512 token | 平衡，最常用 | — | 通用文档 |
| 1024 token | 上下文完整 | 检索精度下降 | 长文档、技术手册 |
| 整章/整页 | 语义完整 | 噪音多、贵 | Late Chunking 场景 |
重叠（overlap）一般设 chunk size 的 10-20%——避免关键句被切到两个 chunk 边界都丢失。
Late Chunking
新思路：先 embedding 整篇文档，然后再切。让每个 chunk 的向量保留全文上下文。Jina v3 等模型原生支持，对长文档效果显著优于先切后 embed。
混合检索：BM25 + 向量
纯向量检索有死角——人名、型号、错别字、罕见专业术语，关键词匹配往往更准。生产 RAG 几乎都用混合检索：
query
├→ BM25 检索 → 候选集 A（关键词命中）
├→ Vector 检索 → 候选集 B（语义命中）
↓
RRF / 加权融合 → top-K 候选
↓
Reranker 二阶段排序 → 最终 top-N
↓
喂给 LLM
经验值：BM25 和向量按 0.5 / 0.5 加权融合就能比纯向量提升 5-15% 召回率。
Reranker：二阶段排序
向量检索快但粗。Reranker（Cross-Encoder） 慢但准——把 query 和每个候选一起输入模型，输出相关性分数。流程：
- 向量检索召回 top-100
- Reranker 重排 top-100 → top-10
- top-10 喂给 LLM
主流 Reranker：BGE-reranker-v2、Cohere Rerank 3、Jina Reranker v2。Reranker 是 RAG 最高 ROI 的优化点之一，加一步通常能让最终答案质量提升 10-20%。
应用场景
1. RAG（检索增强生成）
RAG 的核心步骤就是 Embedding：
- 把知识库文档全部 Embedding → 存入向量数据库
- 用户提问 → Embedding → 在向量数据库找最相似的文档片段
- 把文档片段 + 问题一起发给 LLM → 生成回答
2. 语义搜索
传统搜索靠关键词匹配，搜"手机"找不到"智能手机"。语义搜索用 Embedding，搜"手机"能找到"移动通信设备"。
3. 推荐系统
把用户行为和内容都 Embedding，推荐与用户向量最近的内容。
4. 去重与聚类
把文档 Embedding 后聚类，相似文档自动归为一类。用于：
- 新闻去重
- 文档分类
- 知识图谱构建
向量数据库
| 数据库 | 特点 | 适用场景 |
|---|---|---|
| Chroma | 轻量、Python 原生 | 原型开发 |
| Qdrant | Rust 高性能、支持过滤 | 生产环境 |
| Milvus | 分布式、亿级向量 | 企业级 |
| Pinecone | 托管 SaaS、免运维 | 快速上线 |
| pgvector | PostgreSQL 扩展 | 已有 PG 的项目 |
| Weaviate | 内置多模态 | 多模态搜索 |
| libsql / sqlite-vec | SQLite 扩展 | 嵌入式 / 边缘部署 |
批量 Embedding 的成本优化
百万级文档全量 embed 一次很贵。三招省钱：
- 批量 API——OpenAI / Cohere 都有 batch API，价格直接打五折，24 小时内出结果。
- 本地开源模型——BGE、GTE 在一张 4090 上跑 100 万段文本只要几小时，电费可忽略。
- 增量更新——文档没变就别重新 embed，加 hash 去重。
常见问题
Q: Embedding 维度越高越好吗
不是。高维度带来更高精度，但也带来更大存储和更慢检索。768-1536 维对大多数场景够用。
Q: 不同语言的 Embedding 能互相对比吗
可以，前提是用了多语言 Embedding 模型（如 BGE-m3、Jina v3）。这样中文"猫"和英文"cat"的向量距离会很近。
Q: Embedding 能理解代码吗
专门的代码 Embedding 模型（如 voyage-code-3、jina-embeddings-v2-code）可以。通用 Embedding 模型对代码的语义理解有限——会把所有 import os 都判定为高度相似。
Q: 换 Embedding 模型要重新跑全库吗
是。向量空间不通用，不同模型生成的向量不能混用。这也是为什么生产环境上选模型要慎重——重新 embed 一次百万级文档不便宜。
延伸阅读
- 应用架构：RAG（检索增强生成）
- 上下文组装：Context Engineering
- 计费基础：Token