Data Filtering with a Judgment-Only Model
Updated 2026-09-20
The scenario
Your pipeline ingests more data than your downstream stages can afford to process: scraped pages for a RAG corpus, candidate records for enrichment, retrieval results for an agent's memory, rows for a fine-tuning dataset. The bottleneck is not storage — it is the cost of processing junk as if it were signal.
Why Jev fits
Data filtering is judgment at its purest: keep/discard, relevant/not, high/medium/low quality. The inputs are already structured (metadata, fields, snippets), the answer space is closed, and volume is the whole problem. A judgment-only model can sit inline and evaluate every record at ingest time — the role early coverage summed up as rapid, low-cost micro-decisions that "filter data" ahead of frontier models.
Notably, one of the early-access demos (Moritz's tutorial) used Jev to test AI memory retrieval — judging whether retrieved memories were actually relevant — which is exactly this use case.
Judgment design example
Structured input per record (adapt to your domain):
| Field | Example |
|---|---|
title / snippet | candidate document or row |
source | crawl / import / retrieval |
query_context | what the data is for (e.g. the retrieval query) |
metadata | date, author, language, length |
Judgments to define:
- Binary: "Relevant to the target use?" → the basic keep/discard gate.
- Score: "Quality 0–100" → dedup tie-breaking and top-K selection; keep the best N, not the first N.
- Choice: "Failure mode?" →
off-topic/low-quality/duplicate/stale— rejected items with reasons make the filter tunable instead of opaque. - Binary (for training data): "Would including this example improve or degrade the dataset?" → curation at corpus scale.
Where the LLM sits
Strictly downstream. In RAG: Jev scores retrieved chunks, the LLM generates an answer from only the chunks that passed. In enrichment: Jev gates which records earn an expensive LLM extraction pass. In curation: Jev screens candidates, an LLM occasionally audits a sample for filter drift. Full shape in the front-filter recipe; the scoring YouTube ideas demo is the same pattern with a creative twist.
Watch-outs
- Log rejections with reasons. A filter you cannot audit will silently eat good data; sample rejected items weekly.
- Mind the feedback loop. If tomorrow's training data is filtered by today's judgment, errors compound — keep a human-audited holdout.
- Throughput math first. The win is (cost per judgment × volume) < (downstream savings); verify on your real volumes before committing.
Sources
- "Jev: The New AI Model That's Breaking The Internet (Full Tutorial)" — Moritz (~43K views, 2 days) — includes "Testing Jev for AI memory retrieval" and "Scoring YouTube video ideas."
- "Jev + GPT-6 Astra = 400X Cheaper" — Jack Roberts (~21K views, 11 hours) — micro-decisions to "filter data" ahead of frontier models.
- "Jev is HERE. How to use it" — Greg Isenberg (~293K views, 1 day).
Unofficial fan-made handbook. Not affiliated with TypeSafe AI or jev.com. Jev is a trademark of its respective owner.
Related Guides
Document Triage: Type and Urgency on Two Axes
Sort inbound documents — contracts, invoices, resumes, tickets — by type with Choice and by urgency with Score, so each document class gets its own downstream pipeline and deadline.
Intent Classification: The Front Door of a Chatbot
Classify user messages into intents (and urgency) before any LLM touches them — so simple requests get cheap handlers and only genuinely open-ended messages reach the expensive model.
RAG Reranking: Filtering Retrieval Results by Relevance
Use Jev-style Noul judgments to batch-score retrieved chunks for relevance and keep only the top-k — so the LLM answers from signal, not from whatever the vector search coughed up.
Validating Structured Extraction: Code First, Judgment Second
Pair deterministic code validation (schema, types, ranges) with a Jev-style semantic review pass — catch the extraction errors that parse fine but mean the wrong thing.