Embeddings

如果你准备做 RAG 或语义检索，Embeddings 仍然是最基础的一层。很多团队会把注意力都放在聊天模型上，但真正决定检索质量下限的，往往是向量化、分块和召回链路。

我见过不少项目一开始就急着换更贵的模型，最后才发现问题根本不在模型，而在文档切得太碎，或者切得太粗。

#这页适合谁？

准备做 RAG / 语义检索的工程师
想做推荐系统或文本去重的算法同学
需要在成本和效果之间做平衡的技术负责人

#1. Embeddings 真正解决什么问题

它不是“让模型更聪明”，而是让文本能进入可计算的相似度空间。这个区别很重要。因为一旦进入工程实现，你优化的对象通常不是 prompt，而是：

文档怎么切块
查询怎么向量化
相似度怎么算
过滤条件怎么叠加

#2. 基础调用（Python）

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 示例

ts
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. 典型用法

#语义检索（最常见）

把文档分块并生成向量。
用户查询生成向量。
计算相似度并返回最接近的文档块。

#简化流程示例

python
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”。
路线规划（分块、索引、过滤）没做好，再好的地图也会带你绕远路。