Orquestación de Flujos de Trabajo de Contenido a Escala de Netflix

Bienvenidos a todos. Soy Pradeep Shah, un ingeniero de software senior en el equipo de infraestructura de comprensión de contenido en Netflix. En Netflix, antes de que cualquier título llegue a un espectador, pasa por una cadena de decisiones relacionadas con la comprensión del contenido sobre qué es, qué contiene y cómo debe presentarse. Algunas de estas decisiones son tomadas por motores de reglas, otras por modelos de ML, y algunas requieren que los humanos tomen la decisión.

Hoy, quiero hablar sobre cómo construimos la infraestructura para coordinar de manera confiable estos tres elementos. También les mostraremos cómo la misma infraestructura se extiende naturalmente a los agentes de AI usando nuestro ejemplo de prototipo. Pero antes de explicar los detalles del sistema, cubramos los conceptos clave. Uno, flujo de trabajo. Es el proceso que define qué trabajo necesita realizarse. Y dos, la tarea rastrea la unidad de trabajo de principio a fin.

Ahora que entendemos los conceptos clave, permítanme establecer el contexto sobre por qué el problema es difícil. Netflix tiene un catálogo enorme que abarca mercados e idiomas. Cada título en la plataforma lleva una gran cantidad de atributos de metadatos, señales de contenido que describen qué es el título, qué elemento contiene, etc. Estos metadatos son el motor detrás de la descubribilidad del contenido, cómo el título correcto se presenta al espectador correcto. La mala calidad de los metadatos degrada el descubrimiento, reduce el compromiso y erosiona la confianza del consumidor. El volumen y la variedad de señales significa que esto no puede hacerse manualmente. AI, automatización, motores basados en reglas, etc. son todos esenciales. Pero aquí también está el desafío central de diseño. No todas las decisiones son iguales. Las reglas son rápidas y baratas, pero frágiles. Se rompen en casos extremos. Los modelos de ML son escalables, pero imperfectos. La confianza varía, y necesitamos un mecanismo para capturar predicciones de baja confianza antes de que causen problemas de calidad. Los humanos son precisos, pero este enfoque no escala. Queremos el juicio humano precisamente donde agrega más valor, no como un recurso general. La pregunta no es cuál usar. La respuesta es los tres en la combinación correcta para cada pieza de trabajo. Por lo tanto, necesitamos un sistema que dirija cada pieza de trabajo al trabajador adecuado, humano, modelo, agente de AI, etc. Captura cada decisión humana como retroalimentación estructurada para el reentrenamiento del modelo.

Rastrea el estado a través de muchos flujos de trabajo concurrentes. Diferentes equipos integran su propia lógica sin reconstruir la infraestructura. Y por último, se adapta al nuevo tipo de contenido y flujos de trabajo sin ningún cambio de código. El mantra para nuestro nuevo sistema es construir solo una vez, pero reutilizar a través de los tres flujos de trabajo.

Entonces, ¿cómo construimos un sistema de orquestación que también funcione de manera confiable a escala? Pero antes de eso, respondamos la pregunta obvia. ¿Cuál es el problema con las implementaciones de flujo de trabajo personalizadas? ¿Por qué necesitamos un sistema que lo haga todo? Construimos dos implementaciones de flujo de trabajo personalizadas antes de esto, y esto fue realmente crítico porque aprendimos las principales inflexibilidades con nuestras implementaciones anteriores. Construir múltiples flujos de trabajo significaba discrepancias entre diferentes implementaciones, lo que llevaba a una sobrecarga de mantenimiento, tiempos más largos para construir, y también tenía un impacto aguas abajo.

Los datos de gestión de tareas se capturaban de manera diferente en diferentes sistemas. Eso significaba que los equipos de ciencia de datos, por ejemplo, tenían que normalizarlos de manera diferente para cada flujo de trabajo antes de poder realizar cualquier análisis de calidad entre flujos de trabajo. Lo que observamos es que estos flujos de trabajo comparten una columna vertebral común: activar, enrutar, ejecutar, verificar y completar. Solo cambia la lógica de negocio. Una vez que vimos eso claramente, la respuesta correcta fue un marco. Definiríamos la columna vertebral una vez y dejaríamos que los equipos contribuyeran solo con la parte que es única para su flujo de trabajo. Nuestro nuevo sistema se construyó sobre nuestros aprendizajes de nuestras implementaciones anteriores.

Por ejemplo, en el mundo antiguo, cada flujo de trabajo tenía una máquina de estado personalizada, dependiendo de si requería cumplimiento humano o control de calidad. Uno tenía siete estados, el otro tenía nueve. La lógica de negocio estaba incrustada directamente en las transiciones de estado, lo que significaba que la máquina de estado y la lógica del flujo de trabajo estaban estrechamente acopladas e imposibles de usar. Agregar nuevas fases, como el control de calidad, una vez que el flujo de trabajo se había enviado significaba mucho trabajo. También significaba que los operadores tenían que ser capacitados para el flujo de trabajo y la ciencia de datos tenía que construir sus tuberías nuevamente, porque ahora las transiciones de estado en sí mismas han cambiado.

