miércoles, 8 de abril de 2026

MLflow: Filosofía, Componentes y Arquitectura

MLflow: Filosofía, Componentes y Arquitectura

🔬 MLflow: Filosofía, Componentes y Arquitectura

📅 Fecha: 2025-04-08
✍️ Autor: Rommel Contreras
🏛️ Contexto: Laboratorio de IA
#mlflow #machine-learning #mlops #ia-governance

¿Qué es MLflow?

MLflow es una plataforma de código abierto para gestionar el ciclo de vida completo del machine learning, desde experimentación hasta producción.

En una frase: MLflow transforma el caos de entrenar modelos en un sistema ordenado, reproducible y auditable.

El problema que resuelve

Imagina que eres un científico de datos:

  1. Entrenas un modelo con 1000 hiperparámetros diferentes
  2. Olvidas qué valores usaste en el mejor modelo
  3. Tu colega ejecuta el mismo código, obtiene resultados diferentes
  4. El modelo funciona en tu laptop pero no en producción
  5. Pasan meses, quieres saber qué datos usaste
  6. No hay auditoría de quién cambió qué

MLflow resuelve todo esto.

Filosofía de MLflow

Principios fundamentales

Principio Significado Ejemplo
Reproducibilidad Mismo código = Mismo resultado, siempre Ejecutas en 2025 y 2030, obtienes exactamente el mismo AUC
Trazabilidad Registro completo de decisiones Sé exactamente qué datos, código y parámetros produjo el mejor modelo
Interoperabilidad Funciona con cualquier librería ML TensorFlow, PyTorch, Scikit-learn, XGBoost, en el mismo sistema
Governance Control de quién deployea qué Auditoría de modelos, aprobaciones, rechazos
Simplicidad Mínimo boilerplate Agregar 3 líneas de código a tu script existente

Antes vs Después de MLflow

Aspecto Sin MLflow Con MLflow
Tracking de resultados Excel + notas Dashboard automático
Reproducibilidad "Corre mi notebook entero" Un comando: mlflow run
Versionado de modelos Carpetas (model_v1, model_REAL) Registry con control de versiones
Comparación de experimentos Manual, memorizando números UI interactiva con gráficas
Deploy "Copiar el .pkl a producción" Pipeline automático con control de versiones
Auditoría No existe Quién, cuándo, qué, por qué

Los 4 componentes principales

MLflow consiste en 4 módulos independientes que puedes usar por separado o juntos:

┌─────────────────────────────────────────────────────────────┐ │ MLflow Platform │ ├─────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────┐ ┌──────────────┐ ┌──────────────┐ │ │ │ Tracking │ │ Projects │ │ Models │ │ │ │ │ │ │ │ │ │ │ │ • Loguear │ │ • Reproducir │ │ • Crear │ │ │ │ • Comparar │ │ • Empaquetar │ │ • Versionear│ │ │ │ • Visualizar │ │ • Colaborar │ │ • Servir │ │ │ └──────────────┘ └──────────────┘ └──────────────┘ │ │ │ │ ┌──────────────────────────────────────────────────────┐ │ │ │ Registry (Modelo Central) │ │ │ │ • Versionado • Transiciones de estado │ │ │ │ • Governance • Auditoría completa │ │ │ └──────────────────────────────────────────────────────┘ │ └─────────────────────────────────────────────────────────────┘

Tracking: Logging de experimentos

¿Qué es Tracking?

Tracking = Sistema automático para registrar todo lo que sucede durante el entrenamiento de un modelo.

Qué registra MLflow Tracking

Un "Experimento" (corrida de entrenamiento) registra: ┌─ Parámetros (inputs) │ ├─ learning_rate: 0.01 │ ├─ batch_size: 32 │ ├─ num_epochs: 100 │ └─ optimizer: "adam" │ ├─ Métricas (outputs que cambian) │ ├─ accuracy: [0.7, 0.75, 0.82, 0.88, 0.91] │ ├─ loss: [2.3, 2.1, 1.8, 1.5, 1.2] │ └─ val_accuracy: [0.69, 0.74, 0.80, 0.85, 0.88] │ ├─ Artefactos (archivos) │ ├─ model.pkl │ ├─ scaler.pkl │ └─ feature_importance.png │ ├─ Metadata │ ├─ Timestamp: 2025-04-08T14:30:00 │ ├─ Usuario: rommel │ └─ Git commit: abc123def456 │ └─ Fuente de código ├─ Script: train.py └─ Versión Python: 3.11

