¡Participa de la Maratón Behind the Code, la competencia de programación más desafiante! Inscríbete aqui

Aplique el ciclo de vida de desarrollo de software a los datos que alimentan las aplicaciones de IA

La inteligencia artificial (AI) está de moda, y sus intereses han generado muchas charlas de encadenamiento hacia adelante y hacia atrás, redes neurales, aprendizaje profundo, lógica Bayesiana, agrupamiento, sistemas clasificadores, etc. Todas estas son técnicas de IA, pero la magia no reconocida de la IA viene de proporcionar un respeto similar a la cantidad considerable de datos y a la cantidad que necesita para mismos. Efectivamente, la IA necesita big data. En mi tutorial anterior «Gran cerebro de datos, Parte 1,» He brindado una presentación en profundidad del rol de los datos en la IA. En este tutorial explico cómo aplicar a los datos la versión interactiva del conocido ciclo de vida de desarrollo de software (SDLC) teniendo en cuenta las aplicaciones de IA. Aunque hay muchos algoritmos de IA que utilizan datos de formas diferentes, el aprendizaje automático de una o de otra forma está dirigiendo la mayor parte de la actual expansión de la IA. Por esa razón, y para seguir el hilo de mi tutorial anterior, la mayor parte del énfasis del diálogo y de los ejemplos de este tutorial está centrado en el aprendizaje automático.

El ciclo de vida de los datos de la IA

La mejor forma de pensar en la recopilación, la preparación y el uso efectivo de los datos para la IA camina en paralelo con el ciclo de vida de desarrollo de software. Siguiendo el mismo espíritu de los recientes avances en el desarrollo ágil, para la gestión de datos de IA favorezco un enfoque bien definido pero iterativo, en vez de un enfoque rígido de «cascada».

Los desarrolladores ya deberían estar familiarizados con el SDLC iterativo. Cuando se inicia un proyecto, este entra en el cuadrante de planificación y requisitos, después de los cuales las iteraciones continúan a lo largo del ciclo de vida del software, introduciendo verdaderamente el «ciclo» en el ciclo de vida. Esa idea tiene variaciones, algunas incluso tratan el desarrollo como una salida del proceso después de las pruebas.

Ciclo de Vida de Desarrollo de Software (SDLC) Iterativo: Un circulo cerrado y continuo que incluye: plan, requisitos, análisis y diseño, implementación, prueba, implementación, evaluación

Por supuesto que los desarrolladores normalmente piensan en esas etapas en términos de especificaciones funcionales, sistemas de bases de datos, diagramas de estructura y de interfaz de código, código de programación y casos de pruebas. Es preferible que en el diseño existan diagramas de flujos de datos, pero con demasiada frecuencia en el SDLC los datos solo se tratan parcialmente, lo que es perjudicial para el desarrollo de la IA.

Planificación y requisitos

Generalmente, lo más importante que puede hacer el equipo, además de la definición general del problema y entender el entorno de desarrollo, es incorporar la necesidad de datos en la planificación. Si el equipo está utilizando una de las muchas técnicas de IA que requieren ejemplos de capacitación, el equipo debería decidir qué tipos de datos de capacitación tiene que adquirir. Esto depende de qué tipo de datos están disponibles, además del planteamiento del problema y de los requisitos, porque cuanto más se parezcan los datos de capacitación a la gama de resultados que se necesitan del software implementado, mayor será la probabilidad de éxito.

Puede que haya un tipo de ciclo de retroalimentación en el que la falta de disponibilidad de datos adecuados para la capacitación modifique los requisitos de la solución. Es posible que en los requisitos originales se puedan restaurar iteraciones futuras. Digamos, por ejemplo, que el equipo está desarrollando un programa de identificación de lirios, pero lo único que hay disponible al principio para la capacitación es el famoso conjunto de datos de lirios (vea la Parte 1 para obtener más información sobre esto). El equipo podría decidir que para las primeras iteraciones la meta debería ser reconocer con un alto nivel de confianza el conjunto de lirios de entre otras dos especies, pero aceptar menos confianza a la hora de distinguir entre «Iris virginica» e «Iris versicolor». A medida que empiezan a estar disponibles mejores técnicas o datos en iteraciones posteriores, las expectativas podrían aumentar hacia la clasificación de las tres con confianza.

Análisis y diseño

Usted debería reunir los tres orígenes de datos en bruto para la IA mientras está analizando y diseñando el código. A medida que empiece a reunir estos datos, empezará a entender cómo tienen que ser examinados, aumentados, mantenidos y evaluados. Determine anticipadamente los límites de los formatos y de los parámetros, como el tamaño máximo y mínimo de las imágenes y la duración de los archivos de audio. En el caso de cosas como el conjunto de datos de lirios, no se olvide de controlar las unidades. No querrá que las medidas realizadas en pulgadas se mezclen con las medidas realizadas en centímetros. Recuerde lo que le decía su antiguo profesor de matemáticas, todo se tiene que anotar por sus unidades, en el propio valor de los datos, como un tipo de datos abstracto o quizás en el esquema de los datos. En cualquier caso, es posible que desee incluir algún tipo de validación o de conversión de unidades, en el código o en las instrucciones para que la revise un experto.

