Milestone map
Milestone map
3 milestones
Understand Transformer Architecture Through Implementation
10–18 weeks (includes attention mechanism mathematical foundations)
Study the transformer architecture in depth: self-attention, multi-head attention, positional encoding, layer normalisation, and feed-forward sublayers. Implement a minimal transformer (encoder only or decoder only) in PyTorch without using HuggingFace Transformers or similar high-level libraries — the architecture must be implemented from attention matrices up. Train it on a small sequence modelling task.
Proof required
Submit: a public GitHub repository (or Colab) containing your transformer implementation with at least self-attention, multi-head attention, positional encoding, layer norm, and feed-forward sublayers coded from scratch; a training loss plot showing the model learns on a small task; and a written explanation (300 words) of why multi-head attention produces richer representations than single-head attention. An ML researcher or senior ML engineer must confirm the implementation is architecturally correct.
What gets checked
- Implementation builds the transformer from attention matrices — no HuggingFace Transformers or pre-built attention modules used
- Training loss plot shows learning on a small sequence task — not a flat loss curve
- An ML researcher or senior ML engineer has confirmed the architectural implementation is correct
Common mistakes
- Using HuggingFace Transformers' attention implementation directly — the proof requires implementing attention from matrix operations
- Training on a task where a flat loss curve is expected — must show the model is actually learning
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Is the attention mechanism implemented from matrix operations — no HuggingFace attention module?
- Does the training loss plot show the model is actually learning on the small task?
- Ask: 'why does positional encoding need to encode position at all?' — tests understanding of the permutation-invariance issue in attention
Study Pretraining, Fine-Tuning, and RLHF at Technical Depth
8–14 weeks (after milestone 1)
Study the key training stages for LLMs at technical depth: pretraining (next-token prediction objective, data curation, scaling laws), supervised fine-tuning (instruction tuning, format), and alignment (RLHF, PPO, DPO). Write a technical analysis (600 words) of the training pipeline for GPT-3 or LLaMA 2, explaining each stage, what data was used, and what problem each stage solved that the previous stage did not.
Proof required
Submit: a technical analysis (at least 600 words) of the full training pipeline for a specific published LLM (GPT-3, LLaMA 2, or equivalent), citing the original papers; and a worked mathematical example (written, not code) showing how the PPO or DPO objective is computed for a specific token sequence. An ML researcher or senior ML engineer must review and confirm the analysis is technically accurate.
What gets checked
- Analysis cites primary papers — the original GPT-3 or LLaMA 2 paper, not blog summaries
- Worked mathematical example for PPO or DPO is correct — not a high-level description of what the objective does
- An ML researcher has confirmed the analysis is technically accurate
Common mistakes
- Analysis that summarises blog posts without citing primary papers — must engage with the actual methodology sections
- Worked mathematical example that describes the objective without computing it for a specific example
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the analysis cite primary papers — not blog summaries?
- Is the worked mathematical example for PPO or DPO a genuine computation — not a description?
- Ask: 'what problem does RLHF solve that supervised fine-tuning alone does not?' — tests understanding of the alignment stage
Analyse Limitations and Present to an Expert Reviewer
4–8 weeks (after milestone 2)
Write a technical analysis (400 words) of the three most significant technical limitations of current LLM architectures — not capability limitations, but architectural or training constraints — and what the most credible proposed solutions are. Present to an ML researcher or senior ML engineer who challenges your analysis in at least two specific places.
Proof required
Submit: a technical analysis (at least 400 words) of three architectural or training limitations of current LLMs, with proposed solutions and primary citations; and a recording or transcript of a live review session with an ML researcher where they challenged at least two specific claims.
What gets checked
- Analysis addresses architectural or training limitations specifically — not general capability gaps
- At least two proposed solutions cite primary research — not blog descriptions of research
- An ML researcher challenged at least two specific claims in a documented live review
Common mistakes
- Analysis that describes capability limitations ('LLMs can't reason') without connecting to architectural constraints
- Proposed solutions drawn from blog posts rather than primary papers
Resources
Foundationstart here
Depthgo deeper
What a verifier looks for
- Does the analysis address architectural or training constraints — not general capability gaps?
- Do the proposed solutions cite primary papers?
- Were at least two specific claims challenged in the documented live review?