💻 computer science

Declarative Data Services: Structured Agentic Discovery for Composing Data Systems

Este artículo introduce los Servicios de Datos Declarativos (DDS), una arquitectura estructurada que supera los fallos de convergencia del descubrimiento de agentes ilimitado en sistemas de datos heterogéneos mediante la descomposición del espacio de búsqueda en capas acotadas y tipificadas, guiadas por la intención declarativa del usuario y la retroalimentación iterativa en tiempo de ejecución.

Autores originales: Shanshan Ye, Duo Lu

Publicado 2026-05-21

📖 6 min de lectura🧠 Análisis profundo

CC BY 4.0

Autores originales: Shanshan Ye, Duo Lu

Artículo original bajo licencia CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ Esta es una explicación generada por IA del artículo a continuación. No ha sido escrita ni avalada por los autores. Para mayor precisión técnica, consulte el artículo original. Leer descargo de responsabilidad completo

El Gran Problema: El "Lejano Oeste" de la Programación con IA

Imagina que le pides a un arquitecto muy inteligente y bien leído (un agente de IA) que construya una casa. Dices: "Quiero una casa de 3 dormitorios con techo solar, una piscina y un presupuesto de 300.000 dólares".

En el pasado, si le pedías a una IA que escribiera código para una sola aplicación, generalmente lo hacía muy bien. Pero cuando le pides que construya un sistema de datos complejo (como una plataforma de trading que necesita manejar miles de operaciones bursátiles por segundo, almacenar años de historial y mantenerse rápida), las cosas salen mal.

¿Por qué? Porque la IA es como un genio que ha leído todos los libros de la biblioteca pero nunca ha construido realmente una casa. Sabe qué es una cola de "Kafka" o una base de datos "ClickHouse", pero no sabe cómo encajan en el mundo real. Podría elegir los materiales equivocados, olvidar conectar las tuberías o elegir un diseño que colapse bajo presión.

Si simplemente le dices a la IA: "Arréglalo", y la dejas adivinar una y otra vez (un proceso llamado "descubrimiento ilimitado"), a menudo gira en círculos. Intenta arreglar la fontanería cambiando el techo, o sigue reconstruyendo toda la casa desde cero cada vez que comete un pequeño error. Nunca converge hacia una solución que funcione.

La Solución: DDS (El "Arquitecto Estructurado")

Los autores proponen un nuevo sistema llamado Servicios Declarativos de Datos (DDS). En lugar de dejar que la IA deambule sin rumbo, DDS actúa como un gerente de construcción estricto y organizado que obliga a la IA a seguir un plano específico de cuatro pasos.

Piensa en DDS como un edificio de cuatro pisos donde cada piso tiene un trabajo específico y un conjunto específico de reglas. La IA (el "sub-agente") hace el trabajo, pero el Marco (el "gerente") sostiene los planos y verifica el trabajo en cada paso.

Los Cuatro Pisos del Edificio DDS

Piso 1: El "Qué" (Intención)

El Trabajo: Antes de construir, debes definir exactamente lo que quieres.
La Analogía: En lugar de decir "Quiero una casa genial", el usuario dice: "Necesito 3 dormitorios, 2 baños, paneles solares y un presupuesto de 300 mil dólares".
La Magia: El sistema obliga a la IA a traducir tu deseo vago en una lista de verificación estricta y tipificada (Modelo de Datos, Velocidad, Costo, etc.). Si la solicitud es imposible (por ejemplo, "Quiero una mansión por 500 dólares"), el sistema te detiene antes de que se escriba cualquier código.

Piso 2: El "Cómo" (El Plano)

El Trabajo: Diseñar el flujo de datos sin elegir marcas específicas todavía.
La Analogía: El arquitecto dibuja un diagrama: "El agua entra, va al filtro, luego al tanque y luego a la ducha". Aún no dicen "Usaremos un filtro Whirlpool". Solo deciden la forma del sistema.
La Magia: Esto separa el diseño de los productos. Si el diseño está mal, arreglas el dibujo, no la marca específica de las tuberías. Esto evita que la IA cambie toda la casa solo porque una tubería goteó.

Piso 3: El "Cuál" (Las Habilidades)

