Follow Ben From Beginner AI Books to His First Local Model

By Sheng Pang · Published · 9 min read · Fictional learning story

AI in practice ai books learning ai software engineers language models local ai

Ben fixed a bug before lunch, then spent the break wondering whether he was learning the wrong things. He was a software engineer who could build a useful application and find the query slowing it down. That morning, a colleague had shown him code written with an AI assistant. Some of it needed fixing, but it had arrived quickly. Ben went back to his own screen with an uncomfortable question about how much of his working day a machine could learn to do.

That evening he searched for books about AI. His browser soon contained a maths textbook, a guide to chatbots and a discussion about whether computers could think. He could not tell which problem he was meant to solve first. Rather than order the whole pile, he wrote a small goal in his notebook. He wanted to understand enough to build a learning program, explain its mistakes and eventually run a language model he had trained himself.

He began with Artificial Intelligence by Melanie Mitchell, subtitled A Guide for Thinking Humans. It was a book about ideas and their limits, rather than instructions for writing a training program. Ben read about learning systems and the trouble with judging intelligence from an impressive demonstration. He had been using AI as a single word for almost anything that worried him. By the time he returned the book, he could ask a narrower question about what a particular system had actually learned.

He tried to turn his notes into a program and realized he did not know how to write even one weight update. His next choice was Andrew W. Trask's Grokking Deep Learning. The book used Python and NumPy to build neural networks from small calculations. Its starting point suited someone who already programmed but had never trained a network. Ben checked that he could work with Python arrays before going further.

Over the following evenings he typed the early examples and stopped them midway through a calculation. A prediction depended on adjustable numbers called weights. The code compared its prediction with a target, measured an error and changed the weights. Ben could inspect those steps instead of calling a distant service and hoping. When he changed an input and saw the prediction move, the new connection between the code and the result held his attention.

Then he broke it. He combined arrays whose shapes did not fit, tried changing a bracket and made the error less understandable. His usual debugging habits finally rescued him. He wrote down what each dimension represented and traced the values through the operation. The problem was no longer an angry block of maths. It was a mismatch between the calculation he intended and the data he had supplied.

That was when Mathematics for Machine Learning joined his desk. Its authors were Marc Peter Deisenroth, A. Aldo Faisal and Cheng Soon Ong. Ben used the author-provided free PDF as a reference when vectors or gradients stopped making sense. He did not try to finish it before touching Python again. Some pages needed a slower read than his programming books. He studied the part blocking his experiment, worked a small example on paper and returned to the code.

The mathematical language gradually became less alarming. A gradient described how the error would change as a weight changed. Matrix operations gave him a way to combine values without writing a separate line for every connection. He could connect the notation to the arrays he had just inspected. He still paused at difficult derivations, but he now knew what question he was trying to answer when he opened the reference.

A few weeks later, Ben was using a practice network to sort support requests into billing problems and login problems. He wrote made-up requests rather than copy private work records. He tested the network on the same cases he had used to train it, and its answers looked encouraging. Then a new request about resetting a password landed in the billing group. Ben kept the failed case on screen and looked again at how he had been checking the model.

He looked up evaluation in Aurélien Géron's Hands-On Machine Learning with Scikit-Learn and PyTorch while keeping the classifier open. He chose the PyTorch version deliberately, since the older books using Keras and TensorFlow had similar names. Géron's treatment of a complete machine learning project gave him a way to organize the next attempt. Ben separated data for training from data for validation and kept a final test set aside. He also compared the classifier with a simple rule instead of assuming a network deserved to win.

The rule did rather well. Ben was offended for a moment, then realized it had saved him from building a complicated solution without checking a plain one. He used validation results to guide changes and left the final test alone until he was ready to evaluate. Working through the PyTorch material also helped him connect tensors and automatic gradients to his earlier NumPy calculations. The framework handled useful machinery, while Ben remained responsible for what he asked it to learn.

