40 Companion guide and verification record
The code follows the same learning ladder
Unpack the companion into a new directory. Keep its examples and data-generation scripts together. Commands in the book state when to run from the companion root and when to change into a project directory. Do not mix those working directories silently; a relative path is resolved from the current directory.
The companion is a collection of separate small projects. It intentionally does not have one global requirements file. A CPU tabular environment, a pinned image-diffusion environment, and a current Transformers environment have different compatibility needs. Use the requirements and README beside the project you are running.
| Project directory | Main result | First useful check |
|---|---|---|
| examples/first-model | A three-parameter classifier and JSON model | Run train.py and predict.py with only Python |
| examples/tiny-ml | Tabular prediction, image classification, one-object detection, masks and contours | Run the CPU tabular project, then inspect generated images and masks |
| examples/tiny-transformer | A byte-level causal model trained from random weights | Generate data, then run check_model.py in the pinned torch environment |
| examples/embeddings | Keyword baseline, neural retrieval adaptation, saved-index search | Generate data and measure the lexical baseline before neural training |
| examples/llm | Full, LoRA, and QLoRA adaptation plus structured-output scoring | Run test_offline.py before installing or downloading models |
| examples/decision_pointer | A Qwen-derived candidate-option scorer | Run dependency-free numerical tests before model training |
| examples/asr | Audio transcript validation, current small ASR adaptation and CPU/GPU transcription | Run manifest and WER/CER checks before downloading a model |
| examples/diffusion | Image LoRA and a tiny waveform diffusion model | Validate generated images and audio before any neural run |
| examples/shared | Small budgeting and environment-inspection utilities | Run the memory worksheet with your own stated assumptions |
What was actually executed
The dependency-free first classifier was trained, saved, reloaded, and used for a fresh prediction. Its fixed synthetic validation accuracy was 0.96 and its separately generated test accuracy was 0.985. Those values are educational observations on the supplied synthetic rule.
The CPU tabular classification and regression projects were executed with the versions recorded in their verification file. The lexical retrieval baseline, dataset generators, image and mask checks, retrieval metrics, audio file audits, numerical decision-model tests, and offline LLM parser tests were also run. The final companion includes per-project validation records with exact commands or checked behaviors.
Python syntax compilation and shell syntax checks were performed where appropriate. Independent source review checked important model APIs, masking logic, memory assumptions, tagged training code, calibration boundaries, and resume behavior. Several implementation defects were corrected during that review, including training-resume provenance and malformed tool-output scoring.
What was not executed
No neural model training or inference was performed on the reader's RTX GPU while preparing this edition. The authoring environment did not contain the necessary PyTorch model runtime for those neural paths. No large pretrained checkpoints were downloaded for an end-to-end reproduction. GPU peak-memory figures and wall-clock estimates in planning examples are calculations or starting assumptions unless explicitly identified as measurements from a named source.
Syntax checks do not prove that a dependency set resolves, that a model download is accessible, that a device kernel is supported, or that a training run improves quality. The pinned neural environments are inspected reference targets. Complete the local smoke tests before treating them as a working lockfile on your machine.
Read every project's exact source-version, dependency, and local-modification instructions. A public trainer can contain stale defaults or version conflicts even when its main idea is correct. A copied command without its associated source version and documented changes is a different experiment.
Your local acceptance checklist
First, verify the interpreter, package versions, device, and free storage. Second, generate or validate a tiny dataset and inspect the exact encoded input and targets. Third, run one complete update and confirm finite loss, gradients, and changed parameters. Fourth, save, reload in a fresh process, and compare outputs. Fifth, test the intended CPU or GPU inference path on a new input.
Then test the maximum supported input shape, evaluation, and checkpoint writing. Test a deliberate resume only where the project implements optimizer recovery; otherwise record that limitation and use short runs or add and test recovery before a long job. Record measured memory and throughput. Run the fixed baseline and candidate evaluation before increasing the training budget. Freeze the environment only after these checks pass.
If a check fails, keep its error and the environment record. Do not remove version pins at random until the command happens to run. Identify the incompatible component, change it deliberately, repeat the smoke test, and record the new validated environment.
Where to keep your own evidence
Each project should have a runs directory with a unique name for each experiment. Keep configuration, data hashes, logs, metrics, selected outputs, checkpoints, and a short decision note. Use the supplied data-card and model-card patterns as a starting point, and expand them when the task's consequences require more documentation.
The book's examples demonstrate mechanics and disciplined experimentation. Your own evidence determines whether a resulting model is useful for your application.