Who should use Jev RAG?

Jev RAG is designed for developers evaluating local document search, BM25 plus semantic reranking, agent-generated lexical searches, hybrid retrieval, or reproducible retrieval benchmarks. It is alpha software rather than a hosted multi-user product.

Can Jev RAG search documents without a vector database?

Yes. The default path uses local SQLite FTS5 and BM25 for candidate retrieval, then sends selected passages to Jev for evidence reranking. Embeddings and a vector database are not required for this path.

Does Jev replace the answer model in RAG?

No. Jev makes typed decisions about candidate evidence. A separate answer model generates the cited response from the selected passages.

Jev RAG / Use cases

Problem-first project guide

Different users,
different retrieval failures.

Jev RAG is not one universal recipe. It is a local knowledge-search application and evaluation harness with seven selectable paths. Start from the failure you need to fix: exact-term recall, vocabulary mismatch, evidence ordering, agent search planning, or retrieval evaluation.

Try Jev RAG locally Inspect the benchmark

Direct answer

Who is Jev RAG for?

Jev RAG is for developers who want an inspectable retrieval pipeline over local files and need to measure what happens when Jev judges the evidence. The smallest path is SQLite BM25 followed by Jev reranking. Optional paths add agentic query planning, embeddings, local rank fusion, passage gates, taxonomy routing, or full-corpus Jev Line Search.

It is local-first, not fully offline. Indexing and lexical retrieval stay local, but configured remote providers receive the text needed for reranking, planning, embeddings, or answer generation.

For RAG engineers: rerank a bounded candidate set

Problem: the first-stage retriever returns relevant-looking passages that do not actually support an answer.

Use: retrieve locally with BM25 or a hybrid method, then ask Jev one consistent evidence question per candidate and sort the returned probabilities in code.

Measured boundary: on NFCorpus, Jev raised BM25 top-30 nDCG@10 from 0.305654 to 0.353235. It cannot recover evidence that BM25 never retrieved.

For local knowledge-base builders: search a folder first

Problem: you want to test document search without deploying an embedding service, vector index, and database before the first useful query.

Use: point Jev RAG at Markdown, text, HTML, JSON, CSV, YAML, DOCX, or PDF files. SQLite FTS5 builds a local lexical index; the web interface returns cited passages and streams an answer.

Boundary: source files and the index remain local, but selected text is sent to configured providers. Do not use the default hosted-provider configuration for documents that must never leave the machine.

For search engineers: compare lexical and semantic recall

Problem: exact identifiers favor BM25, while synonyms and paraphrases favor semantic retrieval.

Use: keep the same corpus and metrics while switching between BM25, embedding RRF, agentic lexical search, and hybrid candidate pools before the same Jev stage.

Measured boundary: plain hybrid retrieval reached 0.396712 nDCG@10; Hybrid + Jev reached 0.444327. Wider recall and better ranking both mattered.

For agent developers: turn planning into bounded searches

Problem: one user question may hide several searchable subphrases, names, or constraints.

Use: let a planning model propose multiple lexical searches, execute every search locally, fuse the rankings, and give Jev a bounded shortlist. Code still owns the loop, limits, and fallback behavior.

Measured boundary: Agentic lexical + Jev reached 0.430969 nDCG@10 without a document embedding index, but online planning added latency and provider dependency.

For Jev developers: test where typed judgment belongs

Problem: a Jev integration can use independent Noul questions, a listwise Choice, a multi-question gate, or a local fusion after the model. Those designs are not interchangeable.

Use: compare the ordinary passage reranker, the unified Passage Gate, and two-level Line Search against the same retrieval baselines.

Measured boundary: the fixed Passage Gate was a negative result at 0.376298 nDCG@10, while Line Search improved first-hit behavior but cost USD 4.553288 for the cold full-corpus run.

For retrieval researchers: reproduce the whole comparison

Problem: architecture claims are difficult to evaluate when candidate pools, metrics, costs, and failed experiments are hidden.

Use: run the published commands on the complete BEIR NFCorpus test split: 3,633 documents and 323 queries, with shared qrels and metric code.

Boundary: these are project-run results, not an official MTEB submission. The repository publishes negative results and configuration caveats so another corpus can falsify the conclusions.

Problem-to-pipeline map

Choose the smallest path that addresses your failure.

If you care most about…	Start with	Accept this trade-off
Exact names, IDs and simple deployment	BM25 + Jev	Weak synonym recall
Vocabulary mismatch without document embeddings	Agentic lexical + Jev	Planner latency and remote calls
Semantic recall and ranking quality	Hybrid + Jev	Embedding setup and remote text boundary
Highest measured NFCorpus result	Agentic Hybrid	Two planning rounds; 6.99 s cold median retrieval
Evidence and injection policy experiments	Passage Gate	Threshold calibration; current fixed policy underperformed
Small-corpus Jev-first deep search	Line Search	Highest provider cost and widest remote-data boundary

What it does not replace

Retrieval, judgment and generation remain separate.

Jev does not generate the final answer and does not make a weak candidate pool complete. The retriever determines which evidence can be judged. Jev scores or selects within a bounded state. The answer model writes from the retained evidence. Keeping those stages separate makes failures measurable and lets you change one layer without pretending the whole system improved.

Run Jev RAG locally Follow the tutorial

Different users,different retrieval failures.