Saltar al contenido
Henry Rincón
CV (PDF)

Métodos · Tema T8

Cómo se debe decidir con modelos

Se imprime completa desde el navegador, en A4 o en carta.

Bloque 1

El problema

Decidir con modelos sin engañarse: que cada modelo supere una línea base, se valide como lo enfrentará la operación, llegue con sus límites a quien decide y se vigile después de entregarlo, y que la optimización se formule de modo que su resultado se pueda verificar.

Síntesis en tres líneas

  1. El problema nace del proceso: qué se anticipa, sobre qué unidad, con cuánta anticipación y qué decisión cambia con el resultado; y antes del algoritmo, la línea base que el modelo tiene que superar.
  2. El modelo se valida como lo enfrentará la operación —orden temporal, prueba sin fuga, error por segmento— y llega con su ficha y sus límites a quien decide, que recibe una señal y no una decisión.
  3. Cuando la pregunta es qué elegir y no qué pasará, el problema se formula como optimización, dos veces, y se simula bajo variabilidad; y todo modelo publicado se vigila, porque la deriva no avisa.
Bloque 2

El mapa

Del problema del proceso a la decisión vigilada

Desliza para ver el mapa completo.

Del problema del proceso a la decisión vigiladaEl dueño de la decisión define el problema y su horizonte; primero se fija la línea base y después se construyen las variables con lo que existe a tiempo. El modelo candidato se valida en orden temporal y se mide en una prueba sin fuga; sus errores se leen por segmento, se escriben en la ficha del modelo y la predicción se entrega donde se decide. Quien decide recibe una señal; cuando la pregunta es qué elegir, entra la optimización, y la simulación aporta escenarios a lo que se entrega. En operación, la vigilancia de la deriva avisa al dueño de la decisión.Dueño de ladecisión1Problema yhorizonte2Línea base3Variables atiempo4Modelo candidato5Orden temporal6Prueba sin fuga7Errores porsegmento8La ficha delmodelo9Entrega donde sedecide10Quien decide11Vigilancia yderiva12Optimización13Simulación14

Leyenda de formas y colores

  • Actor — quien hace el trabajo
  • Dato — lo que se guarda y se lee
  • Control — una regla que se comprueba
  • Persona — una persona decide
  • Externo — lo que viene de afuera

Lectura del mapa, nodo por nodo

El dueño de la decisión define el problema y su horizonte; primero se fija la línea base y después se construyen las variables con lo que existe a tiempo. El modelo candidato se valida en orden temporal y se mide en una prueba sin fuga; sus errores se leen por segmento, se escriben en la ficha del modelo y la predicción se entrega donde se decide. Quien decide recibe una señal; cuando la pregunta es qué elegir, entra la optimización, y la simulación aporta escenarios a lo que se entrega. En operación, la vigilancia de la deriva avisa al dueño de la decisión.

  1. Nodo 1 Dueño de la decisión (Persona) — Quien responde por la decisión que el modelo debe mejorar y fija qué error cuesta más.
  2. Nodo 2 Problema y horizonte (Control) — Qué se anticipa, sobre qué unidad, con cuánta anticipación y qué decisión puede cambiar con el resultado.
  3. Nodo 3 Línea base (Control) — Una regla simple, una media histórica o la forma actual de decidir: lo que el modelo tiene que superar.
  4. Nodo 4 Variables a tiempo (Dato) — Solo lo que existe en el momento de predecir: nada del futuro filtrado al entrenamiento.
  5. Nodo 5 Modelo candidato (Actor) — Los modelos compiten con el mismo preprocesamiento y se eligen por su error, no por su novedad.
  6. Nodo 6 Orden temporal (Control) — Se entrena con el pasado y se mide sobre periodos posteriores, como lo enfrentará la operación.
  7. Nodo 7 Prueba sin fuga (Control) — Las métricas salen de datos que el entrenamiento no vio, con el preprocesamiento ajustado solo en entrenamiento.
  8. Nodo 8 Errores por segmento (Dato) — La matriz de confusión, el error por ruta, clase o grupo y lo que cuesta cada tipo de error.
  9. Nodo 9 La ficha del modelo (Dato) — Datos, partición, método, métricas, veredicto frente a la línea base y límites, escritos.
  10. Nodo 10 Entrega donde se decide (Actor) — La predicción llega con su contexto al tablero o al informe que ya se usa, antes de que la decisión se cierre.
  11. Nodo 11 Quien decide (Persona) — Recibe una señal, no una decisión: prioriza, revisa y responde por la acción.
  12. Nodo 12 Vigilancia y deriva (Control) — Entradas, distribución, desempeño, uso e impacto, vigilados después de publicar y no solo antes.
  13. Nodo 13 Optimización (Actor) — El mismo problema como programación entera y como programación por restricciones: los óptimos deben coincidir.
  14. Nodo 14 Simulación (Actor) — Compara políticas y asignaciones bajo variabilidad antes de intervenir la operación.

