Ingeniería de grafos: principios de diseño para estructurar flujos de trabajo de agentes de IA ============================================================================================== La ingeniería de grafos es un enfoque que divide las tareas complejas de IA en nodos y reglas de transición, y diseña explícitamente el estado, la validación, la recuperación ante fallos y la aprobación del usuario. La clave no es confiar todas las etapas a la IA, sino diferenciar las funciones del código, los modelos y las personas. - La ingeniería de grafos no diseña una única respuesta del modelo, sino el recorrido, el estado, las bifurcaciones, las repeticiones y las condiciones de finalización de toda la tarea. - Los nodos ejecutan tareas, las aristas definen las rutas de transición, el estado transmite datos entre etapas y las condiciones seleccionan la siguiente ruta. - El enrutamiento, la ejecución paralela, la iteración entre generador y evaluador, y la aprobación del usuario son patrones representativos de los grafos de agentes. - Conviene asignar al código las tareas deterministas, como la validación de formatos y la comparación numérica; a la IA, las interpretaciones ambiguas; y a las personas, las decisiones de alto riesgo. - Un grafo operativo requiere un esquema de estado, límites de reintentos, prevención de ejecuciones duplicadas, observabilidad, límites de permisos y un presupuesto de costes. 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í. Capa Pregunta clave Principales objetos de diseño Ingeniería de prompts ¿Cómo dar instrucciones al modelo? Instrucciones, ejemplos, formato de salida Ingeniería de contexto ¿Con qué información se debe conformar lo necesario para tomar decisiones? Resultados de búsqueda, memoria, resultados de herramientas, reglas del sistema Ingeniería de bucles ¿Cómo repetir la planificación, la ejecución, la verificación y la corrección? Condiciones de repetición, criterios de evaluación, condiciones de finalización Ingeniería de grafos ¿Mediante qué rutas conectar diversas tareas y entidades decisoras? Nodos, transiciones, estado, bifurcaciones, paralelización, aprobación 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 Naturaleza de la tarea Medio prioritario Ejemplos Reglas claras que deben producir siempre el mismo resultado Código convencional Recuento de elementos, comparación de fechas, validación de esquemas JSON Juicios que tratan el significado y la ambigüedad del lenguaje natural Modelo de AI Clasificación de intenciones, resumen, redacción de borradores, evaluación cualitativa Decisiones que requieren responsabilidad, ética o juicio de alto riesgo Personas Aprobación de comunicaciones externas, autorización de excepciones, aprobación de medidas de alto riesgo 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 Definir el resultado final y los criterios de éxito de forma mensurable. Limitar cada nodo a una sola responsabilidad y a entradas y salidas verificables. Implementar mediante código las reglas claras y minimizar el alcance de los juicios del LLM. Definir el esquema de estado y las reglas de fusión de resultados paralelos. Distinguir los errores que admiten reintentos de los que requieren una interrupción inmediata. Establecer límites máximos para el número de repeticiones, el tiempo de ejecución y el coste. Incorporar mecanismos para evitar ejecuciones duplicadas en los nodos con efectos secundarios externos. Situar la aprobación humana y una explicación suficiente antes de las acciones de alto riesgo. Establecer registros y métricas de evaluación por nodo y ruta, así como reglas de protección de la información personal. 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. FAQ Q. ¿Qué es la ingeniería de grafos? A. Es un enfoque que divide las tareas complejas de IA en nodos y diseña explícitamente las rutas de transición entre tareas, el estado compartido, las condiciones de bifurcación, las iteraciones y los procedimientos de aprobación. Más que un único término estándar consensuado por todo el sector, es una expresión práctica para describir la orquestación de agentes basada en grafos. Q. ¿En qué se diferencian la ingeniería de grafos y la ingeniería de prompts? A. La ingeniería de prompts aborda qué instrucciones y ejemplos proporcionar en cada llamada al modelo. La ingeniería de grafos aborda en qué orden y bajo qué condiciones conectar varias llamadas a modelos, código, herramientas y el criterio humano. Los prompts se siguen utilizando dentro de cada nodo que compone el grafo. Q. ¿Son la ingeniería de grafos y los grafos de conocimiento el mismo concepto? A. No. Un grafo de conocimiento consiste en datos que estructuran entidades y relaciones, mientras que un grafo de ejecución de agentes representa el orden de las tareas y el flujo de control. La búsqueda en un grafo de conocimiento puede utilizarse como un nodo del grafo de ejecución, pero ninguno es un requisito indispensable para el otro. Q. ¿Es necesario convertir todos los nodos en agentes de IA? A. No es necesario. Para tareas con resultados claros, como contar elementos, comparar fechas o comprobar formatos, el código convencional es más rápido, económico y predecible. Es apropiado dejar a la IA la interpretación del lenguaje natural y las evaluaciones cualitativas, y a las personas las decisiones de gran responsabilidad o difíciles de revertir. Q. ¿Cómo evita un bucle generador-evaluador las repeticiones infinitas? A. Deben definirse de antemano el número máximo de iteraciones, los límites de tiempo y costes, y los criterios de aprobación. También se necesitan condiciones de finalización para devolver el mejor resultado anterior o enviarlo a una ruta de revisión humana si la calidad no mejora tras las iteraciones o si el nivel de confianza de la evaluación es bajo. Q. ¿Un sistema multiagente es siempre mejor que un único agente? A. No. Al aumentar los roles, también aumentan el coste de las llamadas, los errores en la transferencia de estado, la latencia y la carga de depuración. Conviene elegir una estructura multiagente solo cuando la separación entre roles especializados contribuya realmente a la calidad o al control de permisos; para los procedimientos fijos, puede ser mejor utilizar un flujo de trabajo de código convencional. Q. ¿Qué debe almacenarse en el estado del grafo? A. El principio es almacenar únicamente los datos necesarios para el siguiente paso, como la solicitud del usuario, los resultados intermedios validados, las fuentes, los tipos de error, el número de iteraciones y el estado de aprobación. Deben definirse el formato y los permisos de modificación de cada campo, y las credenciales o los datos personales innecesarios no deben almacenarse o deben enmascararse. Q. ¿Qué debe tenerse en cuenta al reintentar un nodo fallido? A. Primero hay que distinguir si el error es temporal, si la propia entrada es incorrecta o si el proceso debe detenerse por motivos de política. Para tareas con efectos externos, como enviar correos electrónicos, realizar pagos o modificar datos, deben utilizarse claves de idempotencia y comprobaciones de ejecución duplicada. Q. ¿Qué tareas no necesitan ingeniería de grafos? A. Por lo general, no es necesaria para tareas en las que basta una sola llamada, como un resumen sencillo, una pregunta y respuesta breve o una única clasificación. Si la gestión del estado y los costes operativos derivados de añadir un grafo son mayores que las mejoras en la calidad, el control o la capacidad de recuperación, es preferible mantener una estructura sencilla. Sources - Creación de agentes eficaces: https://www.anthropic.com/research/building-effective-agents - LangGraph: https://github.com/langchain-ai/langgraph - Documentación de Temporal: https://docs.temporal.io/ - Marco de gestión de riesgos de IA del NIST: https://www.nist.gov/itl/ai-risk-management-framework - Graphiti: https://github.com/getzep/graphiti - Las 10 principales vulnerabilidades de OWASP para aplicaciones de modelos de lenguaje de gran tamaño: https://genai.owasp.org/llm-top-10/ Images - Mujer operando un grafo de flujo de trabajo en una pantalla táctil de una sala de servidores: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTA0NzMsInB1ciI6ImJsb2JfaWQifX0=--ef1105ce6a385a669f3ac38d2daca7268be12737/ai-8a9b7d63.webp - Diagrama de flujo con agentes de IA, paneles de datos, validación, seguridad y revisión humana: https://injoys.com/rails/active_storage/blobs/proxy/eyJfcmFpbHMiOnsiZGF0YSI6MTA0NzksInB1ciI6ImJsb2JfaWQifX0=--dcdc470a0909904f41c12684bf7ee53b4ab8a805/ai-03b3a3b1.webp --- Category: Datos de IA Source: https://injoys.com/es/articles/graph-engineering-ai-agent-workflow-guide License: cc_by Translation-Status: reviewed