Intfloat: E5-Large-v2

Intfloat: E5-Large-v2 is an embeddings model from Intfloat. It belongs to the embeddings category, which means its job is to turn text into vectors rather than to generate chat responses. The provider describes it as mapping English sentences, paragraphs, and documents into a 1024-dimensional dense vector space, with the aim of high-accuracy semantic embeddings. If your application needs a representation of text that captures meaning rather than a written answer, this is the kind of model you would reach for.

The model accepts text as its only input modality and produces embeddings as its only output modality. Its context length is 512 tokens, so each request is limited to a fairly short span of text, and the maximum output is 460. There is no image, audio, or other non-text input, and there is no generated prose on the output side. Everything the model returns is a vector, which you then store, compare, or feed into another stage of your pipeline.

Those characteristics point to a specific set of uses. Retrieval is the clearest one: embed your documents once, embed the query at request time, and compare vectors to find the closest passages. Semantic search works the same way, matching on meaning rather than exact keywords. The provider also lists reranking and similarity scoring, so you can use the vectors to reorder candidate results or to measure how close two pieces of text are. Because the vectors are 1024-dimensional and dense, they are well suited to storage in a vector index and to cosine or dot-product comparison.

You call the model through api14's OpenAI-compatible API using the model id "intfloat/e5-large-v2". Because the endpoint follows the OpenAI format, you can point an existing OpenAI client at api14 and send your text in the usual way, then read the embedding out of the response. The model supports no additional request parameters, so there is nothing beyond the standard request fields to configure. Keep each input within the 512-token context length, and expect the output to be the embedding itself.

The main constraint to plan around is that 512-token window. Long documents will need to be split into chunks before embedding, and you will have to decide how to combine or store those chunk vectors. The model is also English-focused per the provider description, so text in other languages may not embed as reliably. If your task is text generation, conversation, or anything that requires a written response, an embeddings model is the wrong tool and a generative model would fit better.