BGE-M3 is BAAI’s multilingual retrieval model designed around three kinds of versatility: multiple retrieval functions, multiple languages and different input lengths. The manufacturer documents support for more than one hundred languages and inputs up to 8192 tokens. Its unified model can provide dense vectors, sparse lexical weights and multi-vector representations, so a retrieval design can select or combine more than one kind of evidence.
Dense mode maps a text to a single 1024-dimensional vector. It supports comparison of the meaning represented by a query and a passage. Sparse mode assigns weights to the tokens present in the text for lexical matching. Multi-vector mode represents a text with several vectors and uses a ColBERT-style interaction to compare the query and document at a finer level.
These outputs have different roles in a search index. A dense vector provides one representation for a passage; a sparse token-weight map retains lexical signals; multiple vectors provide a different comparison structure. The producer examples show returning the selected representations and computing scores for text pairs. Treat the chosen representation and scoring method as a deliberate part of the retrieval task.
BGE-M3 does not require adding the retrieval instruction used by earlier BGE models. Prepare the query and the actual source passages directly. A multilingual knowledge collection can retain each passage in its original language, with its document identifier and locale. Use real user questions from the intended language mix when checking the results.
A practical task is to search policy explanations, product help or technical documentation held in several languages. Retain names, model numbers and terms that matter to the question. A lexical representation can help preserve matching on those terms, while a dense representation supplies semantic evidence. The retrieved passage should include the text and source location that a reader can inspect.
The 8192-token input window allows the model to represent material from short sentences through longer documents. Choose the granularity around the answer the search should return. A complete section can preserve a definition and its exceptions; a smaller passage can make a specific instruction easier to locate. A long window makes those choices possible, but the vector remains associated with the material actually encoded.
Keep each passage linked to its parent document and version. For a lengthy report, preserve the heading and surrounding explanation of the relevant figure or conclusion. Do not rely on a search hit’s title alone when the evidence is in the body. If the source changes, retain enough metadata to update the corresponding retrieval representations.
The manufacturer recommends hybrid retrieval followed by a separate reranking stage. Its examples compute dense, sparse and multi-vector scores and form weighted combinations. Select the combination around the collection’s questions and vocabulary; a weight shown in an example is not a universal setting for every corpus.
A useful result is a candidate set whose source passages remain available, with the representation and ranking method recorded. A separate reranker can refine that set, and a separate text-generation stage can use the passage content. BGE-M3’s sparse and multi-vector capabilities are producer model modes; the dense embedding, lexical output and pair score are distinct artifacts rather than interchangeable arrays.
", "aboutText": "BGE-M3 is BAAI’s multilingual retrieval model designed around three kinds of versatility: multiple retrieval functions, multiple languages and different input lengths. The manufacturer documents support for more than one hundred languages and inputs up to 8192 tokens. Its unified model can provide dense vectors, sparse lexical weights and multi-vector representations, so a retrieval design can select or combine more than one kind of evidence.\n\n### Three representations for retrieval\n\nDense mode maps a text to a single 1024-dimensional vector. It supports comparison of the meaning represented by a query and a passage. Sparse mode assigns weights to the tokens present in the text for lexical matching. Multi-vector mode represents a text with several vectors and uses a ColBERT-style interaction to compare the query and document at a finer level.\n\nThese outputs have different roles in a search index. A dense vector provides one representation for a passage; a sparse token-weight map retains lexical signals; multiple vectors provide a different comparison structure. The producer examples show returning the selected representations and computing scores for text pairs. Treat the chosen representation and scoring method as a deliberate part of the retrieval task.\n\n### Multilingual text and input preparation\n\nBGE-M3 does not require adding the retrieval instruction used by earlier BGE models. Prepare the query and the actual source passages directly. A multilingual knowledge collection can retain each passage in its original language, with its document identifier and locale. Use real user questions from the intended language mix when checking the results.\n\nA practical task is to search policy explanations, product help or technical documentation held in several languages. Retain names, model numbers and terms that matter to the question. A lexical representation can help preserve matching on those terms, while a dense representation supplies semantic evidence. The retrieved passage should include the text and source location that a reader can inspect.\n\n### Longer documents and granularity\n\nThe 8192-token input window allows the model to represent material from short sentences through longer documents. Choose the granularity around the answer the search should return. A complete section can preserve a definition and its exceptions; a smaller passage can make a specific instruction easier to locate. A long window makes those choices possible, but the vector remains associated with the material actually encoded.\n\nKeep each passage linked to its parent document and version. For a lengthy report, preserve the heading and surrounding explanation of the relevant figure or conclusion. Do not rely on a search hit’s title alone when the evidence is in the body. If the source changes, retain enough metadata to update the corresponding retrieval representations.\n\n### Hybrid scores and downstream use\n\nThe manufacturer recommends hybrid retrieval followed by a separate reranking stage. Its examples compute dense, sparse and multi-vector scores and form weighted combinations. Select the combination around the collection’s questions and vocabulary; a weight shown in an example is not a universal setting for every corpus.\n\nA useful result is a candidate set whose source passages remain available, with the representation and ranking method recorded. A separate reranker can refine that set, and a separate text-generation stage can use the passage content. BGE-M3’s sparse and multi-vector capabilities are producer model modes; the dense embedding, lexical output and pair score are distinct artifacts rather than interchangeable arrays.", "editorialOverlay": { "copy_fields": null, "copy_sha256": null, "copy_source": null, "html_sha256": "420c6fd5672697d1d3b159393ddefb8f520b24a207540821e00bb940edd2b068", "module_sha256": "ee9dc1c50b1e6a8fb7fa062030fcb4646b9aaaeb08be513b723a5a92a7290f06", "raw_model_unchanged": true, "schema": "ailoot-native-model-editorial-v1" }, "locale": "en", "methods": [ { "html": "baai/bge-m3BAAI BGE-M3 supports dense, sparse lexical and multi-vector retrieval across more than 100 languages. Its dense output has 1024 dimensions and its 8192-token window accommodates sentences through longer documents without a required query instruction.
This description covers the model’s capabilities. Available in Ailoot inputs, outputs and options are listed for the selected method below.
BGE-M3 is BAAI’s multilingual retrieval model designed around three kinds of versatility: multiple retrieval functions, multiple languages and different input lengths. The manufacturer documents support for more than one hundred languages and inputs up to 8192 tokens. Its unified model can provide dense vectors, sparse lexical weights and multi-vector representations, so a retrieval design can select or combine more than one kind of evidence.
Dense mode maps a text to a single 1024-dimensional vector. It supports comparison of the meaning represented by a query and a passage. Sparse mode assigns weights to the tokens present in the text for lexical matching. Multi-vector mode represents a text with several vectors and uses a ColBERT-style interaction to compare the query and document at a finer level.
These outputs have different roles in a search index. A dense vector provides one representation for a passage; a sparse token-weight map retains lexical signals; multiple vectors provide a different comparison structure. The producer examples show returning the selected representations and computing scores for text pairs. Treat the chosen representation and scoring method as a deliberate part of the retrieval task.
BGE-M3 does not require adding the retrieval instruction used by earlier BGE models. Prepare the query and the actual source passages directly. A multilingual knowledge collection can retain each passage in its original language, with its document identifier and locale. Use real user questions from the intended language mix when checking the results.
A practical task is to search policy explanations, product help or technical documentation held in several languages. Retain names, model numbers and terms that matter to the question. A lexical representation can help preserve matching on those terms, while a dense representation supplies semantic evidence. The retrieved passage should include the text and source location that a reader can inspect.
The 8192-token input window allows the model to represent material from short sentences through longer documents. Choose the granularity around the answer the search should return. A complete section can preserve a definition and its exceptions; a smaller passage can make a specific instruction easier to locate. A long window makes those choices possible, but the vector remains associated with the material actually encoded.
Keep each passage linked to its parent document and version. For a lengthy report, preserve the heading and surrounding explanation of the relevant figure or conclusion. Do not rely on a search hit’s title alone when the evidence is in the body. If the source changes, retain enough metadata to update the corresponding retrieval representations.
The manufacturer recommends hybrid retrieval followed by a separate reranking stage. Its examples compute dense, sparse and multi-vector scores and form weighted combinations. Select the combination around the collection’s questions and vocabulary; a weight shown in an example is not a universal setting for every corpus.
A useful result is a candidate set whose source passages remain available, with the representation and ranking method recorded. A separate reranker can refine that set, and a separate text-generation stage can use the passage content. BGE-M3’s sparse and multi-vector capabilities are producer model modes; the dense embedding, lexical output and pair score are distinct artifacts rather than interchangeable arrays.
POST /v1/embeddingstext, token_idsembedding| Field | Type | Requirement | Values & limits | Default |
|---|---|---|---|---|
Fieldmodel | Typestring | RequirementRequired | Values & limits baai/bge-m3 | Default— |
Fieldinput | Typestring|string[]|integer[]|integer[][] | RequirementRequired | Values & limits Minimum items: 1 Conditions: Nonempty homogeneous batch. Token IDs are nonnegative integers. Input budget: Maximum: 8,194 · Text unit: UTF8 bytes · Token unit: token-array elements | Default— |
Fieldencoding_format | Typestring | RequirementOptional | Values & limits float | Defaultfloat |
Fielddimensions | Typeinteger | RequirementNot supported | Values & limits Minimum: 1 | Default— |
Fielduser | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldsession_id | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldtrace | Typejson_value | RequirementOptional | Values & limits Conditions: Source allows this JSON metadata field; exact upstream semantics are model-specific. | Default— |
Fieldprovider | Typeobject | RequirementOptional | Values & limits Conditions: provider.options rejected | Default— |
text_to_embedding
| Parameter | Contract |
|---|---|
Parametercontent_type | Contractapplication/json |
Parameterrequired | Contractmodel, input |
Parameterinput_shapes | Contractstring, string[], nonnegative_integer_token_array, nonnegative_integer_token_array[] |
Parameterencoding_format | Contractfloat |
Parameterdimensions_override | Contractfalse |
Parametermax_input_budget_units | Contract8194 |
Parametermultimodal_objects | Contractfalse |
Parametermaterial_types | Contracttext, token_ids |
Lifecycle: synchronous_json
Keep every vector index and dimension.
Multimodal model name does not admit image objects on this exact path.
Tariff references do not add request options. Supported parameters are listed for the selected method.
| Configuration | Rate schedule | Charge |
|---|---|---|
| ConfigurationBase token rates | Rate scheduleBase rate | Charge Input · Input tokens $0.00004 / 1K tokens Output · Output tokens $0 / 1K tokens Input · Cache read — / 1K tokens Input · Cache write — / 1K tokens Input · Cache write, 1 hour — / 1K tokens |
Ailoot reserves an estimated amount before a request. After the result, it settles the final charge from measured usage. Streaming settlement uses the final usage record. How reservation and settlement work →
set -eu\n: "${AILOOT_API_KEY:?Set your Ailoot API key}"\npython3 - <<'PY_REQUEST'\nimport json,os\nfrom pathlib import Path\np=json.loads('{"model": "baai/bge-m3", "input": ["First document", "Second document"]}')\n\nPath("request.json").write_text(json.dumps(p,ensure_ascii=False))\nPY_REQUEST\ncurl --fail-with-body --silent --show-error https://api.ailoot.ai/v1/embeddings \\\n -H "Authorization: Bearer $AILOOT_API_KEY" -H 'Content-Type: application/json' \\\n --data-binary @request.json -D response-headers.txt -o result.json\npython3 - <<'PY_RESULT'\nimport json\nfrom pathlib import Path\nr=json.loads(Path("result.json").read_text())\nfor x in r.get("data",[]): print(json.dumps({"index":x.get("index"),"embedding":x.get("embedding")}))\nPY_RESULT\nfrom openai import OpenAI\nimport os\n\nclient=OpenAI(base_url="https://api.ailoot.ai/v1",api_key=os.environ["AILOOT_API_KEY"],max_retries=0)\nresult=client.embeddings.create(model='baai/bge-m3',input=["First document","Second document"])\nprint(result)\nfor item in result.data:print(item.index,item.embedding)\njson
Keep every complete returned response, file and content part.
Keep every vector with its index. Vector count must equal input count; dimensions must be consistent.
No embedding job endpoint is introduced.
| Field | Type |
|---|---|
Fieldobject | Typestring |
Fieldmodel | Typestring |
Fielddata[].index | Typeinteger |
Fielddata[].embedding | Typefinite float[] |
Fieldusage | Typeobject |
| Response | Condition | Next step |
|---|---|---|
Response400 · invalid_request_error | ConditionInvalid required fields, material representation or parameter value | Next stepCorrect the indicated fields before a new creation request. |
Ailoot Ultra baai/bge-m3
Use the method paths shown above.