Una cosa importante pero que a menudo se pasa por alto en el diseño de los datos es su procedencia. ¿De dónde proviene cada elemento de datos y qué tan bien podemos rastrearlo? ¿Cuál fue su cadena de custodia a través de las personas o de los sistemas antes de llegar a su aplicación? ¿Cómo los cambió exactamente su aplicación, a través de algoritmos o de revisión de expertos? Si encuentra anomalías, fuentes de sesgo u otros problemas, la proveniencia puede ser la clave para entender qué datos de un corpus agregado mayor tiene que corregir o descartar usted. También es importante para la mejora continua de los sistemas. A medida que su aplicación madure y que entienda mejor qué técnicas y procesos son efectivos y cuáles son deficientes, podrá incluir el mismo entendimiento de los orígenes de datos.

La Parte 1 contiene una explicación más amplia de la dimensionalidad. También en esta etapa debe decidir o reconsiderar la dimensionalidad de los datos para las muestras de capacitación o para utilizarlos para el algoritmo. ¿Si añade más detalles a los datos se reduce el rendimiento? ¿Mejoran los resultados o reducen su confiabilidad, quizás por la maldición de la dimensión? Normalmente el análisis y el diseño es donde usted establecería las técnicas para la reducción de la dimensionalidad.

Flujo de datos

Los diagramas de flujos de datos (DFDs) son artefactos de diseño importantes, pero infrautilizados. A finales de los 70 se describieron detalladamente por primera vez como una parte principal del proceso de ingeniería de software en el libro altamente influyente Structured Design (Diseño estructurado), de Ed Yourdon and Larry Constantine. Su trabajo se basó en el trabajo anterior de David Martin y Gerald Estrin. Los desarrolladores de áreas como la seguridad online han aprendido que para las aplicaciones bancarias online, es importante el diagrama de flujo de los datos a medida que pasan desde el navegador remoto del usuario a través de capas cada vez más seguras de dentro de los sistemas de conciliación de backoffice y del libro contable minorista. La descripción detallada de nivel similar es una parte importante para determinar el proceso de preparación de los datos de la IA, que a su vez es un factor importante en el éxito práctico.

Los DFDs para los datos de IA suelen basarse en técnicas habituales de adquisición y preparación de datos. La siguiente imagen es una versión abstracta de un DFD que usted debería actualizar con los pasos más específicos que está dando, basándose en la naturaleza de su espacio problemático, de la naturaleza de los datos y de los algoritmos que está empleando.

Diagrama abstracto de flujo de datos para IA que muestra como se captan datos, se organizan, y finalmente se filtran errores mecánicamente para llegar a resultado

El diagrama de flujo de datos trata de datos, no de procesos. Los recuadros redondeados son procesos, pero se deberían describir en términos de lo que hacen a los datos. Las fechas son las claves que muestran los pasos por los que pasan los datos a lo largo de los procesos. El repositorio final para los datos es el corpus para su aplicación. Aunque los DFDs no tratan del flujo de procesos, he incluido el ícono del ciclo como un recordatorio de que el proceso debería ser continuo, añadiendo y acomodando los datos en el corpus según lo dicte el análisis, como los resultados de las puntuaciones de la población.

Para ayudarle a tener un DFD especial para sus propios proyectos, aquí hay una descripción de algunos de los procesos abstractos que están incluidos en este ejemplo.

  • La adquisición de datos es el proceso de obtener datos en bruto para incorporarlos al corpus. Puede ser a través de digitalización o de raspado de datos;-extracción bruta de datos de algunas fuentes de la web- ; o de otro lugar.
  • La disputa de datos es el proceso de convertir el formato de los datos a lo que se necesita como entrada, además de detectar y anotar los datos con las características entendidas mecánicamente de los metadatos, lo que incluye la procedencia. Aquí puede intentar identificar los elementos de datos discretos y eliminar los duplicados.
  • La limpieza de datos es el proceso de evaluar los elementos de datos identificados y etiquetados para corregir o eliminar los que están corruptos, incompletos o son imprecisos.
  • La puntuación y la incorporación es el proceso de aplicar el análisis estadístico para garantizar la salud general del corpus resultante. Cada elemento puede ser puntuado según su aplicabilidad a las necesidades del mantenimiento del corpus. Toda la población de elementos que se deben añadir al corpus se puede puntuar para asegurar que su composición maximiza la eficiencia y la precisión de los algoritmos.

