RAG (Retrieval-Augmented Generation)
Fetching relevant documents at query time and placing them in the model’s context, so answers ground in your data instead of training memory. The retrieval layer determines most of the quality.
Retrieval decides the answer
Generation quality is largely downstream of retrieval quality: a model given the right three paragraphs will answer well, and the same model given three plausible but wrong ones will answer confidently and incorrectly. Most effort spent tuning prompts in a RAG system would return more if spent on what is being retrieved.
Chunking, embedding and the boring parts
How documents are split, what is embedded, whether results are reranked, and how much makes it into the final context — these unglamorous choices dominate outcomes. Hybrid retrieval combining keyword and vector search is usually a bigger win than swapping the generation model.
Keep the sources attached
A retrieved passage should travel with its origin all the way into the answer. Without that, nobody can check a claim, and an unverifiable answer from a system that reads your documents is worse than no answer — it is a confident one you cannot audit.
In AGNT
AGNT workflows compose retrieval steps — files, databases, web — ahead of generation, with sources kept for the receipt.
RAG (Retrieval-Augmented Generation) — common questions
Is RAG better than fine-tuning?
They solve different problems. RAG supplies knowledge that changes; fine-tuning shapes behaviour, format and tone. Teams needing current facts want retrieval, not new weights.
Does a bigger context window make RAG unnecessary?
No. Large windows reduce the pressure to chunk aggressively, but stuffing everything in costs more, runs slower and dilutes attention. Selecting well still beats sending everything.
How does AGNT handle retrieval?
As explicit workflow steps ahead of generation — files, databases or the web — with the sources retained for the run’s receipt.