All models

text-embedding-3-large

OpenAIEmbedding
Input 0.182 Credits / 1M
Get your API key
text-embedding-3-large

面向多语言语义检索的高精度文本向量模型

text-embedding-3-large 是 OpenAI 第三代文本嵌入模型中的高精度型号,可将自然语言与代码转成数值向量,用于语义搜索、知识库检索和文本聚类。它提供最高 3072 维的完整表示,也支持缩短维度,适合在检索质量与索引体积之间做有针对性的取舍,而不是直接生成聊天答案。

OpenAI模型品牌
向量模型类型
向量任务能力

规格与接口特性

在选型前明确容量、输入输出与调用方式。

原生完整维度
最高 3072 维;不设置 dimensions 时默认输出完整维度
维度控制
支持 dimensions 缩短向量,官方示例包括 1024 维与 256 维
输入形式
非空文本、文本数组、token 整数数组或 token 序列批次
批次项数
文本数组或 token 序列批次最多 2048 项
输出编码
float 数值数组或 base64 字符串,默认 float
调用入口
POST /openai/embeddings;model 使用 text-embedding-3-large
返回信息
逐项 embedding 与 index,并返回 model、usage 和 created

向量维度属于模型原生规格;输入组织、批次项数与返回编码属于本平台嵌入接口的调用范围。

核心能力

了解 text-embedding-3-large 能为你的工作带来什么。

围绕语义建立检索关联

模型把文本内容转换为可计算的概念表示,让检索不必只依赖关键词是否完全相同。问题、段落和代码说明可以分别生成向量,再交给检索系统比较相似性。它负责提供表示,文档排序、过滤与最终答案则由应用流程完成。

更适合重视多语言质量的任务

在发布时的多语言检索与英文任务评测中,large 的平均成绩均高于同代 small 和上一代 ada-002。对于多语言资料库、表达方式多样的查询,或需要区分相近主题的内容,可将它作为质量优先的候选,再用真实查询验证效果。

用维度调节索引规模

完整向量提供最高 3072 维表示,也可以通过 dimensions 缩短输出。较短向量能够减少向量存储及相似度计算的负担,但可能牺牲部分精度。已有向量库存在维度约束时,可先测试缩短配置,而不是立即更换整个嵌入模型。

适用场景

从具体任务出发,找到模型发挥作用的位置。

企业知识库的检索层

把产品手册、操作规范和常见问题拆成文本段落,批量生成向量并保存对应文档位置。用户提问时,对问题使用同一模型与维度生成向量,检索相关段落后交给回答模型。交付物是可检索的内容索引,而非嵌入接口直接写出的答案。

多语言资料的统一搜索

面向包含不同语言资料的帮助中心或研究库,将标题、摘要和正文片段转成向量,建立语义检索基础。上线前准备各语言的代表性查询,检查相关内容能否进入候选结果;随后结合语言、产品和时间筛选,形成可用的搜索列表。

反馈归类与相似内容发现

输入工单描述、用户反馈或代码说明,获得逐条对应的向量,供后续聚类和相似度分析使用。可据此发现主题接近的反馈、潜在重复内容及相关技术说明。最终分类标签和重复判断应由业务规则或人工抽检确认,而非直接读取向量数值。

如何选择这个模型

结合任务复杂度、输入材料与预期结果选择。

与 small 的取舍:先确定质量目标

text-embedding-3-small 更偏向高效应用,large 更适合把检索质量放在优先位置的任务。不要只因型号更大就替换所有索引:先固定语料、查询和检索流程,对比相关文档召回情况,再评估向量体积与计算负担。若 small 已满足需求,可保留;若难例仍多,再测试 large。

从 ada-002 迁移:重新设计向量配置

与 text-embedding-ada-002 相比,large 提供更强的发布评测表现和原生维度缩短能力。官方还给出了 large 的 256 维表示在 MTEB 上超过完整 ada-002 的示例。迁移时应重新生成文档与查询向量,并统一模型和维度;不能仅修改查询端型号,就继续沿用旧索引。

开始使用

从一次小规模任务到正式接入。

01

准备任务与材料

明确目标、必要输入与输出要求,使用真实业务样例作为起点。

02

在 API 调试区试用

打开试用页,确认此入口支持的参数,再提交小规模任务查看结果。

03

按 API 文档接入

保留完整模型 ID,使用文档规定的请求格式,并在 Pricing 页确认计费规则。

使用边界

在正式使用前,了解输出质量与能力范围。

  • 它是嵌入模型,不是聊天、翻译或摘要生成模型。返回的是数值表示,不能直接作为可读答案或分类理由;知识库问答仍需要检索逻辑和回答模型配合,也不会因为生成了向量就自动完成文档搜索。
  • 缩短维度不是无损压缩,完整向量也不代表所有任务都能获得最佳检索结果。选择维度时应同时评估相关内容召回与索引规模;文档端和查询端需保持一致配置,不应混合不同模型生成的向量进行比较。
  • 批次最多 2048 项是输入条目约束,不等于每条文本可以任意长。长文档宜先拆分为语义完整的段落,空文本应清理;PDF、图片或音频需要先提取成文本,不能作为这些文本输入形式直接提交。

常见问题

解答使用 text-embedding-3-large 时的常见疑问。

text-embedding-3-large 能直接回答知识库问题吗?

不能直接生成答案。它将问题和文档片段转成向量,帮助检索系统找到相关内容。完整问答流程通常先取回相关段落,再由生成模型组织回答;嵌入接口返回的 embedding 本身不是答案,也不附带解释。

应该使用完整 3072 维,还是缩短维度?

质量优先时可以从完整维度开始;向量库有维度限制或索引体积较大时,可测试缩短配置。官方提供了 1024 维和 256 维示例,但具体取舍应依据自己的查询集,比较召回效果与存储负担后确定。

为什么要选择 large,而不是 text-embedding-3-small?

large 在发布时的多语言检索和英文任务评测中平均表现更高,适合检索质量要求较高的应用。small 偏向高效选择。建议用相同语料和真实查询进行对比,重点检查难例,而不是仅根据型号名称决定。

批量输入后,怎样对应每一条结果?

可将多条非空文本放入 input 数组,一次请求生成多项向量。响应的 data 中,每项包含 index 与 embedding,可据此关联原始输入。保存向量时也应保存文档标识、片段位置和所用维度,方便后续检索。

float 和 base64 应该如何选择?

float 默认返回数值数组,适合直接接入需要数字向量的程序或向量库。base64 返回编码字符串,适合已有对应解码流程的系统。两者改变的是返回表示方式,不是嵌入任务,也不会替代 dimensions 的维度控制。

模型资料 · 更新日期:2026-10-01。调用参数与计费规则请查看 API 和定价栏目。

把 text-embedding-3-large 用到你的下一项任务

从清晰的目标开始,在实际结果中判断它是否适合你的工作。