Welcome to CDS593 (Spring 2026)!

About this site

This site contains a complete set of resources and links for CDS593 for Spring 2026.

How the material works

• Check the schedule for a list of lecture topics and key due dates
• Reference the syllabus and rubrics as needed
• See the Final Project Guide for the full project timeline and deliverables

Each week:

• Preview the week by viewing the week's WEEK GUIDE (see table of contents) - this will give you a checklist of tasks for the week, learning objectives for that week's lectures, a preview of the discussion section, ideas for reflections and lab work, and links to other resources!
• Review the LECTURE NOTES which will be posted after class each day

Other resources:

• Ask questions and discuss on Piazza (link TBD)

• Submit your work weekly on GitHub (link TBD)

• Check on your past assignment grades on Gradescope (link TBD)

• Prof. Wheelock coffee slots sign-up

Theory and Applications of Large Language Models

DS 593 - Spring 2026

Instructor: Prof. Lauren Wheelock

Email: laurenbw@bu.edu

Class Meetings: Monday/Wednesday 12:20-1:35pm

Office Hours: Every weekday with a member of the teaching team

• Prof. Wheelock: Mon 11-12 in the CDS building, room 1506
• Bhoomika: Wed 11-12 and Fri 10-11 location TBD
• Naky: Tue 1-2 and Thu 4-5 location TBD

Course Description

Large language models are reshaping software development, data science, and AI research. In this course, you'll learn how and why LLMs work, then master the skills to adapt and deploy them in real applications. You'll build transformers from scratch to understand the architecture deeply, then move to production techniques: fine-tuning models for specific tasks, building RAG-powered chatbots, and developing AI agents. After this course, you'll have a portfolio of work and the confidence to discuss these techniques in your future work and research.

We'll start with classical NLP and work up through modern transformer architectures, giving you both theoretical understanding and hands-on implementation experience. Throughout, we emphasize responsible AI: understanding bias, safety considerations, and the real-world implications of deployment decisions.

Recommended Co-requisite: Introduction to Machine Learning/AI (DS340 or equivalent)

Learning Objectives

By the end of this course, you will be able to:

• Build a transformer from scratch and explain how attention mechanisms work
• Implement a production RAG system with vector databases and semantic search
• Fine-tune open-source LLMs for specific applications using LoRA and other PEFT techniques
• Design and red-team prompt engineering strategies, including defenses against injection attacks
• Critically evaluate LLMs for bias, safety risks, and alignment with human values
• Maintain a professional technical portfolio demonstrating your work with modern AI tools

What to Expect in This Course

Weekly rhythm:

• Monday/Wednesday: New concepts through lecture and discussion. Expect icebreakers, group activities, and minimal laptop use. We'll close laptops to focus on ideas, opening them only for specific hands-on activities.
• Tuesday: Discussion section (optional but highly recommended) for hands-on practice with that week's techniques, troubleshooting, and getting started on labs
• Friday evenings: Weekly reflection and lab notebook due (pushed to your GitHub repo)
• Throughout the week: Work on your GitHub portfolio, explore resources, engage on Piazza. Office hours are available every weekday with a member of the teaching team!

Weekly deliverables: Each week you'll complete:

• A personal reflection (300-500 words) on what you're learning
• A lab notebook documenting your experiments and implementation work
• See the detailed weekly guides on our website for specific prompts, resources, and learning objectives for each week

Twice per semester: You'll take your exploratory weekly labs and polish them into portfolio pieces - cohesive, well-documented projects ready for peer review and professional portfolios.

Two midterms, no final: In-class exams (Week 6 and Week 12) test your conceptual understanding on paper. You will have the option to redo one topic on exam section orally to demonstrate post-exam learning.

One final project: The capstone of the course where you apply everything you've learned to build something substantial, whether that's training a model from scratch, building a production RAG system, creating an AI agent, or diving deep into research. You'll work through ideation, proposal, development, and presentation stages, with checkpoints to keep you on track. This becomes a portfolio piece you can show future employers or use as a foundation for further research.

AI Use Policy

For coding: There are no restrictions on AI use to assist in your coding. Correspondingly, I have high expectations for the quality of the final products you will be able to produce in course projects, especially the final project. Using AI-powered coding tools will be especially helpful if you are building a project that uses non-LLM software components, such as building a web interface or app.

For reflections: I do ask that you write your weekly reflections without AI, in your own voice. These assignments are not graded for content, and I will use them to aid in my own teaching and reflection on the course, and to understand what material is most valuable to you. These are about your experiences and opinions. I don't care about grammar, and they can be stream-of-consciousness if need be.

For exams: There will be no technology or cheat-sheet use on exams so that I can evaluate your understanding of the theory we cover.

Course Tools

