Embeddings and Reranking

You do not have to adopt this server's Search engine to benefit from its models: the embedding and reranking surfaces stand alone, for teams with their own vector database, their own retrieval pipeline, or their own ranking stage. Your infrastructure keeps its role; the models run here, and text never leaves to be embedded.

1The OpenAI-compatible door#

POST /v1/embeddings serves the standard shape (a string or an array of strings in, one vector per input out), so every embeddings client, framework, and vector-database loader that speaks OpenAI points its base URL here and works unchanged. Vector dimensionality follows the chosen model, as clients expect to discover it.

2The native door: documents and images go in directly#

POST /lmkit/v1/embeddings accepts more than strings. input is an array whose input_format is PlainText, Base64EncodedFile, or FileIdentifier, and the files behind the latter two may be PDF, HTML, EML, MBOX, Microsoft Office documents, or images:

• Documents embed without a client-side extraction step: the server reads them the same way its document pipeline does, and answers one vector per input.
• Images embed through a vision embedding model, which is what powers visual similarity over screenshots, scans, and photos in your own store.
• Long inputs and big batches ride the jobs contract: a call that outgrows the sync timeout answers 202 with a job_id to poll.

3Query and passage are not the same vector#

Retrieval-grade embedding models are asymmetric: text being INDEXED and text being SEARCHED FOR embed differently. The native request's embedding_mode carries that intent: embed your corpus with Passage (the default) and your search strings with Query. Mixing them up is the classic silent quality bug in bring-your-own-vector pipelines: everything works, recall is just mysteriously mediocre.

4Reranking your own results#

Vector similarity gets candidates; a reranking model reads the query against each candidate and scores actual relevance. Two routes serve the stage:

The blend is the point: pure rerank scores discard what your retrieval already knew, and pure retrieval scores ignore what the reranker just read. alpha sets the mix per call.

5Choosing and operating the models#

Embedding and reranking are their own model roles: pick them from the catalog and set the default slots in the admin console, or name a model per request. The catalog carries text embedding models in several sizes and dedicated rerankers; dimensionality and speed differ, so measure on your own data before standardizing. One operational fact worth knowing: embedding requests decode on their own pinned pool, sized independently of chat (Inference Capacity), so bulk embedding does not queue behind conversations.

6Changing models means re-embedding#

Vectors from different models, and even different sizes of the same family, live in different spaces: they must never be compared. When you switch embedding models, re-embed the corpus and the queries both; keep the model id stored next to your vectors so the mismatch is detectable. This server's own Search engine automates exactly that lifecycle, which is the honest trade of bringing your own store: the knobs are yours, and so is the bookkeeping.

7Stated plainly#

• OpenAI-compatible embeddings for drop-in clients; the native route additionally embeds PDFs, Office documents, email archives, and images with no extraction step.
• Embed corpora as Passage and searches as Query; the asymmetry is where quality hides.
• Rerank as raw scores or as a finished alpha-blended stage that respects your retrieval scores and carries your metadata through.
• Your database, your pipeline, these models; switching models re-embeds, and Search exists for when you would rather not own that.