Ingeniería de grafos: principios de diseño para estructurar flujos de trabajo de agentes de IA

La ingeniería de grafos (Graph Engineering) es un enfoque que, en lugar de limitarse a mejorar la calidad de las respuestas de un único modelo de AI, diseña en qué orden y bajo qué condiciones se ejecutan diversas tareas y herramientas. Al representar un trabajo complejo mediante nodos y relaciones de conexión, es posible gestionar por separado las entradas y salidas de cada etapa, las causas de los fallos, las rutas de reintento y los puntos de aprobación humana.

Sin embargo, esta expresión todavía no es un término estándar único consensuado por todo el sector. Es más preciso entenderla como un concepto práctico que abarca el diseño de flujos de trabajo de agentes, la orquestación basada en grafos y el control multiagente.

Contexto de la aparición de los grafos en la ingeniería de AI

Los aspectos de interés en el diseño de aplicaciones de AI se han ampliado de la siguiente manera. Más que etapas oficiales de desarrollo que todas las organizaciones atraviesan de la misma forma, se trata de capas de diseño que se complementan entre sí.

Los prompts y el contexto siguen siendo necesarios dentro del grafo. Los bucles también pueden representarse mediante aristas cíclicas del grafo. Por tanto, la ingeniería de grafos no es una tecnología que descarte las técnicas anteriores, sino que se aproxima más a una perspectiva de diseño de nivel superior que las sitúa dentro de una estructura de ejecución.

Componentes de la ingeniería de grafos

Nodos

Un nodo (Node) es una unidad de trabajo con una única responsabilidad claramente definida. Además de una llamada a un LLM, también puede ser un nodo el código convencional para consultar una base de datos, llamar a una API de búsqueda, validar un formato, efectuar un cálculo o esperar la aprobación de un usuario.

Un buen nodo tiene entradas y salidas claras y puede probarse de manera independiente. Para facilitar la depuración, conviene delimitar la responsabilidad con nombres como recopilar materiales recientes del sector especificado, eliminar fuentes duplicadas o comprobar las pruebas de cada afirmación, en lugar de usar un nombre tan amplio como investigación de mercado.

Aristas

Una arista (Edge) es una transición de un nodo al siguiente. Hay aristas fijas que siempre conducen a la misma etapa siguiente, aristas condicionales que inspeccionan el estado para seleccionar una ruta y aristas de bifurcación que inician varias tareas al mismo tiempo.

Estado

El estado (State) son los datos compartidos mientras se ejecuta el grafo. Puede incluir la solicitud del usuario, resultados intermedios, fuentes de búsqueda, códigos de error, resultados de aprobación y número de repeticiones.

El estado no es un simple historial de conversación. Es necesario definir mediante esquemas y reglas qué campos son obligatorios, quién puede modificarlos, cómo se combinan los resultados paralelos y cuándo se elimina la información sensible.

Condiciones

Una condición (Condition) es una regla para seleccionar la siguiente ruta. Una condición determinista como ¿hay al menos tres fuentes? puede evaluarse mediante código. En cambio, una condición que requiera un juicio semántico, como ¿las pruebas respaldan suficientemente la conclusión?, puede necesitar una evaluación del modelo o una revisión humana.

Por qué es más fácil de controlar que un solo agente

Si se confían a un solo agente la investigación, el análisis, la redacción y la verificación, resulta difícil distinguir la causa cuando el resultado es incorrecto. Esto se debe a que en un mismo registro de ejecución quedan mezclados los errores de planificación, las omisiones en la búsqueda, los fallos en las llamadas a herramientas y la generación sin fundamento.

Al descomponer el trabajo en un grafo, se pueden gestionar los siguientes aspectos etapa por etapa.

• Limitar las herramientas permitidas y los permisos de acceso a datos de cada nodo.
• Guardar los resultados intermedios y evaluarlos de forma independiente.
• Volver a ejecutar únicamente el nodo fallido para reducir costes y tiempo.
• Obtener aprobación humana justo antes de una acción externa importante.
• Rastrear la ruta de ejecución, la latencia, el uso de tokens y los errores.

Sin embargo, dividir el proceso en muchos nodos no aumenta automáticamente la fiabilidad. Si la transferencia de estado es imprecisa o los criterios de evaluación son ambiguos, los errores pueden amplificarse a lo largo de varias etapas.

Patrones representativos de uso de grafos

Patrón de enrutador

