Disjuntores de IA doméstica: por que uma ferramenta com falhas não deve bloquear todos os pedidos
Um disjuntor impede que uma ferramenta de IA doméstica com falhas bloqueie todos os pedidos, interrompendo chamadas repetidas até que a recuperação se torne plausível.
Um agente pode depender de pesquisa, transcrição, de uma API de câmara e de uma ponte para casa inteligente. Se uma ferramenta bloquear, todos os fluxos de trabalho que lhe tocam podem ocupar um trabalhador, aguardar um tempo limite e tentar novamente. Um disjuntor converte falhas repetidas numa rejeição rápida temporária, preservando threads e capacidade da fila para pedidos que ainda podem ser concluídos.
Os tempos limite repetidos consomem capacidade para além da ferramenta avariada
Um tempo limite ocupa uma ligação, um trabalhador e o prazo do fluxo de trabalho, sem produzir qualquer resultado útil. Os passos paralelos do agente podem multiplicar esse custo, e as novas tentativas podem manter ocupada uma dependência já pouco saudável. O modelo local pode ser rápido, enquanto os utilizadores aguardam pela mesma chamada externa condenada ao fracasso.
A AWS descreve o padrão de disjuntor como um proxy com estado que monitoriza falhas e bloqueia pedidos quando um limiar é atingido. O padrão difere de uma nova tentativa porque deixa de consumir capacidade com uma dependência que se prevê que falhe.
A falha rápida permite ao orquestrador omitir um passo opcional, utilizar dados em cache ou comunicar uma disponibilidade parcial. Também impede que a fila principal fique cheia de chamadas que não podem ser concluídas antes dos respetivos prazos. Esta distinção continua a ser importante em condições realistas de funcionamento doméstico.
Os estados fechado, aberto e semiaberto controlam a recuperação
No estado fechado, as chamadas prosseguem e as falhas são contabilizadas. Ao ultrapassar o limiar configurado, o circuito abre e rejeita chamadas durante um período de arrefecimento. O estado semiaberto admite então uma sondagem limitada; se for bem-sucedida, fecha o circuito, enquanto uma falha o volta a abrir.
As orientações da Microsoft sobre estados do disjuntor salientam que as contagens de falhas, o tempo limite e o comportamento de recuperação devem adequar-se à operação. Um disjuntor partilhado pode ser demasiado genérico quando os pontos finais de leitura e escrita têm modos de falha diferentes. O estado intermédio deve permanecer visível durante o diagnóstico e a revisão posteriores.
O disjuntor deve estar associado à operação da ferramenta e à classe de falha. Os erros de autenticação, os limites de frequência, os tempos limite, os argumentos inválidos e as recusas do modelo exigem regras de recuperação diferentes; combiná-los num único contador pode ocultar a verdadeira falha.
As alternativas podem preservar a disponibilidade, reduzindo a correção
Um valor meteorológico em cache pode ser adequado para apresentação, mas inseguro para fechar janelas durante uma tempestade. Um modelo de CPU pode responder lentamente, mas com correção, enquanto um resultado genérico pode parecer completo e induzir o agente em erro. Os disjuntores protegem a capacidade, não a qualidade semântica.
O catálogo de disjuntores para agentes aplica a interrupção de circuito às ferramentas dos agentes e salienta a necessidade de alternativas e observabilidade. Num agente, o resultado de um circuito aberto deve permanecer estruturado, para que o planeador consiga distinguir dados indisponíveis de uma resposta negativa.
A fronteira de falha é qualquer ação que exija o resultado atual da ferramenta em falta. Nesse caso, falhe de forma segura, indique a dependência indisponível e peça aprovação ou tente novamente mais tarde, em vez de substituir silenciosamente os dados por evidências desatualizadas ou mais fracas.
Injete uma falha numa ferramenta e rastreie o isolamento
Escolha uma ferramenta não destrutiva e injete tempos limite, erros e respostas lentas enquanto os fluxos de trabalho mistos continuam. Registe o estado do disjuntor, a janela de falha, as chamadas simultâneas, a profundidade da fila, a alternativa selecionada e as sondagens de recuperação. Verifique se as ferramentas não relacionadas mantêm a latência normal.
Teste o limite da alternativa baseada em CPU descrito na mudança para CPU em caso de falha, mas assinale explicitamente a execução degradada e meça se ainda cumpre o prazo do fluxo de trabalho. Confirme que uma sondagem em estado semiaberto não pode desencadear uma vaga de pedidos em espera.
O teste só passa se a operação com falha ficar isolada, os chamadores receberem um estado estruturado de indisponibilidade e a recuperação fechar o disjuntor após sondagens controladas. Se os resultados em cache ou alternativos alterarem uma ação, adicione um controlo de política antes de ativar essa alternativa.
Produtos recomendados
Centro de Tecnologia e IA
Mais para Ler
Calibração da pontuação de pesquisa privada: como a similaridade bruta se transforma num indicador de confiança utilizável
Saiba por que razão a similaridade do cosseno não é confiança, como as consultas rotuladas calibram as pontuações e como monitorizar os limiares quando...
Localidade NUMA da IA local: por que a colocação da memória altera a taxa de alimentação do acelerador
Saiba como a topologia da CPU, da RAM e do PCIe afeta a alimentação do acelerador, por que motivo a colocação automática pode variar...
Mapeamento de ficheiros de modelos na memória: como as páginas partilhadas reduzem a utilização duplicada de RAM
Compreenda como as páginas de modelos mapeados são paginadas e partilhadas, por que motivo o RSS pode induzir em erro e que caches e...