El Trabajo: Elegir los productos y configuraciones reales.
La Analogía: Ahora el arquitecto elige los artículos específicos: "Usaremos un filtro Whirlpool y tuberías de PVC". Pero aquí está el ingrediente secreto: el sistema utiliza un "Libro de Habilidades" (una memoria persistente).
La Magia: Este Libro de Habilidades es como un manual vivo. Si una casa anterior tuvo un problema porque el filtro Whirlpool necesitaba un adaptador específico, ese hecho se escribe en el Libro de Habilidades. La próxima vez que la IA construya una casa, lee el Libro de Habilidades y sabe exactamente qué adaptador usar. No tiene que "adivinar" ni "volver a aprender" ese error.

Piso 4: El "Verificar" (Atribución en Tiempo de Ejecución)

El Trabajo: Construirlo, encenderlo y ver qué se rompe.
La Analogía: Enciendes el agua. Si la ducha gotea, el sistema no dice simplemente "La casa está rota". Dice: "La fuga está en la conexión de la tubería de PVC (Piso 3)".
La Magia: Esta es la parte más importante. Cuando el sistema falla, rastrea el error hasta el piso exacto donde se tomó la decisión.
- Si el presupuesto es demasiado bajo, vuelve al Piso 1.
- Si el diseño es imposible, vuelve al Piso 2.
- Si la elección del producto específico fue mala, actualiza el Libro de Habilidades en el Piso 3.
- No hace que la IA adivine toda la casa de nuevo. Hace una corrección pequeña y dirigida.

Por Qué Esto Funciona (El Momento "¡Ajá!")

El artículo probó esto frente a agentes de IA "ilimitados" (aquellos que solo adivinan y reintentan).

El Agente Ilimitado: Como un estudiante que intenta resolver un problema de matemáticas escribiendo números al azar hasta que lo acierta. Toma mucho tiempo, cuesta mucho dinero (potencia de computación) y a menudo se rinde.
El Agente DDS: Como un estudiante que usa un libro de texto y una calculadora. Si se equivoca en un paso, el libro de texto le dice exactamente qué regla rompió. Corrige esa única regla y continúa.

Los Resultados:
En una prueba para construir un backend de trading:

Agentes Ilimitados: Fallaron al construir un sistema funcional 8 de cada 10 veces, incluso después de muchos intentos. Quedaron atrapados en bucles.
DDS: Construyó un sistema funcional 10 de cada 10 veces. Fue más rápido, más barato y el sistema realmente funcionó con datos reales.

La Analogía del "Libro de Habilidades"

El artículo enfatiza que el conocimiento necesita un hogar.

En los antiguos métodos de IA, si la IA aprendía que "Kafka necesita el puerto 9092", podría olvidarlo mañana. Tiene que volver a aprenderlo cada vez.
En DDS, ese conocimiento se guarda en un Archivo de Habilidades (como un archivo YAML).
Si la IA comete un error (por ejemplo, "Olvidé abrir el puerto 9092"), el sistema corrige el Archivo de Habilidades.
Crucialmente: La próxima vez que la IA construya un sistema, lee el Archivo de Habilidades corregido. El error nunca se vuelve a cometer. La "corrección" es permanente, no solo un parche de una sola vez.

Resumen

El artículo argumenta que para construir sistemas de datos complejos con IA, no podemos simplemente dejar que la IA "improvisé". Necesitamos un marco estructurado que:

Descomponga el problema en pasos claros y tipificados (Intención -> Diseño -> Producto -> Código).
Obligue a la IA a verificar su trabajo en cada paso antes de avanzar.
Recuerde los errores en un "Libro de Habilidades" permanente para que no se repitan.
Localice los errores con precisión para que la IA no tenga que adivinar qué arreglar.

Convierte el proceso caótico de "la IA adivinando" en una línea de montaje industrial confiable para construir software.

Resumen Técnico: Servicios de Datos Declarativos (DDS)

Enunciado del Problema

El artículo aborda el desafío del descubrimiento agéntico para backends de datos multi-sistema. Si bien los agentes impulsados por Modelos de Lenguaje Grande (LLM) han demostrado éxito en el descubrimiento de algoritmos novedosos o en la optimización de configuraciones de un solo sistema (por ejemplo, bases de datos autónomas), tienen dificultades cuando se les asigna la tarea de componer pilas de datos heterogéneas (por ejemplo, combinando colas, almacenes OLAP/OLTP, cachés y conectores) a partir de la intención del usuario en lenguaje natural.