He changed his reading habit after that. Each session ended with a small alteration to an example and a note about what happened. Sometimes he changed the data. Sometimes he closed the book and tried to explain why the update moved a weight. If his explanation became a cloud of technical words, he opened the example again. Progress felt slower than finishing chapters, but he could remember what had gone wrong and how he had checked it.

Only then did he start Sebastian Raschka's Build a Large Language Model From Scratch. The book worked through a GPT-style model in Python and PyTorch, including text processing, attention and training. Ben now recognized much of the machinery around the unfamiliar parts. He also read the PyTorch appendix when a library operation puzzled him. This was the harder book in his path, and he gave it space on the desk rather than squeezing it into the last minutes before bed.

Text introduced a new set of mistakes. A tokenizer converted text into pieces represented by numbers, and the model used those numbers to produce predictions. Ben had to understand how input text and its expected continuation were lined up for training. Later, he stepped through attention, where information from the available text affected the calculation. Keeping future tokens hidden from the prediction took careful checking. A program could run successfully while quietly giving itself the answer.

When he assembled the model, its first output was poor. Its weights had not learned from training data, so Ben went back to check the calculations rather than expecting useful replies. He put the model diagram beside his code and followed a batch through it. Once he could explain where the predictions came from, he moved on to the training loop.

He kept the experiment small, using a reduced configuration and a small teaching text. The book and its code supported this kind of educational exercise, rather than a promise to train a competitive assistant on a laptop. Ben watched training loss alongside validation loss, checking how badly predictions missed their targets. He also read the generated text. A lower error on material the model had already studied could still come with repetition and poor results elsewhere.

One evening, the same prompt produced different continuations from the same model. Ben had enabled sampling, which could choose between possible next tokens rather than always taking the top choice. He recorded the random seed and sampling settings before comparing changes. The memory and computing limits of local models also helped him keep the experiment modest. He was learning why he had chosen the small configuration, rather than waiting for a large run to make a poor decision expensive.

Eventually he saved the weights from his own training run. He kept the matching model configuration and code with them, along with the tokenizer details needed to turn text into numbers and back. The book also showed how to load existing pretrained weights, but he kept that experiment separate. Replacing his weights with somebody else's would have changed what this particular test demonstrated. He wanted to know whether the program he had just trained could survive being closed.

Ben stopped the process and started a fresh one. He rebuilt the same model structure, loaded his saved weights and put the model in evaluation mode. With the same tokenizer ready, he entered a short prompt and ran generation locally. The program continued it with repetitive fragments of the teaching text. Ben checked the path to the checkpoint and looked back at the fresh process. The training session was closed, but the weights he had saved were working. He could not stop grinning.

His partner came over and asked whether she could start it on the same laptop without his help. Ben opened a text file and began writing the steps. He had to include the model settings and tokenizer, not just the path to the weights. She followed the note while he watched, and he added the step he had skipped. He saved the corrected note beside the checkpoint.

The next morning he tried unfamiliar prompts. The model repeated fragments from its teaching text and handled other requests badly. Ben kept those failures in his notes rather than replacing them with its nicest output. He could now explain why training a model and making it a useful assistant involved different work. Finishing the local experiment had made the remaining questions clearer, including how to improve the data and check whether any change helped.

At work, he described the project without calling it a rival to the tools his colleagues used. He could discuss a training loop and show how he had checked saved weights. His software experience still helped him trace bad inputs and keep the experiment reproducible. When a colleague asked about adding AI to a feature, Ben asked what a wrong answer would cost and how they could test the result.

That evening, Ben put his notebook beside the books instead of opening another list of things he ought to learn. He flipped back to the first broken array calculation and recognized the problem immediately. Later pages contained failed predictions and notes about changes he had checked.

He still cared about keeping his job, but the fear no longer occupied the whole desk. He felt ready to tackle an unfamiliar task at work, even when he did not know the answer at once. Before shutting the laptop, he chose a failed prompt from his notes to investigate at the next study session.

← More AI in practice articles  ·  All articles

↑ Top