什么是 embedding?把语义变成数字

Embedding 是一串数字 — 通常 256 到 3,072 个 — 用来代表一段文字的「意思」。神奇之处不在任何单一数字,而是意思相近的文字会产生相近的数字串。一旦能把「意思」当成数字比对,你就能做语义搜索、RAG、推荐、去重、聚类 — 所有「需要 AI 但不到要 LLM」的功能。

具体上,embedding 长什么样

喂一句话进 embedding 模型,它回一个向量。例如 OpenAI 的 text-embedding-3-small 会回 1,536 个数字,像:

[0.012, -0.041, 0.087, -0.003, ..., 0.022]

单一数字对人没意义。重点是:两句意思相近的话,embedding 出来的向量会指向相近方向。「How do I reset my password?」跟「I forgot my login」会有高 cosine similarity(接近 1.0)。「How do I reset my password?」跟「What's the weather in Tokyo?」相似度低(接近 0)。

之所以能做到,是因为 embedding 模型被训练(在巨大文本数据集上)把相近意思 map 到高维空间相近的区域。训练目标就是把相关文本推近、无关推远。

Embedding 实际在做什么用途

**语义搜索。**把所有文档切块、每块 embed、存进向量数据库。用户搜索时,把查询 embed,找最接近的块。即使查询用不同字眼,也能找到相关文档。RAG 的核心引擎。

**推荐系统。**把用户行为 embed(读过的文章、看过的商品)。找 embedding 相近的用户或商品。轻量「more like this」,不必复杂 ML。

**去重。**把数据库每条 embed,找相似度 > 0.95 的配对,大概是重复。清客户名单、客服工单、商品列表很好用。

**分类。**把每个类别的标注样本 embed,新项目用「最接近哪个类别的 embedding」分类。比 fine-tune 分类器便宜的替代。

**聚类(clustering)。**对一批 embedding 跑 k-means 或 DBSCAN 把相关项目分组。客服工单分流、内容主题探勘很好用。

该用哪个 embedding 模型

2026 年实用选项:

OpenAI text-embedding-3-small — 便宜(每百万 tokens 约 $0.02)、1,536 维、质量不错、英文强。默认可选。
OpenAI text-embedding-3-large — 质量更好、3,072 维、约 3 倍价钱。要准确时用。
Voyage AI voyage-3 / voyage-3-large — 前沿等级质量,稍贵于 OpenAI,检索常常是最好。
Cohere embed-english-v3 / embed-multilingual-v3 — 多语言强;非英文内容选 multilingual 版。
BGE(智源研究院)M3 / BGE-large — 开放权重、可自架、顶级质量。中文最强的选项之一。
gte-large、e5-large — 其他开放权重,比 BGE 轻。

如果是中文为主的内容:BGE-M3 跟 Cohere multilingual v3 明显赢 OpenAI。非英文不要傻傻默认 OpenAI。

Embedding 怎么存怎么搜

1,536 维向量约 6KB。一百万个 chunk 就是 6GB 加 overhead。暴力比相似度(每查询 O(n))在 ~10 万向量以上就会慢爆。

这正是 vector database 解决的问题:索引结构(HNSW、IVF)用 O(log n) 之类的复杂度找近似最近邻。2026 年选项:

pgvector — Postgres extension,在一般 Postgres(包括 Supabase)就能用。大多数 app 的最佳默认,因为数据都在同一个 DB。
Pinecone — 托管、容易 scale、稍贵。需要超高吞吐量或不想 ops 时用。
Qdrant — 开源、Rust、性能好,可自架或用云。
Weaviate、Chroma、Milvus — 同个赛道其他选项。
DuckDB / SQLite 向量扩展 — 小数据(< 1000 万条)。

刚起步的 app 90% 用 pgvector 就对。

常见错误

**Embed 错的单位。**整份 50 页文档 embed 出来是糊的 — 意思太密无法压缩。先切块(通常每块 250-500 tokens),每块各自 embed。检索是 per-chunk 不是 per-document。

**混用 embedding 模型。**你 store 里所有 embedding 必须来自同一个模型。换模型等于要全部重 embed。请事先规划。

**忘记归一化。**很多相似度公式假设单位长度向量。现代 API 多半回传已归一化;没有的话,存之前归一化。

**把相似度分数当准确度。**0.85 cosine similarity 不等于「85% 相关」。经验式 review 结果定阈值,不要凭感觉。

什么时候不要用 embedding

完全匹配的查询。「找 product_id = 12345 的行」应该是 SQL WHERE,不是向量搜索。Embedding 是给模糊语义比对。
**小语料。**如果只有 50 份文档,全塞进 context window 让 LLM 读就好。Embedding 有 setup 成本(切块、embed、索引),少于 ~1,000 个 chunk 划不来。
**高度结构化数据。**SQL 或 JSON 查询在有明确 schema 的数据(财务、库存、user metadata)上赢 embedding。
**要关键字也要语义的场合。**纯向量搜索会漏掉关键字精确匹配(产品代号、名字)。用 hybrid search(BM25 + 向量)效果最好。