• GitHub: For your labs, reflections, portfolio pieces, and final project
• [Piazza](https://piazza.com/class/mkegpx14bz48t] for questions, discussions, and announcements
• Gradescope for exam and portfolio piece grading
• Course website:
  • https://lauren897.github.io/cds593-private/
  • For syllabus, lecture schedule, lecture notes, week guides, and other reference material.

Course Structure

See the website's Course Schedule for detailed day-by-day topics and due dates.

Part I: Foundations (Weeks 1-3)

Where are we going? How are we going to work together?

• Welcome, GitHub and collaboration setup
• Introduction to NLP and the current LLM landscape

How did we process language before transformers?

• AI-assisted development tools and best practices
• Classical NLP: bag-of-words, TF-IDF, naive Bayes, tokenization deep dive

How do neural networks learn from text?

• Deep learning fundamentals: backpropagation, gradient descent
• Word embeddings: Word2vec, GloVe, distributional hypothesis
• Sequence-to-sequence models and the bottleneck problem

Part II: Transformer Architecture (Weeks 4-6)

What makes transformers so powerful?

• Attention mechanisms: Query-Key-Value framework, scaled dot-product attention
• Self-attention and multi-head attention
• Transformer architecture: encoder-decoder blocks, residual connections, layer normalization

How do we actually build and use transformers?

• Implementing transformers from scratch
• Transformer variants: BERT, GPT, T5
• Using pre-trained models with HuggingFace, visualizing attention with BertViz
• Philosophy of AI: consciousness, understanding, Chinese Room, Turing test

Portfolio Piece 1 due (Week 5)

First Midterm (Week 6)

Part III: LLMs at Scale (Weeks 6-8)

How do you train a model that costs millions of dollars?

• Pre-training LLMs: data sources, cleaning pipelines, scaling laws (Kaplan vs Chinchilla)
• Training at scale: distributed training, compute costs, environmental impact
• Post-training and RLHF: instruction tuning, reward modeling, reinforcement learning
• Constitutional AI: principles-based alignment vs human preferences

How do we evaluate and compare LLMs?

• Evaluation frameworks: benchmarks (MMLU, HellaSwag, TruthfulQA), Goodhart's Law
• The LLM landscape: GPT, Claude, LLaMA, foundation models, open vs. closed
• Fine-tuning strategies and PEFT: when to fine-tune, LoRA, catastrophic forgetting, safety considerations

Part IV: Applications (Weeks 8-11)

How do we make LLMs do what we want, and what can go wrong?

• Prompt engineering: core principles, few-shot learning, chain-of-thought reasoning
• Prompt injection and jailbreaking: attack surface, direct/indirect injection, defense strategies
• Safety, alignment, and red-teaming: whose values?, real-world harms, alignment tax

How can LLMs access and use external knowledge?

• Retrieval-augmented generation (RAG): vector databases, semantic search, retrieval augmentation
• Hallucination mitigation and advanced RAG architectures
• Evaluating RAG system performance

How can LLMs act autonomously in the world?

• AI agents: tool use, reasoning loops, multi-agent systems
• Memory systems and long-term context
• Real-world agent applications and limitations

Portfolio Piece 2 due (Week 10)

Final Project Proposal due (Week 11)

Part V: Deployment and Capstone (Weeks 12-14)

How do we responsibly deploy what we've built?

• Deployment considerations: production systems, API design, monitoring
• Safety in production: content filtering, rate limiting, abuse prevention
• Regulatory landscape and ethical considerations

Second Midterm (Week 12)

What's emerging in the field right now?

• Guest lecture or discussion of current developments
• Final project development and peer consultation

What can you build with everything you've learned?

• Final project presentations and demonstrations

Final Project due (May 1)

Assessment Structure

Weekly Reflections + Lab Notebooks (10%)

There are no traditional homework assignments. Each week you will keep a GitHub repo for this course that includes:

• Reflections: Weekly reflections (300-500 words each) documenting your learning, questions, and connections to other topics
• Lab Notebooks: Well-documented Jupyter notebooks showing your thought process and experiments with the course material (20-50 lines of working code plus comments)

Timing: Complete each week's reflection and lab notebook by Friday evening. Submit by pushing to your GitHub repo.

Freedom to explore: I will give suggested questions and resources for exploration but you are free to take these assignments in another direction and follow your interests as long as your work is related to the topics covered. For example, if you are particularly interested in the philosophical or linguistic aspects of language models, you could make that a theme throughout all your reflections and data work.

Grading: These assignments are graded for completion only (credit/no credit), not for content. The teaching team will read your work and leave constructive feedback. If there is a particular type of feedback you are interested in for your own growth, let us know!

Participation (10%)

I don't expect everyone to engage in the same way, so focusing on 2-3 of these will merit full participation credit:

• Participation in lecture: Consistent attendance, asking and answering questions, participating in groupwork
• Participation in discussion: Consistent attendance and engagement
• Office hours: Coming to office hours to ask questions and discuss project work
• Piazza engagement: Asking or answering questions that help the community learn
• Peer support: Helping classmates troubleshoot code or understand concepts

Participation Self-Assessment: At the middle and the end of the semester, you will submit a short reflection (1-2 paragraphs) making a case for your participation grade based on a rubric I will provide, giving specific examples of your contributions. The teaching team will review and confirm or adjust your self-assessment.

Portfolio Pieces (10% total)

Two portfolio pieces where you build upon your past labs to create a polished project. Portfolio pieces must be completed individually. You will share your work with peers for feedback, and providing thoughtful peer reviews is part of your grade.

Each portfolio piece will be graded on a detailed rubric (100 points total) covering: conceptual understanding, technical implementation, code quality, documentation & communication, critical analysis, originality & depth, and peer reviews. See the detailed rubric document for point breakdown and grading criteria at each level.

Exams (40% total)

These exams are designed to check your mastery of theoretical material, while project work demonstrates your mastery of applications.

• First Midterm (20% - Week 6, Feb 23):
• Second Midterm (20% - Week 12, Apr 15):

No reference materials will be allowed on the exams.

Both exams will occur in-class on the dates shown (75 minutes). You can mark these dates in your calendar now, since they are firm. If you have existing accommodations that impact exams, please let me know as soon as possible, but by two weeks before the exam at the very latest.

Exam Structure: Exams are organized into standards, each covering a specific topic area. This structure helps you identify which concepts you've mastered and which need more work, and enables you to select one topic for re-examination (see oral exam policy below).

Final Project (30%)

Final projects can be completed individually or in groups of 2-3 people. Group projects should be more ambitious in scope, with clear division of labor documented.

Project options might include:

• Train a small language model from scratch and explore what's possible without relying on pre-trained models
• Build a RAG-based chatbot with prompt engineering that minimizes hallucinations for a particular application
• Fine-tune an open-source LLM for a particular application and demonstrate improved performance
• Build an LLM agent for a specific task with LangChain or MCP and a web interface
• Deep dive into a recent LLM research paper with implementation and novel analysis

Project checkpoints:

• Week 8 (Mar 20): Project ideation checkpoint - submit 2-3 project ideas, form teams (if applicable)
• Week 11 (Apr 10): Project proposal - one-page proposal including problem statement, proposed approach, evaluation plan, timeline, and (if group) division of labor. Dataset acquired and preliminary exploration complete.
• Week 14 (Apr 27-29): Final presentations in class
• May 1: Final project write-ups due

Grading: Projects will be assessed on a rubric (50 points total) covering: scope & ambition, design decisions, technical execution, use of course concepts, evaluation & analysis, iteration & reflection, ethics & limitations, and documentation & presentation. See the detailed rubric document for point breakdown and grading criteria, and the project guide for scope expectations and tips.

For group projects, individual grades may differ based on contribution (assessed through peer evaluations).

Paper presentation alternative: A paper presentation is available as an alternative for students who are more theoretically inclined. This involves critical analysis of a significant LLM paper (not just summary) plus at least one of: implementation/demo, novel visualizations/teaching materials, or synthesis with additional sources. This is expected to take equivalent effort as a final project. If you are intertested in this option, please reach out to me by Week 4 so we can select an appropriate paper and make time in class for your presentation, which may be better fit for an earlier point in the term than the final week.

Additional Course Policies

Extensions and Late Work

Weekly reflections and labs: These will receive 100% credit if they meet the length criteria, are on topic, and are submitted by the deadline, with up to 90% credit one day late, 80% credit two days late, and no credit after more than two days. Since these tasks are lightweight I do not expect to offer extensions except in extreme circumstances.

Portfolio pieces: Same late policy as weekly work (100% on time, 90% one day late, 80% two days late, 0% after). Since these assignments are posted for peer review, turning them in late impedes the ability for your peers to provide feedback, so I will rarely offer extensions.

Final projects: Projects submitted by the last day of class (May 1) will receive up to 100% credit. Since this course does not have a final exam, I must issue final grades within 48 hours of the end of the term, so projects more than 48 hours late will result in a (temporary) Incomplete, and will receive up to 70% credit once the project is submitted. I highly encourage you to submit projects by the deadline, even if you feel they could be improved, with your reflections on what you would have done with more time or how you could have planned differently.

Exams: There will be no make-up exams without prior arrangement or documented emergency if within 24 hours of the exam time.

Calculating and communicating grades

I will be tracking your course grades in a spreadsheet and will automate email updates so you can see your gradebook status approximately every 2 weeks. If you receive these emails and believe there is a factual error on your grade sheet (for example, you see a late penalty on a lab you believe you completed on time) please reply to the email and I will look into it.

Exams, portfolio pieces, and the final project will be graded on rubric forms on Gradescope and your score will automatically be sent to you through that tool. You will also see these scores reflected in the gradebook emails that follow.

"Curving" exams and course grades

I reserve the right to add a fixed number of "free" points to linearly curve exam scores - this will never result in a lower grade for anyone. It is my intention to design exams so this policy should not be needed.

I will use the standard map from numeric grades to letter grades (>=93 is A, >=90 is A-, etc) to produce final grades for the class. This final distribution will not be curved or capped.

Regrade requests

You have the right to request a re-grade of any rubric-based assignment or exam. Regrade requests must be submitted using the Gradescope interface, not by email, and must be submitted within one week of grading. If you request a re-grade for a portion of an assignment, then we may review the entire assignment, not just the part in question. This may potentially result in a lower grade.

Oral exam re-test

You may elect after either the first or second exam to re-examine one topic during a personalized oral exam. (Exams will be clearly broken up into equally-weighted topics.) The oral exam may consist of questions about your original answers, related questions that did not appear on the exam, or discussion of code or other work that relates to the topic. You must request a re-test within one week of exam grades being posted, and the re-tests will be scheduled roughly a week later. More information on this option will be provided during the semester.

Corrections

There are no exam corrections or assignment corrections in this course. With the exception of the oral exam option, assignment and exam grades are final.

Classroom Presence and Engagement

This course emphasizes active learning through discussions, activities, and collaborative work. When you're here, you're here. This means:

• Laptops and devices should be closed unless we're actively using them for course activities
• I may occasionally cold-call on students (gently!) to foster discussion
• If you're too busy to engage fully in class activities, it's better to skip that session and catch up later

I understand that life happens and sometimes you need to miss class. That's okay! But when you do attend, I ask that you be mentally present and ready to participate.

Absences

This course follows BU's policy on religious observance. Otherwise, it is generally expected that students attend lectures and discussion sections. There is no need to email me in advance for missing a class due to illness or other conflict (unless there is an exam or presentation). If you miss a lecture, please review the lecture notes and confer with other students in the class. Lectures will not be recorded.

If you expect to miss more than two lectures in a row, please let me know as soon as possible so we can make a plan and I can help give you any support you need.

In the unlikely event that I cannot teach in person on a particular day, I will send a Piazza announcement with further instructions.

Collaboration

You are encouraged to discuss concepts and approaches with classmates, but all written work and code must be your own (unless it's a group project). For portfolio pieces, you may discuss general strategies but not share code or specific solutions. Cite any external resources you use, including AI dev tools.

Academic Integrity

This course follows all BU policies regarding academic honesty. Plagiarism or cheating of any kind will result in a failing grade for the assignment and possible referral to the university.

Accommodations

If you need accommodations, please let me know as soon as possible. You have the right to have your needs met, and the sooner you let me know, the sooner I can make arrangements to support you. Students with documented disabilities should contact the Office for Disability Services (ODS) at access@bu.edu or (617) 353-3658. Scheduling of alternative exam times and environments due to accommodations are handled by ODS directly.

Wellness

Your wellbeing matters. If you are struggling with course material, personal issues, or anything else, please reach out. I'm happy to work with you on extensions, alternative arrangements, or just to listen.

CDS593 Course Schedule - Spring 2026

Topics and dates in this table are subject to change. Please check back regularly for updates. We will also announce any major changes in class.

Assessment Rubrics

CDS 593 - Spring 2026

This document contains the rubrics used to evaluate your work in this course: portfolio pieces, the final project (or paper alternative), and participation. Use these rubrics to understand expectations and guide your work.

Portfolio Piece Rubric

Total: 25 points

Each portfolio piece is assessed on five categories. The same rubric applies to both Portfolio Pieces 1 and 2.

What We're Looking For

Conceptual Understanding: We want to see that you understand the why, not just the what. Why did you choose this model? Why these hyperparameters? What are the tradeoffs?

Technical Implementation: Your code should run cleanly when we execute it. Test your notebook from top to bottom before submitting.

Code Quality & Documentation: Write code that your classmates could read and learn from. Your notebook should read like a report, not a code dump. Guide the reader through your thinking.

Critical Analysis: Don't just report numbers, interpret them. What do the results tell you? What are the limitations? What would you do differently?

Peer Reviews: Provide feedback that would actually help your classmates improve. Be specific about what worked and what could be better.

Final Project Rubric

Total: 50 points

The final project is assessed on eight categories. Scope & Ambition and Evaluation & Analysis are each worth 10 points (scored on a 1-10 scale) because they're where the most important learning happens. The remaining categories are worth 5 points each. Proposal and checkpoint deliverables are graded separately for completion and are not included in this rubric.

See the project guide for scope expectations by team size, project ideas, and tips.

Scope & Ambition (10 points)

This is where team-size expectations are reflected. A pair doing a solo-sized project, or a trio doing a pair-sized project, will lose points here.

Design Decisions (5 points)

Technical Execution (5 points)

Use of Course Concepts (5 points)

Evaluation & Analysis (10 points)

Double-weighted because this is where most projects fall short. "I built it and it works" is not enough.

Iteration & Reflection (5 points)

Ethics & Limitations (5 points)

Documentation & Presentation (5 points)

Group Projects

For group projects, include a brief statement of who contributed what. Each team member will also complete a peer evaluation. Individual grades may be adjusted based on contribution.

Paper Presentation Rubric (Alternative to Final Project)

Total: 30 points

This option is for students who prefer a more theoretical approach. It requires critical analysis of a significant LLM paper plus a working demo. Contact the instructor by Week 4 to discuss paper selection and scheduling. Paper presentations can only be done solo (not in a group).

Participation Rubric

Total: 10 points (5 points for each half of the semester, 10% of course grade)

Participation is assessed through self-reflection. At the midpoint and end of the semester, you'll submit a short reflection (1-2 paragraphs) making a case for your participation score, with specific examples of your contributions. The teaching team will review and confirm or adjust your self-assessment.

Ways to Participate

You don't need to engage in every category. Focus on 2-3 that fit your learning style:

• Lecture participation: Consistent attendance, asking and answering questions, engaging in group work
• Discussion section: Consistent attendance and active engagement
• Office hours: Coming to office hours to ask questions or discuss project work
• Piazza: Asking or answering questions that help the community learn
• Peer support: Helping classmates troubleshoot code or understand concepts outside of class, going an extra mile with peer feedback on portfolio pieces

Scoring Guidelines (per half-semester)

Writing Your Self-Assessment

In your reflection, address:

1. Which categories did you focus on? (You don't need to do all of them.)
2. What specific examples demonstrate your engagement? (e.g., "I asked about X in lecture on [date]," "I helped [classmate] debug their portfolio piece," "I answered questions on Piazza about neural networks")
3. What score do you believe you earned (out of 5) and why?

You can describe general patterns of engagement, but include at least 2-3 specific examples to support your case. The teaching team will confirm your assessment or follow up if we see it differently.

Example Self-Assessments

Example A (requesting 5/5):

I focused on lecture participation and peer support this half of the semester. I attended every lecture and regularly asked questions, and typically led small group work and discussions and presentations, such as when I presented for our group in lectures 4 and 6. I also helped several classmates outside of class: I spent about an hour helping Jordan debug a shape mismatch error in their CNN for Portfolio Piece 1, and I worked through the backpropagation math with Alex before the midterm. I'm requesting 5 points because I consistently engaged in two categories and contributed to both my and my classmates' learning.

Example B (requesting 4/5):

My main form of participation was attending office hours. I came to office hours three times to ask questions about my portfolio piece—once about feature engineering, once about hyperparameter tuning, and once to get feedback on my analysis before submitting. I attended most lectures, and even though I didn't ask many questions in class, I participated in groupwork and feel like I was fully engaged there. I'm requesting 4 points because I have been attentive to the course in multiple ways but have been actively engaged in just one category.

Final Project Guide

The final project is where you put it all together. You'll build something real with LLMs, evaluate it honestly, and present it to the class. It's 30% of your grade and the biggest single thing you'll produce in this course.

You can work solo or in a team of 2-3. Solo is totally fine, most teams will be pairs, and three-person teams should expect a higher bar for scope and complexity (more on that below). There is a wide range for acceptable topics, the only requirement is that it has to meaningfully use LLMs and involve something you can actually evaluate.

Deliverable timeline

All intermediate deliverables are graded for completion only (using the usual late penalties). Full descriptions for each are in the relevant week guides.

Scope expectations by team size

Solo projects are more targeted. Pick one technique, apply it well, evaluate it thoroughly. You don't need a polished UI or a multi-component system. Focus on depth over breadth.

Pair projects (most common) should feel like building out an application. Two people means you can go deeper on evaluation, compare more approaches, or build a more complete system.

Three-person projects carry a higher expectation for scope and complexity. If three people could have done the same project as a pair, the scope wasn't ambitious enough. Documentation must include a clear division of labor. Each person's contribution should be individually substantial.

For group projects, include a brief statement of who contributed what. I will also eask students on teams to comment privately about whether there were issues in how work was divided up and will take this into account during evaluations.

What to build

Projects generally fall into a few categories. I've included examples at different team sizes so you can calibrate scope.

RAG applications

• Solo: Q&A system over a specific corpus (your research papers, a textbook, legal documents). Getting basic retrieval and generation working is just the starting point. Try multiple retrieval strategies (keyword vs. semantic, different chunking approaches), build a golden test set, and rigorously evaluate what works and what doesn't.
• Pair: Add a UI, more complex reasoning given retrieved information, more focus on safety and security for end-users. Evaluate both retrieval and generation quality separately. OR Testing fine-tuning alongside RAG.
• Trio: Full pipeline with access control or multi-user support, systematic error analysis, and a production-readiness assessment.

Fine-tuning projects

• Solo: Fine-tune a model for a specific task in an area of interest or research. Compare base vs. fine-tuned performance on a held-out test set. Compare results from different base models, hyperparameter choices, and reflect on design decisions.
• Pair: Compare fine-tuning approaches (full fine-tune vs. LoRA vs. prompt tuning) on the same task, or fine-tune for a harder task that requires careful data curation. Include cost/performance tradeoff analysis. Likely includes a user-facing component.
• Trio: Multi-stage fine-tuning pipeline, or fine-tuning combined with another technique (RAG, agents). Systematic evaluation across multiple dimensions.

Agent applications

• Solo: Single-purpose agent (research assistant, code reviewer, data analyst) with tool use and a user interface. Getting an agent to call a tool is just the starting point. Try different prompting strategies, evaluate on concrete tasks with clear success criteria, and reflect on what design decisions made the agent more or less reliable.
• Pair: Multi-step agent with multiple tools, error recovery, and a comparison of different prompting/orchestration strategies. Thoughtful analysis of safety, access issues, and legal risks.
• Trio: Multi-agent system or complex workflow with planning, memory, and evaluation of failure modes.

Model architecture projects

• Solo: Train a small language model from scratch on a specific corpus (song lyrics, legal text, a programming language). Experiment with architecture choices: attention variants, positional encoding, tokenization strategy. Evaluate how design decisions affect output quality. Won't rival GPT-5, but you'll learn a lot about what actually matters in the architecture. You may need more compute than you can get on Colab.
• Pair: Systematic comparison of architecture decisions. Train multiple small models with different configurations on the same data and evaluate tradeoffs (quality vs. training cost vs. inference speed). Experiment with training regimes, training set curation, hyperparameters, curriculum learning. Could include teacher-student distillation from a larger model.

Safety and red-teaming projects

• Solo: Build a guardrail or content filtering system for a specific use case. Or: systematic red-teaming of a model for a specific domain (medical advice, legal guidance, financial recommendations) with a taxonomy of failure modes. Or: bias auditing pipeline that detects and measures bias across demographic groups for a specific task, with mitigation strategies implemented and evaluated.
• Pair: Significant experimentation in safety and moderation as an additional component to a larger project (eg. solo-scoped RAG plus significant safety work)

These are starting points. The best projects come from your own interests and research areas.

Tips

Scope it right. You have about 3 weeks to build. A focused system that works and is well-evaluated beats an ambitious system that barely runs. If you bite off more than you can chew, you can round out the project with a postmortem of what you'd do differently with more time or compute.

The bar is higher than "it works." Getting a basic proof of concept running is step one, not the finish line. What makes a project strong is what happens after that. Why did you make the design choices you made? What alternatives did you consider? How do you know it's working well, and where does it fall short?

Have a baseline. "My RAG system answers questions" is not an evaluation. "My RAG system answers 73% of questions correctly vs. 41% without retrieval" is. Measure where you're starting from and know where you're going.

Document failures. Knowing what you tried, what happened, what you'd do differently, is (in the long-run) worth as much making things that work. A project that tried three approaches and carefully explains why each failed is stronger than one that tried one approach and got lucky.

Think about who's affected. Who would use this? What could go wrong? What biases might your system have? What ethical challenges give you pause? This may be "just" a class project, but what if it wasn't? How would you feel if what you built was actually deployed?

Iterate. Your first attempt probably won't be your best. Try something, evaluate it, adjust. The write-up should tell the story of that process, not just describe the final artifact.

Rubric overview

Total: 50 points (see the full rubric for detailed criteria at each level)

Proposal and checkpoint deliverables are graded separately for completion (not included in the 50 points above).

Getting unstuck

If you're blocked on data, compute, or scope, flag it in your next deliverable or come to office hours. That's what the check-ins are for.

• Office hours: see the course calendar
• Project clinic: Mon Apr 13 (come with your abstract)
• TA support during discussion section, Week 13

WEEK 1: Introduction (1 lecture)

Welcome to DS 593! For each week in the course I will give an overview of what we will be discussing in lectures, discussions, and what our expectations are for your work outside of class.

This week's checklist (due Sunday 1/25)

• (Note that there is NO discussion on Tue, Jan 20!)
• Complete entry survey (before the first lecture if possible!)
• Attend Lecture 1 on Wed, Jan 21 and turn-in the syllabus activity on paper
• Create a GitHub account and a GitHub Classroom repo
• Complete Reflection 1, pushed to GitHub
• Complete Lab 0, pushed to GitHub

This week's learning objectives

After Lecture 1 students will be able to...

• Explain the overall course objectives, deliverables, and key policies
• Use the course syllabus, website, and other resources to address most questions that might arise during the course
• Set up a GitHub account and create repos from GitHub Classroom for use during the course
• Select and use a python enviornment for local development (enough for the first two weeks of the course)
• Sign up for Google Colab and test using cloud compute
• Begin using AI tools to aid in set-up troubleshooting

Week 1 Reflection Prompts

• What do you hope to learn?
• If you had unlimited time and resources, what project would you dream of working on for this course?
• What has been one highlight and one lowlight of your language model interactions prior to this course?

Lab 0: GitHub and Google Colab

• Connect your GitHub account to GitHub Classroom and start your private repo
• Add your week 1 reflections to your repo
• Create a python notebook for your repo with some working code (hello world!)
• Set up a Google Colab account / begin to apply for student credits (this isn't graded, but it would be helpful to start now)
• Add three commits and a PR to your repo

WEEK 2: AI-Assisted Development & NLP Intro

This week we have just one lecture due to the snow day cancellation on Monday. We'll focus on how to effectively use AI tools for coding, then introduce the foundations of classical NLP.

This week's checklist (due Friday 1/30)

• (Note: Monday 1/26 class is cancelled due to weather)
• Attend Discussion Section (Tue, Jan 27): Getting started with Google Colab, GitHub Classroom, and using python for classical NLP
• Attend Lecture 2 (Wed, Jan 28): AI-assisted development + Classical NLP
• Complete Week 2 Reflection, pushed to GitHub
• Complete Lab 1, pushed to GitHub

This week's learning objectives

After Lecture 2 (Wed 1/28) students will be able to...

AI-Assisted Development:

• Identify appropriate AI coding tools for different development tasks (brainstorming, writing, debugging, understanding)
• Distinguish between AI coding interfaces (chat, edit mode, agentic) and when to use each
• Apply best practices for AI-assisted coding (verification, security awareness, understanding before shipping)
• Recognize common AI coding failures and when to be skeptical

Classical NLP:

• Explain the classical NLP pipeline: text to numbers to predictions
• Represent text documents using bag-of-words vectors
• Identify common preprocessing steps (lowercasing, stop words, stemming, etc.)
• Implement n-gram models for simple text generation
• Recognize the limitations of counting-based approaches (no context, no word meaning)

Discussion Section (Tue 1/27): Getting Started and Classic NLP

Note: This week's discussion happens before the lecture, so we'll use it as hands-on exploration rather than reinforcement.

Please bring your laptop to discussion! You will be coding during the class.

What you'll do:

1. Learn about Google Colab and instructions for set-up
2. Briefly review git and GitHub, troubleshoot any issues that came up with Lab 0
3. Start building on a template repo using a bag-of-words and TF-IDF approach to solve a text classification problem.

Week 2 Reflection Prompts

Write 300-500 words reflecting on this week's content, or the area in general. Some prompts to consider:

• What has your experience been using AI tools for coding so far? What works well? What doesn't?
• After learning about bag-of-words and n-grams, what surprised you about these simple approaches? What can they do well?
• How do you think about the tradeoff between using AI tools to move fast vs. understanding what the code does?
• What questions do you have about AI-assisted development and classic NLP that we didn't cover?

Remember to write in your own voice, without AI assistance. These reflections are graded on completion only and help me understand what's working for you.

Lab 1: Text Processing Basics

Due: Friday, Jan 30 by 11:59pm

Suggested explorations

• Build upon the bag-of-words and TF-IDF work you began during discussion - what can you do to make the model better? Explore the impact on the size of the vocabulary, data cleaning decisions, the size of the training set, or the type of classifier model used.
• Experiment with n-gram text generation. Try 3-grams, 4-grams... Is there a relationship between input datasets size and the ideal n-gram length? Can you formulate a way to think about using a variable number of n-grams (sometimes 1-grams, sometimes 2-grams depending on the word or word pair? what kinds of pairs are important to preserve?)
• Find an interesting dataset to try these techniques on. Can you predict amazon product star ratings from the review text? Can you generate poetry with a certain structure or jokes with n-grams and a little cleverness?

Resources for further learning

On AI coding tools

• A Practical Guide to AI-Assisted Coding Tools - a great guide to choosing the right AI and IDE for the job
• Making Tea While AI Codes - practical workflows and guardrails for AI-assisted development
• AI-Assisted Software Development: A Comprehensive Guide - how to actually use AI for coding, with prompt examples for different stages of a project
• GitHub Copilot Best Practices
• OpenAI - Best Practices for Prompt Engineering

Videos

• DataMListic - TF-IDF explained - A great explanation of BoW and TF-IDF with a computed example

Tutorials

• Understanding Bag of Words and TF-IDF: A Beginner-Friendly Guide
• N-gram Language Models - Chapter from Speech and Language Processing (more of a deep dive)

WEEK 3: Deep Learning Fundamentals & Tokenization

This week we dive into the foundations of modern NLP. On Monday we'll explore how neural networks learn through backpropagation and gradient descent. Tuesday's discussion gets you hands-on with PyTorch. Then Wednesday we'll see how text gets split into tokens - a critical step that affects everything downstream.

This week's checklist (due Friday 2/6)

• Attend Lecture 3 (Mon, Feb 3): Deep learning fundamentals
• Attend Discussion Section (Tue, Feb 4): PyTorch hands-on
• Attend Lecture 4 (Wed, Feb 5): Tokenization
• Complete Week 3 Reflection and Lab, pushed to GitHub

This week's learning objectives

After Lecture 3 (Mon 2/3) students will be able to...

Neural Networks:

• Explain how neural networks transform inputs through layers of weighted sums and activations
• Understand backpropagation as efficient application of the chain rule
• Describe gradient descent and how it minimizes loss functions
• Recognize why depth matters: hierarchical feature learning
• Identify the sequence modeling challenge for feed-forward networks
• Discuss the computational and environmental costs of training large models

After Lecture 4 (Wed 2/5) students will be able to...

Tokenization:

• Explain why tokenization choices affect model behavior (e.g., why LLMs struggle to count letters)
• Describe historical approaches: word-level, stemming, lemmatization
• Explain how subword tokenization (BPE, WordPiece) handles vocabulary challenges
• Understand the role of special tokens in chat models (system, user, assistant)
• Use tokenizer tools to see how models "see" text
• Discuss fairness implications of tokenization across languages
• Preview: understand that tokens become embeddings (vectors that capture meaning)

Discussion Section (Tue 2/4): PyTorch Hands-On

Please bring your laptop to discussion! You will be coding during the class.

What you'll do:

1. Get PyTorch installed and running (if not already)
2. Build a simple neural network from scratch
3. Train it on a toy task (e.g. simple classification)
4. Experiment with different architectures: more layers, different activations
5. See backpropagation in action with loss.backward()

Week 3 Reflection Prompts

Write 300-500 words reflecting on this week's content, or the area in general. Some prompts to consider:

• If you are new to deep learning, what clicked for you, and what questions do you still have? If you've studied the subject before, did you learn something or gain a new perspective?
• After learning about tokenization, were you surprised by how LLMs "see" text? What implications does this have?
• What do you think about the tokenization fairness discussion? Should companies address language efficiency differences? How?
• What connections do you see between tokenization choices and model capabilities?
• We discussed the environmental and financial costs of training large models. Who should bear these costs? Should there be regulations?

Remember to write in your own voice, without AI assistance. These reflections are graded on completion only and help me understand what's working for you.

Lab 2: Neural Networks and/or Tokenization Exploration

Due: Friday, Feb 6 by 11:59pm

Choose your focus (or do both, or something else!):

Option A: Neural Network Exploration

• Build a simple neural network in PyTorch from scratch
• Train it on a task (XOR, MNIST digits, simple classification)
• Experiment: What happens as you add layers? Change activation functions? Adjust learning rate?
• Visualize the loss curve - can you see gradient descent working?

Option B: Tokenization Exploration

• Experiment with different tokenizers (OpenAI, Claude, tiktoken)
• Compare token counts: code vs prose, English vs other languages, emojis
• Investigate the "strawberry" problem - why can't LLMs count letters?
• Explore fairness: same content in different languages, how do token counts differ?

Option C: Connect the Two

• Tokenize some text, convert to simple numerical representations
• Feed through a neural network for a simple task
• See the full pipeline: text, tokens, numbers, neural network, predictions

Resources for further learning

On neural networks

• 3Blue1Brown - Neural Networks series - Beautiful visualizations of backprop (Chapters 1-4)
• TensorFlow Playground - Visualize neural networks learning in real-time (we'll use this in class!)
• StatQuest - Backpropagation - Clear step-by-step walkthrough
• Loss Landscapes - Interactive visualizations of neural network loss surfaces

On tokenization

• OpenAI Tokenizer - See how GPT tokenizes text
• Claude Tokenizer - Compare with Claude's tokenization
• Let's build the GPT Tokenizer - Andrej Karpathy's walkthrough of BPE

Tutorials

• PyTorch tutorials - Official PyTorch docs
• Michael Nielsen: Neural Networks and Deep Learning - Free online book, very accessible

WEEK 4: Word Embeddings & Attention

This week we learn how neural networks capture meaning. Monday we'll explore word embeddings and the distributional hypothesis, the key insight behind how LLMs represent language. Wednesday we'll see how attention solves the bottleneck problem in sequence models and sets the stage for transformers.

This week's checklist (due Friday 2/13)

• Attend Lecture 5 (Mon, Feb 9): Word embeddings & sequence models
• Attend Discussion Section (Tue, Feb 10): Exploring word vectors
• Attend Lecture 6 (Wed, Feb 11): Attention mechanisms
• Complete Week 4 Reflection and Lab 3, pushed to GitHub

This week's learning objectives

After Lecture 5 (Mon 2/9) students will be able to...

Word Embeddings:

• Explain the distributional hypothesis: "you shall know a word by the company it keeps"
• Describe how Word2Vec learns word vectors by predicting context
• Use vector arithmetic to explore semantic relationships (king - man + woman = queen)
• Recognize that modern LLMs use the same concept, just at scale

Sequence Models:

• Understand the encoder-decoder framework for sequence-to-sequence tasks
• Explain why RNNs struggled with long sequences (vanishing gradients)
• Identify the bottleneck problem: compressing everything into one fixed vector
• Discuss bias in word embeddings and its real-world consequences

After Lecture 6 (Wed 2/11) students will be able to...

Attention:

• Explain how attention solves the bottleneck problem
• Understand the Query, Key, Value framework using the library metaphor
• Walk through scaled dot-product attention step by step
• Describe why we scale by √d_k and apply softmax
• Distinguish cross-attention (decoder attending to encoder) from self-attention (sequence attending to itself)
• Explain multi-head attention: why multiple heads capture different relationships (syntax, semantics, position)

Discussion Section (Tue 2/10): Word Vectors & PyTorch Practice

Part 1: Exploring Word Vectors (~25 min)

1. Load pre-trained word vectors (Word2Vec via gensim)
2. Explore word similarity: find nearest neighbors for different words
3. Try the famous analogies: king - man + woman = ?
4. Investigate bias: profession + gender associations
5. Visualize clusters in 2D (using t-SNE or PCA)

Part 2: Building a Text Pipeline in PyTorch (~25 min)

1. Tokenize text using a BPE tokenizer (HuggingFace tokenizers library)
2. Convert token IDs to embeddings (using nn.Embedding)
3. Build a simple feed-forward classifier (embeddings, average, linear layer, prediction)
4. Train on a small sentiment dataset and see the full pipeline

Week 4 Reflection Prompts

Write 300-500 words reflecting on this week's content. Pick one or two prompts that resonate, or go in your own direction:

• The distributional hypothesis says meaning comes from context. Do you understand words that way? When you encounter a new word, how do you figure out what it means and how does that compare to what Word2Vec does?
• Word embeddings encode "bank" as a single vector, but you effortlessly distinguish financial banks from riverbanks. What's your brain doing that Word2Vec can't? Does attention get closer to how you actually process language?
• We saw that embeddings trained on human text absorb human biases. If a company ships a product built on biased embeddings, who bears responsibility - the researchers, the company, the training data creators, or someone else? What would you want done about it?
• Now that you've seen embeddings, encoder-decoder models, and attention, are any project ideas starting to take shape for you? What problems or datasets interest you?
• Is there a concept from this week that felt like it "clicked" or one that still feels fuzzy? What would help it land?

Remember to write in your own voice, without AI assistance. These reflections are graded on completion only and help me understand what's working for you.

Lab 3: Embeddings and Attention

Due: Friday, Feb 13 by 11:59pm

Choose your focus:

Option A: Word Embeddings Exploration

• Load pre-trained embeddings (Word2Vec, GloVe, or fastText via gensim)
• Find interesting analogies and relationships
• Investigate bias: gender, profession, nationality associations
• Compare: do different embedding models have different biases?
• Visualize clusters of related words

Option B: Attention Implementation

• Implement scaled dot-product attention from scratch in PyTorch
• Test on simple sequences with small Q, K, V matrices
• Visualize attention weights as heatmaps
• Experiment: what happens with different d_k values? With multiple heads?
• Try self-attention: feed the same sequence as Q, K, and V and see what patterns emerge?

Option C: Connect the Two

• Start with word embeddings as your vectors
• Apply self-attention to a sentence to produce contextualized representations
• Visualize: which words attend to which? Does "it" attend to the noun it refers to?

Resources for further learning

On word embeddings

• Word2Vec Explained by Jay Alammar - Beautiful visualizations
• TensorFlow Embedding Projector - Explore word vectors interactively
• Bolukbasi et al. - Man is to Computer Programmer as Woman is to Homemaker? - The bias paper we discuss

On attention

• Visualizing A Neural Machine Translation Model by Jay Alammar - Attention introduction
• The Illustrated Transformer by Jay Alammar - Preview of next week

Videos

• Attention in transformers, visually explained by 3Blue1Brown - Chapter 6
• Word2Vec Paper Walkthrough by Yannic Kilcher

Papers (optional)

• Efficient Estimation of Word Representations (Mikolov et al., 2013) - The Word2Vec paper
  • Link
• Neural Machine Translation by Jointly Learning to Align and Translate (Bahdanau et al., 2014) - The attention breakthrough
  • Link

WEEK 5: Transformer Architecture

This week we assemble all the pieces you've learned (attention, embeddings, sequence models) into the transformer architecture that powers every major LLM. You'll see how encoders and decoders work together, understand the complete data flow from text to predictions, and practice drawing the architecture yourself. This is also exam prep week. You'll finish Portfolio Piece 1, complete your reflection, and prepare for Exam 1 on Monday.

Note: Monday Feb 16 is Presidents Day (no class). We meet Tuesday and Wednesday instead, and there is no discussion.

This week's checklist

• Attend Lecture 7 (Tue, Feb 17): Transformer Architecture
• Attend Lecture 8 (WEd, Feb 18): Decoding and Review
• Complete Portfolio Piece 1 and Reflection 5, pushed to GitHub (due Friday, Feb 20 by 11:59pm)
• Study for Exam 1 (Monday, Feb 23) - covers everything through transformers and decoding

No discussion section this week (Presidents Day week)

This week's learning objectives

After Lecture 7 (Tue 2/17) students will be able to...

• Trace complete data flow: text → tokens → embeddings → Q/K/V → attention → predictions
• Explain all transformer building blocks: positional encoding, residual connections, layer norm, FFN
• Draw encoder-decoder architecture from memory
• Distinguish encoder blocks (2 sublayers, runs once) from decoder blocks (3 sublayers, runs multiple times)
• Explain autoregressive generation and what feeds back at each step
• Distinguish training (teacher forcing, parallel) from inference (sequential generation)

After Lecture 8 (Wed 2/18) students will be able to...

• Explain greedy decoding and why it can produce repetitive or suboptimal outputs
• Describe beam search: how it works, beam width, when to use it
• Understand sampling strategies: temperature, top-k, top-p (nucleus sampling)
• Articulate tradeoffs: deterministic vs creative, quality vs diversity
• Connect decoding choices to real LLM behavior (why ChatGPT responses vary)
• Recognize common decoding problems: repetition, hallucination, mode collapse
• Feel prepared for the exam on Monday!

Portfolio Piece 1: Polish a Past Lab

Due: Friday, Feb 20 by 11:59pm

Task: Take one of your past labs (Labs 1-3) and polish it into a portfolio-quality project.

What "polish" means:

• Clean, well-documented code
• Thoughtful analysis and insights
• Clear visualizations

Where to find details:

• GitHub Classroom repo README has full instructions
• Rubric is in the assignment repo
• You have flexibility in how you extend and improve your chosen lab

Peer Review Process: After submission, you'll be assigned 2 peers' projects to review (assigned Monday 2/23, due Wednesday 2/25). Provide specific feedback: what worked well, a substantive question, something you learned.

Week 5 Reflection Prompts

Write 300-500 words reflecting on this week's content. Pick one or two prompts that resonate, or go in your own direction:

• Now that you've seen the full transformer architecture, what surprised you most? What design choices seem clever or confusing?
• Temperature, top-k, top-p... Which would you choose when and why? When is creativity good vs problematic in LLM outputs?
• As you prepare for the exam, what concepts from the past 5 weeks feel most central? What connections are you seeing?
• As you polish your portfolio piece, what stands out about your learning journey?

Remember to write in your own voice, without AI assistance. These reflections are graded on completion only and help me understand what's working for you.

Exam 1 Preparation

Exam 1: Monday, Feb 23 during class (12:20-1:35pm)

Coverage: Lectures 1-8 (tokenization, embeddings, attention, transformers, decoding)

Format: Short answer, conceptual questions, worked problems. Trace data flows, draw architectures, explain mechanisms.

Study tips:

• Practice drawing transformer architecture from memory
• Trace examples: text → tokens → embeddings → predictions
• Understand WHY (not just WHAT)
• Review notesheets and lecture notes online

Key topics: Tokenization (BPE), word embeddings, attention (Q/K/V, multi-head), transformers (encoder vs decoder), decoding (greedy, beam search, sampling)

Resources for further learning

Core readings

• The Illustrated Transformer by Jay Alammar - Read this again now that you've learned the pieces!
• Attention is All You Need (Vaswani et al., 2017) - The original transformer paper

Visualizations and demos

• Transformer Explainer - Interactive visualization
• BertViz - Visualize attention in transformers
• TensorFlow Embedding Projector - Explore word vectors

Videos

• Attention in transformers, visually explained by 3Blue1Brown - Chapter 6
• The Illustrated Transformer by Jay Alammar (video walkthrough)

Deep dives into sampling and beam search

For deeper understanding

• Formal Algorithms for Transformers - Mathematical treatment
• The Annotated Transformer - Code walkthrough with explanations
• Sampling and Beam Search - Lectures from Graham Neubig

WEEK 6: Exam 1

This is a short week. Monday was cancelled due to snow, and Exam 1 is on Wednesday. There is no new lecture content - use this week to consolidate what you've learned over the first five weeks and take the exam.

This week's checklist

• Take Exam 1 (Wed, Feb 25) during class time (12:20-1:35pm)
• Peer review deadline postponed to next Wedneseday

Exam 1

When: Wednesday, Feb 25 during class time (12:20-1:35pm)

Format:

• In-class, 75 minutes
• Closed-book, closed-notes
• Mix of question types: multiple choice, short answer, diagram/sketch, short essay

What's covered: Lectures 1-8 - Classical NLP, tokenization, embeddings, neural networks, encoder-decoder, attention, transformers, decoding

Key topics: See Lecture 8 notes for a complete list

Grading: 20% of final course grade

Discussion Section (Tue Feb 24): Implementing Attention and Transformers

Cancelled due to snow

Week 6 Reflection Prompts

Cancelled since the only class was the exam

Portfolio Piece 1: Peer Reviews

Dates and procedures have changed - see Piazza.

More Resources for Exam Prep

• Lecture slides and notesheets (all on the course website)
• The Illustrated Transformer - the best visual reference
• Transformer Explainer - interactive visualization
• Office hours: check the course calendar for this week's schedule

WEEK 7: Training at Scale and Post-Training

Welcome back from Exam 1! This week we shift from architecture to training - how do you actually take a transformer and turn it into a powerful LLM? Monday covers the massive engineering and data effort behind pre-training at scale: data pipelines, distributed compute, and the scaling laws that guide design decisions. Wednesday pivots to post-training: how raw pre-trained models become useful assistants like ChatGPT through instruction tuning, RLHF, and DPO.

Spring break follows this week (March 9-13).

This week's checklist

• Attend Lecture 9 (Mon, Mar 2): Training LLMs at scale
• Attend discussion section (Tue, Mar 3): Transformers in Python + project brainstorming
• Attend Lecture 10 (Wed, Mar 4): Post-training and RLHF
• Portfolio Piece 1 peer reviews due Wednesday, Mar 4 by 11:59pm (Gradescope)
• Week 7 Reflection due Friday, Mar 6 by 11:59pm (GitHub)
• Course survey due Friday, Mar 6 by 11:59pm (Gradescope, anonymous)
• Mid-course participation self-assessment due Friday, Mar 6 by 11:59pm (Gradescope)

This week's learning objectives

After Lecture 9 (Mon Mar 2) students will be able to...

• Articulate the qualitative differences between lab-scale transformers and production LLMs
• Explain pre-training objectives: next-token prediction (GPT) vs masked language modeling (BERT)
• Describe typical data sources for pre-training (Common Crawl, books, Wikipedia, code) and why data quality matters
• Recognize the scale of pre-training: trillions of tokens, weeks to months, thousands of GPUs
• Explain key distributed training strategies: data parallelism, model parallelism, pipeline parallelism
• Describe Chinchilla scaling laws and how they changed how models are trained
• Explain what "emergent abilities" means and the debate around them

After Lecture 10 (Wed Mar 4) students will be able to...

• Explain why post-training is necessary: base models predict tokens, they don't follow instructions
• Describe the three-stage post-training pipeline: SFT, reward model training, RLHF
• Explain how human preference rankings are collected and used to train reward models
• Describe DPO (Direct Preference Optimization) and why it simplifies RLHF
• Explain Constitutional AI: how models critique their own outputs using explicit principles
• Compare RLHF, DPO, and Constitutional AI trade-offs
• Describe common benchmarks (MMLU, TruthfulQA) and their limitations (Goodhart's Law, saturation)
• Explain why automated benchmarks are insufficient and describe alternatives (human evaluation, Chatbot Arena)

Discussion Section (Tue Mar 3): Transformers in Python + Project Brainstorming

This section has two parts.

Part 1: Implementing attention and transformers in Python (rescheduled from last week)

• Implement scaled dot-product attention from scratch in NumPy
• Trace data through a transformer block step by step
• Connect the math from Lectures 6-7 to working code

Part 2: Project brainstorming

• Start thinking about what you'd like to build for the final project
• Discuss ideas with classmates - what problems interest you? What would you actually use?
• You'll have more time to formalize proposals later in the semester

Week 7 Reflection Prompts

Write 300-500 words. Some prompts to consider (you don't need to answer all of them):

• What surprised you most about the scale of pre-training? The data volume? The compute cost? Who can afford to do it?
• Scaling laws say performance improves predictably with compute. Emergent abilities suggest surprises can still happen. Do you find these ideas in tension? Does it matter, for AI risk, whether capabilities emerge suddenly or gradually?
• After learning about RLHF and post-training, how do you think about the models you use (ChatGPT, Claude) differently?
• What's the hardest part of aligning LLMs with human values? Whose values should be encoded? How do you handle disagreement across cultures or communities?
• What questions are you taking into spring break? What are you most curious about for the second half of the course?

Write in your own voice, without AI assistance. Graded on completion only.

Portfolio Piece 1 Peer Reviews

Due: Wednesday, March 4 by 11:59pm on Gradescope

Weight: 20% of your portfolio piece grade (1% of overall course grade)

Review 2 peers' Portfolio Piece 1 submissions. For each, provide:

1. What worked well (2-3 specific observations)
2. A substantive question showing you engaged with their work
3. Something you learned from reading their project

Be specific - reference their actual code, choices, or analysis. "This was interesting" is not useful feedback. See the Participation and Assessment rubrics on the course site for guidance on what makes good peer feedback.

Mid-Course Participation Self-Assessment

Due: Friday, March 6 by 11:59pm on Gradescope

Write 1-2 paragraphs making a case for your participation score (out of 5) for the first half of the semester. Include at least 2-3 specific examples of ways you engaged - lecture questions, office hours visits, Piazza posts, helping classmates, etc. The teaching team will confirm or follow up if we see it differently.

See the Participation rubric for full details and example self-assessments.

Course Survey

Due: Friday, March 6 by 11:59pm on Gradescope

An anonymous survey to share feedback on the course so far. Takes about 15-25 minutes. Your honest input shapes how the course runs for the rest of the semester.

Resources for further learning

Pre-training and scaling

• GPT-3 Paper (Brown et al., 2020) - Language Models are Few-Shot Learners
• Chinchilla Paper (Hoffmann et al., 2022) - Training Compute-Optimal Large Language Models
• Scaling Laws for Neural Language Models (Kaplan et al., 2020)
• The Pile - EleutherAI's open-source training dataset

Post-training and alignment

• InstructGPT paper (Ouyang et al., 2022) - The original RLHF paper for GPT-3
• DPO paper (Rafailov et al., 2023) - Direct Preference Optimization
• Constitutional AI paper (Bai et al., 2022) - Anthropic's approach
• Hugging Face RLHF blog - Illustrating Reinforcement Learning from Human Feedback

Tools

• HuggingFace Model Hub - browse pre-trained and instruction-tuned models
• HuggingFace TRL library - for working with RLHF and DPO
• Google Colab - free GPU for running small models

WEEK 8: The LLM Landscape and Fine-Tuning Strategies

Welcome back from spring break! This week we zoom out to survey the model landscape and then zoom back in to ask: once you have a model, how do you adapt it? Monday covers the ecosystem of available LLMs - how to read model cards, compare open vs. closed models, and pick the right tool for a task. Wednesday gets practical with fine-tuning: the adaptation spectrum from simple prompting all the way to full fine-tuning, with a focus on parameter-efficient methods like LoRA that make fine-tuning accessible.

This week's checklist

• Attend your oral exam time, if applicable
• Attend Lecture 11 (Mon, Mar 16): The LLM Landscape
• Attend discussion section (Tue, Mar 17): Model selection and fine-tuning strategy design
• Attend Lecture 12 (Wed, Mar 18): Fine-Tuning Strategies
• Submit Week 8 Lab (due Sun, Mar 22 by 11:59pm)

This week's learning objectives

After Lecture 11 (Mon Mar 16) students will be able to...

• Navigate the major model families: GPT series, Claude, Gemini, Llama, Mistral, Falcon
• Compare proprietary and open-source models: cost, capability, customization, privacy
• Read and interpret model cards: what information should a model provide, and what's missing?
• Make informed model selection decisions for specific use cases
• Explain the foundation model paradigm: pre-train once, adapt for many tasks

After Lecture 12 (Wed Mar 18) students will be able to...

• Navigate the adaptation spectrum: API calls, prompting, PEFT, full fine-tuning, pre-training from scratch
• Explain why full fine-tuning can be expensive and impractical at scale
• Describe LoRA (Low-Rank Adaptation): freeze the base model, train small adapter matrices
• Identify when to use LoRA vs. full fine-tuning vs. just prompting
• Explain catastrophic forgetting and how training choices can prevent it
• Recognize that fine-tuning can degrade safety training, and why that matters

Discussion Section (Tue Mar 17): Loading and Fine-Tuning Open Models

Hands-on practice with open-source model weights in Python.

Activities:

1. Load a model from HuggingFace: Use transformers to download and run a small open model (e.g., Llama 3.2 1B or Qwen2.5-1.5B). Run a few generations and inspect the output.
2. Fine-tune on a small dataset: Use the transformers Trainer or a PEFT/LoRA setup to fine-tune on a toy dataset. Observe how loss changes and compare outputs before and after.
3. Discuss tradeoffs: What did you need to get this running? What would break at larger scale? What would you do differently for a real project?

Week 8 Lab: Exploring the LLM Landscape

Due: Sunday, March 22 by 11:59pm

What you'll do:

• Choose a task (e.g., summarization, code generation, question answering)
• Run the same prompts through 2-3 different models (mix open and proprietary if possible)
• Document the differences: quality, style, refusals, speed, cost per token
• Read and evaluate one model card critically: what's documented well? What's missing?
• Reflection: Based on your experiments, which model would you use for a real project, and why?

Deliverable: Push your notebook to GitHub (fully merged) and submit your repo link on Gradescope.

Note: Use the free tiers of APIs (OpenAI, Anthropic, together.ai, or HuggingFace Inference API) and small open models to keep costs low.

Resources for further learning

LLM landscape

• HuggingFace Open LLM Leaderboard - Browse current benchmarks
• Mistral AI - Leading open-weight model developer
• GPT-4 System Card
• LLaMA 4 Technical Report - Meta's latest
• Claude Model Card

Fine-tuning and PEFT

• LoRA paper (Hu et al., 2021) - Low-Rank Adaptation of Large Language Models
• HuggingFace PEFT library - LoRA and other PEFT methods
• HuggingFace fine-tuning tutorial
• QLoRA paper - Quantized LoRA for even more efficient fine-tuning
• together.ai - Cheap inference for open models

Staying current:

• Hugging Face Blog - New model releases, tutorials
• Artificial Analysis - Model comparisons, pricing, latency
• Chatbot Arena Leaderboard - Human preference rankings
• Open LLM Leaderboard

Frameworks:

• Stanford Foundation Models Report
• Stanford AI Index 2025 - Annual state of the field

WEEK 9: Prompt Engineering and Safety

This week covers two topics that are deeply connected: how to get LLMs to do what you want (prompt engineering), and what happens when someone tries to make them do things they shouldn't (prompt injection, jailbreaking, alignment failures). Monday teaches systematic prompt engineering - the techniques that separate casual users from skilled practitioners. Wednesday goes deeper on safety: red-teaming, alignment challenges, and responsible deployment. You'll come away understanding both how to wield these models effectively and what makes them hard to control.

This week's checklist

• Attend your oral exam time, if applicable
• Attend Lecture 13 (Mon, Mar 23): Prompt Engineering and Prompt Injection
• (No discussion this week)
• Attend Lecture 14 (Wed, Mar 25): Safety, Alignment, and Red-Teaming
• Submit Week 9 Reflection + Project ideation (due on Gradescope by Sun, Mar 29 by 11:59pm)

This week's learning objectives

After Lecture 13 (Mon Mar 23) students will be able to...

• Apply core prompting principles: specificity, context, examples, output format
• Design effective few-shot examples and know how many to use
• Implement chain-of-thought prompting and explain why it helps reasoning tasks
• Identify when zero-shot, few-shot, or chain-of-thought is the right approach
• Explain prompt injection (direct and indirect) and why it's hard to defend against
• Describe basic mitigation strategies: input sanitization, output filtering, instruction hierarchy

After Lecture 14 (Wed Mar 25) students will be able to...

• Define the alignment tax: making models safer often makes them less capable
• Explain jailbreaking: how roleplay, hypotheticals, and encoding bypass safety guardrails
• Design a basic red-teaming protocol for an LLM application
• Engage with value alignment questions: whose values, how to handle cultural disagreement
• Describe responsible disclosure practices when finding LLM vulnerabilities
• Distinguish between safety (preventing harm) and alignment (matching human values) as separate challenges

Discussion Section (Tue Mar 24): Red-Teaming Exercise

Discussion is cancelled this week due to a timing conflict.

Week 9 Reflection + Project Ideation

Due: Sunday, March 29 by 11:59pm

Weight: Counts as part of the completion-based tasks category. Graded for completion.

No lab this week. Two parts: a short reflection on course content, and your first project deliverable, both due on Gradescope.

Part 1: Reflection (200-300 words)

Some prompts to consider (you don't need to address all of them):

• What surprised you about prompt injection or jailbreaking? Were there techniques that seemed obviously exploitable? Are there obvious defenses that weren't implemented?
• The code/data separation problem (everything is tokens) is fundamentally different from traditional software security. Do you think this is a solvable problem, or something we'll always be managing?
• If you were deploying an LLM for a real application, what safety measures would you implement? What would you still be worried about?
• The Character.AI case and the alignment tax represent two failure modes: too little safety and too much. Which failure mode worries you more, and why?

Write in your own voice, without AI assistance.

Part 2: Project Ideation

Submit 2 project ideas. No commitment yet, this is to get you thinking early and let us flag scope issues before you're invested. The Gradescope assignment will walk you through these questions for each idea (with an optional open box if you have a third).

For each idea, answer:

1. What problem are you solving, and for whom? Describe a real task or pain point. Be specific: "summarizing legal contracts for paralegals" not "using AI for law."
2. What technique(s) would you use? Pick from what we've covered or will cover: prompting, fine-tuning, RAG, agents, or a combination. Why does that approach fit your problem better than the alternatives?
3. What data or resources would you need? What model would you start from? Is there a dataset you'd use, or would you need to collect/create one? Are there access or cost constraints?
4. What's your biggest open question or risk? What might not work? What would you need to figure out first?

Finally: Are you working solo or in a group? If group, list members. If looking for a partner, say so and we'll help match people.

Resources for further learning

Prompt engineering

• Anthropic: Prompt Engineering Guide
• OpenAI: Prompt Engineering Best Practices
• Chain-of-Thought Prompting paper (Wei et al., 2022)
• Self-Consistency paper (Wang et al., 2022)
• Learn Prompting - Comprehensive, practical guide

Security and safety

• Simon Willison: Prompt Injection Explained
• OWASP Top 10 for LLM Applications
• Jailbroken: How Does LLM Safety Training Fail? (Wei et al., 2023)
• Gandalf game - Learn prompt injection defenses by playing

Alignment and red-teaming

• Anthropic: Core Views on AI Safety
• GPT-4 System Card - Red-teaming methodology
• Constitutional AI paper - Anthropic's alignment approach (from Lecture 10)
• Prompt Injection Primer for Developers by Simon Willison

WEEK 10: Retrieval-Augmented Generation (RAG)

RAG is one of the most immediately useful techniques for building real LLM applications. It solves a fundamental problem: LLMs have knowledge cutoffs, they hallucinate on specific facts, and they can't access private or proprietary information. Retrieval can fix all of that. Monday introduces the core architecture: embed documents, store in a vector database, retrieve relevant chunks, inject into the prompt. Wednesday goes deeper: advanced retrieval strategies, evaluation, and what makes production RAG systems actually work.

This week's checklist

• Attend Lecture 15 (Mon, Mar 30): RAG Part 1 - Architecture and Foundations
• Attend discussion section (Tue, Apr 1): Tools for RAG implementation and evaluation
• Attend Lecture 16 (Wed, Apr 1): RAG Part 2 - Advanced Techniques and Evaluation
• Submit Week 10 Lab (due Sun, Apr 5 by 11:59pm)

This week's learning objectives

After Lecture 15 (Mon Mar 30) students will be able to...

• Explain the three core RAG problems it solves: knowledge cutoffs, hallucination on specifics, private data
• Describe the RAG pipeline: chunk, embed, store, retrieve, augment, generate
• Choose an appropriate chunking strategy for a given document type
• Explain why semantic (vector) search outperforms keyword matching for many queries, and when it doesn't
• Describe how vector databases use ANN algorithms to scale similarity search
• Distinguish bi-encoders (retrieval) from cross-encoders (re-ranking) and explain the two-stage pattern
• Describe hybrid search: combining BM25 keyword search with semantic search using Reciprocal Rank Fusion
• Know when RAG is the right approach vs. fine-tuning, or using both

After Lecture 16 (Wed Apr 1) students will be able to...

• Write effective RAG prompts: grounding instructions, fallback behavior, citation requirements
• Explain and apply contextual retrieval, HyDE, and multi-query retrieval, and know when each helps
• Explain how HNSW, IVF, and Product Quantization differ as ANN approaches
• Describe query routing and why some questions shouldn't go to a vector database at all
• Identify the three main RAG attack surfaces: prompt injection, data access/privacy, and database curation
• Apply defenses: metadata filtering, PII redaction, document governance
• Evaluate a RAG system: retrieval metrics (Precision@k, Recall@k, MRR) vs. generation metrics (faithfulness, relevance)
• Diagnose common RAG failures: is it a retrieval problem or a generation problem?

Discussion Section (Tue Apr 1): Tools for RAG

Hands-on practice with the tools you'll use to build and evaluate RAG systems.

Week 10 Lab: RAG Exploration

Due: Sunday, April 5 by 11:59pm

Weight: Counts as part of the completion-based tasks category. Graded for completion.

This lab is intentionally open-ended. Use it to explore RAG in a direction that connects to your project idea. Build something small, see what breaks, and come away with a sense of what a RAG-based project would actually involve.

What to do:

• Build a minimal RAG pipeline: chunk some documents, embed them, store in a vector DB, and retrieve against a few queries
• Experiment with at least one design choice: chunk size, number of retrieved chunks, embedding model, or advanced technique (contextual retrieval, HyDE, hybrid search)
• Document what you tried and what you noticed: when does retrieval work well? When does it fail?
• Reflect on connections to your project: could RAG fit into what you're building? What would you need?

Deliverable: Push your notebook to GitHub (fully merged) and submit your repo link on Gradescope.

Resources for further learning

RAG foundations

• RAG paper (Lewis et al., 2020) - Original retrieval-augmented generation
• Dense Passage Retrieval (Karpukhin et al., 2020) - Semantic search foundations
• Pinecone: What is RAG? - Accessible explainer

Advanced RAG

• Anthropic: Contextual Retrieval
• HyDE paper (Gao et al., 2022) - Hypothetical document embeddings
• RAGAS - Automated RAG evaluation framework

Tools

• ChromaDB - Simple, local vector database (recommended for getting started)
• FAISS - Fast similarity search from Meta
• Sentence Transformers - Open-source embedding models
• LangChain RAG guide - End-to-end tutorials
• LlamaIndex - RAG-focused framework

Lecture 1 - Welcome to CDS593!

Welcome!

What today will look like

• Perhaps surprisingly, a screen-free space by default

About class timing:

• Classes are 75 minutes (not the full 90 min block)
• Discussions are 50 minutes (not the full 75 min block)
• Exception: Last week's student presentations may use full blocks

Today's Agenda:

• Quick introductions and ice breaker
• What are LLMs? A brief history
• Tour of course website and syllabus activity
• Essential shell and git skills
• Challenge the AI

Who am I?

Prof. Lauren Wheelock

• Background
• Family
• Fun facts
• I'm learning alongside you - this field moves fast

Coffee Chats

Every other Tuesday, I'll have an hour open for coffee chats.

• Reserve a 20-minute slot, or drop in if nothing's booked
• Come individually or in small groups
• I'll provide the coffee

The one rule: You can't talk about the class. It's not office hours.

We can talk about life, career, interests, research, whatever else.

Sign-up link on the website

Our Teaching Team

Teaching Assistant: Bhoomika

Course Assistant: Naky

Office hours and contact info on the syllabus and Piazza

Who are YOU?

Highlights from the survey and conversations

You're excited about:

• Understanding how LLMs actually work (transformers, attention, the "magic")
• Building things: RAG systems, agents, applying concepts to real projects
• Preparing for industry and understanding a technology that's reshaping the world
• Some of you: approaching AI critically, wanting to understand before forming opinions

Who are YOU?

You're excited about:

• Understanding how LLMs actually work (transformers, attention, the "magic")
• Building things: RAG systems, agents, applying concepts to real projects
• Preparing for industry and understanding a technology that's reshaping the world
• Some of you: approaching AI critically, wanting to understand before forming opinions

You're a little nervous about:

• PyTorch (several of you have never used it - that's okay!)
• Git (it gets easier the more you use it)
• Keeping up with the material / time management
• The two midterms (we'll do lots of practice and review)

Who are YOU?

You bring a range of backgrounds:

• Some of you have built LLM-based systems and co-authored ML papers
• Some of you haven't taken a deep learning course yet
• This course is designed for all of you

My hope: you'll learn a lot from each other.

I may intentionally mix groups based on background to facilitate peer learning.

Who are YOU?

You're good at things I'm going to lean on:

• Resilience and persistence through difficult material
• Public speaking and explaining ideas to others
• Writing (professional and creative)
• Theory and math
• Creating visualizations and clear documentation
• Bringing people together around a project
• Asking questions and questioning others' thinking

A note on names

I want to learn all your names - please be patient with me for the first couple weeks!

If I mispronounce your name, please correct me. I'd rather be corrected than keep getting it wrong.

When you're here, you're HERE

• We'll have discussions and activities every class
• Laptops away unless we're actively using them
• I might cold-call (gently!)
• If you're too busy to engage, that's okay - but please don't come to class

About participation (10% of your grade)

You can engage in different ways - pick 2-3 that work for you:

• Participation in lecture
• Discussion section or office hours attendance
• Contributing on Piazza (answering peers' questions, sharing resources)
• Peer help and feedback

Twice this semester you'll write a short self-assessment making a case for your participation grade. I'll review and confirm or adjust.

Turning to the content with an Ice Breaker

Question: What's one thing you hope AI can do in the future?

What problems could AI solve? What would make your life easier? What would just be cool?

• 2-3 follow-ups

What even IS a Large Language Model?

What even IS a Large Language Model?

A neural network trained on massive amounts of text to predict the next token (word/piece of word) that somehow develops remarkable abilities to understand, reason, and generate language

A (Very) Brief History

Natural Language Processing (NLP) has been around since the 1950s

Goal: Make computers understand and generate human language

• 1950s: Alan Turing's "Computing Machinery and Intelligence" (1950) (the Turing Test)
• 1954: Georgetown-IBM experiment - first machine translation (Russian to English)
• Early approaches: hand-coded rules, symbolic AI
• Why it was hard: ambiguity, context-dependence, world knowledge

The Journey to LLMs

1950s-1990s: Rule-based systems

1990s-2000s: Statistical methods (bag-of-words, n-grams)

2013: Word embeddings (Word2Vec) - words become vectors!

2014-2017: RNNs and LSTMs for sequence modeling

2017: Transformers - "Attention is All You Need"

The Transformer Revolution (2017-Present)

2018: BERT (Google) - bidirectional understanding

2018: GPT-1 (OpenAI) - 117M parameters

2019: GPT-2 (OpenAI) - 1.5B parameters - "too dangerous to release"

2020: GPT-3 (OpenAI) - 175B parameters - few-shot learning!

2022: ChatGPT launches - AI goes mainstream

2023: GPT-4, Claude 2, LLaMA 2, Gemini - the race is on

2024-2025: Agents, reasoning models (o1), Claude Sonnet 4

The Pace of Change

Image generation - results

Image generation - policy

Code generation

• From fancy autocomplete to building entire apps

Multimodal

• Text to vision, audio, video

Context windows

• 4k tokens to 200k+ tokens

This course will teach you fundamentals that persist despite rapid change, and the skills to keep up with the changing landscape!

What this course is about

By the end of this course, you will:

• Understand how LLMs work (not just how to use them)
• Build transformers from scratch
• Apply LLMs to real problems (fine-tuning, prompting, RAG, agents)
• Think critically about bias, safety, and responsible deployment
• Build a professional portfolio of LLM projects

For detailed topics list and schedule, see our syllabus and the website.

Ethical Questions We'll Wrestle With

This technology raises questions we don't have answers to yet:

• Environmental impact - Training costs enormous energy
• Psychological safety - Reports of suicidality and psychosis in some users
• Bots and fakes - Proliferation of synthetic content
• Impact on learning - More classes are cancelling graded homework
• Artist and author rights - Unpaid labor used to train models
• Future of knowledge - What happens to deep expertise and persistence?
• The big questions - AI consciousness? Existential risk?

We won't solve these, but we'll think carefully about them throughout the semester.

Course Website Tour & Syllabus

Let's look at the course website

You're already here! Take a moment to explore:

• Syllabus
• Course Schedule
• Lecture notes (this page!)

What you'll find on the website

• Full syllabus with course policies
• Weekly schedule with due dates
• Lecture notes for every class
• Links to resources

Bookmark this page - it's your home base for the semester

How this course works

No traditional homework! Instead:

• Weekly reflections (200-500 words)
• Lab notebooks (hands-on experimentation)
• 2 portfolio pieces (polished projects)
• 2 midterm exams (theory, no AI)
• Final project (build something cool!)

All work goes in your GitHub portfolio - you'll have something to show employers!

Compute Resources

Towards the end of the course (and for your final project), you'll need more compute than your laptop can provide.

Recommended approach: Google Colab with education credits

Alternative: BU's Shared Computing Cluster (SCC)

If you find you need more compute than that, talk to us.

For first discussion (Tuesday): Try to have GitHub and a Colab account set up. Bhoomika can help troubleshoot any issues.

A note on how I teach

There will be times when I think I can explain something to you most effectively in person.

And there will be times when I think your best opportunity to learn comes from a YouTube video, a blog post, or other resources.

I'll be intentional about which is which. When I assign prework, it's because I genuinely think that's the best way for you to learn that material - not because I'm offloading teaching.

Key Course Policies

A few highlights before we dive into the full syllabus:

AI use for coding: Encouraged! Use it as much as you want. (Correspondingly: high expectations for project quality)

AI use for reflections: Please write in your own voice, no AI

Exams: No notes - just you and the concepts

Late work: 100% on time, 90% one day late, 80% two days late, exceptions are rare

Struggling? Reach out early! Extensions available, wellness matters

Syllabus Activity (20 min)

Time to dig into the details!

Instructions:

1. Form groups of 2-3 people
2. Grab a printed syllabus and worksheet
3. Work together to answer the questions
4. We'll reconvene in 15 minutes to discuss

Let's debrief

Essential Shell & Git Skills

What's your experience level with shell and git?

Drop hands polling

Why shell and git?

• Essential skills for developers and researchers that enable efficient iteration and collaboration
• Even MORE essential if you're handing the reins to AI development tools
• We'll use these throughout the course - your investment now will pay off later

Shell Basics: Navigation

The command line is your text-based interface to your computer

Essential commands:

pwd                   # Print working directory (where am I?)
ls                    # List files
ls -la                # List all files including hidden ones
cd folder_name        # Change directory
cd ..                 # Go up one level
cd ~                  # Go to home directory

If you're on windows, you can use git-bash for linux-compatible command line, or learn somewhat different commands for a shell like powershell

Tips:

• Use Tab for auto-completion
• Use Up Arrow to repeat previous commands
• Ctrl+C to cancel/abort

Shell Basics: File Operations

mkdir project_name       # Create a directory
touch filename.txt       # Create an empty file
echo "text" > file.txt   # Write text to file
cat filename.txt         # Display file contents

cp file.txt backup.txt   # Copy a file
mv old.txt new.txt       # Rename/move a file
rm filename.txt          # Delete a file

For Lab 0, you'll mostly use:

• cd to navigate to your projects folder
• mkdir to create your course repo folder
• git commands (next slide!)

Git & GitHub Essentials

Git = version control system (tracks changes to your code)

GitHub = hosting service for git repositories (plus collaboration tools)

You'll use GitHub Classroom for this course

Git Workflow for This Course

# One-time setup
git config --global user.name "Your Name"
git config --global user.email "your.email@bu.edu"

# For each lab/assignment
git clone [repo-url]           # Get the repo from GitHub
cd repo-name                   # Navigate into it

# Work on your code, then...
git add .                      # Stage all changes
git commit -m "Descriptive message"  # Save a snapshot
git push                       # Upload to GitHub

That's it! For this course, you mostly just need: clone, add, commit, push

Git Cheat Sheet

Common commands:

git status              # What's changed?
git add filename        # Stage specific file
git add .              # Stage everything
git commit -m "msg"    # Save a snapshot
git push               # Upload to GitHub
git pull               # Download from GitHub
git log                # See commit history

Good commit messages:

• "Add spam detection implementation"
• "Fix typo in reflection"
• "Complete Lab 1 embeddings exploration"

Pro tip: If you need to use "and" in your commit message, you're probably committing too many changes at once!

Resources for Shell & Git

• Git documentation
• GitHub's Git guides
• Interactive Git tutorial
• Ask in Piazza!
• Office hours

For Lab 0: You just need the basics - we'll practice more as the semester goes on

Challenge the AI!

Time to see what LLMs can (and can't) do

Let's put ChatGPT and Claude to the test!

Your mission: Come up with questions or tasks that might trip them up

A few starter ideas...

• Ask it to count the number of times the letter 'r' appears in "strawberry"
• Ask it about very recent events (knowledge cutoff!)
• Ask it to do complex multi-step reasoning
• Ask it something that requires true understanding vs pattern matching
• Try to get it to contradict itself

5 minutes: Pair up and try to stump the AI on your laptops

What did you find?

Why did these fail?

LLMs aren't perfect (yet)

LLMs are impressive but have clear limitations They're predicting patterns, not "thinking" (or are they?) Understanding their failures helps us use them responsibly.

This semester: we'll learn WHY they fail and how to work around it

Wrap-up

Before Friday (Lab 0 due)

1. Complete the intro survey (linked on Piazza)
2. Set up: GitHub account, Python environment, Jupyter notebooks
3. Create your course GitHub repository (link to come)
4. Write your first reflection (see website)
5. Lab 0 (see website)

Coming up

Monday: AI-assisted development + Classical NLP introduction

• How to use AI coding tools effectively
• Bag-of-words and TF-IDF
• Start of Lab 1

See you Monday!

CDS593 Syllabus Review Worksheet

Group members:

Concrete questions:

1. How are weekly reflections and lab notebooks submitted?

2. What happens if you submit work a day late?

3. Is attendance in discussions required?

4. If you get stuck on an assignment and your friend explains how to do it, what should you do?

5. If you have accommodations for exams, how soon should you request them?

6. Is there a final exam for the course?

7. Can you use AI tools when working on portfolio pieces?

8. Can you use AI tools to help write your reflections?

Open-ended questions:

1. What parts of the course policies seem standard and what parts seem unique?

   Standard: Unique:

2. Identify 2-3 things in the syllabus that concern you

3. What strategies could you use to address these concerns?

4. Identify 2-3 things on the syllabus that you're glad to see

5. List 2-3 questions you have about the course that aren't answered in the syllabus

6. What kind of engagement do you think you'll focus on for participation credit?

Lecture 2 - AI-Assisted Development & Classical NLP

Welcome back!

Last time: We explored what LLMs are, their history, how we're going to work together this term

Today:

• AI-assisted development
• A bit of classical NLP (BoW and ngrams)

Highlights from the syllabus activity and other logistics

• The "cite your friends" question

Concerns:

• Lack of deep learning background
• Strict late policy
• Exams (percentage, no notes)
• Grading fairly given tool access, collaborators
• Project open-endedness (choosing one, grading given that)
• Lots of deliverables
• "Ethical concern"?

You liked:

• Project-based structure
• Clear expectations
• No blackboard?
• AI use allowed
• No final
• Coffee chats!

Questions

• Time commitment
• iPads / how to take notes
• How labs and portfolio pieces work
• Suggestions for books / other resources
• Forming teams

Both liked and disliked:

• No laptop policy
• Oral exam redo option

Logistics:

• Swapping L3 and L4
• Renaming / numbering labs and reflections (see schedule)

How to Report a Problem (Life Skill!)

When you message us (or a future coworker/manager) about a technical issue, include:

1. What you did - Be specific!

• What tool/command/interface?
• What did you click or type?
• Any other context (network connections, previous actions)

2. What you expected - What should have happened?

3. What actually happened - Error messages, screenshots, exact text

4. What you've tried yourself - Steps you've taken to debug that have failed

Bad: "Torch isn't working for me"

Good: "I ran python train.py in VS Code's terminal on my Mac. I expected it to start training, but instead I got:

Traceback (most recent call last):
  File "train.py", line 1, in <module>
    import torch
ModuleNotFoundError: No module named 'torch'

I installed PyTorch yesterday using pip install torch. I'm using Python 3.11 and I'm not using a virtual environment. When I run which python I get /usr/bin/python3. I tried running pip install torch again and it says 'Requirement already satisfied.' I also tried pip3 install torch with the same result."

Bad: "I can't push to GitHub"

Good: "I clicked 'Push' in GitHub Desktop last night. I expected my commits to appear on github.com, but instead I got:

Updates were rejected because the remote contains work that you do not have locally.

I'm the only one working on this repo and I haven't made changes from another computer. When I run git status I see Your branch and 'origin/main' have diverged, and have 1 and 1 different commits each. I'm not sure how the remote got a different commit since I haven't pushed from anywhere else."

Ice-breaker

Question: What's one thing you used an AI tool for in the last week?

Share with a neighbor, then we'll hear a few examples.

Part 1: AI-Assisted Development

How AI Can Help You Code

AI tools can assist at many different stages of development:

Brainstorming and planning

• "What's a good architecture for a web scraper?"
• "What libraries should I use for text processing in Python?"

Writing code

• Autocomplete, generating functions, boilerplate

Debugging and fixing errors

• "Why am I getting this error?" with the stack trace

Understanding unfamiliar code

• "Explain what this function does" when joining a new project

Writing tests and documentation

• "Write unit tests for this function"
• "Add docstrings to these methods"

The Tools Landscape

There are two things to understand: the interface (how you interact) and the model (the AI doing the work).

Interfaces / IDEs:

• Cursor - AI-native IDE (fork of VS Code), $20/month or free tier
• VS Code + Extensions - Claude extension, GitHub Copilot extension
• Chat interfaces - ChatGPT, Claude.ai, Gemini

Underlying Models:

• Anthropic's Claude 4.5 - Opus, Sonnet, Haiku
• OpenAI's GPT-5.2 (Thinking/Pro/Instant/Codex)
• Google's Gemini 3 (Pro/Flash)
• xAI's Grok 4 (Reasoning/Non-reasoning/Code/Mini)
• Open source: Llama, Mistral, DeepSeek

NOTE that the interface and model are separable!

Free vs Paid Options

Free or free for students:

• Claude in VS Code - The smaller Claude models (Haiku) work without an account in agent mode
• GitHub Copilot - Free for students with GitHub Education pack
• ChatGPT - Free tier available
• Claude.ai - Free tier with usage limits
• Google Colab AI - Free tier available
• Cursor - Free tier with limited requests

Paid options:

• Claude Pro ($20/month) - Access to larger models, more usage
• ChatGPT Plus ($20/month) - Latest model, plugins, more features
• Cursor Pro ($20/month) - More AI requests, better models

Modes of AI-Assisted Coding

Modern AI coding tools have different modes for different tasks:

Chat / Ask mode

• You ask questions, get answers
• Good for: understanding concepts, explaining errors, brainstorming

Edit mode

• AI modifies specific code you highlight
• Good for: refactoring, fixing bugs in specific places

Agent / Composer mode

• AI autonomously makes changes across multiple files
• Good for: larger features, multi-file refactors
• More powerful but needs more oversight!

Pro tip: Help the AI help you

• Most tools support project-level instructions (.cursorrules, CLAUDE.md, etc.)
• Use these to specify coding style, conventions, preferred libraries
• Point the agent to your README or docs: "Read README.md first to understand the project structure"
• The more context you provide upfront, the less you'll need to correct later

A Workflow for AI-Assisted Coding

When working with AI on non-trivial tasks:

Step 1: Propose

• Present your goal with context
• Ask AI to suggest approaches and raise concerns
• Don't start coding yet!

Step 2: Refine

• Answer questions, discuss edge cases
• Clarify ambiguities before implementation
• Don't start coding yet!

Step 3: Execute

• Define clear success criteria ("all tests pass", "API returns 200")
• Give permission to proceed

Step 4: Supervise

• Make sure the output is as expected
• Understand the code generated - if you don't, ask the AI to explain!

"Treat the AI like a slightly dopey intern": "Write a function that..." is okay. "Write a function that does X, without using external dependencies, returning a dict with keys a, b, c" is better. Vague prompts produce vague results.

The Cup of Tea Test

Can you define success criteria clearly enough that you could walk away while the AI iterates?

Good success criteria:

• "All tests pass"
• "API returns 200 with valid JSON"
• "Script runs without errors and produces output.csv"

Vague criteria (harder for AI to iterate on):

• "Make it work"
• "Clean this up"
• "Fix the bug"

Write tests first, then tell the AI "make these tests pass without changing them."

Why Git Matters Even More Now

When AI can make sweeping changes to your code, version control becomes critical.

Git is your safety net:

• You can always roll back if AI breaks something
• You can see exactly what changed
• You can experiment fearlessly

Good habits:

• Commit before asking AI to make big changes
• Review diffs carefully before committing AI-generated code
• Use branches for experimental AI-assisted features

The undo button for AI mistakes = git checkout or git revert

When to Be Skeptical

AI coding tools are powerful, but they have blind spots.

Be extra careful with:

• Security-sensitive code (authentication, encryption, input validation)
• Database operations (SQL injection is common in AI-generated code)
• API keys and credentials (AI sometimes hardcodes these!)
• Dependencies (AI can "hallucinate" packages that don't exist)
• Anything you don't understand (if you can't explain it, you can't debug it)

What Does the Research Say?

A 2025 study of open-source projects using AI coding assistants found:

Initial velocity gains:

• 281% increase in lines of code added in the first month
• But only 28.6% sustained increase after two months

Quality concerns:

• 30% increase in static analysis warnings
• 41% increase in code complexity
• Quality declines persisted even after velocity gains faded

Discussion: What might explain these patterns? What does "more code" actually mean for a project? How might this affect how teams should adopt AI tools?

Red Flags During AI Sessions

Stop and reassess if you notice:

• Very long conversations - AI loses context over extended chats
• Unexplained deletion of tests or code - AI may "simplify" things you need
• AI forgetting your original goals - Context drift is real
• Circular problem-solving - Same approaches failing repeatedly

Recovery tactics:

• Revert and try with adjusted prompts
• Ask AI: "What's going wrong here? What are you trying to accomplish?"
• Start a fresh conversation with a summary of what you need
• Use git commits like video game save points - checkpoint frequently!

Remember: Studies show AI-generated code tends to be more complex and harder to maintain. If the AI's solution feels convoluted, it probably is. Simpler is usually better.

Real Failures: The Tea App Breach (July 2025)

A women's dating advice app called Tea announced they had been "hacked."

72,000 images were exposed, including 13,000 government IDs from user verification.

What actually happened?

Nobody hacked them. The Firebase storage was left completely open with default settings. The AI-generated code didn't include any authorization policies.

The developers were "vibe-coding" - trusting AI to handle implementation without understanding security fundamentals.

More Cautionary Tales

The Replit Database Deletion: An AI agent was told to help develop a project. It decided the database "needed cleanup" and deleted it - violating a direct instruction prohibiting modifications.

Hallucinated Packages: AI sometimes invents package names that don't exist. Attackers have registered these fake package names with malicious code. If you blindly pip install what AI suggests...

The Statistics: A 2025 study found that 45% of AI-generated code contains security flaws. When given a choice between secure and insecure approaches, LLMs choose the insecure path nearly half the time.

The lesson: AI is a powerful assistant, not a replacement for understanding what your code does.

Activity: Build Something Fun with AI (10 min)

Pair up and use an AI tool to build something small and interactive in Python.

Process:

1. Open a new notebook or python script and AI tool
2. Decide what you want to build
3. Prompt the AI and iterate
4. We'll discuss - What went well? What didn't?

Ideas:

• A magic 8-ball that answers questions
• A text-based choose-your-own-adventure
• A fortune cookie generator
• A simple game (trivia, rock-paper-scissors, mad libs)
• A password generator
• A maze generator / solver

Debrief: What did you notice?

The Bottom Line on AI Dev Tools

Use them! They're incredibly powerful and will be part of your professional toolkit.

Stay critical. Verify everything, especially security-sensitive code.

Focus on understanding. If you can't explain the code, you don't own it.

Git is your friend. Commit often, review diffs, don't be afraid to revert.

You are responsible for the code you submit, regardless of who (or what) wrote it.

For more blog posts with frameworks and prompt examples see the "Week 2 Guide"

Part 2: A Taste of Classical NLP

The Landscape of NLP Tasks

NLP is a broad field. Here are some classic problems:

Classification - Is this email spam? Is this review positive or negative?

Sequence labeling - What part of speech is each word? Which words are names/places? (Historically solved with Hidden Markov Models)

Sequence-to-sequence - Translate English to French. Summarize this article.

Generation - Write the next word, sentence, or paragraph.

Today we'll focus on classification and generation - the two ends of the spectrum.

The Simplest Idea: Just Count Words

Bag of Words (BoW): Represent a document by which words appear and how often.

Document: "I love NLP. I love machine learning."

Vocabulary: [I, love, NLP, machine, learning]
Vector:     [2,   2,    1,      1,       1]

That's it. Count the words, ignore the order.

Why "Bag" of Words?

Because we throw the words in a bag and shake it up. Order is lost!

"Dog bites man" -> {dog: 1, bites: 1, man: 1}
"Man bites dog" -> {dog: 1, bites: 1, man: 1}

Same representation. Very different meanings.

This is a huge limitation. But BoW is fast, simple, and works surprisingly well for some tasks.

What Can You Do With BoW?

Once you have word counts, you have numbers. Now you can use any classifier!

Naive Bayes - The classic choice for text. Fast, simple, works surprisingly well for spam detection.

Logistic regression, SVM, random forests... - All work with BoW features.

Remember: BoW is NOT a model, it is just feature engineering. You're turning text into a table of numbers. After that, you can use whatever machine learning method you like.

Before You Count: Data Cleaning

Raw text is messy. Before building a BoW representation, what might we need to do?

Common Preprocessing Steps

Lowercasing - "The" and "the" should be the same word

Punctuation removal - "learning." and "learning" are the same

Stop word removal - "the", "a", "is" don't tell us much

Stemming - "running", "runs", "ran" all become "run"

Lemmatization - Like stemming but smarter ("better" becomes "good")

Which ones matter depends on your task!

TF-IDF to address word rarity

With raw word counts, common words dominate. "The" appears in almost every document but tells us nothing about the topic.

TF-IDF (Term Frequency–Inverse Document Frequency) is one way to address this:

$$\text{TF-IDF}(t,d)=\text{TF}(t,d)\times \log \left(\frac{N}{\text{DF}(t)}\right)$$

Where:

• TF(t, d) = how often term t appears in document d
• DF(t) = how many documents contain term t
• N = total number of documents

Words that appear frequently in one document but rarely across all documents get high scores.

BoW in Practice

From Counting to Generating: N-grams

Step 1: Count transitions

Go through your training text and count: "After word X, what word Y appeared?" (This is bi-grams - we can also do tri-grams or higher)

Step 2: Convert to probabilities

If "love" appeared 10 times, and it was followed by "NLP" 3 times and "machine" 7 times:

• P(NLP | love) = 3/10 = 30%
• P(machine | love) = 7/10 = 70%

Step 3: Generate

Start with a word. Roll the dice based on probabilities. Repeat!

Let's Build One!

Training text: "I love NLP. I love machine learning."

Bigram counts:

• After "I": "love" appears 2 times (100%)
• After "love": "NLP" (1 time, 50%), "machine" (1 time, 50%)
• After "machine": "learning" (1 time, 100%)

To generate: Start with "I", then pick the next word based on probabilities.

Demo: N-gram Text Generation

Let's see this in action with a Python demo.

What to watch for:

• How do the probabilities come from the training text?
• What kinds of sentences does it generate?
• Do you recognize any fragments?

Activity: Talk to ELIZA (5 min)

ELIZA was created in 1966 - one of the first "chatbots." It was convincing enough that some users believed they were talking to a real therapist.

Try it: Go to njit.edu/~ronkowit/eliza.html or search "ELIZA chatbot online"

As you chat, think about:

• What patterns do you notice in ELIZA's responses?
• How do you think it works? (Hint: no neural networks existed in 1966!)
• What tricks make it seem more intelligent than it is?

What N-grams Can't Do

"The trophy would not fit in the suitcase because it was too large."

What is "it"? The trophy? The suitcase?

N-grams struggle with:

• Long-range dependencies (the Markov assumption is too limiting)
• Generating novel combinations (only what we've seen)
• Understanding meaning (no semantics, just statistics)

LLMs solve these problems. We'll see how later in the course.

Why Learn This Old Stuff?

1. The limitations motivate the innovations - When we study attention and transformers, you'll see they directly solve the problems n-grams couldn't: long-range dependencies, semantic understanding, generalization beyond training data.

2. Simplicity - sometimes simple methods are good enough (and faster!). Not every problem needs GPT-5.

3. Building blocks - ideas like tokenization, probability distributions over sequences, and context windows carry directly into modern architectures.

4. Debugging intuition - understanding why models fail helps you prompt better and catch errors.

5. Interview questions - you'd be surprised how often these come up

What We Learned Today

AI-assisted development:

• Different phases: brainstorming, coding, debugging, understanding
• Free and paid tools available
• Different modes: chat, edit, agent
• Git as your safety net
• When to be skeptical (security, credentials, hallucinated packages)

Classical NLP:

• Bag of Words: count words, ignore order
• N-grams and Markov chains: predict next word from recent history
• Limitations that motivate modern methods

Looking Ahead

Lab 1 due Friday: Explore text classification and n-gram generation

Monday: Deep learning fundamentals

• How neural networks learn
• Backpropagation and gradient descent
• If you're new - check out the Week 3 guide for resources to view before class

Wednesday: Tokenization

• How do LLMs split text into pieces?
• Subword tokenization (BPE)
• Why tokenization affects what models can and can't do

Lecture 3 - Neural Networks & Deep Learning Foundations

Welcome back!

Last time: AI-assisted development + classical NLP (bag-of-words, n-grams)

Today: The machinery that makes it all work - neural networks and deep learning

Logistics:

• Today may be review (or not) - mixing it up
• Week numbering for assignments
• Last day for add/drop

Ice breaker

If you could go back in time, at what age would you have given yourself access to ChatGPT?

https://answergarden.ch/5123533

Agenda for today

1. Neural networks review - the building blocks
2. How learning works - backpropagation
3. Training in practice + hands-on exploration
4. Looking ahead: sequences and scale

The landscape of neural networks

Today: Feed-forward networks. The foundation for everything else.

Part 1: Neural Networks - The Building Blocks

The biological inspiration

The analogy breaks down quickly, but it remains an inspiration for network design

A single artificial neuron

$$a=f\left(\sum _i{w}_i{x}_i+b\right)$$

Activation functions - why we need them

Without activation (just linear combinations):

Multiple layers = still just one linear transformation!

With activation (non-linearity):

We can approximate any function!

This is the key to deep learning's power

Quick thought experiment

What would happen if we removed ALL activation functions from a 10-layer network?

Answer: It collapses to a single linear transformation. Ten layers of matrix multiplication = one matrix multiplication. All that depth buys you nothing without non-linearity!

Common activation functions

Multi-layer networks

• Input layer: Your features (e.g., word embeddings)
• Hidden layers: Where the magic happens
• Output layer: Your prediction

Each layer transforms the representation

It's just an equation

A neural network is just a big equation with many parameters

Single neuron: $y=f(w_1{x}_1+w_2{x}_2+\dots +b)$

One hidden layer (vector form): $y=f_2(W_2\cdot f_1(W_1\cdot x+b_1)+b_2)$

Two hidden layers: $y=f_3(W_3\cdot f_2(W_2\cdot f_1(W_1\cdot x+b_1)+b_2)+b_3)$

GPT-5 (~10T parameters): Same pattern, just... more.

Familiar friends in disguise

Linear regression is a neural network:

• 0 hidden layers
• No activation function
• y = Wx + b

Logistic regression is a neural network:

• 0 hidden layers
• Sigmoid activation
• y = σ(Wx + b)

Large networks generalize from here

Using NNs: Forward propagation

1. Start with inputs
2. Multiply by weights, add bias
3. Apply activation function
4. Repeat for each layer
5. Get prediction at output

This is just matrix multiplication + activation!

Think-pair-share: Why go deep?

Question: Why use multiple hidden layers instead of one giant layer?

Why depth matters

Deep networks learn hierarchical representations

Why depth matters

Example: Learning word embeddings

Layer 1: Character patterns (prefixes, suffixes, common letter combinations)

Layer 2: Syntactic roles (noun vs verb, singular vs plural)

Layer 3: Semantic clusters (animals, emotions, actions)

This is how neural networks learn rich representations: each layer builds on the previous.

Part 2: How Learning Works - Backpropagation

The learning problem

We have:

• Network with random initial weights
• Training data (input, correct output)

We want:

• Adjust weights so predictions match correct outputs

But how do we know what "match" means?

Learning as optimization

Key insight: Frame learning as minimization

We need two things:

The recipe:

1. Make a prediction
2. Measure how wrong we are (loss)
3. Adjust weights to reduce loss
4. Repeat

Quick chat: What's "wrong"?

Turn to a neighbor: How would you measure "wrongness" for each task?

Gradient descent intuition

Imagine: Lost in foggy mountains, trying to reach the valley

Strategy: Feel the slope under your feet, step downhill

Repeat: Until you can't go lower

The reality:

Gradient descent: the math

Gradient: Vector pointing in direction of steepest increase

We want to go downhill, so we go the opposite direction:

$$w_{new}=w_{old}-\eta \cdot \nabla L$$

Where $\eta$ (eta) is the learning rate

Learning rate matters

Draw on the board:

Too small: Takes forever, might get stuck

Too large: Overshoot the minimum, bounce around or diverge

Just right: Converge efficiently to minimum

In practice: Start with 0.001, adjust based on training curves

Stochastic Gradient Descent (SGD)

Full gradient descent: Compute gradient using ALL training examples

$$\nabla L=\frac{1}{N}\sum _{i=1}^N\nabla L_i$$

Problem: N might be millions. One step = one pass through entire dataset!

Stochastic GD: Use a random mini-batch of examples instead

$$\nabla L\approx \frac{1}{m}\sum _{i=1}^m\nabla L_i\text{(m << N)}$$

Typical batch sizes: 32, 64, 128, 256

The answer is counterintuitive:

1. Speed tradeoff: Each step is noisier, but we can take many more steps
2. Noise is a feature: Random kicks help escape local minima and saddle points
3. Regularization effect: The noise actually improves generalization
4. Practical necessity: GPU memory can only fit a batch, not millions of examples

This is what everyone actually uses (usually with Adam optimizer on top)

But how do we compute gradients?

Problem: Our network has thousands/millions of parameters

Question: How does changing one weight affect the final loss?

Answer: The chain rule from calculus!

This is backpropagation

Backpropagation - the key insight

Forward pass: Input -> Layer 1 -> Layer 2 -> Output -> Loss

Backward pass: Propagate error information backward through the network

The manager metaphor

Chain rule: If A affects B, and B affects C, then:

$$\frac{\partial C}{\partial A}=\frac{\partial C}{\partial B}\times \frac{\partial B}{\partial A}$$

Backprop is just an efficient way to apply the chain rule

Loss functions - measuring wrongness

Loss function: A single number telling us how wrong we are

Higher loss = worse predictions

Goal: Find parameters that minimize loss

Mean Squared Error (MSE)

For regression (predicting continuous values):

$$L=\frac{1}{n}\sum _{i=1}^n(y_i-{\hat{y}}_i{)}^2$$

Intuition: Penalize distance from correct answer, squared

Why squared?

• Differentiable everywhere (no absolute value kink)
• Bigger errors hurt more than small errors

Example: Predicting house prices, temperature, stock prices

Cross-Entropy Loss

For classification (predicting categories):

$$L=-\sum _c{y}_c\log ({\hat{y}}_c)$$

Where y is true label (one-hot), ŷ is predicted probabilities

Binary case: L = -[y log(ŷ) + (1-y) log(1-ŷ)]

Intuition: Punish confident wrong predictions severely

Softmax: from scores to probabilities

Before cross-entropy, we need probabilities. Softmax converts raw scores to probabilities:

$$\text{softmax}(z_i)=\frac{e^{z_i}}{{\sum }_j{e}^{z_j}}$$

Properties:

• All outputs between 0 and 1
• All outputs sum to 1
• Preserves ordering (highest score -> highest probability)
• Differentiable!

Example: Scores [2.0, 1.0, 0.1] -> Probabilities [0.66, 0.24, 0.10]

KL Divergence (preview)

Kullback-Leibler divergence: How different are two probability distributions?

$$D_{KL}(P||Q)=\sum _{x}P(x)\log \frac{P(x)}{Q(x)}$$

Not symmetric: $KL(P||Q)\ne KL(Q||P)$

Cross-entropy = KL divergence + constant (when P is fixed)

Where you'll see it:

• Training LLMs (comparing predicted vs actual next-word distributions)
• Variational autoencoders
• Knowledge distillation (making smaller models mimic bigger ones)

Loss functions must be differentiable

Why? We need to compute gradients!

$\partial L/\partial w$ tells us how to adjust weights

If loss has "kinks" or discontinuities:

• Can't compute gradient at those points
• Optimization gets stuck or behaves badly

This is why we use:

• Squared error (not absolute error)
• Cross-entropy (not 0/1 accuracy)
• Smooth activation functions (or ReLU, which is "almost" smooth)

Backprop example: setup

Tiny network: 1 input, 1 hidden, 1 output

Backprop example: forward pass

Step through the computation:

$h=\text{ReLU}(w_1\cdot x)=\text{ReLU}(0.5\times 2)=\text{ReLU}(1)=$ 1

$\hat{y}=w_2\cdot h=1.0\times 1=$ 1

$L=(\hat{y}-y{)}^2=(1-3{)}^2=$ 4

We predicted 1, target was 3. Loss = 4.

Now: how should we adjust $w_1$ and $w_2$ to reduce loss?

Backprop example: backward pass

Apply chain rule, working backward:

$$\frac{\partial L}{\partial \hat{y}}=2(\hat{y}-y)=2(1-3)=-4$$

$$\frac{\partial \hat{y}}{\partial w_2}=h=1$$

$$\frac{\partial L}{\partial w_2}=\frac{\partial L}{\partial \hat{y}}\cdot \frac{\partial \hat{y}}{\partial w_2}=(-4)(1)=-4$$

Gradient is -4: Increasing $w_2$ would decrease loss (good!)

Backprop example: the update

Update rule: $w_{new}=w_{old}-\eta \cdot \text{gradient}$

With learning rate $\eta =0.1$:

$$w_2^{new}=1.0-0.1\times (-4)=1.0+0.4=1.4$$

Sanity check: New prediction would be $\hat{y}=1.4\times 1=1.4$

Closer to target of 3! Loss would drop from 4 to 2.56.

Repeat thousands of times -> weights converge to good values

PyTorch does the math for you

You never write gradient code. Frameworks handle backprop automatically.

import torch

# Define network
model = torch.nn.Sequential(
    torch.nn.Linear(10, 5),
    torch.nn.ReLU(),
    torch.nn.Linear(5, 1)
)

# Forward pass - you write this
prediction = model(x)
loss = (prediction - target) ** 2

# Backward pass - PyTorch does this automatically!
loss.backward()

# Update weights
optimizer.step()

The magic: .backward() applies the chain rule through your entire network

This is why we can train models with billions of parameters

Training loop - putting it together

Repeat many times:

1. Forward pass - compute predictions
2. Compute loss
3. Backward pass - compute gradients
4. Update weights

Over many iterations: Loss goes down, predictions improve!

Explain it to a friend

Pair up: Pretend your partner knows nothing about deep learning.

Explain how a neural network learns in plain language. What's actually happening?

Part 3: Training in Practice

Hyperparameters matter

Learning rate: How big are the steps?

• Too large: overshoot the minimum, diverge
• Too small: takes forever, gets stuck

Batch size: How many examples before updating?

• Larger: more stable, slower
• Smaller: noisier, faster, better generalization

Network architecture: How many layers? How many nodes?

Activation functions, initialization, optimization algorithm...

It's an art and a science

Beyond vanilla gradient descent

Vanilla gradient descent: w_new = w_old - learning_rate × gradient

Problem: Uses fixed learning rate, treats all parameters the same

Adam optimizer (Adaptive Moment Estimation):

• Keeps moving averages of gradients and squared gradients
• Adjusts learning rate for each parameter individually
• Fast convergence, works well in practice

Why it matters: Adam is the default optimizer for most modern deep learning (including training LLMs!)

Common challenges

Vanishing gradients: Gradients get tiny in deep networks

Exploding gradients: Gradients get huge, weights blow up

Overfitting: Memorizes training data, fails on new data

Local minima: Gets stuck in suboptimal solutions

Solutions: Better architectures (ReLU, skip connections), regularization, careful initialization

Topics to explore on your own

These are important but we won't cover in depth:

Activity: TensorFlow Playground

Open: playground.tensorflow.org

Try to classify the spiral dataset with:

• Just 1 hidden layer. Can you do it?
• Using linear activation instead of ReLU - what changes?
• What happens if you sent a very large or very small learning rate?

Let's add some competition: Find the SMALLEST network (fewest total neurons) that achieves loss < 0.1 on spiral.

Part 4: Looking Ahead - Sequences and Scale

What we've covered so far

Week 2: Classical NLP (bag-of-words, n-grams) and AI-assisted development

Today: How neural networks learn (backprop, gradient descent)

Wednesday: Tokenization - how text becomes input for these networks

Next challenge: How do we apply neural networks to sequences?

The problem with feed-forward networks

Feed-forward networks expect:

• Fixed-size input
• Fixed-size output
• No memory of previous inputs

But text is:

• Variable length
• Sequential (order matters!)
• Context-dependent

Examples of sequence tasks

Machine translation: Variable length in, variable length out

"Hello" -> "Bonjour"

"How are you?" -> "Comment allez-vous?"

Sentiment analysis: Variable length in, single output

"This movie was amazing!" -> Positive

Text generation: Sequence in, next word out

"The cat sat on the" -> "mat"

Feed-forward networks can't handle these naturally

Why variable length is hard

Traditional approach:

• Pad all sequences to max length (wasteful)
• Or truncate long sequences (lose information)

Either way, we lose the "sequential" aspect

We need architectures designed for sequences

Long-range dependencies

Remember this? "The trophy would not fit in the suitcase because it was too large"

What is "it"? The trophy or the suitcase?

Answer: The trophy (because it was too large)

Challenge: "it" is far from "trophy" in the sequence

Feed-forward networks treat each position independently

What we need for sequences

Memory: Remember what came before

Flexible length: Handle any input/output size

Order awareness: Position matters!

Context: Use earlier words to understand later ones

The evolution of solutions

1990s-2000s: Statistical machine translation (word alignment tables, phrase tables)

2014-2017: RNNs and LSTMs (memory in hidden states) - Monday

2017-present: Transformers with attention - Wednesday

Each approach solved some problems but had new limitations

The scale of modern deep learning

Training neural networks is mostly matrix multiplication

Why GPUs? Matrix multiplication is perfectly parallelizable

The result: Training that would take months on CPUs takes days on GPUs

The cost of scale

*Caution: These figures aren't directly comparable. Eg. DeepSeek's $5.6M is compute-only; Grok's $2-3B includes buying 100K GPUs.

Putting it in context:

Training is just the beginning. Using the model (inference) now accounts for more than half of total lifecycle emissions.

Discussion: Who bears the cost?

Turn to your neighbor:

1. Training large models requires massive compute resources. Who has access to this? Who doesn't?

2. The environmental cost is real. Should there be regulations on AI training? Who should decide?

3. Is it ethical to train ever-larger models? What are the trade-offs?

What we've learned today

Neural networks: Layers of weighted sums + activation functions

Learning: Gradient descent to minimize loss, backprop to compute gradients

Training: Hyperparameters matter, GPUs enable scale

Looking ahead: Sequences are hard (variable length, memory, context)

The bigger picture: Scale has costs - computational, financial, environmental

Reminders

Lab/Reflection due Friday (Feb 6): Tokenization and Neural Network Basics

You'll get to explore tokenization and building simple neural networks. Today's lecture gives you the foundation for the neural network part.

See the Week 3 guide for suggested explorations and resources

Wednesday (Feb 4): Tokenization - how text becomes numbers for neural networks

Lecture 4 - Tokenization: From Text to Tokens

Welcome back!

Last time: Neural networks and deep learning - how models learn from data

Today: Tokenization, how text becomes numbers

Why it matters: How we split text affects everything: model behavior, cost, fairness across languages.

Ice breaker

Actually this time:

What can you do better than an LLM?

Agenda for today

1. Bridging from last time: why tokenization matters
2. Historical approaches: stemming and lemmatization
3. Modern subword tokenization: BPE and WordPiece
4. Hands-on: How ChatGPT sees text
5. Tokenization and fairness
6. Preview: Word embeddings (next week)

Part 1: Why Tokenization Matters

Remember the NLP pipeline

From Lecture 2:

1. Tokenization - Split text into pieces

2. Representation - Convert to numbers

3. Learning - Train a model

Today: Deep dive into step 1, because it affects everything else!

Why tokenization is foundational

Your tokenization choice determines:

What the model can "see"

Your vocabulary size (memory and speed)

How you handle new/rare words

Whether your model works across languages

The vocabulary explosion problem

English has:

• ~170,000 words in current use
• Countless proper nouns (names, places, brands)
• New words constantly ("COVID-19", "ChatGPT", "6-7")
• Typos and variations ("looooove", "alot", "independant")

If every unique word gets its own token:

• Massive vocabulary
• Rare words poorly represented
• Can't handle new words
• ~100,000+ possible output "labels"

Think-pair-share: Related words

Turn to your neighbor:

These words are clearly related, but to a computer they're completely different:

run, runs, running, ran, runner
happy, happier, happiest, happily, happiness
go, going, went, gone

How might we help a computer see the connection?

Part 2: Historical Approaches

Stemming: The crude solution

Idea: Chop off word endings to find the "stem"

Examples:

running  -> run
runs     -> run
runner   -> run
easily   -> easili
happiness -> happi
studies  -> studi

Problem 1: Creates nonsense stems ("easili" and "happi" aren't words)

Problem 2: Different words collide to the same stem:

• "universal", "university", "universe" -> all become "univers"
• "policy", "police" -> both become "polic"
• "arm", "army" -> both become "arm"

Lemmatization: The smarter solution

Idea: Use linguistic knowledge to find the dictionary form (lemma)

Examples:

running  -> run
ran      -> run
better   -> good
is       -> be
mice     -> mouse

Better! Uses dictionaries and morphological rules to find true word forms.

But: Slow, language-specific, still treats lemmas as atomic.

Why stemming and lemmatization aren't enough

Still one token per word (vocabulary explosion continues)

Language-specific (need new rules/dictionaries for each language)

Can't handle new words (not in the dictionary)

Loses information ("running" vs "ran" have different tenses!)

Part 3: Modern Subword Tokenization

Let's guess and check

Quick pair-share:

How would you split this sentence into pieces for a computer to process?

How many "words"/tokens do you think ChatGPT sees?

"I can't believe ChatGPT doesn't understand state-of-the-art LLM-training techniques like gobbledigook! 🤯"

The trick - Don't tokenize at word boundaries

Instead: Learn a vocabulary of subword units that can be combined

"unhappiness" -> ["un", "happiness"]
"ChatGPT"     -> ["Chat", "GPT"]
"supercal..." -> ["super", "cal", "if", "rag", "il", "ist", "ic"]

Benefits:

• Fixed vocabulary size (50k subwords vs 170k+ words)
• New words break into known pieces
• Shared meaning ("un" = negation across many words)

Byte-Pair Encoding (BPE)

The dominant approach for modern LLMs

High-level idea:

1. Start with character-level vocabulary
2. Find the most frequent pair of adjacent tokens
3. Merge them into a new token
4. Repeat until vocabulary reaches target size

Result: Common words become single tokens, rare words split into pieces

BPE example (board work)

Let's build a toy BPE vocabulary together on the board

Training text: "I like to run in my running shoes when I'm running late"

We'll merge the most frequent pairs step by step and watch how "run" emerges as a token!

BPE: Training vs. Encoding

Training (learning the vocabulary):

• Scan corpus, count all adjacent token pairs
• Greedily merge the most frequent pair to get a new token
• Repeat until vocabulary reaches target size (e.g., 50k tokens)
• Save the ordered list of merge rules

Encoding (tokenizing new text):

• Apply the learned merge rules in priority order (order they were learned)
• Don't re-count frequencies, just apply the rules deterministically
• Same text always produces same tokens

Training: greedy, data-driven. Encoding: deterministic, fast.

BPE: Preventing cross-word merges

Problem: Without boundaries, BPE might merge characters across word boundaries.

"faster lower" split naively: f a s t e r l o w e r

The pair r + could merge across the two words!

Solution 1: End-of-word marker (original BPE, Sennrich et al. 2016)

Each word gets a </w> suffix before merging:

"faster" -> f a s t e r </w>
"lower"  -> l o w e r </w>

Merges like er</w> stay within each word. The boundary is never crossed.

Solution 2: Space prefix (GPT-2 and all GPT descendants)

Mark word starts with the preceding space:

"faster lower" -> ["faster", "Ġlower"]    (Ġ = space)

This is why "hello" and " hello" tokenize differently in the demo - the space is part of the next token, not the previous one.

BPE in practice

For real LLMs:

• Train on billions of words
• Create vocabulary of ~30k-50k subword tokens
• Common words: one token ("the", "and", "ChatGPT")
• Rare words: multiple tokens ("supercalifragilisticexpialidocious")

Tokenizer Variants (just FYI!)

WordPiece: Like BPE, but instead of raw frequency, scores merges by: $$\frac{P(\text{merged})}{P(\text{first})\times P(\text{second})}$$ Prefers merges where the combined token is more likely than you'd expect from the parts.

Unigram: Opposite direction from BPE:

1. Start with a large vocabulary (all common substrings)
2. Compute how much each token contributes to likelihood
3. Remove the least useful tokens until target vocabulary size

Why subword tokenization works

• Balances vocab size and granularity
• Shares info across related words
• Handles new/rare words gracefully
• Data-driven - no linguistic rules needed
• Works across languages

This is why all modern LLMs use subword tokenization!

Special Tokens

Beyond regular text, LLMs use special tokens for control and structure:

End of text: <|endoftext|>- tells the model a document is complete

• Important to think about when using structured output (eg generating JSON / other formats)

Beginning of text: <|startoftext|> - marks the start

Padding: <pad> - fills in when batching sequences of different lengths

Unknown: <unk> - rare fallback for truly unknown input (less common with BPE)

Chat-specific: <|user|>, <|assistant|>, <|system|> - structure conversations

Example chat template (simplified):

<|system|>You are a helpful assistant.<|endoftext|>
<|user|>What's the capital of France?<|endoftext|>
<|assistant|>Paris is the capital of France.<|endoftext|>

This is why "system prompts" work. They go in a special place the model treats as instructions.

Understanding special tokens helps you understand prompt injection - malicious input can insert fake tokens like <|system|> to override instructions. More on this in later.

Part 4: Tokenization in Practice

Live demo: OpenAI tokenizer

Let's see how GPT actually tokenizes text

Go to: platform.openai.com/tokenizer

Try these examples and discuss:

1. "running" vs "run"
2. "ChatGPT"
3. "supercalifragilisticexpialidocious"
4. " hello" vs "hello"
5. Code: "def main():"
6. Math: "2+2=4"
7. "🙂😀"
8. "strawberry"

Why LLMs struggle with certain tasks

Question: Why do LLMs struggle to count letters in words or reverse words?

Turn to your neighbor and discuss

Why LLMs struggle with certain tasks

Answer: They don't see individual letters - common words are single tokens!

Example: "strawberry" = ["str", "awberry"]

The model can't count the "r"s - it doesn't see individual letters!

This is why prompting tricks sometimes work:

• "Spell it out letter by letter first"
• "Break the word into characters"

These force the model to generate character-level tokens

Fun fact: OpenAI's o1 was code-named "Strawberry"

Tokenization archaeology: "SolidGoldMagikarp"

Story: In 2023, researchers discovered "glitch tokens" - tokens that made ChatGPT behave bizarrely.

One example: the token "SolidGoldMagikarp" (a Reddit username). When asked to repeat it, ChatGPT would:

• Claim it couldn't see the word
• Refuse to say it
• Output completely unrelated text
• Behave erratically

What happened? The tokenizer saw this Reddit username enough to make it a token. But the model rarely saw it during training - mismatch between tokenizer and model.

Quick skim now, but great reading for later!

• https://www.alignmentforum.org/posts/aPeJE8bSo6rAFoLqg/solidgoldmagikarp-plus-prompt-generation

Tokenizers are frozen

Once a model is trained, its tokenizer is fixed. You can't easily change it.

• In 2020, models tokenized COVID-19 as ~["CO", "VID", "-", "19"].
• Newer models trained after 2020 may have "COVID" as a single token.

Why newer models handle recent terms better: not just more data, updated tokenizers too.

Other tokenization effects

Arithmetic: Numbers tokenize inconsistently - sometimes digit-by-digit, sometimes as chunks

Code: Variable names split unpredictably

Rhymes: "cat" and "bat" might not share an "at" token

Tokenization shapes what LLMs find easy vs hard

Tokenizing Code vs Natural Language

Code and prose tokenize very differently:

Natural language: Words mostly stay intact

• "The quick brown fox" = 5 tokens

Code: Variable names split unpredictably

• print = 1 token (very common)
• getUserDataFromDB = 6 tokens ["get", "User", "Data", "From", "DB"]
• mySpecialFunction = 4 tokens ["my", "Special", "Function"]

Why this matters:

• Longer sequences are harder for the model to understand
• Uses up context faster

Rule of thumb: Assume ~ 10 tokens per line of code when you're asking AI to parse code files

Token Vocabularies Across Models

Different models make different tokenization choices:

A prompt optimized for one model may be inefficient for another.

Why this matters for prompt engineering:

• Context window limits (e.g., 128k tokens) are in TOKENS, not words
• Few-shot examples eat into your token budget
• Verbose prompts = fewer tokens for the actual task
• Non-English prompts use more of your context window

Mental model: How big is a token?

Rules of thumb for English:

• ~4 characters per token (on average)
• ~0.75 words per token (or ~1.3 tokens per word)
• A typical page of text ≈ 500-700 tokens
• A typical email ≈ 200-400 tokens
• 128K token context ≈ a 250-page book

The cost of tokens

Typical API pricing (as of early 2026):

Quick cost estimates (Claude Sonnet at ~$15/1M input):

• 1 email (~300 tokens): ~$0.005
• A novel (~100K tokens): ~$1.50

Tokens are cheap individually. Volume is where costs add up.

How it adds up

• Every time you send a message the LLM REREADS YOUR WHOLE CONVERSATION HISTORY as context
• If you're doing development work with lots of code, each message could easily be 10k+ tokens (~$0.20)
• If you set up a chatbot for many users / use LLMs to send spam emails...

Minification: Squeezing more into your context

You can strip characters to reduce token count before sending to an LLM.

Strategies:

Pros:

• Fit more in context window
• Reduce API costs

Cons:

• Harder for the model to "read" - formatting aids comprehension
• Harder for humans to read without whitespace?
• Diminishing returns (saving 10% rarely matters)
• Risk of removing important context

Rule of thumb: Minify data/logs aggressively. Keep code and instructions readable.

Activity: Tokenization Scavenger Hunt

Select a tokenizer (or compare them):

• platform.openai.com/tokenizer
• https://claude-tokenizer.vercel.app/

Find examples of each:

1. A real English word that splits into 4+ tokens
2. What's the longest English word you can find that is just one token?
3. Find a 4-digit number that's ONE token, and another 4-digit number that's TWO tokens. What's the pattern?
4. Find a word where changing the capitalization changes the number of tokens
5. Find a string where GPT's and Claude's tokenizers produce different numbers of tokens.
6. COVID-19 was 4 tokens in GPT-3 but is now 3 tokens. Can you find other examples of token count changing over time?
7. Translate "Hello, how are you today?" into at least 3 languages. Which language uses the MOST tokens?
8. Find a non-English word that's a single token.
9. If your name isn't common in English, how many tokens is it? Compare to a common English name.

Part 5: Tokenization and Fairness

Not all languages are created equal

BPE vocabularies are learned from training data.

If training data is mostly English:

• English words - efficient (one token per word)
• Other languages - split aggressively

This has real consequences

Token efficiency across languages

Same meaning, different token counts:

"Hello, how are you?" (English): 6 tokens

"你好，你好吗？" (Chinese): 11 tokens

Nǐ hǎo ma (Chinese, pinyin): 7 tokens

"مرحبا، كيف حالك؟" (Arabic): 14 tokens

Same semantic content, different token counts!

Why this matters

Cost: Many APIs charge per token

Context limits: Same token limit = fewer words in Chinese than English

Performance: More tokens = longer sequences = harder to learn

Fairness: English speakers get a better deal

Discussion: Is this a problem?

Turn to your neighbor:

1. Is token inefficiency for non-English languages a fairness issue?
2. Whose responsibility is it to address this?
3. What could be done about it?

Train on more balanced multilingual data

Language-specific tokenizers (but lose cross-lingual transfer)

Character-level models (no bias, but less efficient)

Larger vocabularies - more slots for non-Latin characters (GPT-4o went from 100k to 200k vocabulary, improving Chinese efficiency ~3x)

Adjust pricing by language (some APIs do this)

Part 6: Looking Ahead

What we've learned today

Tokenization is foundational - it determines what models can "see"

Historical approaches: stemming and lemmatization (word-level, limited)

Modern approach: subword tokenization (BPE, WordPiece)

Tokenization affects LLM behavior (letter counting, arithmetic, etc.)

Tokenization has fairness implications (language efficiency, cost)

Connecting the dots

Lecture 2: AI development + Classical NLP

Lecture 3 (Monday): Deep learning foundations

Lecture 4 (today): Tokenization

Lab/Reflection Due Friday (Feb 6)

• Explore tokenization and/or neural network basics.

Monday: Sequence-to-sequence models and word embeddings

Monday: Attention!

Lecture 5 - Sequence Models & Word Embeddings

Welcome back!

Last time: Tokenization - how text becomes pieces a model can process

Today: How those pieces get meaning - word embeddings and sequence models

Why this matters: These are the building blocks of every LLM

Ice breaker: Personal Corpus

(See Poll Everywhere)

Connecting the pieces

Lecture 2: Classical NLP (BoW, TF-IDF, n-grams) - count words

Lecture 3: Neural networks - the learning machinery

Lecture 4: Tokenization - break text into pieces

Today: Learn representations that capture meaning

Spoiler: LLMs are basically this idea at massive scale.

Agenda for today

1. From counting to meaning: the distributional hypothesis
2. Encoder-decoder framework for sequence tasks
3. Word embeddings: Word2Vec and how neural networks learn meaning
4. Properties of Embeddings
5. Ethics: Bias in embeddings
6. Quick intro to RNNs (and why transformers replaced them)

Part 1: The Distributional Hypothesis

The problem with counting

Remember n-grams from Lecture 2?

Training text: "I love NLP. I love machine learning."

Bigram model learns: I -> love, love -> (NLP or machine)

But what if we see: "I adore NLP"?

The model has no idea that "adore" and "love" are similar!

We need a representation that captures semantic similarity

The insight: distributional hypothesis

"You shall know a word by the company it keeps"

• J.R. Firth, 1957

Intuition: Words that appear in similar contexts have similar meanings

This is the foundation of how LLMs work.

For more theories, go down a rabbit hole on "semiotics"

Think about these sentences

"The cat sat on the mat"

"The dog sat on the mat"

"The automobile sat on the mat" (weird!)

Question: What other contexts do "cat" and "dog" share?

From contexts to vectors

Idea: Represent each word as a vector based on the contexts where it appears

Words in similar contexts lead to similar vectors

Example (simplified):

• "cat" -> [0.8 near "sat", 0.9 near "mat", 0.7 near "pet", ...]
• "dog" -> [0.9 near "sat", 0.8 near "mat", 0.9 near "pet", ...]
• "automobile" -> [0.1 near "sat", 0.0 near "mat", 0.0 near "pet", ...]

cat and dog vectors are close together in high-dimensional space!

Similarity voting - poll everywhere

Which word is MOST similar to "cat"?

A) dog B) car C) meow D) kitten

Round 2: Which is most similar to "Taylor Swift"?

A) Beyoncé B) Taylor Smith C) Travis Kelce D) 1989

Round 3: Which is most similar to "bank"?

A) river B) money C) rob D) save

What would a computer answer?

Part 2: Encoder-Decoder Framework

From single words to sequences

Word embeddings solve: Representing individual words as vectors

But many NLP tasks need: Processing and generating sequences

Machine translation: "I love NLP" -> "J'adore le NLP"

Summarization: Long article -> short summary

Question answering: Question + context -> answer

We need architectures for sequence-to-sequence tasks

The encoder-decoder architecture

High-level idea:

Encoder: Read the input sequence, build a representation

Decoder: Generate the output sequence using that representation

Example (translation):

• Encoder reads English: "I love NLP"
• Encoder outputs: [0.134, 0.841, ... , 0.529]
• Decoder uses that vector to generate French: "J'adore le NLP"

This framework is still how modern LLMs work:

• GPT, Claude, LLaMA: Decoder-only (generate text from a prompt)
• BERT: Encoder-only (understand text, don't generate)
• T5, translation models: Full encoder-decoder

Real-world impact: Google Translate (2016)

In 2016, Google switched from phrase-based translation to a neural encoder-decoder model.

Translation quality improved more in that single jump than in the previous 10 years combined.

Google released a great paper, "Google's Neural Machine Translation System: Bridging the Gap between Human and Machine Translation" if you want to learn more!

Encoder-decoder diagram

The context vector is the bottleneck!

This pattern is everywhere

Encoder-decoder isn't just for language, it's any time you compress information through a bottleneck and reconstruct on the other side.

The key trade-off is always the same: How small can you make the middle representation while still reconstructing something useful?

• Stable Diffusion (that's the "latent" in Latent Diffusion)
• Meta's EnCodec, Google's SoundStream

The bottleneck problem

Challenge: Compress an entire sentence into a single fixed-size vector

Short sentences: "Hi" -> 1 vector (okay)

Long sentences: "The quick brown fox jumps over the lazy dog" -> 1 vector (hard)

Very long: "In the beginning was the Word, and the Word was with God..." -> 1 vector (impossible)

The fixed-size vector becomes a bottleneck for long sequences

But what if we just... didn't compress?

Thought experiment: What if the decoder could look at ALL the word vectors' states, not just a single combined one?

Instead of: Input -> Encoder -> one vector -> Decoder -> Output

What about: Input -> Encoder -> all words available -> Decoder picks what it needs -> Output

This is exactly what attention does. Wednesday's topic!

Part 3: Word2Vec - Learning Embeddings with Neural Networks

From framework to technique

We have a framework: encoder builds a representation, decoder uses it. But how do we actually learn those word representations?

Word2Vec (Mikolov et al., 2013): Train a neural network on a dead-simple task: given a word, predict its neighbors. The representations it learns along the way turn out to capture meaning.

Skip-gram: The training task

• Training sentence: "The cat sat on the mat"
• Center word: "sat"
• Context window (size 2): the 2 words on each side
• Training pairs generated: (sat, cat), (sat, on), (sat, the), (sat, the)

     The    cat   [sat]   on    the    mat
      ↑      ↑   center   ↑     ↑
   context context      context context

Each pair is a separate training example. Slide the window across billions of sentences and you get billions of training pairs.

Window size is a hyperparameter, typically 5-10.

• Larger windows capture semantic/topical similarity ("dog" and "cat" both appear near "pet")
• Smaller windows capture syntactic similarity ("dog" and "cat" both follow "the")

Skip-gram: The training data

What does the training set actually look like? Each center word paired with each context word is one training example: input x, target y.

"The cat sat on the mat", window = 2:

18 training pairs from a single 6-word sentence. The network sees each row independently: "given this input word (as a one-hot vector), try to predict this target word." Scale to billions of sentences and you get billions of training pairs.

Skip-gram: The architecture

This is a mini encoder-decoder:

Encoder (embedding layer): One-hot vector for "sat" (size 50,000) × weight matrix W_embed (50,000 × 300) = word vector (size 300)

This is just a lookup - multiplying a one-hot vector by a matrix pulls out one row.

Decoder (context layer): Word vector (size 300) × weight matrix W_context (300 × 50,000), then softmax to get probability for each word in the vocabulary

Training: For each pair (sat, cat), did the model assign high probability to "cat"? If not, backpropagation adjusts both weight matrices.

After training, we throw away the decoder (W_context). The encoder weights (W_embed) are the word embeddings. Each row is a word's vector.

From token to embedding

Putting it together - how does raw text become vectors?

"The cat sat" passes through tokenizer to get token IDs [0, 1, 2], then embedding lookup gives us three 300-dim vectors

For "cat" (token ID 1), the lookup selects row 1 from the embedding matrix:

   W_embed:         dim1   dim2   dim3   ...  (300 cols)
   ID 0  "the":  [  0.12, -0.34,  0.56,  ... ]
   ID 1  "cat":  [  0.78,  0.23, -0.11,  ... ]  ← this row
   ID 2  "sat":  [  0.45,  0.67,  0.89,  ... ]
   ...              (one row per token in vocabulary)

The tokenizer decides WHAT gets embedded. The embedding matrix learns HOW to represent it.

Thought experiment: Training data matters

Turn to your neighbor: Pick one of these domains. What does "cell" mean there?

• Medical journals: "cell membrane", "cell division", "stem cell"
• Legal documents: "prison cell", "jail cell", "cell block"
• Tech blogs: "cell phone", "cellular network", "spreadsheet cell"
• Biology textbooks: "cell wall", "cell nucleus"

Same word, completely different vectors. The distributional hypothesis means your embeddings are only as good as the text they learned from.

Part 4: Properties of Embeddings

The embedding space

After training, each word is a 300-dimensional vector (typically)

Why 300? More dimensions = more nuance. 50 dimensions might capture "cat is an animal." 300 dimensions can also capture "cat is small, is a pet, is independent, is internet-famous, purrs, has whiskers..."

Example (simplified to 2D for visualization):

"king"   -> [0.5, 0.8]
"queen"  -> [0.6, 0.7]
"man"    -> [0.3, 0.9]
"woman"  -> [0.4, 0.8]
"banana" -> [0.9, 0.1]

Similar words are close together in this space

Vector arithmetic: The famous example

king - man + woman ≈ queen

Paris - France + Italy ≈ Rome

better - good + bad ≈ worse

The embeddings capture relationships, not just similarity!

The limitation: One vector per word

Think about this sentence:

"I deposited money at the bank before walking along the river bank."

Word2Vec gives "bank" ONE vector. Same representation for both meanings.

Question: How would you want a smarter system to handle this?

FYI - there are other word embeddings

GloVe (2014) and FastText (2016) used the same distributional hypothesis but with different technical tricks.

FastText is notable for handling out-of-vocabulary words by using character n-grams.

Word2Vec is the most conceptually clear, which is why we focused on it.

Loading word embeddings in python

Let's actually work with pre-trained word vectors!

# Using gensim library
from gensim.models import KeyedVectors

# Load pre-trained vectors
model = KeyedVectors.load_word2vec_format('GoogleNews-vectors.bin', binary=True)

# Find similar words
model.most_similar("king")
# Output: [('queen', 0.65), ('monarch', 0.58), ('prince', 0.55), ...]

# Compute similarity
model.similarity("cat", "dog")    # High! ~0.76
model.similarity("cat", "car")    # Low  ~0.31

# Analogies
model.most_similar(positive=["woman", "king"], negative=["man"])
# Output: [('queen', 0.71), ...]

Challenge: Best and worst analogies

Each pair has a mission:

1. Find the most surprising analogy that works
2. Find one you expected to work but doesn't

Format: [word1] - [word2] + [word3] ≈ ?

Starting ideas:

• swimming - swim + run ≈ ?
• France - Paris + London ≈ ?
• good - bad + ugly ≈ ?

Also try: projector.tensorflow.org

We'll vote on the best find!

Do modern LLMs use Word2Vec?

No, but they use the same concept.

• GPT, Claude, LLaMA all have an embedding layer as their first layer
• Each token in the vocabulary gets a learned vector (typically 4096+ dimensions now)
• These embeddings are learned during training, not separately

How big is this? GPT-2's embedding table alone:

• 50,257 tokens
• 768 dimensions
• 38.6 million parameters and that's just the first layer of a "small" model

The key difference:

• Word2Vec embeddings are static: "bank" has one vector whether it's a river bank or a money bank
• Modern LLMs start with the same kind of static lookup table, but then transformer layers use attention to build context-dependent representations on top
• By layer 40, "bank" looks completely different depending on whether "river" or "money" is nearby

Where are embeddings used today? (skim)

"If LLMs learn their own embeddings, is Word2Vec obsolete?"

Not quite! Embeddings are still everywhere:

E.g. Spotify: Your listening history becomes a point in "music space," and recommendations are nearby points.

When to use pre-trained embeddings vs. LLMs:

• Embeddings: Fast, cheap, good for similarity/search
• LLMs: Slower, expensive, good for generation/reasoning

Part 5: Ethics and Bias in Embeddings

The problem: Embeddings learn human biases

Remember: Embeddings learn from text data

That text reflects human biases

So embeddings encode those biases into the vectors**

We just learned vector arithmetic. Let's try one more:

man - woman + doctor ≈ ???

man - woman + doctor ≈ ?

Result: "nurse"

man - woman + programmer ≈ ?

Result: "homemaker"

These reflect gender stereotypes in the training data

If you're interested, check out the famous paper "Man is to Computer Programmer as Woman is to Homemaker? Debiasing Word Embeddings"

Let's try a few! (And test your embeddings from earlier)

jupyter notebook scripts/embedding_demo.ipynb

Real-world impact: Amazon's recruiting tool

2014-2017: Amazon built AI to screen resumes

Trained on: Historical resumes (mostly from men, especially in tech roles)

Result: The model learned to penalize:

• The word "women's" so "women's chess club captain" was a red flag
• Graduates of all-women's colleges
• Any signal correlated with being female

Outcome: Amazon scrapped the tool in 2017

This isn't a "bug in the algorithm" it's the algorithm doing exactly what we taught it. The bias is in the data.

Discussion: Where do these biases come from?

Turn to your neighbor:

1. Why do word embeddings encode bias?
2. Where in the pipeline does bias enter?
3. What can we do about it?

The bias pipeline

1. Training data reflects historical bias

2. Algorithm accurately learns patterns (including biased ones)

3. Embeddings encode those biases as geometric relationships

4. Downstream applications (hiring, lending, recommendations) amplify bias

The algorithm is doing its job - that's the problem!

Can we "debias" embeddings?

Bolukbasi et al.'s approach:

1. Identify a "gender direction" in embedding space
2. For neutral words (like professions), remove the gender component
3. Preserve gender for definitional words (king/queen, father/mother)

Does this work?

Partially - reduces some measurable biases

But doesn't eliminate them, and may introduce new problems

Hard to define "fair" - what should the "right" associations be?

Have you seen this? Have there been times ChatGPT/Claude/etc. gave you a response that felt stereotypical or made assumptions?

The deeper questions

Open discussion:

Should we try to debias embeddings? Why or why not?

If embeddings accurately reflect reality, is that itself a problem?

Who gets to decide what's "biased" vs "accurate"?

Whose responsibility is this: researchers? companies? users?

There are no easy answers - that's what makes this important

What companies do now

2016 framing: "Debias word embeddings"

2026 framing: "Align LLMs with human values"

None of these fully solve the problem. Active research area.

Part 6: RNNs - Context You Should Know

The implementation question

We've seen the encoder-decoder framework. We've seen how to learn word vectors.

But here's the problem: neural networks expect fixed-size inputs. Sentences have variable length.

How would YOU feed a sentence into a neural network?

Take 15 seconds to think about it.

How to build the encoder and decoder?

Option 1: Just use feed-forward networks

• Problem: Can't handle variable length sequences!

Option 2: Recurrent Neural Networks (RNNs)

• Process sequences one step at a time
• Maintain "hidden state" that carries information
• This was the dominant approach 2014-2017

Option 3: Transformers with attention

• This is what won (2017+)
• We'll finally dig into this starting Wednesday

RNNs in 60 seconds

Before transformers (2014-2017), RNNs were how we processed sequences.

The idea: Process tokens one at a time, maintaining a "hidden state" that carries information forward.

"I"         -> h1
"love" & h1 -> h2
"NLP" & h2  -> h3

You don't need to know the math. Just know they existed and why they lost.

If you're curious - check out Andrej Karpathy's excellent (viral) blog post "The Unreasonable Effectiveness of RNNs"

Why transformers replaced RNNs

Can't parallelize

• Each token waits for the previous. Can't parallelize across a sentence.
• A 10T parameter model like GPT-5 would take hundreds of years to train.

Vanishing gradients

• Information from early tokens fades.
• Hard to connect "The cat that..." to "...was hungry" 50 words later.

Context bottleneck

• Entire input compressed to one context vector
• Same problem we discussed - can't fit a novel into 512 numbers

LSTMs/GRUs helped with gradients but didn't fix parallelization or bottleneck.

The solution: Attention (Wednesday!)

Attention lets the model:

• Process all tokens in parallel (fast!)
• Look directly at any input token when generating output (no bottleneck!)
• Learn which tokens are relevant to which (better long-range connections!)

This is why we have modern LLMs. Without attention, GPT-5 couldn't exist.

What we've learned today

Distributional hypothesis: words in similar contexts have similar meanings

Encoder-decoder framework for sequence-to-sequence tasks

Word2Vec: train neural networks to predict context, learn embeddings

Embeddings encode societal biases from training data

RNNs briefly (transformers replaced them!)

Connecting the dots

Lecture 2: Classical NLP (counting, BoW, n-grams)

Lecture 3: Neural networks (the learning machinery)

Lecture 4: Tokenization (how we break text into pieces)

Lecture 5 (today): Embeddings + encoder-decoder (putting it together for sequences)

Wednesday: Attention, the key ingredient in transformers

Lab/reflection for week 4 due Friday

• Explore sequence-to-sequence concepts and word embeddings
• Use pre-trained embeddings (gensim) for exploration
• Experiment with encoder-decoder concepts
• Try to build a network with an attention mechanism by hand (play around!)

Lecture 6 - Attention Mechanisms

Welcome back!

Last time: Encoder-decoder models and word embeddings - how we represent meaning and handle sequences

Today: The mechanism that revolutionized NLP - attention

Why this matters: Attention solves the bottleneck problem and enables transformers

Ice breaker

What do you see in this picture? Can you tell what's going on?

• Visual saccades
• The classic test

Agenda for today

1. Quick recap: the bottleneck problem
2. Attention intuition: Query, Key, Value
3. The math: scaled dot-product attention
4. Board work: computing attention step by step
5. Self-attention: a sequence attending to itself
6. Multi-head attention: multiple perspectives
7. Masked attention: padding and causal masks

Part 1: Recap - The Bottleneck Problem

Remember encoder-decoder models?

From Lecture 5:

Input sequence -> Encoder -> Fixed-size context vector -> Decoder -> Output sequence

Example task: Translate English to French

"The snow closed the campus" -> [encoder] -> c -> [decoder] -> "La neige a fermé le campus"

The bottleneck problem

Challenge: Compress entire input sequence into one fixed-size vector

Long inputs lose information:

Short sentence (5 words) -> c (256 dims) -> works ok

Long paragraph (100 words) -> c (256 dims) -> loses details!

It's like summarizing a novel in one sentence - you lose crucial details

Try it: 5-word summary

Pick your favorite book or movie. Summarize the entire story in exactly 5 words.

Share with your neighbor, can they guess what it is?

Hard, right? That's the bottleneck problem. Now imagine compressing a 100-word paragraph into a 256-dimensional vector.

What if we could look back?

Intuition: When generating each output word, look at all the input words and focus on the most relevant ones

Example: Translating "I got cash from the bank on the way home"

When generating "banque" (bank), the model attends to both "bank" and "cash" - it needs the context to know this is a financial bank, not a riverbank

This is attention!

Attention: high-level idea

Instead of a single context vector, the decoder gets a dynamic context for each output

Each decoder step:

1. Look at all encoder hidden states (roughly, token embeddings)
2. Decide which ones are most relevant
3. Create a weighted combination
4. Use that as context for this step

Result: The model can focus on different parts of the input for different outputs

Part 2: Query, Key, Value - The Attention Intuition

Three roles in attention

Attention uses three different representations of the same data:

Query (Q): "What am I looking for?"

Key (K): "What do I contain?"

Value (V): "What do I actually output?"

Metaphor: Googling your symptoms

You wake up with a headache and blurry vision. Naturally, you do the responsible thing and consult Dr. Google.

Your search: "headache blurry vision" - This is Q

Page titles and descriptions: What each result claims to be about - These are Ks

The actual articles: The content you read when you click - These are Vs

Metaphor: Googling your symptoms

1. Type in your symptoms (Q)
2. Skim titles and descriptions for matches (compare Q to all Ks)
3. Click into the most relevant results and read them (retrieve their Vs)
4. Combine what you read into your (probably wrong) self-diagnosis

This is exactly how attention works!

Attention beyond translation

Translation is our running example, but attention is everywhere:

Document summarization: When generating each summary word, attend to the most relevant sentences in the source document

Image captioning: When generating "dog," attend to the dog region of the image; when generating "frisbee," shift attention to the frisbee

Question answering: Given a question about a passage, attend to the sentences most likely to contain the answer

The same Q, K, V mechanism works across all these tasks!

Q, K, V in the decoder attending to encoder

Example: Translating "The snow closed" -> "La neige a ___"

Decoder is generating the next French word

Query (Q): Current decoder state (Q = "what's the next word in my translation after 'La neige a'")

Keys (K): All encoder hidden states (titles/descriptions for "The", "snow", and "closed")

Values (V): The same encoder hidden states (full content of "The", "snow", and "closed")

Process:

1. Compare Q to all Ks -> get relevance scores
2. Use scores to weight the Vs
3. Output weighted combination of Vs

Why K and V are separate

Question: If K and V both come from encoder hidden states, why distinguish them?

Answer: We transform them differently!

In practice:

$K=W_K\times \text{(encoder hidden state)}$ = Optimized for matching

$V=W_V\times \text{(encoder hidden state)}$ = Optimized for content

W_K and W_V are learned projection matrices (sometimes called weight matrices)

Keys learn to be good for comparison (which inputs match this query?)

Values learn to be good for output (what information to pass forward?)

Part 3: The Math - Scaled Dot-Product Attention

The attention formula

Given: Queries (Q), Keys (K), Values (V)

Compute:

$$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{Q{K}^T}{\sqrt{d_k}}\right)V$$

Let's break this down step by step

Step 1: Compute similarity scores

$$Q{K}^T$$

What this does: Dot product between query and all keys

Intuition: "How well does my query match each key?"

Output: Similarity scores (higher = more relevant)

Dimensions:

$Q$: $(1\times d_k)$ - one query

$K$: $(n\times d_k)$ - n keys (one per input token)

$Q{K}^T$: $(1\times n)$ - one score per input token

Step 2: Scale by sqrt(d_k)

$$\frac{Q{K}^T}{\sqrt{d_k}}$$

Why scale? Dot products get large when dimensionality ($d_k$) is high

Problem with large scores: Softmax saturates (pushes probabilities toward 0 or 1)

Solution: Divide by $\sqrt{d_k}$ to keep scores in a reasonable range

Step 3: Softmax

$$\text{softmax}\left(\frac{Q{K}^T}{\sqrt{d_k}}\right)$$

What softmax does: Converts scores to probabilities (sum to 1)

Input: Raw similarity scores [3.2, 1.1, 5.8]

Output: Attention weights [0.15, 0.05, 0.80]

Interpretation: "Focus 80% on token 3, 15% on token 1, 5% on token 2"

Step 4: Weighted sum of values

$$\text{softmax}\left(\frac{Q{K}^T}{\sqrt{d_k}}\right)V$$

Finally: Multiply attention weights by values

This creates a weighted combination of the input values

Example:

Attention weights: [0.15, 0.05, 0.80]

Values: $v_1,v_2,v_3$

Output: $0.15 \times v_1 + 0.05 \times v_2 + 0.80 \times v_3$

The output focuses on the most relevant values!

Putting it all together

$$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{Q{K}^T}{\sqrt{d_k}}\right)V$$1.Computesimilarity:$Q \cdot K^T$2.Scale:divideby$\sqrt{d_k}$ 3. Normalize: softmax -> probabilities 4. Weighted sum: multiply by V

Result: Context vector that focuses on relevant input tokens

Computational cost: $O(n^2)$\ast \ast Importantcaveat:\ast \ast AttentioncompareseveryquerytoeverykeyForasequenceoflengthn:-$QK^T$producesan$(n \times n)$matrix-Tha{t}^{\prime }s$n^2$ similarity calculations!

Implications:

• Short sequences (100 tokens): 10,000 comparisons - fast
• Long sequences (10,000 tokens): 100,000,000 comparisons - slow!

This is why: Long documents are challenging, and researchers work on "efficient attention" variants

Quick check: vibe-coding and context limits

How's the vibe-coding going? Have you encountered:

• Your conversation gets long,
• the model starts "forgetting" earlier context
• and eventually you hit a structural limit on context length

We know forgetting happened with RNNs - why is it still happening with attention?

Quick check: Do you understand the formula?

Turn to your neighbor (2 min):

In your own words, explain what each step accomplishes:

1. QK^T - what does this compute?
2. Softmax - why do we need this?
3. Multiply by V - what's the result?

Part 4: "Board" (Screen) Work

Let's calculate attention by hand

Scenario: Translating "snow closed campus"

We have 3 input tokens (words), and we're generating an output

Simplified example with d_k = 4

(Real models use d_k = 64 or larger, but 4 is enough to see the pattern)

Step 1: Set up matrices

Query (what we're looking for):

Q = [1, 0, 1, 2]

Keys (what each input contains):

K = [[2, 1, 0, 1],   ← "snow"
     [0, 2, 1, 0],   ← "closed"
     [2, 0, 1, 2]]   ← "campus"

Values (what we output):

V = [[1, 0, 1, 2],   ← "snow"
     [0, 1, 2, 0],   ← "closed"
     [2, 1, 0, 1]]   ← "campus"

Step 2: Compute $QK^TQ \cdot K^T$meansdotproductofQwitheachrowofK$Q = [1, 0, 1, 2]Q \cdot [2, 1, 0, 1] = 1\times2 + 0\times1 + 1\times0 + 2\times1 =$\ast \ast 4\ast \ast \leftarrow similaritywith"snow"$Q \cdot [0, 2, 1, 0] = 1\times0 + 0\times2 + 1\times1 + 2\times0 =$\ast \ast 1\ast \ast \leftarrow similaritywith"closed"$Q \cdot [2, 0, 1, 2] = 1\times2 + 0\times0 + 1\times1 + 2\times2 =$ 7 ← similarity with "campus"

Scores: [4, 1, 7]

Observation: "campus" has highest similarity to our query!

Step 3: Scale by $\sqrt{d_k}d_k = 4$,so$\sqrt{d_k} =$ 2

Scaled scores: [4/2, 1/2, 7/2] = [2, 0.5, 3.5]

Step 4: Apply softmax

Scaled scores: [2, 0.5, 3.5]

Softmax: Convert to probabilities (approximate!)

$\text{softmax}([2, 0.5, 3.5]) \approx$ [0.18, 0.04, 0.78]

Check: 0.18 + 0.04 + 0.78 = 1.0

Interpretation:

• Focus 78% on "campus"
• Focus 18% on "snow"
• Focus 4% on "closed"

Step 5: Weighted sum of values

Attention weights: [0.18, 0.04, 0.78]

Values:

• $V_1$=[1,0,1,2]\leftarrow "snow"-$V_2$=[0,1,2,0]\leftarrow "closed"-$V_3$=[2,1,0,1]\leftarrow "campus"\ast \ast Output:\ast \ast$= 0.18 \times [1, 0, 1, 2] + 0.04 \times [0, 1, 2, 0] + 0.78 \times [2, 1, 0, 1]\approx [0.18, 0, 0.18, 0.36] + [0, 0.04, 0.08, 0] + [1.56, 0.78, 0, 0.78]\approx$ [1.74, 0.82, 0.26, 1.14]

This is our context vector - a weighted combination focused on "campus"

What did we just do?

Started with: Query asking "what am I looking for?"

Compared to: Keys for each input token

Found: "campus" was most relevant (similarity = 7, then scaled to 3.5)

Retrieved: Weighted combination of values, focused 78% on "campus"

Result: A context vector that emphasizes "campus", the most relevant input

This is attention!

Attention Variants

Part 5: Self-Attention

From cross-attention to self-attention

So far, we've seen the decoder attending to the encoder (cross-attention).

But what if Q, K, and V all come from the same sequence?

Self-attention: Each word in a sentence attends to all other words (including itself)

Why? To build better representations by capturing relationships within the sequence

Self-attention in action

Input sentence: "The animal didn't cross the street because it was too tired"

Question: What does "it" refer to?

Self-attention for the word "it":

• Query: "it" embedding
• Keys/Values: All word embeddings in the sentence

Results:

• High attention to "animal" (that's what "it" refers to!)
• Low attention to "street"

The Great Jay Alammar

The process

For each word in the sequence:

1. Create Q, K, V from that word's embedding (using learned projection matrices W_Q, W_K, W_V)

2. Compare Q to all K's (including itself) -> attention weights

3. Weighted sum of all V's -> contextualized representation

Do this for ALL words simultaneously! (this is why transformers are parallelizable, unlike RNNs)

Result: Every word gets a new representation that incorporates information from the whole sequence

The Great Jay Alammar II

Cross-attention vs self-attention

The math is identical. Only the source of Q, K, V changes.

Live demo: BertViz

Before we calculate by hand, let's see what attention actually looks like in a real model.

Demo: scripts/bertviz_demo.ipynb

Was this insightful at all? You might take sides between the papers:

• "Attention is not explanation" (Jain and Wallace, 2019)
• "Attention is not not explanation" (Wiegreffe and Pinter, 2019)

Part 6: Multi-Head Attention

One head isn't enough

In "The snow closed the campus":

• Syntactic: "snow" is the subject of "closed"
• Semantic: "snow" and "campus" (weather event affecting a place)
• Positional: "snow" is near "The"

Problem: A single attention mechanism tries to capture all these relationships at once

Solution: Run multiple attention "heads" in parallel - each one learns to focus on different things

Multi-head attention: The idea

Instead of one set of Q, K, V:

Run h different attention mechanisms in parallel (typically h = 8 or 16)

Each head:

• Has its own W_Q, W_K, W_V projection matrices
• Learns to focus on different aspects
• Produces its own output

Finally: Concatenate all head outputs and project

Multi-head attention formula

For each head i:

$${\text{head}}_i=\text{Attention}(X{W}_Q^i,X{W}_K^i,X{W}_V^i)$$orwecanwrite$${\text{head}}_i=\text{Attention}(Q^i,K^i,V^i)$$\ast \ast Concatenateallheads:\ast \ast$$\text{MultiHead}(Q,K,V)=\text{Concat}({\text{head}}_1,\dots ,{\text{head}}_h)W_O$W_O$:Outputprojectionmatrix(learned)\ast \ast Typicalsetup:\ast \ast 8heads,eachwith$d_k = d_v = 64$, total model dimension = 512

The Great Jay Alammar III

If you had 8 attention heads in this class...

What would each one attend to?

• Head 1: The slides
• Head 2: What the professor is saying
• Head 3: Whether it's almost 1:35
• Head 4: ?
• Head 5: ?
• Head 6: ?
• Head 7: ?
• Head 8: ?

The point: Each head specializes. No single head can capture everything, that's why we need multiple.

Stepping back

You now understand the core mechanism behind every modern LLM.

The attention formula (cross-attention, self-attention, same math) is what powers ChatGPT, Claude, BERT, and every transformer.

Multi-head attention just runs it multiple times in parallel for richer representations.

Question if we have time: How similar is this to how our brains work?

Part 7: Masked Attention

Masking Demystified

Why do we need masking? Two reasons:

1. Padding: Batches have different sequence lengths
2. Causal attention: Decoders can't look at future tokens

Padding mask

Problem: Batching sequences of different lengths

Batch:
  Sentence 1: "The cat sat on the mat"  (6 tokens)
  Sentence 2: "I love NLP"              (3 tokens)

Solution: Pad shorter sequence
  Sentence 1: [The, cat, sat, on, the, mat]
  Sentence 2: [I, love, NLP, PAD, PAD, PAD]

But we don't want attention to [PAD] tokens!

Padding mask: how it works

Create mask: 1 = real token, 0 = padding

Sentence 2: [I,  love,  NLP,  PAD,  PAD,  PAD]
Mask:       [1,   1,    1,    0,    0,    0  ]

During attention: Set masked positions to -∞

Before mask: QK^T = [2.1, 1.5, 3.2, 0.8, 0.5, 0.7]
After mask:        [2.1, 1.5, 3.2, -∞,  -∞,  -∞ ]
After softmax:     [0.3, 0.2, 0.5, 0.0, 0.0, 0.0]

Result: Padding gets zero attention weight.

Causal mask (for decoders/generation)

Problem: During training, the decoder can't peek at future tokens

Solution: Lower triangular mask - each position attends only to itself and earlier positions

        pos 0  pos 1  pos 2  pos 3
pos 0   [  1     0      0      0   ]   "The"
pos 1   [  1     1      0      0   ]   "cat"
pos 2   [  1     1      1      0   ]   "sat"
pos 3   [  1     1      1      1   ]   "on"

Why? When generating "cat", the model has only seen "The". The mask enforces this at training time too.

Extra Discussion: moltbook

In the last few minutes... what do you think?

Project idea: scraping/analyzing this or writing your own bot to join them?

What we learned today

Attention solves the bottleneck problem - dynamic context instead of one fixed vector

Q, K, V framework: Query what you want, match against Keys, retrieve Values

Self-attention: The same mechanism, but a sequence attends to itself

Multi-head attention: Multiple perspectives in parallel

Masked attention: Two flavors - padding masks (ignore [PAD] tokens) and causal masks (can't peek at future)

Next time: The full transformer architecture

Highly recommended reading: The Illustrated Transformer by Jay Alammar

Lab reminder: Lab/reflections for week 4 due Friday

Tuesday: Positional encoding + encoder/decoder blocks + the complete picture

Lecture 7 - Transformer Architecture

Welcome back!

Last time: Attention, self-attention, multi-head attention

Today: Full transformer architecture

Why this matters: Every major LLM uses transformers (GPT, BERT, Claude, Gemini)

Logistics

• Portfolio piece due Friday (slash Sunday)
  • Scope ~ blog post
• Decoding and midterm review tomorrow
• Exam Monday

Ice breaker (think/pair/share)

What differences have you noticed across LLM models - from GPT-2/3 to today's models?

Agenda for today

1. Recap + Data flow: From text to Q/K/V
2. Building blocks: Positional encoding, residual connections, layer norm, FFN
3. Full architecture: Encoder and decoder deep dive
4. Hands-on: Drawing the transformer together

Part 1: Recap and Data Flow

Monday's key ideas

Cross-attention: Decoder attends to encoder

• "What input is relevant to what I'm generating?"

Self-attention: Sequence attends to itself

• "How do words relate to each other?"

Multi-head attention: Multiple attention heads in parallel

• Different heads capture syntax, semantics, position

The formula:

$$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{Q{K}^T}{\sqrt{d_k}}\right)V$$

Today: How these pieces snap together

But first: where do Q, K, V come from?

I was clear about: Attention formula, combining Q, K, V

I was not clear about: Where do we GET Q, K, V?

So let's track the complete flow

From raw input to embeddings

Starting point: "snow melts"

Let's assume the size of our embeddings is $d_{model}=512$

Step 1: Tokenization

• ["snow", "melts"], one-hot encoded gives us a $2 \times 50,000$matrix\ast \ast Step2:Embeddings\ast \ast -MultiplybyembeddingmatrixM$(50,000 \times 512) \to 2 \times 512$\ast \ast Step3:Addpositionalencoding\ast \ast -Addednotconcatenated(samematrixsize)\ast \ast Result:\ast \ast MatrixX$(2 \times 512)$

From embeddings to Q, K, V

(Assuming self-attention)

Three learned projection matrices: $W_Q$,$W_K$,$W_V$(each\$512\times 512$)

$Q=X\times W_Q$

• Project embedding into query space

$K=X\times W_K$

• Project embedding into key space (for matching)

$V=X\times W_V$

• Project embedding into value space (for content)

Projection matrices are learned during training

Now we can use the attention formula

Once we have Q, K, V:

$$\text{Attention}(Q,K,V)=\text{softmax}\left(\frac{Q{K}^T}{\sqrt{d_k}}\right)V$$