Generated Knowledge prompting: ask the model what it knows first

Ask a model: "Could a pumpkin fit in a shoebox?" About a quarter of the time you get a wrong answer — "yes" from a model that didn't pause to think about pumpkin sizes.

Now ask in two steps. First: "What is the typical size of a pumpkin? What is the typical size of a shoebox?" Then, using that recall as context: "Given that, could a pumpkin fit in a shoebox?" The answer is almost always right.

Sometimes a model fails not because it can't reason, but because it never surfaced the relevant facts. Direct questions skip the step where the model recalls background knowledge — and without that step, reasoning proceeds from incomplete premises.

Generated Knowledge prompting fixes this with a simple two-step trick: first, ask the model what it knows about the topic. Then, ask it to answer the original question using that knowledge as context. It's the cheapest accuracy boost you can apply to knowledge-heavy tasks that don't justify a full RAG pipeline.

The mental model: recall before reason#

LLMs encode knowledge in their weights, but accessing it isn't deterministic. A direct question pulls whatever recall is most easily activated; subtle facts often stay buried. Asking the model to recall first forces a more thorough sweep — the recalled passage becomes context the answering pass can attend to.

Mechanically, this is similar to how Chain-of-Thought works for reasoning. CoT exposes intermediate logic; Generated Knowledge exposes intermediate facts. Both give the model more useful tokens to attend to.

Think of it as the difference between an open-book exam (RAG: real documents in front of you) and a closed-book exam where you make notes from memory before answering (Generated Knowledge: recall first, then answer). Both outperform "just write the answer" — but Generated Knowledge requires no infrastructure.

The basic two-step pattern#

Generate background knowledge about: {{topic}}.

Output a concise list of the most relevant facts. Aim for 5-10 bullets.
Focus on facts that would matter for answering questions about this
topic. Do not invent details; if uncertain about a specific fact,
write "uncertain" instead.

Given the knowledge below, answer the question.

Knowledge:
{{generated_knowledge_from_step_1}}

Question: {{user_question}}

If the knowledge above contradicts the question, say so explicitly.
If the knowledge is insufficient to answer, say "I don't have enough
information."

Two prompts; the first's output becomes the second's input. The pattern is just prompt chaining with a knowledge-recall step.

The single-prompt version (latency-friendly)#

For latency-sensitive applications, you can collapse both steps into a single prompt:

Answer the question below in two phases.

Phase 1 — recall: list the relevant background knowledge as bullets.
Phase 2 — answer: provide the final answer using the knowledge above.
Mark each phase with its label.

If you don't have relevant knowledge, say so in Phase 1 and decline
to answer in Phase 2 instead of guessing.

Question: {{user_question}}

Phase 1 — recall:

Trades a little reliability for half the latency and token cost. For most production tasks, this is the right trade-off.

When Generated Knowledge pays off#

When NOT to use it#

• Knowledge that's outside the model's training. Generating knowledge about your private product or post-training events produces fabrications. Use real RAG.
• Pure logic or math tasks. The model doesn't need to recall facts; it needs to reason. Use Chain-of-Thought instead.
• Simple lookups. "What's the capital of France?" doesn't need a knowledge-recall step. Generated Knowledge is for questions that depend on multiple facts.

Going further: production patterns#

Confidence-tagged recall#

Have the recall step output each fact with a confidence score (HIGH / MEDIUM / LOW or 1-5). In the answering step, instruct the model to weight high-confidence facts more heavily and explicitly note when it's relying on low-confidence facts. Doesn't eliminate hallucination but makes it more visible to downstream reviewers.

Validate recall against a source#

For high-stakes use cases, run the recall step, then validate each fact against a real source (a vector store, a database lookup, a web search). Drop unverified facts before the answering step. Effectively converts Generated Knowledge into RAG with a smarter query generator on top.

Multiple recall passes#

For genuinely hard questions, recall facts from multiple angles before answering: " What relevant scientific facts exist? What historical context applies? What practical considerations matter?" Each angle is a separate recall step. Costs more; produces richer grounding for genuinely complex questions.

Combine with self-consistency#

For high-stakes reasoning over recalled knowledge, run the answering step N times at temperature 0.7+ and take the majority. Same pattern as self-consistency applied on top of Generated Knowledge. Expensive but the most accurate non-RAG-non-tool-using pattern available.

Common mistakes#

• Generic knowledge prompts. "Generate knowledge about this topic" produces generic fluff. Be specific about what kind of knowledge would help — "list relevant physical sizes," "list applicable regulations," "list known edge cases."
• Ignoring uncertainty signals. If Step 1 outputs "uncertain," that's information. Don't blow past it in Step 2 — flag low-confidence answers.
• Using it as a substitute for RAG on private data. The model can't generate knowledge it doesn't have. Don't pretend otherwise — use real retrieval.
• Treating recalled knowledge as ground truth. The model is still working from training memory; nothing was looked up. For customer-facing factual claims, validate against an authoritative source.

Quick reference#

What to read next#

For the real-data version of this pattern, Retrieval-Augmented Generation. To layer reasoning on top of recalled knowledge, Chain-of-Thought. And to chain Generated Knowledge into bigger workflows, prompt chaining.