19-chapter hands-on guide to machine learning — from supervised learning fundamentals to CNNs, NLP, LLMs, LangChain RAG pipelines, MLOps, and career paths. Every chapter includes Python code examples you can run directly.
Ch 1: ML fundamentals — supervised vs unsupervised vs reinforcement learning. Ch 2: Python for ML — NumPy, Pandas, Matplotlib, scikit-learn. Ch 3: Linear and logistic regression with gradient descent. Ch 4: Decision trees, random forests, and XGBoost. Ch 5: Neural networks — perceptrons, backpropagation, activation functions. Ch 6: CNNs for computer vision — convolutions, pooling, ResNet. Ch 7: RNNs and LSTMs for sequences. Ch 8: Transformers and attention mechanism. Ch 9: NLP — tokenization, word embeddings, BERT. Ch 10: LLMs — GPT architecture, fine-tuning, prompting. Ch 11–19: RAG with LangChain, MLOps (MLflow, DVC), model deployment (FastAPI, Docker), Kubernetes, feature stores, data pipelines, A/B testing, and ML career roadmap.
scikit-learn: the go-to library for classical ML (linear models, trees, clustering, preprocessing, pipelines). PyTorch: the research-standard deep learning framework — dynamic computation graphs, easy debugging, dominant in academia and growing in production. TensorFlow/Keras: production-ready deep learning, strong TFLite/TensorFlow.js ecosystem for edge and web deployment. Hugging Face Transformers: the standard library for working with pre-trained LLMs (BERT, GPT-2, LLaMA). LangChain: LLM application framework for RAG pipelines, agents, and chains. XGBoost/LightGBM: gradient boosting libraries that win most tabular data competitions.
RAG (Retrieval-Augmented Generation) chapter covers: Document loaders (PDF, web, CSV via LangChain). Text splitters (recursive character splitting with overlap). Embedding models (OpenAI text-embedding-3-small, open-source nomic-embed-text). Vector stores (Chroma for local, Pinecone for production). Retriever configuration (similarity search, MMR for diversity). LLM response generation (GPT-4o or Claude via LangChain ChatModel). ConversationalRetrievalChain for multi-turn Q&A. Evaluation with RAGAS (Retrieval Augmented Generation Assessment). All code is runnable in Google Colab.
The MLOps chapters cover the gap most ML courses skip: how to get models into production and keep them working. MLflow for experiment tracking (log parameters, metrics, artifacts). DVC for dataset versioning and pipeline reproducibility. FastAPI for serving models as REST endpoints. Docker for containerizing ML services. Kubernetes for scaling ML deployments. Feature stores (Feast) for serving consistent features in training and inference. Model monitoring for detecting data drift and performance degradation. CI/CD pipelines for automated model retraining.
For classical ML (tabular data): scikit-learn for everything from linear regression to SVMs and clustering; XGBoost and LightGBM for gradient boosting on structured datasets (these consistently win Kaggle competitions). For deep learning: PyTorch is the dominant research framework and increasingly dominant in production; TensorFlow/Keras remains strong for mobile/edge deployment via TFLite. For LLMs and generative AI: Hugging Face Transformers + Datasets + PEFT for working with and fine-tuning pre-trained models; LangChain or LlamaIndex for RAG and agent pipelines; vLLM for serving LLMs at scale. For data manipulation: Pandas for small/medium datasets; Polars (Rust-backed) for large datasets; DuckDB for SQL analytics on files.
Imbalanced datasets (where one class dominates, like 99% non-fraud vs 1% fraud) require special handling. Resampling approaches: oversample the minority class (SMOTE — Synthetic Minority Oversampling Technique, which generates synthetic samples), undersample the majority class (RandomUnderSampler), or combine both. Algorithm-level approaches: class_weight="balanced" in scikit-learn (adjusts loss function to penalize misclassifying minority class more), or use algorithms that handle imbalance natively (balanced random forest, EasyEnsemble). Evaluation: never use accuracy — use precision, recall, F1-score, ROC-AUC, or PR-AUC. The choice depends on the cost of false positives vs false negatives in your specific domain.
CNNs (Convolutional Neural Networks) are best for data with spatial structure: images (pattern detection with local receptive fields), audio spectrograms, and fixed-length signal segments. CNNs are parallelizable and fast to train. RNNs/LSTMs (Recurrent Neural Networks) were the standard for sequential data with temporal dependencies: text, time series, and variable-length sequences. However, Transformers have replaced RNNs for most NLP and long-sequence tasks due to their ability to capture long-range dependencies and their parallelizability. Today, the practical rule is: use CNNs for images, use Transformers for text and long sequences, consider 1D-CNNs or Transformers for time series depending on the length and pattern type.
RAG (Retrieval-Augmented Generation) retrieves relevant documents at inference time and includes them in the prompt. Fine-tuning updates the model's weights using domain-specific training data. RAG is better when: your knowledge base changes frequently, you need source citations, you want to avoid hallucination on factual queries, or your knowledge base is larger than what can fit in model weights. Fine-tuning is better when: you need the model to change its style or tone consistently, you want faster inference (no retrieval step), your domain uses specialized vocabulary the base model doesn't know, or you need the model to learn specific output formats. Most production systems combine both: fine-tune for behavior and format, then RAG for current factual knowledge.
Data scientists focus on analysis, modeling, and insights — they explore data, build models in notebooks, and communicate findings to business stakeholders. Their output is typically a report, a model in a Jupyter notebook, or a dashboard. ML engineers focus on productionizing ML systems — building data pipelines, deploying models as APIs, monitoring production model performance, and maintaining infrastructure. Their output is running software. In practice, the distinction varies by company size: at startups, one person often does both; at large companies, these are separate roles. The ML engineer role typically requires stronger software engineering skills (Docker, Kubernetes, CI/CD, distributed systems) while the data scientist role requires stronger statistics and domain expertise.