Capítulo 4. Ingeniería de datos
Este trabajo se ha traducido utilizando IA. Agradecemos tus opiniones y comentarios: translation-feedback@oreilly.com
Introducción
En capítulos anteriores, se te presentaron conceptos abstractos. Ahora, pasaremos de esa introducción técnica a discutir detalles de implementación y opciones más subjetivas. Te mostraré cómo trabajamos con el arte de los datos de entrenamiento en la práctica, mientras recorremos la ampliación a proyectos más grandes y la optimización del rendimiento.
La ingesta de datos es el primer paso y uno de los más importantes. Y el primer paso para la ingestión es establecer y utilizar un sistema de registro de datos de entrenamiento (SoR). Un ejemplo de un SoR es una base de datos de datos de entrenamiento.
¿Por qué es difícil la ingestión de datos? Por muchas razones. Por ejemplo, los datos de formación son un concepto relativamente nuevo, existen diversos retos de formato y comunicación. El volumen, la variedad y la velocidad de los datos varían, y faltan normas bien establecidas, lo que da lugar a muchas formas de hacerlo.
Además, hay muchos conceptos, como el uso de una base de datos de datos de entrenamiento, y quién quiere acceder a qué cuando; que pueden no ser obvios, incluso para los ingenieros experimentados. Las decisiones de ingestión determinan, en última instancia, las consideraciones de consulta, acceso y exportación.
Este capítulo está organizado en:
Quién quiere utilizar los datos y cuándo quiere utilizarlos
Por qué importan los formatos de datos y los métodos de comunicación; piensa en el "juego del teléfono".
Una introducción a una base de datos de entrenamiento como sistema de registro
Aspectos técnicos básicos para empezar
Almacenamiento, necesidades específicas de los medios y versionado
Aspectos comerciales del formateo y la cartografía de datos
Acceso a los datos, seguridad y datos preetiquetados
Para lograr un enfoque basado en los datos o centrado en los datos, se necesitan herramientas, iteración y datos. Cuanta más iteración y más datos, más necesidad de una gran organización para manejarlos.
Puede que ingieras datos, los explores y los anotes en ese orden. O puede que pases directamente de la ingesta a la depuración de un modelo. Después de pasar al entrenamiento, puedes ingerir nuevas predicciones, depurarlas y utilizar el flujo de trabajo de anotación. Cuanto más te apoyes en tu base de datos para hacer el trabajo pesado, menos tendrás que hacerlo tú.
¿Quién quiere los datos?
Antes de sumergirnos en los retos y las especificidades técnicas, pongamos sobre la mesa los objetivos y los seres humanos implicados aquí, y hablemos de cómo la ingeniería de datos sirve a esos usuarios finales y sistemas. A continuación, trataré las razones conceptuales para querer una base de datos de datos de entrenamiento. Enmarcaré la necesidad de esto mostrando cómo es el caso por defecto sin ella, y luego cómo es con ella.
Para facilitar el debate, podemos dividirlo en grupos:
Anotadores
Científicos de datos
Programas ML (de máquina a máquina)
Ingenieros de aplicaciones
Otras partes interesadas
Anotadores
Los anotadores necesitan que se les sirvan los datos correctos de en el momento adecuado y con los permisos adecuados. A menudo, esto se hace a nivel de un solo archivo, y está impulsado por solicitudes de alcance muy específico. Se hace hincapié en los permisos y la autorización. Además, los datos deben entregarse en el momento adecuado, pero ¿qué es el "momento adecuado"? Bueno, en general significa acceso bajo demanda o en línea. Aquí es donde el archivo es identificado por un proceso de software, como un sistema de tareas, y servido con tiempos de respuesta rápidos.
Científicos de datos
La ciencia de datos suele examinar los datos en el nivel de conjunto. Se hace más hincapié en las capacidades de consulta, la capacidad de manejar grandes volúmenes de datos y el formateo. Idealmente, también existe la capacidad de profundizar en muestras específicas y comparar los resultados de distintos enfoques tanto cuantitativa como cualitativamente.
Programas de ML
Los programas de ML siguen un camino similar al de la ciencia de datos en . Las diferencias incluyen los esquemas de permisos (normalmente los programas tienen más acceso que los científicos de datos individuales), y la claridad sobre lo que sale a la superficie y cuándo (normalmente más orientado a la integración y a los procesos que al análisis bajo demanda). A menudo, los programas de ML pueden tener una integración o automatización definida por software.
Ingenieros de aplicaciones
A los ingenieros de aplicaciones les preocupa conseguir datos de la aplicación a la base de datos de datos de entrenamiento y cómo integrar la anotación y la supervisión a los usuarios finales. Las consultas por segundo (rendimiento) y el volumen de datos suelen ser las principales preocupaciones. A veces se asume erróneamente que existe un flujo lineal de datos desde un equipo de "ingestión", o la aplicación, hasta los científicos de datos.
Otras partes interesadas
Otras partes interesadas en los datos de formación de pueden ser el personal de seguridad, los profesionales de DevMLOps, los ingenieros de sistemas de respaldo, etc. A menudo, estos grupos tienen preocupaciones que afectan a varios dominios y se entrecruzan con las necesidades de otros usuarios y sistemas. Por ejemplo, la seguridad se preocupa de los permisos del usuario final ya mencionados. La seguridad también se preocupa de que un único científico de datos no sea un punto único de fallo crítico, por ejemplo, que tenga todo el conjunto de datos en su máquina o un acceso demasiado amplio a conjuntos remotos.
Ahora que tienes una visión general de los grupos implicados, ¿cómo hablan entre ellos? ¿Cómo trabajan juntos?
Un juego de teléfono
El teléfono es "un juego en el que vienes con una frase y luego se la susurras al oído a la persona sentada a tu lado. A continuación, esta persona tiene que susurrar lo que ha oído en el oído de la siguiente. Esto continúa en el círculo hasta que la última persona haya oído la frase. Los errores suelen acumularse en las repeticiones, de modo que la frase anunciada por el último jugador difiere significativamente de la del primero, normalmente con un efecto divertido o humorístico."1
Como analogía, puedes pensar en la ingeniería de datos subóptima como en un juego de teléfono, tal y como se muestra en la Figura 4-1. En cada etapa, aumentan los errores de datos acumulados. Y en realidad es incluso peor de lo que muestra ese gráfico. Esto se debe a que los sensores, los humanos, los modelos, los datos y los sistemas de ML interactúan entre sí de forma no lineal.
Figura 4-1. Sin un sistema de registro, los errores en los datos se acumulan como un juego de teléfono
A diferencia del juego, con los datos de entrenamiento, estos errores de no son humorísticos. Los errores en los datos causan un rendimiento deficiente, degradación del sistema y fallos, que provocan daños físicos y financieros en el mundo real. En cada etapa, cosas como formatos diferentes, definiciones de datos deficientes o inexistentes, y suposiciones, harán que los datos se deformen y distorsionen. Mientras que una herramienta puede conocer las propiedades "xyz", la siguiente puede que no. Y esto se repite. La siguiente herramienta no exportará todas las propiedades, o las modificará aleatoriamente, etc. Por triviales que parezcan estas cuestiones en la pizarra, siempre serán un problema en el mundo real.
Los problemas son especialmente frecuentes en contextos más amplios y multiequipo, y cuando no se tienen en cuenta las necesidades holísticas de todos los grupos principales. Al ser un área nueva con normas emergentes, incluso las cosas aparentemente sencillas están mal definidas. En otras palabras, la ingeniería de datos es especialmente importante para los datos de formación. Si tienes un proyecto greenfield (nuevo), ahora es el momento perfecto para planificar tu ingeniería de datos.
¿Cómo saber cuándo se necesita un sistema de registro? Exploremos eso a continuación.
Cuándo se necesita un sistema de registro
Desde la planificación de un nuevo proyecto hasta el replanteamiento de los proyectos existentes en , las señales de que ha llegado el momento de tener un sistema de registro de datos de formación incluyen las siguientes:
Hay pérdida de datos entre equipos, por ejemplo, porque cada equipo posee su propia copia de los datos.
Los equipos agregan los datos de otros equipos, pero sólo utilizan una pequeña parte de ellos, por ejemplo, cuando una consulta sería mejor.
Hay abuso o uso excesivo de formatos no estructurados o semiestructurados como CSV, cadenas, JSON, etc., por ejemplo, volcar la salida en muchos archivos CSV en un cubo.
Surgen casos en los que el formato sólo lo conoce la única aplicación que generó los datos. Por ejemplo, se pueden cargar datos no estructurados o mal estructurados a posteriori, esperando lo mejor.
Se asume en exceso que cada sistema funcionará en un orden específico, predefinido y en cadena, en lugar de un diseño más componible.
El rendimiento general del sistema no cumple las expectativas o los modelos tardan en enviarse o actualizarse.
Otra posibilidad es que simplemente no tengas un verdadero sistema de registro en ninguna parte. Si tienes un sistema, pero no representa holísticamente el estado de los datos de entrenamiento (por ejemplo, considerándolo sólo como un etiquetado en lugar de como el centro de gravedad del proceso), entonces su utilidad es probablemente baja. Esto se debe a que probablemente se requerirá un nivel de comunicación excesivo para realizar cambios (por ejemplo, cambiar el esquema no es una rápida llamada a la API o una interacción con la interfaz de usuario). También significa que los cambios que deberían hacer los usuarios finales deben discutirse como un cambio a nivel de ingeniería.
Si cada equipo posee su propia copia de los datos, habrá una sobrecarga innecesaria de comunicaciones e integración, y probablemente pérdida de datos. Esta copia suele ser el "pecado original", ya que en el momento en que haya varios equipos haciendo esto, se necesitará un cambio a nivel de ingeniería para actualizar el sistema general, lo que significa que las actualizaciones no serán fluidas, lo que hará que el rendimiento general del sistema no cumpla las expectativas.
Las expectativas de los usuarios y los formatos de los datos cambian con suficiente frecuencia como para que la solución no pueda ser un proceso automático demasiado rígido. Así que no pienses en esto en términos de automatización, sino más bien en términos de "¿dónde está el centro de gravedad de los datos de entrenamiento?". Debe estar en los humanos y en un sistema de registro, por ejemplo, una base de datos de datos de entrenamiento, para obtener los mejores resultados.
Planificar un gran sistema
Entonces, ¿cómo evitar el juego del teléfono? Empieza con la planificación. Aquí tienes un par de ideas para empezar, y luego te explicaré las buenas prácticas para la configuración propiamente dicha.
La primera es establecer en una unidad de trabajo significativa y relevante para tu negocio. Por ejemplo, para una empresa que hace análisis de vídeos médicos, podría ser un único procedimiento médico. Luego, dentro de cada procedimiento, piensa en cuántos modelos se necesitan (¡no des por supuesto uno!), con qué frecuencia se actualizarán, cómo fluirán los datos, etc. Trataremos esto con más profundidad en "Diseño general del sistema", pero por ahora sólo quiero asegurarme de que quede claro que la ingestión no suele ser cosa de "una vez y ya está". Es algo que necesitará un mantenimiento continuo, y probablemente una ampliación a lo largo del tiempo.
En segundo lugar, hay que pensar en el almacenamiento y el acceso a los datos, estableciendo un sistema de registro como una base de datos de formación. Aunque es posible "montártela tú mismo", es difícil tener en cuenta de forma holística las necesidades de todos los grupos. Cuanto más se utilice una base de datos de datos de entrenamiento, más fácil será gestionar la complejidad. Cuanto más se utilice el almacenamiento independiente, mayor será la presión sobre tu equipo para "reinventar la rueda" de la base de datos.
Hay algunos detalles específicos para construir un gran subsistema de ingestión. Normalmente, lo ideal es que estos sensores alimenten directamente un sistema de datos de entrenamiento. Piensa en cuánta distancia, o saltos, hay entre los sensores, las predicciones, los datos brutos y tus herramientas de datos de entrenamiento.
A menudo, los datos de producción deben ser revisados por humanos, analizados a un nivel determinado y, potencialmente, "minados" aún más en busca de mejoras. Cuantas más predicciones, más oportunidades de corrección del sistema. Tendrás que considerar cuestiones como ¿Cómo llegarán los datos de producción al sistema de datos de entrenamiento de forma útil? ¿Cuántas veces se duplican los datos durante los procesos de utillaje?
¿Cuáles son nuestros supuestos en torno a las distinciones entre los distintos usos de los datos? Por ejemplo, consultar los datos dentro de una herramienta de datos de formación se adapta mejor que esperar que un científico de datos exporte a todos los datos y los consulte después por sí mismo.
Enfoques ingenuos y centrados en los datos de entrenamiento
Hay dos enfoques principales que la gente tiende a adoptar para trabajar con datos de entrenamiento. Uno lo denominaré "ingenuo", y el otro está más centrado en la importancia de los propios datos (centrado en los datos).
Los enfoques ingenuos tienden a ver los datos de entrenamiento como un simple paso que hay que atornillar a una serie de pasos ya existentes. Los enfoques centrados en los datos ven las acciones humanas de supervisión de los datos como el "centro de gravedad" del sistema. Muchos de los enfoques de este libro se alinean bien o equivalen directamente a estar centrados en los datos, lo que en cierto modo hace que la mentalidad de entrenar primero los datos sea sinónimo de estar centrada en los datos.
Por ejemplo, una base de datos de datos de entrenamiento tiene las definiciones, y/o el almacenamiento literal, de los datos brutos, las anotaciones, el esquema y el mapeo para el acceso de máquina a máquina.
Naturalmente, hay cierto solapamiento en los enfoques. En general, cuanto mayor es la competencia del enfoque ingenuo, más empieza a parecerse a una recreación de uno centrado en los datos de entrenamiento. Aunque es posible conseguir resultados deseables utilizando otros enfoques, es mucho más fácil conseguirlos sistemáticamente con un enfoque centrado en los datos de entrenamiento.
Empecemos por ver cómo funcionan normalmente los planteamientos ingenuos.
Enfoques ingenuos
Normalmente, en un enfoque ingenuo, los sensores capturan, almacenan y consultan los datos independientemente de la herramienta de datos de entrenamiento, como se muestra en la Figura 4-2. Esto suele acabar pareciendo un proceso lineal, con condiciones de inicio y fin preestablecidas.
Figura 4-2. Ejemplo de proceso ingenuo de ingeniería de datos
Las razones más comunes por las que se utilizan enfoques ingenuos:
El proyecto comenzó antes de que los enfoques centrados en los datos de formación tuvieran un soporte maduro de herramientas.
Los ingenieros no conocían los enfoques centrados en los datos de formación.
Pruebas y desarrollo de nuevos sistemas.
Datos antiguos, históricos, sin posibilidad de que lleguen datos nuevos (raro).
Casos en los que no es práctico utilizar un enfoque centrado en los datos de entrenamiento (poco frecuentes).
Los enfoques ingenuos tienden a parecerse a el juego del teléfono mencionado anteriormente. Como cada equipo tiene su propia copia de los datos, los errores se acumulan a medida que esos datos se van pasando de unos a otros. Como no hay un sistema de registro, o el sistema de registro no contiene el estado completo de los datos de entrenamiento, es difícil hacer cambios a nivel de usuario. En general, cuanto más difícil es hacer cambios con seguridad, más lento es enviar e iterar, y peores son los resultados globales.
Además, los enfoques ingenuos tienden a estar acoplados a procesos humanos ocultos o indefinidos. Por ejemplo, algún ingeniero en algún lugar tiene un script en su máquina local que hace alguna parte crítica del flujo general, pero ese script no está documentado o no es accesible a otros de forma razonable. Esto suele ocurrir por falta de comprensión de cómo utilizar una base de datos de datos de entrenamiento, en lugar de ser una acción intencionada.
En los enfoques ingenuos, hay más posibilidades de que los datos se dupliquen innecesariamente. Esto aumenta los costes de hardware, como el almacenamiento y el ancho de banda de la red, además de los ya mencionados cuellos de botella conceptuales entre equipos. También puede introducir problemas de seguridad, ya que las distintas copias pueden mantener posturas de seguridad diferentes. Por ejemplo, un equipo que agregue o correlacione datos podría eludir la seguridad de un sistema anterior en la cadena de procesamiento.
Un supuesto importante en los enfoques ingenuos es que un administrador humano revisa manualmente los datos (normalmente sólo a nivel de conjunto), de modo que sólo se importan los datos que parece que se desea anotar. En otras palabras, sólo se importan los datos designados previamente (normalmente a través de un medio relativamente inconsistente) para ser anotados. Esta suposición de "administración aleatoria antes de la importación" dificulta la supervisión eficaz de los datos de producción y el uso de métodos de exploración, y en general atasca el proceso debido a la naturaleza manual e indefinida del proceso de curación oculta. Esencialmente, esto es confiar en suposiciones implícitas impulsadas por los administradores, en lugar de definir explícitamente los procesos con múltiples partes interesadas, incluidas las PYMES. Para que quede claro, no se trata de la revisión de los datos, sino de la distinción entre un proceso impulsado a nivel de un equipo más amplio que es mejor que una sola persona administradora trabajando de forma más arbitraria.
Piensa en esto conceptualmente, no en términos de automatización literal. Un proceso de ingesta definido por software es, por sí mismo, poco indicativo de la salud general de un sistema, ya que no habla de ninguna de las preocupaciones arquitectónicas reales en torno al uso de una base de datos de datos de entrenamiento.
Centrado en los datos de formación (sistema de registro)
Otra opción es utilizar un enfoque centrado en los datos de entrenamiento. Una base de datos de datos de entrenamiento, como se muestra en la Figura 4-3, es el corazón de un enfoque centrado en los datos de entrenamiento. Constituye el sistema de registro de tus aplicaciones.
Figura 4-3. Base de datos de datos de entrenamiento (sistema de registro)
Una base de datos de datos de entrenamiento tiene las definiciones, y/o el almacenamiento literal, de los datos en bruto, las anotaciones, el esquema y el mapeo para el acceso de máquina a máquina, y mucho más. Idealmente, es la definición completa del sistema, lo que significa que, dada la base de datos de datos de entrenamiento, podrías reproducir todo el proceso de ML sin trabajo adicional.
Cuando utilizas una base de datos de datos de entrenamiento como sistema de registro, dispones de un lugar central para que todos los equipos almacenen y accedan a los datos de entrenamiento. Cuanto mayor sea el uso de la base de datos, mejores serán los resultados globales, de forma similar a como se sabe que es esencial el uso adecuado de una base de datos en una aplicación tradicional.
Las razones más comunes para utilizar una base de datos de datos de entrenamiento:
Apoya un cambio hacia el aprendizaje automático centrado en los datos . Esto significa centrarse en mejorar el rendimiento general mejorando los datos, en lugar de limitarse a mejorar el algoritmo del modelo.
Permite alinear más fácilmente varios programas de ML al tener las definiciones de los datos de entrenamiento en un solo lugar.
Admite que los usuarios finales supervisen (anoten) los datos y permite incrustar la supervisión del usuario final más profundamente en los flujos de trabajo y las aplicaciones.
El acceso a los datos se basa ahora en consultas, en lugar de requerir una duplicación masiva y pasos adicionales de agregación.
Siguiendo con el tema de la distinción entre datos de entrenamiento y ciencia de datos, en los puntos de integración, naturalmente, la línea será la más borrosa. En la práctica, es razonable invocar programas de ML desde un sistema de datos de entrenamiento.
Otras razones para utilizar una base de datos de entrenamiento son las siguientes:
Desacopla los requisitos visuales de la interfaz de usuario del modelado de datos (por ejemplo, los mecanismos de consulta ).
Permite un acceso más rápido a nuevas herramientas para el descubrimiento de datos, qué etiquetar y mucho más.
Permite tipos de archivo definidos por el usuario, por ejemplo, representar una "Interacción" como un conjunto de imágenes y texto, lo que admite la iteración fluida y los cambios impulsados por el usuario final.
Evita la duplicación de datos y almacena las definiciones y relaciones de los mapas externos en un solo lugar.
Desbloquea a los equipos para que trabajen tan rápido como puedan, en lugar de esperar a que se completen etapas discretas.
El planteamiento de una base de datos de datos de entrenamiento plantea algunos problemas:
Utilizar uno requiere conocer su existencia y comprenderlo conceptualmente.
El personal debe disponer del tiempo, la capacidad y los recursos necesarios para utilizar una base de datos de formación.
Los patrones de acceso a los datos bien establecidos pueden requerir un reajuste al nuevo contexto.
Su fiabilidad como sistema de registro no tiene la misma historia que tienen los sistemas más antiguos.
Lo ideal es que, en lugar de decidir qué datos en bruto se envían (por ejemplo, de una aplicación a la base de datos), primero se envíen todos los datos relevantes a la base de datos, antes de que los humanos seleccionen las muestras que van a etiquetar. Esto ayuda a garantizar que se trata del verdadero sistema de registro. Por ejemplo, puede haber un programa "qué etiquetar" que utilice todos los datos, aunque los humanos sólo revisen una muestra de ellos. Tener todos los datos a disposición del programa "qué etiquetar" a través de la base de datos de entrenamiento facilita esta tarea. La forma más fácil de recordar esto es pensar en la base de datos de datos de entrenamiento como el centro de gravedad del proceso.
La base de datos de datos de entrenamiento asume la función de gestionar las referencias a los soportes brutos, o incluso contiene el almacenamiento literal en bytes de los mismos. Esto significa enviar los datos directamente a la herramienta de datos de entrenamiento. En la implementación real, podría haber una serie de pasos de procesamiento, pero la idea es que el lugar de reposo final de los datos, la fuente de la verdad, esté dentro de la base de datos de datos de entrenamiento.
Una base de datos de datos de entrenamiento es la definición completa del sistema, lo que significa que, dada la base de datos de datos de entrenamiento, puedes crear, gestionar y reproducir todas las necesidades de aplicación de ML del usuario final, incluidos los procesos de ML, sin trabajo adicional. Esto va más allá de MLOps, que es un enfoque que a menudo se centra más en la automatización, el modelado y la reproducibilidad, puramente en el lado del ML. Puedes pensar en los MLOps como una subpreocupación de un enfoque más estratégico centrado en los datos de entrenamiento.
Una base de datos de datos de entrenamiento tiene en cuenta a múltiples usuarios desde el primer día y planifica en consecuencia. Por ejemplo, una aplicación diseñada para apoyar la exploración de datos puede establecer que los índices para el descubrimiento de datos se creen automáticamente en la ingesta. Cuando guarda las anotaciones, también puede crear índices para el descubrimiento, el streaming, la seguridad, etc., todo al mismo tiempo.
Un tema estrechamente relacionado es el de la exportación de los datos a otras herramientas. Quizá quieras ejecutar algún proceso para explorar los datos, y luego necesites enviarlos a otra herramienta para un proceso de seguridad, como difuminar la información personal identificable. A continuación, tienes que enviarlos a otra empresa para que los anote, y luego recibir los resultados de ellos e introducirlos en tus modelos, etc. Y digamos que en cada uno de estos pasos hay un problema de mapeo (definiciones). La herramienta A produce resultados en un formato distinto al de las entradas de la herramienta B. Este tipo de transferencia de datos suele requerir órdenes de magnitud más de recursos informáticos que cuando se utilizan otros sistemas comunes. En cierto sentido, cada transferencia es más bien una minitransferencia de base de datos, porque todos los componentes de los datos tienen que pasar por el proceso de conversión. Esto también se trata en "Escala".
En general, cuanto más estrecha sea la conexión entre los sensores y las herramientas de datos de entrenamiento, más posibilidades habrá de que todos los usuarios finales y las herramientas sean eficaces juntos. Cualquier otro paso que se añada entre los sensores y las herramientas tiene prácticamente garantizado ser un cuello de botella. Al mismo tiempo, se puede hacer una copia de seguridad de los datos en algún otro servicio, pero en general, esto significa organizar los datos en las herramientas de datos de entrenamiento desde el primer día.
Los primeros pasos
Supongamos que estás de acuerdo en utilizar un enfoque centrado en los datos de formación. ¿Cómo empiezas realmente?
Los primeros pasos son
Establecer las definiciones de la base de datos de datos de entrenamiento
Configurar la ingesta de datos
Consideremos primero las definiciones. Una base de datos de datos de entrenamiento pone todos los datos en un solo lugar, incluidas las definiciones de mapeo a otros sistemas. Esto significa que hay un único lugar para el sistema de registro y las definiciones de mapeo asociadas a los módulos que funcionan dentro del sistema de datos de entrenamiento y fuera de él. Esto reduce los errores de mapeo, las necesidades de transferencia de datos y la duplicación de datos.
Antes de empezar realmente a ingerir datos, aquí tienes algunos términos más que hay que cubrir primero:
Almacenamiento de datos brutos
Problemas específicos de los BLOB de medios en bruto
Formateo y mapeo
Acceso a los datos
Cuestiones de seguridad
Empecemos por el almacenamiento de datos en bruto.
Almacenamiento de datos brutos
El objetivo es conseguir los datos en bruto, como imágenes, vídeo y texto, en una forma utilizable para el trabajo con datos de entrenamiento. Según el tipo de medio, esto puede ser más fácil o más difícil. Con pequeñas cantidades de datos de texto, la tarea es relativamente fácil; con grandes cantidades de vídeo o incluso datos más especializados como los genómicos, se convierte en un reto central.
Es habitual almacenar datos sin procesar en una abstracción de cubo. Esto puede ser en la nube o utilizando software como MinIO. A algunas personas les gusta pensar en estos cubos en la nube como "vuélcalo y olvídalo", pero en realidad hay muchas opciones de ajuste del rendimiento disponibles. A escala de los datos de entrenamiento, las opciones de almacenamiento en bruto importan. Hay algunas consideraciones importantes que debes tener en cuenta al identificar tu solución de almacenamiento:
- Clase de almacenamiento
- Hay más diferencias importantes entre los niveles de almacenamiento de de lo que pueda parecer a primera vista. Las compensaciones tienen que ver con cosas como el tiempo de acceso, la redundancia, la geodisponibilidad, etc. Hay diferencias de precio de órdenes de magnitud entre los niveles. La herramienta más importante que debes conocer son las reglas del ciclo de vida, por ejemplo, las de Amazon S3, en las que, normalmente con unos pocos clics, puedes establecer políticas para mover automáticamente los archivos antiguos a opciones de almacenamiento más baratas a medida que envejecen. Puedes encontrar ejemplos de buenas prácticas más detallados en el sitio de Diffgram.
- Geolocalización (alias Zona, Región)
- ¿Estás almacenando datos a un lado del Océano Atlántico y haciendo que los anotadores accedan a ellos al otro? Merece la pena considerar dónde se espera que se produzca la anotación real, y si hay opciones para almacenar los datos más cerca de ella.
- Apoyo al vendedor
- No todas las herramientas de anotación tienen el mismo grado de compatibilidad con los principales proveedores. Ten en cuenta que normalmente puedes integrar manualmente cualquiera de estas ofertas, pero esto requiere más esfuerzo que las herramientas que tienen integración nativa.
El soporte para acceder a los datos de estos proveedores de almacenamiento es diferente de la herramienta que se ejecuta en ese proveedor. Algunas herramientas pueden admitir el acceso desde los tres, pero como servicio, la propia herramienta se ejecuta en una única nube. Si tienes un sistema que instalas en tu propia nube, normalmente la herramienta soportará las tres.
Por ejemplo, puedes optar por instalar el sistema en Azure. A continuación, puedes introducir datos en la herramienta desde Azure, lo que mejora el rendimiento. Sin embargo, eso no te impide extraer datos de Amazon y Google cuando sea necesario.
Por referencia o por valor
Almacenar por referencia significa almacenar sólo pequeños fragmentos de información , como cadenas o IDs, que te permitan identificar y acceder a los bytes en bruto en un sistema fuente existente. Por valor significa copiar los bytes literales. Una vez copiados en el sistema de destino, no hay dependencia del sistema de origen.
Si quieres mantener tu estructura de carpetas, algunas herramientas permiten referenciar los archivos en lugar de transferirlos realmente. La ventaja de esto es una menor transferencia de datos. La desventaja es que ahora es posible que haya enlaces rotos. Además, la separación de intereses podría ser un problema; por ejemplo, algún otro proceso podría modificar un archivo al que la herramienta de anotación espera poder acceder.
Aunque utilices un enfoque de paso por referencia para los datos brutos, es crucial que el sistema de verdad sea la base de datos de los datos de entrenamiento. Por ejemplo, los datos pueden estar organizados en conjuntos en la base de datos que no están representados en la organización por cubos. Además, el cubo sólo representa los datos brutos, mientras que la base de datos tendrá las anotaciones y otras definiciones asociadas.
Para simplificar, es mejor pensar en la base de datos de datos de entrenamiento como una abstracción, aunque los datos brutos se almacenen fuera del hardware físico de la base de datos , como se muestra en la Figura 4-4.
Figura 4-4. Base de datos de datos de entrenamiento con referencias a datos brutos almacenados externamente
Herramientas de datos de formación dedicadas y listas para usar en tu propio hardware
Supongamos que tu herramienta es de confianza (quizás hayas podido inspeccionar el código fuente). En este contexto, confiamos en que la herramienta de datos de entrenamiento gestione el proceso de URL firmada y se ocupe de los asuntos relacionados con la gestión de identidades y accesos (IAM). Una vez establecido esto, la única preocupación real es qué cubo utiliza, y eso generalmente se convierte en una preocupación puntual, porque la herramienta gestiona la IAM. Para casos avanzados, la herramienta puede vincularse a un inicio de sesión único (SSO) o a un esquema IAM más complejo.
Nota: La herramienta no tiene por qué ejecutarse en el hardware. El siguiente nivel es confiar en la herramienta de datos de entrenamiento, y también confiar en el proveedor de servicios para alojar/procesar los datos. Aunque ésta es una opción, ten en cuenta que proporciona el menor nivel de control.
Almacenamiento de datos: ¿Dónde reposan los datos?
En general, cualquier forma de herramienta generará algún tipo de dato que se añade a los datos "originales". Los datos BLOB suelen almacenarse por referencia, o desplazándolos físicamente.
Esto significa que si tengo datos en el cubo A, y utilizo una herramienta para procesarlos, tiene que haber datos adicionales en el cubo A, o necesitaré un nuevo cubo, B, para que lo utilice la herramienta. Esto es cierto para Diffgram, SageMaker y, que yo sepa, la mayoría de las herramientas importantes.
Dependiendo de tus objetivos de coste y rendimiento, esto puede ser una cuestión crítica o de poca importancia. A nivel práctico, para la mayoría de los casos de uso, sólo tienes que tener en cuenta dos conceptos sencillos:
Espera que se generen datos adicionales.
Conoce dónde se almacenan los datos, pero no lo pienses demasiado.
Del mismo modo, no nos cuestionamos realmente cuánto almacenamiento genera, por ejemplo, un Registro de escritura en cabeza (WAL) de PostgreSQL. Mi opinión personal es que es mejor confiar en la herramienta de datos de entrenamiento a este respecto. Si hay algún problema, resuélvelo dentro del ámbito de influencia de la herramienta de datos de entrenamiento.
Conexión de referencia externa
Una abstracción útil para crear es una conexión desde la herramienta de datos de entrenamiento a una referencia externa existente, por ejemplo, un cubo en la nube. Hay varias opiniones sobre cómo hacer esto, y los detalles varían según el hardware y el proveedor de la nube.
Para el usuario no técnico, esto es esencialmente "iniciar sesión" en un bucket. En otras palabras, creo un nuevo bucket, A, y obtiene un ID de usuario y una contraseña (ID de cliente/secreto de cliente) del sistema IAM. Paso esas credenciales a la herramienta de datos de entrenamiento y ésta las almacena de forma segura. Entonces, cuando lo necesite, la herramienta de datos de entrenamiento utilizará esas credenciales para interactuar con el cubo.
Medios sin procesar (BLOB)-Tipo específico
Un BLOB es un Objeto Grande Binario. Es la forma de datos en bruto de un medio, y también se conoce como "objeto". La tecnología que almacena los BLOB de datos en bruto se llama "cubo" o "almacén de objetos". Dependiendo de tu tipo de medio, habrá problemas específicos. Cada tipo de soporte tendrá muchas más preocupaciones de las que se pueden enumerar aquí. Debes investigar cada tipo según tus necesidades. Una base de datos de datos de entrenamiento ayudará a formatear los BLOB para que sean útiles a múltiples usuarios finales, como anotadores y científicos de datos. A continuación, señalo algunas de las consideraciones más comunes que debes tener en cuenta.
Vídeo
Es habitual dividir los archivos de vídeo en clips más pequeños para facilitar la anotación y el procesamiento. Por ejemplo, un vídeo de 10 minutos puede dividirse en clips de 60 segundos.
El muestreo de fotogramas es una forma de reducir la sobrecarga de procesamiento. Esto puede hacerse reduciendo la velocidad de fotogramas y extrayendo fotogramas. Por ejemplo, puedes convertir un archivo de 30 fotogramas por segundo (FPS) a 5 ó 10 por segundo. Un inconveniente es que perder demasiados fotogramas puede dificultar la anotación (por ejemplo, puede cortarse un momento clave del vídeo) o puedes perder la capacidad de utilizar otras funciones de vídeo relevantes como la interpolación o el seguimiento (que se basan en suposiciones sobre la existencia de una determinada frecuencia de fotogramas). Normalmente, es mejor mantener el vídeo como un vídeo reproducible y extraer también todos los fotogramas necesarios. Esto mejora la experiencia de anotación del usuario final y maximiza la capacidad de anotación.
Los análisis centrados en sucesos necesitan el fotograma exacto en el que ocurre algo, que efectivamente se pierde si se eliminan muchos fotogramas. Además, con todos los fotogramas intactos, los datos completos están disponibles para ser muestreados por algoritmos de "búsqueda de puntos destacados interesantes". Esto hace que los anotadores vean que ocurren más cosas "interesantes" y, por tanto, datos de mayor calidad. El seguimiento de objetos y la interpolación refuerzan aún más este punto, ya que un anotador puede que sólo necesite etiquetar un puñado de fotogramas y a menudo puede recuperar muchos "gratis" mediante esos algoritmos. Y aunque, en la práctica, los fotogramas cercanos suelen ser similares, a menudo sigue siendo útil disponer de los datos adicionales.
Una excepción a esto es que, a veces, un vídeo de FPS muy altos (por ejemplo, 240-480+) puede necesitar un muestreo a 120 FPS o similar. Ten en cuenta que, aunque haya muchos fotogramas disponibles para ser anotados, aún podemos elegir entrenar los modelos sólo con los vídeos completos, los fotogramas completos de , etc. Si debes reducir la muestra de los fotogramas, utiliza el fotograma de referencia global para mantener la correspondencia del fotograma reducido con el fotograma original.
Texto
Tendrás que seleccionar el tokenizador que desees o confirmar que el tokenizador utilizado por el sistema satisface tus necesidades. El tokenizador divide las palabras, por ejemplo basándose en espacios o utilizando algoritmos más complejos, en componentes más pequeños. Hay muchos tokenizadores de código abierto y una descripción más detallada de esto queda fuera del alcance de este libro. También puedes necesitar un proceso para convertir archivos BLOB (por ejemplo, .txt) en cadenas o viceversa.
Geoespacial
GeoTiff y Cloud-Optimized GeoTIFF (COG) son formatos estándar en el análisis geoespacial. No todas las herramientas de datos de entrenamiento admiten ninguno de los dos formatos; sin embargo, cuando se ofrece soporte, la tendencia parece decantarse por COG. Ten en cuenta que puede ser necesario un cambio de proyección cartográfica para normalizar las capas.
Formateo y mapeo
Los medios en bruto son una parte del rompecabezas. Las anotaciones y predicciones son otra gran parte. Piensa en términos de establecer definiciones de datos en lugar de una importación única. Cuanto mejores sean tus definiciones, más fácilmente podrán fluir los datos entre las aplicaciones de ML, y más podrán actualizarlos los usuarios finales sin ingeniería.
Tipos definidos por el usuario (archivos compuestos)
Los casos del mundo real suelen implicar más de un archivo. Por ejemplo, un carné de conducir tiene un anverso y un reverso. Podemos pensar en crear un nuevo tipo de "carné de conducir" definido por el usuario y hacer que admita dos archivos hijos, cada uno de los cuales sea una imagen. O podemos considerar una conversación de "texto enriquecido" que tenga varios archivos de texto, imágenes, etc.
Definir mapas de datos
Un DataMap gestiona la carga y descarga de definiciones entre aplicaciones. Por ejemplo, puede cargar datos en un sistema de formación del modelo o en un analizador "Qué etiquetar". Tener estas definiciones bien definidas permite integraciones fluidas por parte de los usuarios finales, y desacopla la necesidad de cambios a nivel de ingeniería. En otras palabras, desvincula el momento en que se llama a una aplicación de la propia definición de los datos. Algunos ejemplos son la declaración de un mapeo entre ubicaciones espaciales formateadas como x_min, y_min, x_max, y_max y top_left, bottom_right, o el mapeo de resultados enteros de un modelo de vuelta a un esquema.
Ingerir magos
Una de las mayores lagunas en las herramientas suele girar en torno a la pregunta: "¿Es difícil configurar mis datos en el sistema y mantenerlo?". Luego viene ¿qué tipo de medios puede ingerir? ¿Con qué rapidez puede ingerirlos?
Este es un problema que todavía no está tan bien definido como en otras formas de software. ¿Sabes cuando recibes un enlace a un documento y lo cargas por primera vez? ¿O algún documento grande empieza a cargarse en tu ordenador?
Recientemente, han aparecido nuevas tecnologías como los "Asistentes de importación" -formularios paso a paso- que ayudan a facilitar parte del proceso de importación de datos. Aunque espero que estos procesos sigan haciéndose aún más fáciles con el tiempo, cuanto más conozcas los aspectos entre bastidores, más entenderás cómo funcionan realmente estos nuevos y maravillosos asistentes. Esto empezó originalmente con exploradores de archivos para sistemas basados en la nube, y ha progresado hasta convertirse en motores de mapeo completos, similares a las aplicaciones de cambio inteligente para teléfonos, como la que te permite pasar todos tus datos de Android a iPhone, o viceversa.
A alto nivel, el funcionamiento consiste en que un motor de mapeo (por ejemplo, parte del asistente de ingesta) te guía a través del proceso de mapeo de cada campo de una fuente de datos a otra. Los asistentes de mapeo ofrecen un valor enorme. Evitan tener que hacer una integración más técnica. Suelen proporcionar más validaciones y comprobaciones para asegurar que los datos son los que esperas (imagínate ver una vista previa de un correo electrónico en Gmail antes de comprometerte a abrirlo). Y lo mejor de todo es que, una vez configuradas las asignaciones, ¡se pueden cambiar fácilmente desde una lista sin necesidad de cambiar de contexto!
Es difícil exagerar el impacto de esto. Antes, podías haber dudado, por ejemplo, en probar una nueva arquitectura de modelos, un servicio comercial de predicción, etc., debido a los matices de obtener y enviar los datos. Esto alivia drásticamente esa presión.
¿Cuáles son las limitaciones de los asistentes? Bueno, en primer lugar, algunas herramientas aún no los admiten, así que puede que simplemente no estén disponibles. Otra cuestión es que pueden imponer limitaciones técnicas que no están presentes en las llamadas a API más puras o en las integraciones SDK.
Organización de datos y almacenamiento útil
Uno de los primeros retos suele ser cómo organizar los datos que ya has capturado (o capturarás). Una de las razones por las que esto es más difícil de lo que puede parecer a primera vista es que, a menudo, estos conjuntos de datos en bruto se almacenan a distancia.
En el momento de escribir esto, los navegadores de almacenamiento de datos en la nube suelen estar menos maduros que los navegadores de archivos locales. Por eso, incluso las operaciones más sencillas, como sentarme ante una pantalla y arrastrar archivos, pueden suponer un nuevo reto.
Aquí tienes algunas sugerencias prácticas:
Intenta introducir los datos en tu herramienta de anotación antes en el proceso que después. Por ejemplo, al mismo tiempo que llegan nuevos datos, puedo escribir la referencia de los datos en la herramienta de anotación en un momento similar al que escribo en un almacén de objetos genérico. De este modo, puedo organizarlo "automáticamente" hasta cierto punto, y/o conseguir más fácilmente que los miembros del equipo me ayuden con las tareas a nivel de organización.
Considera la posibilidad de utilizar herramientas que ayuden a sacar a la superficie los datos "más interesantes". Se trata de un área emergente, pero ya está claro que estos métodos, aunque no están exentos de dificultades, tienen mérito y parecen estar mejorando.
Utiliza etiquetas. Aunque suene sencillo, etiquetar los conjuntos de datos con información organizativa a nivel empresarial ayuda. Por ejemplo, el conjunto de datos "Sensor de tren 12" puede etiquetarse como "Cliente ABC". Las etiquetas pueden ser transversales a las preocupaciones de la ciencia de datos y permitir tanto el control empresarial/organizativo como los objetivos a nivel de ciencia de datos.
Almacenamiento remoto
Los datos suelen almacenarse de forma remota en relación con el usuario final. Esto se debe al tamaño de los datos, los requisitos de seguridad y los requisitos de automatización (por ejemplo, la conexión desde un programa integrado, los aspectos prácticos de la ejecución de la inferencia del modelo, la agregación de datos de nodos/sistema). En cuanto al trabajo en equipo, la persona que administra los datos de entrenamiento puede no ser la persona que recogió los datos (considera los casos de uso en medicina, ejército, construcción in situ, etc.).
Esto es relevante incluso para las soluciones sin conexión externa a Internet, también conocidas comúnmente como soluciones de nivel secreto "encapsuladas en el aire". En estos casos, sigue siendo probable que el sistema físico que aloja los datos se encuentre en un lugar distinto al del usuario final, aunque estén sentados a medio metro el uno del otro.
La implicación de que los datos estén en otro lugar es que ahora necesitamos una forma de acceder a ellos. Como mínimo, quien esté anotando los datos necesita acceso, y lo más probable es que algún tipo de proceso de preparación de datos también lo requiera.
Versionado
El control de versiones es importante para la reproducibilidad. Dicho esto , a veces se presta demasiada atención al control de versiones. En la práctica, para la mayoría de los casos de uso, ser consciente de los conceptos de alto nivel, utilizar instantáneas y tener un buen sistema general de definiciones de registros te llevará muy lejos.
Hay tres niveles principales de versionado de datos: por instancia (anotación), por archivo y exportación. Su relación entre sí se muestra en la Figura 4-5.
Figura 4-5. Comparación de versiones de alto nivel
A continuación, presentaré cada uno de ellos a alto nivel.
Historial por instancia
Por defecto, las instancias no se borran con fuerza . Cuando se realiza una edición en una instancia existente, Diffgram la marca como borrado suave y crea una nueva instancia que la sucede, como se muestra en la Figura 4-6. Podrías utilizarlo, por ejemplo, para la anotación en profundidad o la auditoría de modelos. Se supone que las instancias de soft_deleted no se devuelven cuando se extrae la lista de instancias por defecto de un archivo.
Figura 4-6. Izquierda, historial por instancia en la IU; derecha, una única comparación diferencial entre la misma instancia en distintos momentos del tiempo.
Por archivo y por juego
Cada conjunto de tareas puede configurarse para que cree automáticamente copias por archivo en cada etapa de la cadena de procesamiento. Esto mantiene automáticamente múltiples versiones a nivel de archivo relevantes para el esquema de tareas.
También puedes organizar y copiar datos programática y manualmente en conjuntos bajo demanda. Puedes filtrar los datos por etiquetas, como por ejemplo por una ejecución específica de aprendizaje automático. Luego, compara entre archivos y conjuntos para ver qué ha cambiado.
Añade archivos a varios conjuntos para los casos en que quieras que los archivos estén siempre en la última versión. Eso significa que puedes construir varios conjuntos, con criterios diferentes, y tener al instante la última versión a medida que se produce la anotación. Fundamentalmente, se trata de una versión viva, por lo que es fácil estar siempre en la "última".
Puedes utilizar estos bloques de construcción para gestionar de forma flexible las versiones a través del trabajo en curso a nivel de administrador.
Instantáneas por exportación
Con las instantáneas por exportación, cada exportación se almacena automáticamente en caché en un archivo estático. Esto significa que puedes tomar una instantánea en cualquier momento, para cualquier consulta, y tener una forma repetible de acceder a ese conjunto exacto de datos. Esto puede combinarse con webhooks, SDKs o scripts de usuario para generar exportaciones automáticamente. Éstas pueden generarse bajo demanda, en cualquier momento. Por ejemplo, puedes utilizar instantáneas por exportación para garantizar que un modelo accede exactamente a los mismos datos. La cabecera de una exportación se muestra como ejemplo en la Figura 4-7.
Figura 4-7. Ejemplo de vista de lista de la IU de exportación
A continuación, trataremos con más detalle los intercambios de patrones de exportación y acceso en Acceso a Datos.
Acceso a los datos
Hasta ahora, hemos cubierto conceptos generales de arquitectura de , como el uso de una base de datos de datos de entrenamiento para evitar un juego de teléfono. Hemos tratado los conceptos básicos para empezar, el almacenamiento de medios, los conceptos de mapeo y los BLOB y otros formatos. Ahora hablaremos de las anotaciones propiamente dichas. Una ventaja de utilizar un enfoque centrado en los datos de entrenamiento es que tienes incorporadas las buenas prácticas, como las instantáneas y el streaming.
El streaming es un concepto independiente de la consulta, pero va de la mano en las aplicaciones prácticas. Por ejemplo, puedes ejecutar una consulta que dé como resultado 1/100 de los datos de una exportación a nivel de archivo, y luego transmitir esa porción de los datos directamente en código.
Hay algunos conceptos importantes que debes tener en cuenta:
Exportaciones basadas en archivos
Streaming
Consulta de datos
Desambiguar el almacenamiento, la ingestión, la exportación y el acceso
Una forma de pensar en esto es que, a menudo, la forma en que se utilizan los datos en una base de datos es diferente de cómo se almacenan en reposo y de cómo se consultan. Los datos de entrenamiento son similares. Hay procesos para ingerir los datos, procesos diferentes para almacenarlos, y otros diferentes de nuevo para consultarlos:
El almacenamiento de datos en bruto se refiere a el almacenamiento literal de los BLOB, y no de las anotaciones, que se supone que se guardan en una base de datos aparte.
La ingestión tiene que ver con el rendimiento, la arquitectura, los formatos y el mapeo de los datos. A menudo, esto ocurre entre otras aplicaciones y el sistema de datos de entrenamiento.
Exportar, en este contexto, suele referirse a una exportación única basada en archivos del sistema de datos de entrenamiento.
El acceso a los datos consiste en consultar, ver y descargar BLOBs y anotaciones.
Los sistemas modernos de datos de entrenamiento almacenan las anotaciones en una base de datos (no en un volcado JSON), y proporcionan capacidades de consulta abstractas sobre esas anotaciones.
Exportación basada en archivos
Como se ha mencionado en el versionado, una exportación de basada en un archivo es una instantánea de los datos en un momento dado. Normalmente sólo se genera en función de un conjunto muy aproximado de criterios, por ejemplo, un nombre de conjunto de datos. Las exportaciones basadas en archivos son bastante sencillas, por lo que no les dedicaré mucho tiempo. En la siguiente sección se comparan las ventajas y desventajas de la exportación basada en archivos y el streaming.
Transmisión de datos
Clásicamente, las anotaciones siempre se exportaban a un archivo estático, como un archivo JSON. Ahora, en lugar de generar cada exportación como algo puntual, transmites los datos directamente a la memoria. Esto plantea la pregunta: "¿Cómo sacar mis datos del sistema?". Todos los sistemas ofrecen alguna forma de exportación, pero tendrás que considerar de qué tipo. ¿Es una exportación estática, de un solo término? ¿Es directa a la memoria de TensorFlow o PyTorch?
Ventajas del streaming
Puedes cargar sólo lo que necesites, que puede ser un pequeño porcentaje de un archivo JSON. A escala, puede resultar poco práctico cargar todos los datos en un archivo JSON, por lo que esto puede ser una gran ventaja.
Funciona mejor para equipos grandes. Evita tener que esperar a los archivos estáticos; puedes programar y trabajar con el conjunto de datos esperado antes de que comience la anotación, o incluso mientras se está realizando la anotación.
Es más eficiente en el uso de la memoria: al ser un flujo, no es necesario cargar todo el conjunto de datos en la memoria. Esto es especialmente aplicable al entrenamiento distribuido, y cuando marshalear un archivo JSON sería poco práctico en una máquina local.
Ahorra tener que hacer un "doble mapeo", por ejemplo, mapear a otro formato, que a su vez se mapeará a tensores. Además, en algunos casos, analizar un archivo JSON puede requerir más esfuerzo que actualizar unos cuantos tensores.
Proporciona más flexibilidad; los usuarios finales pueden definir y redefinir el formato.
Inconvenientes del streaming
Las especificaciones se definen en el código. Si el conjunto de datos cambia, la reproducibilidad puede verse afectada, a menos que se tomen medidas adicionales.
Requiere una conexión de red.
Es posible que algunos sistemas de formación heredados/proveedores de AutoML no admitan la carga directa desde la memoria y requieran archivos estáticos.
Una cosa que hay que tener muy presente en todo esto es que en realidad no queremos seleccionar estáticamente carpetas y archivos. En realidad estamos configurando un proceso en el que transmitimos nuevos datos, de una forma impulsada por eventos. Para ello, tenemos que pensar en ello más como el montaje de una tubería, en lugar de centrarnos en la mecánica de obtener un único conjunto conocido existente.
Ejemplo: Obtener y transmitir
En este ejemplo, obtendremos un conjunto de datos y lo transmitiremos utilizando el SDK de Diffgram:
pipinstalldiffgram==0.15.0
fromdiffgramimportProjectproject=Project(project_string_id='your_project')default_dataset=project.directory.get(name='Default')# Let's see how many images we got('Number of items in dataset:{}'.format(len(default_dataset)))# Let's stream just the 8th element of the dataset('8th element:{}'.format(default_dataset[7]))pytorch_ready_dataset=default_dataset.to_pytorch()
Introducción a las consultas
Cada aplicación tiene su propio lenguaje de consulta . Este lenguaje suele tener una estructura especial específica para el contexto de los datos de entrenamiento. También puede tener soporte para integraciones abstractas con otras construcciones de consulta.
Para ayudar a enmarcar esto, empecemos con este sencillo ejemplo para obtener todos los archivos con más de 3 coches y al menos 1 peatón (suponiendo que esas etiquetas existan en tu proyecto):
dataset = project.dataset.get('my dataset')
sliced_dataset = dataset.slice('labels.cars > 3 and labels.pedestrian >= 1')
Integración con el ecosistema
Hay muchas aplicaciones disponibles para realizar el entrenamiento y el funcionamiento de los modelos. En el momento de escribir esto, en hay muchos cientos de herramientas que entran en esta categoría. Como ya se ha mencionado, puedes establecer un mapeo de definiciones de formatos, activadores, nombres de conjuntos de datos, etc. en tus herramientas de datos de entrenamiento. Trataremos estos conceptos con más profundidad en capítulos posteriores.
Seguridad
La seguridad de los datos de entrenamiento es de vital importancia. A menudo, los datos brutos se tratan con mayor escrutinio que los datos en otras formas desde el punto de vista de la seguridad. Por ejemplo, los datos brutos de infraestructuras críticas, permisos de conducir, objetivos militares, etc. se almacenan y transfieren con mucho cuidado.
La seguridad es un tema amplio que debe investigarse a fondo y tratarse aparte en este libro. Sin embargo, abordaremos algunas cuestiones que es crucial comprender cuando se trabaja con datos de entrenamiento. Llamo la atención específicamente sobre los temas de seguridad más comunes en el contexto de la ingeniería de datos para datos de entrenamiento:
Control de acceso
URL firmadas
Información personal identificable
Control de acceso
Hay algunas preguntas importantes sobre el control de acceso en las que podemos centrarnos para empezar. ¿Qué sistema está procesando los datos? ¿Cuáles son las preocupaciones sobre los permisos de gestión de identidades y accesos (IAM) en torno al procesamiento y almacenamiento a nivel de sistema? ¿Cuáles son los problemas de acceso de los usuarios?
Identidad y autorización
Los sistemas a nivel de producción suelen utilizar OpenID Connect (OIDC). Esto puede combinarse con el control de acceso basado en roles (RBAC) y el control de acceso basado en atributos (ABAC).
En lo que respecta específicamente a los datos de entrenamiento, a menudo es en los datos brutos donde hay más tensión en torno al acceso. En ese contexto, normalmente puede abordarse a nivel por archivo o por conjunto. En el nivel por archivo, el acceso debe ser controlado por un motor de políticas que conozca el triplicado de {user, file, policy}. Esto puede ser complejo de administrar en el nivel por archivo. Normalmente, es más fácil conseguirlo a nivel de conjunto. A nivel de conjunto (dataset), se consigue con {user, set, policy}.
Ejemplo de configuración de permisos
En este ejemplo de código, crearemos un nuevo conjunto de datos y un nuevo rol de asesor de seguridad, y añadiremos el par de objetos abstractos de permiso {view, dataset} en ese rol:
restricted_ds1=project.directory.new(name='Hidden Dataset 1',access_type='restricted')advisor_role=project.roles.new(name='security_advisor')advisor_role.add_permission(perm='dataset_view',object_type='WorkingDir')
A continuación, asignamos el usuario (miembro) al conjunto de datos restringido:
member_to_grant=project.get_member(='security_advisor_1@example.com')advisor_role.assign_to_member_in_object(member_id=member.get('member_id'),object_id=restricted_ds1.id,object_type='WorkingDir')
Alternativamente, esto puede hacerse con un motor de políticas externo.
URL firmadas
Las URL firmadas son un mecanismo técnico de para proporcionar acceso seguro a recursos, casi siempre BLOBs de medios en bruto. Una URL firmada es el resultado de un proceso de seguridad que implica pasos de identidad y autorización. Una URL firmada se concibe más concretamente como una contraseña de un solo uso a un recurso, con la advertencia añadida más común de que caduca al cabo de un tiempo preestablecido. Este tiempo de caducidad es a veces tan breve como unos segundos, suele ser inferior a una semana y, en raras ocasiones, la URL firmada será aplicable "virtualmente de forma indefinida", por ejemplo durante varios años. Las URL firmadas no son exclusivas de los datos de entrenamiento, y te convendría investigar más sobre ellas, ya que parecen sencillas pero contienen muchas trampas. Aquí nos referimos a las URL firmadas sólo en el contexto de los datos de entrenamiento.
Una de las cosas más críticas que hay que tener en cuenta es que, dado que las URL firmadas son efímeras, no es buena idea transmitirlas como algo puntual. Hacerlo paralizaría de hecho el sistema de datos de entrenamiento cuando la URL caduque. También es menos seguro, ya que el tiempo será demasiado corto para ser útil, o demasiado largo para ser seguro. En su lugar, es mejor integrarlas con tu sistema de identidad y autorización. De este modo, se pueden generar URL firmadas a petición de pares {User, Object/Resource} específicos. Ese usuario concreto puede entonces obtener una URL de corta caducidad.
En otras palabras, puedes utilizar un servicio externo al sistema de datos de entrenamiento para generar las URL firmadas, siempre que el servicio esté integrado directamente con el sistema de datos de entrenamiento. De nuevo, es importante trasladar la mayor parte posible de la lógica y las definiciones organizativas reales dentro del sistema de datos de formación. El inicio de sesión único (SSO) y la integración de la gestión de identidades y accesos suelen ser transversales a las bases de datos y las aplicaciones, por lo que es una consideración aparte.
Además de lo que cubrimos en esta sección, los sistemas de datos de entrenamiento ofrecen actualmente nuevas formas de asegurar los datos. Esto incluye cosas como transmitir los datos de entrenamiento directamente a los programas de ML, evitando así la necesidad de que una sola persona tenga un acceso extremadamente abierto. Te animo a que leas la documentación más reciente de tu proveedor de sistemas de datos de entrenamiento para estar al día de las últimas buenas prácticas de seguridad.
Conexiones a la nube y URL firmadas
Quien vaya a supervisar los datos necesita verlos. Éste es el nivel mínimo de acceso y es esencialmente inevitable. Los sistemas de preparación, como el que elimina la información personal identificable (IPI), generan miniaturas de , preetiquetan, etc., también necesitan verlo. Además, para la comunicación práctica entre sistemas, a menudo es más fácil transmitir sólo una URL/ruta de archivo y luego hacer que el sistema descargue directamente los datos. Esto es especialmente cierto porque muchos sistemas de usuario final tienen velocidades de carga mucho más lentas que las de descarga. Por ejemplo, imagina decir "utiliza el vídeo de 48 GB en esta ruta de la nube" (KBs de datos) frente a intentar transmitir 48 GB desde tu máquina doméstica.
Hay muchas formas de conseguirlo, pero las URL firmadas -un sistema de contraseñas por recurso- son actualmente el método más comúnmente aceptado. Pueden estar "entre bastidores", pero generalmente siempre acaban utilizándose de alguna forma.
Por buenas y malas razones, a veces puede ser un área de controversia. Aquí destacaré algunas ventajas y desventajas para ayudarte a decidir lo que es relevante para tu sistema.
En resumen, los datos de entrenamiento presentan algunos problemas inusuales de seguridad en el procesamiento de datos que hay que tener en cuenta:
Los humanos ven los datos "en bruto" de formas poco comunes en otros sistemas.
Los administradores suelen necesitar permisos bastante amplios para trabajar con los datos, de nuevo de formas poco comunes en los sistemas clásicos.
Debido a la proliferación de nuevos tipos de medios, formatos y métodos de transmisión de datos, existen preocupaciones sobre el tamaño y el procesamiento de los datos de entrenamiento. Aunque las preocupaciones son similares a las que conocemos de los sistemas clásicos, hay menos normas establecidas sobre lo que es razonable.
Información personal identificable
La información de identificación personal debe tratarse con cuidado cuando se trabaja con datos de formación. Tres de las formas más comunes de abordar los problemas relacionados con la IPI son crear una cadena de tratamiento que la respete, evitarla por completo o eliminarla.
Cadena de datos conforme a PII
Aunque la IIP introduce complicaciones en nuestros flujos de trabajo, a veces su presencia es necesaria. Tal vez la IIP sea deseada o útil para la formación. Esto requiere disponer de una cadena de datos que cumpla la IIP, formación sobre la IIP para el personal y un etiquetado adecuado que identifique los elementos que contienen IIP. Esto también se aplica si el conjunto de datos contiene IPI y la IPI no se va a modificar. Los principales factores que hay que tener en cuenta son
OAuth o métodos de identificación similares, como OIDC
Instalaciones locales u orientadas a la nube
Pasar por referencia y no enviar datos
Evitar PII
Tal vez sea posible evitar el manejo de la IIP. Tal vez tus clientes o usuarios puedan ser quienes miren realmente su propia IIP. Esto aún puede requerir cierto nivel de trabajo de cumplimiento de la IIP, pero menos que si tú o tu equipo miráis directamente los datos.
Eliminación de PII
Es posible que puedas despojar, eliminar o agregar datos para evitar la IIP. Por ejemplo, la IIP puede estar contenida en metadatos (como DICOM). Es posible que desees borrar completamente esta información, o conservar sólo un único ID que enlace con una base de datos independiente que contenga los metadatos necesarios. O bien, la IIP puede estar contenida en los propios datos, en cuyo caso se aplican otras medidas. Para las imágenes, por ejemplo, esto puede implicar difuminar las caras y las marcas de identificación, como los números de las casas. Esto variará drásticamente según tus leyes locales y tu caso de uso.
Etiquetado previo
La supervisión de las predicciones de los modelos es habitual. Se utiliza para medir la calidad del sistema, mejorar los datos de entrenamiento (anotación) y alertar sobre los errores. Discutiré los pros y los contras del preetiquetado en capítulos posteriores; por ahora, haré una breve introducción a los detalles técnicos. La gran idea del preetiquetado es que tomamos el resultado de un modelo ya ejecutado y lo exponemos a otros procesos, como la revisión humana.
Actualizar datos
Puede parecer extraño empezar con el caso de actualización de , pero como los registros se actualizarán a menudo mediante programas de ML, es bueno tener un plan sobre cómo funcionarán las actualizaciones antes de ejecutar modelos y programas de ML.
Si los datos ya están en el sistema, tendrás que referirte al ID del archivo, o a alguna otra forma de identificación como el nombre del archivo, para hacerlos coincidir con el archivo existente. Para grandes volúmenes de imágenes, actualizaciones frecuentes, vídeo, etc., es mucho más rápido actualizar un registro conocido existente que volver a importar y procesar los datos brutos.
Lo mejor es que las definiciones entre los programas de ML y los datos de entrenamiento se definan en el programa de datos de entrenamiento.
Si no es posible, al menos incluye el ID del archivo de datos de entrenamiento junto con los datos en los que se entrena el modelo. Esto te permitirá actualizar más fácilmente el archivo con los nuevos resultados. Este ID es más fiable que un nombre de archivo, porque los nombres de archivo a menudo sólo son únicos dentro de un directorio.
Consecuencias del preetiquetado
Algunos formatos, por ejemplo las secuencias de vídeo, pueden ser un poco difíciles de entender. Esto es especialmente cierto si tienes un esquema complejo. Para éstos, te sugiero que te asegures de que el proceso funciona con una imagen, y/o de que el proceso funciona con una única secuencia por defecto, antes de probar con secuencias múltiples verdaderas. Las funciones del SDK pueden ayudar en los esfuerzos de preetiquetado.
Algunos sistemas utilizan coordenadas relativas y otros absolutas. Es fácil transformar entre ellas, siempre que se conozcan la altura y la anchura de la imagen. Por ejemplo, una transformación de coordenadas absolutas a relativas se define como "x / anchura de la imagen" e "y / altura de la imagen". Por ejemplo Un punto x,y (120, 90) con una anchura/altura de imagen (1280, 720) tendría un valor relativo de 120/1280 y 90/720 o (0,09375, 0,125).
Si es la primera vez que importas los datos brutos, entonces es posible adjuntar las instancias existentes (anotaciones) al mismo tiempo que los datos brutos. Si no es posible adjuntar las instancias, entonces trátalo como una actualización.
Una pregunta habitual es: "¿Deben enviarse todas las predicciones de la máquina a la base de datos de datos de entrenamiento?". La respuesta es sí, siempre que sea factible. El ruido es el ruido. No tiene sentido enviar predicciones ruidosas conocidas. Muchos métodos de predicción generan múltiples predicciones con algún umbral para su inclusión. En general, cualquier mecanismo que tengas para filtrar estos datos debe aplicarse también aquí. Por ejemplo, podrías tomar sólo la predicción de mayor "confianza". Con este mismo fin, en algunos casos, puede ser muy beneficioso incluir este valor de "confianza" u otros valores de "entropía" para ayudar a filtrar mejor los datos de entrenamiento.
Proceso de preparación de datos previos al etiquetado
Ahora que hemos cubierto algunos de los conceptos abstractos, vamos a sumergirnos en algunos ejemplos específicos para formatos de medios seleccionados. En este libro no podemos abarcar todos los formatos y tipos posibles, por lo que deberás investigar los documentos correspondientes a tu sistema de datos de entrenamiento, tipos de medios y necesidades específicos.
La Figura 4-8 muestra un ejemplo de proceso de preetiquetado con tres pasos. Es importante empezar por asignar tus datos al formato de tu sistema de registro. Una vez procesados tus datos, deberás asegurarte de que todo es correcto.
Figura 4-8. Ejemplo de diagrama de bloques
Normalmente, habrá alguna información de formato de alto nivel que anotar, como decir que una imagen puede tener muchas instancias asociadas a ella, o que un vídeo puede tener muchos fotogramas, y cada fotograma puede tener muchas instancias, como se muestra en la Figura 4-9.
Figura 4-9. Resumen visual de la relación entre los medios brutos y las instancias
Pongamos todo esto junto en un ejemplo de código práctico que maquetará los datos de un cuadro delimitador de imagen.
Aquí tienes un ejemplo de código Python:
defmock_box(sequence_number:int=None,name:str=None):return{"name":name,"number":sequence_number,"type":"box","x_max":random.randint(500,800),"x_min":random.randint(400,499),"y_max":random.randint(500,800),"y_min":random.randint(400,499)}
Esto es una "instancia". Así, por ejemplo, si ejecutas la función mock_box() obtendrás lo siguiente:
instance={"name":"Example","number":0,"type":"box","x_max":500,"x_min":400,"y_max":500,"y_min":400}
Podemos combinar instancias en una lista para representar varias anotaciones sobre el mismo fotograma:
instance={}instance_list=[instance,instance,instance]
Resumen
Una gran ingeniería de datos para los datos de entrenamiento requiere un sistema central de registro, consideraciones sobre los datos brutos, configuraciones de ingestión y consulta, definición de métodos de acceso, asegurar los datos adecuadamente y establecer integraciones de preetiquetado (por ejemplo, predicción de modelos). Hay algunos puntos clave de este capítulo que merecen ser revisados:
Un sistema de registro es crucial para conseguir un gran rendimiento y evitar acumular errores de datos como en un juego de teléfono.
Una base de datos de datos de entrenamiento es un ejemplo de sistema práctico de registro.
Lo ideal es planificar con antelación un sistema de registro de datos de formación, pero también puedes añadirlo a un sistema existente.
Las consideraciones sobre el almacenamiento de datos en bruto incluyen la clase de almacenamiento, la geolocalización, el coste, el soporte del proveedor y el almacenamiento por referencia frente al almacenamiento por valor.
Los distintos tipos de medios de datos brutos, como imágenes, vídeo, 3D, texto, datos médicos y geoespaciales, tienen necesidades de ingestión particulares.
Las consultas y el streaming proporcionan un acceso a los datos más flexible que la exportación de archivos.
Hay que tener en cuenta aspectos de seguridad como el control de acceso, las URL firmadas y la información personal.
Lo ideal es que el preetiquetado cargue las predicciones del modelo en el sistema de registro.
Mapear formatos, gestionar actualizaciones y comprobar la precisión son partes clave de los flujos de trabajo de preetiquetado.
Utilizar las buenas prácticas de este capítulo te ayudará en tu camino hacia la mejora de los resultados generales de los datos de entrenamiento y del consumo de los datos por parte del modelo de aprendizaje automático .
1 De Google Respuestas
Get Datos de entrenamiento para el aprendizaje automático now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
