logo

Embeddings

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

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

OpenAI 标识

这页适合谁?

  • 准备做 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. 典型用法

语义检索(最常见)

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

简化流程示例

import numpy as np

def cosine_sim(a, b):
    return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

实战落地顺序(读者导向)

  1. 先用 text-embedding-3-small 建立最小可用检索链路。
  2. 再优化分块策略(chunk size / overlap)提升召回质量。
  3. 最后才切换更大模型做 A/B,对比收益是否覆盖成本。

5. 选型建议

  • text-embedding-3-small:性价比高,适合大多数检索场景。
  • text-embedding-3-large:精度更高,适合对检索质量要求高的场景。

6. 常见注意事项

  • 文本过长时先分块(chunking)。
  • 对检索库进行向量归一化,便于相似度计算。
  • 为向量库设置合适的维度与索引类型。

再补一个很常见的误区:不要一开始就纠结 small 还是 large,先把分块和召回做对。很多检索差,并不是 embedding 模型不够强,而是文档组织方式本身就有问题。

真要排优先级,我会把它排成这样:分块策略第一,过滤条件第二,向量模型第三。顺序反过来,通常只会多花钱。

一句轻松总结:
向量化不是魔法棒,更像“给知识库装 GPS”。
路线规划(分块、索引、过滤)没做好,再好的地图也会带你绕远路。

参考资料

OpenAI API Guide
AI Engineer

OpenAI API Guide

Build with the OpenAI API using Responses API, streaming, tools, embeddings, and multimodal inputs.

OpenAI API GuideEmbeddings

Embeddings

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

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

OpenAI 标识
OpenAI 标识

#这页适合谁?

  • 准备做 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. 典型用法

#语义检索(最常见)

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

#简化流程示例

python
import numpy as np def cosine_sim(a, b): return np.dot(a, b) / (np.linalg.norm(a) * np.linalg.norm(b))

#实战落地顺序(读者导向)

  1. 先用 text-embedding-3-small 建立最小可用检索链路。
  2. 再优化分块策略(chunk size / overlap)提升召回质量。
  3. 最后才切换更大模型做 A/B,对比收益是否覆盖成本。

#5. 选型建议

  • text-embedding-3-small:性价比高,适合大多数检索场景。
  • text-embedding-3-large:精度更高,适合对检索质量要求高的场景。

#6. 常见注意事项

  • 文本过长时先分块(chunking)。
  • 对检索库进行向量归一化,便于相似度计算。
  • 为向量库设置合适的维度与索引类型。

再补一个很常见的误区:不要一开始就纠结 small 还是 large,先把分块和召回做对。很多检索差,并不是 embedding 模型不够强,而是文档组织方式本身就有问题。

真要排优先级,我会把它排成这样:分块策略第一,过滤条件第二,向量模型第三。顺序反过来,通常只会多花钱。

一句轻松总结:
向量化不是魔法棒,更像“给知识库装 GPS”。
路线规划(分块、索引、过滤)没做好,再好的地图也会带你绕远路。

#参考资料

System Design

Core system design concepts and practical case studies

Learn the trade-offs and patterns that matter in technical interviews.

Open System Design →

Related Roadmaps