Resumo Técnico: Serviços de Dados Declarativos (DDS)

Declaração do Problema

O artigo aborda o desafio da descoberta agênica para backends de dados multi-sistema. Embora agentes impulsionados por Modelos de Linguagem de Grande Escala (LLM) tenham demonstrado sucesso na descoberta de algoritmos inovadores ou na otimização de configurações de sistemas únicos (por exemplo, bancos de dados autônomos), eles enfrentam dificuldades quando encarregados de compor pilhas de dados heterogêneas (por exemplo, combinando filas, armazenamentos OLAP/OLTP, caches e conectores) a partir da intenção do usuário em linguagem natural.

As principais dificuldades identificadas são:

1. Espaço de Busca Heterogêneo: O espaço de soluções abrange múltiplos sistemas distintos com dialetos, conectores e peculiaridades operacionais diferentes.
2. Complexidade de Verificação: O "verificador" não é uma chave de resposta de benchmark, mas sim se uma pilha implantada realmente executa e atende aos Objetivos de Nível de Serviço (SLOs).
3. Captura Desigual de Conhecimento: O conhecimento de composição (o que funciona junto, quais anti-padrões evitar) é escasso nos dados de pré-treinamento e muda a cada ciclo de lançamento.
4. Falha da Descoberta Ilimitada: Agentes de codificação iterativa que dependem de feedback de logs de falha (descoberta ilimitada) falham em convergir consistentemente. Eles frequentemente regredem camadas anteriores bem-sucedidas ao reescrever a arquitetura em resposta a erros a jusante ou ficam presos em loops tentando adivinhar as causas raízes sem rastrear sinais para camadas de decisão específicas.

Metodologia: O Framework DDS

Os autores propõem os Serviços de Dados Declarativos (DDS), uma arquitetura de descoberta agênica estruturada que decompõe o problema de busca global em quatro sub-buscas delimitadas e tipadas. O framework impõe uma divisão estrita entre Framework (que detém os contratos e a validação) e Sub-Agentes (que realizam a busca delimitada dentro desses contratos).

A arquitetura consiste em quatro camadas (L1–L4), cada uma carregando um contrato tipado:

• L1: Contrato de Intenção:

  • Objetivo: Traduzir linguagem natural ambígua em uma declaração validada e tipada.
  • Mecanismo: Um sub-agente elicita uma intenção de rascunho, que o framework valida contra um esquema de seis dimensões: modelo de dados, padrão de acesso, escala, latência, consistência e custo.
  • Restrição: O framework rejeita entradas malformadas antes que qualquer geração de código ocorra.

• L2: DAG de Operadores Lógicos:

  • Objetivo: Determinar a topologia (o "o quê" e o "como" do fluxo de dados) independentemente de produtos específicos.
  • Mecanismo: O framework define um grafo de operadores tipado (por exemplo, INGESTÃO → FILA → TRANSFORMAÇÃO → ARMAZENAMENTO).
  • Restrição: O framework impõe alcançabilidade (toda ingestão deve alcançar todo atendimento) e compõe garantias de aresta em SLOs de ponta a ponta. Se uma topologia não puder atender ao orçamento ou SLOs da L1, ela é rejeitada antes da seleção de produtos.

• L3: Contrato de Habilidade Física:

  • Objetivo: Selecionar produtos e configurações específicos que se encaixem no DAG.
  • Mecanismo: Esta camada utiliza Habilidades de Agente, que são artefatos estruturados, persistentes e editáveis (YAML) por sistema. Cada habilidade contém quatro blocos: capacidades, composições, anti-padrões e operacionais.
  • Restrição: O framework valida candidatos contra anti-padrões definidos pela habilidade (por exemplo, faixas de versão proibidas, combinações de operadores incompatíveis). Crucialmente, o conhecimento de composição é armazenado aqui como um artefato reutilizável, em vez de contexto de prompt transitório.

• L4: Loop de Atribuição em Tempo de Execução:

  • Objetivo: Implantar a pilha e rotear falhas de tempo de execução de volta para a camada correta.
  • Mecanismo: Após falha de implantação, o framework classifica o sinal (por exemplo, falha de pull de imagem, conflito de porta, atraso do consumidor) e o roteia para a camada que detém a decisão violada.
  • Restrição:
    • Erros L4 (problemas transitórios de geração de código/host) são corrigidos automaticamente pelo framework.
    • Erros L3 (habilidades ausentes/anti-padrões) resultam em correções de habilidade que são editadas no artefato de habilidade, persistindo para implantações futuras.
    • Erros L1/L2 (mismatches de intenção ou topologia) são apresentados ao usuário para revisão, pois o framework não pode reavaliar automaticamente esses limites de contrato.

