Most NLP tutorials stop at isolated notebooks: one file for tokenization, another for sentiment, a third for intent, none wired to HTTP, persistence, or observability. week_25_26_aiml_integrated_project is a self-contained capstone that consolidates classical text processing, transformer tokenization, embeddings, sequence modeling, sentiment analysis, intent routing, and response selection into one runnable system:

• An installable Python package (week2526_python) with a core engine, learning lab wrappers, and a product NLP pipeline

• A single FastAPI backend exposing a lab path for component exploration and a product path for analyze, predict, and experiment training

• A React dashboard with live telemetry, a support-assistant workflow, a pipeline studio, and an operations console

• Postgres-backed experiment metadata, PyTorch artifacts on disk, and production hardening (timeouts, structured logging, graceful ML degradation)

The engineer payoff is operational clarity: one /analyze call runs preprocess → intent → sentiment → response; training jobs become Run rows you poll from the dashboard; missing models fall back to lexicon and keyword rules instead of crashing the API.

Core Components

Each block below is a distinct capability inside this repository—not an external dependency.

Classical text pipeline

week2526_python.core.text_pipeline provides NLTK-backed normalization, tokenization, stemming, lemmatization, POS tagging, and TF-IDF feature extraction. nltk_bootstrap.py lazily downloads punkt and stopwords only when classical processing runs, keeping cold starts fast.

Subword tokenization

core.tokenization.distilbert and core.tokenization.subword wrap Hugging Face tokenizers (DistilBERT, BERT, GPT-2). Lab endpoints expose side-by-side token comparisons without loading full models on every health check.

Word embeddings

core.embeddings.glove loads GloVe vectors or falls back to a deterministic synthetic vocabulary for offline demos. glove_bootstrap.py caches vector files under GLOVE_CACHE_DIR on startup when WEEK2526_BOOTSTRAP_MISSING=true.

Character sequence model

core.sequence_models.char_lstm implements a character-level LSTM for text generation. Checkpoints live under artifacts/sequence/char_lstm.pt after a lab train call.

Sentiment stack

The sentiment module spans vocabulary building (vocabulary.py), Bi-LSTM architecture (model.py), training (training.py), lexicon scoring (lexicon.py), and inference (inference.py). Artifacts: artifacts/sentiment/best_model.pt, vocab.json, and metrics.json.

Intent classification

core.intent.classifier trains a DistilBERT head over six support intents. core.intent.lightweight provides keyword-based routing when no checkpoint exists or when WEEK2526_LIGHTWEIGHT_MODE=true. Checkpoint path: artifacts/intent/intent_classifier.pt.

Response selection

core.response_selection.selector maps intent + sentiment score to template replies, optionally reranking with embedding similarity when ML artifacts are present.

Product NLP engine

core.nlp_engine.pipeline implements analyze_text, predict_sentiment_product, system_status, and bootstrap_missing_assets. This is the orchestration layer the product API calls through app.services.model_loader.

Model registry loader

backend/app/services/model_loader.py lazy-loads sentiment and intent models behind a thread-safe registry, exposes readiness(), and never raises on missing artifacts—lexicon and lightweight intent are used instead.

Experiment and training orchestration

SQLAlchemy models (Experiment, Run, Artifact) plus async repositories manage product training. nlp_train_job.py schedules background jobs with asyncio.create_task and supports synchronous training via ?sync=true.

FastAPI surface and middleware

backend/app/main.py defines the only FastAPI() instance. Middleware includes request timeouts (30s default, 600s for long train routes), upload size limits (WEEK2526_MAX_UPLOAD_MB), JSON request logging with request_id and latency_ms, and environment-aware CORS.

React dashboard

The frontend (frontend/src/ui/) ships four views—Overview, Support Assistant, Pipeline Studio, and Operations—with sidebar navigation, live metric polling (4s global, 3s during active training runs), animated pipeline progress on analyze, and module cards grouped by topic (text processing, embeddings, sentiment, intent and response).

Architecture Overview

Surface table

http://localhost:3000

OperatorsMulti-panel NLP console proxied through Nginx

Architecture diagram

The diagram below shows how the dashboard, API layer, Python package tiers, and persistence volumes connect. External caches (NLTK, Hugging Face) feed the core package without blocking the product path in lightweight mode.

Read more

• A multi-capability NLP Intelligence API that classifies intent, scores sentiment, and generates contextual responses — all served through a single REST endpoint.

• A modular PyTorch-based pipeline where each NLP component is independently testable and swappable without touching the rest of the system.

• A production-style deployment with Docker, a health-check endpoint, structured logging, and a minimal web demo interface.

Why This Matters

You’ve spent 176 days learning how individual pieces work — tensors, layers, training loops, embeddings, sequence models. What separates a student from a practitioner is the ability to compose those pieces into a system that solves a real problem end-to-end. Every major NLP product at companies like OpenAI, Cohere, or Hugging Face is not one model — it’s a pipeline of coordinated components: input normalization, classification, generation, post-processing, and serving. This capstone is your first time building that pipeline yourself, which means by the end of Day 180, you’ll have produced something you can legitimately show in a job interview or deploy for real users.

Core Concepts

1. The NLP Pipeline as a System, Not a Script

A pipeline is a directed graph of transformations. Each node takes in a well-defined input and produces a well-defined output. The moment you start building pipelines this way, your code becomes composable. You can swap a rule-based intent classifier for a neural one without touching the sentiment module. You can add a new component — say, entity extraction — without modifying the response generator.

In production systems at Stripe or Shopify, the ML inference path looks exactly like this: an API gateway hands the raw text to a normalization service, which passes the cleaned text to a classification model, which produces a structured prediction object, which routes to a generation or retrieval system, which formats the final response. Each handoff is a typed contract. Today you’re building that exact pattern.

2. Intent Classification with Lightweight Transformers

The dominant pattern for intent classification in production is fine-tuning a pre-trained transformer on a small labeled dataset. DistilBERT — a compressed version of BERT — gives you 97% of the accuracy at 40% of the size. This is the same trade-off that powers intent routing in voice assistants at Amazon and Google.

The key insight here is that the pre-trained model already understands language at a deep level. Your fine-tuning job is not to teach it language — it’s to teach it your categories. When you have only a few hundred labeled examples, this transfer learning approach outperforms training from scratch by a wide margin. Your final classifier is really just a linear layer sitting on top of a frozen or lightly-unfrozen transformer backbone.

3. Sentiment-Aware Response Generation

The response generation in this system is a hybrid: a retrieval layer picks a candidate response template based on intent and sentiment score, and a neural reranker scores each candidate against the original query context. This avoids the hallucination risk of pure generation while still producing contextually relevant responses.

This pattern — retrieval-augmented generation with a reranker — is exactly what systems like Perplexity AI and Bing Chat use at scale. The reranker is a cross-encoder transformer that takes (query, candidate) pairs as input and outputs a relevance score. You’re not building the full RAG stack today, but the architecture you implement mirrors the production pattern precisely.

4. API Design for ML Systems

Serving an ML model is fundamentally different from serving a database. Model inference has unpredictable latency, GPU resource contention, and serialization overhead. Three patterns matter most:

