376 Unit 3: Architectures

• What’s a hidden state?
  • It’s the output of a layer of a neural network.
  • It’s an embedding of the part of the input needed to continue the current calculation (e.g., predict the next token).
• Why is just the start token’s hidden state typically used for classification?
  • Any individual token would otherwise contain some information from that single token as well as information from the entire sequence.
  • Note: It can attend to the entire sequence (in a bidirectional model like BERT).
  • Its hidden state representation doesn’t need to be used for anything else (unlike other tokens, which need to be able to decode to a token.)
  • There may be better ways to do this, but this is a common approach.
• Why do we need padding?
  • Everything needs to be a tensor.
  • Tensors generally need to be rectangular, not ragged.
  • But when we put multiple sentences into a batch, they might have different lengths.
  • So we pad them to the same length.
  • (We could use ragged tensors instead, but hardware support for them isn’t as good.)
  • This is mainly a concern when training. At inference time we often only have one sequence at a time. (unless we’re doing beam search, which we’ll talk about later.)
• Why is GPT-3 encoder-only?
  • See the Outline.

These notes are reference material for Unit 3 (Architectures). The primary focus of class is self-attention and Transformers; these notes cover other architectures for comparison.

Deep Neural Net = Stack of Layers

Neural networks are built from modular components, often connected sequentially:

• Linear transformation (“Dense”, “fully connected”)
• Multiple linear layers: MLP / “Feed-forward”
• Convolution and Pooling
• Self-Attention
• Recurrent (RNN, LSTM)
• Normalization (BatchNorm, LayerNorm)
• Dropout

The key difference between architectures is their connectivity structure:

• Fully Connected: Perceptron, MLP — every input connects to every output within a layer
• Fixed Local Connections: Convolutional networks (CNN) — local spatial connections
• Fixed Temporal Connections: Recurrent networks (RNN) — information flows forward through time
• Dynamic Connections: Transformer — connections are computed on the fly via attention

Feed-Forward / MLP

A feed-forward network (or multi-layer perceptron) is a stack of linear transformations with nonlinearities between them:

where $f_1$ and $f_2$ are both linear transformations ($f_i(x) = x W_i + b$) and $\text{ReLU}(x) = \max(0, x)$ applied elementwise. Other nonlinearities (GELU, SiLU, etc.) are sometimes used instead of ReLU.

Key properties:

• Universal function approximator — can represent any function in principle, but not necessarily efficiently
• Fixed information flow within each layer

Applying an MLP to a Sequence

There are two options for processing a sequence with an MLP:

In Transformers, the MLP layers use Option 2 (applied independently to each position). Information sharing between positions happens in the attention layers instead.

Convolutional Networks (CNN)

A convolutional layer is essentially a feed-forward network applied to a small patch (or “window”) of the input, slid across the entire input to produce many outputs.

Key properties:

• Information flow is fixed but local — each output depends only on a small neighborhood of the input
• Parallel — all patches can be computed at the same time
• Summarize regions of the input via pooling (e.g., take the max or average over a region)
• Efficient at inference time
• Excellent for data with spatial structure (images, audio spectrograms)

How they work: A small set of learnable weights (the “kernel” or “filter”) slides across the input. At each position, the kernel computes a weighted sum of the local patch. Different kernels detect different features — edges, textures, patterns. Stacking multiple convolutional layers lets the network build up from simple local features to complex high-level concepts.

Resources

• Image Kernels explained visually — interactive demo of what convolution does to an image
• CS231n: Convolutional Neural Networks for Visual Recognition — how to use convolutions in a neural network
• Feature Visualization — what convolutional networks learn at each layer

Recurrent Networks (RNN, LSTM)

A recurrent network processes a sequence one step at a time, maintaining a “hidden state” that summarizes everything seen so far. At each time step, the network takes the current input and the previous hidden state, and produces an updated hidden state and an output.

Key properties:

• Sequential processing — one step at a time
• Maintains and updates a hidden state that acts as a compressed memory of the sequence so far
• Can handle variable-length sequences naturally
• Efficient at inference time (constant memory per step)
• Difficult to learn long-range dependencies — information from early in the sequence tends to get “washed out” as the hidden state is updated many times

LSTM (Long Short-Term Memory) is a variant of RNN designed to mitigate the long-range dependency problem. It uses a gating mechanism to selectively remember or forget information, which helps gradients flow over longer sequences. LSTMs were the dominant architecture for sequence tasks (translation, speech recognition, text generation) before Transformers.

Compare and Contrast

When to Use Each