Contribuições Principais

1. Arquitetura Estruturada para Descoberta Multi-Sistema: Uma divisão framework/agente com quatro contratos tipados (L1–L4) que decompõe a busca global em sub-buscas delimitadas, governada por regras de propriedade onde o framework valida contratos e os agentes buscam dentro deles.
2. Descoberta Estruturada vs. Ilimitada: Duas inovações arquitetônicas:
   • Atribuição Tipada: Roteamento de cada sinal de tempo de execução para a camada específica que detém a decisão violada, prevenindo regressão na busca global.
   • Memória de Habilidade Persistente: Armazenamento de conhecimento de composição em artefatos de habilidade editáveis e citáveis (L3) em vez de prompts, permitindo que correções se acumulem e persistam entre implantações.
3. Validação Empírica (Backend de Trading): Um estudo de caso demonstrando que o DDS converge para uma pilha funcional onde a descoberta ilimitada falha, com falhas de tempo de execução tornando-se correções de habilidade que melhoram iterações subsequentes.

Resultados

O artigo avalia o DDS contra bases de descoberta agênica ilimitada (Condições A, B, C) usando uma carga de trabalho de backend de trading (50K ticks/seg, buscas sub-10ms, orçamento de $300/mês) e o mesmo LLM subjacente (Claude Opus 4.6).

• Convergência:
  • Bases Ilimitadas: Mesmo com 5 iterações e nomes de sistemas explícitos ou conteúdo de habilidade colado como prosa, agentes ilimitados falharam em alcançar consistentemente um estado funcional (T1/T2). A Condição A (NL apenas) alcançou T1 em 2/10 execuções; a Condição C (NL + prosa de habilidade) alcançou T1 em 6/10 execuções.
  • DDS: Com o mesmo loop de 5 iterações, o DDS alcançou T1 e T2 em 10/10 execuções.
• Eficiência:
  • O DDS exigiu uma mediana de 44 turnos e $1,94 para convergir.
  • As bases ilimitadas exigiram significativamente mais turnos (mediana 209–268) e custo ($5,06–$6,23), frequentemente esgotando iterações sem convergência.
• Estudo de Ablação: Remover os blocos operational e anti_patterns dos artefatos de habilidade fez a taxa de sucesso cair para 0/3, demonstrando que o conhecimento operacional específico (por exemplo, imagens recomendadas, conflitos de porta) é crítico e não redundante com o pré-treinamento.
• Precisão de Atribuição: Em um experimento controlado de injeção de falhas (20 instâncias), o loop de atribuição L4 roteou corretamente os sinais para a camada proprietária 100% das vezes.
• Loop de Aprendizado: Em um cenário real de falha, quatro falhas distintas de tempo de execução foram atribuídas a lacunas de habilidade L3. O framework aplicou correções apenas de habilidade (sem alterações de código), e a segunda implantação corrigiu 4/4 falhas com citações inline dos campos corrigidos.

Significado e Afirmações

O artigo posiciona o DDS como um protótipo inicial relatando lições da composição de sistemas de dados do mundo real. Seu significado reside em demonstrar que estrutura, não apenas iteração ou volume de conhecimento, é a chave para a descoberta agênica confiável para sistemas complexos.

• A "Vitória" é a Estrutura: Os autores afirmam que o "canal tipado" (a superfície do contrato) é o que transforma a iteração em uma edição delimitada por camada. Agentes ilimitados falham porque carecem de um mecanismo para rastrear sintomas até decisões de causa raiz; o DDS resolve isso forçando falhas a aterrissarem em camadas específicas.
• Conhecimento Persistente: O artigo argumenta que o conhecimento de composição deve ser um "artefato persistente de primeira classe" (a habilidade) em vez de contexto transitório. Isso permite que o sistema aprenda com falhas e aplique essas lições a implantações futuras sem precisar redescobri-las.
• Escopo Modesto: Os autores afirmam explicitamente que o protótipo roda em Docker Compose local e é uma "prova de vida", não um sistema pronto para produção. Eles reconhecem problemas abertos, como confiança de atribuição para sinais ambíguos (por exemplo, atraso do consumidor), desvio de intenção e a necessidade de uma camada avaliadora L5 para verificar SLOs sob carga sustentada. O trabalho não afirma resolver todos os problemas de engenharia de dados, mas oferece um padrão arquitetônico específico para conectar a intenção do usuário à implantação multi-sistema.