Request batching: Group multiple incoming requests together before sending to the model. A batch of 32 requests takes only 1.5× the time of a single request on a GPU, so throughput multiplies dramatically. Your system implements a simple synchronous batch endpoint.

Response caching: Identical or near-identical queries should return cached predictions. A simple Redis-backed LRU cache cuts GPU load significantly in production. The architecture includes a cache layer even if you implement it in-memory for the capstone.

Structured error envelopes: Every response — success or failure — should follow the same JSON schema. Clients must be able to rely on the response structure regardless of what happened internally. Your API will always return {status, data, error, latency_ms}.

5. Component Architecture

The preprocessor runs first and its output is shared by both the intent classifier and the sentiment scorer — they run in parallel, then their outputs converge at the response selector. This parallel fan-out pattern keeps latency bounded to max(t_intent, t_sentiment) rather than t_intent + t_sentiment.

                   NLP Intelligence API

   Input Text
       |
       v
   [Preprocessor]  -->  normalize, tokenize, truncate
       |
       +-----------------------------+
       v                             v
   [Intent Classifier]        [Sentiment Scorer]
   (DistilBERT + linear)      (LSTM / Day 176)
       |                             |
       +-------------+---------------+
                     v
            [Response Selector]
            (retrieve + rerank)
                     |
                     v
              [JSON Response]

Read more

Computer vision prototypes usually die in notebooks: one script for preprocessing, another for training, a third for evaluation, and nothing that tracks experiments or serves inference behind a stable HTTP contract. week_23_24_aiml_integrated_project is a self-contained capstone that consolidates the full vision pipeline into one runnable system:

• An installable Python package (week2324_python) with concept-named modules for preprocessing, CNNs, pooling, datasets, training loops, evaluation, export, and deployment

• A FastAPI backend exposing two API surfaces: a lab path for topic exploration and a product path for experiment lifecycle management

• VisionClassifier Platform — a React dashboard with a guided pipeline, component studio, live training monitor, and multipart image inference

• PostgreSQL-backed experiment metadata (async SQLAlchemy + Alembic), named Docker volumes for artifacts and dataset caches, and offline-safe synthetic fallbacks when CIFAR archives cannot be downloaded

The engineer payoff is traceability and boundaries. A quick CNN smoke test is not a stray script—it is train_simple_cnn behind a lab route with capped batches. Production training is not a blocking HTTP call—it is POST /api/v1/cv/experiments/{id}/train returning HTTP 202 while asyncio.create_task runs ResNet fine-tuning in a worker thread, with the dashboard polling run status until completion or failure.

Core Components

The stack is layered. Each topic below is a distinct building block; together they form one coherent image-classification platform.

Image preprocessing and normalization

image_pipeline.py handles OpenCV/PIL ingestion, ImageNet-style normalization profiles (CIFAR10_MEAN / CIFAR100_MEAN), and build_inference_transform for 224×224 upload tensors. preprocess_upload_bytes powers multipart inference on the product API.

Convolutional network architectures

SimpleCNN provides a pedagogical three-block classifier for CIFAR-10 smoke tests. ImageClassifier is a deeper three-block production-style CNN with checkpoint saving. build_resnet18_classifier wraps torchvision ResNet18 with a replaceable FC head for 100-way CIFAR-100 classification. inspect_feature_maps in cnn/debug.py exposes spatial activations for architecture demos.

Pooling strategies

Read more

• Wire together everything from Days 169–172 into a single end-to-end pipeline

• Build a production-style sentiment classifier on the IMDB movie reviews dataset

• Train, evaluate, and serve the model through a lightweight REST inference endpoint

• Measure real metrics — accuracy, F1 score, and confusion matrix — not just training loss

Why This Matters

Every product that handles user-generated text has a sentiment layer somewhere. Amazon uses it to surface trending complaints before they become PR crises. Airbnb uses it to flag toxic reviews in real time. Spotify uses it on social data to figure out which artists are gaining buzz before the charts reflect it. The pattern is always the same: preprocess text, encode meaning, classify intent, act on the signal. You have all three of those pieces now — tokenization from Day 169, embeddings from Day 170, and sequence modeling from Day 172. This project stitches them into a deployable system and teaches you the engineering discipline of closing the loop from raw data to a live prediction endpoint.

Core Concepts

1. The Full NLP Pipeline as One Unit

Up to now you have built each stage in isolation. A sentiment analyzer forces you to reason about the pipeline as a single contract: garbage in one stage poisons every stage after it. The input to your model is not text — it is a fixed-length integer sequence produced by a specific tokenizer trained on a specific vocabulary. That tokenizer must be saved alongside the model weights or the model is useless at inference time. This is the single most common mistake junior engineers make when deploying NLP systems: they checkpoint the weights and throw away the tokenizer.

Think of it like a lock-and-key pair. The model is the lock; the tokenizer is the key. Ship them as one artifact.

2. Bidirectional LSTMs for Sentiment

A standard LSTM reads a sentence left to right. But the word “not” near the beginning of a sentence can completely invert the meaning of a word that appears twelve tokens later. A Bidirectional LSTM runs two passes — one forward, one backward — and concatenates the hidden states at each timestep. The model can now “see” what comes after a word before it decides how to weight that word. For sentiment tasks, Bi-LSTMs consistently outperform unidirectional ones by three to five percentage points on benchmark datasets with no extra training data.

3. Pretrained GloVe Embeddings vs Learned Embeddings

You can initialize your embedding layer with random weights and let the model learn them from scratch. That works fine if you have hundreds of thousands of training examples. For smaller datasets — under fifty thousand examples — you are better off seeding the embedding layer with pretrained GloVe vectors (100d or 200d). GloVe was trained on billions of tokens; your model gets that knowledge for free and only needs to fine-tune it. The practical difference in validation accuracy on IMDB is typically three to eight points, and training converges two to three times faster.

4. Evaluation Beyond Accuracy

Binary sentiment on IMDB is balanced (50% positive, 50% negative), so accuracy is a fair metric here. The moment you move to a real production dataset — say, customer support tickets where 80% are neutral — accuracy becomes misleading. A model that always predicts “neutral” gets 80% accuracy while being completely useless. F1 score, which balances precision and recall, is the metric that actually tells you whether the model is doing something useful. Wire in scikit-learn’s classification_report from day one so you develop the habit of looking at the full picture.

5. The Inference Contract

A trained model sitting in a .pt file does nothing for a product team. What they need is an inference function with a clean, stable interface: string in, label and confidence score out. In production this function gets wrapped in a FastAPI endpoint, containerized, and deployed behind a load balancer. Building that wrapper is as much a part of the project as training the model. The function needs to handle edge cases — empty strings, non-ASCII characters, extremely long inputs — without crashing.

Read more

What We Are Building Today

By the end of this lesson you will have done three things that actually matter:

• Understood why sequential data breaks standard networks — and what RNNs do differently at the architectural level.

• Decoded how LSTMs solve the vanishing gradient problem that crippled early RNNs, using three learned memory gates.

• Built a working character-level language model that generates text one character at a time — the same core idea behind every autocomplete you have ever used.

