Skip to main content

0.4 Recommended Learning Path

Recommended Learning Path Selection Diagram

If you are unsure, choose the beginner path: Chapter 1 -> Chapter 9 in order, one small output per stage, then choose one specialization from Chapters 10-12 only when you need it.

Your goalFirst route
I am newFollow Chapters 1-9 before branching
I already codeSkim 1-6, focus on 7-9, then pick a specialization
I need a portfolioKeep README, screenshots, logs, metrics, traces, failures
I care about modelsSpend more time on math, ML, DL, Transformer, then choose CV/NLP/multimodal depth

Pick A Route

RouteBest forChaptersWhat to produce
Beginner full pathNew learners or career switchers1 -> 9, then one of 10-12One runnable mini project after each main track, plus one specialization demo
Builder pathDevelopers who want LLM apps quicklyskim 1-6, focus 7 -> 9, then 12 if multimodal is neededRAG app, Agent trace, evaluation notes, safety boundary
Model pathLearners who want deeper ML intuition1 -> 7, then 10 or 11 based on data typeModel experiments, metric comparisons, failure analysis
Portfolio pathJob-focused learners1 -> 9 with stronger README work, then one capstone directionA public project story with setup, screenshots, logs, metrics, traces, limits

Stage Exit Checks

Do not judge progress by pages read. Judge it by evidence.

StageChaptersMinimum evidenceDeeper evidence for experienced learners
Foundations1-3A reproducible project folder, Python scripts, cleaned data, chartsREADME rerun test, edge cases, data quality notes
Model understanding4-6One model experiment with a metric and failure samplesBias/variance notes, ablation, training diagnosis
LLM applications7-9Prompt tests, RAG retrieval trace, Agent tool traceFixed eval set, safety boundary, cost/latency notes
Specialization10-12One vision, NLP, or multimodal demo with saved inputs and outputsDomain metric, review checklist, deployment constraint

The specialization chapters are not a reward for finishing everything. They are a deliberate branch: choose them when the product needs images, text pipelines, multimodal assets, or domain-specific evaluation.

Weekly Loop

Use the same loop every week:

read briefly -> run one thing -> change one condition -> record evidence -> write one reflection

The reflection can be short. Good examples:

  • What failed first?
  • What input changed the output most?
  • What evidence would convince another developer?
  • What would break if this became a real user-facing feature?

When To Skip Or Slow Down

Skip only when you can pass the chapter check without guessing. Slow down when you cannot explain the output, cannot rerun the code, or cannot tell whether the result is good. Experienced learners should slow down on evaluation, failure modes, and production constraints even when the demo feels easy.

Do not switch routes every week. Read briefly, run something, keep evidence, then continue to Chapter 1.