Chapter 2 – Language Modeling Basics

Chapter 2 introduces the fundamental building blocks of machine learning with natural language input and outputs: tokenization, embeddings, and model evaluation frameworks. Tokenization is the process of converting input words into “tokens” that are recognizable by language models, and embeddings convert those tokens into dense numerical representations. Together, they tackle the problem of efficiently representing arbitrarily large vocabularies in machine-readable formats.

I had heard the word “embeddings”, of course, and I understood, at a high level, that embedding models are something important for LLMs, and are used to capture semantic similarity between words. More than that, I could not have told you. HPLM explains the concepts beautifully:

Imagine that you have a language with a vocabulary of 10000 words. (Note that this is a very small language. The Oxford English Dictionary contains over 500,000 words, and modern LLMs model multiple languages simultaneously.) The most straightforward way to represent a word in this vocabulary is with a one-hot vector, an array of 10000 bits, with each index in the array corresponding to a word in the vocabulary.

One-hot vectors are easy to understand and perfectly machine-readable, but they have two major drawbacks: they are incredibly memory inefficient, wasting most of their space storing useless 0s, and they fail to encode any useful relationships between words. Indices are assigned to words arbitrarily, and words that are very similar (e.g. “happy” and “glad”) may end up far away from each other, whereas words with adjacent indices may have no meaningful semantic relationship.

Word2vec

The primary insight of embeddings is that it is possible to generate an alternative representation of tokens which is both more dense than one-hot encoding and represents semantic relationships between words. HPLM goes into detail on Word2vec, a family of algorithms used to generate word embeddings. Word2vec comes in several flavors, but they all share the same core conceptual idea. Imagine a snippet of text containing a target word (in this case “cat”) and several surrounding context words:

If you were to train a neural network such that, when given the target word as input, it produces the context words with high likelihood, then if you were to pass in a similar word, one that is likely to appear in similar contexts (e.g. “kitten”), you should expect the network to produce similar output. The structure of the network looks like this: two layers, an input layer that scales from the vocabulary size down to the embedding dimension size and an output layer that does the reverse. The output of the first layer is a vector of floats, also called the embedding vector, which can be used as a dense representation of the input word when training or using a language model.

The part that blew my mind

So far so good. It makes intuitive sense that the vectors for “cat” and “kitten” should be similar i.e. close to each other in vector-space. But then, the author casually drops this bomb – these embedding vectors support simple mathematical operations. For example, if you take the embedding vector for “king”, subtract the vector for “man”, and add the vector for “woman”, you get a vector very similar to the one for “queen”.

What?

How?

That sounds completely made up.

I had a little chat with Claude, trying to understand why this might be true. Claude made the argument to me that, within the vectors for “king” and “queen”, there is some subcomponent representing the concept of “royalty”. Honestly, that seems like nonsense to me.

It gets a little clearer when I think of the operations as if they were happening in the space of training examples, or at least I can squint at it and pretend that it makes sense. Imagine all of the context examples for the word “king”. Some of them will include context about gender, many will not. When you subtract the vector for “man”, you’re not removing only the examples that include both “king” and “man”. You are removing all of the context examples for the word “man”, as if the concept of “man” is being removed from your language entirely. That doesn’t land you on some genderless concept of “monarch”; it moves you somewhere really weird.

Now, add in all of the example texts for “woman”. Not only are we adding back in some examples for “queen”, we’re also moving our whole language back from the strange universe in which “man” doesn’t exist.

Ok, no, maybe this doesn’t actually help.

Visualizing embedding vectors

Obsessed with this idea, I decided to vibe-code an app that would let me play around with more of this word vector math. You can try it out here (Word2Vec Arithmetic, GitHub repo). Over a smallish vocabulary of about 1600 words, you can add and subtract them together, and get a list of the closest resulting word vectors from a larger vocabulary of 30K words, along with a visualization of the operation in vector space. Distance is measured by cosine similarity between vectors.

The quality of an embedding model should grow as the model is trained on a larger data set, and I wanted to see if I could visualize this improvement. I trained two embedding models, one on text8, which is the first 100MB of English Wikipedia, and one on enwik9, the first 1GB of English Wikipedia. I also downloaded one pretrained embedding model, Stanford NLP’s 6-billion token GloVe vectors.

So does it work? Well, sort of.

The “king - man + woman” equation returns queen for all three vector models. Interestingly, the result vector computed by the enwik9 model is just a little bit closer to its actual vector for “queen” than the result that comes out of the GloVe model.