Conexiones

  • de Dueño de la decisión a Problema y horizonte (define)
  • de Problema y horizonte a Línea base (primero)
  • de Línea base a Variables a tiempo (después)
  • de Variables a tiempo a Modelo candidato (entrena)
  • de Modelo candidato a Orden temporal (se valida)
  • de Orden temporal a Prueba sin fuga (se mide)
  • de Prueba sin fuga a Errores por segmento (muestra)
  • de Errores por segmento a La ficha del modelo (se escribe)
  • de La ficha del modelo a Entrega donde se decide (se entrega)
  • de Entrega donde se decide a Quien decide (informa)
  • de Quien decide a Vigilancia y deriva (en operación)
  • de Vigilancia y deriva a Dueño de la decisión (avisa)
  • de Quien decide a Optimización (si hay que elegir)
  • de Optimización a Simulación (bajo variabilidad)
  • de Simulación a Entrega donde se decide (aporta escenarios)
Bloque 3

Las fases

  1. Fase 1

    Formular el problema desde la decisión

    Entradas

    • La decisión que se quiere mejorar y quien responde por ella.
    • El proceso, sus eventos y la forma actual de decidir.

    Actividades

    • Definir el fenómeno, la unidad de análisis y el horizonte de predicción frente al de decisión.
    • Fijar la línea base y el costo de cada tipo de error antes de entrenar.
    • Decidir si la pregunta es anticipar o elegir: predicción u optimización.

    Artefactos

    • La definición del problema: fenómeno, unidad, horizonte y decisión.
    • La línea base escrita.
    Quién decide
    El dueño de la decisión.
    Control que cierra la fase
    Ningún modelo se entrena sin una línea base y sin una decisión que su resultado pueda cambiar.
    Evidencia

    En TransMilenio la unidad era la ruta en una franja horaria de un tipo de día, con un horizonte mensual: la programación del mes siguiente se decide antes de que ese mes empiece, y una predicción que llegara después no servía.

  2. Fase 2

    Construir las variables con lo que existe a tiempo

    Entradas

    • Los eventos, estados y fuentes del proceso.
    • El momento exacto en que se producirá cada predicción.

    Actividades

    • Construir cada variable con un significado, una fuente, una ventana temporal y su relación con la unidad.
    • Descartar lo que solo aparece después del evento que se quiere anticipar.
    • Usar en la inferencia la misma transformación que en el entrenamiento.

    Artefactos

    • El conjunto de variables con su fuente y su ventana.
    • Las reglas de transformación versionadas.
    Quién decide
    Quien construye el modelo, con quien conoce el proceso.
    Control que cierra la fase
    Ninguna variable entra si no puede calcularse antes del evento objetivo.
    Evidencia

    En Banco Pichincha cada variable tenía que poder calcularse con la información disponible antes del evento: un modelo de mora que usa información posterior al impago es perfecto en el laboratorio e inútil en operación.

  3. Fase 3

    Validar como lo enfrentará la operación

    Entradas

    • Los modelos candidatos y la línea base.
    • Periodos posteriores a los que el modelo vio.

    Actividades

    • Medir sobre periodos posteriores, nunca con una partición al azar en un problema temporal.
    • Leer la matriz de confusión y el error por segmento, no solo la métrica global.
    • Revisar la calibración cuando la salida se usa como probabilidad.

    Artefactos

    • El veredicto frente a la línea base.
    • El mapa de errores por segmento.
    Quién decide
    El dueño de la decisión, con quien construye el modelo.
    Control que cierra la fase
    Un modelo que no supera la línea base no pasa, y el veredicto lo dice.
    Evidencia

    En TransMilenio un buen promedio podía esconder errores en los segmentos críticos: acertar en la mayoría de las rutas de baja demanda y fallar en las troncales de hora pico es un buen promedio y una mala predicción.

  4. Fase 4

    Entregar donde se decide, con la ficha del modelo

    Entradas

    • El modelo aprobado, su ficha y sus límites.
    • El tablero, el informe o el flujo que ya usa quien decide.

    Actividades

    • Presentar la predicción con el contexto que permite interpretarla.
    • Conservar la fecha, la versión, los datos y la población de cada predicción.
    • Definir qué pasa cuando los datos de entrada no cumplen lo esperado.

    Artefactos

    • La predicción en el producto que ya se usa.
    • El registro que permite reconstruir cada predicción.
    Quién decide
    Quien decide, con el dueño del producto analítico.
    Control que cierra la fase
    Ninguna predicción llega sin contexto ni después de que la decisión se cierre.
    Evidencia

    En Banco Pichincha las predicciones llegaban por Power BI, junto con la información histórica y contextual del cliente, a los mismos tableros que habían adoptado más de 50 usuarios del negocio: el canal de entrega era parte del diseño del modelo.

  5. Fase 5

    Vigilar el modelo y decidir qué hacer con lo que se ve

    Entradas

    • Las entradas, las predicciones y el resultado real cuando llega.
    • El uso que los responsables hacen de la predicción.

    Actividades

    • Vigilar cinco niveles: calidad de las entradas, distribución, desempeño observado, uso e impacto.
    • Comparar la predicción con lo que de verdad ocurrió, segmento por segmento.
    • Decidir ante cada desviación: investigar la fuente, recalibrar, reentrenar, restringir o volver a una versión anterior.

    Artefactos

    • El tablero de vigilancia del modelo.
    • El registro de cada decisión tomada sobre el modelo.
    Quién decide
    El dueño del modelo, con el dueño de la decisión.
    Control que cierra la fase
    Ninguna alerta queda sin una acción decidida.
    Evidencia

    En TransMilenio el resultado real llegaba con el recaudo del mes: la predicción por ruta y franja se contrastaba con lo que de verdad ocurrió.

