En un artículo anterior de la serie, tratamos en detalle en qué consiste lo que conocemos como prueba de concepto (proof of concept o PoC) y vimos su relevancia en el ámbito de Data Science e IA. En resumen, una PoC consiste en el desarrollo de un proyecto a pequeña escala con un alcance limitado, en un entorno controlado, con el objetivo de testear la viabilidad y utilidad de una solución antes de implementarla a gran escala.

Hemos desarrollado con éxito la PoC, ¿y ahora qué?

Una vez hemos conseguido ejecutar la PoC con éxito y demostrar el valor de la solución, el paso lógico es incorporarla a los procesos operativos de la compañía. La operativización de una solución es un proceso que suele requerir más esfuerzo que una PoC. Por ello es crucial primero validar la solución antes de escalarla, y después operativizar (explotar) los resultados en un contexto real.

La mejor forma de explicar estas fases es mediante un ejemplo. Supongamos que desde el departamento de Marketing de una compañía financiera quieren mejorar la eficacia de sus campañas de cross-selling. Hasta ahora seleccionaban, con reglas simples de negocio, a qué clientes van a contactar para ofrecerles un nuevo producto. Sin embargo, consideran que este procedimiento es poco eficiente y pueden mejorar la tasa de conversión mediante técnicas de analítica avanzada.

Con estos requisitos hicieron una PoC con un modelo analítico de propensión de contratación. Para hacerlo de forma rápida acotaron el alcance modelando sólo un producto de toda la cartera, y muestreando a la población de clientes potenciales, con un histórico de datos limitado. La PoC ha sido un éxito: la tasa de conversión es, teóricamente, tres veces superior a la actual. La compañía ha decidido operativizar la solución.

Validación

El objetivo ahora es hacer un piloto de la solución en un entorno real y comprobar si se mantienen los niveles de rendimiento teóricos. Ejecutaremos la solución durante unas pocas campañas de tal forma que podamos comprobar la estabilidad de la tasa de conversión. Además, en esta fase piloto otros stakeholders evaluarán también la solución, por ejemplo: negocio, infraestructura, compliance, etc.

Validación por negocio

Lo primero es validar si la solución analítica aporta un valor de negocio adicional a la organización. Este tema debería ser un problema menor si hemos realizado correctamente la fase de priorización de casos de uso.

En cualquier caso, uno de los aspectos clave es el rendimiento del modelo analítico en un entorno real. Para ello, extenderemos el análisis de las métricas obtenidas en la fase de desarrollo a otros productos ofertados en la cartera de la compañía para comprobar si el rendimiento es igual de bueno. Se analizará también la estabilidad en el tiempo de estas métricas.

Además, no podemos olvidarnos de la validez económica. La productivización de la solución implica cambios en los procesos de la compañía, lo que genera una serie de costes de desarrollo y arquitectura. La organización ha de valorar el impacto económico del cambio y asegurarse el retorno de la inversión.

Validación por arquitectura

En este punto se engloban aquellos aspectos de la operativización que pueden tener un impacto en la infraestructura tecnológica de referencia de la compañía. Uno de los criterios clave en todo proceso de validación y productivización de una PoC es la escalabilidad. Poner un desarrollo en producción, implica ampliar el alcance a toda la cartera de clientes y de productos, con el consecutivo aumento en volumetría de datos. Por lo tanto, se hace necesaria una adecuada evaluación de los requisitos de explotación en términos de infraestructura y su impacto en el estado actual.

También hay que comprobar si la solución puede proveer el entregable final en un tiempo adecuado (timeliness). Supongamos que nuestro modelo utiliza cierta información generada con periodicidad mensual (transacciones de tarjeta, por ejemplo), pero la ingesta de esta información se realiza trimestralmente. En esta situación, la explotación del modelo no puede alinearse con la operativa de la organización y pierde todo su valor. Por tanto, deberíamos replantearnos la metodología de ingesta de datos de la compañía.

Otro aspecto importante es la compatibilidad. Este criterio hace referencia a la capacidad de integrar el proceso de explotación de la solución en los sistemas usados ya en la compañía. El despliegue de un componente de software en un entorno de producción puede requerir de una exigente validación de seguridad. Probablemente para el desarrollo de nuestro modelo de propensión se haya usado un framework de desarrollo reciente que aún no habrá sido validado internamente para su uso en entornos de producción.

Validación por responsabilidad corporativa