La solución fue colapsar todas las máquinas de estado a través de un ciclo de vida simple y desacoplar la lógica de negocio. Esto nos ayudó a lograr consistencia a través de diferentes flujos de trabajo. Entonces, ¿cómo hicimos eso? Al separar la gestión de estados y la ejecución del flujo de trabajo, ideamos una arquitectura de dos niveles. El primer nivel era la capa de gestión de tareas, que responde preguntas como ¿cuál es la tarea? ¿Quién la posee? ¿Está esperando requisitos previos, se está trabajando activamente en ella o está terminada? Esto sucede para obtener respuestas rápidas a través de entidades, a través de diferentes flujos de trabajo, capturando diferentes metadatos.

El segundo nivel es la capa de orquestación. Dada una tarea lista, ¿cuáles son los pasos para ejecutarla? ¿Depende de algoritmos o agentes de AI o humanos? ¿Dónde y cómo viven los metadatos, etc.? Cuando estas dos preocupaciones se combinan como lo estaban en nuestros sistemas anteriores, terminamos con máquinas de estado frágiles y rígidas que no se pueden reutilizar a través de equipos y lógica de flujo de trabajo. La lógica del flujo de trabajo no podía razonarse de manera independiente en absoluto. Separarlas es lo que hizo que el sistema fuera lo suficientemente extensible para manejar reglas, modelos y humanos como tipos de trabajadores intercambiables. Para implementar el primer nivel de nuestro sistema, utilizamos Raw Holo.

de trabajadores intercambiables. Para implementar el nivel uno de nuestro sistema, utilizamos Raw Holo. Raw Holo es el almacén de datos comprimidos en memoria interna de Netflix, utilizado ampliamente dentro de Netflix. En lugar de hacer llamadas de red a una base de datos o un caché para cada lectura, cada instancia de lector en Raw Holo contiene el conjunto completo de datos en su propio heap de JVM. Una lectura es solo un recorrido de la memoria en proceso. Las escrituras en Raw Holo se propagan a todas las instancias de lector en milisegundos de un solo dígito.

Para nuestro caso de uso, esto importa enormemente ya que hace que la búsqueda a través de flujos de trabajo a través de entidades sea extremadamente rápida. La advertencia aquí es que una vez que una tarea está completa, necesitamos moverla a un almacenamiento objetivo como una base de datos tradicional para mantener el uso de memoria bajo control. Netflix ha publicado un artículo de investigación sobre Raw Holo al cual tendré un enlace al final de la presentación. Para implementar la capa de orquestación utilizamos Conductor, que es un proyecto de código abierto construido en Netflix. Tiene reintentos integrados, tiempos de espera, ramificación condicional, ejecución paralela, sub-flujos de trabajo, etc. Los pasos- dentro de los flujos de trabajo son sin estado y agnósticos al lenguaje. Los equipos implementan pasos individuales en sus propios repositorios.

Los pasos podrían ser como llamadas GraphQL, llamadas gRPC, tareas de espera, etc. También proporciona una interfaz de usuario DAG visual, visibilidad en tiempo real de cada paso, las entradas y las salidas, y reintentos, historiales, etc. Así que aquí está el flujo de trabajo SATL Conductor que posee la capa de orquestación de nuestro sistema. Permite al equipo conectar su sub-flujo de trabajo mientras mantiene el resto de la ejecución igual en diferentes casos de uso. Cuando la capa de orquestación está lista para ejecutar nuestra tarea, nuestro sistema inicia este flujo de trabajo. Primero ejecuta el sub-flujo de trabajo del equipo. Aquí es donde vive la lógica específica del equipo. Nuestro sistema es agnóstico a la implementación del sub-flujo de trabajo. Después de que el sub-flujo de trabajo del equipo se completa, devuelve una respuesta estándar, que contiene diferentes banderas.

El sistema también proporciona notificaciones, informes, paneles de control, etc. De esta manera, un equipo puede pasar de cero a un flujo de trabajo completamente operativo con inferencia de IA, revisión humana, control de calidad, etc. escribiendo solo la definición y configuración del sub-flujo de trabajo. No se requieren otros cambios en el sistema.

Así que respondamos la pregunta obvia. ¿Por qué necesitamos dos niveles? Conductor es muy poderoso, entonces ¿por qué no usarlo solo? Conductor es excelente en la ejecución paso a paso, pero no nos da la vista unificada.

No responde preguntas como, ¿cuántas tareas de cumplimiento están esperando revisión humana ahora mismo a través de tipos de flujo de trabajo? Raw Holo proporciona una vista unificada del estado del sistema y distribuye estos datos a los sistemas posteriores. Mientras tanto, Conductor es más adecuado para la ejecución de tareas individuales. Así que los dos niveles son complementarios, no redundantes.

Definimos los eventos necesarios para el desencadenamiento. Los enrutadores de eventos se suscriben a flujos de eventos. En una configuración, los equipos declaran de qué fuentes de eventos escuchar, qué condiciones filtrar, qué campos extraer y enriquecer para crear las tareas. No hay código personalizado.

