De Prompt Spaghetti a Contextos Delimitados: DDD para Bases de Código Agénticas

Hola queridos colegas, encantado de conoceros. Mi nombre es Nikita y soy un arquitecto de portafolio de IA en Siemens, Alemania, y hoy me gustaría hablar sobre la construcción de un sistema JNTX a través del prisma del diseño impulsado por el dominio. Permítanme comenzar con la llamada paradoja del sistema JNTX. Creo que muchos de ustedes probablemente la han visto. Por ejemplo, decides construir un sistema de codificación JNTX. Actualmente, estás en el primer mes, tienes tres agentes, indicaciones bastante limpias, todo funciona bien, estás lanzando nuevas características, nueva funcionalidad como loco, todo se ve increíble. Pero seis meses después, tienes un lío de agentes, más de 3,000 indicaciones de tokens. Cuando cambias algo, todo se rompe, tienes un ciclo de despliegue largo y apenas puedes depurarlo. Y todo esto no se trata principalmente de tus LLMs, no se trata de tus agentes, es un problema de toda la arquitectura.

Bien, veamos cómo sucede. Después de seis meses, tu indicación aumentó dramáticamente y alrededor del 85% de tu indicación se trata de lógica de análisis, se trata de integración. Pero en lugar de escribir esta integración como un código en Python, donde puedes probarlo, versionarlo, hacer comprobaciones de tipo, o simplemente lo escribiste en inglés simple y solo esperas que el LLM de alguna manera pueda ejecutarlo y todo estará bien. Esto es el espagueti de indicaciones y así es como terminan la mayoría de los sistemas JNTX. Y la pregunta principal hoy para nuestra charla, para mi charla, es cómo construir sistemas JNTX que puedan mantenerse mantenibles a medida que escalan. Y un pequeño spoiler, la respuesta será de 2003. Esta respuesta fue dada por Eric Evans. Mostró cómo funciona para microservicios, pero intentemos aplicarlo a nuestros agentes.

Bien, vamos, miremos más a fondo. El problema principal con la construcción de un sistema JNTX es que pensamos que estamos construyendo algún tipo de sistemas pequeños útiles que están claramente integrados o se comunican entre sí. Pero el problema es que en realidad estamos construyendo un sistema distribuido con servicios que se comunican entre sí a través del lenguaje natural sin seguridad de tipo, sin contratos explícitos, sin límites claros, lo que significa que al final del día, estamos construyendo algún tipo de arquitectura de microservicios, pero descuidando todos los principios básicos. Y luego nos preguntamos por qué todo se está rompiendo y por qué nada está funcionando. Bien, veamos esta comparación. Ya tenemos alrededor de 20 años de experiencia en sistemas distribuidos, y sabemos cómo dividir límites, cómo diseñar APIs, contratos, y esto funciona perfectamente para microservicios. Pero para los sistemas JNTX, tenemos una imagen totalmente opuesta. Tenemos una responsabilidad difusa, haciendo todo. Tenemos un lenguaje natural como interfaz, como interacción, en lugar de APIs claras, tenemos una adivinanza semántica, y como resultado, tenemos muchas fallas en cascada y mucha magia sucediendo bajo el capó. La buena noticia es que los patrones que resuelven todos estos problemas ya existen. El nombre de este patrón es diseño impulsado por el dominio, y también una buena noticia es que los principios y enfoques del diseño impulsado por el dominio funcionan aún mejor para los agentes que para los microservicios. Pero echemos un vistazo más de cerca a los cuatro patrones principales, cuatro principios principales del diseño impulsado por el dominio, y cómo podemos aplicarlos a los agentes. El primero, como es obvio, es un contexto delimitado.

