Estas notas nacen de un transcript crudo. La idea no es fingir que el mapa mental ya está completo, sino convertir dudas sueltas en una libreta de aprendizaje que se pueda corregir. ML y MLOps tienen demasiados términos parecidos, así que conviene separar tres capas:
- Machine learning: cómo aprende un modelo a partir de datos.
- Deep learning: cómo redes neuronales grandes aprenden representaciones útiles usando muchos parámetros.
- MLOps: cómo se entrena, versiona, despliega, monitorea y vuelve a entrenar un modelo en sistemas reales.
Correcciones al mapa mental
Torch / PyTorch. Cuando digo “Torch”, normalmente hoy me refiero a PyTorch: un framework open source de deep learning usado para construir modelos, entrenarlos y llevarlos a producción. torch también es el nombre del paquete principal en Python. La corrección importante: no es solo “un framework de machine learning”, sino una librería de tensores, autograd y redes neuronales que hace práctica la optimización en CPU y GPU.
Sigmoid y ReLU. Las funciones de activación no “colapsan los outputs” en general. Lo que hacen es transformar la señal intermedia de una neurona para introducir no linealidad. Sin activaciones, muchas capas lineales se comportarían como una sola transformación lineal.
La sigmoid aplasta cualquier número real al rango entre 0 y 1:
Eso la vuelve útil para interpretar salidas como probabilidades en clasificación binaria, pero también puede saturarse: cuando los valores son muy grandes o muy negativos, el gradiente se vuelve pequeño y el aprendizaje se frena. ReLU es más simple:
ReLU deja pasar valores positivos y corta valores negativos en cero. Es popular porque ayuda a entrenar redes profundas, aunque también puede producir “neuronas muertas” si una unidad queda siempre en la zona cero. Si voy a explicar activaciones, sí: hay que graficarlas. La forma de la curva dice mucho sobre cómo fluye la señal y cómo fluyen los gradientes.
Función de costo, loss y OLS. La intuición de mínimos cuadrados ordinarios es correcta: entrenar muchos modelos significa buscar parámetros que minimicen algún error. Pero conviene distinguir términos. La loss mide el error en una observación o batch; la cost function u objetivo suele agregar la loss sobre el dataset y puede incluir regularización. OLS es un caso particular: minimiza la suma de errores cuadrados. En ML la función objetivo cambia según la tarea: cross-entropy para clasificación, MSE para regresión, contrastive loss para embeddings, etc.
Descenso de gradiente. “Gradient descent” no es solo “ir hacia abajo”. Es usar la derivada de la función objetivo respecto a los parámetros para saber en qué dirección mover pesos y sesgos. La actualización básica es:
Aquí theta representa parámetros, J la función objetivo, y alpha el learning rate. Si alpha es demasiado grande, brincas sobre el mínimo. Si es demasiado pequeño, aprendes lento. Cuando digo “aprendizaje”, en este contexto estoy diciendo: encontrar pesos y sesgos que reduzcan el objetivo en datos de entrenamiento y que generalicen a datos nuevos.
Pesos y sesgos. Los pesos controlan qué tan fuerte pasa una señal de una capa a otra. Los sesgos desplazan la activación. Los parámetros no se escogen a mano: se inicializan, se actualizan por optimización y terminan codificando patrones estadísticos del dataset.
Query, key y value. En atención no basta recordar “key y query”. Falta value. Una forma útil de pensarlo:
query: lo que una posición está buscando.key: lo que cada posición ofrece para ser encontrada.value: la información que se copia cuando hubo match.
La atención calcula compatibilidad entre queries y keys, la normaliza con softmax y usa esos pesos para mezclar values. En transformers, este mecanismo permite que cada token mire otros tokens relevantes dentro del contexto.
Feature engineering, no “Fisher engineering”. El término correcto es feature engineering. No se trata de encontrar “labels” relevantes. Los features son variables de entrada; los labels son el objetivo que quieres predecir. Feature engineering es crear, seleccionar, transformar o limpiar features para que el modelo vea señales útiles. En deep learning, parte de ese trabajo lo aprende la red internamente, pero en datos tabulares, series de tiempo y sistemas de negocio, feature engineering sigue siendo una ventaja enorme.
Hyperparameter tuning. Los hiperparámetros son decisiones que no aprende directamente el modelo por gradiente: learning rate, batch size, número de capas, hidden units, regularización, optimizer, dropout, epochs. “Hidden layers” puede ser un hiperparámetro, pero no es todo el tuning. El tuning busca configuraciones que mejoren la métrica de validación sin sobreajustar.
Tiempo de entrenamiento. No se entrena por “cierto tiempo” de manera arbitraria. Se entrena por epochs, steps, presupuesto de cómputo o hasta que una métrica de validación deje de mejorar. Si entrenas poco, el modelo queda underfit. Si entrenas demasiado, puede overfit. Por eso aparecen early stopping, checkpoints, validation splits y curvas de entrenamiento.
Dónde entra MLOps
MLOps empieza cuando el modelo deja de ser un notebook y se vuelve un sistema. El ciclo se parece a esto:
- Capturar y versionar datos.
- Preparar features y datasets reproducibles.
- Entrenar modelos.
- Registrar parámetros, métricas y artefactos.
- Evaluar contra un baseline.
- Registrar versiones del modelo.
- Desplegar a batch, API o edge.
- Monitorear drift, calidad, latencia, costo y errores.
- Reentrenar cuando cambian los datos o el producto.
Si el transcript decía “You Flow”, probablemente la palabra era Kubeflow o MLflow. No son lo mismo. Kubeflow ayuda a correr pipelines de ML sobre Kubernetes; un pipeline declara componentes, orden de ejecución, dependencias y flujo de datos. MLflow está más enfocado en tracking de experimentos, modelos, registry, evaluación, despliegue y, más recientemente, observabilidad para LLMs y agentes. En un stack real pueden convivir: Kubeflow orquesta; MLflow registra y gobierna artefactos.
GPU, entrenamiento e inferencia
La GPU acelera operaciones que se pueden paralelizar: multiplicaciones de matrices, convoluciones, atención, forward passes y backward passes. En entrenamiento, la GPU sirve en el forward pass para producir predicciones, en el backward pass para calcular gradientes y en la actualización para mover parámetros. En fine-tuning pasa algo parecido, aunque puede limitarse a menos parámetros si usas métodos como LoRA.
En inferencia también sirve. Un modelo ya entrenado no calcula gradientes, pero sigue haciendo muchas operaciones tensoriales para producir logits, probabilidades, embeddings o tokens. En LLMs, la inferencia puede ser cara por la atención, el tamaño del contexto y la generación token por token.
La GPU no es la fuente conceptual de “resultados aleatorios”. La aleatoriedad viene de muestrear una distribución de probabilidad. Un LLM produce logits; esos logits se convierten en probabilidades; luego el runtime puede elegir el token más probable o muestrear con temperatura, top-k, top-p y seed. Aún con temperatura cero puede haber pequeñas diferencias por kernels no deterministas, paralelismo numérico o diferencias de hardware, pero la idea central es: el modelo emite distribuciones, y la política de decoding decide qué tan aleatoria se vuelve la salida.
Prompt engineering y agentes
Prompt engineering no es solo redactar bonito. Es diseñar contexto, ejemplos, restricciones, formatos de salida, criterios de éxito y rutas de recuperación. En modelos frontera, las técnicas útiles suelen ser:
- instrucciones claras y jerárquicas;
- few-shot examples cuando el formato importa;
- contexto recuperado con trazabilidad;
- structured outputs cuando otro sistema va a consumir la respuesta;
- tool calling cuando el modelo necesita actuar fuera del texto;
- evals para medir si el prompt sigue funcionando.
Para flujos agente, structured outputs y function calling son casi obligatorios. Un agente que solo responde texto es difícil de operar. Un agente útil necesita estado, herramientas, permisos, observabilidad, retries, evaluaciones y límites. El truco es no pedirle al modelo que “sea confiable” por personalidad; hay que construir un sistema donde sus grados de libertad estén acotados.
Mapa actual de Google
Los nombres de producto de Google cambian mucho, así que los anoto como mapa funcional, no como taxonomía eterna. Última verificación: 2026-07-08.
- Google AI Studio: lugar rápido para probar Gemini, prompts, contexto largo y prototipos.
- Gemini API: API para integrar modelos Gemini en aplicaciones.
- Gemini Enterprise Agent Platform: plataforma para construir, desplegar, escalar, monitorear y gobernar agentes.
- Agent Development Kit (ADK): framework code-first y open source para construir agentes con herramientas, sesiones y despliegue.
- CX Agent Studio / Conversational Agents: capa orientada a agentes conversacionales para customer experience.
- Agent Assist: asistencia en tiempo real para representantes humanos.
- CX Insights: analítica, calidad y supervisión sobre conversaciones.
- Dialogflow CX: plataforma de NLU y control conversacional que sigue siendo relevante, especialmente en flujos conversacionales más estructurados.
La distinción práctica: AI Studio sirve para prototipar; ADK sirve para construir agentes en código; Agent Platform sirve para llevarlos a producción; CX Agent Studio, Agent Assist, CX Insights y Dialogflow viven más cerca de contact centers y customer engagement.
Preguntas abiertas para la siguiente nota
La siguiente vuelta debería aterrizar estas preguntas:
- Cuál es la diferencia operacional entre entrenamiento, fine-tuning, RAG e inferencia.
- Cómo se ve un pipeline mínimo con datos, entrenamiento, registry, deploy y monitoreo.
- Qué métricas importan para modelos tradicionales vs agentes.
- Cómo se elige entre MLflow, Kubeflow, Airflow, Prefect o un pipeline casero.
- Qué significa reproducibilidad en ML cuando hay datos cambiantes, GPUs y muestreo estocástico.
Por ahora el mapa correcto es: aprender ML no es memorizar nombres de frameworks. Es entender que un modelo es una función parametrizada, que entrenar es optimizar parámetros, que inferir es ejecutar esa función sobre entradas nuevas, y que MLOps es la disciplina de hacer que todo eso sea repetible, observable y útil en producción.