La mayoría de las personas en el mundo técnico ahora están familiarizadas con alguna versión de este Diagrama de Venn de Inteligencia Artificial (IA)…
Crédito: recreación del autor de Aprendizaje profundo (Goodfellow, Bengio, Courville) – edición 2016, página 9.
… que describe la relación entre varios conjuntos de técnicas de IA, incluido el aprendizaje automático y el aprendizaje profundo. Hay muchos libros y artículos excelentes que describen esos temas y cómo se pueden implementar en varios marcos de software, y esas descripciones no se repetirán aquí. También hay muchos artículos sobre Big Tech implementando IA a escala. Pero, ¿cómo implementan con éxito los proyectos de IA las organizaciones «normales», especialmente dentro de una cartera de soluciones existente? En la publicación BLOG@CACM «Anna Karenina sobre metodologías de desarrollo», Describí cómo la famosa línea de apertura «Las familias felices son todas iguales, las familias infelices son infelices cada una a su manera» se aplica al desarrollo de software. Esta publicación describirá de manera similar los comportamientos de desarrollo que tienen la mayor probabilidad de éxito para los esfuerzos de IA.
El dilema del arranque del proyecto AI
Elija un caso de uso
O al menos, elija algunos problemas/oportunidades candidatos para investigar. Este es un consejo de «dicen» que es obvio pero necesario repetir, porque es cierto. Hay una tendencia de marketing de querer rociar AI en todo y ver qué crece con la esperanza de que suceda algo mágico. El negocio de IA de Watson de IBM fue notorio por esto cuando se refirió a su marco de IA del mismo nombre como «Computación cognitiva» en la era de Watson Health, una frase que implicaba muchas cosas pero no significaba nada específico y tuvo el efecto de inflar las expectativas de los clientes a un nivel superior. grado inmanejable.
También es fácil quedarse ciego ante una miríada de posibles problemas de implementación técnica de IA y perder de vista los objetivos analíticos de lo que originalmente se suponía que debía agruparse, categorizarse o predecirse. Se aplica el adagio sobre los caimanes y el drenaje del pantano.
Alineación de niveles múltiples
En la publicación BLOG@CACM «Desarrollo de líderes técnicos», Describí niveles comunes de progresión de liderazgo en ingeniería de software, que van desde colaborador individual hasta líder tecnológico/colaborador individual sénior, líder de equipo y gerente. Los esfuerzos de IA son un excelente ejemplo de la necesidad de una alineación de varios niveles, porque cualquier esfuerzo exitoso necesita cosas como:
- Una persona técnica que puede hacer el trabajo.
- Una persona técnica que puede obtener la aprobación del proyecto.
… y estas habilidades rara vez existen en la misma persona. A veces, en una organización, hay un miembro del personal con una idea pero sin capacidad para priorizarla, y a veces puede haber líderes con una idea general para un esfuerzo de IA, pero sin capacidad de ejecución.
La alineación multinivel también se aplica a la selección de casos de uso, ya que puede haber una diferencia entre la «comprensión ejecutiva» de los casos de uso y aquellos que experimentan puntos débiles en persona. Ambas son perspectivas valiosas, pero son distintas. Esto representa el segundo conjunto de alineación multinivel para las partes interesadas:
- Alguien que pueda hablar sobre el caso de uso con especificidad
- Alguien que pueda abogar por el caso de uso y priorizarlo
Como en el aspecto técnico de la casa, esas personas rara vez son las mismas.
Establecer una línea de base de IA
Según el diagrama de Venn anterior, asegúrese de que todos los miembros del equipo del proyecto utilicen el mismo vocabulario y puedan explicar cosas como la diferencia entre el aprendizaje supervisado y no supervisado, la diferencia entre un clasificador y la regresión, y los pasos comunes en la preparación de datos requerida. es importante. Esto incluye a las partes interesadas porque comprender estos conceptos tanto como sea posible es esencial para la gestión de expectativas, ya que estos no son solo «detalles de implementación», se trata de comprender el arte real de lo posible y lo que es realista.
Como el círculo exterior de conceptos que contiene «IA» es bastante grande, comience con lo básico y continúe desde allí.
Investigación de datos
Los datos son el punto de partida de los proyectos de IA, y es por eso que contar con colaboradores individuales que entiendan tanto la tecnología relevante como el espacio problemático es tan crítico para una investigación de datos efectiva. Nunca dé por sentadas las siguientes preguntas:
- Para el problema que se investiga, ¿hay suficientes datos disponibles?
- Para los datos que existen, ¿qué tan limpios están?
- ¿Qué gobierno de datos es relevante para el contexto?
Un equipo de proyecto podría estar investigando instintivamente en un área problemática real de buena fe solo para descubrir que no hay suficientes datos para respaldar los análisis propuestos, o al menos análisis con los resultados deseados. Del mismo modo, incluso cuando existen datos, la razón por la cual la gente repite el chiste «El 80% de la ciencia de datos es preparación de datos» es porque es verdad, tan, tan dolorosamente cierto. Por último, comprender el gobierno de datos relevante es un requisito, especialmente en industrias reguladas, como la atención médica. «¿Por qué no puedes usar datos de prueba o falsos para este proyecto?» es una respuesta de cumplimiento común con respecto a los esfuerzos de IA y procesamiento del lenguaje natural (NLP). Si bien los datos falsos son adecuados para el desarrollo de soluciones básicas en términos de tener caracteres para mostrar en una página o informe básico, cuando se trata de predecir algo en el mundo real, generalmente se necesita real datos, o algo que se aproxime mucho a lo real, cuya generación suele ser un problema aún más difícil que el simple uso de datos reales. Cuanto más crítico sea el caso de uso, más reales y completos deben ser los datos de entrenamiento. Los esfuerzos de IA y NLP tienden a plantear preguntas de gobernanza no triviales, y mi publicación BLOG@CACM «Gobierno de datos y la psicología de la gestión de la tensión» describe algunos de los desafíos en los que los datos deben protegerse, pero también deben utilizarse para que sean útiles.
El poder de la retroalimentación
Volar un avión es una actividad que, en la superficie, parece fácil cuando las condiciones son perfectas, hasta que no lo son y luego las cosas se complican rápidamente. Pero no se trata solo del avión, como describió Malcolm Gladwell en su libro valores atípicos al discutir el concepto de Distancia de poder y mitigación en la comunicación. como la tripulación negociaciones sobre la resolución de problemas es posiblemente incluso más importante que los problemas subyacentes en sí mismos, ya que el enfoque de comunicación juega un papel fundamental no solo en la gestión de una crisis, sino también en la prevención de una mayor combinación de errores.
Hay paralelos en el desarrollo de software. Digamos que se seleccionó un caso de uso de IA en los rangos ejecutivos. Incluso si el caso de uso se eligió con las mejores intenciones, es posible que el caso de uso no esté listo para la IA por algunas de las razones ya mencionadas anteriormente. ¿Ahora que? La mejor situación sería que todos (incluido el equipo ejecutivo) aprendieran y comprendieran qué estaba impidiendo ese caso de uso de IA y trataran de remediarlo, y los remedios pueden ir más allá de lo que el equipo del proyecto puede hacer por sí mismo, especialmente si se requieren cambios. en un sistema fuente. Las acciones en el otro extremo del espectro serían que el equipo del proyecto continuara golpeando sus cabezas colectivamente en el caso de uso original en lugar de girar para investigar otro, ya sea por temor a «equivocarse» o por temor a dar malas noticias. La cadena. La IA de alta calidad no suele ser algo que pueda convocarse por decreto ejecutivo.
Operacionalizar
Es natural comenzar con los prototipos o pilotos como esfuerzos independientes, pero finalmente el resultado debe integrarse con el resto de la cartera de soluciones para obtener el máximo beneficio de la organización. La «última milla analítica» puede ser difícil, ya que en los entornos de atención médica, por ejemplo, los proveedores pasan una cantidad excesiva de tiempo en los sistemas de registros médicos electrónicos buscando e ingresando datos de pacientes. Solicitar a los proveedores que inicien sesión en un segundo, tercer o cuarto conjunto de soluciones para ver los resultados analíticos de los pacientes aumenta la carga de trabajo, especialmente cuando se atienden 15, 20 o más pacientes al día. Es posible que haya algunos paneles analíticos de IA complementarios sorprendentes en la cartera, pero también es posible que no haya suficiente tiempo para verlos en el flujo de trabajo cuando se requiere un cambio de contexto adicional.
En conclusión
Mi publicación BLOG@CACM «Anna Karenina» describía la velocidad como un atributo fundamental en el desarrollo de software. Los lanzamientos de software frecuentes no pueden garantizar el éxito, pero los lanzamientos esporádicos y la financiación inconsistente han condenado más productos y soluciones al fracaso que cualquier otra razón. Del mismo modo, los primeros resultados de la IA podrían ser un poco toscos al principio. Sigue aprendiendo y sigue iterando.
Referencias
doug meil es un arquitecto de software en gestión y análisis de datos de atención médica. También fundó Cleveland Big Data Meetup en 2010. Puede encontrar más de sus publicaciones BLOG@CACM en https://www.linkedin.com/pulse/publications-doug-meil
entradas no encontradas