Mas leido
Building Stories
Modo Rua: Redefiniendo el desarrollo de aplicaciones mediante iteración centrada en el usuario Ago 23
Building Stories
NuStories: Adaptación de productos para clientes fanáticos en varios países Oct 30
Culture & Values
Cómo los valores y la cultura de Nu dan forma a los productos que creamos Ago 7
Carreras
Reunimos a grandes mentes de diversos orígenes que permiten la discusión y el debate y mejoran la resolución de problemas.
Conoce más sobre nuestras carreras
Escrito por Felipe Almeida
Revisado por Tiago Magalhães
En esta publicación explicaremos qué es entrenamiento-entrega y por qué necesitamos entenderlo cuando trabajamos con modelos de aprendizaje automático en tiempo real.
Proporcionaremos ejemplos sobre cómo monitorear y depurar discrepancias en entrenamiento-entrega, junto con las lecciones que aprendimos durante años aplicando ML en tiempo real a problemas comerciales en Nubank.
¿Qué es el sesgo de entrenamiento-entrega?
Para comprender el sesgo de entrenamiento-entrega, debes recordar que los modelos de aprendizaje automático en tiempo real se entrenan en un entorno diferente al de aquel en el que se utilizan (serven). Además, estos modelos generalmente son entrenados y producidos por diferentes personas.
El entrenamiento normalmente se realiza en un entorno analítico (cuadernos interactivos o lagos de datos, por ejemplo), pero el servicio ocurre en el entorno de producción (microservicios, dispositivos perimetrales, etc.). Esto es lo que representamos en la Figura 1 a continuación:
Figura 1: El entrenamiento de un modelo de Aprendizaje Automático generalmente se lleva a cabo en un entorno analítico (tablas de bases de datos, cuadernos, etc.), mientras que el uso real de un modelo ocurre en el entorno de producción (servicios en tiempo real, dispositivos perimetrales, API, etc.). Las diferencias inesperadas entre estos provocan un sesgo en el entrenamiento-entrega.
Todo en ML depende de una premisa muy importante: el conjunto de entrenamiento debe reflejar los datos reales que el modelo puntuará en el momento de servir.
El sesgo de entrenamiento-entrega se refiere a la situación en la que se rompe la simetría entre los entornos de entrenamiento y de servicio, debido a problemas operativos y una lógica defectuosa. En otras palabras, tenemos sesgo cuando existen diferencias entre la forma en que se entrenó el modelo y la forma en que se sirve.
El sesgo de entrenamiento-entrega se refiere a las diferencias entre el entorno donde se entrena un modelo y donde se sirve (o se utiliza).
Algunos ejemplos de sesgo en entrenamiento-entrega:
Puedes acceder a muchos más ejemplos en el apartado “Comprender el tipo de desajuste” en este artículo.
Descubre las oportunidades
¿Por qué nos preocupa el sesgo en entrenamiento-entrega?
Necesitamos corregir (o al menos ser conscientes de) el sesgo en entrenamiento-entrega porque puede tener graves impactos en las predicciones de un modelo y, en consecuencia, en los procesos de negocio que dependen de él.
Un claro ejemplo es en la suscripción de créditos: Los bancos suelen utilizar modelos de riesgo crediticio en tiempo real para decidir quién recibe un préstamo. El sesgo no detectado en entrenamiento-entrega puede hacer que los clientes de alto riesgo reciban préstamos cuando no deberían, causando pérdidas financieras a los bancos, sin mencionar una posible falla sistémica del sistema bancario.
¿Por qué ocurre el sesgo en entrenamiento-entrega?
La razón principal por la que se produce un sesgo en el entrenamiento-entrega es la falta de comunicación durante la fase previa a la implementación de un modelo.
Los modelos en tiempo real generalmente son entrenados e implementados por diferentes personas (científicos de datos e ingenieros de aprendizaje automático, respectivamente), por lo que es probable que ocurran errores de comunicación y lo que se implementa (o sirve) no es lo mismo que lo que se entrena.
El sesgo en el entrenamiento-entrega se debe a una falta de comunicación entre los equipos de modelado e ingeniería o a cambios inesperados en los servicios utilizados para obtener características.
Pero incluso después de que un modelo haya estado en funcionamiento durante algún tiempo, pueden aparecer nuevos desajustes en el entrenamiento-entrega. Esto se debe a cambios ascendentes o errores al recuperar funciones en tiempo real.
Las empresas modernas operan dentro de una arquitectura de microservicios, por lo que los modelos en tiempo real necesitan información de otros servicios, propiedad de otros equipos, y estos servicios pueden cambiar o interrumpirse sin previo aviso, lo que afecta las características utilizadas en el modelo.
¿Qué tipos de sesgos existen?
En nuestra experiencia, existen dos tipos diferentes de sesgos en entrenamiento-entrega, dependiendo de la etapa del ciclo de vida se produzcan:
Estos se pueden ver a continuación en la Figura 2:
Figura 2: Ciclo de Vida del Modelo ML Simplificado. La primera implementación necesita una verificación del sesgo del entrenamiento-entrega para asegurarse de que las características del modelo se implementen correctamente en primer lugar. Pero una vez que se haya implementado con éxito, todavía debemos seguir monitoreando, detectando y posiblemente solucionando los desajustes en el entrenamiento-entrega a medida que aparecen.
En las siguientes secciones repasaremos algunas de las estrategias para evitar (o al menos mitigar los efectos) el sesgo del entrenamiento-entrega en nuestros modelos en tiempo real en Nubank.
Evitar y mitigar la desviación del entrenamiento-entrega
La desviación del entrenamiento-entrega nunca se eliminará por completo. Siempre habrá casos en los que una función en tiempo real se romperá debido a una falla temporal en los servicios de soporte, por ejemplo. Algunos casos de malas características aquí y allá no deberían causar problemas, especialmente si utiliza clasificadores sólidos como los modelos basados en árboles.
Los casos contra los que queremos protegernos son aquellos en los que una gran parte de las predicciones del modelo se ven afectadas por características incorrectas, ya que podrían tener un impacto grave en los procesos de negocio que utilizan predicciones del modelo.
Para evitar (o al menos mitigar) el sesgo del entrenamiento-entrega, lo primero que necesita es recopilar datos de características de ambas rutas de datos (entrenamiento y entrega). Cubrimos este artículo en Requisitos Previos: Recopilación de datos.
Una vez que se recopilan datos de características en ambas rutas de datos, la tarea de abordar el sesgo se reduce a:
En una arquitectura de microservicios, los modelos en tiempo real son un servicio más. Los modelos dependen de servicios ascendentes para obtener datos de funciones, pero es imposible controlar lo que harán otros equipos,y nosotros tampoco deberíamos hacerlo, ya que eso perjudicaría su autonomía y agilidad.
Es por eso que creemos que el monitoreo es la única forma escalable de defenderse contra el sesgo en entrenamiento-entrega, para que pueda detectar y reaccionar ante los problemas, sin convertirse en un cuello de botella para otros equipos.
El uso de una tienda de funciones también ayuda a evitar el sesgo en entrenamiento-entrega Las tiendas de características suelen ser operadas por un equipo centralizado, lo que libera al equipo de modelado de tener que lidiar con el problema. Si puedes, utiliza una tienda de funciones.
En las siguientes subsecciones repasaremos el enfoque completo para abordar el sesgo en entrenamiento-entrega en Nubank: hablaremos de los requisitos previos (asegurándonos de que está recopilando los datos que necesita) y luego cubriremos qué y cómo monitorear el sesgo en entrenamiento-entrega, cómo interpretarlo para detectar discrepancias y, finalmente, cubriremos algunas estrategias sobre cómo depurar y solucionar los problemas.
Requisitos previos: recopilación de datos
Lo primero que necesitas para poder comparar datos de dos rutas de datos diferentes es asegurarte de que estás recopilando esos datos.
Esto significa que necesitas (a) una forma programática de generar datos de entrenamiento a pedido y (b) necesitas registrar las características utilizadas para cada ejecución del modelo en tiempo real.
Para abordar el punto (a), necesitas una forma programática y repetible de generar datos de entrenamiento para fechas arbitrarias. Necesitas algún tipo de función o rutina que tome un par de fechas y genere los datos de entrenamiento para ese período de tiempo. Consulta la Figura 3 para ver un ejemplo:
Figura 3: La generación programática de datos de entrenamiento para un período de fechas determinado es esencial para poder lidiar con el sesgo en entrenamiento-entrega, porque esto es con lo que compararemos los datos de servicio. Ten en cuenta que no necesitamos incluir la variable de destino en los datos, solo características.
En el punto (b) (registro de datos de funciones de ejecución en tiempo real), necesita alguna forma de registrar el identificador de puntuación (ID) y las funciones utilizadas en el momento de la publicación. Esto se puede hacer fácilmente guardando los datos de las funciones en una base de datos o en un servicio de registro como Splunk.
Cuando tiene cubiertos (a) y (b), detectar el sesgo de entrenamiento-entrega es mucho más fácil: solo necesitas unir características para una instancia determinada y compararlas. Esto se muestra en la Figura 4 en la siguiente sección.
Monitoreo de sesgo en entrenamiento-entrega
Como se explicó anteriormente, necesita datos de tiempo de entrenamiento y de servicio para monitorear el sesgo en entrenamiento-entrega. Una vez que tengas una forma sólida de generarlos continuamente, es simplemente cuestión de usar cualquier herramienta de panel para visualizar los datos.
El monitoreo se puede utilizar tanto para las etapas previas como posteriores a la implementación. Puedes monitorear un modelo antes de que esté en uso mediante la denominada implementación en modo sombra: implementa un modelo en tiempo real pero ignora sus predicciones.
Puedes monitorear las funciones que utiliza un modelo en tiempo real incluso antes de que esté en producción; implementar el modelo en modo sombra es un patrón común.
La forma en que puedes generar datos de monitoreo es la siguiente: toma los datos de tiempo de entrenamiento y de entrega y aplica una unión entre ellos, utilizando el ID de instancia como clave de unión. Esto se muestra a continuación en la Figura 4:
Figura 4: Creación de un conjunto de datos de seguimiento a partir de datos de entrenamiento y entrega: cuando tenga datos de ambas rutas de datos, puedes unirlos para crear un conjunto de datos temporal con ambos valores para cada característica. En el ejemplo mostrado, tenemos una discrepancia para la característica x: su valor debería ser 5.0 pero en su lugar obtuvimos 10.0.
Cuando tengas un conjunto de datos de seguimiento como el que se muestra en la Figura 4, puedes proceder al seguimiento real, como explicamos a continuación.
Tipos de seguimiento de sesgo en entrenamiento-entrega
El llamado ″conjunto de datos de seguimiento″ es todo lo que necesitamos para generar todos los gráficos de seguimiento que se muestran en las siguientes secciones.
Aunque puede haber otras formas de visualizar el sesgo en entrenamiento-entrega, cubriremos las que consideramos más importantes y que utilizamos en nuestro trabajo diario.
Cada uno de estos desempeña un papel para ayudar a los profesionales a mantener saludables los sistemas de aprendizaje automático. Explicaremos cada uno en detalle en las siguientes subsecciones.
Porcentaje de coincidencias exactas por día, por función
Puedes monitorear el sesgo en entrenamiento-entrega trazando el porcentaje de coincidencias exactas, por función, a lo largo del tiempo.
En la Figura 5 a continuación podemos ver uno de esos gráficos, para la ″Característica X″. En el eje Y tenemos los porcentajes de coincidencias exactas y en el eje X el tiempo.
Es fácil ver que tuvimos alrededor del 90% de tasa de coincidencia el 2 de enero de 2022 y alrededor del 60% el 5 de enero de 2022. Esto significa que el 10% y el 40%, respectivamente, de las instancias calificadas tenían valores incorrectos para la Característica X en el momento de la publicación.
Figura 5: Trazando el porcentaje de coincidencias exactas para una característica, por día. Es muy fácil ver que hubo un problema menor el 2 de enero de 2022 y un problema importante el 5 de enero de 2022. Un panel de seguimiento debe incluir varios gráficos como este, uno para cada característica del modelo.
Ten en cuenta que este gráfico no proporciona ninguna información sobre la magnitud de las diferencias. Sigue leyendo para saber qué hacer a continuación.
Diferencia promedio entre entrenamiento y servicio, por función
Monitorear el porcentaje de coincidencias exactas (como se indicó anteriormente) es un buen comienzo, pero no suficiente. Es necesario comprender la magnitud del desajuste para saber qué tan grave es y si se debe investigar más a fondo.
Puedes trazar la diferencia entre los valores de tiempo de entrenamiento y tiempo de entrega de las funciones, como se puede ver en el siguiente ejemplo.
Figura 6: Trazando la diferencia numérica promedio entre los valores de tiempo de entrenamiento y tiempo de entrega para una característica determinada. Podemos ver que la magnitud del sesgo del 2 de enero de 2022 es mucho mayor que la del 5 de enero de 2022. La magnitud del sesgo (junto con el porcentaje de coincidencia exacta como se ve en la Figura 5) le informará sobre la urgencia del problema.
Examinar los promedios de las diferencias, en lugar de simples porcentajes de coincidencia, es un gran paso adelante, pero los promedios pueden ser engañosos y llevarnos a conclusiones falsas.
Percentiles de diferencias entre entrenamiento y servicio, por característica
Si ya controlas la tasa de coincidencias exactas y la magnitud promedio, tienes un buen nivel de protección contra el sesgo en entrenamiento-entrega. Pero los valores atípicos y otros valores extremos pueden engañarte, ya que tienen un gran impacto en los promedios: uno o dos valores atípicos pueden mover mucho el valor promedio.
Comprender el comportamiento de las características en los extremos (P99) es importante para los casos en los que solo está interesado en los valores más grandes (colas) de las predicciones, como en la suscripción de créditos, la detección de fraudes, etc.
Para protegernos contra valores atípicos, podemos monitorear las diferencias percentiles entre los valores de las características de tiempo de entrenamiento y tiempo de entrega, como se ve en la Figura 7 a continuación. El sesgo del 2 de enero de 2022 parece haber sido estrictamente en los percentiles más altos: apenas tuvo impacto en los percentiles más bajos. El sesgo del 5 de enero de 2022 afectó a todos los percentiles más o menos por igual.
Figura 7: Trazando los percentiles de las diferencias numéricas entre los valores de tiempo de entrenamiento y tiempo de entrega para una característica determinada. Los desajustes que afectan solo a los percentiles superiores (como el 2 de enero de 2022) pueden indicar un par de malas puntuaciones debido a problemas temporales, pero no problemas generalizados. Los desajustes que afectan a todos los percentiles (como el 5 de enero de 2022) suelen ser indicativos de un sesgo basado en la lógica y pueden ser más graves.
Vimos cómo monitorear adecuadamente las discrepancias de características; Veamos ahora cómo interpretar estos gráficos para detectar cuándo tenemos un sesgo en entrenamiento-entrega.
Detectando cuándo se está produciendo un sesgo
Según nuestra experiencia, la mayoría de los desajustes posteriores a la implementación se deben a cambios ascendentes en los servicios de los que obtenemos funciones en tiempo real. Esto supone que estás trabajando dentro de una arquitectura de microservicios.
El sesgo en entrenamiento-entrega posterior al despliegue generalmente se muestra como un cambio repentino y pegajoso en las parcelas de monitoreo. Mira un ejemplo en la Figura 8.
Figura 8: Gráfico de muestra que muestra una característica ″rota″. Una caída repentina que no vuelve a los niveles normales es una señal clara de que algo fundamental cambió.
¿Y cómo detectamos el sesgo previo a la implementación? Solo necesitamos monitorear los datos de una implementación en modo sombra, como se explica en la sección Monitoreo de Sesgo en Entrenamiento-Entrega.
Comprender la magnitud del desajuste
Para saber qué tan graves son las discrepancias, debemos observar gráficos que muestren las diferencias en los valores de las características. Probablemente no te molestarás en intentar investigar cada pequeño desajuste, especialmente cuando la magnitud es muy pequeña, ya que probablemente tendrás muy poco impacto en la predicción del modelo y, por extensión, en el negocio.
Considera el impacto de la falta de coincidencia de funciones en el negocio.
Incluso si tienes una característica con mucho sesgo, hay casos en los que optarás por no investigarla si el impacto en el negocio es muy pequeño. Esto puede suceder, por ejemplo, en casos en los que hay un sesgo en una característica de baja importancia, por lo que no causa ningún impacto real en el negocio.
Podemos pensar en dos formas de medir el impacto empresarial de las características sesgadas:
Depuración y solución de problemas
Bien, entonces detectaste que tu modelo sufre un sesgo en entrenamiento-entrega, comprendiste la magnitud del desajuste y viste que está teniendo un impacto suficiente en el negocio como para justificar trabajar en él. Ahora necesitas depurar y corregir la discrepancia.
La detección de el sesgo en entrenamiento-entrega se puede realizar observando paneles y gráficos. Sin embargo, al depurar, es necesario acceder a los datos de comparación sin procesar para comprender la naturaleza del sesgo.
La depuración y corrección de discrepancias en entrenamiento-entrega implica comparar los valores de las funciones utilizadas en el entrenamiento y en el momento de la entrega para instancias individuales, por lo que te sugerimos que crees un conjunto de datos de monitoreo donde puedas ver los valores de las funciones para ambas rutas de datos.
Como se mencionó anteriormente, la recopilación de datos es un requisito previo para abordar el sesgo en entrenamiento-entrega: si no se recopilan datos de capacitación y servicio, no se pueden monitorear ni corregir las discrepancias en el entrenamiento-entrega.
En la Figura 9 puedes ver otro ejemplo de cómo debería verse un ″conjunto de datos de seguimiento″ para un modelo en tiempo real que tiene 3 características: “A”, “B” y “C”:
Figura 9: La depuración de discrepancias entre el entrenamiento-entrega generalmente requiere observar el “conjunto de datos de monitoreo” sin procesar y comparar los valores de las características de ambas rutas de datos. El conjunto de datos de monitoreo es solo una unión entre los datos de características del tiempo de entrenamiento y del tiempo de entrega.
Veamos ahora cómo priorizar las investigaciones y veamos ejemplos de tipos comunes de desajustes.
Concéntrate primero en las funciones más importantes
Si tienes que lidiar con discrepancias en muchas funciones, debes elegir en cuáles centrarte primero, especialmente cuando se trata de sesgos previos a la implementación; es común tener varias funciones sesgadas cuando implementas por primera vez tu modelo en tiempo real (con suerte en modo sombra para que no se produzcan daños).
Utiliza la importancia de las características (por ejemplo, valores SHAP) para decidir qué características investigar primero.
Comprender el tipo de desajuste
Ahora enumeraremos los tipos comunes de discrepancias, junto con las razones y soluciones más comunes.
Se explican en las siguientes subsecciones y se resumen en la siguiente tabla:
Valores nulos al momento de entrega
Supusiste (en el momento del entrenamiento) que alguna información estaría disponible en el momento de la inferencia, pero cuando implementas por primera vez el modelo en tiempo real, todos los valores de las características son NULL.
Esto puede ser una forma de fuga de datos: utilizaste información futura para crear funciones. Si esto sucede, verás valores NULL en el momento de la inferencia, mientras que tenías valores no nulos durante el entrenamiento. Es posible que debas eliminar estas funciones y volver a entrenar el modelo. Mira un ejemplo a continuación en la Figura 10:
Figura 10: Si solo tienes valores NULL para una función en el momento de la publicación, puede significar que hubo una fuga de datos durante el entrenamiento. Si ese es el caso, es posible que debas eliminar esta función y volver a entrenar el modelo.
Solo debes sospechar una fuga de datos si todos los valores de una característica son NULL en el momento de la publicación; Si solo algunos valores son NULL, el problema puede deberse a excepciones o tiempos de espera de tiempo de ejecución.
Valores nulos vs 0s
Es común que los valores NULL se mezclen con 0 (cero) durante la implementación de la función. Esto sucede con funciones basadas en recuentos, sumas y promedios. Una solución común es usar fillna(0) para reemplazar los NULL por ceros.
Ejemplo: El modelado se realizó con un paquete R que representa los tamaños de listas vacías como NULL. Pero en el momento de la entrega, las funciones se obtienen con código Java y la semántica puede ser diferente: los recuentos de listas vacías se representan como 0 (cero) en lugar de NULL. Consulta la Figura 11 a continuación:
Figura 11: Este es un ejemplo clásico de sesgo Nulo vs 0; ten en cuenta que solo tenemos discrepancias en los ejemplos en los que el valor real de la característica es 0; no hay discrepancias en el entrenamiento-entrega en los otros casos.
El valor del tiempo de servicio suele ser mayor
Cuando los valores de una característica son consistentemente más altos de lo que deberían ser, probablemente tengamos un error en los filtros y/o rangos de fechas utilizados en el momento de la entrega. Consulta la Figura 12 a continuación.
Ejemplo: Una de las características de un modelo de fraude es el número de compras liquidadas con tarjeta de crédito que realizó un cliente en el último mes. Sin embargo, la función se implementó incorrectamente en el momento de la entrega: en su lugar, utiliza todas las compras (liquidadas y no), por lo que las cifras a veces son más altas de lo que deberían haber sido.
Figura 12: Cuando los valores de las características son consistentemente más altos de lo que deberían ser, esto puede indicar que la implementación de la característica de tiempo de entrega está utilizando filtros demasiado flexibles e incluye más información de la que debería.
El valor del tiempo de servicio suele ser menor
Esto es análogo al tipo de discrepancia anterior: con valores más bajos en lugar de valores más altos de lo esperado. Consulta la Figura 13 a continuación para ver cómo se ve.
Ejemplo: Un modelo de calificación crediticia en tiempo real tiene una función llamada “num_transfers_last_day”, que contiene la cantidad de transferencias realizadas por un cliente en las últimas 24 horas. Sin embargo, el ingeniero encargado de implementarlo en el momento de la entrega pensó que se refería al número de transferencias en el día actual (es decir, desde las 00:00 hasta el momento actual).
Figura 13: En este caso, vemos que muchas instancias tienen valores más bajos de lo que deberían. Nuevamente, esto puede deberse a un filtro implementado incorrectamente, errores uno por uno, etc.
Ejemplos que no se puntúan al momento de entregar
A veces, los modelos en tiempo real terminan puntuando distribuciones de eventos que no existían en los datos de entrenamiento. Esto es peligroso porque no podemos confiar en las predicciones dadas a instancias muestreadas de una distribución diferente a la que se entrenó el modelo.
Ejemplo 1: Un banco entrenó un modelo para calificar el riesgo de incumplimiento crediticio del primer préstamo otorgado a un cliente. Sin embargo, los ingenieros implementaron por error el modelo para calificar también los préstamos posteriores.
Ejemplo 2: Se entrenó un modelo de fraude para detectar intentos de fraude en compras con tarjeta de crédito realizadas en línea. Sin embargo, un equipo de ingeniería implementó por error el modelo para calificar también las compras en persona.
Este tipo de sesgo se diferencia de los anteriores porque no se refiere a discrepancias de características, sino a casos en los que no se debe puntuar todo el ejemplo. En la Figura 14 vemos cómo este tipo de problema aparecería en el conjunto de datos de monitoreo: todos los valores de características de la ruta de datos de entrenamiento serán NULL.
Figura 14: Aquí vemos un caso en el que el modelo en tiempo real calificó dos ejemplos (ID 0004 y 0005), pero no aparecieron en el conjunto de datos de entrenamiento generado mediante programación. Es muy importante utilizar una unión EXTERIOR para unir ambos conjuntos de datos, de modo que los ejemplos en cualquiera de las rutas de datos aparezcan en el conjunto de datos de monitoreo.
Ten en cuenta que esto es diferente de la deriva de datos: la distribución no cambió debido al simple paso del tiempo, sino a diferencias en la forma en que se utiliza el modelo.
Consejos generales
Aquí hay algunos otros consejos y sugerencias generales que pueden ayudarte a lidiar con el sesgo en el entrenamiento-entrega.
Si puedes, utiliza una tienda de características.
Con un almacén de características, la tarea de calcular características se delega a un sistema especializado.
Las tiendas de funciones modernas admiten cálculos por lotes y en tiempo real, lo que evita la necesidad de preocuparse por el sesgo en entrenamiento-entrega. Estos sistemas suelen admitir semántica de escritura única, de modo que las características se definen en una capa superior de abstracción, en lugar de volver a codificarse en los sistemas de producción.
Diferencias de precisión de punto flotante
A veces, los datos de entrenamiento y entrega difieren solo en unos pocos decimales.
Una de las situaciones en las que esto sucede es cuando se utilizan diferentes tecnologías (por ejemplo, Python y Java) para crear funciones de tiempo de entrenamiento y entrega. Puede suceder que la precisión flotante sea diferente en ambos y termines con desajustes como los que se muestran a continuación en la Figura 15:
Figura 15: Las diferencias de precisión de punto flotante, como las que se muestran, no suelen ser indicativas de un problema real: reflejan la forma en que las diferentes tecnologías tratan los números de punto flotante.
Estas pequeñas diferencias no suelen contar como desajustes reales; por lo general, no tienen ningún impacto en los resultados del modelo. Aplica algo de holgura al comparar valores de coma flotante para evitar perder tiempo en esto.
Nombrar características con precisión
Los nombres de funciones bien escritos ayudan a evitar malentendidos entre los equipos de modelado e ingeniería. La siguiente tabla muestra ejemplos de nombres de funciones buenos y malos.
Estrecha comunicación entre científicos de datos e ingenieros de aprendizaje automático.
Como mencionamos anteriormente, los científicos de datos (DSs) y los ingenieros de aprendizaje automático (MLEs) son clave para llevar un modelo de aprendizaje automático a producción, encargándose del modelado y la implementación en tiempo real, respectivamente.
Deberían formar parte de un único equipo—como un escuadrón. Si diferentes equipos son responsables de modelar e implementar modelos, hay mayores posibilidades de que haya malentendidos que provoquen un sesgo en entrenamiento-entrega.
Probablemente puedas usar datos de muestra para monitorear
Monitorear los modelos de ML requiere mucho tiempo y es costoso. No es necesario utilizar todos los datos para monitorear el sesgo en entrenamiento-entrega.
Si utiliza datos muestreados, asegúrate de que sea una muestra determinista para que se incluyan muestras en ambas rutas de datos (entrenamiento y entrega). El muestreo basado en hash es una forma de hacerlo.
Implementaciones en modo sombra
La implementación del modo sombra se refiere a la implementación completa de un modelo en tiempo real, excepto el uso de sus predicciones para tomar decisiones. Esto se puede hacer con una bandera de característica (o una simple declaración if).
Puedes utilizar implementaciones en modo sombra para probar si hay discrepancias en entrenamiento-entrega, sin causar ningún daño al negocio, porque las predicciones no se utilizarán.
Conclusión
En resumen, el sesgo en entrenamiento-entrega es un problema importante en los modelos de aprendizaje automático en tiempo real, que surge de las diferencias entre los entornos de entrenamiento y entrega. Esto puede deberse a una falta de comunicación entre equipos o a cambios inesperados en las fuentes de datos.
Para mitigar esto, es vital monitorear y depurar discrepancias, centrándose en las características de gran importancia. Esto implica recopilar y comparar datos de características de las rutas de capacitación y servicio, y abordar los problemas a medida que surjan.
El uso de una tienda de funciones puede simplificar este proceso al subcontratar el cálculo de funciones a otros equipos. Además, mantener una buena comunicación entre los científicos de datos y los ingenieros de aprendizaje automático puede evitar malentendidos que conduzcan a sesgos.
La implementación de modelos en modo sombra, donde las predicciones no se utilizan para tomar decisiones, puede ayudar a probar las discrepancias entre los servicios de trenes sin impacto en el negocio. Al abordar el sesgo en entrenamiento-entrega, las empresas pueden garantizar que sus modelos de aprendizaje automático en tiempo real sean más precisos y confiables.
Descubre las oportunidades