Latest / M365.FM – Podcast de Microsoft 365, Copilot e IA en español / Notebooks de Microsoft Fabric para entrenar IA: modelos directamente sobre datos del Lakehouse, sin caos de CSV (Doblaje IA)

Transcript

Notebooks de Microsoft Fabric para entrenar IA: modelos directamente sobre datos del Lakehouse, sin caos de CSV (Doblaje IA) · M365.FM – Podcast de Microsoft 365, Copilot e IA en español

0:00
Speaker 2: Listo para 10 días de Microsoft 365 Copilot, EA, Azure
0:04
Speaker 2: y las personas que están dando forma al futuro del trabajo.
0:06
Speaker 2: Este enero, vuelve M365 con más fuerza. Únete a nosotros
0:13
Speaker 2: para sesiones en vivo, demostraciones reales y conocimientos prácticos de
0:16
Speaker 2: MVPs y expertos de la industria de todo el mundo.
0:18
Speaker 2: Nada de diapositivas genéricas. Nada de palabras de moda interminable.
0:22
Speaker 2: Abordaremos los desafíos reales. Copilot Studio, agentes de EA Fabric, Seguridad,
0:27
Speaker 2: Gobernanza y Automatización. Ya seas un profesional de TI, desarrollador
0:31
Speaker 2: o líder empresarial, hay sesiones diseñadas para ti. Con 10
0:35
Speaker 2: días completos, podrás explorar múltiples tecnologías y conectar con una
0:39
Speaker 2: comunidad global. Mira las sesiones en vivo y lleva ideas
0:42
Speaker 2: prácticas de vuelta a tu organización. Del 20 al 27
0:46
Speaker 2: de enero, 10 días, una comunidad Microsoft. Las inscripciones ya
0:50
Speaker 2: están abiertas. Ve a m365con.net y asegura tu lugar hoy mismo.
0:56
Speaker 2: Eso es m365con.net. Únete ahora en m365com.net y nos veremos
1:03
Speaker 2: en vivo en enero.
1:05
Speaker 4: Alguna vez intentaste entrenar un modelo de IA en tu
1:06
Speaker 4: computadora y viste cómo avanzaba a paso de tortuga o
1:09
Speaker 4: se bloqueaba por completo?¿ O se bloqueaba por completo? No
1:11
Speaker 4: estás solo. La mayoría de los conjuntos de datos empresariales
1:13
Speaker 4: han superado la capacidad de nuestro hardware local.¿ Pero qué
1:16
Speaker 4: pasaría si todo tu conjunto de datos de varios terabytes
1:18
Speaker 4: fuera accesible al instante desde tu notebook de entrenamiento, sin
1:21
Speaker 4: extracciones y sin el caos de los archivos SEO? Hoy
1:23
Speaker 4: entraremos en los notebooks integrados de Microsoft Fabric, donde el
1:26
Speaker 4: entrenamiento de tu modelo ocurre junto a los datos de
1:28
Speaker 4: tu lake house. Analizaremos exactamente cómo esta configuración puede ahorrar
1:33
Speaker 4: días de tiempo de procesamiento, mientras trabajas en Python o
1:36
Speaker 4: R sin concesiones. Cuando los macrodatos superan tu laptop, imagina
1:41
Speaker 4: el ventilador girando tan fuerte que ahoga tu reunión mientras
1:44
Speaker 4: trabajas en una hoja de cálculo. Ahora reemplaza esa hoja
1:48
Speaker 4: de cálculo con 12 terabytes de transacciones de clientes distribuidas
1:51
Speaker 4: a lo largo de años de actividad con docenas de
1:53
Speaker 4: campos por registro. Incluso antes de presionar ejecutar ya sabes
1:56
Speaker 4: que esto va a doler. Ahí es exactamente donde se
1:59
Speaker 4: encuentran muchos equipos de marketing. Tiene una base de datos
2:01
Speaker 4: transaccional que fácilmente podría ser la columna vertebral de un
2:04
Speaker 4: proyecto avanzado de IA. Predecir la pérdida de clientes, segmentar audiencias,
2:09
Speaker 4: personalizar campañas casi en tiempo real, pero sus herramientas sí
2:13
Speaker 4: están casi en sus escritorios. Abren archivos en Excel o
2:18
Speaker 4: en un notebook de Jupyter local, segmentan y filtran en
2:22
Speaker 4: partes diminutas solo para evitar que la máquina se congele,
2:24
Speaker 4: esperando que todo aguante lo suficiente para obtener resultados útiles.
2:30
Speaker 4: Cuando los equipos intentan hacer esto localmente, las fallas aparecen rápidamente.
2:32
Speaker 4: El procesamiento se vuelve lentísimo, los elementos de la interfaz
2:35
Speaker 4: tardan segundos en reaccionar y los de exportación que antes
2:37
Speaker 4: tomaban minutos ahora llevan horas. Pero aún las cargas de
2:40
Speaker 4: trabajo más grandes no solo se ralentizan, se detienen. Errores
2:42
Speaker 4: de memoria sobre carga de disco duro o reinicios del
2:44
Speaker 4: kernel significan que los entrenamientos no solo tardan más, a
2:47
Speaker 4: menudo nunca terminan. Y cuando hablamos de entrenar un modelo
2:50
Speaker 4: de IA, eso es cómputo desperdiciado, tiempo perdido y oportunidades perdidas.
2:55
Speaker 4: un intento de predicción de abandono que viste programó como
2:57
Speaker 4: una ejecución nocturna en un entorno local de Python. Veinte
3:02
Speaker 4: horas después, el proceso finalmente falló porque la última parte
3:05
Speaker 4: del conjunto de datos superó el límite de uso de
3:07
Speaker 4: la memoria RAM. El equipo perdió un día entero sin
3:09
Speaker 4: siquiera obtener un conjunto de métricas de entrenamiento. Si eso
3:12
Speaker 4: suena extremo, es cada vez más común. Los conjuntos de
3:15
Speaker 4: datos de marketing empresarial se han expandido año tras año,
3:18
Speaker 4: impulsados por un seguimiento más rico, experiencias omnicanal y el
3:21
Speaker 4: auge del registro basado en eventos... Incluso en la configuración estándar,
3:26
Speaker 4: los registros de rendimiento de campañas, análisis web y datos
3:29
Speaker 4: de CRM pueden aumentar fácilmente a cientos de gigabytes. Las
3:32
Speaker 4: grandes cuentas con múltiples líneas de productos a menudo terminan
3:34
Speaker 4: en el rango de los múltiples terabytes. El problema no
3:36
Speaker 4: es solo la capacidad de almacenamiento. Las cargas de entrenamiento
3:38
Speaker 4: de modelos grandes estresan todas las limitaciones de una máquina local.
3:41
Speaker 4: Las CPUs se mantienen al 100% durante periodos prolongados e
3:44
Speaker 4: incluso las GPUs de gama alta terminan inactivas mientras los
3:47
Speaker 4: datos llegan demasiado lentamente. La entrada y salida del disco
3:51
Speaker 4: se convierte en un cuello de botella constante, especialmente si
3:53
Speaker 4: el conjunto de datos reside en una unidad externa o
3:55
Speaker 4: una red compartida. Y luego está la capa de software.
3:59
Speaker 4: Una vez que los archivos son lo suficientemente grandes, incluso
4:01
Speaker 4: algo tan versátil como un cuaderno Jupyter comienza a superar
4:03
Speaker 4: sus límites, no puedes simplemente cargar un CSV de datos
4:06
Speaker 4: en la memoria cuando el archivo es más grande que
4:08
Speaker 4: tu SSD. Es por eso que muchos equipos han intentado
4:11
Speaker 4: dividir archivos, muestrar datos o crear sustitutos ligeros para los
4:14
Speaker 4: conjuntos de datos de producción reales. Es un compromiso que
4:17
Speaker 4: mantiene tu laptop funcionando para el costo de perder información valiosa.
4:20
Speaker 4: El muestreo puede descartar patrones sutiles que habrían mejorado el
4:22
Speaker 4: rendimiento del modelo. Dividir archivos introduce todo tipo de inconsistencias
4:26
Speaker 4: y hace que el reentrenamiento sea más doloroso de lo necesario.
4:31
Speaker 4: Hay una forma más inteligente de saltarse todo ese ciclo
4:33
Speaker 4: de descarga e importación. Microsoft Fabric traslada el trabajo pesado
4:36
Speaker 4: fuera de tu entorno local por completo. El entrenamiento se
4:39
Speaker 4: mueve a la nube, donde los recursos de cómputo se
4:41
Speaker 4: encuentran junto a los datos almacenados en el Lake House.
4:45
Speaker 4: No estás moviendo terabytes de un lado a otro, estás
4:47
Speaker 4: llevando tu código a donde los datos ya viven. En
4:51
Speaker 4: lugar de preocuparte por qué parte de tu historial de
4:53
Speaker 4: clientes cabe en la RAM, puedes concentrarte en la estructura
4:55
Speaker 4: y la lógica de tu ejecución de entrenamiento. Y aquí
4:58
Speaker 4: está la parte que la mayoría de los equipos pasa
5:00
Speaker 4: por alto. La verdadera ventaja no es solo la potencia
5:03
Speaker 4: adicional del cómputo en la nube. Es el hecho de
5:06
Speaker 4: que ya no tienes que mover los datos en absoluto.
5:09
Speaker 4: Acceso directo a Lakehouse, no mascados de archivos CSV.¿ Qué
5:12
Speaker 4: pasaría si tu cuaderno pudiera extraer terabytes de datos al
5:14
Speaker 4: instante sin siquiera mostrar una barra de progreso de descarga?
5:18
Speaker 4: Sin exportar a CSV, sin ver un indicador de carga
5:21
Speaker 4: moverse lentamente por la pantalla. Solo escribe la consulta, ejecútala
5:25
Speaker 4: y empieza a trabajar con los resultados ahí mismo. Esa
5:27
Speaker 4: es la diferencia cuando la capa de datos no es
5:29
Speaker 4: un paso externo, sino que está integrada en el entorno
5:32
Speaker 4: donde ya programas. En Fabric, el Lighthouse no es solo
5:35
Speaker 4: un depósito de almacenamiento separado al que te conectas de
5:38
Speaker 4: vez en cuando. Es la capa de datos nativa para
5:41
Speaker 4: los notebooks. Esto significa que tu código se ejecuta en
5:44
Speaker 4: el mismo entorno donde residen los datos físicamente. No estás
5:48
Speaker 4: enviando millones de filas a través de la red hacia
5:50
Speaker 4: tu sesión. Estás enviando instrucciones a los datos en su
5:53
Speaker 4: ubicación de origen. El proceso de entrada del modelo no
5:55
Speaker 4: es un malabarismo de exportaciones e importaciones. Es una línea
5:58
Speaker 4: directa desde el almacenamiento hacia Spark y hacia cualquier lógica
6:01
Speaker 4: de Python o RxScreen. Si has trabajado en un flujo
6:03
Speaker 4: de trabajo tradicional ya conoces los puntos críticos habituales. Alguien
6:07
Speaker 4: crea una extracción del data warehouse, la escribe en un
6:09
Speaker 4: CSV y se la entrega al equipo de ciencia de datos. Ahora,¿
6:12
Speaker 4: el esquema queda congelado en el tiempo? La semana siguiente,
6:15
Speaker 4: los datos de origen cambian y la extracción ya está obsoleta.
6:18
Speaker 4: En algunos casos, incluso tienes a dos equipos diferentes creando
6:20
Speaker 4: sus propias exportaciones ligeramente distintas. Y ahora tienes almacenamiento duplicado
6:24
Speaker 4: con definiciones que no coinciden. El mejor de los casos
6:27
Speaker 4: es una ineficiencia. En el peor, es la razón por
6:29
Speaker 4: la que dos modelos entrenados con los mismos datos dan
6:32
Speaker 4: predicciones contradictorias. Un equipo con el que trabajé necesitaba un
6:35
Speaker 4: conjunto filtrado de registros de actividad de clientes para un
6:37
Speaker 4: nuevo modelo de deserción. Extrajeron todo del almacén a una
6:40
Speaker 4: base de datos SQL local, lo filtraron y luego exportaron
6:42
Speaker 4: el conjunto de resultados a un CSV para el entorno
6:44
Speaker 4: de entrenamiento. Solo eso tomó casi un día completo en
6:48
Speaker 4: su red. Cuando se cargaron nuevos registros de actividad, la
6:51
Speaker 4: semana siguiente tuvieron que repetir todo el proceso desde cero.
6:54
Speaker 4: Para cuando pudieron comenzar el entrenamiento real, habían pasado más
6:56
Speaker 4: tiempo gestionando archivos que escribiendo código. El impacto en el
7:00
Speaker 4: rendimiento no se trata solo del tiempo que toman las transferencias.
7:03
Speaker 4: La investigación en múltiples empresas muestra ganancias consistentes cuando las
7:06
Speaker 4: transformaciones se ejecutan donde los datos están almacenados. Cuando puedes
7:09
Speaker 4: realizar las uniones, filtros y agregaciones en lugar de después,
7:13
Speaker 4: eliminas la sobrecarga, los saltos de red y las lecturas redundantes.
7:17
Speaker 4: Los notebooks de fábrica aprovechan Spark internamente para hacer esto posible.
7:21
Speaker 4: Así que, en lugar de traer 400 millones de filas
7:24
Speaker 4: a tu sesión de notebook, Spark ejecuta esa agregación dentro
7:27
Speaker 4: del entorno de Lakehouse y solo devuelve los resultados que
7:29
Speaker 4: tu modelo necesita... Si trabajas en Python o R, tampoco
7:33
Speaker 4: empiezas desde una consola vacía. Fabric viene con un conjunto
7:38
Speaker 4: de bibliotecas ya integradas para trabajos a gran escala, PySpark,
7:42
Speaker 4: Pandas on Spark, Sparklyr y más. Por lo tanto, el
7:45
Speaker 4: procesamiento distribuido es una opción desde el momento en que
7:47
Speaker 4: abres un nuevo notebook. Eso importa cuando convienes tablas de
7:51
Speaker 4: hechos y dimensiones de cientos de gigabytes, o cuando necesitas
7:54
Speaker 4: calcular ventanas móviles a lo largo de varios años de
7:58
Speaker 4: historial de clientes. Tan pronto como termina la consulta, el
8:01
Speaker 4: conjunto de datos limpio y agregado está listo para pasar
8:03
Speaker 4: directamente a tu proceso de ingeniería de características. No hay
8:06
Speaker 4: una fase intermedia de guardar en disco, verificar el esquema
8:09
Speaker 4: y volver a importar en un cuaderno de entrenamiento local.
8:12
Speaker 4: Te has saltado toda una etapa de preparación. Los equipos
8:14
Speaker 4: solían pasar días simplemente alineando columnas y re-ejecutando filtros cuando
8:17
Speaker 4: los datos de origen cambiaban. Con esta configuración pueden explorar
8:20
Speaker 4: combinaciones de características para el modelo en la misma hora
8:23
Speaker 4: en que se actualizaron los datos sin procesar. Y ahí
8:26
Speaker 4: es donde se pone interesante porque una vez que tienes
8:27
Speaker 4: conjuntos de datos limpios y masivos fluyendo directamente a tu
8:31
Speaker 4: sesión de cuaderno, tu forma de pensar sobre la creación
8:33
Speaker 4: de características empieza a cambiar. Ingeniería de características y selección
8:37
Speaker 4: de modelos a escala. Tu conjunto de datos puede ser
8:40
Speaker 4: lo suficientemente grande como para predecir casi cualquier cosa, pero
8:43
Speaker 4: eso no significa que cada columna debe estar en tu modelo.
8:45
Speaker 4: La diferencia entre un modelo que produce predicciones significativas y
8:48
Speaker 4: uno que arroja ruido a menudo se reduce a cómo
8:50
Speaker 4: seleccionas y das forma a tus características. La escala te
8:54
Speaker 4: da posibilidades, pero también magnifica los errores. Con conjuntos de
8:58
Speaker 4: datos masivos. Lanzar todos los campos sin procesar a tu
9:00
Speaker 4: algoritmo no solo es desordenado, puede erosionar activamente el rendimiento.
9:05
Speaker 4: Más columnas significan más parámetros para estimar y más oportunidades
9:09
Speaker 4: para que tu modelo se ajuste a peculiaridades en los
9:11
Speaker 4: datos de entrenamiento que no se generalizan. El sobreajuste se
9:16
Speaker 4: vuelve más fácil, no más difícil, cuando el conjunto de
9:17
Speaker 4: características es inflado. Además de eso, cada variable adicional significa
9:21
Speaker 4: más computación. Incluso en un entorno de nube bien provisto,
9:24
Speaker 4: 500 características sin procesar ralentizarán el entrenamiento, aumentarán el uso
9:29
Speaker 4: de memoria y complicarán cada paso posterior en comparación con
9:31
Speaker 4: un conjunto ágil de 50 bien diseñadas. El costo oculto
9:35
Speaker 4: no siempre es obvio según el reloj. Esa ejecución de
9:37
Speaker 4: 500 características podría terminar sin errores, pero podría dejarte con
9:40
Speaker 4: un modelo que es marginalmente más preciso en los datos
9:42
Speaker 4: de entrenamiento y notablemente peor en datos nuevos. Cuando reduces
9:48
Speaker 4: y refinas esas características, fusionando variables relacionadas, codificando categorías de
9:53
Speaker 4: manera más eficiente o creando agregados que capturen patrones en
9:56
Speaker 4: lugar de valores brutos, reduces el tiempo de cómputo mientras
9:59
Speaker 4: mejoras el precisión con la que el modelo predice el futuro.
10:04
Speaker 4: Ciertas formas de datos hacen que esto sea más difícil.
10:06
Speaker 4: Las características de alta cardinalidad, como los SKU de productos
10:10
Speaker 4: únicos o los ID de clientes, pueden explotar en miles
10:12
Speaker 4: de columnas codificadas si se manejan de manera ingenua. Los
10:16
Speaker 4: datos dispersos, donde la mayoría de los campos están vacíos
10:18
Speaker 4: para la mayoría de los registros, pueden ocultar señales útiles
10:21
Speaker 4: pero consumir recursos al almacenar y procesar valores mayormente faltantes.
10:26
Speaker 4: En algo como la predicción de deserción de clientes también
10:28
Speaker 4: puedes tener patrones temporales, ciclos de compra, actividad estacional o
10:32
Speaker 4: fases de incorporación que no aparecen en los campos estáticos comunes.
10:38
Speaker 4: La ingeniería de característica de esta escala implica diseñar transformaciones
10:41
Speaker 4: que condensen y revelen patrones sin inundar el conjunto de
10:44
Speaker 4: datos con ruido. Ahí es donde las herramientas de automatización
10:47
Speaker 4: y procesamiento distribuido comienzan a dar resultados. Bibliotecas como Feature
10:50
Speaker 4: Tools pueden automatizar la generación de agregados y características móviles
10:54
Speaker 4: en grandes conjuntos de datos relacionales. En Fabric, esas transformaciones
10:57
Speaker 4: pueden ejecutarse en Spark, permitiéndote escalar la creación de cientos
11:00
Speaker 4: de posibles características sin cargar todo en la memoria de
11:03
Speaker 4: una sola máquina. Agrupaciones temporales, agregados a nivel de cliente,
11:08
Speaker 4: ratios entre métricas relacionadas, todo esto puede crearse y probarse
11:11
Speaker 4: de forma iterativa sin interrumpir tu flujo de trabajo laboral.
11:15
Speaker 4: Una vez que has curado tu conjunto de características, la
11:17
Speaker 4: selección del modelo se convierte en un acto de equilibrio
11:19
Speaker 4: por sí mismo. Diferentes algoritmos interactúan con datos a gran
11:22
Speaker 4: escala de maneras distintas. Los marcos de trabajo de Gradient
11:24
Speaker 4: Boosting como Exige Boost o Like KBM manejan conjuntos de
11:27
Speaker 4: datos tabulares grandes de manera eficiente, pero siguen teniendo un
11:30
Speaker 4: costo por característica tanto en memoria como en tiempo de iteración.
11:33
Speaker 4: La regresión logística escala bien y entrena rápido, pero no captura.
11:37
Speaker 4: Delaciones no lineales complejas a menos que tú mismo las
11:39
Speaker 4: incorpores en las características... Los modelos de aprendizaje profundo pueden,
11:44
Speaker 4: en teoría, descubrir patrones más ricos, pero también exigen más
11:46
Speaker 4: ajustes y más cómputo. En el entorno Fabric puedes aprovisionar eso,
11:50
Speaker 4: pero tendrás que evaluar si las ganancias justifican el costo
11:52
Speaker 4: de entrenamiento. La buena noticia es que con los notebooks
11:55
Speaker 4: de Fabric conectados directamente a tu Lakehouse puedes probar estas
11:58
Speaker 4: estrategias y los cuellos de botella tradicionales. Puedes iniciar múltiples
12:02
Speaker 4: ejecuciones de entrenamiento con diferentes conjuntos de características y algoritmos
12:06
Speaker 4: usando los mismos datos subyacentes sin tener que recargarlos o
12:08
Speaker 4: remodelarlos en cada intento. Esa capacidad de iterar rápidamente significa
12:12
Speaker 4: que no estás limitado a suponer que enfoque funcionará mejor.
12:16
Speaker 4: Puedes medir y decidir. Las características bien diseñadas y adaptadas
12:19
Speaker 4: a la arquitectura del modelo correcta pueden reducir significativamente los
12:21
Speaker 4: tiempos de ejecución, disminuir el uso de memoria y aún
12:23
Speaker 4: así aumentar la precisión en datos no vistos. Obtienes ciclos
12:27
Speaker 4: de experimentación más rápidos y resultados más confiables y destinas
12:31
Speaker 4: tu presupuesto de cómputo al entrenamiento que realmente importa en
12:34
Speaker 4: lugar de procesar datos irrelevantes. Lo siguiente es el paso
12:37
Speaker 4: que mantiene productivas estas ejecuciones a gran escala. monitorearlas y
12:41
Speaker 4: evaluarlas en tiempo real para saber exactamente qué ocurre mientras
12:44
Speaker 4: el modelo entrena en la nube. Entrenamiento, monitoreo y evaluación
12:48
Speaker 4: a escala de nube. Entrenar con gigabytes de datos suena
12:51
Speaker 4: como un sueño hasta que te quedas sentado preguntándote si
12:53
Speaker 4: el trabajo sigue ejecutándose o si murió silenciosamente hace una hora.
12:58
Speaker 4: Cuando todo sucede en la nube, pierdes la retroalimentación instantánea
13:00
Speaker 4: que obtienes al ver los registros pasar en una terminal local.
13:04
Speaker 4: Eso está bien si el trabajo termina en minuto. Es
13:06
Speaker 4: un problema cuando el tiempo se mide en horas y
13:08
Speaker 4: no tienes idea de si estás avanzando Ejecutar el entrenamiento
13:12
Speaker 4: en un entorno remoto cambia tu forma de pensar sobre
13:14
Speaker 4: la visibilidad. En una sesión local detectas los problemas de inmediato.
13:18
Speaker 4: Valores faltantes en un campo, un error de tipo de
13:21
Speaker 4: dato o un bloqueo en la importación. En un clúster
13:24
Speaker 4: en la nube, ese mismo error podría estar oculto en
13:26
Speaker 4: un archivo de registro que no revisas hasta mucho después.
13:29
Speaker 4: Y dado que los recursos se aprovisionan y construyen mientras
13:32
Speaker 4: el proceso técnicamente está en ejecución cada minuto, de una
13:35
Speaker 4: ejecución fallida sigue siendo dinero gastado. El costo de detectar
13:38
Speaker 4: un problema demasiado tarde aumenta rápidamente. he visto un trabajo
13:41
Speaker 4: de predicción de abandono que se inició un viernes por
13:43
Speaker 4: la noche con una estimación de 8 horas. El lunes
13:46
Speaker 4: por la mañana, el equipo se dio cuenta de que
13:48
Speaker 4: había fallado antes de que comenzara la primera época porque
13:50
Speaker 4: una columna, que debía ser numérica, se cargó como texto.
13:53
Speaker 4: En tiempo de ejecución real, 10 minutos desperdiciados al inicio,
13:56
Speaker 4: 8 horas facturadas en el medidor. Ese es el tipo
13:59
Speaker 4: de error que erosiona la confianza en el proceso y
14:01
Speaker 4: ralentiza los ciclos de iteración hasta dejarlos casi detenidos. Fabric
14:04
Speaker 4: aborda esto con monitoreo de trabajos en tiempo real que
14:08
Speaker 4: puedes abrir junto a tu cuaderno. Obtienes métricas en vivo
14:11
Speaker 4: sobre el consumo de memoria, el uso de CPU y
14:13
Speaker 4: el progreso a través de las épocas de entrenamiento. Los
14:17
Speaker 4: registros se transmiten a medida que el trabajo se ejecuta,
14:20
Speaker 4: por lo que puedes detectar advertencias o errores antes de
14:22
Speaker 4: que se conviertan en fallas totales. Si algo parece extraño,
14:26
Speaker 4: puedes detener la ejecución en ese mismo instante en lugar
14:28
Speaker 4: de aprender de la manera difícil después. Aunque no se
14:30
Speaker 4: trata solo de observar. Puedes configurar puntos de control durante
14:33
Speaker 4: el entrenamiento para que el estado del modelo se guarde periódicamente.
14:35
Speaker 4: Si el trabajo se detiene, ya sea por un error, límite,
14:38
Speaker 4: recursos o interrupción intencional, puedes reiniciar desde el último punto
14:41
Speaker 4: de control en lugar de empezar desde cero. El control
14:44
Speaker 4: de versión es también con papel aquí. Al guardar versiones
14:47
Speaker 4: del modelo entrenado con sus parámetros y divisiones de datos asociadas,
14:50
Speaker 4: puedes revisar una configuración pasada sin tener que recrear todo
14:54
Speaker 4: el entorno que la produjo. Los guardados intermedios no son
14:58
Speaker 4: solo una buena medida de seguridad, son lo que hace
15:00
Speaker 4: viable la experimentación a gran escala. Puedes derivar de un
15:03
Speaker 4: punto de control prometedor y probar diferentes hiperparámetros sin pagar
15:06
Speaker 4: el costo de tiempo de recargar y reentrenar el model
15:09
Speaker 4: base C. Con conjuntos de datos de varios gigabytes eso
15:12
Speaker 4: puede significar la diferencia entre ejecutar tres experimentos en un
15:15
Speaker 4: día o solo uno. Una vez que el modelo termina,
15:17
Speaker 4: la evaluación a esta escala conlleva su propio conjunto de desafíos.
15:21
Speaker 4: No siempre puedes evaluar contra el conjunto de prueba completo
15:23
Speaker 4: en una sola pasada sin ralentizar todo hasta el extremo.
15:26
Speaker 4: El muestreo balanceado ayuda aquí manteniendo las proporciones de clase
15:29
Speaker 4: mientras reduce el conjunto de datos a un tamaño que
15:31
Speaker 4: se evalúa más rápido. Para una mayor precisión, la evaluación
15:34
Speaker 4: distribuida te permite dividir la tarea de puntuación a través
15:36
Speaker 4: del clúster, con resultados agregados automáticamente. Fabric admite bibliotecas de
15:42
Speaker 4: Python como MLib y flujos de trabajo de CKIT Learn
15:44
Speaker 4: distribuidos para hacer eso posible. En lugar de esperar a
15:48
Speaker 4: que una sola máquina ejecute métricas en cientos de millones
15:50
Speaker 4: de registros, puede distribuir la tarea y obtener los resultados
15:53
Speaker 4: consolidados de precisión, exhaustividad o puntuaciones F1 en una fracción
15:57
Speaker 4: del tiempo. Los datos nunca salen de Lake House, por
16:00
Speaker 4: lo que no tiene que lidiar con exportaciones de conjuntos
16:02
Speaker 4: de prueba ni combinaciones manuales.