Se trata de responsabilidad clara. Aquí puedes ver un llamado anti-patrón de un agente guardián cuando en caso de diseñar un sistema de escritura de código contra un sistema de escritura de código por contrato. Este agente es responsable de la revisión de código, de la calidad, de las verificaciones de seguridad, de la cobertura de pruebas. Como resultado, tenemos más de 3000 tokens tratando de resolver todos los problemas existentes. ¿Qué podemos proponer como alternativa, cuál es la mejor práctica? Intenta aplicar contexto delimitado, intenta dividir este desorden en un contexto separado, por ejemplo, contexto de calidad, contexto de seguridad, y así sucesivamente. Cada contexto es responsable de una tarea separada. Cada contexto proporciona un artefacto separado. Por ejemplo, el contexto de calidad responde a la pregunta de si este código está bien elaborado seguridad, si este código es lo suficientemente seguro, y como artefacto, cada contexto proporciona un artefacto separado, por ejemplo, calidad, algún tipo de informes de calidad, informes de seguridad, y verificaciones de CV, y niveles de riesgo, y como resultado, tenemos una disminución significativa de la complejidad de nuestro indicación inicial de miles de tokens a un centenar medible de tokens. Y como primera regla, como primer resultado, tenemos que intentar aplicar contexto delimitado, un agente es un contexto delimitado, una responsabilidad.

El segundo patrón es un contrato como esquema. El problema es que sin contratos, la salida del agente no está estructurada, y cada agente que recibe esta salida puede analizarla e interpretarla de manera diferente. ¿Qué podemos proponer como alternativa? Aplicar contratos, aplicar esquemas estructurados, y, por ejemplo, tratarlo como un modelo pedante. Así que, por ejemplo, un modelo pedante puede representar tu contrato, que representa esta integración entre contextos, que nos ayuda a definir explícitamente la expectativa de la salida de un agente y darle forma de manera estructurada. También, puede darnos la oportunidad de beneficios de auto-documentación, porque el esquema es un documento, puede ser validado automáticamente por, por ejemplo, pedantic, puede ser versionado explícitamente, y ni siquiera necesitamos ninguna lógica de análisis debido a esta estructura desde el primer día. Por eso tenemos una segunda regla. Necesitamos dejar de usar el lenguaje natural como nuestra API. Deberíamos usar esquemas estructurados como nuestros contratos.

Pero veamos cómo hacer estos contratos listos para producción. Para hacer esto, tenemos dos patrones, los llamados puertos y adaptadores de arquitectura hexagonal y puertas CI. Los puertos definirán lo que nuestro agente necesita. Está en un contrato. El adaptador solo traduce el sistema externo a nuestro dominio. Y significa que el agente no conoce el formato externo, porque el adaptador solo absorbe esta complejidad. Cuando algo cambia en el sistema externo, solo necesitamos actualizar nuestro adaptador y el dominio sigue protegido y seguro. Y dado que nuestros contratos están estandarizados y estructurados, podemos automatizar las verificaciones pre y post-despliegue, pruebas y validaciones alrededor de estos contratos con la ayuda de las respectivas puertas CI. Así que los contratos definen la corrección y las puertas CI solo la refuerzan. Bien, el tercer patrón, es una llamada capa anti-corrupción. Podemos considerarlo, podemos tratarlo como un cortafuegos semántico. El problema principal es que en diferentes contextos, en diferentes límites, el mismo término puede tener un significado diferente, una definición diferente. Por ejemplo, para el contrato de generación de código, función es una firma más implementación.

Para el contexto de prueba, es solo un contrato de comportamiento. Así que vemos la misma palabra con diferentes significados y sin traducción, tendremos algún tipo de desorden y caos. La solución es una capa anti-corrupción que puede traducir entre límites. Puede extraer solo la información necesaria del contacto respectivo que necesita el otro contacto receptor. Por ejemplo, para las pruebas, es una firma de función y comportamiento esperado. Y como resultado, tenemos nuestros dominios claros y, por ejemplo, si algo sucede, si algo cambia en un dominio proveedor, recibiremos solo un error respectivo durante la verificación de la puerta CI respectiva. Solo necesitamos cambiar nuestro adaptador y ambos dominios permanecerán protegidos y estables. Así que como resultado, tenemos la tercera regla. La capa anti-corrupción es nuestro cortafuegos semántico. Solo necesitamos traducir explícitamente, fallar ruidosamente y proteger nuestros dominios.

