Embeddings
如果你准备做 RAG 或语义检索,Embeddings 仍然是最基础的一层。很多团队会把注意力都放在聊天模型上,但真正决定检索质量下限的,往往是向量化、分块和召回链路。
我见过不少项目一开始就急着换更贵的模型,最后才发现问题根本不在模型,而在文档切得太碎,或者切得太粗。
这页适合谁?
- 准备做 RAG / 语义检索的工程师
- 想做推荐系统或文本去重的算法同学
- 需要在成本和效果之间做平衡的技术负责人
1. Embeddings 真正解决什么问题
它不是“让模型更聪明”,而是让文本能进入可计算的相似度空间。这个区别很重要。因为一旦进入工程实现,你优化的对象通常不是 prompt,而是:
- 文档怎么切块
- 查询怎么向量化
- 相似度怎么算
- 过滤条件怎么叠加
2. 基础调用(Python)
from openai import OpenAI
client = OpenAI()
response = client.embeddings.create(
model="text-embedding-3-small",
input="这是一段需要向量化的文本"
)
embedding = response.data[0].embedding
print(len(embedding))
3. Node.js 示例
import OpenAI from 'openai';
const client = new OpenAI();
const response = await client.embeddings.create({
model: 'text-embedding-3-small',
input: '这是一段需要向量化的文本'
});
const embedding = response.data[0].embedding;
console.log(embedding.length);
4. 典型用法
语义检索(最常见)
- 把文档分块并生成向量。
- 用户查询生成向量。
- 计算相似度并返回最接近的文档块。
简化流程示例
import numpy as np
def cosine_sim(a, b):
return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))
实战落地顺序(读者导向)
- 先用
text-embedding-3-small建立最小可用检索链路。 - 再优化分块策略(chunk size / overlap)提升召回质量。
- 最后才切换更大模型做 A/B,对比收益是否覆盖成本。
5. 选型建议
- text-embedding-3-small:性价比高,适合大多数检索场景。
- text-embedding-3-large:精度更高,适合对检索质量要求高的场景。
6. 常见注意事项
- 文本过长时先分块(chunking)。
- 对检索库进行向量归一化,便于相似度计算。
- 为向量库设置合适的维度与索引类型。
再补一个很常见的误区:不要一开始就纠结 small 还是 large,先把分块和召回做对。很多检索差,并不是 embedding 模型不够强,而是文档组织方式本身就有问题。
真要排优先级,我会把它排成这样:分块策略第一,过滤条件第二,向量模型第三。顺序反过来,通常只会多花钱。
一句轻松总结:
向量化不是魔法棒,更像“给知识库装 GPS”。
路线规划(分块、索引、过滤)没做好,再好的地图也会带你绕远路。