Graphi: Revolutionizing Dataflow Programming

Así que hoy, voy a hablar sobre Graphi. Se escribe Graph AI, pero yo lo llamo Graphi, que es el entorno de programación declarativa de flujo de datos para AI Asia.

Así que las aplicaciones tradicionales se escriben típicamente, algún tipo de aplicación de control sobre una base de datos, pero debido al rápido avance de la IA, la forma en que construimos aplicaciones está cambiando bastante.

Además de la base de datos, usamos muchos modelos basados en redes neuronales como modelos de lenguaje grande o modelos de generación de imágenes, modelos de reconocimiento de imágenes. Así que esos, los modelos están típicamente disponibles como una API en el servidor remoto o a veces en la propia máquina. El desafío de esos, el módulo de IA, es que son muy lentos. A diferencia de las bases de datos típicas, algunas de las llamadas a la API tardan como 20 segundos, 30 segundos. Así que definitivamente tenemos que usar una API asíncrona, ¿verdad? No es adecuado usar una API síncrona que bloquee el hilo, pero creo que la industria aún no está reconociendo la importancia de las APIs asíncronas y también el entorno de programación profundo. Un buen ejemplo es que la API de Python del SDK de OpenAI es síncrona, lo cual es increíble desde nuestro punto de vista, ¿verdad?

Afortunadamente, la versión de JavaScript de OpenAPI es asíncrona, por lo que podemos aprovecharla, pero aún así lidiar con múltiples llamadas asíncronas es difícil. Y además, la aplicación está cambiando de un simple cliente-servidor a algo más distribuido, ¿verdad? A veces ejecutas toda la aplicación en el lado del cliente o toda la aplicación en el lado del servidor basado en algunos eventos externos o múltiples máquinas. Y lidiar con múltiples máquinas, esencialmente la computación distribuida, que no sabemos cómo escribir un programa de manera eficiente, ¿verdad? Por supuesto, usando JavaScript, podemos ejecutar el mismo código en el lado del cliente y del servidor. Pero nuevamente, coordinar la operación entre máquinas es complicado. Así que tenemos que realmente encontrar la manera correcta de programar. Y luego mi propuesta es que cambiemos de un flujo de control imperativo tradicional a la programación declarativa de flujo de datos. Así que esta es la típica aplicación tipo agente de IA. Llamamos a múltiples llamadas a API asíncronas.

Y algunas de ellas son de un segundo, algunas de ellas son de 20 segundos. Así que este tipo de programación, usando async y await, con lo que estamos familiarizados, y nos encanta porque es mucho más fácil comparado con un mecanismo de llamada a función. Y podemos escribir el código como si fueran sincrónicos.

Pero el problema es que este enfoque, terminamos ejecutando todo secuencialmente, ¿verdad? Aunque las funciones A, B, C son independientes. Así que podríamos ejecutarlas concurrentemente. Este estilo de programación las ejecuta secuencialmente. Así que la cantidad total de tiempo requerido para ejecutar esta función, esa operación, es la suma de cada llamada a la API.

Así que para resolver ese problema, sabemos que podemos usar promise all para ejecutar las funciones A, B, C concurrentemente. Así que realmente reducimos la cantidad total de tiempo requerido. Pero nuevamente, esto no es óptimo aún porque las funciones D y E son independientes. Así que podemos añadir otra promise all para ejecutar D y E concurrentemente. Mucho, mucho mejor que todo secuencialmente, pero aún no es óptimo, ¿verdad? La función D realmente no necesita esperar a que C termine. Así que podríamos realmente comenzar D inmediatamente después de que A y B estén hechas, para que la cantidad total de tiempo se reduzca aún más.

Pero el asunto es, este es el quiz, ¿verdad? ¿Cómo escribir este código? Muy complejo. Esto es solo seis llamadas a funciones. Pero manejar este código de dependencia asíncrona se volvió realmente complicado, ¿verdad? Puedes combinar el promise all, async await, más la llamada a función. Podríamos escribir ese código. Pero ese tipo de código es realmente difícil de leer, difícil de escribir y difícil de mantener. Podemos fácilmente introducir algunos errores y un efecto secundario tan difícil. Creo que la única solución es ir completamente a la programación de flujo de datos, que describe las dependencias de cada llamada a función pero también declarativa. El significado declarativo es que no necesitamos inventar un nuevo lenguaje. Podemos usar ya sea JSON o YAML.

