Skip to content

The Buric-E4B embedder

Retrieval quality is the product, and Buric-E4B is where it comes from: CodeNavi's own code-specialized embedding model, built and fine-tuned by CodeNavi specifically for code retrieval. Every chunk in your index and every query you run passes through it. This page is the evaluator's briefing — what it is, why a specialist model, how it runs, and what it deliberately is not.

What it is

  • A 4-billion-parameter code-specialized embedding model producing 2560-dimension vectors, paired with a cross-encoder reranker that re-reads each query against the candidate chunks before results are returned.
  • Fine-tuned once, by CodeNavi, before shipping. No fine-tuning ever happens on your data — your code is embedded, never trained on.
  • Baked into the release image at a pinned revision: no runtime model download, no remote model-code execution, and the same bytes on a connected install and an air-gapped one. First start fetches only the ~80 MB reranker, once.
  • The weights are proprietary, licensed under the CodeNavi Model License (MODEL-LICENSE.md in every package) — separate from the third-party components list.

Why a specialist model

General-purpose embedders are trained overwhelmingly on prose. Code retrieval is a different problem: identifiers, idioms, and structure carry the meaning, and a model that hasn't specialized in them ranks by surface similarity instead of behavior. Measured on our retrieval suite:

  • Wiring a generic embedder API (OpenAI, Cohere) into the same pipeline loses ~30 retrieval-quality points on code — which is why CodeNavi doesn't offer it as a supported path.
  • The shipped pipeline scores 96/100 retrieval quality with ~80% context-token savings on the published suite — methodology and queries at codenavi.com/benchmarks.
  • Vector-first beat hybrid ranking in our benchmarks: BM25 score fusion was tested and removed, with a keyword fallback kept for edge cases. The reasoning is in Which RAG architecture is CodeNavi?

How it runs

Everything happens on your hardware — embedding, indexing, search, reranking. Nothing about the model phones home.

  • GPU-accelerated indexing: NVIDIA (Turing and newer) or AMD ROCm (including Instinct MI300), with identical index quality on either vendor. See the GPU compatibility matrix.
  • VRAM autotune: the server detects your card at startup and picks the encode batch size and reranker placement. On ≥17 GiB cards the model runs fp16 at full speed; on 8–10 GiB cards the weights stay int8-resident (~4.1 GiB instead of ~7.5 GiB) at identical search quality and ~23% slower indexing. Details in the setup guide.
  • Two instances, one model: the server runs separate code and content embedder slots (visible in the /models endpoint of the API) so document indexing never competes with code search.
  • No GPU on the box? Pre-build the index on a one-shot cloud GPU and ship the LanceDB tables, or ask support about the vendor-assisted remote-embedder setup — the same model served from a GPU box you control. Both preserve full retrieval quality. On a Mac, use the Docker path — the macOS guide explains why.

What it is not

Not swappable. You cannot point CodeNavi at a Hugging Face model or an embedding API, and that's a design decision, not a gap: the 2560-dimension index format, the VRAM autotune tiers, the reranker, and the published quality numbers are all calibrated to this one model. A bring-your-own-embedder option would trade the product's defining property — measured, reproducible code-retrieval quality — for a configuration knob that benchmarks ~30 points worse.

If a future Buric revision ships, it arrives the same way everything else does: in a signed release image, with a reindex.