Un enrutador selecciona distintas rutas según el tipo de solicitud o su nivel de riesgo. Por ejemplo, puede enviar una consulta sobre reembolsos al nodo de búsqueda de políticas y una incidencia técnica al nodo de diagnóstico.

Si los criterios de enrutamiento son simples, como palabras clave o el estado de una cuenta, es adecuado usar código. Si es necesario interpretar el contexto, puede utilizarse una clasificación del modelo, pero se requiere una salvaguarda que envíe el caso a una ruta predeterminada o a revisión humana cuando la confianza sea baja.

Patrón de ejecución paralela

Consiste en realizar simultáneamente tareas que no dependen unas de otras y combinarlas después en un nodo de agregación. Un ejemplo representativo es ejecutar en paralelo investigaciones sobre el mercado, los clientes y la competencia.

La paralelización puede reducir la latencia, pero aumenta el número de llamadas y el coste instantáneo. Si los resultados modifican al mismo tiempo el mismo campo de estado, también es necesario definir reglas de resolución de conflictos y el orden de fusión.

Patrón generador-evaluador

El generador crea un borrador y el evaluador decide, según los criterios, si se aprueba, se corrige o se vuelve a redactar. Como el resultado de la evaluación vuelve al generador, se forma un bucle dentro del grafo.

Si el evaluador también es un LLM, puede emitir un juicio incorrecto. Los aspectos que lo permitan deben complementarse con verificaciones deterministas, como la comprobación del esquema, la ejecución de pruebas o la verificación de las URL citadas, y es necesario establecer un número máximo de repeticiones para evitar bucles infinitos.

Patrón de aprobación del usuario

Antes de acciones difíciles de revertir o que impliquen una gran responsabilidad, como modificar sistemas externos, enviar mensajes, efectuar pagos o realizar despliegues, se detiene la ejecución y se espera el juicio de una persona. En la pantalla de aprobación, es más seguro mostrar no solo el resultado final, sino también la acción que se ejecutará, los datos utilizados, el impacto previsto y el método para revertirla.

Patrón de supervisor y especialistas

Un nodo supervisor descompone el trabajo, lo asigna a nodos especializados en búsqueda, análisis, redacción u otras funciones y después reúne los resultados. La separación de funciones es útil, pero aumentar el número de agentes no debe convertirse en un objetivo en sí mismo. Para procedimientos fijos, un flujo de trabajo explícito puede ser más predecible.

Principios para dividir las funciones de AI, el código y las personas

Usar un LLM cuando las reglas son claras incrementa innecesariamente el coste, la latencia y la falta de determinismo. Por el contrario, fijar todos los juicios mediante reglas de código dificulta el tratamiento de entradas reales con formas de expresión variadas. Un buen grafo combina las ventajas de los tres medios y valida las entradas y salidas en cada límite.

Diferencia entre un grafo de conocimiento y la ingeniería de grafos

Ambos conceptos pueden estar relacionados, pero no son iguales.

• Un grafo de conocimiento es una representación de datos que estructura entidades como personas, organizaciones, documentos y conceptos, así como sus relaciones.
• Un grafo de ejecución de agentes representa en qué orden y bajo qué condiciones se ejecutan las tareas.
• La ingeniería de grafos puede referirse a la práctica de diseñar la estructura, el estado, el control, la validación y el modo de operación de los grafos de ejecución.

La búsqueda en un grafo de conocimiento puede conectarse como un nodo, pero la ingeniería de grafos no requiere necesariamente un grafo de conocimiento. A la inversa, construir un grafo de conocimiento tampoco crea automáticamente un flujo de trabajo de agentes con rutas de reintento y aprobación.

Elementos de diseño ocultos que determinan la calidad operativa

Un sistema de producción no queda completo solo con un diagrama del grafo. Los elementos que determinan la fiabilidad real son la semántica de ejecución y los contratos operativos.

Contratos de estado y control de versiones

Es necesario definir los esquemas de entrada y salida de cada nodo, los campos obligatorios, las fuentes de datos y los permisos de actualización. También debe gestionarse la compatibilidad entre el esquema de estado y la versión del flujo de trabajo para poder reanudar ejecuciones que ya estaban interrumpidas después de modificar el grafo.

Recuperación ante fallos e idempotencia

Si se vuelve a ejecutar un nodo después de un error de red, pueden duplicarse el envío de correos electrónicos o los pagos. Las tareas con efectos secundarios externos necesitan claves de idempotencia, comprobaciones previas a la ejecución, acciones compensatorias o un repositorio de prevención de duplicados.

