A detailed walkthrough of how we got from a single neuron to Gemma3-4B — matched to notebooks 02, 04, 05, 06
Every number on a verified slide was computed live from this repo's actual data during prep for today — experiments/finalserverrun/final_vast_gemma3_4b.csv (137 cases) and the four instructor notebooks. Two demo cells needed a fix before class — flagged where they come up.
Five steps, in order, each one motivated by the failure of the step before it.
Every Transformer layer is built from the same two primitives you'll see today: a matrix multiply + non-linearity, trained by backpropagation. Gemma3-4B has no new math — it has 4 billion of the same parameters you're about to train 17 of.
Logistic Regression draws one straight line (or flat plane) to separate classes. XOR is the smallest problem where that's mathematically impossible.
| A | B | XOR |
|---|---|---|
| 0 | 0 | 0 |
| 0 | 1 | 1 |
| 1 | 0 | 1 |
| 1 | 1 | 0 |
The two 1s sit in opposite corners of the plane. No single straight line separates them from the two 0s.
A coin flip. It predicts the majority class every time — there is no line to find, so gradient descent gives up at the best it can do.
One hidden layer (4 neurons, ReLU) should learn a new coordinate system where XOR becomes linearly separable. Run live today, it doesn't always — and that's worth teaching too.
This exact configuration hits a dead ReLU: with this seed's initial weights, every hidden unit's input starts negative, ReLU zeroes it, and the gradient is zero everywhere — training can't escape.
tanh can't die the same way (its output is never flat-zero for negative inputs), so it always finds the fold. Same architecture, same seed, different result.
"Whether a network trains isn't just about whether the function is representable — it's about whether gradient descent can find it from this starting point." This is the single most common real-world debugging issue with neural nets, and you just watched it happen on the simplest possible example. Before class: edit the activation in teach_02_dl.ipynb cell 4 from 'relu' to 'tanh', or the printed narration ("→ 100%") will contradict the printed accuracy line.
A neural network is a function built from millions of copies of one simple unit.
| Input (x₁,x₂) | z = 0.7x₁+0.3x₂−0.2 | ReLU(z) |
|---|---|---|
| (0, 0) | −0.20 | 0.00 |
| (0, 1) | +0.10 | 0.10 |
| (1, 0) | +0.50 | 0.50 |
| (1, 1) | +0.80 | 0.80 |
One neuron is a weighted vote with a floor at zero. Gemma3-4B repeats this ~4 billion times, arranged in 34 layers.
Training is four steps repeated until the loss stops improving. Below: real loss values training an 8×4 hidden network on XOR (tanh, lr=0.1).
Input flows through every layer. Final layer produces a prediction.
Compare prediction to the true label. One number: how wrong.
Chain rule: how much did each weight contribute to the error?
Nudge every weight to reduce the loss. Repeat from step 1.
| Epoch | 1 | 10 | 25 | 50 | 100 | 150 | 200 |
|---|---|---|---|---|---|---|---|
| Loss | 0.685 | 0.340 | 0.152 | 0.085 | 0.072 | 0.071 | 0.071 |
Sharp drop in the first ~50 epochs, then it flattens near zero — the network has found the fold in feature space that separates the two classes. Final accuracy: 100%.
XOR needed one hidden layer. A harder, checkerboard-shaped pattern (200 points, 4 alternating quadrant classes) needs more.
| Architecture | 5-fold CV accuracy | |
|---|---|---|
| Logistic Regression (0 hidden) | 46.5% | █████████ |
| Shallow MLP (1 layer × 8) | 45.0% | █████████ |
| Deeper MLP (2 layers, 32×16) | 65.0% | █████████████ |
| Deep MLP (4 layers, 64×32×16×8) | 73.5% | ███████████████ |
A single hidden layer is barely better than no hidden layer at all on this problem — it's actually worse here (45.0% vs 46.5%) due to optimization noise on a hard, highly non-linear boundary. Depth is what buys the real gain: 2 layers → 65%, 4 layers → 73.5%.
ImageNet: best 2011 approach, 26% error. AlexNet — a deep network on GPUs — 15.3% error. A 10-point gap overnight. Every layer refines the representation: edges → shapes → objects. In text: tokens → phrases → legal concepts.
Same math you just ran (17 parameters). Modern LLMs are the identical architecture, scaled by ten billion.
| Model | Parameters | Training compute | Notes |
|---|---|---|---|
| Perceptron (1958) | 1 | punch cards | XOR impossible |
| Early MLP (1980s) | 1,000 | CPU seconds | toy problems |
| LeNet (1998) | 60,000 | CPU hours | MNIST digits |
| AlexNet (2012) | 61,000,000 | GPU days | ImageNet photos |
| BERT-base (2018) | 110,000,000 | GPU weeks | NLP understanding |
| GPT-3 (2020) | 175,000,000,000 | GPU months | few-shot learning |
| Gemma3-4B (our model) | 4,000,000,000 | ≈4 GPU-days | fits on one V100 |
| GPT-4 (est., 2023) | 1,800,000,000,000 | months (est.) | frontier model |
Every one of those parameters is a w in a neuron exactly like the one on slide 5. Nothing new happens conceptually between here and Gemma3 — only scale, and (next section) how it reads sequences.
Take the 9 boolean oracle predicates already extracted by Gemma3-4B for all 137 GoldCoin cases. Predict PERMITTED/DENIED from those 9 numbers alone — does a deeper network do better?
| Model (on 9 extracted booleans) | 5-fold CV accuracy |
|---|---|
| Logistic Regression | 68.0% |
| Decision Tree (depth 5) | 64.3% |
| MLP (16×8) | 63.6% |
| Deep MLP (64×32×16) | 63.6% |
| Actual system: LLM extraction → Soufflé engine | 94.2% |
Depth does not help here — a plain Logistic Regression on 9 clean booleans (68.0%) slightly beats every MLP variant. That's not a contradiction of slide 7: depth helps when the network has to discover structure from raw signal (pixels, checkerboard coordinates, raw text). Once Gemma3 has already collapsed a 300-word legal narrative into 9 clean flags, there's no more structure left to discover — the hard part was the extraction, not the classification. That's the whole thesis of this week.
Neural networks need numeric input. Text isn't numeric, and it's sequential. This section answers: how does a network read a sentence, and why does context change meaning?
Every demo in this section runs in plain numpy on a laptop CPU — the attention mechanism is simple linear algebra. Scale (34 layers × 8 billion multiplications) is the only thing that requires a GPU.
LLMs process subword tokens, not words. GPT-4's tokenizer (cl100k_base, ~100k vocabulary) is used here as a stand-in — Gemma3 uses a similarly-sized vocabulary (256,128 tokens).
Legal citations like §164.512(e) split into several small pieces — the symbol §, the section number, the parenthetical — each an independent token the model must reassemble meaning from.
| Min | Median | Mean | Max |
|---|---|---|---|
| 47 | 58 | 58.0 | 76 |
Gemma3-4B context window: 8,192 tokens. Even the longest scenario prompt uses under 1% of it — plenty of headroom for the schema + instructions template on top.
Before Transformers, RNNs read text one token at a time, passing a "hidden state" forward. Each step compresses everything seen so far into one fixed-size vector.
| After N tokens | Signal remaining |
|---|---|
| 1 | 90.0% |
| 5 | 59.0% |
| 10 | 34.9% |
| 20 | 12.2% |
| 50 | 0.5% |
"The patient, who was admitted after a workplace injury treated by a physician who had previously disclosed records in an unrelated matter, filed for damages claiming the hospital had shared information without court authorization."
Subject ("patient") is at word 2. Key fact ("without court authorization") is at word 34.
Signal from "patient" surviving to word 34: 2.78%
→ By the time an RNN reaches the legal fact, it has essentially forgotten who the subject is. This is the vanishing gradient problem, and it's exactly why Transformers throw sequential processing out entirely.
For each token, compute a score for how much it should "look at" every other token. Same word, different sentence, different attention pattern, different meaning. (Illustrative weights below — in a trained model these are learned, not hand-set.)
SAME WORD. DIFFERENT CONTEXT. DIFFERENT MEANING.
This is exactly what TF-IDF (Part 3, next section) cannot represent — and exactly why transformers exist.
From "Attention Is All You Need" (Vaswani et al., 2017):
Each row sums to 1.0 — a probability distribution over "how much attention this token pays to every token."
In Gemma3-4B: d_model=2048, seq_len up to 8,192 → an 8,192×8,192 attention matrix (67M values) computed in parallel on GPU, for every one of 8 attention heads, at every one of 34 layers.
If every token attends to every other token simultaneously, attention alone can't tell "court order" from "order court" — it's permutation-invariant. Transformers add a positional vector to each token's embedding.
Sinusoidal, fixed (not learned). Each position gets a unique fingerprint; nearby positions get similar fingerprints, so the model can infer relative distance.
The Transformer architecture splits into two families. We use the understanding half — an encoder — to finally represent whole-sentence meaning as geometry.
| Encoder (BERT) | Decoder (GPT, Gemma) | |
|---|---|---|
| Direction | Bidirectional (left + right) | Left-to-right only |
| Training task | Predict masked words | Predict next word |
| Use for | Understanding, classification | Generation, completion |
| Today's example | Sentence embeddings | LLM oracle extraction |
Query: "A court order was issued requiring release of the records." Cosine similarity to other phrases, computed live with all-MiniLM-L6-v2.
| Phrase | TF-IDF sim | Embedding sim |
|---|---|---|
| "A judicial mandate compelled disclosure of patient information" | 0.058 | 0.566 |
| "The subpoena issued by the court authorized disclosure" | 0.128 | 0.599 |
| "Law enforcement asked the hospital to turn over the file" | 0.060 | 0.617 |
| "The officer implied there might be a court order forthcoming" | 0.162 | 0.561 |
| "The physician requested records for treatment purposes" | 0.043 | 0.638 |
TF-IDF: "court order" and "judicial mandate" score 0.058 — near zero, despite triggering the identical HIPAA exception. Embeddings lift that to 0.566 — real progress, but notice it's not close to 1.0 either. Embeddings capture rough topic similarity, not legal validity — and interestingly, the hedged "implied there might be a court order" (0.561) scores about the same as genuine court-order language, not clearly higher. Embeddings alone can't reliably tell real authority from a passing mention of authority. That's the gap the LLM has to close.
Real 5-fold cross-validation, all 137 GoldCoin scenarios, predicting PERMITTED vs DENIED from text representation alone (no LLM extraction).
| Method | Accuracy | |
|---|---|---|
| Majority-class baseline | 63.5% | ████████████ |
| TF-IDF (uni+bigrams) + LogReg | 63.5% | ████████████ (no better than guessing!) |
| Sentence embeddings + LogReg | 82.0% (±16.2%) | ████████████████ |
| LLM extraction → formal engine | 94.2% | ██████████████████ |
TF-IDF + Logistic Regression gets exactly the majority-baseline accuracy — it learns nothing useful from the text at all on this task. Embeddings jump to 82% but with high fold-to-fold variance (±16.2%) — on 137 examples, embeddings are unstable. Only reading the full text in context, with an LLM, closes the rest of the gap reliably.
Embeddings let you search by meaning, not keywords — useful when writing adversarial test scenarios: find the real cases most similar to a hypothetical you're designing.
If you're pursuing P1 Adversarial Robustness, this is your tool: write a new hedged scenario, embed it, and see which real cases it lands closest to. If it lands close to a DENIED case but you designed it to look PERMITTED, you've likely found a real Gemma3 failure mode before you even run the model.
Everything so far was building intuition on toy or synthetic data. This section is 100% real: the actual Gemma3-4B experiment on the Stony Brook cluster, 137 real GoldCoin court cases.
| Min | Median | Mean | Max | Std |
|---|---|---|---|---|
| 8.3s | 14.3s | 15.8s | 41.4s | 4.6s |
Total GPU time for all 137 cases: 36.0 minutes. Throughput: ~228 cases/hour on one V100.
V100 32GB — Stony Brook AI Cluster. This is the exact hardware you'll submit your own extraction job to this afternoon (Exercise 9).
Case row_id 4 — a correct PERMITTED prediction.
"In early 2005, a legal battle unfolded involving Anthony Camillo, a plaintiff familiar with Medicare billing practices, and Kenneth Hall Regional Hospital, the defendant. The crux of the dispute was the hospital's billing and refund records, which Camillo suspected contained evidence of fraudulent M…"
| sender | Kenneth Hall Regional Hospital |
| receiver | Anthony Camillo (plaintiff) |
| subject | patients |
| attribute | medical information |
| purpose | litigation |
STEP 4 — Soufflé verdict: PERMITTED (cites §164.512(e)(1)(ii) — subpoena with satisfactory assurance). Match: ✓ correct. Inference latency: 19.6s.
Model said PERMITTED, ground truth was DENIED.
→ Safety-critical: this is a real PHI disclosure that shouldn't have happened.
Cases: row_id 40, 46, 123
Model said DENIED, ground truth was PERMITTED.
→ Over-blocking: a lawful disclosure got incorrectly rejected.
Cases: row_id 16, 27, 30, 59, 66
FNs outnumber FPs 5-to-3 on this run — Gemma3-4B leans slightly toward under-granting access, not over-granting it. That's the safer failure direction, but it's still 5 real cases of incorrectly blocked lawful disclosure.
Truth: DENIED (cites §164.502(a)). Model said: PERMITTED.
"In 2012, an individual found himself requiring emergency medical services and was taken by ambulance to a hospital. To receive this necessary medical attention, he provided the ambulance service, operated by the Philadelphia Fire Department EMS, with his personal and sen[sitive information]…"
is_business_associate · believes_unlawful_conduct · believes_victim_of_crime · is_required_by_law · mentions_patient_notice · has_ba_agreement
"…permitted under 45 CFR §164.502(a)(1)(i), which allows disclosure to the individual or their personal representative…" — a plausible-sounding citation attached to the wrong exception. It over-generalized routine EMS billing/payment processing into six separate enabling oracles that weren't actually satisfied.
Truth: PERMITTED (cites §164.502). Model said: DENIED.
"In a small town, A.S., a young woman with a developmental disability, was under the care of her parents who were appointed as her guardians by a probate court. Throughout her education, A.S. received special education services due to her condition. When she turned eighteen in 2003, her parents became…"
has_authority_to_act · provider_patient · believes_minimum_necessary · is_in_designated_record_set
The model answered "DENIED under §164.203(a)(1)" — reasoning about a related-but-wrong provision (mental-health-evaluation confidentiality) instead of the guardian-authority exception that actually governs this case. It extracted correct facts but the LLM's own explanation cites the wrong rule — a reasoning failure downstream of extraction, not just an oracle miss.
How often each oracle predicate is set TRUE in failure cases vs. correct cases (real counts, 137 cases).
| Oracle predicate | In failures | In correct cases |
|---|---|---|
| provider_patient | 5 | 52 |
| has_treatment_relationship | 5 | 59 |
| has_authority_to_act | 3 | 73 |
| believes_minimum_necessary | 2 | 24 |
| prohibited_by_other_law | 2 | 3 |
| is_required_by_law | 2 | 59 |
| believes_unlawful_conduct | 2 | 26 |
| has_ba_agreement | 2 | 13 |
No single predicate dominates the failure set — the 8 errors are spread across 20 different oracles, each appearing 1–5 times. There's no one broken rule to patch. This is consistent with what you saw in case 40 (over-firing) and case 16 (right facts, wrong reasoning): the errors are contextual, not systematic.
Hypothesis: maybe the model "hesitates" (takes longer) on cases it's about to get wrong. Real latency data says otherwise.
Failures were faster, not slower. There's no latency signal for uncertainty here — if anything, wrong answers were produced slightly more decisively. Don't trust "the model took a while, it must be thinking hard" as a proxy for correctness. Confidence (fast, fluent output) and correctness are simply not the same thing — this is the RLHF effect from Part 4's training discussion: models are optimized to sound sure of themselves.
You've now seen every layer: neuron → attention → embedding → extraction → engine. The 8 remaining errors are your research target. Project selection due Friday, July 3.
Can you write new scenarios that break the model the same way case 40 broke?
Does this same error pattern show up in GDPR / CCPA extraction too?
Does a larger model (Llama3-70B) fix cases 40 and 16?
Do stricter oracle definitions or few-shot negatives fix the FPs?
Can you automatically diagnose why a prediction was wrong?
Does adding 3–5 worked examples to the prompt close the gap?
Every accuracy figure below was computed live on the real 137-case GoldCoin benchmark during prep for today.
| Approach | What you saw today | Accuracy | Wall hit |
|---|---|---|---|
| Logistic Regression | Slide 3 — XOR | 50% | Can't draw a curved boundary |
| Neural network (correct activation) | Slide 4 — XOR | 100% | Needs numeric features; text isn't numeric |
| MLP on 9 extracted booleans | Slide 9 — HIPAA | 68.0% | Ceiling of the classifier, not the features |
| TF-IDF + Logistic Regression | Slide 19 — HIPAA | 63.5% | = majority baseline. Learns nothing. |
| Sentence embeddings + LogReg | Slide 19 — HIPAA | 82.0% (±16.2%) | Unstable; can't distinguish hedged from real authority |
| LLM extraction → formal engine | Slide 22 — GoldCoin | 94.2% | 8 contextual errors remain — no single broken rule |
Discovered while verifying today's numbers — both notebooks currently have never been executed, so these haven't surfaced yet.
With activation='relu', random_state=42, the network hits a dead-ReLU state and prints Accuracy: 50% — but the next line still says "→ 100%. The hidden layer learned…", contradicting its own output live in front of students.
Fix: change activation='relu' → 'tanh' in that cell (and the loss-curve cell right after it). Verified: gives 100% and a clean decreasing loss curve.
The script's narration claims group C (hedged phrases) embeds closer to group A (real court orders) than group B does. Run live with all-MiniLM-L6-v2, the opposite comes out: avg(C→A)=0.401 vs avg(B→A)=0.460.
Fix: use slide 18/19 of this deck instead — the single-phrase table (A1 vs. others) still makes the core point honestly, and the full-dataset classification comparison (63.5% → 82.0% → 94.2%) is a more robust, real result than the 12-phrase toy demo.
| # | Topic | Key demo | When |
|---|---|---|---|
| 01 | Machine Learning | 3 classifiers on FIFA → HIPAA feature-extraction wall | Mon |
| 02 | Deep Learning | XOR: LR fails (50%), MLP succeeds (100% with tanh) | Mon/Tue |
| 03 | NLP | Semantic gap: "court order" ↔ "judicial mandate" = 0.06–0.13 | Tue |
| 04 | Transformers | "order" = different meaning by context; 2.78% RNN signal at word 34 | Tue/Wed |
| 05 | Encoders | Embedding similarity 0.566–0.638; classification 63.5%→82.0% | Wed |
| 06 | LLMs | 129/137 = 94.2%; 8 failures live via show_case(N) | Wed/Thu |
Today (Wed, Jul 1): notebooks 04, 05, 06 — everything in Parts 2–4 of this deck.
Exercise 9 — submit your own Gemma3-4B extraction job to the V100 cluster you just read the specs of. Then Exercises 7–8: find your own failure case, and diagnose it exactly the way we diagnosed cases 40 and 16.
"You've seen every wall that led here. Now: which one do you want to try to climb?"