Jev + RAG: typed judgments replace the reranker for filtering retrieved passages
Instead of a conventional reranker, Jev judges each retrieved candidate against a typed question like whether the passage helps answer the query and returns a probability, dropping passages below a threshold and checking whether the evidence is sufficient.
RAG vs. Jev + RAG, clearly explained! In a standard RAG setup, documents are split into chunks, converted into embeddings, and stored in a vector DB. When a query arrives, the system embeds it and retrieves the top-k chunks with the closest vectors. Many production setups add a reranker after retrieval. The reranker compares the query with each retrieved passage, improves their ordering, and keeps the highest-scoring results. Those passages are then placed in the context window, and the LLM generates an answer from them. The problem is that ranking and answerability are different questions. A passage can be more relevant than the other candidates while still containing weak, incomplete, or merely adjacent evidence. The LLM receives it anyway and may produce a plausible answer from context that never supported one. Jev + RAG keeps the retrieval stage as is but changes what happens before generation. Instead of using a conventional reranker at this stage, Jev can judge every retrieved candidate against a typed question such as: "Does this passage help answer the query?" The query becomes the shared state, while the retrieved passages become individual candidates. Jev evaluates them together and returns a probability for each one. Application code then applies a threshold. ↳ Candidates above the threshold continue to the LLM. ↳ Candidates below it are removed from the context window. The same Jev request can also judge whether the remaining evidence is sufficient to answer the query. If answerability falls below the threshold, the application can skip the LLM and return "not in the documents." Jev does not replace the embedding model, vector database, or generation model. Retrieval still sets the cap because Jev cannot recover a passage that never entered the candidate set. The diagram below depicts the complete flow. - RAG retrieves a broad candidate set. - Jev reranks and gates those candidates. - The LLM generates an answer. If you want to dive deeper, I have also written a hands-on guide showing how to build a Jev-style model with open models, entirely locally. Read it below.
This post quotes another post: x.com/1175166450832687104/status/210156361064449…