The impact of model size starts to show up in “walking - walk + swim”. The two larger models return “swimming”, which is pretty cute. The small text8 model returns “crawling”. Initially, I was worried that this might be a vocabulary mismatch issue, that maybe “swimming” was simply missing from the top 30K most confidently-trained tokens in the text8 model. Once I restricted all three models to a common shared vocabulary, I was able to confirm that this is a genuine example of model quality improving as model training data size increases.

Another interesting result, where you really see the impact of model quality most clearly:

But a lot of the equations are simply nonsense, and Claude’s explanation that “king - man” should expose some kind of “royalty” vector didn’t show up at all.

And with that, I’ve sufficiently scratched this itch, and I’m ready to move on to Chapter 3 – Recurrent Neural Networks.

So maybe it's embarrassing to admit this, but I never really bothered to update my mental model of LLMs beyond my (already cursory) understanding of deep learning. I did at least wrap my head around the colloquial concept of embeddings and the idea that you can represent semantic similarity between words in some machine-readable way, but I didn't go any further than that. I definitely did not do the work of understanding the math.

But now, my goal is to be able to read a HuggingFace model card, and in order to do that, I have to learn all of the vocabulary of LLM architectures and hyperparameters.

I've been steadily working my way through Andriy Burkov's phenomenal The Hundred-Page Languages Models Book. I'm finding it very easy to read, and as long as I force myself to go slowly, and especially if I make sure that I am understanding all of the sample code snippets provided, the concepts that the book presents feel like they are resting in my brain in a way that feels like I'll actually retain them over time.

Chapter 1 – Machine Learning Basics

Just like it says on the box, the first chapter of the book is a review of machine learning basics, written for an audience that is being exposed to these ideas for the very first time. Since I am not encountering machine learning for the very first time, I was able to go through most of the chapter quite quickly. For me, it got interesting when moving from generic classification algorithms to neural networks in particular.

The first bit of novel vocabulary that I encountered is the difference between a dense neural network, one in which each perceptron in a given layer is connected to every perceptron in the subsequent layer, and a convolutional neural network, in which the layers are not fully connected. The author notes that convolutional networks were originally designed for image processing, but have proved useful for certain kinds of text processing such as document classification. For me, this is interesting because one of the first bits of unfamiliar vocabulary that I encountered when browsing models in HuggingFace is that some LLMs are described as “Dense” whereas others are “Mixtures of Experts”.

I'm trying not to skip ahead, so I haven't gone looking for an explanation of why a convolutional network might perform better in some domains or applications than a dense network. I can see the biological analogy; our brains are composed of clusters of neurons that are densely connected to their close neighbors, but only loosely connected to other clusters. I can imagine an image processing network working best when allowed to develop similar clusters of expertise, for example a set of neighboring perceptrons that together perform edge detection and another cluster that handles perspective and scale. I don't really understand why a convolutional network would be better for document classification, though, and I wonder whether the clusters need to be trained independently, or whether “experts” appear emergently, given large-enough training data and a convolutional network with enough subneighborhoods.

The other novel concept for me from this chapter is the RELU activation function. RELU, or rectified linear unit, is the function:

RELU(x) = max(0, x)

What RELU does is take an input and truncate it at 0, so that the output is always positive. Apparently, RELU has been the predominantly-used activation function for neural networks since 2012. I genuinely can't fathom why. When I first studied neural networks, the default activation function was the sigmoid, which makes perfect intuitive sense if you imagine each perceptron as a baby classifier. RELU makes no sense to me at all. However, the book promises that we will come back to RELU in Chapter 4 – Transformers, so I am, for now, suspending disbelief.

A brief recap of the paper

Dr. Hicks interviewed 25 “code writers” of different levels of seniority and from different company sizes, all located in the Bay Area, on their experiences learning as a member of a software development team, with a particular focus on the experience of onboarding in an unfamiliar codebase. The themes that emerged from the interviews clustered into three main topics: the activities that code writers perform when learning a new codebase, code review as the common first instance in which a new team member receives feedback from their new teammates, and ways in which the company or team environment sends implicit and explicit messages about the value of learning.

Most interviewees described a similar set of activities performed in order to build an iteratively more accurate mental model of the new code base. This learning was actively experimental in nature: intentionally breaking things, probing for potential edge cases, and forming hypotheses about the intentions or previous decisions of the previous writers of the code. In most environments, interviewees reported that this learning was conducted individually and privately, with limited opportunities for the new team member to share what they had learned with others.

