O Dilema do Desenvolvedor Java: Parte 3 – O’Reilly

No primeiro artigo analisamos o dilema do desenvolvedor Java: a lacuna entre os protótipos chamativos e a realidade dos sistemas de produção empresarial. No segundo artigo, exploramos por que novos tipos de aplicativos são necessários e como a IA muda a forma do software program empresarial. Este artigo enfoca o que essas mudanças significam para a arquitetura. Se os aplicativos parecerem diferentes, a forma como os estruturamos também deverá mudar.

A pilha empresarial Java tradicional

Os aplicativos Java corporativos sempre foram uma questão de estrutura. Um sistema típico é construído sobre um conjunto de camadas. Na parte inferior está a persistência, geralmente com JPA ou JDBC. A lógica de negócios vai acima disso, impondo regras e processos. No topo estão os endpoints REST ou de mensagens que expõem os serviços ao mundo exterior. Preocupações transversais como transações, segurança e observabilidade percorrem a pilha. Este modelo provou ser durável. Ele carregou o Java desde os primeiros dias do servlet até estruturas modernas como Quarcus, Bota Primaverae Micronauta.

O sucesso desta arquitetura vem da clareza. Cada camada tem uma responsabilidade clara. O aplicativo é previsível e de fácil manutenção porque você sabe onde adicionar lógica, onde aplicar políticas e onde conectar o monitoramento. Adicionar IA não take away essas camadas. Mas acrescenta novas, porque o comportamento da IA ​​não se enquadra nas suposições claras do software program determinístico.

Novas camadas em aplicativos com infusão de IA

A IA muda a arquitetura introduzindo camadas que nunca existiram em sistemas determinísticos. Três dos mais importantes são validação difusa, proteções sensíveis ao contexto e observabilidade do comportamento do modelo. Na prática, você encontrará ainda mais componentes, mas a validação e a observabilidade são a base que torna a IA segura na produção.

Validação e guarda-corpos

Os aplicativos Java tradicionais assumem que as entradas podem ser validadas. Você verifica se um número está dentro do intervalo, se uma string não está vazia ou se uma solicitação corresponde a um esquema. Depois de validado, você o processa de forma determinística. Com os resultados da IA, esta suposição não é mais válida. Um modelo pode gerar texto que parece correto, mas é enganoso, incompleto ou prejudicial. O sistema não pode confiar cegamente nele.

É aqui que entram a validação e as proteções. Eles formam uma nova camada arquitetônica entre o modelo e o restante do aplicativo. Os guarda-corpos podem assumir diferentes formas:

• Validação de esquema: Se você espera um objeto JSON com três campos, deverá verificar se a saída do modelo corresponde a esse esquema. Um campo ausente ou malformado deve ser tratado como um erro.
• Verificações de política: Se o seu domínio proíbe determinadas saídas, como a exposição de dados confidenciais, o retorno de identificadores pessoais ou a geração de conteúdo ofensivo, as políticas deverão filtrá-las.
• Aplicação de intervalo e tipo: Se o modelo produzir uma pontuação numérica, você precisará confirmar se a pontuação é válida antes de passá-la para sua lógica de negócios.

As empresas já sabem o que acontece quando falta validação. Injeção de SQL, scripts entre websites e outras vulnerabilidades nos ensinaram que entradas não verificadas são perigosas. As saídas de IA são outro tipo de entrada não confiável, mesmo que venham de dentro do seu próprio sistema. Tratá-los com suspeita é um requisito.

Em Java, esta camada pode ser construída com ferramentas familiares. Você pode escrever anotações de validação de bean, verificações de esquema ou até mesmo interceptadores CDI personalizados que são executados após cada chamada de IA. A parte importante é arquitetônica: a validação não deve ficar oculta em métodos utilitários. Deve ser uma camada visível e explícita na pilha para que possa ser mantida, evoluída e testada rigorosamente ao longo do tempo.

Observabilidade