Así que aquí es cómo describimos este programa en Graphi. Así que el lado izquierdo es solo un código, ¿verdad? Simplemente define un gráfico, ¿verdad? Con un nodo seis de A a F, y describe, ¿verdad? Que el nodo A necesita llamar a la función A, el nodo B necesita llamar a la función B, y A, B, C son independientes. Pueden ejecutarse en cualquier momento. Y el nodo D, E, F tiene alguna entrada, ¿verdad? D tiene entrada de A y B, E tiene entrada de B y C. Así que el programa simplemente describirá fácilmente esas dependencias, ¿verdad? Los flujos de datos. Y luego el tiempo de ejecución, en este caso, el tiempo de ejecución de Graph AI averiguó cuándo, cómo ejecutar. Así que el programador no necesita decir explícitamente que D necesita volver a ejecutar R, S, Q, A y B, es solo flujo de datos. Luego vamos a la programación de IA real.

Por ejemplo, cuando queremos llamar a open in AI, construimos una pequeña función llamada open in AI agent, que toma el prompt de la entrada del usuario y luego llama a la API de open in AI y devuelve el resultado como una propiedad de texto. Así que simplemente tres nodos, obtienen la entrada del usuario, se la dan a LL, y luego muestran la salida.

Y esto es solo una pregunta y respuesta. Así que para convertirlo en un programa de chat, necesitamos tener algún tipo de bucle, pero el desafío es que el flujo de datos es cíclico. No se puede tener una flecha que regrese. Así que para resolver ese problema, se nos ocurrió la idea del concepto de un bucle dentro de un gráfico. Así que puedes especificar que este gráfico necesita ejecutarse tres veces, o a veces se ejecuta hasta que se cumple una cierta condición, al igual que el bucle while. Entonces podemos ejecutar este gráfico cíclico varias veces. Y esto es simplemente, solo ejecutamos el mismo código tres veces.

Así que no es un chat. Es simplemente obtener la entrada del usuario, luego mostrar el resultado de LLM. Así que para convertirlo en una conversación real, necesitamos acumular mensajes del usuario y LLM en un array, y luego devolverlo a LLM. Así que todo el código se ve así. Un poco complejo, pero no tan complejo. Para mostrarte cómo funciona, quiero mostrarte la demo. Así que el mismo gráfico ahora se está ejecutando en el navegador, ¿verdad? Como dije, el gráfico está implementado en PipeScript. Así que puede ejecutarse en el lado del servidor o del cliente, y esto se está ejecutando dentro del navegador. Y debido al gráfico, podemos obtener fácilmente algunos mensajes de esos gráficos para indicar el estado del gráfico.

Así que ahora mismo, está esperando, el nodo de entrada del usuario está esperando la entrada del usuario. Así que el verde indica que está activo. Así que voy a escribir qué es el dato. Luego presiono enviar, entonces verás que los datos realmente fluyen y se ejecutan. Bien. ¿Verdad? Así que cuando la entrada del usuario, en realidad, dos nodos, el nodo de verificación de entrada recibe la entrada del usuario y luego verifica si el usuario quiere terminar. Y en este caso, simplemente verifica si escribo atrás, y luego la bandera de continuar se convierte en falsa. Pero el valor predeterminado es continuar. Otro nodo, el nodo de mensaje del usuario, recibe la entrada del usuario, luego la añade a los mensajes, el array de mensajes, que originalmente está vacío, la añade y luego se la da a LLM. Así que LLM recibe solo un mensaje al principio, ejecuta, y luego genera la salida. La salida será mostrada por el nodo de salida, pero también este reductor recibió ese mensaje y luego lo añade a un array de mensajes.

Y este array punteado, la flecha indica una especie de caso especial solo permitido en el caso del bucle para que los datos regresen al nodo fuente. Voy a escribir uno más. Así que voy a decir, ¿cuál es el método? Y como estamos añadiendo los mensajes, sabe a qué se refiere con la programación de flujo de datos. Así que el LLM dice la ventaja de la programación de datos, como el paralelismo, la resultabilidad, la escalabilidad. Así que no hice una presentación, y luego simplemente añado al final, escribo adiós, luego el LLM me responde diciendo adiós, pero como el punto de control indica que quiero terminar la conversación, entonces esta bandera de continuar se vuelve falsa, por lo tanto, la ejecución del gráfico termina. Así es como la aplicación de chat dentro de Graphi.

