Sooner or later, someone on every AI project says it: “Can't we just train it on our documents?” It sounds right. Language models learned everything they know from text, and you have plenty of text.
The answer is yes, technically, and it's usually the wrong plan. Feeding a model raw text teaches it to sound like that text far more reliably than it teaches the facts inside. If you want a model to answer from your documents, you probably don't want to train it at all.
What feeding it text really does
Pretraining is the one stage where “just feed it text” is accurate. The model reads a huge corpus and learns to predict the next token, and nothing in that process teaches it to help you. A model trained this way continues text. It doesn't answer questions, unless an answer happens to be the likeliest continuation. Here's an illustration of the difference:
Prompt: What is your refund policy?
Base model: What is your shipping policy? How do I change my
order? Can I cancel a subscription? ...
Assistant: You can request a refund within 30 days of purchase.Turning a base model into an assistant takes more stages, with different data. InstructGPT used three: train on written demonstrations, train a reward model on human comparisons, then optimise the model against that reward.[1] None of those stages uses raw text. They use examples of what good behaviour looks like.
Scale matters too. The open FineWeb dataset holds 15 trillion tokens from 96 Common Crawl snapshots,[2] and Llama 3.1 trained on about 15 trillion tokens.[3] A 500-page company handbook is around 330,000 tokens by our estimate. A model has seen tens of millions of times more text than that, so your documents can't teach it language. At best, they can nudge it.
Why documents don't turn into knowledge
Suppose you take an existing model and continue training it on your handbook. It's natural to expect the model to know what's in it afterwards. The research suggests four reasons it may not.
One mention isn't enough. In a controlled study on synthetic biographies, Allen-Zhu and Li found that for knowledge to be reliably extracted, it had to be augmented during pretraining with paraphrases, shuffled sentences or translations. Without that, accuracy could fall to 0%, regardless of later instruction tuning.[4] A model can memorise a passage and still fail to answer a question about it. Your handbook probably states each policy once.
Retrieval beat fine-tuning on facts. Ovadia and colleagues compared unsupervised fine-tuning with retrieval-augmented generation for adding knowledge to a model. Fine-tuning gave some improvement, but retrieval consistently outperformed it, for both existing and entirely new knowledge. They also suggest that showing a model many variations of the same fact could help.[5] That means more data work, not less.
Facts learned in one direction may not reverse. A model trained on “A is B” won't automatically learn that “B is A”. This is the reversal curse.[6] If your document says “Dana Reyes is our head of compliance”, a model trained on it may still fail to answer “Who is our head of compliance?”
Teaching new facts can raise hallucination. Gekhman and colleagues found that models struggle to acquire new facts through fine-tuning. Once those new examples were learned, the model's tendency to hallucinate rose in step with them.[7] Their setting was closed-book question answering, but the warning applies widely: you can make a model more confident without making it more correct.
What training is good at
Training changes behaviour. The LIMA team fine-tuned a 65B model on just 1,000 carefully curated prompts and responses, with no reinforcement learning, and got strong results. They concluded that their results strongly suggest almost all of a model's knowledge comes from pretraining.[8] In other words, a small set of examples can teach a model how to respond, while what it knows stays largely as it was.
That's why fine-tuning data doesn't look like a pile of documents. It looks like the job itself, with an input and the output you want:
{"messages": [
{"role": "user", "content": "Summarise this ticket: ..."},
{"role": "assistant", "content": "Issue: ...\nImpact: ...\nNext step: ..."}
]}A few hundred examples like that can teach a format, a tone or a procedure. A thousand pages of PDFs can't, because they never show the model what a good answer looks like.
Quality beats volume
Text also needs work before any model should see it. Researchers found a single 61-word sentence repeated more than 60,000 times in the C4 dataset. Models trained on such data copied over 1% of their unprompted output verbatim from it. Deduplicated training produced models that emitted memorised text ten times less often, in fewer training steps, with the same or better accuracy.[9] FineWeb's experiments show the details matter: basic filtering gave a significant lift, while deduplicating globally across all its snapshots gave only a modest one.[2]
The copying also raises a question for private data. Models can reproduce what they were trained on, and once text is in the weights, you can't easily remove it or limit who sees it. Think hard before you train on anything confidential.
Keep your documents outside the model
Retrieval-augmented generation (RAG) takes a different approach. It pairs a model with a searchable index of documents.[10] When a question comes in, the system finds relevant passages and puts them in the prompt, and the model answers from them. It behaves like an open-book exam.
That design solves several practical problems at once:
- Updates are simple. Change a document and reindex it, with no training run.
- Answers can show their sources. You know which passages went into the prompt, so you can display them.
- Access can follow permissions. You can limit search to documents a user is allowed to see.
- Reversal is less of a problem. Models can deduce “B is A” when “A is B” appears in their context.[6]
Retrieval has failure modes of its own. Search can miss the right passage, and the model can still misread what it finds. The RAG paper itself called provenance and knowledge updates open research problems,[10] so treat sources as something to test, not a guarantee. Retrieved text is also untrusted input, which makes it a route for indirect prompt injection.
Which one do you need?
| You want the model to… | Start with |
|---|---|
| Answer from your documents | Retrieval |
| Stay current as content changes | Retrieval |
| Show where an answer came from | Retrieval |
| Follow rules or a process | A better prompt, then fine-tuning |
| Use a consistent format or tone | Examples in the prompt, then fine-tuning |
| Cost less at high volume | Fine-tuning a smaller model |
| Work in a domain open models don't cover | Continued pretraining, if you have the data |
These aren't exclusive. A good support agent might use retrieval for what it knows and fine-tuning for how it writes. Full pretraining is rarely the answer, and our guide to what training really costs shows why.
What to do with your documents
- Write the questions first. Collect 30–50 real questions and the answers your documents should produce. That's your test set.
- Try the simple version. If your documents fit in the prompt, put them there and measure. You may not need anything else.
- Add retrieval when they don't fit. Measure whether the right passage was found as well as whether the answer was right, so you know which part failed.
- Fine-tune last, and only for behaviour. Do it when the facts are right but the format, tone or cost isn't.