Las dificultades principales identificadas son:

Espacio de Búsqueda Heterogéneo: El espacio de soluciones abarca múltiples sistemas distintos con dialectos, conectores y peculiaridades operativas diferentes.
Complejidad de Verificación: El "verificador" no es una clave de respuesta de referencia, sino si una pila desplegada realmente se ejecuta y cumple con los Objetivos de Nivel de Servicio (SLO).
Captura Desigual de Conocimiento: El conocimiento de composición (qué funciona junto, qué anti-patrones evitar) es escaso en los datos de preentrenamiento y cambia con cada ciclo de lanzamiento.
Fallo del Descubrimiento Ilimitado: Los agentes de codificación iterativa que dependen de la retroalimentación de registros de errores (descubrimiento ilimitado) no logran converger consistentemente. A menudo regresan niveles exitosos anteriores al reescribir la arquitectura en respuesta a errores aguas abajo o se quedan atrapados en bucles adivinando causas raíz sin rastrear señales hacia capas de decisión específicas.

Metodología: El Marco DDS

Los autores proponen Servicios de Datos Declarativos (DDS), una arquitectura de descubrimiento agéntico estructurada que descompone el problema de búsqueda global en cuatro sub-búsquedas acotadas y tipadas. El marco impone una división estricta entre Marco (que posee los contratos y la validación) y Sub-agentes (que realizan búsquedas acotadas dentro de esos contratos).

La arquitectura consta de cuatro capas (L1–L4), cada una con un contrato tipado:

L1: Contrato de Intención:
- Objetivo: Traducir lenguaje natural ambiguo en una declaración tipada y validada.
- Mecanismo: Un sub-agente elicita una intención preliminar, que el marco valida contra un esquema de seis dimensiones: modelo de datos, patrón de acceso, escala, latencia, consistencia y costo.
- Restricción: El marco rechaza entradas malformadas antes de que se genere cualquier código.
L2: DAG de Operadores Lógicos:
- Objetivo: Determinar la topología (el "qué" y el "cómo" del flujo de datos) independientemente de productos específicos.
- Mecanismo: El marco define un grafo de operadores tipado (por ejemplo, INGESTA → COLA → TRANSFORMACIÓN → ALMACENAMIENTO).
- Restricción: El marco hace cumplir la alcanzabilidad (cada ingesta debe llegar a cada servicio) y compone garantías de borde en SLOs de extremo a extremo. Si una topología no puede cumplir con el presupuesto de L1 o los SLOs, se rechaza antes de la selección de productos.
L3: Contrato de Habilidad Física:
- Objetivo: Seleccionar productos y configuraciones específicos que se ajusten al DAG.
- Mecanismo: Esta capa utiliza Habilidades de Agente, que son artefactos estructurados, persistentes y editables (YAML) por sistema. Cada habilidad contiene cuatro bloques: capacidades, composiciones, anti_patrones y operacionales.
- Restricción: El marco valida candidatos contra anti-patrones definidos por la habilidad (por ejemplo, rangos de versiones prohibidos, combinaciones de operadores incompatibles). Crucialmente, el conocimiento de composición se almacena aquí como un artefacto reutilizable en lugar de contexto de prompt transitorio.
L4: Bucle de Atribución en Tiempo de Ejecución:
- Objetivo: Desplegar la pila y enrutar los fallos de tiempo de ejecución de vuelta a la capa correcta.
- Mecanismo: Tras un fallo de despliegue, el marco clasifica la señal (por ejemplo, fallo de extracción de imagen, conflicto de puerto, retraso de consumidor) y la enruta a la capa que posee la decisión violada.
- Restricción:
  - Los errores de L4 (problemas transitorios de generación de código/host) se parchean automáticamente por el marco.
  - Los errores de L3 (habilidades faltantes/anti-patrones) resultan en parches de habilidad que se editan en el artefacto de habilidad, persistiendo para despliegues futuros.
  - Los errores de L1/L2 (desajustes de intención o topología) se presentan al usuario para revisión, ya que el marco no puede revisar automáticamente estos límites contractuales.

Contribuciones Clave

