text-embedding-3-large is the high-precision variant among OpenAI's third-generation text embedding models. It converts natural language and code into numerical vectors for semantic search, knowledge base retrieval, and text clustering. It provides full representations of up to 3072 dimensions and also supports reduced dimensions, making it suitable for targeted trade-offs between retrieval quality and index size rather than directly generating chat responses.
Clarify capacity, inputs and outputs, and invocation methods before selecting a model.
Vector dimensions are native model specifications; input organization, batch item count, and response encoding fall within the scope of this platform's embedding API.
Learn what text-embedding-3-large can bring to your work.
The model converts text content into computable conceptual representations, so retrieval does not have to rely only on whether keywords match exactly. Questions, passages, and code descriptions can each be converted into vectors and then compared for similarity by a retrieval system. It provides the representations, while document ranking, filtering, and final answers are handled by the application workflow.
In multilingual retrieval and English task evaluations at launch, large achieved higher average scores than the same-generation small and the previous-generation ada-002. For multilingual knowledge bases, queries with varied phrasing, or content that requires distinguishing between similar topics, it can be considered a quality-first candidate, then validated with real queries.
Full vectors provide representations of up to 3072 dimensions, and the output can also be shortened through dimensions. Shorter vectors can reduce the burden of vector storage and similarity calculations, but may sacrifice some accuracy. When an existing vector database has dimensional constraints, test a shortened configuration first rather than immediately replacing the entire embedding model.
Start with specific tasks to find where the model can be effective.
Split product manuals, operating procedures, and frequently asked questions into text passages, generate vectors in batches, and store the corresponding document locations. When users ask questions, use the same model and dimensions to generate vectors for the questions, retrieve relevant passages, and pass them to an answer model. The deliverable is a searchable content index, not an answer written directly by the embedding API.
For help centers or research repositories containing materials in different languages, convert titles, summaries, and body excerpts into vectors to establish a foundation for semantic retrieval. Before launch, prepare representative queries in each language and check whether relevant content appears among the candidate results; then combine filters for language, product, and time to create a usable search list.
Input ticket descriptions, user feedback, or code descriptions to obtain a corresponding vector for each item, for use in subsequent clustering and similarity analysis. This can help identify feedback on closely related topics, potentially duplicate content, and related technical documentation. Final category labels and duplicate determinations should be confirmed by business rules or manual spot checks rather than by directly reading vector values.
Choose based on task complexity, input materials, and expected results.
text-embedding-3-small is geared more toward efficient applications, while large is better suited for tasks that prioritize retrieval quality. Do not replace all indexes just because the model is larger: first fix the corpus, queries, and retrieval workflow, compare recall of relevant documents, then evaluate vector size and computational burden. If small already meets your needs, keep it; if difficult cases remain common, test large.
Compared with text-embedding-ada-002, large offers stronger published benchmark performance and native dimension shortening capabilities. The official documentation also provides an example in which large's 256-dimensional representation surpasses full ada-002 on MTEB. When migrating, regenerate document and query vectors, and standardize the model and dimensions; you cannot simply change the query-side model while continuing to use the old index.
From a small-scale task to production integration.
Define the goal, required inputs, and output requirements, using real business examples as a starting point.
Open the trial page, confirm the parameters supported by this entry point, then submit a small-scale task to review the results.
Keep the full model ID, use the request format specified in the documentation, and confirm billing rules on the Pricing page.
Example inputs and validation methods to help you design your first trial.
An example query is “How do I grant project access to a new team member?”. The candidate passages describe “adding project members and setting roles” and “migrating a caching service,” respectively. Encode the query and candidate texts as vectors, then calculate similarity to rank them, while retaining the document ID and original text corresponding to each vector.
Check whether relevant passages rank near the top, and use multiple real business queries to check for false positives and missed results. Vectors are only retrieval inputs; the application must also manage indexing, similarity calculation, and original-text display. Keep the same model and dimension settings for indexing and querying to avoid comparing incompatible vectors.
Before formal use, understand the output quality and scope of capabilities.
Answers to common questions about using text-embedding-3-large.
It cannot generate answers directly. It converts questions and document chunks into vectors, helping the retrieval system find relevant content. A complete question-answering workflow typically retrieves relevant passages first, then uses a generative model to compose a response; the embedding returned by the embeddings API is not itself an answer and does not include an explanation.
When quality is the priority, you can start with the full dimensions; if your vector database has dimension limits or the index is large, you can test a reduced configuration. The official examples provide 1024-dimensional and 256-dimensional options, but the specific trade-off should be determined using your own query set after comparing recall performance and storage overhead.
At release, large performed better on average in multilingual retrieval and English task evaluations, making it suitable for applications with higher retrieval quality requirements. small is geared toward efficiency. It is recommended to compare them using the same corpus and real queries, focusing on difficult cases rather than deciding based only on the model name.
You can place multiple non-empty texts in the input array to generate multiple vectors in one request. In the response data, each item contains an index and embedding, which can be used to associate it with the original input. When saving vectors, you should also save the document identifier, chunk position, and dimensions used to facilitate later retrieval.
float returns a numeric array by default, suitable for directly integrating with programs or vector databases that require numeric vectors. base64 returns an encoded string, suitable for systems that already have a corresponding decoding workflow. They change the return representation, not the embedding task, and do not replace dimensions-based dimensionality control.
Model information · Updated: 2026-10-01. For request parameters and billing rules, see the API and pricing sections.
Start with clear goals and evaluate whether it suits your work based on real results.
This is only a basic call example. See the full docs for more parameters and advanced usage.
View Docs