There are four ways to give an LLM your data — put it in the context window, retrieve it with RAG, fetch it through tools at runtime, or bake it into the weights by fine-tuning. They are not competing choices so much as different jobs; most real systems combine them. The trick is matching the method to whether your data is small or large, static or live, and whether you need facts or behavior.
The four methods at a glance
| Method | How | Best when | Freshness |
|---|---|---|---|
| Context window | Paste data into the prompt | Small, one-off, fits in the window | Whatever you paste |
| RAG | Retrieve relevant chunks at query time | Large, mostly-static knowledge base | As fresh as your index |
| Tools / MCP | Model calls an API mid-conversation | Live data, actions, anything time-sensitive | Real time |
| Fine-tuning | Train on examples, update weights | Teaching style, format or a narrow skill | Frozen at training |
1. The context window: simplest, and often enough
The most direct method is to put the data in the prompt. Modern models have large context windows, so "paste the document and ask about it" handles a surprising amount — a contract, a report, a handful of pages. It needs no infrastructure and the model sees exactly what you provide. The limits are size (a knowledge base does not fit) and cost (you pay for every token every call). Reach for it first for one-off tasks; graduate to RAG when the same large corpus is queried repeatedly.
2. RAG: retrieve the relevant slice
Retrieval-augmented generation solves the size problem. You index your documents once (chunk them, embed the chunks, store the vectors), and at query time you retrieve only the chunks relevant to the question and put those in the prompt. The model answers grounded in your documents without ever seeing the whole corpus. RAG is the workhorse for company knowledge bases, documentation assistants and support bots. Its freshness equals your last indexing run — which is why the ingestion pipeline behind RAG matters as much as the retrieval, and why keeping the source current is the real ongoing job.
3. Tools and MCP: fetch it live
Neither context nor RAG helps when the answer depends on the current state of the world — today's price, this morning's news, live inventory. For that, give the model tools it can call. Via the Model Context Protocol, a model can invoke a function mid-conversation — search the web, hit an API, query a database — and reason over the result. This is the only method with real-time freshness, and it composes with the others: an agent uses RAG for what your team has curated and tools for what is happening now. When the live data is the open web, a web-data API exposed as MCP tools lets the model search, scrape and crawl on its own.
4. Fine-tuning: change the model itself
Fine-tuning trains the model on your examples so the behavior is baked into the weights. Crucially, it teaches style, format and skill far better than it teaches facts — use it to make a model reliably output your JSON shape, adopt your tone, or handle a narrow classification task, not to inject a knowledge base (facts belong in RAG or tools, where they can change without retraining). It is the heaviest option — you need a quality training dataset and a training run — and the data is frozen at training time. Most teams try prompting, then RAG, then tools, and only fine-tune when a specific behavior refuses to come from the first three.
How to choose
- Is the data small and used once? Context window. Done.
- Is it a large, mostly-static knowledge base queried often? RAG.
- Does the answer change by the minute, or need an action taken? Tools / MCP.
- Do you need consistent behavior, format or a narrow skill? Fine-tuning — after the others.
Real systems mix them: a support agent might fine-tune the response format, use RAG over the help center, and call tools for live account data. The methods are layers, not a single pick.
The part they all share: the data
Whichever method you use, the data has to come from somewhere and be clean enough to help rather than confuse. Internal data needs privacy scrubbing; public web data — prices, docs, listings, company info — needs collecting, and that collection is its own problem because pages block bots and render in JavaScript. A scraping API that returns clean Markdown feeds RAG indexes and context windows alike, because Markdown preserves the structure models learn from; a crawl ingests a whole documentation site; and the same capabilities as MCP tools cover the live-fetch path. We go deeper on sourcing in how to get data for AI. The method is the easy decision; keeping the underlying data fresh and clean is the work that actually determines answer quality.