Bloque 4

Las decisiones de diseño

  1. La línea base antes que el algoritmo

    Cuándo sí
    Siempre: antes de entrenar se escribe qué tiene que superar el modelo —una regla simple, una media histórica o la forma actual de decidir— y el veredicto puede decir «no supera».
    Cuándo no
    Cuando nadie puede decir qué decisión cambiaría con el resultado: entonces el problema todavía no es predictivo.

    Por qué

    Evidencia

    En Banco Pichincha la línea base era la predicción que ya existía, y el modelo la mejoró hasta un 35 %; en Probeta DS la línea base está a la vista por diseño —clase mayoritaria y regresión logística—.

    Criterio

    La sofisticación del algoritmo no vale por sí sola: vale lo que mejora frente a la forma en que ya se decide.

  2. Validar en orden temporal, nunca con una partición al azar

    Cuándo sí
    Cuando el fenómeno tiene dimensión temporal —demanda, fuga, mora—: se entrena con el pasado y se mide sobre periodos posteriores.
    Cuándo no
    Cuando las observaciones no dependen del tiempo ni del orden en que llegan: una partición al azar, estratificada, basta.

    Por qué

    Evidencia

    En TransMilenio el modelo de demanda se entrenaba con los meses anteriores y se medía con RMSE sobre los siguientes, nunca con una partición aleatoria que dejara ver el futuro dentro del entrenamiento.

    Criterio

    Una precisión que la operación no va a repetir es peor que una precisión modesta: promete lo que nadie va a recibir.

  3. Evaluar por el error que cuesta, no por la exactitud

    Cuándo sí
    Cuando las clases están desbalanceadas o un falso positivo y un falso negativo no cuestan lo mismo: la matriz de confusión y el umbral se leen contra ese costo.
    Cuándo no
    Cuando los dos errores cuestan lo mismo y las clases están equilibradas: la métrica global sirve como primera lectura.

    Por qué

    Evidencia

    En Banco Pichincha llamar a un cliente que no iba a irse costaba una llamada, y no llamar al que sí se iba costaba el cliente: por eso el análisis miraba dónde se concentraban los errores y no solo cuántos había.

  4. Cómo se formula un problema de optimización: dos veces, y los óptimos tienen que coincidir

    Cuándo sí
    Cuando la decisión es elegir una combinación de recursos bajo restricciones —asignar, programar, balancear—: el problema se formula como programación entera y como programación por restricciones, y una diferencia entre sus óptimos delata una traducción mal hecha.
    Cuándo no
    Cuando la pregunta es qué va a pasar y no qué conviene elegir: ahí basta un modelo predictivo con su línea base.

    Por qué

    Evidencia

    En el Paper Computacional del autor cada problema se formula dos veces —programación entera mixta con Pyomo y HiGHS, y programación por restricciones con OR-Tools— y sus óptimos deben coincidir o el modelo está mal traducido; renunciar a una de las dos formulaciones exige una justificación escrita.

    Estado del campo

    Los sistemas que traducen con un LLM un enunciado en lenguaje natural a un modelo de optimización se han evaluado sobre todo con problemas de juguete o sintéticos; reconstruidos 223 problemas reales de MIPLIB 2017, los que rinden bien en esas pruebas se degradan de forma sustancial.[10]

  5. Simular antes de intervenir cuando la variabilidad decide

    Cuándo sí
    Cuando el resultado depende de colas, de recursos que compiten y de tiempos que varían: la simulación de eventos discretos compara escenarios antes de tocar la operación.
    Cuándo no
    Cuando el promedio basta para la decisión y cambiarla no altera la dinámica del sistema.

    Por qué

    Evidencia

    En Cafam, en 2021, el modelo en FlexSim del despacho de medicamentos con la lógica del nuevo WMS mostró dónde una regla razonable en una actividad producía esperas en otra: la cola no estaba donde el promedio decía que iba a estar.

    Criterio

    Una simulación no predice lo que va a pasar: compara escenarios bajo supuestos escritos, y vale lo que valen esos supuestos.

  6. Una señal para quien decide, no una decisión automática

    Cuándo sí
    Cuando la acción exige conocimiento adicional, juicio o rendición de cuentas: el modelo prioriza u ordena, y la persona autorizada decide.
    Cuándo no
    Cuando la acción es verificable, reversible y de bajo costo, y revisar cada caso volvería a la persona el cuello de botella.

    Por qué

    Evidencia

    En los modelos de fuga y mora de Banco Pichincha el modelo generaba evidencia para apoyar una decisión, no una decisión automática que sustituyera el criterio de los responsables.

    Estado del campo

    En Microsoft Fabric las predicciones se escriben en OneLake y los informes de Power BI las leen en modo Direct Lake, directamente y sin copiarlas al modelo semántico.[1]

  7. Vigilar después de publicar: la deriva no avisa

    Cuándo sí
    Siempre que un modelo entra a operar: las entradas, la distribución y el desempeño se vigilan frente a los del entrenamiento, con umbrales y una respuesta definida para cada alerta.
    Cuándo no
    Cuando el modelo responde una sola pregunta que no se repite: basta escribir sus límites y no volver a usarlo.

    Por qué

    Estado del campo

    Los cambios en la distribución de los datos, la diferencia entre el entrenamiento y el servicio, los problemas de calidad, los cambios del entorno y los del comportamiento de los consumidores pueden volver obsoleto un modelo, y su desempeño puede degradarse hasta dejar de aportar valor al negocio.[5]

    Evidencia

    En Vesting, entre agosto de 2023 y enero de 2025, el monitoreo en tiempo real de hasta 23 agentes recogía por sesión entradas, salidas, tiempos, estados y costo, y lo llevaba a Microsoft Fabric y a Power BI, donde una degradación se veía como una tendencia y no como una queja.