• Connected this to production systems at Google, Amazon, Apple, and Stripe that run LSTM-based models today.

Why This Matters

Yesterday you built word embeddings — dense vector representations of meaning. Today you learn how to process sequences of those vectors over time. Every autocomplete suggestion you have typed, every translation you have read, every voice command your phone understood — all of it traces back to the sequential modeling ideas you will master today.

Even in the age of transformers, understanding RNNs and LSTMs is not optional. Production systems at Apple (on-device Siri models), Amazon (Alexa keyword detection), and trading firms (time-series forecasting) still run LSTM-based models because they are computationally lighter and interpretable. Knowing why transformers replaced RNNs requires understanding what RNNs got wrong. That knowledge gap is what separates engineers who implement AI from engineers who design it.

Core Concepts

1. The Sequence Problem — Why Feedforward Networks Fall Short

A standard dense neural network treats every input as independent. Feed it “The cat sat on the ___” and it sees seven unrelated word vectors with no awareness of order. The network has no memory — it cannot know that “cat” modifies what comes after “sat.”

Think of it like reading a book where each page is shuffled randomly. You see the words, but the story is gone.

RNNs fix this by introducing a hidden state — a memory vector that gets updated at every time step. At step t, the network takes two inputs: the current word vector x_t and the hidden state from the previous step h_{t-1}. The output hidden state h_t encodes everything the network has seen up to position t.

h_t = tanh( W_hh · h_{t-1}  +  W_xh · x_t  +  b )

That shared weight matrix W_hh is identical at every time step — it is what makes RNNs parameter-efficient. A 10-step sequence and a 1,000-step sequence use exactly the same parameter count.

2. The Vanishing Gradient — The RNN’s Achilles Heel

Here is the bitter irony. Backpropagation through an RNN means multiplying gradients across every time step. If those gradients are smaller than 1.0 (which they almost always are after a tanh), they shrink exponentially. By the time you are 50 steps back, the gradient is effectively zero.

The network literally forgets what happened earlier in the sequence. Training an RNN on a long paragraph and asking it to remember the subject from sentence one is like whispering a secret across 100 people — by the end, the message is noise.

Key Insight — The Vanishing Gradient Problem This is the single biggest reason vanilla RNNs struggle with dependencies longer than roughly 10–20 tokens. Each time step multiplies gradients together, and repeated multiplication of values less than 1.0 sends them toward zero exponentially fast. LSTMs were invented specifically to fix this.

3. LSTMs — Learned Memory Management

Long Short-Term Memory networks (Hochreiter & Schmidhuber, 1997) solve the vanishing gradient problem with a second memory channel: the cell state C_t. Where the hidden state is your working memory, the cell state is long-term storage — and crucially, information flows through it additively, not multiplicatively.

LSTMs use three learned gates to control information flow:

Read more

Notebook lessons teach tensors, Keras Sequential, PyTorch nn.Module, and CIFAR-10 pipelines in isolation. A platform team needs the opposite: one service that runs curriculum demos for learning, a product API for experiments and async training, and a core library that both surfaces import—without duplicating model code across fourteen days.

This project composes Days 141–147 into a single stack: week2122_python (TensorFlow + PyTorch cores), FastAPI with Learning and Vision APIs, Postgres-backed runs, a React dashboard on port 3000, and HTTP 501 stubs for Days 148–154 until lesson code lands.

Takeaway: You will see how to unify two deep-learning frameworks behind one vision engine, expose them through intentional API layers, and keep long training off the request thread.

System Overview

Four bands carry the design:

• React + Nginx (port 3000) — unified pipeline, curriculum studio, operations monitor with live metrics polling.

• FastAPI (port 8000) — /api/v1/week2122/learn/day{N}/... for Days 141–147 demos; /api/v1/vision/... for experiments, Iris comparison, and CIFAR jobs; lesson aliases at /api/v1/learn/lesson-{N}/.

• week2122_python core — core/tensorflow/ (tensors, autodiff, Iris Sequential, MNIST, CIFAR-10 tf.data), core/pytorch/ (tensors, autograd, tabular nets), core/vision_engine/pipeline.py (product composition), core/runtime/write_gate.py (Day 145 freeze pattern).

• Postgres + Alembic — experiments, runs, artifacts; background CIFAR training via cifar_train_job.py and asyncio.to_thread.

Day 141–143 material surfaces as TensorFlow learning routes and MNIST smoke tests. Days 144–146 feed PyTorch learning routes and the Iris compare product endpoint. Day 147 drives CIFAR baseline training and experiment registration.

Engine / Core System Design

The core package owns tensors, training loops, and evaluation metrics. The backend owns HTTP, SQLAlchemy repositories, and job scheduling. Routes validate caps from settings (max epochs, batch limits) and delegate synchronously or enqueue work.

Read more

• Understand why raw text is unusable by neural networks and what embeddings solve

• Explore the architecture of Word2Vec (Skip-gram and CBOW) and GloVe

• Implement embedding lookups, similarity search, and semantic arithmetic in Python

• Connect word vectors to production NLP systems at scale

Why This Matters

Every search engine, recommendation system, and large language model you have ever used runs on one foundational idea: words can be represented as points in high-dimensional space, and words with similar meanings cluster near each other. Without this, a model cannot know that “bank” and “financial institution” refer to similar concepts, or that “Paris” relates to “France” the same way “Tokyo” relates to “Japan.”

Word embeddings are the bridge between human language and mathematical computation. They are the reason modern NLP works at all.

Core Concepts

The Problem: Language Has No Natural Numbers

Neural networks process tensors — grids of floating point numbers. The letter “A” means nothing to a matrix multiplication. One-hot encoding is the naive fix: represent 50,000 vocabulary words as a 50,000-dimensional vector where only one position is 1. It works, but it is catastrophically wasteful and semantically blind. “Dog” and “canine” have zero overlap in one-hot space even though they mean the same thing.

Word2Vec: Learning Meaning From Context

Word2Vec, introduced by Google researchers in 2013, learns embeddings by training a shallow neural network on a deceptively simple task: given a word, predict its neighbors, or given neighbors, predict the center word.

Skip-gram — Takes a center word, predicts surrounding context words. Works well for infrequent words.

CBOW (Continuous Bag of Words) — Takes surrounding context words, predicts the center word. Faster, better for frequent words.

The key insight is that the network never actually cares about the prediction task. What matters is the weight matrix it builds while solving that task — a 300-dimensional vector per word that encodes semantic relationships the model learned purely from co-occurrence patterns in billions of text examples.

The “aha” moment. After training on billions of words, the geometry that emerges is astonishing. King minus man plus woman equals queen. Paris minus France plus Germany equals Berlin. These are not programmed rules. The geometry emerges entirely from statistics.

Read more

• Why raw text is useless to a neural network, and what preprocessing actually does

• The tokenization spectrum: from character-level splits to subword vocabularies

• How modern NLP pipelines (BERT, GPT, LLaMA) tokenize text at production scale

• Building a preprocessing pipeline from scratch: cleaning, normalization, tokenization, and encoding

• Where this sits in a live AI system’s data flow

Why This Matters