Está completamente basado en configuraciones. Paso 2. Cuando llega el primer evento, la tarea se crea inmediatamente con el estado nuevo.

Nuevo significa que sabemos que este trabajo necesita realizarse pero los requisitos previos aún no se han cumplido. Esta visibilidad temprana tiene una ventaja operativa significativa. Si la tubería de inferencia de ML es lenta o está respaldada, podemos verlo inmediatamente como una pila creciente de tareas atascadas en estado nuevo esperando la señal del modelo. Capturar el ciclo de vida completo desde nuevo hasta completo nos proporciona un conjunto de datos rico. ¿Cuánto tiempo esperamos por el modelo?

Y debido a que estas tareas están en raw holo desde el principio, todo esto es visible en tiempo real para las interfaces de usuario, así como para los usuarios posteriores.

Paso 3. Cuando la tarea está lista, el flujo de trabajo de Conductor se inicia por el marco. Los equipos configuran el nombre de su sub-flujo de trabajo como parte de la configuración, que luego se captura automáticamente sin ningún cambio de código.

La lógica de negocio que es única para cada flujo de trabajo vive dentro de este sub-flujo de trabajo. Aquí es donde decidimos cuándo queremos confiar completamente en reglas o AI o escalar a Paso 4. Cuando la confianza del modelo de AI cae por debajo del umbral, los sub-flujos de trabajo pueden decidir llamar para la intervención humana, que es cuando nuestro flujo de trabajo de Conductor crea una tarea secundaria en raw holo.

El flujo de trabajo principal de Conductor entra en un estado de espera. La tarea secundaria aparece en el dashboard. Un revisor humano la recoge, ve las predicciones del modelo, la revisa y luego hace una conexión si es necesario y la envía. Una vez enviada, el marco envía una señal de finalización de vuelta a Conductor. Esto completa el flujo de trabajo principal de Conductor, completando así la tarea principal también. La elección de diseño crítica aquí es que la decisión humana es una salida estructurada.

No es un comentario o una nota. Cada retroalimentación ingresada durante la tarea de humano-en-el-bucle se ve como esquemas desnormalizados que funcionan a través de diferentes flujos de trabajo. La retroalimentación fluye automáticamente en la canalización de retroalimentación del modelo. Hemos utilizado intencionadamente esquemas independientes del dominio para permitir la reutilización a través del reentrenamiento del modelo y las canalizaciones de ciencia de datos a través de los flujos de trabajo.

Para reiterar, aquí está el flujo de trabajo completo. Un evento de contenido llega. Un nuevo título o una señal de metadatos o una señal ascendente, lo que sea. El evento llega. El enrutador de eventos lo recoge, lo filtra, lo enriquece y crea una tarea en raw holo con estado nuevo. Una vez que todas las señales previas han llegado, la tarea está lista. El marco inicia el flujo de trabajo de Conductor y lo mueve a en progreso. Conductor ejecuta el sub-flujo de trabajo del equipo, que es donde se ejecuta la lógica de dominio. Si la confianza del modelo es alta, el resultado se aplica automáticamente.

Si la confianza está por debajo del umbral, Conductor crea una tarea secundaria de revisión humana. El humano la recoge, la revisa, luego la corrige y la envía. El flujo de trabajo se reanuda con la decisión humana. Cuando la tarea se completa, ya sea automáticamente o con la revisión humana, todas las decisiones se capturan. El estado de la tarea se escribe entonces en el raw hollow, y las correcciones humanas fluyen hacia la canalización de retroalimentación del modelo.

Hemos construido notificaciones, alertas, monitoreo, que abordan nuestros flujos de trabajo actuales y también escalan automáticamente a futuros. Hasta ahora, hemos hablado de humanos, pero ¿qué pasa con los agentes de IA? Permítanme guiarles rápidamente a través de un ejemplo de cómo esto también escala a los agentes de IA. Un agente de IA es solo otro servicio que expone un endpoint. Publicas instrucciones y contexto, realiza el trabajo de manera asíncrona, y una vez hecho, regresa al flujo de trabajo principal. El mecanismo de espera que pausa el flujo de trabajo cuando un revisor humano trabaja es idéntico al mecanismo que pausa mientras un agente de IA está trabajando. El marco no distingue entre ellos. Solo espera esa devolución de llamada, que luego completa la tarea de espera. Prototipamos esto internamente.

Usamos el marco para impulsar un agente de IA que generó ERs de mejora de código para el propio servicio del marco. El agente recibió el contexto de la tarea, qué cambios necesitaban hacerse, los archivos que estaban en el alcance, y las restricciones a seguir. Realizó el análisis y creó un PR. Una vez que el PR fue fusionado, llamó de vuelta al flujo de trabajo principal. El marco lo trató como cualquier otra tarea completada. No hicimos ningún cambio en el marco para soportar este nuevo caso de uso. Esto nos ayudó a mostrar el poder del marco y cómo puede integrarse con diferentes tipos de trabajadores sin problemas. Entonces, ¿qué hace que esta arquitectura funcione?