• MLP: When inputs are fixed-size and there is no meaningful spatial or sequential structure (e.g., tabular data). Also used as a component within other architectures (the “FFN” layers in a Transformer).
• CNN: When the data has local spatial structure and translation invariance matters (e.g., detecting an object regardless of where it appears in an image). Still widely used in computer vision, sometimes combined with Transformers.
• RNN/LSTM: Largely superseded by Transformers for most tasks, but still relevant for streaming/real-time applications where you process one element at a time and need constant memory. Recent “state space models” (like Mamba) revive some RNN ideas with better parallelism.
• Transformer: The default choice for most modern deep learning tasks, especially in NLP. Scales well with data and compute. The key advantage is that attention lets the model learn which parts of the input to focus on, rather than relying on fixed connectivity patterns.

Generative AI systems learn from massive datasets — text scraped from the web, books, images, code, conversations. These datasets aren’t neutral. They carry the assumptions, biases, and interests of whoever collected them, and the people whose work (or data) was collected. As people called to pursue shalom — right relationships with God, others, and creation — how we think about training data is not just a technical question.

This Discussion addresses the course objective Overall-Impact and connects to OG-SelfSupervised.

Initial Post

Find a specific, sourced example of a training data issue that matters to you. This could connect to your major, your community, your creative interests, your faith, or something you’ve encountered using AI tools.

Search for a recent news article, research paper, blog post, legal filing, or firsthand account. Topics are moving fast — look for current reporting on training data lawsuits and legislation, AI-generated content feeding back into training sets (“model collapse”), bias in generated images or text, the working conditions of people hired to label and filter training data, or how specific communities (artists, writers, open-source developers, speakers of minority languages) have been affected. Good starting points include major news outlets’ AI coverage, the PAIR Explorables interactive essays, arXiv preprints, ACM opinion pieces, or your own experience.

Some angles to consider:

• Whose work is in the data? Copyright, consent, compensation — and what happens when creators can’t opt out.
• Whose world does the data reflect? Which voices, languages, and perspectives are overrepresented or missing, and how that shapes what models generate.
• What happens at scale? When models train on their own outputs, when training sets include benchmark answers, when AI-generated content displaces human participation in online communities.
• Who benefits and who bears the cost? The people paid pennies per task to label toxic content, the energy and water consumed by data centers, the companies that profit versus the communities whose data was collected.

In your post (~150-250 words):

1. Describe the issue with a specific example. Name the model, dataset, company, or community involved.
2. Ground your analysis in a framework you find compelling (see below). Don’t just say “this is bad” — articulate what value or obligation is at stake and why it matters.
3. Take a position: What should be done differently? By whom?

Cite your source clearly enough that a classmate could find it.

Replies

Reply to at least two classmates (~75-150 words each). Your replies should do both of the following:

1. Engage with their argument: Do you agree with their position? What would you add, push back on, or complicate?
2. Bring a different lens: If they used a theological framework, try responding with a secular one (or vice versa). If they focused on creators’ rights, consider the perspective of users or model developers. The goal is to deepen the conversation, not just agree.

Rubric

• Initial post is on time and addresses the prompt
• Post identifies a specific, sourced training data issue
• Post grounds its analysis in a named ethical or theological concept
• Post takes a clear position on what should change
• Replies engage substantively with classmates’ arguments
• Replies bring a different perspective or framework
• Writing is clear, specific, and well-cited

Overview

In the u09 logits notebook, you implemented perplexity for a single model on short texts. In this assignment, you will extend that work to compare multiple language models of different sizes, analyzing how performance scales with model size.

Learning Objectives

This assignment addresses the following course objectives:

• [TM-LLM-Generation]
• [OG-LLM-Eval]
• [TM-Scaling]
• [OG-Eval-Experiment]

Students may also use this exercise to demonstrate additional objectives, such as:

• [TM-LLM-Compute]
• [OG-LLM-Tokenization]

Task

Your goal is to evaluate how language model performance (measured by perplexity) changes with model size:

1. Select two or more language models from the Qwen2.5 family (e.g., 0.5B, 1.5B, 3B parameters)
2. Evaluate these models on a set of short stories by computing perplexity for each model on the same stories
3. Create a plot showing how perplexity changes with model size
4. Analyze which stories or which parts of stories are most challenging for the models

Model Options

Use models from the Qwen2.5 family, which are available on the Hugging Face model hub:

• Qwen/Qwen2.5-0.5B (0.5 billion parameters)
• Qwen/Qwen2.5-1.5B (1.5 billion parameters)
• Qwen/Qwen2.5-3B (3 billion parameters, if your system can handle it)