A observabilidade sempre foi crítica em sistemas corporativos. Logs, métricas e rastreamentos nos permitem entender como os aplicativos se comportam na produção. Com a IA, a observabilidade torna-se ainda mais importante porque o comportamento não é determinístico. Um modelo pode dar respostas diferentes amanhã das que dá hoje. Sem visibilidade, você não pode explicar ou depurar o porquê.

Observabilidade para IA significa mais do que registrar um resultado. Requer:

• Rastreando prompts e respostas: Capturar o que foi enviado ao modelo e o que voltou, de preferência com identificadores que os vinculem à solicitação authentic
• Contexto de gravação: Armazenar os dados recuperados de bancos de dados vetoriais ou outras fontes para saber o que influenciou a resposta do modelo
• Custo de rastreamento e latência: Monitorar a frequência com que os modelos são chamados, quanto tempo demoram e quanto custam
• Notificando desvio: Identificar quando a qualidade das respostas muda ao longo do tempo, o que pode indicar uma atualização do modelo ou degradação do desempenho em dados específicos

Para desenvolvedores Java, isso corresponde à prática existente. Já integramos OpenTelemetriaestruturas de registro estruturadas e exportadores de métricas como Micrômetro. A diferença é que agora precisamos aplicar essas ferramentas a sinais específicos de IA. Um immediate é como um evento de entrada. Uma resposta do modelo é como uma dependência downstream. A observabilidade se torna uma camada adicional que atravessa a pilha, capturando o próprio processo de raciocínio.

Considere um Aplicativo Quarkus que se integra ao OpenTelemetry. Você pode criar intervalos para cada chamada de IA; adicione atributos para o nome do modelo, contagem de tokens, latência e ocorrências de cache; e exporte essas métricas para o Grafana ou outro sistema de monitoramento. Isso torna o comportamento da IA ​​visível nos mesmos painéis que sua equipe de operações já usa.

Mapeando novas camadas para práticas familiares

A principal conclusão é que estas novas camadas não substituem as antigas. Eles os estendem. A injeção de dependência ainda funciona. Você deve injetar um componente guardrail em um serviço da mesma forma que injeta um validador ou registrador. Bibliotecas de tolerância a falhas como MicroProfile Fault Tolerance ou Resilience4j ainda são úteis. Você pode encerrar chamadas de IA com tempos limite, novas tentativas e disjuntores. Estruturas de observabilidade como Micrometer e OpenTelemetry ainda são relevantes. Você apenas aponta novos sinais.

Ao tratar a validação e a observabilidade como camadas, e não como patches advert hoc, você mantém a mesma disciplina arquitetônica que sempre definiu o Java corporativo. Essa disciplina é o que mantém os sistemas sustentáveis ​​à medida que crescem e evoluem. As equipes sabem onde procurar quando algo falha e como estender a arquitetura sem introduzir hacks frágeis.

Um exemplo de fluxo

Think about um terminal REST que responda às perguntas dos clientes. O fluxo fica assim:

1. A solicitação chega à camada REST.
2. Um construtor de contexto recupera documentos relevantes de um armazenamento de vetores.
3. O immediate é montado e enviado para um modelo native ou remoto.
4. O resultado passa por uma camada de proteção que valida a estrutura e o conteúdo.
5. Os ganchos de observabilidade registram o immediate, o contexto e a resposta para análise posterior.
6. O resultado validado flui para a lógica de negócios e é retornado ao cliente.

Este fluxo tem camadas claras. Cada um pode evoluir de forma independente. Você pode trocar o armazenamento de vetores, atualizar o modelo ou apertar as proteções sem reescrever todo o sistema. Essa modularidade é exatamente o que as arquiteturas Java corporativas sempre valorizaram.

Um exemplo concreto pode ser o uso de LangChain4j no Quarkus. Você outline uma interface de serviço de IA, anota-a com a ligação do modelo e injeta-a em sua classe de recurso. Em torno desse serviço, você adiciona um interceptador de proteção que impõe um esquema usando Jackson. Você adiciona um intervalo OpenTelemetry que registra o immediate e os tokens usados. Nada disso exige o abandono da disciplina Java. É o mesmo pensamento de pilha que sempre usamos, agora aplicado à IA.