El cuarto patrón es un mapa de contexto. Así que el mapa de contexto hace que nuestra arquitectura de integración sea explícita. Por ejemplo, aquí puedes ver un mapa de contexto para un sistema de codificación gigantesco. Así que podemos ver el contexto de generación de código en la parte superior, prueba y revisión de contexto y documentación en el medio y despliegue en la parte inferior con las relaciones respectivas entre contextos. Pero la clave es que no es solo un diagrama, no es solo una imagen, es código ejecutable. Así que necesitamos considerar nuestro mapa de contexto como una configuración con el sistema upstream, downstream definiendo qué tipo de relación, qué tipo de patrón debe usarse entre contextos, qué adaptador, qué versión del contrato. Esto puede ser validado durante el proceso de inicialización. Puede ser usado para generar documentación. Al final del día, reforzará nuestros patrones de integración. Y como resultado, aquí tenemos la siguiente regla de que el mapa de contexto es nuestra arquitectura de integración, no solo una documentación. Debe ser un código que pueda ejecutarse, validar y reforzar nuestra integración.

Bien, veamos cómo funcionan juntos estos cuatro patrones. Así que como resultado, tenemos tres contextos delimitados separados con responsabilidades claras y enfocadas. Los adaptadores traducen entre contextos. SCL, capa anti-corrupción, protege la claridad del dominio. Las puertas CI se utilizan para validar contratos y verificar la consistencia semántica. Cada llamada es rastreada. El mapa de contexto coordina todas estas relaciones y cada límite, cada contexto tiene su propio ACL, puerta CI y rastreo. Y solo para mirar la imagen antes y después. Así que antes teníamos cientos de miles de tokens por agente y el 85 por ciento de este prompt estaba principalmente dedicado a la integración, espagueti para la lógica de integración y los ingenieros pasaban horas solo para depurar.

Y después, tenemos una especie de cientos medibles, 500 tokens por agente donde alrededor del 90 por ciento de este prompt está dedicado a una lógica de dominio y un error de tipo o error de integración puede ser fácilmente detectado a través de la respectiva puerta CI o verificaciones CI.

Hagamos un resumen de los principales puntos clave. En primer lugar, cuando estás construyendo un sistema agéntico, debes tener en cuenta que estás construyendo un sistema distribuido. Así que deja de tratar este sistema como un script. Arquitecta como servicios. A continuación, contexto delimitado equivale a responsabilidad clara. Un agente, un dominio. Simplemente deja de construir agentes u objetos de guardia.

El tercer resultado es que un esquema es tu contrato. Deja de usar lenguaje natural como tu API. La cuarta capa anti-corrupción es tu cortafuegos semántico. Necesitas traducir entre límites. Necesitas proteger con la ayuda de ACL tus dominios. El quinto mapa de contexto es la arquitectura de integración. Necesitas tratarlo como una configuración ejecutable que especifique, describa y explique toda la arquitectura de tus agentes. Y el sexto, por favor usa puertas CI. Por favor bloquea y rastrea todo, lo que te dará la capacidad de depurar y ver qué está sucediendo dentro de tu sistema.

Bien, los próximos pasos. ¿Qué puedes hacer? Así que, por supuesto, es un gran paso. Pero si haces solo una cosa, simplemente puedes definir el contrato entre dos agentes. Puedes hacerlo como un esquema pedante e intentar validar, intentar incrustar esto. La validación de este esquema pedante es parte de tu pipeline CI. Eso es todo. Este es el comienzo. Todo lo demás nos sigue desde el primer límite. Así que no esperes un diseño perfecto. No esperes la aprobación de la gestión. Y solo para animarte, para inspirarte, te dejaré con esta frase de que el mejor momento para empezar fue hace seis meses. El segundo mejor momento es el lunes. Puedes incluso ponerte como autor de esta frase. Y sí, muchas gracias. Mantente atento y espero tus preguntas. Gracias.