📚 Auto-publish: Add/update 2 blog posts
Some checks failed
Hugo Publish CI / build-and-deploy (push) Failing after 11m2s
Some checks failed
Hugo Publish CI / build-and-deploy (push) Failing after 11m2s
Generated on: Sat Aug 2 18:07:06 PDT 2025 Source: md-personal repository
This commit is contained in:
108
content/posts/a-deep-dive-into-ppo-for-language-models.md
Normal file
108
content/posts/a-deep-dive-into-ppo-for-language-models.md
Normal file
@@ -0,0 +1,108 @@
|
||||
---
|
||||
title: "A Deep Dive into PPO for Language Models"
|
||||
date: 2025-08-02T17:34:34-0700
|
||||
draft: false
|
||||
---
|
||||
|
||||
|
||||
Large Language Models (LLMs) have demonstrated astonishing capabilities, but out-of-the-box, they are simply powerful text predictors. They don't inherently understand what makes a response helpful, harmless, or aligned with human values. The technique that has proven most effective at bridging this gap is Reinforcement Learning from Human Feedback (RLHF), and at its heart lies a powerful algorithm: Proximal Policy Optimization (PPO).
|
||||
|
||||
You may have seen diagrams like the one below, which outlines the RLHF training process. It can look intimidating, with a web of interconnected models, losses, and data flows.
|
||||
|
||||
![[Pasted image 20250730232756.png]]
|
||||
|
||||
This post will decode that diagram, piece by piece. We'll explore the "why" behind each component, moving from high-level concepts to the deep technical reasoning that makes this process work.
|
||||
|
||||
### Translating RL to a Conversation
|
||||
|
||||
The first step is to understand how the traditional language of reinforcement learning maps to the world of text generation.
|
||||
|
||||
* **State (`s_t`)**: In a chat setting, the "state" is the context of the conversation so far. It's the initial prompt (`x`) plus all the text the model has generated up to the current moment (`y₁, ..., y_{t-1}`).
|
||||
* **Action (`a_t`)**: The "action" is the model's decision at each step. For an LLM, this means generating the very next token (`y_t`). A full response is a sequence of these actions.blob:https://aistudio.google.com/872e746f-88c1-40ec-8e45-fa0efce97299
|
||||
* **Reward (`r`)**: The "reward" is a numeric score that tells the model how good its full response (`y`) was. This score comes from a separate **Reward Model**, which has been trained on a large dataset of human preference comparisons (e.g., humans rating which of two responses is better). This reward is often only awarded at the end of the entire generated sequence.
|
||||
|
||||
Let's make this concrete. If a user provides the prompt **(x)**: *"The best thing about AI is"*, and the model generates the response **(y)**: *"its potential to solve problems."*, here is how it's broken down for training:
|
||||
|
||||
* **State 1**: "The best thing about AI is"
|
||||
* **Action 1**: "its"
|
||||
* **State 2**: "The best thing about AI is its"
|
||||
* **Action 2**: " potential"
|
||||
* **State 3**: "The best thing about AI is its potential"
|
||||
* **Action 3**: " to"
|
||||
* ...and so on for every generated token.
|
||||
|
||||
This breakdown transforms a single prompt-response pair into a rich trajectory of state-action pairs, which becomes the raw data for our learning algorithm.
|
||||
|
||||
### The Cast of Models: An Actor-Critic Ensemble
|
||||
|
||||
The PPO process doesn't rely on a single model but an ensemble where each member has a distinct role.
|
||||
|
||||
1. **The Actor (Policy LM)**: This is the star of the show—the LLM we are actively fine-tuning. Its role is to take a state (the current text) and decide on an action (the next token). We refer to its decision-making process as its "policy" (`π`).
|
||||
2. **The Critic (Value Model)**: This is the Actor's coach. The Critic doesn't generate text. Instead, it observes a state and estimates the *potential future reward* the Actor is likely to receive from that point onward. This estimate is called the "value" (`V(s_t)`). The Critic's feedback helps the Actor understand whether it's in a promising or a dead-end situation, which is a much more immediate learning signal than waiting for the final reward.
|
||||
3. **The Reward Model**: This is the ultimate judge. As mentioned, it's a separate model trained on human preference data that provides the final score for a complete generation. Its judgment is treated as the ground truth for training both the Actor and the Critic.
|
||||
|
||||
### The Challenge of Credit Assignment: Generalized Advantage Estimation (GAE)
|
||||
|
||||
A key problem in RL is assigning credit. If a 20-token response gets a high reward, was it because of the first token, the last one, or all of them? The Critic helps solve this. By comparing the reward at each step with the Critic's value estimate, we can calculate the **Advantage (`Â`)**.
|
||||
|
||||
A simple advantage calculation might be: `Advantage = reward + Value_of_next_state - Value_of_current_state`.
|
||||
|
||||
However, this can be noisy. PPO uses a more sophisticated technique called **Generalized Advantage Estimation (GAE)**. The formula looks complex, but the idea is intuitive:
|
||||
|
||||
`Â(s_t, a_t) = Σ(γλ)^l * δ_{t+l}`
|
||||
where `δ_t = r_t + γV(s_{t+1}) - V(s_t)`
|
||||
|
||||
* **γ (gamma)** is a discount factor (e.g., 0.99), which values immediate rewards slightly more than distant ones.
|
||||
* **λ (lambda)** is a smoothing parameter that balances the trade-off between bias and variance. It creates a weighted average of advantages over multiple future time steps.
|
||||
|
||||
In essence, GAE provides a more stable and accurate estimate of how much better a specific action was compared to the policy's average behavior in that state.
|
||||
|
||||
### The Heart of PPO: The Quest for Stable Updates
|
||||
|
||||
Now we arrive at the core innovation of PPO. We want to update our Actor model to take actions with higher advantages. The naive way to do this is to re-weight our training objective by an **importance sampling ratio**: `(π_new / π_old)`. This corrects for the fact that the data we are learning from was generated by a slightly older version of our policy.
|
||||
|
||||
However, this ratio is incredibly dangerous. If the new policy becomes very different from the old one, the ratio can explode, leading to massive, unstable gradient updates that destroy the model.
|
||||
|
||||
PPO solves this with its signature **Clipped Surrogate Objective**. The PPO loss function is:
|
||||
|
||||
`L_CLIP(θ) = Ê_t [ min( r_t(θ)Â_t, clip(r_t(θ), 1 - ε, 1 + ε)Â_t ) ]`
|
||||
|
||||
Let's translate this from math to English:
|
||||
* `r_t(θ)` is the probability ratio `π_new(a_t|s_t) / π_old(a_t|s_t)`.
|
||||
* The goal is to increase the objective by an amount proportional to the advantage `Â_t`.
|
||||
* **The `clip` function is the crucial safeguard.** It forbids the probability ratio from moving outside a small window (e.g., `[0.8, 1.2]`).
|
||||
|
||||
This means the algorithm says: "Let's update our policy to favor this good action. But if the required update would change the policy too drastically from the old one, we'll 'clip' the update to a more modest size." This creates a "trust region," ensuring stable, incremental improvements.
|
||||
|
||||
### Avoiding Amnesia: The Pretraining Loss
|
||||
|
||||
There's one final problem. If we only optimize for the PPO loss, the model might learn to "hack" the reward model by generating repetitive or nonsensical text that gets a high score. In doing so, it could suffer from **catastrophic forgetting**, losing its fundamental grasp of grammar and facts.
|
||||
|
||||
To prevent this, we introduce a second loss term. As seen in the diagram, we mix in data from the original **Pretraining Data** (or the dataset used for Supervised Fine-Tuning). We calculate a standard next-token prediction loss (`LM Loss`) on this high-quality data.
|
||||
|
||||
The final loss for the Actor is a combination of both objectives:
|
||||
|
||||
**Total Loss = Loss_PPO + `λ_ptx` * Loss_LM**
|
||||
|
||||
This brilliantly balances two goals:
|
||||
1. The `Loss_PPO` pushes the model towards behaviors that align with human preferences.
|
||||
2. The `Loss_LM` acts as a regularizer, pulling the model back towards its core language capabilities and preventing it from drifting into gibberish.
|
||||
|
||||
### The Full Training Loop
|
||||
|
||||
Now, we can assemble the entire process into a clear, iterative loop:
|
||||
|
||||
1. **Collect**: The current Actor policy `π_k` generates responses to a batch of prompts. These experiences—`(state, action, probability, reward, value)`—are stored in an **Experience Buffer**.
|
||||
2. **Calculate**: Once the buffer is full, we use the collected data to compute the advantage estimates `Â_t` for every single token-generation step.
|
||||
3. **Optimize**: For a few epochs, we repeatedly sample mini-batches from the buffer and update the Actor and Critic models. The Actor is updated using the combined `PPO-clip Loss` and `LM Loss`. The Critic is updated to improve its value predictions.
|
||||
4. **Flush and Repeat**: After the optimization phase, the entire experience buffer is discarded. The data is now "stale" because our policy has changed. The newly updated policy `π_{k+1}` becomes the new Actor, and we return to step 1 to collect fresh data.
|
||||
|
||||
This cycle of collection and optimization allows the language model to gradually and safely steer its behavior towards human-defined goals, creating the helpful and aligned AI assistants we interact with today.
|
||||
|
||||
***
|
||||
|
||||
**References:**
|
||||
|
||||
1. Schulman, J., Wolski, F., Dhariwal, P., Radford, A., & Klimov, O. (2017). *Proximal Policy Optimization Algorithms*. arXiv preprint arXiv:1707.06347.
|
||||
2. Schulman, J., Moritz, P., Levine, S., Jordan, M., & Abbeel, P. (2015). *High-Dimensional Continuous Control Using Generalized Advantage Estimation*. arXiv preprint arXiv:1506.02438.
|
||||
3. Ouyang, L., et al. (2022). *Training language models to follow instructions with human feedback*. Advances in Neural Information Processing Systems 35.
|
@@ -0,0 +1,81 @@
|
||||
---
|
||||
title: "T5 - The Transformer That Zigged When Others Zagged - An Architectural Deep Dive"
|
||||
date: 2025-08-02T17:43:37-0700
|
||||
draft: false
|
||||
---
|
||||
|
||||
|
||||
In the rapidly evolving landscape of Large Language Models, a few key architectures define the dominant paradigms. Today, the "decoder-only" model, popularized by the GPT series and its successors like LLaMA and Mistral, reigns supreme. These models are scaled to incredible sizes and excel at in-context learning.
|
||||
|
||||
But to truly understand the field, we must look at the pivotal models that explored different paths. Google's T5, or **Text-to-Text Transfer Transformer**, stands out as one of the most influential. It didn't just introduce a new model; it proposed a new philosophy. This article dives deep into the architecture of T5, how it fundamentally differs from modern LLMs, and the lasting legacy of its unique design choices.
|
||||
|
||||
### The Core Philosophy: Everything is a Text-to-Text Problem
|
||||
|
||||
The genius of T5 lies in its unifying framework. Instead of building different models or fine-tuning procedures for various NLP tasks, T5 reframes every task as a text-to-text problem. The model takes a string as input and generates a string as output, regardless of the underlying objective.
|
||||
|
||||
This is accomplished by adding a **task prefix** to the input. These prefixes are not conversational prompts like a GPT "system prompt"; they are learned triggers that the model is explicitly fine-tuned to recognize.
|
||||
|
||||
| Task | T5 Input | Expected T5 Output |
|
||||
| :--- | :--- | :--- |
|
||||
| Translation | `translate English to German: The cat is cute.` | `Die Katze ist süß.` |
|
||||
| Summarization | `summarize: [A long news article...]` | `[A concise summary.]` |
|
||||
| Classification | `cola sentence: The boys is walking.` | `unacceptable` |
|
||||
| Similarity | `stsb sentence1: The car is red. sentence2: The auto is crimson.` | `4.8` |
|
||||
|
||||
This elegant approach turns even classification into a generation task, where the model learns to generate the text of the correct label.
|
||||
|
||||
### The Engine: A Two-Window Encoder-Decoder Architecture
|
||||
|
||||
To execute this text-to-text mission, T5 uses the original Transformer's **encoder-decoder architecture**. This is the most significant point of divergence from modern decoder-only LLMs. The inference process works in two distinct stages:
|
||||
|
||||
#### Stage 1: The Encoder (The "Understanding" Window)
|
||||
When T5 receives an input like `summarize: [article text]`, the entire string is fed into the **encoder**.
|
||||
|
||||
* **Bidirectional Context:** The encoder processes the input bidirectionally. Every token can see every other token in the input text simultaneously. This allows the model to build a deep, holistic understanding of the entire prompt and its context.
|
||||
* **Static Representation:** The encoder's final output is not text. It's a set of numerical representations (hidden states) that encapsulates the meaning and intent of the input. This representation is generated once and remains static for the entire generation process.
|
||||
|
||||
#### Stage 2: The Decoder (The "Writing" Window)
|
||||
The decoder is responsible for generating the output string token by token.
|
||||
|
||||
* **Autoregressive Generation:** It begins with a `start-of-sequence` token and generates the output one word at a time.
|
||||
* **Cross-Attention:** At each step, the decoder does two things: it looks at the text it has generated so far (its own "decoder context"), and crucially, it uses a mechanism called **cross-attention** to look back at the static representation created by the encoder. This allows the decoder's generation to be guided by the encoder's complete understanding of the prompt.
|
||||
* **Growing Context:** The decoder's context window grows with each token it generates until it produces an `end-of-sequence` token, signaling that the task is complete.
|
||||
|
||||
This two-window system is a powerful design, especially for tasks that require a full understanding of a source document before generating a new one (like translation or summarization).
|
||||
|
||||
### Architectural Divergence: T5 vs. The Modern LLM Playbook
|
||||
|
||||
Beyond its core architecture, T5 made several specific design choices that contrast with today's standards.
|
||||
|
||||
#### 1. Positional Embeddings: Relative (RPE) vs. Rotary (RoPE)
|
||||
How a model knows the order of words is critical.
|
||||
|
||||
* **T5's Approach (RPE):** T5 uses a form of **Relative Positional Embedding**. Instead of adding a position signal to the word embeddings, it adds a learned bias directly to the attention scores based on the relative distance between tokens. It's a clever way to encode position that is independent of sequence length.
|
||||
* **The Modern Standard (RoPE):** Most modern LLMs (LLaMA, PaLM, Mistral) use **Rotary Positional Embeddings**. As detailed in the CS336 slides, RoPE works by mathematically *rotating* the Query and Key vectors based on their absolute position. This method has proven exceptionally effective for long sequences and is considered the current state-of-the-art.
|
||||
|
||||
#### 2. The Feed-Forward Network: An Extreme Experiment
|
||||
The Feed-Forward Network (FFN) inside each Transformer block is typically 4 times the model's hidden dimension (`d_model`). The original T5 11B model took a radical departure from this rule.
|
||||
|
||||
* **T5 11B's Choice:** It used a small hidden dimension (`d_model = 1024`) but an astoundingly large FFN dimension (`d_ff = 65,536`), a **64-times multiplier**. The rationale was that modern accelerators (like Google's TPUs) are highly efficient at large, dense matrix multiplications.
|
||||
* **The Modern Standard:** This experiment was not widely adopted. Later models, including T5's own successor **T5 v1.1**, reverted to the standard 4x multiplier (or ~2.66x when using GLU activations) for a better balance of parameters and performance.
|
||||
|
||||
#### 3. Denoising: Span Corruption vs. Iterative Diffusion
|
||||
While T5's pre-training is called "denoising," it's conceptually different from the denoising in modern diffusion models.
|
||||
|
||||
* **T5's Denoising:** This is **span corruption**. The model is shown a sentence with chunks of text masked out and learns to predict exactly what was removed in a single step. It's a fill-in-the-blanks task to learn rich language representations.
|
||||
* **Diffusion Denoising:** This is a multi-step generative process. A clean text is gradually corrupted with noise, and the model learns to reverse this process step-by-step, allowing it to generate high-fidelity text from pure noise.
|
||||
|
||||
### Where T5 Was Ahead of its Time
|
||||
|
||||
Despite its differences, the "T5 v1.1" variant pioneered several techniques that are now standard practice in the most advanced LLMs:
|
||||
|
||||
* **RMSNorm:** It was one of the first major models to adopt Root Mean Square Normalization instead of LayerNorm, a choice now used by LLaMA, Mistral, and others for its efficiency and stability.
|
||||
* **Pre-Normalization:** T5 applies the normalization layer *before* the attention and FFN blocks, a critical technique for enabling stable training of very deep networks.
|
||||
* **No Bias Terms:** T5 v1.1 removed the bias parameters from its normalization and FFN layers, a small but important optimization for memory and stability that modern models follow.
|
||||
* **Gated Activations (GeGLU):** While the original T5 used ReLU, T5 v1.1 adopted a Gated Linear Unit (GeGLU), presaging the move to GLU-family activations (like SwiGLU) that is now ubiquitous.
|
||||
|
||||
### Conclusion: The Lasting Legacy
|
||||
|
||||
T5 represents a different evolutionary branch in the Transformer family tree. While the field has largely converged on the decoder-only architecture for its scalability in general-purpose models, T5's design remains a masterclass in purpose-built engineering.
|
||||
|
||||
Its text-to-text framework was revolutionary, its encoder-decoder structure is still a go-to for tasks like translation, and its refined T5 v1.1 architecture laid the groundwork for many of the stability and efficiency tricks we see in today's state-of-the-art models. T5 is more than just a model; it's a crucial case study in the architectural trade-offs that continue to shape the future of artificial intelligence.
|
Reference in New Issue
Block a user