BAAI: bge-large-en-v1.5

BAAI bge-large-en-v1.5 is an embedding model from BAAI, the Beijing Academy of Artificial Intelligence. It sits in the embeddings category rather than the chat category, which means it does not generate conversational text. Instead, it turns text into vectors that you can store, compare, and search over. The model was released by the provider on 2025-11-18.

The model takes English text as input and produces embeddings as output. It maps English sentences, paragraphs, and documents into a 1024-dimensional dense vector space, with the goal of high-fidelity semantic embeddings. The context window is 512 tokens, and the maximum output is 460. Because the input is text only and the output is a vector, there is no generated prose to read or parse; you get numeric representations of meaning that downstream systems can work with.

Those characteristics point to a fairly specific set of uses. Semantic search is the obvious one: embed your documents once, embed the query at request time, and rank by vector similarity. Document retrieval and retrieval-augmented generation pipelines fit the same pattern, where the embedding model handles recall and a separate generation model handles the answer. The model is also suited to downstream NLP tasks that consume embeddings, such as clustering, deduplication, classification features, and similarity comparison between sentences or paragraphs. Anything that needs a compact numeric representation of English text is a candidate.

You call it through api14's OpenAI-compatible API using the model id "baai/bge-large-en-v1.5". Because the endpoint follows the OpenAI embeddings shape, you send your text in the input field and receive a vector back in the response. The model lists no supported parameters, so there is nothing to tune beyond the model id and the input itself; do not expect options like temperature or top_p to apply here, since those belong to generation models. Keep each input within the 512 token context window, and note the maximum output of 460.

The main constraint to plan around is that 512 token window. Long documents need to be split into chunks before embedding, and chunking strategy will affect retrieval quality more than anything else you control. If your task requires generating text rather than representing it, this is the wrong model and you should look at a chat or completion model instead. If your text is not English, the model's stated focus on English means you should check whether it fits before committing.