Ejemplo práctico en Python

import mlflow
from sklearn.ensemble import RandomForestClassifier
from sklearn.metrics import accuracy_score, f1_score

# 1. Iniciar un experimento
mlflow.set_experiment("agua_clasificacion_v1")

# 2. Comenzar una corrida (run)
with mlflow.start_run():
    # 3. Definir hiperparámetros
    params = {
        "n_estimators": 100,
        "max_depth": 10,
        "random_state": 42
    }
    
    # 4. Loguear parámetros
    mlflow.log_params(params)
    
    # 5. Entrenar modelo
    model = RandomForestClassifier(**params)
    model.fit(X_train, y_train)
    
    # 6. Hacer predicciones
    predictions = model.predict(X_test)
    
    # 7. Loguear métricas
    accuracy = accuracy_score(y_test, predictions)
    f1 = f1_score(y_test, predictions)
    
    mlflow.log_metric("accuracy", accuracy)
    mlflow.log_metric("f1_score", f1)
    
    # 8. Loguear artefactos
    mlflow.sklearn.log_model(model, "model")
    
    # 9. Agregar tags
    mlflow.set_tag("modelo_tipo", "RandomForest")
    mlflow.set_tag("dataset", "agua_ciudadanos_2025")

Projects: Reproducibilidad

¿Qué es un MLflow Project?

Un MLflow Project es una forma estándar de empaquetar código ML para que cualquiera pueda ejecutarlo de forma idéntica.

Estructura de un MLflow Project

mi_proyecto_agua/ ├── MLproject ← Manifest del proyecto ├── conda.yaml ← Dependencias Python ├── train.py ← Script de entrenamiento ├── evaluate.py ← Script de evaluación ├── data/ │ ├── ciudadanos.csv │ └── reportes.csv └── README.md

Ejecutar un MLflow Project

# Ejecutar localmente con parámetros por defecto
mlflow run . --experiment-name "agua_exp_001"

# Ejecutar con parámetros custom
mlflow run . \
  --experiment-name "agua_exp_001" \
  -P model_type="xgboost" \
  -P n_estimators=200

# Ejecutar desde GitHub
mlflow run https://github.com/tu-usuario/agua-ml.git \
  --experiment-name "agua_exp_001"

Models: Gestión del ciclo de vida

¿Qué son MLflow Models?

Un MLflow Model es una forma estándar de empaquetar cualquier modelo ML con toda su metadata y dependencias.

Loguear modelos de diferentes frameworks

import mlflow
import tensorflow as tf
import torch
from sklearn.ensemble import RandomForestClassifier

# 1. TensorFlow
mlflow.tensorflow.log_model(tf_model, "model_tf")

# 2. PyTorch
mlflow.pytorch.log_model(torch_model, "model_torch")

# 3. Scikit-learn
mlflow.sklearn.log_model(sklearn_model, "model_sklearn")

# 4. Custom (función Python personalizada)
def predict_custom(model_input):
    return model.predict(model_input)

mlflow.pyfunc.log_model("model_custom", python_model=predict_custom)

Cargar y usar un modelo logueado

import mlflow

# Opción 1: Cargar desde un run específico
model = mlflow.pyfunc.load_model("runs/abc123/artifacts/model")
predictions = model.predict(X_test)

# Opción 2: Cargar desde el Registry
model = mlflow.pyfunc.load_model("models:/agua_clasificador/production")

# Opción 3: Servir automáticamente (REST API)
mlflow models serve -m runs/abc123/artifacts/model -p 1234

Registry: Versionado y governance

¿Qué es el Model Registry?

El Model Registry es un repositorio central de modelos con control de versiones, transiciones de estado y auditoría.

Model Registry (Central) │ ├─ agua_clasificador (modelo 1) │ ├─ v1 [archived] │ ├─ v2 [archived] │ ├─ v3 [staging] ← En pruebas │ └─ v4 [production] ← En producción ⭐ │ ├─ agua_predictor (modelo 2) │ ├─ v1 [production] │ └─ v2 [staging] │ └─ electricidad_demanda (modelo 3) └─ v1 [development]