Bloque 5

Lo innovador en 2026

  • Estado del campo

    El experimento y el modelo quedan registrados solos

    Qué cambia frente a la práctica común

    En la ciencia de datos de Microsoft Fabric el registro automático con MLflow captura, mientras se entrena, los parámetros, las métricas y los artefactos de cada corrida, y con MLflow 3 cada modelo que se guarda queda enlazado a la corrida que lo produjo, con sus parámetros, sus métricas y los conjuntos de datos con que se entrenó.[2][3]

    Criterio

    El registro automático guarda lo que pasó; la línea base y el criterio de aceptación se siguen escribiendo antes de la primera corrida.

  • Estado del campo

    La predicción llega al tablero sin copias

    Qué cambia frente a la práctica común

    Las predicciones escritas en OneLake se leen desde Power BI en modo Direct Lake, sin copiarlas al modelo semántico: la predicción se mantiene al día sin mover datos de más.[1]

  • Estado del campo

    La deriva como una señal con umbral

    Qué cambia frente a la práctica común

    Azure Machine Learning ofrece señales de vigilancia para datos tabulares —deriva de los datos, deriva de la predicción, calidad de los datos, deriva de la atribución de variables y desempeño del modelo—, y la guía de estudio del examen de Microsoft sobre operar modelos de aprendizaje automático y de IA generativa incluye detectar y analizar la deriva de datos y configurar alertas o reentrenamientos cuando se superan los umbrales.[5][6]

    Criterio

    Una señal de deriva abre una revisión; reentrenar porque cambió una distribución puede borrar justo lo que había que investigar.

  • Estado del campo

    Modelos fundacionales para series de tiempo

    Qué cambia frente a la práctica común

    GIFT-Eval compara modelos estadísticos, de aprendizaje profundo y fundacionales en 23 conjuntos de datos con más de 144.000 series de tiempo, y un trabajo de 2026 sostiene que un Transformer de parches estándar, entrenado con un protocolo sencillo, alcanza el estado del arte en pronóstico sin entrenarse con las series que pronostica, con un análisis de qué lo mueve: la escala, la composición de los datos y las técnicas de entrenamiento.[7][8]

    Criterio

    Un modelo fundacional entra como un candidato más: se valida en orden temporal y contra la misma línea base que cualquier otro.

  • Estado del campo

    El LLM como asistente de formulación

    Qué cambia frente a la práctica común

    OptiMUS-0.3 usa un LLM para convertir la descripción en lenguaje natural de un problema de programación lineal o entera en un modelo matemático y en código para el solver, y después evalúa y corrige lo que generó; sus autores encuentran que la arquitectura del sistema pesa más en el resultado que la capacidad del modelo.[9]

    Criterio

    Una formulación propuesta por un LLM se verifica como cualquier otra: con una segunda formulación independiente y óptimos que coinciden.

  • Estado del campo

    MLOps por niveles, no como un salto

    Qué cambia frente a la práctica común

    El modelo de madurez de MLOps de Microsoft describe cinco niveles, del trabajo sin MLOps a la operación automatizada en la que las señales de deriva o de regresión disparan el reentrenamiento, y advierte que una organización suele mostrar rasgos de más de un nivel a la vez.[4]