Implicações para arquitetos

Para os arquitetos, a principal implicação é que a IA não elimina a necessidade de estrutura. Na verdade, aumenta. Sem limites claros, a IA torna-se uma caixa preta no meio do sistema. Isso não é aceitável em um ambiente empresarial. Ao definir proteções e observabilidade como camadas explícitas, você torna os componentes de IA tão gerenciáveis ​​quanto qualquer outra parte da pilha.

Isto é o que avaliação neste contexto significa: medir sistematicamente o comportamento de um componente de IA, utilizando testes e monitorização que vão além das tradicionais verificações de correcção. Em vez de esperar resultados exatos, as avaliações analisam a estrutura, os limites, a relevância e a conformidade. Eles combinam testes automatizados, solicitações selecionadas e, às vezes, revisão humana para criar confiança de que um sistema está se comportando conforme planejado. Em ambientes empresariais, a avaliação torna-se uma atividade recorrente em vez de uma etapa única de validação.

A própria avaliação torna-se uma preocupação arquitetônica que vai além dos próprios modelos. Hamel Husain descreve a avaliação como um sistema de primeira classe, não um complemento. Para desenvolvedores Java, isso significa construir a avaliação em CI/CD, assim como os testes de unidade e integração. A avaliação contínua de prompts, recuperação e resultados torna-se parte do portão de implantação. Isso amplia o que já fazemos com suítes de testes de integração.

Essa abordagem também ajuda com habilidades. As equipes já sabem pensar em termos de camadas, serviços e preocupações transversais. Ao enquadrar a integração da IA ​​da mesma forma, você diminui a barreira para a adoção. Os desenvolvedores podem aplicar práticas familiares a comportamentos desconhecidos. Isto é basic para o pessoal. As empresas não devem depender de um pequeno grupo de especialistas em IA. Eles precisam de grandes equipes de desenvolvedores Java que possam aplicar suas habilidades existentes com apenas um treinamento moderado.

Há também um aspecto de governança. Quando reguladores ou auditores perguntam como funciona o seu sistema de IA, você precisa mostrar mais do que um diagrama com uma caixa “ligue para o LLM aqui”. Você precisa mostrar a camada de validação que verifica os resultados, as proteções que aplicam as políticas e a observabilidade que registra as decisões. É isso que transforma a IA de um experimento em um sistema de produção confiável.

Esperando ansiosamente

As mudanças arquitetônicas descritas aqui são apenas o começo. Mais camadas surgirão à medida que a adoção da IA ​​amadurecer. Veremos camadas de cache especializadas e por usuário para controlar custos, controle de acesso refinado para limitar quem pode usar quais modelos e novas formas de teste para verificar o comportamento. Mas a lição principal é clara: a IA exige que adicionemos estrutura, e não que a removamos.

A história do Java nos dá confiança. Já passamos por mudanças de monólitos para sistemas distribuídos, de programação síncrona para reativa e de native para nuvem. Cada mudança adicionou camadas e padrões. Cada vez, o ecossistema se adaptava. A chegada da IA ​​não é diferente. É mais um passo na mesma jornada.

Para os desenvolvedores Java, o desafio não é jogar fora o que sabemos, mas ampliá-lo. A mudança é actual, mas não é estranha. A história do Java de arquiteturas em camadas, injeção de dependência e serviços transversais nos dá as ferramentas para lidar com isso. O resultado não são protótipos ou demonstrações únicas, mas aplicações confiáveis, auditáveis ​​e prontas para os longos ciclos de vida exigidos pelas empresas.

Em nosso livro, IA aplicada para desenvolvimento Java empresarialexploramos essas mudanças arquitetônicas em profundidade com exemplos e padrões concretos. Desde pipelines de recuperação com Docling até testes de proteção e integração de observabilidade, mostramos como os desenvolvedores Java podem pegar as ideias descritas aqui e transformá-las em sistemas prontos para produção.