What this is
If the file in the model is stale, a fresh page can still be fetched and held in front of it. Open a PDF. Pull the line items off an invoice. Search a site and paste the hits. That is retrieval: a person, or a small program, fetched text and put it in the window. Then the model writes from what it was shown.
RAG is one way to do that automatically: search, then put the hits into the prompt. The model is still reading what it was handed. Nothing on the calendar moves. No invoice gets paid.
Retrieval supplies non-parametric context: documents, search results, or database text inserted into the prompt. The generator does not fetch. A separate step does.
RAG is a pattern for doing that automatically. The model remains a reader of supplied tokens. Retrieval has no side effects on external systems.
Easy to mix up
This is easy to mix up with the model knowing the files. It does not. A fetch happened. If that fetch is from the wrong folder, the wrong year, or a drive the assistant cannot see, the model will still sound sure. It only saw what it was given.
It is also easy to mix up with doing. A wrong reading list can still cause trouble if the summary is trusted. That trouble is not the same as a button getting pressed.
Answer quality is bounded by the retrieval step: index coverage, query, ranking, permissions, and freshness. The generator cannot audit sources it was not shown.
Harm from a bad summary is downstream of a person acting on it. That is a different risk surface from a tool call that mutates state.
From work
Finance drops last quarter’s vendor invoices into a folder and asks for a summary of what is still unpaid. A retrieval step searches the folder, puts three PDFs in the window, and the model writes a tidy table. One invoice was in a different folder. It never entered the window. The table sounds complete and is missing a file.
The object that mattered was the PDF, not the model’s general idea of what an invoice looks like. If the fetch missed a file, fluency will not notice.
The unpaid-invoice table is grounded only in the retrieved PDFs. A document outside the index is invisible. Confidence in the prose is not confidence in recall of the corpus.
The right unit of review is the fetch: which objects were retrieved, with what timestamp, under whose permissions. A missing invoice is a retrieval miss, not a generation error, though the table will not say so.
What to ask next time
Which files were actually put in front of it? Can the snippets be seen? If a PDF or a row is missing from that list, it was not read, no matter what the summary claims.
Ask for the retrieved objects, the query, and the timestamp. Spans that do not trace to a fetched document are generated, not retrieved.