Cada vez más se está haciendo más énfasis en la importancia de un uso responsable de la analítica avanzada y la IA. En este caso, la responsabilidad corporativa hace referencia al impacto social que tiene la toma de decisiones basada en IA. Por tanto, se hace fundamental que las soluciones o productos basados en datos cumplan una serie de principios como:

1. No tener sesgo (bias). La solución analítica no puede basar su predicción en el género, la raza, la orientación sexual, etc.
2. Ser justa (fairness). La decisión tomada a partir de la solución ha de ser imparcial para todos los sujetos estudiados.
3. Ser transparente (transparency). La predicción tiene que poder ser comprendida por los sujetos afectados.

Desde LUCA, estamos haciendo un esfuerzo en esta área mediante el desarrollo de soluciones que nos ayuden a cumplir estos principios en nuestra práctica profesional.

Productivización

Una vez validados todos los pasos anteriores, estamos listos para productivizar el desarrollo. El objetivo de esta fase es la de integrar la solución analítica en la operativa de la organización.

Por un lado, es importante tener presente quién va a ser el usuario final del producto. Esto va a determinar cuál va a ser el formato de entregable y qué uso se le va a dar. En nuestro ejemplo, los resultados del modelo podrían ser ingestados como una tabla en el CRM del departamento o bien desarrollar una API que alimente a su vez a otras soluciones.

Para productivizar modelos, hay que definir una serie las condiciones de operación del modelo:

• Por tiempo de operación. Dependiendo de la operativa en la que se va a integrar el modelo puede ser necesario que este esté siempre en funcionamiento, o que sólo haga predicciones en momentos puntuales. Estas decisiones tienen impacto en la carga de los equipos, en los componentes de infraestructura necesarios, así como en el coste, por lo que hay que tomar las decisiones adecuadas. Por ello distinguimos:
  • Entrenamiento: en bloque (batch) o en tiempo real (online).
  • Predicciones: periódicas o en tiempo real
• Por plataforma de lanzamiento. Un modelo no deja de ser un código que ha de ejecutarse para obtener resultados. Cómo se ejecute ese modelo depende de la arquitectura configurada. Existen varias opciones:
  • Usando servicios propios de una plataforma cloud: AWS, Azure y otros ya disponen de una serie de servicios preconfigurados listos para entrar en producción.
  • Usando modelo serializados: Otra opción es serializar el modelo y ejecutarlo desde una instancia o servidor propio. Los formatos más comunes de serialización son (de más a menos común): Pickle, PMML, ONNX, POJO/MOJO.

Por último, es fundamental incorporar en el proceso de explotación mecanismos que permitan realizar una monitorización del rendimiento del modelo y del mantenimiento de este. Esta es una práctica crucial para que la solución siga aportando valor en el tiempo. Existen varias opciones, en función del perfil que monitorice el modelo:

• Perfiles técnicos (arquitectura). Sus métricas de interés se centran en analizar la evolución del modelo en términos de: carga de procesamiento, tiempo levantado (uptime), tiempo de procesamiento, coste de procesamiento, número de ejecuciones fallidas (retries) etc.
• Perfiles analíticos. Métricas relacionadas con la estadística: precisión/cobertura del entrenamiento y test, media de las predicciones, desviaciones, etc.
• Perfiles de negocio. Métricas relacionadas con el problema de negocio a resolver: ROI acumulado en el tiempo, número de clientes afectados, etc.

Cierre

El desarrollo de soluciones en formato PoC permite a las organizaciones innovar minimizando los costes y tiempos de ejecución. Sin embargo, hemos visto cómo el impacto de negocio de una PoC potencialmente exitosa ha de garantizarse mediante una adecuada metodología de validación y productivización. Una correcta validación en términos de negocio, infraestructura y responsabilidad resultan claves para maximizar el éxito de nuestra solución.

Todos los post de esta serie:

• Cómo transformar una compañía(I): Priorizar casos de uso
• Cómo transformar una compañía(II): conectar la tecnología con el negocio
• Cómo transformar una compañía(III): Profundizando en la arquitectura de referencia
• Cómo transformar una compañía (IV): Desarrollar una metodología de ingesta de datos
• Cómo transformar una compañía (V): Complementar las fuentes internas con datos externos
• Cómo transformar una compañía(VI):Las POC o como un proyecto pequeño puede salvar uno grande
• Cómo transformar una compañía(VII): Poner una PoC en producción