Generated-Knowledge Prompting: Surface Facts Before You Answer
Have the model write down what it knows first, then answer using that as context
Some questions go wrong not because the model cannot reason, but because it answers before bringing the relevant facts to mind. Generated-knowledge prompting fixes that with two steps: first ask the model to write down what it knows about the topic, then ask the real question with that knowledge in context. It is a small change that meaningfully helps on commonsense and world-knowledge tasks. This is part seven of Prompt Engineering, Properly.
The problem it solves#
Ask a model a knowledge-laden question cold and it can answer on vibes rather than facts:
Part of golf is trying to get a higher point total than others. Yes or No?Yes.Wrong. In golf you want the lowest score, not the highest. The model has the facts somewhere, it just did not surface them before committing to an answer. Generated-knowledge prompting (Liu et al., 2022) is the fix: make the model state the relevant knowledge first, then answer using it.
Step one: generate the knowledge#
You prompt the model to produce a few relevant facts about the input. A few-shot prompt with example "knowledge" statements steers the format:
Input: Greece is larger than Mexico.
Knowledge: Greece is approximately 131,957 sq km, while Mexico is
approximately 1,964,375 sq km, making Mexico 1,389% larger than Greece.
Input: A rock is the same size as a pebble.
Knowledge: A pebble is a clast of rock with a particle size of 4 to 64 mm
on the Udden-Wentworth scale, larger than a granule and smaller than a cobble.
Input: Part of golf is trying to get a higher point total than others.
Knowledge:The model generates something like:
The objective of golf is to play a set of holes in the least number of
strokes. Each stroke counts as one point, and the total number of strokes
determines the winner.Generate a couple of these knowledge statements, not just one, since different generations surface different facts and you can use more than one.
Step two: answer using the knowledge#
Now feed that knowledge back in alongside the question, and ask the model to explain and answer:
Question: Part of golf is trying to get a higher point total than others. Yes or No?
Knowledge: The objective of golf is to play a set of holes in the least
number of strokes. The total number of strokes determines the winner.
Explain and Answer:No. The objective of golf is to play a set of holes in the fewest strokes.
The total number of strokes determines the winner, so a lower total wins,
not a higher one.Correct now, because the relevant fact was in front of the model when it answered instead of buried in its weights. The original paper also looks at the model's confidence across the different knowledge statements and uses that to pick the final answer; in practice, generating a couple and taking the well-supported one is enough to see the benefit.
This pairs naturally with the techniques earlier in this series. The generated knowledge is just high-quality context (the second element from the anatomy of a good prompt), and you can layer chain-of-thought on the answer step so the model reasons over the facts it surfaced.
Generated knowledge vs RAG#
This is the obvious question, and the distinction matters. Generated-knowledge prompting pulls facts from the model's own parameters. Retrieval-augmented generation pulls them from an external source you control. They solve overlapping problems in very different ways.
| Generated knowledge | RAG | |
|---|---|---|
| Source of facts | The model's own training | Your documents / database |
| Good for | Common knowledge the model reliably knows | Private, current, or niche facts the model does not |
| Risk | Can generate wrong "facts" (hallucinate) | Retrieval can miss or return irrelevant context |
| Setup cost | None, it is just prompting | Embeddings, a vector store, a retrieval pipeline |
The honest limitation: generated knowledge can only surface what the model already knows, and it can confidently generate something false. So it helps on well-trodden commonsense and general knowledge, where the model's recall is solid but its first-pass answer is sloppy. It does not help, and can hurt, on private data, recent events, or specialized facts the model never learned. For those, you want retrieval. I cover that whole stack in What is a vector database, and how does RAG use it? and the rest of the RAG cluster, starting with chunking strategies.
A useful way to decide: if the fact lives in the model, generate it; if it lives in your data, retrieve it.
Wrapping up#
When a question needs world knowledge and the model answers carelessly, make it lay out the relevant facts first, then answer using them. It is two prompts instead of one, it costs an extra call, and it reliably helps on commonsense tasks the model knows but rushes. When the facts are private, current, or niche, reach for RAG instead, because generated knowledge can only give you what the model already holds.
This is the last of the foundational techniques in this batch. Next in the series: Prompt chaining, where we stop trying to do everything in one prompt and break a task into linked steps that feed each other. The previous part is Self-consistency.
Source: the Prompt Engineering Guide, Generated Knowledge Prompting; Liu et al. 2022.
Folarin Akinloye is an AI Engineer based in London, UK. He builds production-ready agentic AI systems, multi-agent architectures, and sophisticated RAG implementations, and writes about the engineering decisions behind them.