These notes start from a raw transcript. The point is not to pretend the mental map is already complete, but to turn loose doubts into a learning notebook that can be corrected. ML and MLOps have too many similar terms, so it helps to separate three layers:
- Machine learning: how a model learns from data.
- Deep learning: how large neural networks learn useful representations with many parameters.
- MLOps: how a model is trained, versioned, deployed, monitored, and retrained inside real systems.
Corrections to the mental map
Torch / PyTorch. When I say “Torch”, today I usually mean PyTorch: an open source deep learning framework used to build models, train them, and move them toward production. torch is also the name of the main Python package. The important correction: it is not merely “a machine learning framework”, but a tensor, autograd, and neural network library that makes optimization practical on CPUs and GPUs.
Sigmoid and ReLU. Activation functions do not generally “collapse outputs”. They transform the intermediate signal of a neuron to introduce nonlinearity. Without activations, many linear layers would behave like a single linear transformation.
Sigmoid squashes any real number into the range between 0 and 1:
That makes it useful when interpreting outputs as probabilities in binary classification, but it can also saturate: when values are very large or very negative, the gradient becomes small and learning slows down. ReLU is simpler:
ReLU passes positive values through and cuts negative values to zero. It is popular because it helps train deep networks, although it can also create “dead neurons” if a unit stays forever in the zero region. If I am going to explain activations, yes: I should graph them. The shape of the curve says a lot about how signal and gradients flow.
Cost function, loss, and OLS. The ordinary least squares intuition is correct: training many models means searching for parameters that minimize some error. But the terms should be separated. The loss measures error on one observation or batch; the cost function or objective usually aggregates loss across the dataset and may include regularization. OLS is a special case: it minimizes the sum of squared errors. In ML, the objective changes with the task: cross-entropy for classification, MSE for regression, contrastive loss for embeddings, and so on.
Gradient descent. Gradient descent is not just “going downward”. It uses the derivative of the objective function with respect to the parameters to know which direction to move weights and biases. The basic update is:
Here theta represents parameters, J the objective function, and alpha the learning rate. If alpha is too large, you jump over the minimum. If it is too small, you learn slowly. When I say “learning” in this context, I mean: finding weights and biases that reduce the objective on training data and generalize to new data.
Weights and biases. Weights control how strongly a signal passes from one layer to another. Biases shift the activation. Parameters are not chosen by hand: they are initialized, updated through optimization, and eventually encode statistical patterns from the dataset.
Query, key, and value. In attention it is not enough to remember “key and query”. Value is missing. A useful way to think about it:
query: what a position is looking for.key: what each position offers so it can be found.value: the information copied when there is a match.
Attention computes compatibility between queries and keys, normalizes it with softmax, and uses those weights to mix values. In transformers, this mechanism lets each token look at other relevant tokens inside the context.
Feature engineering, not “Fisher engineering”. The correct term is feature engineering. It is not about finding relevant “labels”. Features are input variables; labels are the target you want to predict. Feature engineering means creating, selecting, transforming, or cleaning features so the model sees useful signals. In deep learning, part of that work is learned by the network internally, but for tabular data, time series, and business systems, feature engineering remains a huge advantage.
Hyperparameter tuning. Hyperparameters are decisions the model does not learn directly through gradients: learning rate, batch size, number of layers, hidden units, regularization, optimizer, dropout, epochs. “Hidden layers” can be a hyperparameter, but it is not all of tuning. Tuning searches for configurations that improve validation metrics without overfitting.
Training time. You do not train for “some amount of time” arbitrarily. You train for epochs, steps, compute budget, or until a validation metric stops improving. If you train too little, the model is underfit. If you train too much, it can overfit. That is why early stopping, checkpoints, validation splits, and training curves exist.
Where MLOps enters
MLOps starts when the model stops being a notebook and becomes a system. The cycle looks like this:
- Capture and version data.
- Prepare reproducible features and datasets.
- Train models.
- Log parameters, metrics, and artifacts.
- Evaluate against a baseline.
- Register model versions.
- Deploy to batch, API, or edge.
- Monitor drift, quality, latency, cost, and errors.
- Retrain when data or the product changes.
If the transcript said “You Flow”, the word was probably Kubeflow or MLflow. They are not the same. Kubeflow helps run ML pipelines on Kubernetes; a pipeline declares components, execution order, dependencies, and data flow. MLflow is more focused on experiment tracking, models, registry, evaluation, deployment, and more recently observability for LLMs and agents. In a real stack they can coexist: Kubeflow orchestrates; MLflow records and governs artifacts.
GPU, training, and inference
The GPU accelerates operations that can be parallelized: matrix multiplications, convolutions, attention, forward passes, and backward passes. In training, the GPU helps during the forward pass to produce predictions, during the backward pass to compute gradients, and during updates to move parameters. Fine-tuning is similar, although it can be limited to fewer parameters if you use methods like LoRA.
It also helps during inference. A trained model no longer computes gradients, but it still performs many tensor operations to produce logits, probabilities, embeddings, or tokens. In LLMs, inference can be expensive because of attention, context size, and token-by-token generation.
The GPU is not the conceptual source of “random results”. Randomness comes from sampling a probability distribution. An LLM produces logits; those logits become probabilities; then the runtime can choose the most likely token or sample with temperature, top-k, top-p, and seed. Even with temperature zero, there can be small differences from nondeterministic kernels, numeric parallelism, or hardware differences, but the core idea is: the model emits distributions, and the decoding policy decides how random the output becomes.
Prompt engineering and agents
Prompt engineering is not just writing nicely. It is designing context, examples, constraints, output formats, success criteria, and recovery paths. For frontier models, useful techniques usually include:
- clear and hierarchical instructions;
- few-shot examples when format matters;
- retrieved context with traceability;
- structured outputs when another system will consume the response;
- tool calling when the model needs to act outside text;
- evals to measure whether the prompt still works.
For agent flows, structured outputs and function calling are almost mandatory. An agent that only replies with text is hard to operate. A useful agent needs state, tools, permissions, observability, retries, evaluations, and limits. The trick is not to ask the model to “be reliable” as a personality trait; it is to build a system where its degrees of freedom are constrained.
Current Google map
Google product names move a lot, so I am writing these as a functional map, not as an eternal taxonomy. Last checked: 2026-07-08.
- Google AI Studio: a fast place to try Gemini, prompts, long context, and prototypes.
- Gemini API: the API for integrating Gemini models into applications.
- Gemini Enterprise Agent Platform: a platform to build, deploy, scale, monitor, and govern agents.
- Agent Development Kit (ADK): an open source, code-first framework for building agents with tools, sessions, and deployment.
- CX Agent Studio / Conversational Agents: the layer oriented toward conversational agents for customer experience.
- Agent Assist: real-time assistance for human representatives.
- CX Insights: analytics, quality, and supervision over conversations.
- Dialogflow CX: an NLU and conversational control platform that remains relevant, especially for more structured conversational flows.
The practical distinction: AI Studio is for prototyping; ADK is for building agents in code; Agent Platform is for taking them to production; CX Agent Studio, Agent Assist, CX Insights, and Dialogflow live closer to contact centers and customer engagement.
Open questions for the next note
The next pass should land these questions:
- What is the operational difference between training, fine-tuning, RAG, and inference.
- What a minimal pipeline looks like with data, training, registry, deploy, and monitoring.
- Which metrics matter for traditional models versus agents.
- How to choose between MLflow, Kubeflow, Airflow, Prefect, or a custom pipeline.
- What reproducibility means in ML when data changes and GPUs and stochastic sampling are involved.
For now, the correct map is: learning ML is not memorizing framework names. It is understanding that a model is a parameterized function, that training optimizes parameters, that inference executes that function on new inputs, and that MLOps is the discipline of making all of that repeatable, observable, and useful in production.