Un modelo popular para el paso de puntuar es el análisis exploratorio de datos (EDA), que implica muchas combinaciones de visualizaciones de relaciones entre las diferentes variables de la población. Para reducir la dimensionalidad con éxito es importante realizar un trabajo exhaustivo con el EDA.

En este tutorial, sigo adelante para echar un vistazo a etapas mayores del SDLC, pero es muy importante asimilar la disciplina de que el análisis y preparación de datos es una actividad constante durante todas las etapas del SDLC para la IA.

Implementación y pruebas

Una de las principales lecciones de los inicios del SDLCs, a través de las muchas tecnologías que han surgido para el desarrollo de software, ha sido poner en su lugar la implementación real. La mayor parte de las personas acuden a la programación porque la consideran una persecución emocionante. Es emocionante poner las instrucciones paso a paso en la computadora y verla hacer algo especial. Buscar errores y encontrar mejoras para algoritmos también puede ser emocionante.

Este factor psicológico siempre ha hecho que los desarrolladores acaben con la tendencia de querer entrar en la etapa de implementación lo antes posible, y de no poner suficiente énfasis en la planificación, el análisis, el diseño, las pruebas estructuradas, la gestión de sistemas y en otros aspectos de los proyectos que tienen éxito. Estas etapas pueden parecer aburridas en comparación con la codificación, pero la experiencia y la disciplina en el diseño muestra que, por ejemplo, en las causas habituales de los problemas de los proyectos y de que los costos y el tiempo se sobrepasen están que no se coordinen claramente los requisitos y que no se preste suficiente atención a las pruebas estructuradas.

En el diagrama SDLC puede ver que la implementación tan solo es la parte final del análisis y el diseño, y el mismo énfasis se aplica a los datos. La atención a los datos durante la etapa de implementación es, en gran medida, una cuestión de garantizar que el diseño se adapte fielmente en la codificación de los algoritmos.

Todo esto cambia durante las pruebas. En una aplicación de IA, es en las pruebas donde se ve si todo el trabajo realizado en la recopilación y preparación de los datos se ha hecho correctamente. Los datos de capacitación se lanzan a través de los algoritmos y se comparan con los resultados esperados. Los resultados esperados se pueden derivar del proceso original de adquirir el corpus de la capacitación o de iteraciones previas del SDLC. El arco que atraviesa las pruebas y la evaluación tiene un énfasis especial cuando se desarrollan aplicaciones de IA, y esta coyuntura crítica también es la razón por la que la IA normalmente requiere más iteraciones del SDLC que otros casos antes de que estén listas para su uso en producción.

Evaluación, y el ciclo continúa

En el corazón de las pruebas está una comparación estructurada entre los resultados esperados y los reales, es una evaluación mecánica de si el algoritmo procesa las muestras de la capacitación tal como se espera. Este es solamente el inicio del proceso de asegurarse de que la IA produce resultados útiles de forma fiable. La evaluación a menudo está supervisada por expertos que la hacen funcionar con datos no planificados de potenciales aplicaciones del mundo real. Si usted está desarrollando un agente móvil, usted podría tener grabadas un conjunto de frases de personas conocidas que digan algo parecido a «¿Cuál es la población de Gana?» y podría comparar la respuesta hablada con la respuesta esperada. La evaluación podría incluir el proceso de que personas nuevas formulen la misma pregunta, o una variación, «¿cuál es la población de Nigeria?» y que los expertos que evalúan los resultados puedan conocer mejor cómo se podría comportar el agente en condiciones más realistas.

El proceso de evaluación generalmente incluye la implementación de la aplicación y su uso por probadores beta y después por clientes. La retroalimentación de todos estos datos daría información a las fases siguientes de la planificación y, por lo tanto, impulsaría iteraciones posteriores. Es posible que los informes de campo indiquen que el agente tiene problemas diferenciando la pregunta «¿cuál es la población de Gana?» de «¿cuál es la población de la Guyana?» de algunas personas. Esto se puede convertir en una muestra importante para la capacitación y las pruebas en iteraciones posteriores.

Conclusión

El primer article explicó cuál es la importancia de los datos para la creación de aplicaciones de IA y cognitivas, que esta importancia ha sido constante a lo largo de la historia de la disciplina, y cómo se ha conectado a éxitos y fallos históricos de IA. En este tutorial, he explicado cómo manejar los datos de IA con la misma disciplina que tiene con el código, en un proceso simultáneo al código. Aplique el SDLC tradicional e iterativo para sacar el máximo provecho de los beneficios que están incluidos en el gran suministro de datos que hay disponibles hoy en día, mientras está atento para visualizar los peligros.

Aviso

El contenido aquí presentado fue traducido de la página IBM Developer US. Puede revisar el contenido original en este link.