Which RAG architecture is CodeNavi?

Every RAG explainer ends with the same map: Naive → Graph → Hybrid → HyDE → Contextual → Adaptive → Agentic, and the advice "pick the one that matches the problem". Buyers ask where CodeNavi sits on it. The honest answer is that CodeNavi is not one box on the map. It is a retrieval toolkit that an agent drives, so it covers several levels, skips two on purpose, and rejected one after measuring it. This page goes level by level and says what actually ships, with the reasons.

The short version

Level	In CodeNavi?	What it is here
Naive RAG	Yes — the core	Code-specialised embedder → LanceDB vector search → cross-encoder rerank
Graph RAG	Yes	A precomputed call graph from the AST, not an LLM-extracted entity graph
Hybrid RAG	Yes at the agent level; no at the ranker	Vector + graph + grep + file reads, combined by the agent. BM25 score fusion was benchmarked and removed
HyDE	No	Vocabulary gaps are closed by alias and index-term expansion with no LLM call
Contextual RAG	Yes	AST-bounded chunks that keep the symbol, path and language; docs compiled into wiki pages
Adaptive RAG	No, by design	No query router. The agent already decides which tool to call
Agentic RAG	Yes — the product shape	33 MCP tools, agent notes as memory, crawler for external sources

Level by level

Naive RAG — yes, and it is where the quality comes from

semantic_search is a plain pipeline: query → embedding → approximate nearest-neighbour search in LanceDB → cross-encoder rerank → threshold. Three details make it work on code rather than on FAQs:

• The embedder is trained on code. Buric-E4B (2560 dimensions) is CodeNavi's own model, run on your GPU. General-purpose text embedders put "how does login fail after three attempts" nowhere near the function that implements it; a code embedder does. See concepts.
• Reranking is a second model, not a score tweak. The top candidates go through a cross-encoder that reads query and chunk together. The relevance threshold sits on that reranker's output.
• Relevance scores are relative. Scores rank results within one query; they are not calibrated across queries, so do not compare a 0.71 from one search with a 0.71 from another.

Graph RAG — yes, but a call graph, not an entity graph

Graph RAG in the explainers usually means an LLM extracting entities and relationships from prose at index time. Code already has an explicit relationship structure, so CodeNavi builds it deterministically instead:

• Tree-sitter parses every file into symbols (functions, methods, classes) and the calls between them. No LLM is involved, so the graph is reproducible and costs nothing per query.
• Degree and PageRank are computed over the graph and stored per symbol. Hubs (a logger, a base controller) are flagged so that impact_analysis does not report "everything depends on this" as if it were news.
• Cross-language edges are gated: a JavaScript init no longer collects Python callers of a function with the same name.

The tools on top: find_callers, impact_analysis, diff_impact, graph_neighborhood, and the Graph screen in the web UI. Reference: API reference.

Hybrid RAG — yes for the agent, no for the ranker

There are two things people call "hybrid".

Combining retrieval strategies — vector for meaning, graph for structure, grep for exact literals, file reads for verification — is exactly what happens in a CodeNavi session. The agent calls semantic_search to orient, then find_callers or grep_search to pin down, then read_file to confirm. That is hybrid retrieval, done by the caller with full context of what it is looking for.

Fusing BM25 and vector scores inside one ranker is the other meaning, and CodeNavi does not do it. It was tried. On a 3,500-file PHP application the 20-query benchmark fell from 99/100 to 57/100 with linear score fusion turned on: keyword-dense routing files (a giant switch-case, a catch-all settings template) win every BM25 contest and drown the correct result. Vector-only retrieval with the cross-encoder downstream restored 96/100, and that is what ships. Full-text search still exists in the index — it powers grep_search, symbol_search, and the query expansion described next — it just never touches the semantic ranking.

HyDE — no

HyDE generates a hypothetical answer document with an LLM and embeds that, to bridge the gap between how a user phrases a question and how the corpus phrases the answer. CodeNavi closes the same gap two cheaper ways, neither of which calls an LLM at query time:

• Alias expansion. Your team's vocabulary ("the checkout", "the cron stuff") maps to the identifiers the code uses, from a global list, a per-codebase manual list, and a per-codebase list that can be generated once by an LLM and then reviewed. Word-bounded matching, capped at twelve extra terms.
• Index-term expansion. Before embedding, non-stopword query terms are looked up against symbol and file names in the index; matches are appended to the query. "error logging" picks up lib_err_rep before the embedder ever sees it.

Both are deterministic, run in milliseconds, and are visible in the query log. HyDE would add an LLM round trip per search for a gap that is already mostly closed by a code-trained embedder.

Contextual RAG — yes

The explainer's advice is "enrich chunks with surrounding context so a fragment does not lose its meaning". For code the surrounding context is the syntax tree, so:

• Chunks are AST nodes — a whole function, method or class — across 15 languages, never a 500-token window that cuts a function in half. Each chunk carries its qualified symbol name, path and language. Full matrix in supported languages.
• Search results guarantee a floor of code chunks when both code and docs are indexed, so a README paragraph cannot crowd out the implementation it describes.
• For documentation the same idea runs one level up: the Docs Wiki compiles indexed docs into knowledge pages with an LLM you choose (local by default), so an agent can read one page on "how deployment works" instead of six partial hits. See web UI.

Adaptive RAG — no, on purpose

Adaptive RAG puts a classifier in front of retrieval: simple question → one lookup, complex question → multi-step pipeline. CodeNavi has no such router, and adding one would be a regression. The caller is already an agent with the whole conversation in context. It knows whether it holds an exact identifier (grep_search), a vague concept (semantic_search), or a change it is about to make (diff_impact). A router inside the server would be a second, less informed brain deciding on the first one's behalf. The server's job is to make each tool cheap, precise and honestly described, and let the agent pick.

Agentic RAG — yes, this is the product shape

Every item on the explainer's list maps to something concrete:

Explainer says	CodeNavi
Planning, multi-step execution	Done by the agent you connect: Claude Code, Codex CLI, Antigravity, VS Code, Zed, any MCP client
Tools	33 MCP tools (41 with the crawler): search, structure, graph, files, index control
Memory	save_note / search_notes — agent investigation notes, anchored to code and marked stale when the code moves, blended into later searches as advisory results
External data sources	Opt-in web crawler over your own documentation sites, indexed alongside code
Multiple agents	One server, many clients: every developer's agent and the CI review bot query the same index

Retrieval here is one tool in the agent's kit, not the whole strategy. That matches what the assistants with built-in retrieval do internally; the difference is that CodeNavi does it on your hardware, for any agent, with the code never leaving the box. See compare.

What this means when you evaluate

• Do not benchmark CodeNavi as Naive RAG alone. A single semantic_search is the fast first hop. The value shows on structural questions — "what calls this, what breaks if I change it" — that no embedding answers.
• Do not expect it to beat grep on a known identifier in a small repo. It will not, and it is not meant to. The win is orientation in large codebases and relationships an agent cannot get from text search.
• Ask any vendor for the hybrid-search number. If fusion helped, they should be able to show the before and after. CodeNavi's is above.

Related: air-gapped code RAG · concepts · compare