Bloque 6

Modos de falla y cómo anticiparlos

  • Qué se rompe
    Información del futuro en el entrenamiento
    Cómo se ve venir
    Una métrica casi perfecta en el laboratorio que la operación no repite.
    Control que la atrapa
    Variables solo con lo disponible al predecir, preprocesamiento ajustado solo en entrenamiento y una métrica redonda tratada como sospechosa.
  • Qué se rompe
    Partición al azar en un problema temporal
    Cómo se ve venir
    El error en operación es mucho mayor que el de la validación.
    Control que la atrapa
    Validación sobre periodos posteriores a los que el modelo vio.
  • Qué se rompe
    Exactitud alta sobre una clase desbalanceada
    Cómo se ve venir
    El modelo acierta la mayoría y falla justo en los casos que justificaron construirlo.
    Control que la atrapa
    Matriz de confusión, métricas por clase y un umbral según el costo de cada error.
  • Qué se rompe
    Un modelo sin línea base
    Cómo se ve venir
    Nadie puede decir si el modelo mejora la forma actual de decidir.
    Control que la atrapa
    La línea base se fija antes de entrenar y el veredicto puede decir «no supera».
  • Qué se rompe
    El promedio que esconde el segmento
    Cómo se ve venir
    Un error aceptable en el agregado y sistemático en las rutas, clases o clientes que importan.
    Control que la atrapa
    Error por segmento allí donde se usará la predicción.
  • Qué se rompe
    La predicción que llega tarde
    Cómo se ve venir
    La estimación aparece después de que la decisión se cerró.
    Control que la atrapa
    El horizonte de predicción se alinea con el de decisión.
  • Qué se rompe
    Deriva sin vigilancia
    Cómo se ve venir
    El modelo se degrada y nadie lo nota hasta que alguien se queja.
    Control que la atrapa
    Entradas, distribución, desempeño, uso e impacto vigilados en operación, con umbrales y una respuesta definida.
  • Qué se rompe
    Una formulación mal traducida
    Cómo se ve venir
    El solver entrega un óptimo que no respeta una restricción real.
    Control que la atrapa
    Dos formulaciones independientes cuyos óptimos deben coincidir.
