Embedding, Reranking, and Multivector: Three Signals, One Search Engine
How Context212 combines dense embeddings, LLM relevance scoring, and MaxSim multivector matching to retrieve, refine, and judge document passages.
When you ask Context212 a question (via Search or Ask), the answer does not rest on a single magic score. The engine chains complementary signals. Three of them structure text search: embedding, reranking (relevance score), and multivector (ColBERT-style MaxSim).
They do different jobs. Confusing them means misreading a result, and mis-designing a RAG pipeline.
1. Embedding: finding the right shelf
Embedding turns an entire passage (and your query) into one dense vector.
What it answers: “Does this chunk talk about roughly the same topic as my question?”
Where it runs: at ingest, then as the first search stage: approximate nearest-neighbor retrieval. That signal feeds scores.text in the API.
Strengths: fast at corpus scale, strong recall for a candidate short-list.
Limits: a single “average” vector can blur precise lexical detail.
Without embedding, there are no candidates. It is the wide net.
2. Reranking: asking the librarian
Once roughly twenty passages surface, Context212 can run an LLM relevance score. This is not vector geometry: the model reads the question and the text, then assigns a note between 0 and 1 (scores.relevance).
What it answers: “Among these candidates, which ones actually answer the question?”
Where it runs: after vector retrieval, optionally (relevance_scoring: filter, score-only, or off). When scoring is on, the result’s score typically follows this relevance.
Strengths: nuance, negation, “almost but not quite”: semantic judgment.
Limits: slower and costlier; it only sees the small set already selected.
Context212 reranking is an LLM judge, not ColBERT MaxSim. Distinct ideas, often mashed under “rerank.”
3. Multivector (MaxSim): token-level alignment
Multivector, exposed via scores.multivector, encodes tokens, not the whole passage. The query becomes a matrix of vectors; each chunk does too. MaxSim sums, for every query token, the best match in the document.
What it answers: “Which words in the question align finely with this passage?”
Where it fits: ideally as a second stage on the same candidates embedding found: geometric refinement beside or before the LLM score. Values are ≥ 0 with no fixed ceiling; higher means stronger alignment. It stays null while multivector mode is off or unavailable for the chunk.
Strengths: token-level precision for near-misses.
Limits: heavier storage, a dedicated model (ColBERT-style), distinct from classic dense embedding.
Three stages, one intent
Query
│
├─① Embedding ──► candidates → scores.text
│
├─② Multivector ──► MaxSim on those K → scores.multivector
│
└─③ Reranking ──► LLM relevance → scores.relevance
(sort score when enabled)
| Embedding | Reranking | Multivector | |
|---|---|---|---|
| Unit | 1 vector / chunk | LLM note / chunk | Many vectors / chunk |
| Role | Recall candidates | Judge usefulness | Refine alignment |
| API signal | scores.text | scores.relevance | scores.multivector |
| Analogy | Find the shelf | Ask the librarian | Check word by word |
Why Context212 exposes all three
Serious document products do not hide behind an opaque ranker. By separating signals in scores, Context212 lets you:
- understand why a passage ranked;
- plug in your own logic (keep dense, disable LLM, anticipate MaxSim);
- audit Ask and Search with citations grounded in the corpus.
Embedding recalls. Multivector refines. Reranking decides. Together they form the core of grounded Context212 search, so every answer stays traceable to the source page.