Yesterday you got the 10,000-foot view of NLP. Today you go one level down into the engine room. Every language model — whether it’s the BERT model powering Google Search or the GPT-4 backbone behind ChatGPT — starts with the exact same problem: text is just a sequence of Unicode characters, and neural networks only understand numbers.

Text preprocessing is the translation layer. It transforms messy, human-written language into clean, structured numerical representations that a model can actually learn from. Get this wrong and your model learns noise. Get it right and you’ve handed your model a consistent, information-dense signal. At companies like OpenAI, Hugging Face, and Cohere, entire teams are dedicated to tokenizer design — not because it’s glamorous, but because a bad tokenizer caps the ceiling on everything built on top of it.

Tokenizers are not utilities. They are model components.

Core Concepts

1. The Raw Text Problem

Neural networks are mathematical functions. They compute dot products, matrix multiplications, and nonlinear activations — all operations that require floating-point numbers. The sentence "The model crashed at 3am!!" has no numeric form until you create one.

Before you even think about tokenization, the text itself needs to be cleaned. Production text is full of HTML artifacts (&, <br/>), inconsistent Unicode, mixed case, multiple whitespace characters, and null bytes from encoding issues. These irregularities don’t just add noise — they fragment your vocabulary. "Apple", "apple", and "APPLE" would all become different tokens if you skip lowercasing. That’s three entries in your vocabulary table for the same semantic concept.

The cleaning phase handles:

• Lowercasing (where appropriate)

• HTML unescaping and tag stripping

• Unicode normalization (NFC vs NFD)

• Punctuation handling

• Whitespace collapsing

This is not optional housekeeping — it directly determines vocabulary size, which determines model parameter count.

2. Tokenization Strategies

Tokenization is the act of splitting text into discrete units called tokens. Three main strategies exist, and each makes a different tradeoff.

Word-level tokenization splits on whitespace and punctuation. Simple and interpretable — "the cat sat" becomes ["the", "cat", "sat"]. The fatal flaw: out-of-vocabulary (OOV) words. If your training data never contained "transformer", the model has no representation for it at inference time. Vocabularies also explode — English alone has 500,000+ words, and that’s before you add technical jargon, names, and typos.

Character-level tokenization splits into individual characters. No OOV problem by definition — every character is in your alphabet. But sequences become extremely long, and the model must learn to compose meaning from scratch, which requires vastly more training data and compute.

Subword tokenization is the practical solution that modern systems use. The insight is elegant: keep common words as single tokens, but split rare or unknown words into meaningful sub-pieces. The word "tokenization" might become ["token", "ization"]. The word "unhappiness" might become ["un", "happiness"]. The model sees morphemic structure rather than opaque character soup.

Two dominant subword algorithms:

Byte Pair Encoding (BPE) — used by GPT-2, GPT-3, GPT-4, and LLaMA. Starts with character-level tokenization and iteratively merges the most frequent adjacent pairs until a target vocabulary size is reached.

WordPiece — used by BERT. Same general idea as BPE, but uses a likelihood-based merge criterion instead of raw frequency. Results in a vocabulary of 30,000–100,000 tokens that covers essentially any input text without OOV issues.

3. Vocabulary and Encoding

Once you have tokens, you need to map them to integers — this is the vocabulary lookup. The vocabulary is a dictionary: {"the": 0, "cat": 1, ...}. Every token in your corpus gets a unique integer ID. Special tokens are added explicitly to handle structural positions in a sequence.

After encoding, each sentence is a list of integers. This is the actual input to the embedding layer — not the words themselves.

4. Attention Masks and the Padding Problem

Batching sequences requires them to be the same length. But sentences are not. The solution is to pad shorter sequences with [PAD] tokens up to the maximum sequence length in the batch, then provide an attention mask — a binary vector marking which positions are real tokens (1) and which are padding (0).

The transformer’s attention mechanism uses this mask to ignore padded positions during computation. This is architectural plumbing that most tutorials skip, but it’s fundamental to how batched inference works at production scale.

Component Architecture

The preprocessing pipeline has five distinct stages. Each stage is stateless except the Tokenizer and Encoder — both depend on a trained vocabulary file (typically a .json or .txt vocab file loaded at startup). In production systems, this vocabulary file is versioned alongside the model weights.

Raw Input Text
      |
      v
+---------------------+
|   Text Cleaner      |  --> strip HTML, normalize unicode, collapse whitespace
+---------------------+
      |
      v
+---------------------+
|   Normalizer        |  --> lowercase, remove/keep punctuation, handle numbers
+---------------------+
      |
      v
+---------------------+
|   Tokenizer         |  --> split into subword tokens using BPE/WordPiece vocab
+---------------------+
      |
      v
+---------------------+
|   Encoder           |  --> map tokens --> integer IDs via vocabulary lookup
+---------------------+
      |
      v
+---------------------+
|   Padder/Masker     |  --> pad to batch length, generate attention masks
+---------------------+
      |
      v
 Tensor [batch_size, seq_len]  <-->  Model Input

Critical production note: Swapping a vocabulary file without updating the corresponding model weights is a silent failure mode. The model receives a different token distribution than it was trained on and produces degraded outputs with no error thrown. Tokenizer and weights are always versioned together.

Real-World Connection

At Stripe, every merchant-facing text field — chargeback descriptions, dispute notes, fraud explanations — passes through a preprocessing pipeline before hitting the risk classification model. The tokenizer there is trained on financial domain text to ensure that terms like "ACH reversal" and "NSF fee" are preserved as meaningful units rather than split arbitrarily.

At Google, the search query tokenizer handles 8.5 billion queries per day, many in low-resource languages where subword tokenization is the only viable strategy. The design of that tokenizer — its vocabulary size, its handling of numerals and punctuation — directly affects ranking quality for billions of searches.

Tokenizers are not utilities. They are model components.

Implementation: Build, Test and Demo

Github Link:

https://github.com/sysdr/aiml/tree/main/day170/day170_tokenization

What you will build: A complete, five-stage NLP preprocessing pipeline in Python, ending with batched tensors ready to feed directly into a BERT or GPT-2 model. All code lives in lesson_code.py. The test suite (20 pytest tests) lives in test_lesson.py.

Expected output: a confirmation message and a listing of the five files created inside day170_tokenization/.

Step 1 — Set Up the Environment

Installs all pinned dependencies, and downloads the NLTK and spaCy data required for tokenization exercises.

Expected output: "Environment ready." followed by the activation command. If you see a warning about a missing Rust compiler, ignore it — the Hugging Face tokenizers library ships pre-compiled wheels.

With Docker instead: docker build -t day170 . && docker run --rm day170

Step 2 — Run the Lesson Demo

lesson_code.py runs all seven sections of the pipeline in sequence, printing labeled output for each stage. Read through the terminal output as it runs — every printed block corresponds to a Core Concept section above.

python lesson_code.py

Step 3 — Run the Test Suite

The test suite has 20 tests organized into six classes, each covering a distinct stage of the pipeline.

pytest test_lesson.py -v

Expected result: 20 passed in approximately 8 seconds. The first run will download the BERT and GPT-2 tokenizer files from Hugging Face (~500 MB total). Subsequent runs use the local cache.

To also see line coverage:

pytest test_lesson.py -v --cov=lesson_code --cov-report=term-missing

Step 4 — Key Exercises to Try Yourself

Exercise A — Compare tokenization of a medical vs. general sentence

from lesson_code import load_bert_tokenizer, bert_tokenize

tok = load_bert_tokenizer()
medical = "The patient presented with tachycardia and diaphoresis."
general = "The patient felt dizzy and was sweating."

print(bert_tokenize(tok, medical))
print(bert_tokenize(tok, general))

Pay attention to how the medical terms fragment into subwords. This is exactly why clinical NLP teams train domain-specific tokenizers.

Exercise B — Inspect the token distribution of a larger corpus

from lesson_code import load_bert_tokenizer, token_length_analysis

sentences = [
    "BERT uses WordPiece tokenization.",
    "GPT uses byte pair encoding.",
    "Both are subword tokenization methods.",
    "The quick brown fox jumps over the lazy dog.",
    "Tokenizers convert text into numbers.",
]

tok = load_bert_tokenizer()
print(token_length_analysis(tok, sentences))

Change max_length in bert_encode_batch to the max value from this analysis. Compare the number of padding tokens before and after.

Exercise C — Find where BERT and GPT-2 agree

from lesson_code import load_bert_tokenizer, load_gpt2_tokenizer, compare_tokenizers

words = ["running", "cats", "the", "AI", "unhappiness"]
result = compare_tokenizers(load_bert_tokenizer(), load_gpt2_tokenizer(), words)

for word, splits in result.items():
    match = splits['bert_wordpiece'] == splits['gpt2_bpe']
    print(f"{word:15s}  match={match}  bert={splits['bert_wordpiece']}")

Common English function words like "the" and "cats" produce identical single-token results in both tokenizers. Rare or morphologically complex words diverge.

Verification Checklist

Before moving to Day 171, confirm you can answer each of these from memory or by looking at lesson_code.py:

1. Why does skipping lowercasing inflate vocabulary size?

2. What does the ## prefix mean in a WordPiece token list?

3. What is the integer ID for [CLS] in bert-base-uncased? (Hint: check bert_tok.cls_token_id)

4. What shape does bert_encode_batch return for 3 sentences padded to max_length=32?

5. Why do BERT and GPT-2 produce different splits for the same word?

6. What does a 0 in the attention_mask indicate, and why does it matter?

7. If you swap the vocab.json file without updating model weights, what happens at inference?

Working Code Demo:

Read more

• Set up a production-grade image classification project targeting CIFAR-100 (100 classes, 60,000 images)

• Conduct exploratory data analysis to understand class distribution, sample quality, and inter-class similarity

• Design the full system architecture, from raw pixel ingestion through augmentation pipelines, model selection, and evaluation strategy

• Lay down the project scaffolding that Days 160-168 will build on top of

Why This Matters

Every production computer vision system at scale — Google Lens classifying 200+ plant species, Tesla’s object detection distinguishing pedestrians from cyclists, Pinterest’s visual search mapping images to 10,000+ product categories — started exactly here: someone had to decide the architecture before writing a single line of model code.

The decisions you make on Day 1 of a project, dataset splits, augmentation strategy, whether to train from scratch or fine-tune, have cascading effects on every downstream component. A model that reaches 92% accuracy on the training set but ships with a leaky train/test split is worse than useless in production. This project week teaches you to think like an ML engineer, not just a model trainer.

Agenda

1. Understanding CIFAR-100 and why complex datasets break naive CNN approaches

2. Project architecture: pipeline layers, data flow, and evaluation contracts

3. Exploratory data analysis: class imbalance, visual difficulty, superclass groupings

4. Transfer learning decision framework: when to fine-tune vs. train from scratch

5. Project directory scaffolding and reproducibility practices

Read more

Most “from scratch” neural network repos stop at a script that prints accuracy. That’s useful for learning, but it’s not a system engineers can iterate on: there’s no stable API surface, no durable run metadata, no clear separation between reusable core logic and orchestration, and no way to observe what the system is doing while it works.

This project turns Days 127-140 into a single production-style application: a NumPy-first core package, a FastAPI backend that exposes both Learning and Product endpoints, a React dashboard, and a Postgres-backed run ledger. You’ll walk away with a practical blueprint for integrating neural network lesson code into an operable service without losing the educational “glass box” properties.

System Overview

The stack is intentionally small and explicit:

• React dashboard (Vite build served by Nginx, port 3000) — one integrated workbench: a stepper for Days 127–131 and a Product view for experiments and runs.

• FastAPI backend (port 8000) — /api/v1/week1920/learn/... for curriculum-backed demos, /api/v1/ml/... for persisted experiments, runs, artifacts, and live metrics.

• week1920_python core package — the “engine room”: perceptron training, activation primitives, MLP forward passes, backprop trainer, MNIST forward model, plus a minimal losses/metrics surface.

• Persistence — Postgres (async SQLAlchemy + Alembic) for experiment and run metadata; Docker volumes for artifacts and cache directories.

The curriculum topics don’t show up as separate apps. They show up as modules that the system can execute: perceptron training is a callable unit, activations expose gradient checks, backprop is a bounded training job, and MNIST is operationalized as a forward pipeline (with training staged for later days).

Engine / Core System Design

The core package owns math and algorithms; the backend owns HTTP, input validation, and orchestration. That separation is what keeps the “lesson logic” reusable while letting the system behave like a service.

At the core layer, the “day modules” are not scripts. They’re importable functions and classes that can be dispatched from either the Learning API or a Product workflow. The engine layer is minimal on purpose: it standardizes conventions (shapes, seeds, bounded defaults) and provides a stable surface for orchestration.

Two details matter for correctness and operability:

1) A consistent parameter convention

The core uses a consistent dense-layer convention ((fan_in, fan_out) weights and Z = A @ W + b) across MLP and MNIST. That makes later training code predictable and keeps “shape debugging” localized.

2) Non-blocking orchestration

Learning endpoints can still do “real work” (training or dataset access), but the backend must remain responsive while that happens. This repo moves CPU-heavy work into asyncio.to_thread(...) so the event loop isn’t blocked by NumPy loops or dataset preprocessing.

backend/app/routes/week1920_lab.py (excerpt)
@week1920_router.post(”/learn/day130/backprop/train”)

async def learn_day130_backprop_train(epochs: int = 200, lr: float = 0.05, seed: int = 0):
    epochs = min(epochs, settings.WEEK1920_MAX_EPOCHS_LEARN)
def _run_sync():
        X, y = get_xor_data()
        y2 = y.reshape(-1, 1).astype(float)
        net = Trainer(layer_sizes=[2, 4, 4, 1], hidden_activation=”relu”, seed=seed)
        result = net.train(X, y2, epochs=epochs, lr=lr)
        preds = net.predict(X)
        accuracy = float(np.mean((preds >= 0.5).astype(int).flatten() == y2.flatten()))
return {”final_loss”: result[”final_loss”], “accuracy”: accuracy}
return await asyncio.to_thread(_run_sync)

Data Flow Diagram Reference

API Design

The API is split into two surfaces that behave differently:

