The practical decision tree

Why this matters

Everything in this module collapses into one repeatable decision tree you can run in five minutes before any LLM project: is it knowledge or behavior, do you have data and an eval, have you exhausted prompting, and is a small fine-tuned model the cheapest path to your latency or cost goal. Encoding the whole module as a single function makes the decision fast, consistent, and shareable with your team. This is the artifact you'll actually reuse — the rest of the course assumes you've run it and landed on 'yes, fine-tune.'

Demo

The demo composes the whole module into one decision tree that returns a concrete recommendation, so you never start a fine-tune on instinct again.

Try it yourself

1. Run decide() on three real projects and record what it recommends for each.
2. Reorder two checks and reason about whether the order changes any outcome (it should be intentional).
3. Add a branch for 'classification with a fixed label set' and decide where it lands.
4. Save this function as your team's pre-fine-tune gate and write one sentence on why each branch exists.

Prompt your AI

Use these three in order. Each builds on the one before.

1. Basics & terminology

In one paragraph, give me a simple decision tree for whether to fine-tune, use RAG, or just prompt.

2. Why it works (the mechanism)

Walk me through each branch of a fine-tune-vs-RAG-vs-prompt decision tree and why the order of checks matters.

3. Advanced — application & what's next

Critique this decision tree for a production setting: what edge cases (multilingual, regulated facts, multi-tenant) would I need to add branches for, and why?

References

• Hugging Face — PEFT documentation
• OpenAI — Fine-tuning guidance