At the code review stage, interviewees reported feeling significant performance pressure. They were reluctant to use the code review as an opportunity to discuss their learning because of fear of being seen as less competent, and because of implicit or explicit messaging that communicated to them that only their output, the code artifact being reviewed, was of value, and the process that got them to that artifact was not.

The code writers' environments reinforced a message that devalued learning both implicitly and explicitly. Explicitly, time pressure was a consistent theme, and activities that promote learning, such as documentation, code comments, and mentorship and collaboration, were seen as taking time away from producing code. Implicitly, new team members observed the absence of documentation, code comments, and pair programming, and inferred that these activities would not be valued by their new employer.

Collectively, these themes combine to create cultures of what Dr. Hicks calls “learning debt”, defined as “cumulative failure to support learning, created when code writers' investment in long-term understanding is disincentivized”. Code writers working in cultures with large learning debts report feelings of loneliness, long-term stress, and demotivation.

Discussion themes

The themes and environments described by the interviewees in the paper resonated with many of us, and it felt validating to read about it as a commonly shared experience. One member of the discussion group recalled a time when, upon joining a new team as the only junior engineer, they were explicitly told by their manager that they were expected to “sink or swim”. The common theme of time pressure as a disincentive to learning was universally familiar.

An interesting reflection that we had was that, even environments that want to promote learning sometimes struggle to do so effectively because of immature practices around knowledge transfer. One participant in our discussion described being on a team with a recurring Friday morning meeting called “Knowledge Transfer”, in which a member of the team would brain-dump everything they knew about a particular part of the code base. Attendees were expected to remember and retain everything that was said in those meetings, since there was no other documentation. We also noted that effective learning often requires a teacher, and that being an effective teacher is itself a skill that is not explicitly taught in most coding environments.

Some of us have been fortunate enough to spend time in environments that do value and promote learning. Some useful practices from those environments include:

• Explicit and formal requirements to mentor others in order to be promoted to Senior Engineer
• Clearly documented onboarding expectations
  • For example, at one company, new team members were expected to reach a certain learning milestone by 3 months. However, if they failed to reach that milestone, this was explicitly named as a failure of their existing team, rather than the new employee themselves.
• Onboarding as an objectively-evaluable rubric (e.g. “can the new team member successfully deploy?”, “can the new team member successfully debug an issue?”)

We noted that all of these practices are only as effective as the managers who implement them. Individual team members are unlikely to successfully self-organize to promote a learning culture without leadership support.

Finally, we spent a little while discussing the study itself, such as how it might have been impacted by a sample of 25 Bay Area software engineers, vs code writers from other countries or cultures, or employees in other fields. One participant described working in another country with an even stronger culture of not sharing information. In software teams in that country, the participant said, if you have knowledge, it's the norm to keep it to yourself because that will help you get ahead of your peers. Another participant described the substantial formal structures that exist to scaffold learning in other fields such as mental health and medicine, which are largely absent in software engineering.

My reflections

Over the years, I've worked in software environments with very different learning cultures. Reading the paper's section on code reviews, I couldn't help but think of my first code reviews as a brand new junior engineer at Google. I know that I learned so much from those reviews, but I definitely wouldn't describe the experience as comfortable. Later, at Flatiron, when we were writing our first engineering job ladder, we intentionally put teaching, mentoring, and sharing knowledge with others as expectations for senior engineers. Flatiron had recently acquired another company where being the “go to expert” on a topic was strongly valued, and some engineers from that company were reluctant to share their unique knowledge because they feared it would harm their job security. We encoded formal expectations around knowledge sharing in our ladder (and in the company value of “Train Your Own Replacement”) as a way of pushing back against that cultural norm.

I also strongly agree with the paper's reflection that companies with strong learning cultures are those where it's safe to be seen making mistakes and where communicating about your process, and not just your results, is appreciated and rewarded. I don't need to write about blameless postmortems, plenty of others have said what needs to be said already. I haven't seen this idea about the value of showing your process said explicitly before. It made me think of a common practice on my most recent engineering team. Engineers would frequently record short videos in which they demonstrated some part of their work setup, or an experiment they had done, whether or not that experiment succeeded. The most senior and tenured engineers pioneered this practice, demonstrating to newer team members that showing your work was a behavior that would be valued within the team culture.

