Debasis Bhattacharjee

Word embeddings are dense numerical vectors representing words where semantically similar words have similar vectors. Word2Vec trains a neural network to predict surrounding words (skip-gram) or predict a word from its context (CBOW) — the learned weights become the word vectors.

Deep Dive: Traditional NLP represented words as one-hot vectors (10000-dimensional for a 10000-word vocabulary with a single 1 and all other 0s). These are high-dimensional sparse and have no semantic relationships — 'king' and 'queen' are just as different as 'king' and 'banana'. Word2Vec trains a shallow neural network on a large text corpus to either predict context words from a center word (skip-gram) or predict the center word from context words (CBOW). The weights learned for the hidden layer become the word vectors (typically 100-300 dimensions). The resulting vectors capture semantic relationships: king - man + woman ≈ queen. Similar words cluster together in vector space. GloVe (Global Vectors) is an alternative approach using word co-occurrence statistics. Modern LLMs use contextual embeddings (the same word has different vectors in different contexts) which are more powerful but require more compute.

Real-World: In a product recommendation system at an e-commerce company Word2Vec was trained on product purchase sequences (treating each purchase as a 'word' and each customer's purchase history as a 'sentence'). Products frequently bought together got similar embeddings. Recommendation became a nearest-neighbor search in embedding space — fast and semantically meaningful.

⚠ Common Mistakes: Confusing static word embeddings (Word2Vec GloVe — one vector per word) with contextual embeddings (BERT GPT — context-dependent vectors). Not handling out-of-vocabulary words in production (Word2Vec has no representation for words not in the training vocabulary — use subword models like FastText). Normalizing embeddings before cosine similarity comparison.

🏭 Production Scenario: A job matching platform trained Word2Vec on job descriptions and resumes treating skills as vocabulary. The model learned that 'React' and 'ReactJS' and 'React.js' map to nearby vectors even though they are different strings. This enabled matching across skill name variations that exact string matching would miss completely.

Follow-up questions: What is the difference between Word2Vec and BERT embeddings? What is FastText and how does it handle out-of-vocabulary words? What is the curse of dimensionality and how does it affect embedding space?

// ID: ML-INT-005  ·  DIFFICULTY: 5/10  ·  ★★★★★☆☆☆☆☆

Vectorized operations (using NumPy/pandas built-ins) operate on entire arrays at once in optimized C code. apply() calls a Python function row by row or column by column in pure Python. Vectorized operations are 10-1000x faster; use apply() only when no vectorized alternative exists.

Deep Dive: pandas is built on NumPy which stores data in contiguous memory arrays and performs operations in optimized C/FORTRAN code without Python overhead. When you write df['price'] * 1.1 NumPy multiplies the entire array in C. When you write df.apply(lambda x: x['price'] * 1.1 axis=1) Python calls a function for every single row — potentially millions of function calls with Python overhead each time. The performance gap is enormous: for a 1M row DataFrame vectorized operations might take 10ms while apply() takes 10-30 seconds. Use apply() only for: operations that cannot be expressed vectorially complex multi-column operations with conditional logic or when applying a function that expects a Series object.

Real-World: A daily sales report generation for a retail chain was taking 45 minutes to run on a 5M-row transaction DataFrame. Profiling revealed three apply() calls doing price calculations that could be rewritten as vectorized operations. Replacing them reduced runtime to 90 seconds — a 30x speedup with no algorithmic change.

⚠ Common Mistakes: Using apply() for simple arithmetic that pandas/NumPy can do natively. Using apply(axis=1) to iterate rows for anything that can be done with vectorized conditionals (use np.where instead). Not knowing about str accessor methods (df['col'].str.contains()) which provide vectorized string operations avoiding apply() entirely.

🏭 Production Scenario: A pandas ETL pipeline at a financial data company was processing end-of-day data and regularly missing the 6 AM business deadline. Profiling showed apply() calls for currency conversion and date parsing were the bottleneck. Replacing with vectorized arithmetic and pd.to_datetime() reduced the pipeline from 4 hours to 18 minutes.

Follow-up questions: What is the difference between apply() and applymap()? How does numpy.vectorize() differ from true vectorization? When should you use Polars instead of pandas?

// ID: PY-DS-001  ·  DIFFICULTY: 5/10  ·  ★★★★★☆☆☆☆☆

Type hints are annotations that specify expected types for variables function parameters and return values. They are ignored at runtime by default but used by static analysis tools (mypy pyright). Runtime enforcement requires libraries like Pydantic or beartype.

Deep Dive: Python's type system is gradual — you add hints progressively without breaking existing code. Basic syntax: def greet(name: str) -> str. Complex types: List[str] Dict[str int] Optional[str] (can be None) Union[int str] and in Python 3.10+ int | str. Generic types allow parameterized classes: class Stack(Generic[T]). TypeVar creates generic type variables. Protocol defines structural subtyping (duck typing with type safety). At runtime type hints are stored in __annotations__ and are just metadata — Python does not check them. mypy and pyright perform static analysis. Pydantic validates at runtime using type hints for data parsing and validation. beartype provides runtime type checking with minimal overhead.

Real-World: FastAPI's entire API surface is type-annotated — function parameter types define API request validation response model types define OpenAPI documentation and return type serialization. SQLAlchemy 2.0 uses type annotations for ORM model definitions. Both use the same type hints for static analysis AND runtime behavior.

⚠ Common Mistakes: Adding type hints to existing code and then being confused when it still fails at runtime (hints are not enforced by default). Using complex Union types when Optional (Union[X None]) is the common case. Not using TypedDict for dict structures with known keys (makes static analysis much more useful). Mixing legacy typing module types (List Dict) with modern built-in generics (list dict) available from Python 3.9+.

🏭 Production Scenario: A production data pipeline was passing incorrectly typed arguments silently for months because no type checking was in place. Adding mypy to the CI pipeline immediately surfaced 47 type errors. Fixing them prevented a class of bugs that had been causing occasional data corruption. Three of the errors would have caused production failures in the next quarter based on upcoming data changes.

Follow-up questions: What is the difference between mypy and pyright? What is TypedDict and when is it better than a dataclass? What is Protocol and how does it differ from ABC?

// ID: PY-ADV-004  ·  DIFFICULTY: 6/10  ·  ★★★★★★☆☆☆☆

A reliable LLM document processing pipeline requires structured output enforcement validation layers error handling for LLM failures chunking strategy for large documents and human-in-the-loop for low-confidence cases. Never assume a single LLM call gives a reliable result.

Deep Dive: Pipeline architecture: document ingestion (parse PDF/Word/images — use PyMuPDF pytesseract for OCR) → preprocessing (clean normalize extract metadata) → chunking (split into processable segments with overlap) → LLM extraction (prompt for structured output using JSON mode or function calling) → validation (check output format required fields data types business rules) → confidence scoring (if output is ambiguous or fields are missing flag for review) → human review queue (route low-confidence cases to humans) → output storage. Key reliability patterns: retry with exponential backoff on API errors use JSON mode/structured output to enforce output format validate all extracted fields against expected types and ranges implement idempotency (reprocessing a document produces the same result) and monitor extraction success rate and field-level accuracy over time.

Real-World: An insurance claims processing pipeline: PDFs are parsed with PyMuPDF → tables extracted with pdfplumber → Claude API extracts claim fields (date amount type claimant) in JSON mode → Pydantic validates the schema → business rules check (amount within policy limits date within claim period) → claims with validation errors or missing fields route to human reviewers → processed claims write to PostgreSQL with full audit trail.

⚠ Common Mistakes: Trusting LLM extraction without validation — LLMs occasionally miss fields hallucinate values or return malformed JSON. Not implementing retry logic for transient API failures. Processing documents sequentially instead of in parallel (rate limiting and concurrency are engineering challenges). Not storing the raw LLM output alongside the processed result making debugging impossible.

🏭 Production Scenario: A legal contract analysis pipeline was silently dropping 8% of documents due to PDF parsing failures that were caught but not logged. Another 3% had LLM extraction failures that returned empty results stored as valid empty extractions. Adding structured logging at every pipeline stage and distinguishing between 'processed successfully' and 'processing failed silently' revealed the data loss enabling fixes that recovered full accuracy.

Follow-up questions: How do you implement structured output with the Anthropic or OpenAI API? What is the difference between JSON mode and function calling for structured extraction? How do you evaluate extraction accuracy at scale?

// ID: AI-INT-006  ·  DIFFICULTY: 6/10  ·  ★★★★★★☆☆☆☆

A vector database stores high-dimensional vector embeddings and enables fast similarity search — finding the most similar vectors to a query. Traditional databases store structured data and query by exact matches or ranges. They solve fundamentally different problems.

Deep Dive: Traditional databases (PostgreSQL MySQL) store tabular data and query with exact or range conditions: WHERE price > 100 AND category = 'electronics'. Vector databases store dense numerical vectors (embeddings) — e.g. a 1536-dimensional vector representing a document's semantic meaning — and query for approximate nearest neighbors (ANN): find the 10 vectors most similar to this query vector using cosine similarity or Euclidean distance. Vector databases use specialized indexing algorithms for ANN search: HNSW (Hierarchical Navigable Small World) is the most common — it builds a multi-layer graph structure that enables fast approximate search with controllable precision-speed tradeoff. Popular options: Pinecone (fully managed) Weaviate (open-source multi-modal) Qdrant (Rust-based high performance) pgvector (PostgreSQL extension — adds vector search to a relational DB).

Real-World: A semantic document search system: documents are embedded into 1536-dimensional vectors using OpenAI's text-embedding-3-small. Vectors are stored in pgvector. When a user queries 'deadline for tax filing' the query is embedded and pgvector finds the 5 most similar document chunks — even if they never contain those exact words but discuss tax submission dates.

⚠ Common Mistakes: Confusing vector similarity with keyword matching — vector search finds semantically similar content not lexically similar. Not normalizing vectors before cosine similarity (unnormalized vectors give wrong similarity scores). Using exact kNN search (O(n) brute force) instead of ANN indexes for large datasets. Not filtering by metadata before vector search when you have a large multi-tenant dataset.

🏭 Production Scenario: A customer support RAG system was returning irrelevant results from other customers' document spaces because vector similarity search had no tenant isolation. Implementing metadata filtering (filter by tenant_id before ANN search) in Qdrant's payload filters fixed the security and relevance problem simultaneously.

Follow-up questions: What is HNSW and how does it enable fast approximate nearest neighbor search? What is the difference between cosine similarity and dot product for vector search? When should you use hybrid search (vector + keyword)?

// ID: AI-INT-005  ·  DIFFICULTY: 6/10  ·  ★★★★★★☆☆☆☆

Gradient boosting builds trees sequentially each correcting the errors of the previous. Random Forest builds trees in parallel independently. Gradient boosting typically achieves higher accuracy but is slower to train and more prone to overfitting if not carefully tuned.

Deep Dive: Gradient boosting is an ensemble method that builds trees one at a time with each new tree trained on the residual errors (the gradient of the loss function) of the combined previous trees. The final prediction is a weighted sum of all tree predictions. Because each tree is small (weak learner) and trained on residuals the ensemble gradually improves. Key implementations: XGBoost (adds regularization column subsampling parallel tree construction) LightGBM (leaf-wise growth instead of depth-wise extremely fast) CatBoost (native categorical feature handling symmetric trees). Random Forest: trees are independent any order each sees a bootstrap sample random feature subsets. Gradient boosting: trees are sequential each sees all data focused on hardest examples.

Real-World: Kaggle competitions are dominated by gradient boosting (XGBoost LightGBM) for tabular data problems. Industry production: credit scoring (LightGBM) click-through rate prediction (XGBoost at scale) fraud detection. When accuracy is critical and training time is not the primary constraint gradient boosting almost always outperforms Random Forest on structured data.

⚠ Common Mistakes: Not tuning learning_rate and n_estimators together (lower learning rate requires more trees). Ignoring early stopping — without it gradient boosting inevitably overfits. Not tuning max_depth (should be shallow 3-7) — deep trees cause overfitting. Using gradient boosting for non-tabular data (images text) where neural networks are appropriate.

🏭 Production Scenario: A price optimization model for an airline used Random Forest and achieved 0.79 AUC. Switching to LightGBM with tuned hyperparameters (learning_rate=0.05 2000 trees with early stopping) improved AUC to 0.86 translating to measurable revenue improvement in A/B testing.

Follow-up questions: What is the difference between XGBoost and LightGBM? What is early stopping in gradient boosting? What is the difference between gradient boosting and AdaBoost?

// ID: ML-INT-004  ·  DIFFICULTY: 6/10  ·  ★★★★★★☆☆☆☆

The Global Interpreter Lock (GIL) is a mutex that prevents multiple native threads from executing Python bytecode simultaneously. It makes Python threads unsuitable for CPU-bound parallelism.

Deep Dive: CPython (the standard Python implementation) uses reference counting for memory management. The GIL protects this reference counting from race conditions by ensuring only one thread executes Python code at a time. This means Python threads do NOT run in true parallel for CPU-bound tasks — they take turns. However the GIL is released during I/O operations (file reads network calls database queries) so threading IS effective for I/O-bound tasks. For true CPU parallelism use the multiprocessing module which spawns separate processes each with their own GIL or use libraries like NumPy that release the GIL in their C extensions.

Real-World: A web scraper using threading to fetch 100 URLs runs significantly faster with threads because most time is spent waiting for network I/O (GIL released). The same approach for parsing and processing 100 large JSON files (CPU-bound) would see no speedup from threading — multiprocessing or concurrent.futures ProcessPoolExecutor should be used instead.

⚠ Common Mistakes: Using threading for CPU-intensive tasks and being confused when there is no performance improvement. Assuming multiprocessing will always be better — it has high overhead for process spawning and IPC. Not considering asyncio for I/O-bound tasks which is more efficient than threading for high-concurrency scenarios.

🏭 Production Scenario: A production image processing service used Python threading expecting parallel image resizing. Performance was identical to single-threaded execution. The fix was switching to multiprocessing.Pool which reduced processing time by 75% on an 8-core server by actually utilizing all cores.

Follow-up questions: What is the difference between threading multiprocessing and asyncio? When does Python release the GIL? Does Jython or PyPy have a GIL?

// ID: PY-INT-003  ·  DIFFICULTY: 6/10  ·  ★★★★★★☆☆☆☆

FastAPI uses Python type hints to automatically generate API validation serialization and OpenAPI documentation. Production-ready additions include async database access dependency injection for auth middleware for logging/CORS rate limiting and health check endpoints.

Deep Dive: FastAPI is built on Starlette (ASGI framework) and Pydantic (data validation). You define endpoints as async functions with type-annotated parameters — FastAPI automatically validates inputs returns 422 for invalid data and generates Swagger UI documentation. Pydantic models define request/response schemas with validation. Dependency injection (Depends()) handles shared logic: database sessions authentication rate limiting. For production: use async ORMs (SQLAlchemy async Tortoise ORM) add middleware (CORS request logging timing) implement proper error handling with custom exception handlers add health check endpoints for load balancer probes use environment-based configuration (pydantic-settings) and containerize with uvicorn behind nginx.

Real-World: A production API for a fintech app: Pydantic models validate all financial amounts (positive correct decimal places) JWT authentication is injected via Depends() into protected routes a PostgreSQL database is accessed via async SQLAlchemy Prometheus middleware exports metrics and a /health endpoint returns database connectivity status for the load balancer.

⚠ Common Mistakes: Using synchronous database drivers with async FastAPI (blocks the event loop destroying performance). Not validating response models (can leak internal data). Forgetting to handle the database connection lifecycle — connections not closed properly exhaust the pool. Not implementing proper HTTP status codes — returning 200 for errors.

🏭 Production Scenario: A FastAPI service handling 500 req/s was experiencing periodic slowdowns. Investigation revealed synchronous calls to a third-party API inside async route handlers were blocking the event loop during each slow response. Replacing with httpx (async HTTP client) and proper timeout handling eliminated the slowdowns.

Follow-up questions: What is ASGI vs WSGI? How does Pydantic validation work under the hood? What is the difference between FastAPI and Flask for production APIs?

// ID: PY-INT-007  ·  DIFFICULTY: 6/10  ·  ★★★★★★☆☆☆☆

Zero-shot uses the base model with only instructions (no examples). Few-shot includes examples in the prompt. Fine-tuned models are retrained on domain data. The tradeoff is cost and flexibility versus consistency and performance.

Deep Dive: Zero-shot: just the task description in the prompt. Relies entirely on the model's pretraining. Fast to deploy requires no labeled data. Performance varies by task complexity. Best for: common well-defined tasks (summarization translation sentiment). Few-shot: include 3-10 task examples in the prompt. Dramatically improves consistency and format adherence. Cost: larger prompts = more tokens per call. Performance ceiling limited by context window and what can be communicated via examples. Best for: uncommon tasks new formats specific style requirements. Fine-tuned: domain-specific retraining. Bakes behavior into model weights instead of prompt tokens. Shorter prompts lower inference cost better consistency on trained tasks. Requires labeled data (minimum 100-1000 high-quality examples) compute for training. Not updatable without retraining. Best for: consistent structured output domain-specific terminology and behaviors classification with specific categories.

Real-World: A legal clause extraction system evolution: zero-shot (78% accuracy) → few-shot with 5 examples (86% accuracy) → few-shot with 20 examples (89% accuracy) → fine-tuned on 3000 examples (96% accuracy lower latency lower cost per call). Each step required more investment but delivered better ROI at the production volume they were operating at.

⚠ Common Mistakes: Jumping to fine-tuning before exhausting prompt engineering (expensive and inflexible). Using few-shot examples that are low quality or inconsistent — few-shot examples teach the model a behavior; bad examples teach bad behavior. Not measuring whether the performance gain justifies the cost of fine-tuning. Fine-tuning on a narrow task and breaking general capabilities (catastrophic forgetting).

🏭 Production Scenario: A startup building a document AI product started with zero-shot (fast prototype) discovered insufficient performance moved to few-shot (8 examples in prompt fixed 70% of failures) then fine-tuned only their highest-volume document type (processing 100K documents/month — fine-tuning ROI was clear) while keeping few-shot for lower-volume types. This staged approach minimized cost while maximizing quality where it mattered.

Follow-up questions: How do you measure whether fine-tuning improved over few-shot? What is instruction tuning and how is it different from task-specific fine-tuning? What is RLHF and how does it relate to fine-tuning?

// ID: AI-ADV-004  ·  DIFFICULTY: 7/10  ·  ★★★★★★★☆☆☆

Batch GD computes gradients on the entire dataset — slow but stable. Stochastic GD (SGD) computes gradients on one example — fast but noisy. Mini-batch GD computes on a subset (typically 32-256 examples) — balancing speed and stability. Mini-batch is the standard for deep learning.

Deep Dive: Batch gradient descent: compute loss and gradients across all training examples then update weights. Advantage: stable convergence guaranteed direction toward minimum. Disadvantage: extremely slow for large datasets (must process all data before updating) cannot fit large datasets in memory. SGD: compute gradient on one random example update weights immediately. Advantage: fast updates can escape local minima due to noise. Disadvantage: noisy updates cause loss to oscillate even near minimum hard to parallelize. Mini-batch: compromise — compute gradient on a random subset (batch size). Advantages: vectorized computation uses GPU parallelism efficiently noise helps escape local minima more stable than pure SGD. Batch size is a key hyperparameter: smaller batches (16-32) more noise better generalization larger batches (512-2048) more stable faster wall-clock time but may generalize worse (sharp vs flat minima research). Modern optimizers (Adam AdaGrad RMSprop) adapt learning rate per parameter addressing many SGD limitations.

Real-World: Training GPT-scale models: batch sizes of 2048-8192 tokens are used across hundreds of GPUs. The batch is distributed across GPUs (data parallelism) with gradients averaged across GPUs before weight updates. Learning rate warmup (gradual increase from 0) is used because large batch sizes are sensitive to initial learning rate choice.

⚠ Common Mistakes: Using batch size 1 (pure SGD) on modern GPU hardware — wastes parallelism. Not adjusting learning rate when changing batch size (linear scaling rule: if you double batch size double learning rate). Using a constant learning rate when training benefits from decay (use cosine annealing or linear decay). Not shuffling training data before each epoch causing the model to see data in the same order repeatedly.

🏭 Production Scenario: A production deep learning model was trained with batch size 4 because the researcher was worried about memory. Training took 72 hours. Using gradient accumulation (accumulate gradients over 32 steps before updating) achieved effectively batch size 128 without exceeding memory limits reducing training time to 18 hours with better final performance.

Follow-up questions: What is the learning rate warmup and why is it used? What is gradient accumulation and when do you use it? What is the difference between Adam and AdamW?

// ID: ML-ADV-004  ·  DIFFICULTY: 7/10  ·  ★★★★★★★☆☆☆