All Qwen2.5 sizes share the same tokenizer, which makes perplexity comparison across sizes fair.

Memory tip: Load models with torch_dtype=torch.float16 (or torch.bfloat16) to reduce memory usage:

from transformers import AutoModelForCausalLM, AutoTokenizer

model_name = "Qwen/Qwen2.5-0.5B"
tokenizer = AutoTokenizer.from_pretrained(model_name)
model = AutoModelForCausalLM.from_pretrained(model_name, torch_dtype=torch.float16)

Dataset

Use the TinyStories dataset, which contains short stories. You can load it from the Hugging Face hub using the datasets library:

from datasets import load_dataset
dataset = load_dataset("roneneldan/TinyStories", split="train[:100]")
# Take a sample of stories for evaluation
stories = dataset.select(range(50))

Computing Perplexity

Adapt your work from the u09 logits notebook, where you began implementing perplexity. I still recommend computing the loss manually (extracting logits, indexing the correct token probabilities, averaging) rather than using shortcut approaches like passing labels to the model. The main addition here is running it across multiple models and stories.

Here’s a suggested function signature (you may want to return additional values for token-level analysis, or take additional arguments for context to prepend):

def compute_perplexity(model, tokenizer, text):
    """
    Compute the perplexity of a model on a given text.
    
    Args:
        model: A language model that returns logits
        tokenizer: The tokenizer associated with the model
        text: The text to evaluate
        
    Returns:
        float: The perplexity of the model on the text
    """
    # Your implementation here

Caution about indexing: Pay careful attention to token positions! Remember that when predicting the token at position i, you use the logits from position i-1. This off-by-one error is easy to make.

For data collection, consider creating a structure like:

results = []

# For each model and story
for model_name in model_names:
    for story_idx, story in enumerate(stories):
        # Compute perplexity
        perplexity = compute_perplexity(model, tokenizer, story["text"])
        
        # Store results
        results.append({
            "model_name": model_name,
            "story_idx": story_idx,
            "perplexity": perplexity
        })

# Convert to DataFrame for easier analysis
import pandas as pd
results_df = pd.DataFrame(results)

Analysis and Submission

Create a Jupyter notebook that includes:

1. Implementation of the perplexity calculation
2. A table showing perplexity for each model on each story
3. A plot showing how perplexity changes with model size
4. Analysis of results:
   • Which models performed best?
   • Is there a consistent relationship between model size and perplexity?
   • Which stories had the highest/lowest perplexity across models? (look at their full text, don’t make assumptions)
   • Optional: Identify specific tokens or sentence positions that were most challenging for the models

Grading Rubric

Extension (for E-level work)

Implement context: instead of just computing perplexity on the full story, only compute it on part of the story while providing the previous sentences as context.

• Compare perplexity when computing it with different prompt lengths (e.g., using first 1, 2, or 3 sentences as context).
• Prepend an “instruction”, like “Write a story about ___”, to see how it affects perplexity.
  • Does this vary between base models vs instruction-tuned variants (e.g., Qwen2.5-0.5B vs Qwen2.5-0.5B-Instruct)? For the Instruct models, you may want to use the chat template to format the input as a conversation.
  • Try a few different variants of the instruction. Does more specific instructions (e.g., “Write a story about a dragon and a princess”) lead to lower perplexity than vague instructions (“Write a story”)–and can you disentangle specificity from keyword overlap (e.g., asking for a story about a “dragon” vs about a “mythical flying creature”)?
• Analyze perplexity on different categories of text (e.g., stories vs. news vs. code)
• Implement a token-level analysis that highlights exactly where models struggle most. Can you identify any patterns?

In this lab, you’ll trace through parts of the implementation of a Transformer language model, focusing on the self-attention mechanism. We’ll compare the performance of a Transformer model with a baseline that only uses a feedforward network (MLP).

This lab address the following course objectives:

• [NC-Embeddings]
• [NC-SelfAttention]
• [NC-TransformerDataFlow]
• [MS-LLM-Generation]
• [MS-LLM-Tokenization]

Task

Start with this notebook:

Implementing self-attention (name: u10n1-implement-transformer.ipynb; show preview, open in Colab)

You may find it helpful to refer to The Illustrated GPT-2 (Visualizing Transformer Language Models) – Jay Alammar – Visualizing machine learning one concept at a time.

Extension idea

• measure how much this network speeds up when you move it to a GPU (you may need to torch.compile it first)
• Other extensions are described on the Architectural Experimentation page.