• Learning endpoints are stateless, bounded, and “demo-first.”

• Product endpoints are stateful: they create experiments, record runs, and surface artifacts/metrics for the dashboard.

Representative endpoints:

GET /api/v1/week1920/learn/day127/perceptron?dataset=xor&max_epochs=50
Response: {
  lesson: "day127",
  dataset: "xor",
  accuracy: number,
  training: { converged: boolean, epochs_run: number, training_errors: number[] }
}

Runs the perceptron training loop with bounded epochs to demonstrate separability limits.

POST /api/v1/week1920/learn/day130/backprop/train?epochs=200&lr=0.05
Response: {
  lesson: "day130",
  epochs: number,
  lr: number,
  final_loss: number,
  loss_history_tail: number[],
  accuracy: number
}

Executes a bounded XOR backprop training run; designed to stay responsive by pushing CPU work off the event loop.

POST /api/v1/ml/experiments
Request:  { name: string, dataset_profile: "mnist", model_backend: "numpy_scratch", task_type: "mnist" }
Response: { id: uuid, name: string, created_at: string, architecture_json: object }

Creates a durable experiment record that will own many runs.

GET /api/v1/ml/metrics/live
Response: {
  server_time: string,
  experiments_count: number,
  runs_summary: { running: number, pending: number, completed: number, failed: number },
  latest_runs: [{ id: uuid, run_type: string, status: string, elapsed_seconds: number|null }]
}

A lightweight polling endpoint for the dashboard; it must remain fast even when learning routes are active.

In FastAPI, the pattern is consistent: validate inputs, then delegate to core modules or background jobs. The Product layer uses repositories to persist metadata, and services to execute work.

backend/app/routes/week1920_lab.py (excerpt)
@ml_router.post(”/experiments”, response_model=ExperimentOut)
async def create_experiment(payload: ExperimentCreate, db: AsyncSession = Depends(get_db)):
    repo = ExperimentRepository(db)
    exp = await repo.create_experiment(
        name=payload.name,
        dataset_profile=payload.dataset_profile,
        model_backend=payload.model_backend,
        objective_metric=payload.objective_metric,
        task_type=payload.task_type,
        architecture_json=payload.architecture_json or {”layers”: [784, 128, 64, 10]},
)
return ExperimentOut.model_validate(exp)

Subscribe to access Github

Github Link:

https://github.com/sysdr/aiml-p/tree/main/week_19_20_aiml_integrated_project

Implementation Guide

Read more

• Assemble a complete CNN pipeline — from raw pixels to class predictions — using PyTorch

• Wire together Conv2d, BatchNorm, pooling, and fully connected layers into a production-grade architecture

• Train, evaluate, and export a model that mirrors what ships in real computer vision systems

Why This Matters

Every camera-facing AI product you interact with — Google Photos tagging your vacation, Tesla’s Autopilot reading lane markings, Pinterest’s visual search matching your screenshots — runs on a CNN at its core. Yesterday you understood pooling and flattening in isolation. Today those pieces click together into a working classifier you can train end-to-end. This is the moment the theory stops being abstract. A student who completes today’s lesson walks away with a neural network architecture that, with more data and compute, could power a real production service.

Read more

• Why CNNs need pooling and what happens without it

• Max pooling vs. average pooling: mechanics and tradeoffs

• Flattening: the bridge from spatial features to classification decisions

• How pooling and flattening appear in production vision pipelines at Google, Tesla, and Meta

Why This Matters

Yesterday you built your first convolutional layers. They extract features — edges, textures, gradients — by sliding filters across an image. But there is a problem: a raw convolution output is enormous, spatially sensitive, and computationally expensive to work with. Pooling solves this. It compresses spatial information aggressively while retaining the parts that actually matter. Flattening then converts those compressed feature maps into a vector that a dense classifier can reason over.

Together, these two operations form the backbone of every production image classifier you have ever interacted with — the photo tagger on Instagram, the defect detector in a Tesla factory, the medical scan reader at a hospital.

Read more

Most course notebooks stop at a trained model on disk. Production teams need something else: repeatable experiments, tracked runs, persisted artifacts, and lesson code that does not fork into fifteen copies. This project unifies Days 113–126 into one stack—a shared Python core, a FastAPI service with separate Learning and Product APIs, a React dashboard, and Postgres-backed experiment metadata with background Optuna tuning.

You will walk away knowing how to compose gradient-boosting lessons into a single engine, expose them through two API surfaces, and run hyperparameter search without blocking HTTP or corrupting your database schema.

System Overview

The system splits into four bands:

• React dashboard (Nginx, port 3000) — experiment workbench, learning demos, live run polling.

