Gestión de sesgos y riesgos en cada paso del proceso de construcción de IA
Por Kathryn Hume y Alex LaPlante
Tecnología
Harvard Business Review
Aquí hay un escenario común para las organizaciones que aplican el aprendizaje automático en sus procesos comerciales. Los equipos de negocios y técnicos se han alineado en una declaración de problema general para una tarea de aprendizaje automático. Todos están entusiasmados, y el equipo técnico se va por unos meses y experimenta con diferentes algoritmos en los datos disponibles, eventualmente convergiendo en un algoritmo que creen logra el mayor rendimiento en las métricas acordadas. Orgullosos de su trabajo, traen resultados a la empresa para integrarlos en un proceso comercial o implementarlos como una característica en un producto de software.
Sin embargo, antes de la implementación, su modelo algorítmico debe ser revisado por un equipo de gobierno para garantizar que cumpla con los requisitos de gestión de riesgos. El equipo de gobierno busca documentación rigurosa sobre los requisitos que el equipo técnico nunca consideró: ¿podemos explicar por qué el algoritmo deriva sus resultados de sus entradas? ¿Qué controles usa el sistema para proteger la privacidad del cliente? ¿Qué tan estables son los datos de entrada durante largos períodos de tiempo, especialmente si solo planeamos volver a entrenar el modelo una vez al mes, o incluso una vez al año? ¿Podemos asegurar que el algoritmo produzca resultados justos en la población de clientes afectados?
El equipo técnico responde que nadie les informó sobre estos requisitos, por lo que no los consideraron durante el desarrollo. Frustrados, comienzan de nuevo, esta vez limitando las opciones sobre posibles algoritmos y datos de entrada para garantizar que se cumplan los requisitos de gestión de riesgos recientemente articulados. Se desperdicia tiempo y esfuerzo. Las líneas de tiempo se estiran. Los ejecutivos se preguntan por qué las cosas están tomando tanto tiempo y están tan ansiosos que van a la zaga de los competidores.
Esta falta de comunicación y coordinación resulta de lagunas en el conocimiento que tienen las partes interesadas comerciales y técnicas sobre lo que se necesita para hacer que el aprendizaje automático funcione en aplicaciones del mundo real, así como los enfoques en cascada residuales para la gestión de proyectos técnicos. Como el campo aún es joven, muchos desarrolladores de aprendizaje automático carecen de experiencia en la creación de aplicaciones empresariales, y muchas partes interesadas en los negocios tienen un conocimiento insuficiente del aprendizaje automático para saber qué preguntas hacer al analizar y administrar proyectos. Para innovar de manera efectiva, los propietarios de proyectos necesitan saber qué compensaciones y decisiones enfrentarán al construir un sistema de aprendizaje automático, y cuándo deben evaluar estas compensaciones para minimizar la frustración y el esfuerzo desperdiciado.
Comencemos con el qué. Hacer que el aprendizaje automático funcione en un contexto empresarial a menudo requiere una serie de decisiones y compensaciones que pueden afectar el rendimiento del modelo. En el centro del asunto se encuentra la estructura de los algoritmos de aprendizaje automático, que usan datos para aprender mapeos aproximados entre entradas y salidas que son útiles para un negocio. Con el software estándar, los programadores escriben instrucciones específicas que ejecutan las mismas operaciones cada vez; La desventaja es que estas instrucciones se limitan a lo que se puede articular explícitamente en el código. Con el aprendizaje automático, por el contrario, los programadores especifican el objetivo del programa y escriben un algoritmo que ayuda al sistema a aprender de manera eficiente el mejor mapeo de entrada-salida de los datos disponibles para lograr este objetivo, en lugar de seleccionar un mapeo particular desde el principio. Este enfoque nos permite abordar escenarios en los que es mucho más difícil escribir las reglas precisas (por ejemplo, reconocimiento de imágenes, análisis textual, generación de secuencias de video), pero la compensación es que la salida del sistema puede ser impredecible o poco intuitiva. De esta base inductiva surgen muchos de los matices de la aplicación de sistemas de aprendizaje automático, especialmente para equipos de negocios y tecnología que están acostumbrados a los sistemas informáticos basados en reglas.
A menudo, estos matices cobran vida a medida que las compensaciones que los equipos comerciales necesitan hacer durante el desarrollo del sistema. Por ejemplo, los equipos pueden encontrar que el objetivo que el negocio busca predecir u optimizar no puede medirse fácilmente con los datos disponibles, por lo que recurren a un proxy medible. La preocupación aquí es que el sistema aprenderá a predecir esto y solo este proxy, no el verdadero objetivo; cuanto más lejos esté el proxy del objetivo, menos útil será la salida del sistema para el negocio.
Otras compensaciones sopesan la precisión del modelo frente a preocupaciones como la explicabilidad, la imparcialidad y la privacidad. Si la empresa duda en adoptar un modelo sin una explicación de cómo y por qué asigna las entradas a las salidas, el equipo técnico podría restringir el conjunto de soluciones potenciales a los algoritmos que permiten una mejor explicabilidad, pero esto puede tener el costo de reducir el rendimiento del modelo . Del mismo modo, si a la empresa le preocupa que el sistema pueda propagar resultados injustos a ciertos segmentos de clientes, o que el sistema pueda exponer datos confidenciales del usuario, el equipo técnico podría restringir su atención a algoritmos que garanticen la equidad y la privacidad, lo que también podría afectar el rendimiento.
A veces, las tasas de error inherentes hacen que sea mejor reducir las pérdidas antes de tiempo. Esto ocurre particularmente en contextos donde el costo de cometer un error es alto (por ejemplo, la confianza del usuario podría ser denigrada o los usuarios esperan certeza). El equipo técnico podría invertir mucho en el diseño del sistema para mejorar la precisión o implementar la toma de decisiones humana en el circuito, pero si los costos de estas inversiones exceden los beneficios potenciales, reducir las pérdidas temprano puede ser la mejor solución.
Estas consideraciones son demasiado matizadas para ser gestionadas en una sola sesión de trabajo. En cambio, los propietarios de proyectos deben involucrar a los equipos de negocios, usuarios finales, técnicos y de gobierno en un diálogo iterativo durante todo el proceso de desarrollo del sistema.
En Borealis AI, desglosamos este proceso en el siguiente ciclo de vida:
Durante la fase de diseño, la primera parte del proceso, buscamos definir el objetivo comercial, traducir ese objetivo en un objetivo medible y determinar si habrá suficiente impacto comercial para justificar el esfuerzo de desarrollo. Una parte clave de esta fase es evaluar la brecha entre lo que queremos medir y lo que podemos medir, y garantizar que el negocio tenga claras las consecuencias de la brecha entre un resultado deseado y el proxy disponible. Muy a menudo, las empresas luchan por definir métricas precisas requeridas para que un algoritmo satisfaga las necesidades comerciales o de los usuarios; Esto frustra a los equipos técnicos, que buscan una línea de base clara para determinar si una tarea es factible. Los equipos pueden gestionar esto comunicando con frecuencia sus resultados al negocio durante las fases de diseño y exploración, y, cuando sea necesario, cortando proyectos temprano debido a preocupaciones anticipadas con tasas de error o insignificancia económica. Por ejemplo, una empresa de auditoría o un banco que busca automatizar una parte de un proceso de cumplimiento puede decidir desde el principio que una tasa de precisión de predicción del 70% es demasiado arriesgada para la certeza que requieren en sus procesos comerciales.
Las preguntas sobre explicabilidad, equidad y privacidad deben abordarse durante las fases de exploración y refinamiento, cuando los equipos técnicos experimentan con diferentes variaciones del modelo para determinar el mejor enfoque para resolver el problema comercial. La clave a tener en cuenta es que no todos los algoritmos se crean de la misma manera (al menos hoy, ya que esto puede cambiar con futuras investigaciones): algunos son más explicables que otros, y algunos admiten variantes de preservación de la privacidad más fácilmente que otros. Como tal, lo más importante es que los equipos técnicos conozcan las limitaciones de antemano, no después de que ya hayan invertido tiempo en crear un algoritmo que no cumpla con los requisitos comerciales. Los equipos de gobierno deberían entablar un diálogo durante las fases de viabilidad y refinamiento del modelo; esto no significa que la validación de preproducción deba desaparecer, sino que los equipos no deberían esperar hasta el final del proceso para comenzar el diálogo. Finalmente, a veces es difícil hacer un llamado sobre si se debe cambiar la precisión por privacidad, justicia o explicabilidad hasta que se pueda medir el impacto en el rendimiento del sistema. Como tal, los equipos técnicos pueden crear algunas soluciones candidatas y presentar opciones a un líder empresarial para hacer un llamado a qué sistema avanzar a la producción.
Gran parte de esto será familiar para los equipos acostumbrados a aplicar métodos ágiles en proyectos de desarrollo de software. La naturaleza inductiva de los sistemas de aprendizaje automático plantea algunas preguntas nuevas y matizadas, pero los principios de la comunicación iterativa y multifuncional siguen siendo más importantes que nunca. La mayoría de las veces, hacer que una solución funcione requiere el compromiso de los equipos de negocios, técnicos y de gobierno. Contrariamente a las narraciones populares, podríamos concluir que la práctica de aplicar el aprendizaje automático de una manera que defienda los principios y valores de una organización es un terreno fértil para el razonamiento y la comunicación. Hacerlo bien requiere que ejercitemos las habilidades que nos hacen humanos.
Kathryn Hume lidera el desarrollo de productos y negocios para Borealis AI.
Alex LaPlante lidera la gestión de riesgos y las prácticas de banca comercial para Borealis AI.
Tecnología
Harvard Business Review
Aquí hay un escenario común para las organizaciones que aplican el aprendizaje automático en sus procesos comerciales. Los equipos de negocios y técnicos se han alineado en una declaración de problema general para una tarea de aprendizaje automático. Todos están entusiasmados, y el equipo técnico se va por unos meses y experimenta con diferentes algoritmos en los datos disponibles, eventualmente convergiendo en un algoritmo que creen logra el mayor rendimiento en las métricas acordadas. Orgullosos de su trabajo, traen resultados a la empresa para integrarlos en un proceso comercial o implementarlos como una característica en un producto de software.
Sin embargo, antes de la implementación, su modelo algorítmico debe ser revisado por un equipo de gobierno para garantizar que cumpla con los requisitos de gestión de riesgos. El equipo de gobierno busca documentación rigurosa sobre los requisitos que el equipo técnico nunca consideró: ¿podemos explicar por qué el algoritmo deriva sus resultados de sus entradas? ¿Qué controles usa el sistema para proteger la privacidad del cliente? ¿Qué tan estables son los datos de entrada durante largos períodos de tiempo, especialmente si solo planeamos volver a entrenar el modelo una vez al mes, o incluso una vez al año? ¿Podemos asegurar que el algoritmo produzca resultados justos en la población de clientes afectados?
El equipo técnico responde que nadie les informó sobre estos requisitos, por lo que no los consideraron durante el desarrollo. Frustrados, comienzan de nuevo, esta vez limitando las opciones sobre posibles algoritmos y datos de entrada para garantizar que se cumplan los requisitos de gestión de riesgos recientemente articulados. Se desperdicia tiempo y esfuerzo. Las líneas de tiempo se estiran. Los ejecutivos se preguntan por qué las cosas están tomando tanto tiempo y están tan ansiosos que van a la zaga de los competidores.
Esta falta de comunicación y coordinación resulta de lagunas en el conocimiento que tienen las partes interesadas comerciales y técnicas sobre lo que se necesita para hacer que el aprendizaje automático funcione en aplicaciones del mundo real, así como los enfoques en cascada residuales para la gestión de proyectos técnicos. Como el campo aún es joven, muchos desarrolladores de aprendizaje automático carecen de experiencia en la creación de aplicaciones empresariales, y muchas partes interesadas en los negocios tienen un conocimiento insuficiente del aprendizaje automático para saber qué preguntas hacer al analizar y administrar proyectos. Para innovar de manera efectiva, los propietarios de proyectos necesitan saber qué compensaciones y decisiones enfrentarán al construir un sistema de aprendizaje automático, y cuándo deben evaluar estas compensaciones para minimizar la frustración y el esfuerzo desperdiciado.
Comencemos con el qué. Hacer que el aprendizaje automático funcione en un contexto empresarial a menudo requiere una serie de decisiones y compensaciones que pueden afectar el rendimiento del modelo. En el centro del asunto se encuentra la estructura de los algoritmos de aprendizaje automático, que usan datos para aprender mapeos aproximados entre entradas y salidas que son útiles para un negocio. Con el software estándar, los programadores escriben instrucciones específicas que ejecutan las mismas operaciones cada vez; La desventaja es que estas instrucciones se limitan a lo que se puede articular explícitamente en el código. Con el aprendizaje automático, por el contrario, los programadores especifican el objetivo del programa y escriben un algoritmo que ayuda al sistema a aprender de manera eficiente el mejor mapeo de entrada-salida de los datos disponibles para lograr este objetivo, en lugar de seleccionar un mapeo particular desde el principio. Este enfoque nos permite abordar escenarios en los que es mucho más difícil escribir las reglas precisas (por ejemplo, reconocimiento de imágenes, análisis textual, generación de secuencias de video), pero la compensación es que la salida del sistema puede ser impredecible o poco intuitiva. De esta base inductiva surgen muchos de los matices de la aplicación de sistemas de aprendizaje automático, especialmente para equipos de negocios y tecnología que están acostumbrados a los sistemas informáticos basados en reglas.
A menudo, estos matices cobran vida a medida que las compensaciones que los equipos comerciales necesitan hacer durante el desarrollo del sistema. Por ejemplo, los equipos pueden encontrar que el objetivo que el negocio busca predecir u optimizar no puede medirse fácilmente con los datos disponibles, por lo que recurren a un proxy medible. La preocupación aquí es que el sistema aprenderá a predecir esto y solo este proxy, no el verdadero objetivo; cuanto más lejos esté el proxy del objetivo, menos útil será la salida del sistema para el negocio.
Otras compensaciones sopesan la precisión del modelo frente a preocupaciones como la explicabilidad, la imparcialidad y la privacidad. Si la empresa duda en adoptar un modelo sin una explicación de cómo y por qué asigna las entradas a las salidas, el equipo técnico podría restringir el conjunto de soluciones potenciales a los algoritmos que permiten una mejor explicabilidad, pero esto puede tener el costo de reducir el rendimiento del modelo . Del mismo modo, si a la empresa le preocupa que el sistema pueda propagar resultados injustos a ciertos segmentos de clientes, o que el sistema pueda exponer datos confidenciales del usuario, el equipo técnico podría restringir su atención a algoritmos que garanticen la equidad y la privacidad, lo que también podría afectar el rendimiento.
A veces, las tasas de error inherentes hacen que sea mejor reducir las pérdidas antes de tiempo. Esto ocurre particularmente en contextos donde el costo de cometer un error es alto (por ejemplo, la confianza del usuario podría ser denigrada o los usuarios esperan certeza). El equipo técnico podría invertir mucho en el diseño del sistema para mejorar la precisión o implementar la toma de decisiones humana en el circuito, pero si los costos de estas inversiones exceden los beneficios potenciales, reducir las pérdidas temprano puede ser la mejor solución.
Estas consideraciones son demasiado matizadas para ser gestionadas en una sola sesión de trabajo. En cambio, los propietarios de proyectos deben involucrar a los equipos de negocios, usuarios finales, técnicos y de gobierno en un diálogo iterativo durante todo el proceso de desarrollo del sistema.
En Borealis AI, desglosamos este proceso en el siguiente ciclo de vida:
- Diseño: defina el problema y articule el caso de negocio. Determine la tolerancia de la empresa al error y determine qué regulaciones, si las hay, podrían afectar la solución.
- Exploración: realice un estudio de viabilidad sobre los datos disponibles. Determine si los datos están sesgados o desequilibrados, y analice la necesidad de explicabilidad de la empresa. Puede requerir la repetición de la fase de diseño según las respuestas a estas preguntas.
- Refinamiento: Entrene y pruebe el modelo (o varias variantes potenciales del modelo). Calcule el impacto de las mejoras de equidad y privacidad en la precisión.
- Construir y enviar: Implemente una versión de grado de producción del modelo. Determine con qué frecuencia debe volverse a entrenar el modelo y si su salida debe almacenarse, y cómo estos requisitos afectan las necesidades de infraestructura.
- Medir: documentar y aprender del rendimiento continuo del modelo. Escale a nuevos contextos e incorpore nuevas características. Discuta cómo gestionar errores del modelo y resultados inesperados. Puede requerir la repetición de la fase de construcción y envío, según las respuestas a estas preguntas.
Durante la fase de diseño, la primera parte del proceso, buscamos definir el objetivo comercial, traducir ese objetivo en un objetivo medible y determinar si habrá suficiente impacto comercial para justificar el esfuerzo de desarrollo. Una parte clave de esta fase es evaluar la brecha entre lo que queremos medir y lo que podemos medir, y garantizar que el negocio tenga claras las consecuencias de la brecha entre un resultado deseado y el proxy disponible. Muy a menudo, las empresas luchan por definir métricas precisas requeridas para que un algoritmo satisfaga las necesidades comerciales o de los usuarios; Esto frustra a los equipos técnicos, que buscan una línea de base clara para determinar si una tarea es factible. Los equipos pueden gestionar esto comunicando con frecuencia sus resultados al negocio durante las fases de diseño y exploración, y, cuando sea necesario, cortando proyectos temprano debido a preocupaciones anticipadas con tasas de error o insignificancia económica. Por ejemplo, una empresa de auditoría o un banco que busca automatizar una parte de un proceso de cumplimiento puede decidir desde el principio que una tasa de precisión de predicción del 70% es demasiado arriesgada para la certeza que requieren en sus procesos comerciales.
Las preguntas sobre explicabilidad, equidad y privacidad deben abordarse durante las fases de exploración y refinamiento, cuando los equipos técnicos experimentan con diferentes variaciones del modelo para determinar el mejor enfoque para resolver el problema comercial. La clave a tener en cuenta es que no todos los algoritmos se crean de la misma manera (al menos hoy, ya que esto puede cambiar con futuras investigaciones): algunos son más explicables que otros, y algunos admiten variantes de preservación de la privacidad más fácilmente que otros. Como tal, lo más importante es que los equipos técnicos conozcan las limitaciones de antemano, no después de que ya hayan invertido tiempo en crear un algoritmo que no cumpla con los requisitos comerciales. Los equipos de gobierno deberían entablar un diálogo durante las fases de viabilidad y refinamiento del modelo; esto no significa que la validación de preproducción deba desaparecer, sino que los equipos no deberían esperar hasta el final del proceso para comenzar el diálogo. Finalmente, a veces es difícil hacer un llamado sobre si se debe cambiar la precisión por privacidad, justicia o explicabilidad hasta que se pueda medir el impacto en el rendimiento del sistema. Como tal, los equipos técnicos pueden crear algunas soluciones candidatas y presentar opciones a un líder empresarial para hacer un llamado a qué sistema avanzar a la producción.
Gran parte de esto será familiar para los equipos acostumbrados a aplicar métodos ágiles en proyectos de desarrollo de software. La naturaleza inductiva de los sistemas de aprendizaje automático plantea algunas preguntas nuevas y matizadas, pero los principios de la comunicación iterativa y multifuncional siguen siendo más importantes que nunca. La mayoría de las veces, hacer que una solución funcione requiere el compromiso de los equipos de negocios, técnicos y de gobierno. Contrariamente a las narraciones populares, podríamos concluir que la práctica de aplicar el aprendizaje automático de una manera que defienda los principios y valores de una organización es un terreno fértil para el razonamiento y la comunicación. Hacerlo bien requiere que ejercitemos las habilidades que nos hacen humanos.
Kathryn Hume lidera el desarrollo de productos y negocios para Borealis AI.
Alex LaPlante lidera la gestión de riesgos y las prácticas de banca comercial para Borealis AI.
No hay comentarios:
Publicar un comentario