Y Graphi, porque como dije que el gráfico típico la programación de flujo de datos, que porque el gráfico necesita ser cíclico, necesitábamos introducir algunos nuevos conceptos para facilitar la escritura de un programa complejo. Así que este es otro ejemplo, el primero mostramos el bucle, pero este es otro ejemplo, es un subgráfico. Así que en el grande, cuando comenzaste a escribir un gráfico grande, entonces se volvió complejo.

Así que a veces quieres crear una especie de gráfico anidado, para que podamos usar esa porción, al igual que una subrutina o función. Así que puedes tener un gráfico dentro de un gráfico, y desde el punto de vista externo, el gráfico exterior es desde el punto de vista, es como un nodo especial, que dentro ejecuta un subgráfico. Pero desde el padre ahora desde el punto de vista, simplemente recibe los datos de otro nodo en el lado del padre, ejecuta algunas operaciones de manera asincrónica, y luego devuelve la salida al padre. Así que esto permite el código reutilizable, también facilita la lectura del código.

Otro es el map reduce. Así que cuando estamos leyendo con un array de datos, como un benchmark, ¿verdad?, el benchmark de datos LLM tiene un gran conjunto de preguntas y respuestas. Y necesitamos lanzarlo a LLM para ver si responde correctamente. Y ejecutar ese código es nuevamente complejo. Si intentas hacerlo concurrentemente, así que hoy, muchas personas simplemente lo hacen de manera sincrónica, pero usando un gráfico, puedes simplemente dar un array de datos a este agente de mapa, lo llamamos el agente de mapa, el agente de mapa, reconoce ese array, y ejecuta el subgráfico en cada elemento.

Y luego, por supuesto, concurrentemente. Así que deberías tener cuatro elementos en la fila, luego el agente de mapa inicia cuatro operaciones paralelas concurrentemente. Y luego obtiene el resultado de cada ejecución, y luego lo empaqueta de nuevo en el array de resultados, y luego lo devuelve al padre. Así que estamos usando esto, y podemos ejecutar como el tipo de operación map reduce. Otra complejidad surge cuando el gráfico se vuelve grande y demasiado pesado para ejecutarse en una sola máquina. Podemos especificar realmente una cierta porción del gráfico, típicamente un subgráfico, para ser ejecutado en el servidor remoto. Nuevamente, todo es parte de la extensión del gráfico. Así que no necesitas preocuparte por cómo ejecutar remotamente. Simplemente necesitas especificar que este subconjunto del gráfico necesita ser ejecutado en esta URL, luego la extensión del gráfico lo resolverá y luego ejecutará. Y desde el punto de vista del padre, el punto de vista del gráfico del padre, es simplemente un nodo, ¿verdad?, que realiza la ejecución asincrónica.

Pero internamente, ese nodo envía el subgráfico al servidor remoto, el servidor remoto ejecuta concurrentemente, y devuelven el resultado a ese nodo, ese nodo, luego da el resultado de vuelta al nodo padre. Así es como funciona la computación distribuida dentro de un gráfico. Y como dije, porque el gráfico está implementado en pipes route, así que puedes ejecutar en el lado del cliente o del servidor o en cualquier lugar.

que como una base de datos especial necesita ser accedida solo desde un servidor particular. Así que en ese caso, damos un subgráfico a ese servidor para ejecutar en nombre del servidor externo, el cual no tiene acceso a la base de datos, ese servidor ejecuta ese gráfico, obtiene el resultado, y luego solo el resultado regresa al servidor padre.

Así es como ejecutamos gráficos distribuidos. Así que este es el GraphI, y esto es nuevo, pero lo hemos hecho de código abierto. Así que está disponible tanto en GitHub como también en node package manager. Y tiene una licencia completamente MIT. Así que cualquiera puede acceder a él, usarlo hoy. Estamos trabajando activamente para mejorar. De hecho, el motor está bien hecho, creo que muy pequeño. Y estamos agregando múltiples capacidades en extensiones, como un subgráfico o gráfico remoto o mapas, reducir, son todas extensiones.

Así que podemos agregar fácilmente las características al GraphI usando ese mecanismo. Así que estamos buscando que otras personas participen y nos ayuden. Necesitamos más mejoras en tutoriales y ejemplos, pero estamos muy abiertos.