RAG vs. retriever-free RAG, clearly explained!
(powered by decision models like Jev)
In a standard RAG setup, documents are split into chunks, converted into embeddings, and stored in a vector index.
When a query arrives, the system embeds it and pulls the top-k chunks with the closest vectors.
A reranker then reorders those candidates against the query, and the best few go to the LLM as context.
The problem is that the similarity search decides what the LLM can ever see.
If the right passage never made the top-k, nothing later in the pipeline can bring it back, not even a strong reranker.
Retriever-free RAG, from a new Cornell and ASAPP paper, keeps the documents and the LLM but replaces similarity search with navigation.
The documents are organized as a document tree, like a table of contents, and a decision model (Jev 1.13) walks down it.
A decision model doesn't generate text. It reads one shared context and returns a probability for every yes/no question about it, in one forward pass per stage.
Here's how a query moves through the tree:
↳ Top documents: the model reads the query beside every candidate document, asks "Is this relevant?" for each, and keeps the best few.
↳ Top passages: it opens only those documents and asks the same question for every passage inside them.
↳ Most relevant? (optional): a single multiple-choice question reorders the top 20 passages (top 5 on Natural Questions).
Dropped documents are never opened, so their passages are never scored.
On Natural Questions (2.68M Wikipedia paragraphs), its top pick contained the answer 65.4% of the time. Embedding search plus an 8B reranker got 48.0%, and GPT-5 reranking got 60.8%.
The gain comes from ranking, not coverage. Embedding search's top 100 holds the answer more often than the navigated shortlist (98.4% vs 94.0%), but navigation is better at putting it first.
Median retrieval takes under 2 seconds per query, but each method was timed in a different setup, so it isn't a controlled speed comparison.
The main limit is that it needs a sensible hierarchy, and a document pruned early is gone for good. It also skips embedding search only at query time, since the Wikipedia tree was built offline using embeddings.
The diagram below depicts the complete flow.
- RAG retrieves by similarity, then reranks.
- Retriever-free RAG navigates a document tree with a decision model.
- The LLM answers from the top passages.
If you're building a RAG system, this is worth benchmarking against your current setup.
Here's the paper: https://t.co/U7cCcIfZV1
If you're new to decision models, I've quoted my full breakdown of how Jev works below.
Google open-sourced Harness²!
Harness² is a framework for recursively improving the harness around an agent while keeping the underlying model weights fixed.
The interesting part is that it does this at two different levels.
For the current task, Harness² uses a Propose → Probe → Compose loop. It proposes changes to the harness, runs those variants on the same task, compares how the executions behave, and then composes a better harness from that evidence.
That is the task-level recursion.
But the process does not reset after every task.
Harness² also keeps the harnesses it adopted and the lessons supported by execution evidence, then uses those to guide how future harnesses should be improved on new tasks.
That is the harnessing-level recursion.
So one loop improves the harness for the task in front of the agent.
The second loop improves how the system learns to build better harnesses over time.
The editable harness itself can include the system prompt, guardrails, memory, tool guidance, subagents, skills, scripts, and plugins.
You can also run the recursion in two ways:
Parallel recursion explores more candidate harnesses.
Sequential recursion carries the refined harness and accumulated evidence through multiple Propose → Probe → Compose steps.
Google reports that even a single Harness² step improved GLM-5 and Gemini 3.5 Flash across JobBench, LAB, and WorkBuddy-Bench, with larger task-level recursion budgets bringing further gains.
That is what makes Harness² more interesting than just another agent framework.
It is treating the harness itself as something that can be iteratively improved from execution evidence, both within a task and across tasks.
100% open source.
I’ve shared the GitHub repo in the comments!
Google just released free 2-hour course on full Harness engineering from 0% to 100%:
0% → 0:29 - Harness engineering from scratch
15% → 11:08 - build your first agent right way
30% → 28:08 - Eval engineering: build Chief of Staff agent
65% → 1:00:13 - Loop engineering
100% → 1:23:19 - self-improving graphs system that works 24/7
most people keep trusting agent that "looks right" - the real upgrade is a Harness that tests, judges and rewrite your agent until it works
learn Harness from Google, ship your first - then unlock the full Agent systems below:
Probability of getting rejected for not knowing RAG, vector databases, and AI agents: 20%
Probability of getting rejected for not knowing networking, load balancers, CDNs, operating systems, and databases: 99%
I have been fine-tuning LLMs for over 3 years now.
Here are 5 LLM fine-tuning techniques, explained with visuals:
Traditional fine‑tuning is impractical for LLMs (billions of params; 100s of GB).
Since this kind of compute isn't accessible to everyone, parameter-efficient fine-tuning techniques (PEFT) were built.
Before we go into details of each technique, here's some background that will help you better understand these techniques:
LLM weights are matrices of numbers adjusted during fine-tuning.
Most PEFT techniques involve finding a lower-rank adaptation of these matrices, a smaller-dimensional matrix that can still represent the information stored in the original.
Now with a basic understanding of the rank of a matrix, we're in a good position to understand the different fine-tuning techniques.
(refer to the image below for a visual explanation of each technique)
1) LoRA
- Add two low-rank trainable matrices, A and B, alongside the weight matrices.
- Instead of fine-tuning W, adjust the updates in these low-rank matrices.
Even for the largest LLMs, LoRA matrices take up a few MBs of memory.
2) LoRA-FA
While LoRA significantly decreases the total trainable parameters, it requires substantial activation memory to update the low-rank weights.
LoRA-FA (FA stands for Frozen-A) freezes matrix A and only updates matrix B.
3) VeRA
- In LoRA, low-rank matrices A and B are unique for each layer.
- In VeRA, A and B are frozen, random, and shared across all layers.
- Instead, it learns layer-specific scaling VECTORS (b and d) instead.
4) Delta-LoRA
- It tunes the matrix W as well, but not in the traditional way.
- Here, the difference (or delta) between the product of matrices A and B in two consecutive training steps is added to W.
5) LoRA+
- In LoRA, both matrices A and B are updated with the same learning rate.
- Authors of LoRA+ found that setting a higher learning rate for matrix B results in better convergence.
____
Find me → @_avichawla
Every day, I share tutorials and insights on DS, ML, LLMs, and RAGs.