Arquitectura Estructurada para Descubrimiento Multi-Sistema: Una división marco/agente con cuatro contratos tipados (L1–L4) que descompone la búsqueda global en sub-búsquedas acotadas, gobernada por reglas de propiedad donde el marco valida contratos y los agentes buscan dentro de ellos.
Descubrimiento Estructurado vs. Ilimitado: Dos innovaciones arquitectónicas:
- Atribución Tipada: Enrutar cada señal de tiempo de ejecución a la capa específica que posee la decisión violada, evitando la regresión de la búsqueda global.
- Memoria de Habilidad Persistente: Almacenar el conocimiento de composición en artefactos de habilidad editables y citables (L3) en lugar de prompts, permitiendo que las correcciones se acumulen y persistan a través de despliegues.
Validación Empírica (Backend de Trading): Un estudio de caso que demuestra que DDS converge a una pila funcional donde el descubrimiento ilimitado falla, con fallos de tiempo de ejecución que se convierten en parches de habilidad que mejoran las iteraciones posteriores.

Resultados

El artículo evalúa DDS frente a líneas base de descubrimiento agéntico ilimitado (Condiciones A, B, C) utilizando una carga de trabajo de backend de trading (50k ticks/seg, búsquedas sub-10ms, presupuesto de 300 $/mes) y el mismo LLM subyacente (Claude Opus 4.6).

Convergencia:
- Líneas Base Ilimitadas: Incluso con 5 iteraciones y nombres de sistemas explícitos o contenido de habilidad pegado como prosa, los agentes ilimitados no lograron alcanzar un estado funcional (T1/T2) consistentemente. La Condición A (NL solo) alcanzó T1 en 2/10 ejecuciones; la Condición C (NL + prosa de habilidad) alcanzó T1 en 6/10 ejecuciones.
- DDS: Con el mismo bucle de 5 iteraciones, DDS alcanzó T1 y T2 en 10/10 ejecuciones.
Eficiencia:
- DDS requirió una mediana de 44 turnos y 1,94 $ para converger.
- Las líneas base ilimitadas requirieron significativamente más turnos (mediana 209–268) y costo (5,06 $–6,23$ ), a menudo agotando las iteraciones sin convergencia.
Estudio de Ablación: Eliminar los bloques operacionales y anti_patrones de los artefactos de habilidad hizo que la tasa de éxito cayera a 0/3, demostrando que el conocimiento operativo específico (por ejemplo, imágenes recomendadas, conflictos de puerto) es crítico y no redundante con el preentrenamiento.
Precisión de Atribución: En un experimento controlado de inyección de fallos (20 instancias), el bucle de atribución L4 enrutó correctamente las señales a la capa propietaria el 100% de las veces.
Bucle de Aprendizaje: En un escenario real de fallo, cuatro fallos distintos de tiempo de ejecución se atribuyeron a brechas de habilidad L3. El marco aplicó parches solo de habilidad (sin cambios de código), y el segundo despliegue corrigió 4/4 fallos con citas en línea de los campos parcheados.

Significado y Afirmaciones

El artículo posiciona a DDS como un prototipo temprano que reporta lecciones de la composición de sistemas de datos del mundo real. Su significado radica en demostrar que la estructura, no solo la iteración o el volumen de conocimiento, es la clave para el descubrimiento agéntico fiable en sistemas complejos.

El "Éxito" es la Estructura: Los autores afirman que el "canal tipado" (la superficie contractual) es lo que convierte la iteración en una edición acotada a una capa. Los agentes ilimitados fallan porque carecen de un mecanismo para rastrear síntomas hasta decisiones de causa raíz; DDS resuelve esto forzando a que los fallos aterricen en capas específicas.
Conocimiento Persistente: El artículo argumenta que el conocimiento de composición debe ser un "artefacto de primera clase y persistente" (la habilidad) en lugar de contexto transitorio. Esto permite que el sistema aprenda de los fallos y aplique esas lecciones a despliegues futuros sin volver a descubrirlos.
Alcance Modesto: Los autores declaran explícitamente que el prototipo se ejecuta en Docker Compose local y es una "prueba de vida", no un sistema de nivel de producción. Reconocen problemas abiertos como la confianza de atribución para señales ambiguas (por ejemplo, retraso de consumidor), deriva de intención y la necesidad de una capa evaluadora L5 para verificar SLOs bajo carga sostenida. El trabajo no afirma resolver todos los problemas de ingeniería de datos, sino que ofrece un patrón arquitectónico específico para conectar la intención del usuario con el despliegue multi-sistema.