It's fun to read this paper while at Recurse Center, a software environment with the stated goal of being a learning culture. There are lots of explicit ways that RC promotes learning (e.g. scheduled pair coding jams and presentations), but it's also been fun to notice the implicit ways that the value of learning-promoting activity is communicated. The paper describes cultural onboarding moments in which new employees look around and note whether their more established peers are writing comments and documentation, and through that observation decide whether or not to write comments and documents. Similarly, as a new batch member, I've noticed that RC participants devote as much or more space in their daily check-in messages to coffee chats and pairing sessions with other RCers as they do to their coding output.

If you're a Recurser and would like to join us for a future discussion, we'll be meeting on Thursdays at 1pm ET for at least the next 4 weeks. I also highly recommend following Dr. Hicks on Bluesky.

I came into Recurse Center with the goal of becoming a proficient user of open source LLMs, and some vague idea of hooking an open source model up with some kind of large-scale agent management framework like GasCity and seeing if I could get the system to make something useful.

I was inspired by Vicki Boykis' recent newsletter issue, Running local models is good now, in which she describes her experience successfully getting a local open weight model to serve as her primary agentic coding tool. I love the idea of getting the benefit of an AI coding assistant without bleeding money to Anthropic. My first week at RC, I spent about a day wrestling with the setup tutorial that Vicki links to but ran into one yak-shaving problem after another.

No shade to the tutorial – it's perfectly clear and the steps work perfectly. It's just that, when I followed the tutorial, I indeed got LM Studio up and running, I successfully downloaded the recommended Gemma model from HuggingFace, I hooked it up with Pi as my coding harness... And then watched my computer, with its poor sad 8GB of RAM, become completely unresponsive as soon as I started trying to use my new setup. Flipping back to Vicki's post, I saw that her computer has 64GB of RAM. Fancy!

Ok, fine, maybe local models are not in my immediate future. But luckily, Recurse Center has a partnership with Modal, where we can get some free credits to run AI projects in their cloud. My next idea was to host an inference server on Modal and have Pi, running on my machine, make calls out to that server. Modal has a tutorial and example script for spinning up an inference server, which I downloaded and ran.

Again, props to the folks at Modal – the tutorial script worked smoothly out of the box. I didn't change any of the defaults, just spun up the inference server and pointed Pi at it. And promptly burned $2.48 in Modal credits writing a Python function to generate the next number in a Fibonacci sequence.

Now what?

Let's back up.

In his tutorial (How to run a local coding agent with Gemma 4 and Pi), Pat Loeber recommends using Gemma 4 26B A4B (Q4_K_M). He describes it as a “mixture of experts” model, and suggests downloading the quantized GGUF version. I have no idea what any of those words mean.

Vicki Boykis recommends gemma-4-12b-qat, noting that it is “more recent and smaller and faster, without much sacrifice in accuracy”. Sounds good to me, I like smaller, faster, and more accurate. Unfortunately, before I even tried to download it, LM Studio informed me that this model is too large to run successfully on my computer. Pat's model is much larger, an obvious non-starter.

The model that I did semi-successfully run locally was gemma-4-e2b. Is that a good model? A bad model? If it had not completely frozen my computer, would it have done anything actually useful? How am I to know?

Modal's inference tutorial script recommends the same model as Pat, google/gemma-4-26B-A4B-it, but runs it on their third-most-expensive GPU, an H200. Since I wasn't excited to set quite that much money on fire quite that fast, I tried to sub out Vicki's recommended model.

Here's where it got exciting. I tried to modify the Modal script to use gemma-4-12b-qat and a much cheaper GPU, only to discover that vLLM, the model serving framework that the tutorial relies on, doesn't support the Gemma 4 12B models (open bug report here).

At this point, I had a series of very frustrating chats with Claude, in which I tried to select a different model, one that would effectively trade off low cost with adequate performance as a coding agent. But ultimately, I felt like I just really had no idea what was going on. What's the difference between 12B vs 26B vs E2B? What does QAT mean? Why would I pick a model from the Gemma 4 family vs Claude's suggestion of GPT-OSS-20B?

Changing direction

One of my goals during this batch at Recurse Center is to stop feeling like an imposter when it comes to large language models. Not so much how to use them, which honestly, I feel fine about, but to have a better mental model of what's going on under the hood, and how the different models vary. Maybe a good way to express this goal is, “I'd like to be able to read a model card on HuggingFace and understand what all the words mean, both individually and together.”

A fellow Recurser recommended Andriy Burkov's The Hundred-Page Languages Models Book as a good way to go all the way back to basics. I'm about halfway through Chapter 2 and finding it to be a fantastic read: clear, accessible, and the right mix of theory and implementation. I'll share more thoughts on what I've read so far, and what I've started to implement as a result, in a future post.