Bloque 7

Métricas y controles

  • Qué se mide
    Mejora frente a la línea base
    Umbral
    La supera en la prueba; si no la supera, el veredicto lo dice y el modelo no pasa.
    Quién aprueba el paso a producción
    El dueño de la decisión.
  • Qué se mide
    Error en los segmentos que se usarán
    Umbral
    Dentro del margen acordado en cada segmento, no solo en el agregado.
    Quién aprueba el paso a producción
    El dueño de la decisión, con quien construye el modelo.
  • Qué se mide
    Calibración de las probabilidades
    Umbral
    La probabilidad anunciada corresponde con la frecuencia observada en los grupos que se priorizan.
    Quién aprueba el paso a producción
    Quien reparte la capacidad de intervención.
  • Qué se mide
    Oportunidad de la predicción
    Umbral
    Siempre antes de que la decisión se cierre.
    Quién aprueba el paso a producción
    El dueño de la decisión.
  • Qué se mide
    Variables disponibles al predecir
    Umbral
    Todas, verificadas antes de entrenar.
    Quién aprueba el paso a producción
    Quien construye el modelo.
  • Qué se mide
    Alertas de deriva atendidas
    Umbral
    Todas, cada una con una acción decidida.
    Quién aprueba el paso a producción
    El dueño del modelo.
  • Qué se mide
    Coincidencia de las dos formulaciones
    Umbral
    Óptimos iguales en cada instancia; si difieren, el modelo está mal traducido.
    Quién aprueba el paso a producción
    Quien formula el problema.

Los umbrales son ejemplos del método, no cifras de un proyecto concreto.

Bloque 8

Evidencia en proyectos

  • EvidenciaNivel: Uso real

    TransMilenio: la demanda por ruta y franja, en uso después de la salida

    En C&M Consultores, entre julio de 2021 y mayo de 2022, un modelo con scikit-learn predijo la demanda del sistema por ruta, tipo de día y franja horaria con un horizonte mensual; se validó con RMSE respetando el orden temporal, entró al informe de demanda con el que las unidades programaban, siguió en uso después de la salida del autor y contribuyó a una mejora reportada del 20 % en el rendimiento del sistema.

    Ver dónde
  • EvidenciaNivel: Uso real

    Banco Pichincha: fuga y mora, con la persona decidiendo

    En Banco Pichincha, en 2023, modelos con scikit-learn para fuga de clientes y mora llegaron a producción con resultados reportados de más del 90 % de precisión y hasta un 35 % de mejora frente a las predicciones que existían; la evaluación miraba dónde se concentraban los errores y las predicciones llegaban por Power BI a quienes decidían.

    Ver dónde
  • EvidenciaNivel: Prototipo

    Probeta DS: lo que garantiza por construcción

    Probeta DS, una aplicación del autor, ejecuta Python, Pandas y scikit-learn en el navegador con Pyodide: dos modelos compiten contra dos líneas base a la vista —la clase mayoritaria y una regresión logística— y el veredicto dice «no supera» cuando no supera; las cinco métricas se calculan sobre el conjunto de prueba, con la matriz de confusión al lado; la fuga es imposible porque el preprocesamiento se ajusta solo con la mitad de entrenamiento, y una model card descargable guarda datos, partición, método, métricas, veredicto y límites.

    Ver dónde
  • EvidenciaNivel: Uso real

    La optimización formulada dos veces

    En el paper de asignación conductor y bus, producido con el Paper Computacional, las dos formulaciones independientes —programación entera y programación por restricciones— dieron 14.251 óptimos idénticos en 14.251 comparaciones, sobre la topología real de rutas de los datos abiertos del sistema y con un generador sintético declarado.

    Ver dónde
  • EvidenciaNivel: Uso real

    FlexSim en Inglopres y en Cafam: simular antes de intervenir

    En Inglopres, en 2016, la simulación de eventos discretos con FlexSim comparó alternativas de la operación de alquiler de maquinaria antes de cambiarla; en Cafam, en 2021, el modelo del despacho de medicamentos con la lógica del nuevo WMS se validó contra la operación que conocía el equipo de pruebas: si el modelo hacía cola donde la bodega no la hacía, el error estaba en el modelo.

    Ver dónde
  • EvidenciaNivel: Uso real

    Criterios congelados y resultados negativos publicados

    En las investigaciones del autor los umbrales que deciden si una tesis se sostiene se congelan antes de que exista un solo resultado, y lo que sale se publica: en el paper piloto, dos de los tres principios evaluados quedaron refutados por sus propias métricas, y así se escribieron.

    Ver dónde
  • EvidenciaNivel: Prototipo

    Convoyes de buses: la política, contra el mejor control clásico

    En la investigación sobre convoyes de buses, la política propuesta se prueba en una simulación de eventos discretos con verdad conocida por construcción y se compara contra el mejor control clásico, nunca contra no hacer nada; las experiencias medidas son de un corredor simulado, y su ficha no afirma cifras del sistema real.

    Ver dónde
