Compound AI Systems

Os sistemas de IA compostos são aplicações de IA construídas a partir de múltiplos componentes interativos em vez de um único modelo. Um sistema pode combinar modelos, serviços de recuperação, bases de dados, regras determinísticas, ferramentas externas e revisão humana num único fluxo de trabalho coordenado. Na visão computacional, por exemplo, um modelo pode detetar objetos enquanto o software de rastqueamento mantém identidades, as regras de negócio interpretam eventos e os serviços de monitorização observam o desempenho em produção. A característica definidora é a composição: o comportamento ao nível do sistema emerge da forma como as peças trocam informações e tomam decisões.

Como Funcionam os Sistemas de IA Compostos#

Um sistema composto divide uma tarefa maior em etapas especializadas. Os componentes típicos incluem pré-processamento de dados, um ou mais modelos de IA, armazenamento, lógica de validação, interfaces de programação de aplicações e uma camada de orquestração. Contratos claros, tais como os descritos pela OpenAPI Specification, definem os dados que cada serviço aceita e devolve.

O controlo pode ser determinístico, com código convencional a chamar componentes numa sequência fixa, ou dinâmico, com uma camada de AI agent orchestration a selecionar ferramentas e rotas em tempo de execução. A AI orchestration coordena dependências, tentativas, recursos e o fluxo de dados em toda a aplicação.

Os padrões comuns incluem retrieval-augmented generation, onde a recuperação fornece contexto a um modelo de linguagem, e pipelines de fusão de sensores que combinam câmaras, radares ou outras entradas. A mudança mais vasta de modelos isolados para sistemas integrados é descrita na Berkeley AI Research overview of compound AI systems. (bair.berkeley.edu)

Porque É Que os Sistemas Compostos Importam#

A composição permite aos programadores melhorar uma aplicação sem re-treinar um modelo enorme. Um componente especializado pode ser substituído, escalado ou otimizado enquanto o resto do fluxo de trabalho permanece estável. As regras e as etapas de validação também podem fornecer mais controlo do que depender inteiramente da saída probabilística de um modelo.

Estes benefícios introduzem compromissos ao nível do sistema:

• Propagação de falhas: Uma deteção incorreta, uma recuperação falhada ou uma API indisponível podem afetar todas as decisões a jusante.
• Latência e custo: Cada chamada de modelo, pedido de rede e etapa de verificação consome parte do orçamento total de resposta.
• Desvio de interface: Atualizar um serviço pode alterar o seu formato de saída ou pressupostos e quebrar silenciosamente outro componente.
• Avaliação difícil: Um componente forte não garante um resultado de ponta a ponta forte.

Consequentemente, as machine learning operations devem abranger todo o fluxo de trabalho. A OpenTelemetry observability guidance explica como os rastontos, métricas e registos revelam o que aconteceu em serviços distribuídos, enquanto o MLflow experiment tracking pode registar configurações de modelos e resultados de avaliação. (opentelemetry.io)

Conceitos Relacionados e Principais Diferenças#

Um sistema de IA composto não é simplesmente outro nome para um modelo complexo.

Um model ensemble combina previsões de múltiplos modelos, frequentemente através de votação, cálculo de média ou empilhamento. Um ensemble pode ser um componente dentro de um sistema composto, mas normalmente carece de bases de dados, ferramentas, lógica de fluxo de trabalho e serviços operacionais.

Um fluxo de trabalho agêntico permite que os modelos escolham ações ou ferramentas de forma autónoma. Os sistemas compostos são mais abrangentes: muitos utilizam pipelines fixas, serviços orientados a eventos ou aprovação humana sem agentes autónomos.

Da mesma forma, o RAG é um padrão composto específico que envolve recuperação e geração. A IA composta também pode coordenar visão computacional, previsão, otimização, robótica e software convencional sem utilizar um modelo de linguagem.

Aplicações no Mundo Real#

• Manufacturing visual inspection: Uma câmara captura produtos, um Ultralytics YOLO26 model deteta defeitos, a lógica baseada em regras verifica a gravidade e a localização, e um sistema de produção rejeita ou aprova cada item. Os casos incertos podem ser encaminhados para um inspetor humano, enquanto as imagens armazenadas apoiam o re-treino posterior.

• Traffic and parking analytics: A deteção identifica veículos, o multi-object tracking mantém identidades entre fotogramas, a lógica geométrica determina a ocupação de faixas ou de zonas de estacionamento, e os painéis agregam contagens e alertas. Os erros podem causar contagens duplicadas, eventos de congestionamento perdidos ou estimativas de disponibilidade incorretas, pelo que cada etapa deve ser testada em conjunto.

O exemplo simplificado seguinte mostra a perceção a alimentar a lógica de decisão determinística:

from ultralytics import YOLO

# Perception component
model = YOLO("yolo26n.pt")
results = model("https://ultralytics.com/images/bus.jpg")
result = results[0]

# Policy component
person_class = next(i for i, name in result.names.items() if name == "person")
person_count = int((result.boxes.cls == person_class).sum())
decision = "review" if person_count >= 4 else "continue"

print({"people_detected": person_count, "next_step": decision})
result.save(filename="compound_system_input.jpg")

Aqui, o YOLO produz observações estruturadas, enquanto a lógica de política separada determina a ação seguinte. Um sistema em produção poderia adicionar armazenamento, notificações, controlos de acesso ou revisão humana.

Orientações Práticas de Conceção#

Começa com um objetivo de ponta a ponta mensurável, depois atribui a cada componente uma responsabilidade clara. Define esquemas e tempos limite em cada limite, testa os componentes de forma independente e avalia fluxos de trabalho realistas em vez de apenas a precisão do modelo.

Usa rastontos para seguir pedidos individuais, define orçamentos de latência e custo, e fornece tentativas ou alternativas seguras para serviços indisponíveis. As Kubernetes health probes ilustram como os serviços implementados podem expor sinais de prontidão e vivacidade.

Os controlos de risco devem abranger todo o sistema, incluindo acesso a dados, ferramentas externas, anulações humanas e consequências a jusante. O NIST AI Risk Management Framework fornece orientações orientadas para o ciclo de vida para governar, medir e gerir estes riscos. As equipas podem usar a Ultralytics Platform para ligar a anotação de conjuntos de dados, treino, implementação e monitorização em produção para componentes de visão dentro de uma aplicação composta mais ampla. (nist.gov)