No todos los fallos son iguales. Es necesario distinguir rutas según el tipo de error: reintentar ante errores temporales de la API, devolver al usuario las entradas incorrectas y detenerse de inmediato ante infracciones de las políticas.

Condiciones de finalización y presupuesto de costes

Los bucles de generador-evaluador deben tener un número máximo de repeticiones, un límite de tiempo y un límite de tokens o costes. También se necesitan condiciones para finalizar o transferir el caso a una persona cuando la mejora de calidad sea mínima.

El coste total del grafo debe calcularse incluyendo no solo el coste de las llamadas individuales al modelo, sino también los reintentos, las llamadas paralelas, el almacenamiento del estado, las herramientas externas y los sistemas de observabilidad.

Observabilidad y evaluación

Los registros operativos deben indicar qué nodos y modelos se ejecutaron, qué ruta se seleccionó y cuáles fueron las entradas, las salidas y los errores. Sin embargo, deben aplicarse enmascaramiento y períodos de conservación para evitar que la información personal, las credenciales y los datos empresariales sensibles se almacenen sin protección en los registros.

La evaluación no termina con la puntuación de la respuesta final. Para identificar los cuellos de botella, también deben medirse métricas por nodo y ruta, como la precisión del enrutamiento, la tasa de éxito de las herramientas, la tasa de cumplimiento de las pruebas, la tasa de detección de riesgos antes de la aprobación y el número medio de reintentos.

Seguridad y límites de permisos

Debe tenerse en cuenta la inyección de prompts, mediante la cual las instrucciones incluidas en documentos de búsqueda o entradas de usuarios modifican las reglas del sistema. Los argumentos de herramientas generados por el modelo deben validarse antes de ejecutarse, y cada nodo debe recibir solo los permisos mínimos necesarios para realizar su trabajo. Separar los permisos de lectura, escritura, eliminación y envío externo puede reducir el riesgo de que el error de un nodo se propague y provoque un incidente en todo el sistema.

Casos adecuados para la ingeniería de grafos

Cuantas más de las siguientes condiciones coincidan, mayor será la utilidad de una estructura de grafos.

• Se necesitan distintas rutas de procesamiento especializado según la entrada.
• Las tareas independientes pueden ejecutarse en paralelo.
• Si falla una etapa concreta, es necesario regresar a un punto determinado.
• Es necesario verificar o auditar los resultados intermedios.
• Se requiere aprobación antes de modificar un sistema externo.
• La ejecución es larga y debe poder reanudarse después de una interrupción o conservar su estado.
• Es necesario separar los permisos y los ámbitos de acceso a datos de cada herramienta.

Para un resumen simple, una sola clasificación o una breve sesión de preguntas y respuestas, es mejor una única llamada al modelo o una canalización secuencial corta. Si las cargas de gestión del estado, pruebas, observabilidad y despliegue derivadas de introducir un grafo superan sus beneficios, se trata de sobreingeniería.

Lista de comprobación para la revisión del diseño

1. Definir el resultado final y los criterios de éxito de forma mensurable.
2. Limitar cada nodo a una sola responsabilidad y a entradas y salidas verificables.
3. Implementar mediante código las reglas claras y minimizar el alcance de los juicios del LLM.
4. Definir el esquema de estado y las reglas de fusión de resultados paralelos.
5. Distinguir los errores que admiten reintentos de los que requieren una interrupción inmediata.
6. Establecer límites máximos para el número de repeticiones, el tiempo de ejecución y el coste.
7. Incorporar mecanismos para evitar ejecuciones duplicadas en los nodos con efectos secundarios externos.
8. Situar la aprobación humana y una explicación suficiente antes de las acciones de alto riesgo.
9. Establecer registros y métricas de evaluación por nodo y ruta, así como reglas de protección de la información personal.
10. Volver a comprobar si es posible lograr la misma fiabilidad con una estructura más sencilla.

Resumen de los puntos clave

Si un solo agente equivale a encargar simultáneamente varias tareas a un único empleado competente, la ingeniería de grafos se parece más al diseño de las funciones de una organización, las rutas de transferencia del trabajo, los procedimientos de revisión y las líneas de aprobación.

Lo fundamental no es el número de agentes, sino una estructura controlable. Debe quedar claro en qué etapas decide la AI, dónde verifica el código y cuándo toma una persona una decisión responsable. Solo cuando se añaden contratos de estado, recuperación ante fallos, observabilidad, control de permisos y límites de costes, el grafo deja de ser un simple diagrama y se convierte en un sistema de AI operable.