Bloque 9

Límites y alcance

  • Evidencia

    No hay un caso propio de deriva observada que pueda contarse con sus cifras: lo que existe es la infraestructura para verla, construida en Vesting.

  • Evidencia

    La capa prescriptiva no se hizo en un empleo: en Vesting faltaba la tercera capa, la simulación de escenarios sobre la base de eventos, y la asignación conductor–vehículo–ruta se detectó en los datos de TransMilenio, pero su formulación y su respuesta llegaron después, en una investigación.

  • Evidencia

    Las magnitudes de la asignación y de los convoyes son de instancias sintéticas y de un corredor simulado: el mecanismo se demuestra; las cifras reales exigen datos de un operador.

  • Evidencia

    PyTorch y TensorFlow son exploración: redes neuronales y aprendizaje profundo, sin caso en producción; los modelos en producción son de scikit-learn.

  • Evidencia

    De MLOps está hecha la mitad de llevar modelos a producción y sostenerlos, no la de empaquetar y orquestar con contenedores; la ruta del AI-300, en curso, reemplazó al DP-100 retirado y no se presenta como obtenida.

  • Criterio

    MLflow, los modelos fundacionales de series de tiempo y los asistentes de formulación con LLM entran aquí como estado del campo: la experiencia que se afirma es la del bloque 8, con el nivel que el corpus le da.

  • Criterio

    Lo que conviene hacer distinto hoy: escribir la línea base y el umbral de aceptación antes de abrir el primer notebook, no cuando el modelo ya promete.

Bloque 10

Fuentes y fecha de revisión

  1. [1]
    What is Data Science in Microsoft Fabric?

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/data-science/data-science-overview

  2. [2]
    Autologging in Data Science

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/data-science/mlflow-autologging

  3. [3]
    MLflow 3 in Fabric Data Science

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/fabric/data-science/mlflow-3-overview

  4. [4]
    MLOps maturity model

    Microsoft Learn (Azure Architecture Center) ·

    https://learn.microsoft.com/en-us/azure/architecture/ai-ml/guide/mlops-maturity-model

  5. [5]
    Azure Machine Learning model monitoring

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/azure/machine-learning/concept-model-monitoring

  6. [6]
    Study guide for Exam AI-300: Operationalizing Machine Learning and Generative AI Solutions

    Microsoft Learn ·

    https://learn.microsoft.com/en-us/credentials/certifications/resources/study-guides/ai-300

  7. [7]
    GIFT-Eval: A Benchmark For General Time Series Forecasting Model Evaluation

    arXiv ·

    https://arxiv.org/abs/2410.10393

  8. [8]
    Revisiting the Generic Transformer: Deconstructing a Strong Baseline for Time Series Foundation Models

    arXiv ·

    https://arxiv.org/abs/2602.06909

  9. [9]
    OptiMUS-0.3: Using Large Language Models to Model and Solve Optimization Problems at Scale

    arXiv ·

    https://arxiv.org/abs/2407.19633

  10. [10]
    Constructing Industrial-Scale Optimization Modeling Benchmark

    arXiv ·

    https://arxiv.org/abs/2602.10450