Jev versus retrieval-only search
Retrieval-only search returns the nearest chunks. It does not say whether a chunk answers the question, contradicts it, or smuggles a prompt injection. Jev is the cheap structured judge you run after (or instead of) showing the top-k.
Unofficial comparison. Official patterns: rerank, semantic find. We do not invent recall@10. Not TypeSafe official.
What retrieval already does well
- Keyword / lexical match (BM25)
- Dense similarity when you have embeddings
- Fast shortlists (30-passage lists in TypeSafe’s rerank writeup)
What it does not do: calibrated “this line is the answer,” “no answer exists,” or “this chunk is hostile.”
What to add
- Retriever → Noul/Score per candidate (parallel questions on one request if the shortlist is small enough).
- Code sorts by
noulor score; drops below τ. - A companion Noul: “Does the document contain an answer at all?” — official line-by-line pattern. If that Noul is low, do not show a best-effort chunk as if it were a hit.
- Never dump the whole corpus into
state(jaggedness + token bill).
Cite vs generate: retrieval-only UIs should display passages, not a hallucinated synthesis. If you add an LLM writer, add a citation check.
When retrieval-only still wins
- Intranet search where users want links, not judgments
- You cannot send document text to any model
- The index already is the product
FAQ
Is Jev a reranker checkpoint? No. You pay per evaluation (vendor: input tokens). It is a request-time judge, not a trained ColBERT.
Hub: Comparisons. Sibling: RAG pipelines. Official: docs.typesafe.ai.
Sources
Public TypeSafe or adjacent documentation only. No private claims.