Estados de un modelo (Model Stage)

Stage Significado Quién lo decide Auditoría
None Sin asignar Usuario Creación
Staging En pruebas, validación Data Scientist Quién movió, cuándo
Production En uso activo Reviewer/ML Engineer Cuándo se deployó
Archived Retirado, legacy Administrador Razón de retiro

Registrar un modelo en el Registry

import mlflow
from mlflow.tracking import MlflowClient

# Opción 1: Desde un run existente
mlflow.register_model(
    model_uri="runs/abc123def456/artifacts/model",
    name="agua_clasificador"
)

# Opción 2: Dentro del entrenamiento
with mlflow.start_run():
    model = train()
    mlflow.sklearn.log_model(model, "model")
    
    # Registrar automáticamente
    mlflow.register_model(
        model_uri=f"runs/{mlflow.active_run().info.run_id}/artifacts/model",
        name="agua_clasificador"
    )

Transicionar entre estados

from mlflow.tracking import MlflowClient

client = MlflowClient()

# Pasar de Staging a Production
client.transition_model_version_stage(
    name="agua_clasificador",
    version=4,
    stage="Production",
    archive_existing_versions=True
)

# Agregar descripción
client.update_model_version(
    name="agua_clasificador",
    version=4,
    description="Random Forest con 95% accuracy. Deployado en Cumaná."
)

Comparativa: MLflow vs Alternativas

Matriz comparativa

Característica MLflow Weights & Biases Neptune Kubeflow DVC
Tracking de experimentos ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐
Reproducibilidad ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Model Registry ⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐
Costo ⭐⭐⭐⭐⭐ (Gratis) ⭐⭐ (Pago) ⭐⭐ (Pago) ⭐⭐⭐⭐ (Gratis) ⭐⭐⭐⭐⭐ (Gratis)
Control on-prem ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Facilidad de uso ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐

¿Por qué MLflow para tu laboratorio?

Razón Beneficio
Código abierto Control total, sin vendor lock-in
Standalone Funciona on-prem, sin internet requerido
Simple 3 líneas de código vs 50 líneas en Kubeflow
Multi-framework TensorFlow, PyTorch, Scikit-learn, XGBoost...
Bajo costo Gratis (contrario a Weights & Biases, Neptune)
Auditoría Importante para gobierno (rastreo completo)

Arquitectura para tu laboratorio

Stack recomendado: MLflow + Otras herramientas