• FastAPI backend (port 8000) — /api/v1/week1718/learn/* for curriculum demos; /api/v1/ml/* for experiments, runs, artifacts, and studies.

• week1718_python core — synthetic fraud data, scratch GBM, XGBoost/LightGBM trainers, bias–variance diagnostics, Optuna objectives, inference benchmarks.

• Persistence — Postgres (async SQLAlchemy + Alembic) for product metadata; dedicated SQLite file for Optuna RDB; Docker volume for joblib models.

Day 113’s scratch booster lives in the learning route. Day 114’s library comparison powers /learn/day114. Days 115–116 inform diagnostics and search configuration inside optuna_tuning.py. Days 117–126 drive the product flow: baseline run → async tune job → artifact write → study reference row.

Engine / Core System Design

Read more

• What a convolutional layer actually does — and why it beats dense layers for images

• Filters, kernels, feature maps, stride, and padding explained from first principles

• CNN architecture: how layers stack to build spatial understanding

• Implementing a CNN in PyTorch for image classification

• Where CNNs live inside production computer vision pipelines at scale

Read more

• What computer vision actually is, and why it matters beyond “image recognition”

• How raw pixels become structured data that neural networks can learn from

• The classic CV pipeline: acquire, preprocess, extract, classify

• Hands-on: build an image preprocessing pipeline using OpenCV and PIL

• How production CV systems at Google, Tesla, and Waymo handle millions of frames per second

Why This Matters

You have spent the last 28 days building neural networks that work on numbers in tables. Computer vision breaks that constraint entirely. The moment you can teach a model to understand images, you unlock a class of problems that touches nearly every industry on the planet: autonomous vehicles reading road signs, radiologists’ assistants flagging tumors in X-rays, warehouse robots locating items on shelves, retail systems tracking inventory without barcodes.

Every one of those systems starts with the same foundational step you are learning today: turning a raw image into a tensor a neural network can process. This is the bridge between the physical world and the computational one.

Core Concepts

What an Image Actually Is

An image is nothing more than a 3-dimensional array of numbers. A standard color photo with dimensions 224 × 224 pixels is a tensor of shape (224, 224, 3), where the three channels represent red, green, and blue intensity values ranging from 0 to 255. Grayscale images collapse to (224, 224, 1). That is it. The moment you accept that an image is just a matrix of integers, the entire field of computer vision becomes approachable.

NumPy stores this as a uint8 array. PyTorch and TensorFlow expect float32 tensors with values normalized to the range [0.0, 1.0]. Every preprocessing pipeline you write will include a division by 255.0 at some point. That single operation is the handshake between the imaging world and the deep learning world.

The Four-Stage CV Pipeline

Production computer vision systems, from Google Lens to Tesla Autopilot, follow a consistent architecture regardless of their ultimate task.

Stage 1 — Acquisition. Raw image data enters the system from a camera, file system, or network stream. Resolution, color space, and frame rate are properties of the acquisition layer. Tesla’s FSD cameras capture at 36 frames per second across eight cameras simultaneously. Every frame must enter the pipeline within 27 milliseconds to maintain real-time performance.

Stage 2 — Preprocessing. Raw images are noisy, inconsistently sized, and poorly lit. Preprocessing normalizes all of that. Resizing to a fixed resolution (commonly 224 × 224 for ImageNet-pretrained models), converting color spaces (BGR to RGB is a classic OpenCV gotcha), applying normalization using dataset-specific mean and standard deviation values — these operations create the clean, consistent input tensors that models expect. Skipping or misapplying preprocessing is the single most common cause of poor model performance on good data.

Stage 3 — Feature Extraction. This is where neural networks replaced decades of hand-crafted algorithms. Before deep learning, engineers spent careers writing code to detect edges with Sobel filters, find corners with Harris detectors, and describe local patches with SIFT descriptors. Convolutional Neural Networks, which you will build tomorrow, learn those detectors automatically from data. Today, understanding that features are the intermediate representations of meaningful visual structure — edges, textures, shapes, objects — is the conceptual foundation you need.

Stage 4 — Inference and Post-processing. The model produces raw scores (logits) or bounding box coordinates. Post-processing converts those into human-readable outputs: class labels, confidence scores, pixel masks. Non-Maximum Suppression (NMS) for object detection, sigmoid/softmax for classification, and morphological operations for segmentation all live here.

Color Spaces and Channel Ordering

A persistent source of bugs in CV pipelines is channel ordering. OpenCV loads images in BGR order by default. PyTorch models trained on ImageNet expect RGB. Loading an image with cv2.imread() and passing it directly to a pretrained model produces subtly wrong results that are difficult to diagnose because the model still produces predictions, just worse ones. Always apply cv2.cvtColor(img, cv2.COLOR_BGR2RGB) when bridging OpenCV and PyTorch.

Watch out for this one. BGR vs RGB is the most common silent bug in new CV pipelines. The model will still run and produce predictions — they will just be quietly wrong. It is the kind of error that costs days of debugging. One line of code prevents it entirely.

Normalization: Mean and Standard Deviation

ImageNet-pretrained models expect inputs normalized with specific statistics: mean = [0.485, 0.456, 0.406] and std = [0.229, 0.224, 0.225] across the RGB channels. These numbers represent the channel-wise mean and standard deviation of the entire ImageNet training set. Applying this normalization ensures your input distribution matches what the model learned on. Forgetting this step when using pretrained weights is another quiet killer of model performance.

Why these specific numbers? They were computed once across all 1.2 million images in the ImageNet dataset and published with the original models. Every researcher and engineer in the field uses the same values. You will have them memorized by the end of this module.

Key Concepts at a Glance

Implementation

These five steps walk you through the full preprocessing pipeline from raw file to normalized tensor. The code is intentionally minimal — you are learning what each operation does before you run the full package.

1. Install the dependencies

pip install opencv-python-headless Pillow torch torchvision numpy matplotlib

2. Load and inspect a raw image

This is the acquisition stage. You are reading the file, confirming its shape, and understanding the data type before touching anything.

import cv2
import numpy as np
from PIL import Image

img_bgr = cv2.imread("sample.jpg")
print(f"Shape: {img_bgr.shape}")   # (H, W, 3)
print(f"Dtype: {img_bgr.dtype}")   # uint8
print(f"Range: [{img_bgr.min()}, {img_bgr.max()}]")

3. Build the preprocessing pipeline

transforms.Compose chains operations in order. ToTensor handles the /255.0 conversion and the HxWxC to CxHxW transpose simultaneously. Normalize applies the ImageNet statistics channel by channel.

import torch
from torchvision import transforms

preprocess = transforms.Compose([
    transforms.Resize((224, 224)),
    transforms.ToTensor(),                # uint8 HxWxC -> float32 CxHxW, divides by 255
    transforms.Normalize(
        mean=[0.485, 0.456, 0.406],
        std=[0.229, 0.224, 0.225]
    )
])

img_rgb = cv2.cvtColor(img_bgr, cv2.COLOR_BGR2RGB)
pil_img = Image.fromarray(img_rgb)
tensor  = preprocess(pil_img)
print(f"Tensor shape: {tensor.shape}")   # torch.Size([3, 224, 224])
print(f"Tensor range: [{tensor.min():.3f}, {tensor.max():.3f}]")

4. Batch multiple images

Models do not process a single image at a time — they process batches. torch.stack adds the N dimension, turning a list of [3, 224, 224] tensors into a single [N, 3, 224, 224] tensor ready for a model.

batch = torch.stack([preprocess(Image.open(p).convert("RGB")) for p in image_paths])
print(f"Batch shape: {batch.shape}")  # [N, 3, 224, 224]

5. Visualize preprocessed tensors

You cannot display a normalized tensor directly — the values are outside the 0–1 range that image viewers expect. This function reverses the normalization so you can confirm the preprocessing visually.

def tensor_to_displayable(tensor):
    # Undo normalization for visualization
    mean = torch.tensor([0.485, 0.456, 0.406]).view(3, 1, 1)
    std  = torch.tensor([0.229, 0.224, 0.225]).view(3, 1, 1)
    img  = tensor * std + mean
    img  = img.permute(1, 2, 0).numpy()
    return (img * 255).astype(np.uint8)

Build, Test, and Demo

Github Link:

https://github.com/sysdr/aiml/tree/main/day155/day155_cv_intro

The bash script scaffolds the full implementation package — lesson_code.py, test_lesson.py, setup.sh, requirements.txt, and README.md.

1. Run the demo

python lesson_code.py

Expected output:

=== Stage 1: Acquisition & Inspection ===
  shape_hwc: (100, 280, 3)
  dtype: uint8    pixel_min: 0    pixel_max: 255

=== Stage 2: Preprocessing ===
  Output tensor shape : torch.Size([3, 224, 224])
  Output tensor dtype : torch.float32

=== Stage 3: Channel Statistics ===
  R -> mean=-0.1823  std=1.0241  range=[-2.117, 2.640]
  G -> mean=-0.0514  std=0.9876  range=[-1.966, 2.428]
  B -> mean= 0.0241  std=1.0103  range=[-1.804, 2.640]

=== Stage 4: Batch Demo ===
  Batch shape: torch.Size([2, 3, 224, 224])

Pipeline visualization saved: pipeline_demo.png
All stages complete.

2. Run the test suite

pytest test_lesson.py -v

25 tests across 5 classes: TestAcquisition, TestColorConversion, TestPreprocessing, TestBatchProcessing, and TestStatisticsAndInverse. All pass in under 30 seconds.

test_lesson.py::TestAcquisition::test_load_returns_dict PASSED
test_lesson.py::TestAcquisition::test_correct_dimensions PASSED
test_lesson.py::TestColorConversion::test_bgr_to_rgb_channels_swapped PASSED
test_lesson.py::TestPreprocessing::test_output_shape_default PASSED
...
25 passed in 18.43s

3. Docker (optional)

docker build -t day155-cv .
docker run --rm day155-cv python lesson_code.py
docker run --rm day155-cv pytest test_lesson.py -v

Real-World Connection

At Google Photos, every uploaded image passes through a preprocessing pipeline before entering the embedding model that powers visual search. The pipeline handles EXIF-aware rotation correction, HEIC-to-JPEG conversion, and adaptive resizing based on detected content type — portrait photos resize differently than landscape panoramas. At Waymo, the preprocessing pipeline for camera inputs must be deterministic and latency-bounded to guarantee frame synchrony across the sensor array. What you built today is a simplified version of those same foundations. The tensor you produce in step 3 is exactly what gets passed into a convolutional neural network.

Working Code Demo:

Preparing for Job Interviews explore preparation material - here

Subscribe to get Free copy of AI Engineer’s Blueprint

Introduction

Reinforcement learning and recommender systems usually arrive as separate lesson repos: a grid-world Q-learning script here, a MovieLens notebook there. That works for studying algorithms in isolation. It breaks when you need one deployable service that trains policies, serves hybrid recommendations, exposes curriculum demos over HTTP, and gives operators a live dashboard.

week_15_16_aiml_integrated_project unifies Days 99–112 into a single Dockerized stack:

• A learning layer that exposes each lesson through structured FastAPI routes.

• A core layer that holds canonical RL and recommender implementations.

• A product layer that runs grid-world training and MovieLens hybrid workflows end-to-end.

• A React dashboard behind nginx for learners and operators.

You will walk away knowing how Q-learning agents, collaborative SVD, content-based filters, and adaptive hybrids become modules inside one engine—not a pile of disconnected notebooks.

System Overview

Runtime shape stays deliberately small:

Original lesson folders (day99/ … day106_to_day112/) in the parent repo stay read-only. Logic is re-homed into packages/week1516_python/ with explicit one-way imports: learning/ never depends on core/ or product/.

Days 99–112 operationalize inside the system as follows—without re-teaching the algorithms:

• Days 99–102 feed the RL product path: intro Q-learning, agent/environment comparison, tabular Q-table export, and the Day 102 canonical grid-world agent persisted as JSON policy artifacts.

• Days 103–105 power the recommender theory and content-filter learning routes; collaborative user/item similarity and TF-IDF catalog demos run over synthetic or sample data.

• Days 106–112 collapse into the MovieLens product pipeline: temporal train/test split, dual artifact persistence (collab + content), and adaptive alpha blending at serve time.

Two routers share the same FastAPI process but serve different audiences. /api/v1/week1516/learn/* returns educational payloads—Q-table snapshots, CF similarity matrices, abbreviated pipeline demos. /api/v1/ml/* returns operator-grade artifacts: policy reward curves, RMSE/MAE scores, ranked movie lists. Both call into the same week1516_python package; only the adapter layer differs.

Engine and Core System Design

Read more

• Architect the full image classification system we’ll build across Days 147–154

• Build a production-grade data pipeline: loading, normalizing, and augmenting CIFAR-10

• Define the model skeleton, compile it, and run a single training epoch to verify the pipeline end-to-end

• Understand where this project fits inside real-world CV systems at companies like Google, Tesla, and Pinterest

Why This Project Matters

You spent Day 146 building a neural network in PyTorch by hand — manually writing the forward pass, the loss calculation, and the optimization step. That exercise taught you what happens under the hood. Now we flip to TensorFlow/Keras, the framework that powers production systems at Google, Waymo, Airbnb, and Twitter, and we use it to build something real: an image classifier trained on CIFAR-10, a 60,000-image benchmark dataset covering 10 object categories.

This is not a toy exercise. The architecture patterns you apply here — data pipeline separation, augmentation strategies, checkpointing, and evaluation loops — are the same ones used in production vision systems handling millions of inference calls per day.

The 7-Day Project Arc

Before writing a single line of code, understand what the week looks like:

Instructor Note: Today is the foundation. Get this wrong and every subsequent day compounds the error. Get it right and the rest of the week flows cleanly.

Core Concepts

1. The Data Pipeline Is Not an Afterthought

In production ML, teams consistently report that 60–80% of engineering effort lives in data, not models. The model itself is often 50 lines. The pipeline that feeds it reliably — handling corrupted files, class imbalance, augmentation, batching, and prefetching — is where the real work happens.

TensorFlow’s tf.data API is the production-standard answer to this. It is a lazy, composable pipeline that runs data loading and preprocessing on the CPU while the GPU trains the model in parallel. Netflix uses tf.data patterns for their recommendation system feature pipelines. Google Vision uses it to feed TPU clusters processing petabytes of images.

The Mental Model: Think of tf.data as a factory conveyor belt. Raw images come in one end. Normalized, augmented, batched tensors come out the other. The belt runs independently of the machine doing the work.

# Conceptual pipeline structure
dataset = tf.data.Dataset.from_tensor_slices((x_train, y_train))
dataset = dataset.shuffle(buffer_size=10000)
dataset = dataset.map(augment_fn, num_parallel_calls=tf.data.AUTOTUNE)
dataset = dataset.batch(64)
dataset = dataset.prefetch(tf.data.AUTOTUNE)

AUTOTUNE is TensorFlow telling the runtime: measure the actual hardware, then decide the optimal parallelism automatically. You never hard-code thread counts in production.

Read more

• Translate the computational graph from Day 145 into a full nn.Module — the standard building block of every PyTorch model in production

• Wire together layers, activation functions, a loss function, and an optimizer into a working training loop

• Train a two-layer network on real tabular data and read the metrics that engineers use to confirm a model is actually learning

Why This Matters

Yesterday you held a raw tensor and watched autograd track every gradient through the graph. That was the engine exposed. Today you bolt the body panels on: torch.nn gives you a composable API that every serious PyTorch codebase — from Meta’s recommendation systems to Waymo’s perception stack — is built on top of. Understanding nn.Module at this level is not academic; it is the exact mental model you need to read open-source model code, debug training failures, and eventually swap in your own custom layers without breaking anything downstream.

Read more

Unsupervised learning tutorials usually ship as disconnected scripts: K-Means in one folder, PCA in another, hierarchical clustering in a third. That is fine for learning algorithms in isolation. It fails when you need a single service that trains segmentations, serves predictions, exposes lesson demos over HTTP, and runs in Docker without eight separate virtual environments.

This project unifies Days 85–92 (plus stub health routes for the 93–98 review window) into one stack:

• A learning layer that exposes each lesson’s logic through structured HTTP routes.

• A composition layer that selects canonical implementations when multiple days solve the same problem differently.

• A product layer that runs customer segmentation, taxonomy building, and PCA workflows end-to-end.

• A React dashboard behind nginx for operators and learners.

You will walk away knowing how clustering theory, optimal-K selection, hierarchical taxonomies, and production PCA become modules inside one engine—not eight apps stitched together.

System Overview

Runtime shape is deliberately small:

Read more