┌─────────────────────────────────────────────────────────────────┐ │ Laboratorio de IA (Cumaná) │ ├─────────────────────────────────────────────────────────────────┤ │ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Datos (Entrada) │ │ │ │ ├─ PostgreSQL (datos ciudadanos, reportes) │ │ │ │ └─ MinIO (fotos, GeoJSON, archivos) │ │ │ └──────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Entrenamiento (MLflow Projects) │ │ │ │ ├─ train.py (código ML) │ │ │ │ ├─ MLproject (reproducibilidad) │ │ │ │ └─ conda.yaml (dependencias) │ │ │ └──────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Tracking (MLflow Tracking) │ │ │ │ ├─ Parámetros logged automáticamente │ │ │ │ ├─ Métricas (accuracy, F1, AUC) │ │ │ │ └─ Dashboard UI (http://localhost:5000) │ │ │ └──────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Model Registry (MLflow Registry) │ │ │ │ ├─ agua_clasificador v4 [production] │ │ │ │ ├─ agua_predictor v2 [staging] │ │ │ │ └─ electricidad_anomalía v1 [development] │ │ │ └──────────────────────────────────────────────────────────┘ │ │ ↓ │ │ ┌──────────────────────────────────────────────────────────┐ │ │ │ Deployment (MLflow Models) │ │ │ │ ├─ REST API (mlflow models serve) │ │ │ │ ├─ Batch predictions │ │ │ │ └─ Integración con Vercel/backend │ │ │ └──────────────────────────────────────────────────────────┘ │ │ │ └─────────────────────────────────────────────────────────────────┘

Configuración local de MLflow

# 1. Instalar MLflow
pip install mlflow

# 2. Crear directorio de almacenamiento
mkdir -p ~/mlflow_server
cd ~/mlflow_server

# 3. Iniciar server
mlflow server \
  --backend-store-uri sqlite:///mlflow.db \
  --default-artifact-root ./artifacts \
  --host 0.0.0.0 \
  --port 5000

# 4. Abrir navegador
# http://localhost:5000

Flujo práctico: De experimento a producción

Scenario: Clasificador de reportes de agua

PASO 1: Data Scientist inicia experimento
$ mlflow run . -P model_type=random_forest

✓ MLflow registra:
  - Parámetros: {"model_type": "random_forest"}
  - Métricas: {"accuracy": 0.92, "f1": 0.90}
  - Modelo: artifact/model
  - Timestamp: 2025-04-08 14:30:00
  - Usuario: rommel
PASO 2: Registrar en el Registry
from mlflow.tracking import MlflowClient

client = MlflowClient()
client.copy_model_version(
    src_model_uri="runs/abc123def456/artifacts/model",
    dst_model_name="agua_clasificador"
)

✓ Modelo registrado como "agua_clasificador" v1
PASO 3: Pasar a Staging para validación
client.transition_model_version_stage(
    name="agua_clasificador",
    version=1,
    stage="Staging"
)

✓ Modelo en Staging (pasa tests automáticos)
PASO 4: Aprobar y mover a Production
client.transition_model_version_stage(
    name="agua_clasificador",
    version=1,
    stage="Production",
    archive_existing_versions=True
)

✓ Modelo en Production (auditoría registrada)
PASO 5: Servir en producción
mlflow models serve \
  --model-uri models:/agua_clasificador/production \
  --port 8000

✓ Modelo sirviendo en REST API

MiNio un almacen de objetos de alto rendimiento

MinIO: Filosofía, Potencialidades y Comparativa

🗄️ MinIO: Filosofía, Potencialidades y Comparativa

📅 Fecha: 2025-04-08
✍️ Autor: Rommel Contreras
🏛️ Contexto: Laboratorio de Inteligencia Artificial
#object-storage #minio #cloud-native #civic-tech

Filosofía de MinIO

MinIO es un Object Store, no un filesystem tradicional. Esta es la distinción fundamental:

Aspecto Filesystem (Linux/Windows) MinIO (Object Store)
Estructura Árbol jerárquico de carpetas Bucket + Key (path plano)
"Carpetas" Reales, con permisos, metadatos Ilusión visual (prefijos)
Acceso Por ruta física Por identificador único (key)
Metadata Permisos, owner, timestamps Tags, content-type, custom metadata
Escalabilidad Limitada por estructura Millones de objetos sin límite

¿Por qué esto importa?

En un filesystem, cuando almacenas:

agua/reportes/2025/febrero/reporte.csv

El sistema crea realmente carpetas anidadas con inodos, permisos, y metadatos de cada nivel.

En MinIO, almacenas una key única:

agua/reportes/2025/febrero/reporte.csv

El "/" es solo delimitación visual. Internamente, MinIO lo trata como un identificador de cadena plano. Sin jerarquía, sin inodos, sin overhead.

Conceptos clave

1. Bucket

El contenedor raíz. Equivalente a un "drive" o "volumen":

Reglas inmutables:
  • Nombre único en toda la instancia MinIO
  • No pueden anidarse (no hay buckets dentro de buckets)
  • Todos los objetos viven en un bucket

2. Ruta / Key / Prefix

Es la ruta del objeto dentro del bucket:

agua/reportes/2025/febrero/reporte_20250408.csv
│     │         │    │       │
│     │         │    │       └─ Nombre del objeto
│     │         │    └─ Prefijo (subcarpeta virtual)
│     │         └─ Prefijo
│     └─ Prefijo
└─ Bucket

3. Artefacto = Objeto + Metadata

Un artefacto es:

Artefacto = Datos binarios + Metadata
Ejemplo en tu contexto:
  • Content-Type: text/csv
  • Size: 1,234,567 bytes
  • Created: 2025-04-08T10:30:00Z
  • ETag: "abc123def456" (detección de cambios)
  • Tags: estatus=confirmado, parroquia=pueblo-nuevo

Definición de rutas y artefactos

Estructura lógica recomendada

Para tu Monitor Situacional Cumaná:

monitor-cumaná/
├── agua/
│   ├── reportes/
│   │   ├── ciudadanos/
│   │   │   └── 2025/04/08/
│   │   │       ├── reporte_20250408_120000_cedula_12345678.csv
│   │   ├── institucional/
│   │   └── análisis/
│   ├── ciudadanos/
│   ├── fotos/
│   │   ├── daños/
│   │   └── reparaciones/
│   └── mapas/
├── electricidad/
├── salud/
└── auditoría/

Naming convention recomendada

Patrón general:

{categoria}/{subcategoría}/{tipo}_{timestamp}_{identificador}.{ext}

Ejemplos reales:

agua/reportes/ciudadanos/reporte_20250408_120530_cedula_12345678.csv
agua/reportes/institucional/resumen_20250408_mensual_aghes.xlsx
agua/mapas/pueblo_nuevo_20250101_v1.geojson
agua/fotos/daños/foto_20250408_153045_calle_mariño_sector1.jpg

Generación de rutas en código

Python (Flask)

from datetime import datetime

def generar_ruta_reporte(cedula, parroquia, estatus):
    timestamp = datetime.now().strftime("%Y%m%d_%H%M%S")
    bucket = "agua"
    prefix = f"reportes/ciudadanos/{parroquia}/{estatus}"
    key = f"{prefix}/reporte_{timestamp}_{cedula}.csv"
    return bucket, key

# Uso:
bucket, ruta = generar_ruta_reporte("12345678", "pueblo_nuevo", "sin_agua")
# Resultado: ("agua", "reportes/ciudadanos/pueblo_nuevo/sin_agua/reporte_20250408_120530_12345678.csv")

Node.js

function generarRutaReporte(cedula, parroquia, estatus) {
  const ahora = new Date();
  const timestamp = ahora.toISOString().replace(/[:\-T.]/g, '').slice(0, 15);
  const año = ahora.getFullYear();
  const mes = String(ahora.getMonth() + 1).padStart(2, '0');
  const dia = String(ahora.getDate()).padStart(2, '0');
  
  const prefix = `reportes/ciudadanos/${parroquia}/${estatus}/${año}/${mes}/${dia}`;
  return {
    bucket: 'agua',
    key: `${prefix}/reporte_${timestamp}_${cedula}.csv`
  };
}

Comparativa: MinIO vs Otros sistemas

Matriz comparativa: Potencialidades reales

Potencial MinIO AWS S3 Google Cloud Azure Blob Filesystem PostgreSQL MongoDB
Escalabilidad horizontal ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐
Costo a escala ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ ⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐⭐
Control total (on-prem) ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Compatibilidad S3 ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐ ⭐⭐
Consultas/indexación ⭐⭐ ⭐⭐ ⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐⭐
Transacciones ACID ⭐⭐⭐⭐⭐ ⭐⭐⭐
Versionado nativo ⭐⭐⭐⭐ ⭐⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐⭐⭐ ⭐⭐ ⭐⭐⭐ ⭐⭐⭐⭐

Potencialidades reales

1. Compatibilidad S3 = Portabilidad máxima ⭐ CRÍTICA

MinIO habla S3 nativamente. El mismo código funciona en MinIO, AWS S3, Google Cloud:

MinIO (local):

from minio import Minio
client = Minio('localhost:9000', access_key='minioadmin', secret_key='minioadmin')
client.put_object('agua', 'reporte.csv', stream, length)

AWS S3 (sin cambiar código):

from minio import Minio
client = Minio('s3.amazonaws.com', access_key='AWS_KEY', secret_key='AWS_SECRET')
client.put_object('agua', 'reporte.csv', stream, length)
Potencial real: Hoy usas MinIO on-prem. Mañana migras a AWS sin reescribir código. O ejecutas híbrido: datos locales + respaldo en cloud.

2. Control total del hardware = Costo predecible ⭐ CRÍTICA para Cumaná

Escenario MinIO AWS S3
5 MB/día × 365 días/año Costo disco fijo $1.38/año
1 TB acumulado (2 años) Costo disco fijo $276/año
10 TB acumulado (5 años) Costo disco fijo $2,760/año
En MinIO: El disco ya existe. El costo adicional es cero.

3. No hay "cold storage" delays

MinIO: todos los datos igual de rápidos, siempre.

AWS S3 tiene tiers:

  • Standard → ms de latencia (caro: $0.023/GB)
  • Infrequent Access → ms de latencia pero penalty por lectura
  • Glacier → horas (muy barato pero lento)
  • Deep Archive → 12 horas (más barato)

MinIO no penaliza archivos viejos. Un reporte de 2024 es igual de rápido que uno de hoy.

4. Edge computing / Replicación local

Cumaná central (cubagua) ↓ (replicación automática) Replica en Margarita ↓ Replica en Cariaco
Potencial:
  • Datos disponibles en múltiples ubicaciones
  • Redundancia automática
  • Sin costos de transferencia inter-región (MinIO) vs ~$0.02 por GB (AWS)

5. Versionado automático para auditoría

MinIO mantiene versiones de objetos:

# Habilitar versionado en bucket
mc version enable minio/agua

# Subir reporte_20250408.csv (versión 1)
# Luego subir reporte_20250408.csv (versión 2)
# Luego subir reporte_20250408.csv (versión 3)

# Listar todas las versiones
mc ls --versions minio/agua/reportes/
Ventajas:
  • Auditoría de cambios (quién cambió qué, cuándo)
  • Recuperación de errores
  • Compliance regulatorio

Matriz de decisión

📊 REPORTES CSV (ciudadanos, agua)
→ PostgreSQL (para consultas) + MinIO (para versionado/backup)
🖼️ IMÁGENES/FOTOS DE DAÑOS
→ MinIO (on-prem) o S3 (si presupuesto permite)
🗺️ GEOJSON/MAPAS VECTORIALES
→ PostgreSQL con PostGIS (para consultas geo) + MinIO (para versiones procesadas)
📝 LOGS DEL SISTEMA
→ Filesystem local (rápido) + MinIO (rotación nightly)
💾 BACKUPS COMPLETOS
→ MinIO (con versionado habilitado)
🔍 AUDITORÍA (quién cambió qué)
→ PostgreSQL (registros transaccionales)

Arquitectura recomendada para Cumaná

Stack full-stack para Monitor Situacional

┌──────────────────────────────────────────────┐ │ FRONTEND (Vercel) │ │ React + Next.js + TypeScript │ │ (Interfaz web, dashboards, reportes) │ └────────────────┬─────────────────────────────┘ │ API calls (HTTPS) │ ┌────────┴──────────────┐ ↓ ↓ ┌──────────────┐ ┌──────────────┐ │ PostgreSQL │ │ MinIO │ │ (Cloud) │ │ (On-prem) │ ├──────────────┤ ├──────────────┤ │ • Ciudadanos │ │ • Fotos │ │ • Reportes │ │ • GeoJSON │ │ • Auditoría │ │ • Backups │ │ • Consultas │ │ • Archivos │ │ • PostGIS │ │ • Versiones │ └──────────────┘ └──────────────┘ ↑ ↑ │ Sincronización bidireccional └───────────────────────┘

Flujo de datos

  1. Ciudadano reporta en Vercel
  2. Backend (Node.js) escribe en PostgreSQL
  3. Foto se almacena en MinIO: agua/fotos/daños/2025/04/08/foto_*.jpg
  4. CSV se sincroniza (cron cada 5 min): PostgreSQL → CSV → MinIO
  5. Dashboard en Vercel consulta estadísticas + fotos + mapas

Ventajas de esta arquitectura

Ventaja Beneficio
PostgreSQL en cloud Escalable, respaldos automáticos, acceso remoto
MinIO on-prem Control de datos, costo fijo, velocidad local
Vercel Deploy automático, CDN global, sin servidores
S3-compatible Portabilidad (mañana migras a AWS si quieres)
Replicable Cambias solo el bucket raíz y funciona en otra ciudad

Conclusión

¿Por qué MinIO para tu caso?

✅ Es PERFECTO porque:
  1. Soberanía de datos (eres gobierno, datos críticos)
  2. Costos predecibles (ya tienes hardware)
  3. Datos no estructurados (fotos, GeoJSON, archivos)
  4. Escalabilidad futura (replicar a otras ciudades)
  5. Portabilidad (si mañana necesitas migrar a S3)
  6. Versionado (auditoría de cambios)
  7. Desarrollo local sin internet (cubagua funciona off-grid)
⚠️ Pero necesitas TAMBIÉN:
  • PostgreSQL para consultas sobre ciudadanos
  • PostGIS para consultas geoespaciales
  • Elasticsearch (futuro) si necesitas búsqueda full-text
❌ NO necesitas:
  • MongoDB (tus datos son estructurados)
  • Elasticsearch (por ahora)
  • AWS/Google (soberanía de datos)

Comandos útiles

Instalar MinIO Client en WSL

$ curl https://dl.min.io/client/mc/release/linux-amd64/mc -o mc
$ chmod +x mc
$ sudo mv mc /usr/local/bin/

Configurar alias

$ mc alias set minio http://localhost:9000 minioadmin minioadmin

Operaciones básicas

$ mc mb minio/agua
$ mc cp reporte.csv minio/agua/reportes/
$ mc ls minio/agua/reportes/ciudadanos/
$ mc rm minio/agua/reportes/viejo.csv
$ mc rm --recursive minio/agua/2024/
$ mc mirror ./datos-locales minio/agua/respaldos/

martes, 7 de abril de 2026

El Procesamiento Cognitivo Humano

Mecanismos Responsables de las Funciones Cognitivas Superiores

Del Localizacionismo al Conectoma: La evolución del paradigma neurocientífico, transitando desde la visión del cerebro como un conjunto de áreas aisladas con funciones específicas, hacia la comprensión moderna de redes neuronales dinámicas e interconectadas.

  • Las Redes del Lenguaje: Los circuitos funcionales (vías dorsal y ventral) encargados de decodificar estímulos auditivos y visuales para la comprensión semántica, la articulación fonológica y la estructuración sintáctica de la comunicación.

  • Las Redes Atencionales: Los sistemas de control que gestionan el enfoque cognitivo, divididos entre la orientación voluntaria y sostenida hacia una tarea (red dorsal), y la reorientación automática ante estímulos inesperados o relevantes (red ventral).

  • Las Redes Afectivas y de Valoración: Las estructuras responsables de detectar estímulos, generar respuestas biológicas automáticas (emociones) y asignarles un valor subjetivo integrado (sentimientos) para guiar la conducta y la toma de decisiones.

  • Las Redes de la Memoria: Los mecanismos de codificación, consolidación y recuperación de la información, abarcando desde el almacenamiento a largo plazo (memoria declarativa y procedimental) hasta el espacio de manipulación temporal (memoria de trabajo).

  • La Plasticidad Neuronal: La capacidad celular y molecular del cerebro para reestructurarse físicamente a sí mismo, creando, fortaleciendo o eliminando conexiones sinápticas (espinas dendríticas) como respuesta directa a la experiencia y el aprendizaje.

  • La Emergencia de la Conciencia: El nivel más complejo de integración cerebral, donde el procesamiento unificado de la percepción, la atención, la emoción y la memoria da lugar a la experiencia subjetiva y al reconocimiento del propio estado mental.


1. El Procesamiento Cognitivo y la Evolución de la Neurociencia

Esta lámina visualiza la transición histórica desde el localizacionismo del siglo XIX hasta la comprensión moderna del conectoma y las redes neuronales dinámicas. ¿cómo el cerebro base de supervivencia se superpone con la "capa cognitiva superior"?

  • La capa de procesamiento cognitivo: El cerebro no solo responde a estímulos para el mantenimiento del cuerpo, sino que añade una capa compleja de procesamiento que permite interpretar la información, razonar y generar conductas elaboradas [00:52].

  • Enfoque Localizacionista (Siglo XIX): A partir del estudio de lesiones cerebrales, se estableció la idea de que áreas específicas del cerebro controlan funciones concretas [01:32]. Aunque este enfoque sentó las bases de la neurología clínica, hoy se considera una visión reduccionista del funcionamiento real del cerebro [05:06].

  • El Conectoma: El cerebro humano funciona mediante redes neuronales, entendidas como grupos de neuronas o áreas que se activan de forma coordinada [05:22]. Esta activación conjunta no implica necesariamente una unión física ininterrumpida entre los puntos [05:38].




2. Áreas Cerebrales Clave

Esta lámina es un "Mapa de Funciones" ilustrado que asigne iconos y miniescenas a cada una de las áreas clave detalladas en las notas, de manera similar a una lámina botánica decorativa.

  • Áreas de Asociación: No reciben señales sensitivas directas del exterior ni ejecutan respuestas motoras [02:06]. Su función es integrar e interpretar informaciones sensitivas (por ejemplo, el área parietooccipitotemporal) [02:24].

  • Corteza Prefrontal: Es la sede clave para las Funciones Ejecutivas [02:57]. Estas incluyen la memoria de trabajo, el control inhibitorio, la flexibilidad cognitiva, la planificación, el razonamiento y la resolución de problemas [02:57].

  • Área Fusiforme: Está especializada en la identificación de caras familiares y en discriminar rasgos faciales [03:12]. Su lesión provoca una incapacidad de reconocer rostros llamada prosopagnosia [03:21].

  • Ínsula: Integra información de tipo interoceptiva [03:35]. Participa en la conciencia visceral, la percepción del estado corporal interno, el dolor, la empatía y la valoración subjetiva [03:35].

  • Amígdala: Desempeña un papel central en el procesamiento emocional, especialmente en la detección de estímulos amenazantes, operando como "el detector del miedo" [03:51].

  • Hipocampo: Esencial para la formación y consolidación de la memoria declarativa, así como para la construcción de los recuerdos autobiográficos [04:06].

  • Giro Cingulado: Actúa como una interfaz o puente entre la cognición y la emoción [04:15]. Participa activamente en la evaluación de conflictos, la motivación y el control de la conducta [04:15].

  • Ganglios Basales: Implicados en la selección y automatización de acciones tanto cognitivas como motoras [04:28]. Son clave en el aprendizaje procedimental, la formación de hábitos y la toma de decisiones basada en recompensas (albergan las neuronas dopaminérgicas) [04:28].

  • Formación Reticular: Ubicada en el tronco del encéfalo, sus neuronas proyectan y modulan el nivel de activación cortical, regulando los estados de alerta y los ciclos de sueño-vigilia [04:51].




3. Dinámica y Organización de Redes

Esta lámina visualiza el flujo y la flexibilidad de la información entre la Segregación y la Integración. Verás cómo los módulos especializados se comunican a través de hubs y cómo el cerebro se reconfigura dinámicamente según la tarea.

  • Redes de Segregación: Módulos formados por nodos (grupos de neuronas) fuertemente conectados entre sí para ejecutar una función específica, como la red visual [06:15]. Permiten que los datos se procesen de forma rápida, eficiente y precisa, sin interferencias innecesarias [06:22].
  • Redes de Integración: Facilitan la comunicación y el intercambio entre distintos módulos especializados [06:44]. Utilizan nodos conectores ("hubs") para combinar información diversa y generar respuestas coherentes [06:59].
  • Flexibilidad Cerebral: La verdadera genialidad del cerebro reside en su capacidad para alternar de forma flexible entre modelos priorizando la segregación (para tareas automáticas) o la integración (para tareas que exigen gran carga cognitiva), según la situación [07:41]. El elemento central de la imagen: un "INTERRUPTOR DE FLEXIBILIDAD" o un cerebro que se "reconfigura". Un cerebro que oscila entre un estado de alta segregación (módulos aislados) y alta integración (una red global activa), según la demanda (tarea automática vs. tarea exigente).



Nota: Estas notas resumen el trabajo publicado en Youtube por la Dra. Noelia Valle, Bióloga de la Universidad Complutense de Madrid y Doctora en Ciencias por la Universidad Autónoma de Madrid.

Páginas

Entrada destacada

MLflow: Filosofía, Componentes y Arquitectura

MLflow: Filosofía, Componentes y Arquitectura 🔬 MLflow: Filosofía, Componentes y Arquit...

Entradas populares

Visitas: