Este capítulo foca nos desafios de estabilidade exclusivos dos sistemas de IA e estabelece um sistema de proteção em várias camadas que abrange a robustez da inferência, a qualidade da saída, a confiabilidade dos dados e a confiabilidade do fluxo de trabalho.
Desafios de estabilidade da IA
Não determinismo
A relação entre entrada e saída no software tradicional é determinística: a mesma entrada sempre produz a mesma saída. Em contrapartida, o processo de inferência de um large language model é inerentemente aleatório e controlado por parâmetros de amostragem como temperature. Isso significa que, mesmo com a mesma entrada, a saída pode variar em momentos diferentes. Essa característica torna as metodologias tradicionais de "Golden Test" ineficazes, pois não é possível simplesmente comparar a saída com um resultado esperado para determinar se o sistema está funcionando corretamente.
Embora definir temperature como 0 reduza a aleatoriedade, isso não garante um determinismo completo. Diferenças no hardware de GPU, nas estratégias de paralelização ou até mesmo nos tamanhos de lote podem levar a variações na precisão de ponto flutuante, afetando diretamente os resultados gerados. Para cenários de negócios que exigem saídas estritamente consistentes, você deve implementar salvaguardas adicionais de consistência no nível da arquitetura.
Instabilidade no inference service
Os inference services baseados em GPU apresentam mais fatores de instabilidade do que os services tradicionais baseados em CPU. O OOM (out-of-memory) de GPU é o problema mais comum. Quando o comprimento combinado do contexto de requisições simultâneas excede a capacidade de memória da GPU, o service pode falhar ou retornar resultados truncados. Ao contrário da memória da CPU, que pode usar o espaço de swap como buffer, o OOM de GPU geralmente é abrupto e não permite uma degradação controlada.
O cold start é outro grande desafio. Carregar um modelo grande exige a leitura de dezenas ou até centenas de gigabytes de arquivos de pesos do armazenamento para a memória da GPU, um processo que pode levar vários minutos. Durante o dimensionamento elástico, as novas instâncias não podem atender a requisições até que o modelo seja totalmente carregado, o que torna a resposta de scale-out muito mais lenta do que em aplicações tradicionais.
O hardware de GPU tem uma taxa de falha maior do que o hardware de CPU. Em clusters de inferência de grande escala, a falha de um único nó de GPU é uma ocorrência comum, e não uma exceção. A arquitetura do sistema deve ser projetada para tolerar falhas de nós.
Exaustão de cota e limitação de taxa
Ao usar model APIs baseadas em cloud, sejam elas de terceiros ou auto-hospedadas, você precisa lidar com cotas e limitação de taxa. A cota de tokens pode ser medida por minuto, hora ou dia, e as requisições são rejeitadas assim que a cota é excedida. Em cenários com picos repentinos de tráfego, como um pico de customer service durante uma campanha de marketing, a exaustão da cota pode fazer com que o service fique indisponível justamente quando é mais necessário.
As políticas de limitação de taxa geralmente se baseiam na frequência de requisições (RPM/RPD) ou no throughput de tokens (TPM), com limites diferentes para diferentes níveis de clientes. À medida que o crescimento do negócio aproxima o volume de requisições do limiar de limitação de taxa, erros ocasionais de throttling podem ser confundidos com bugs do sistema.
Falhas em cascata de agentes
Em uma arquitetura de agentes, a conclusão de uma tarefa geralmente depende de uma cadeia de múltiplas chamadas de ferramentas. Uma falha em qualquer etapa intermediária pode quebrar toda a cadeia da tarefa. Uma situação mais perigosa é a "falha silenciosa", em que uma etapa intermediária retorna um resultado anormal em vez de um erro. O modelo então continua seu raciocínio com base nesses dados intermediários defeituosos, produzindo uma saída final que parece plausível, mas que na verdade está incorreta.
A colaboração multiagente complica ainda mais esse cenário: a saída do Agente A se torna a entrada do Agente B, e quaisquer problemas de qualidade na saída de A são amplificados na saída de B.
Degradação da atualização da base de conhecimento
Os sistemas de RAG (Retrieval-Augmented Generation) dependem de documentos em uma base de conhecimento para fornecer respostas precisas. Com o tempo, as informações na base de conhecimento podem ficar desatualizadas. Por exemplo, os preços de product podem mudar, mas a base de conhecimento ainda mostra os preços antigos; as regulamentações podem ser revisadas, mas a base ainda cita a versão antiga; ou as estruturas organizacionais podem mudar, mas a base ainda lista informações de contato antigas. A atualização de uma base de conhecimento se degrada de forma lenta, porém contínua. Seu impacto não é uma interrupção repentina do service, mas um declínio gradual na qualidade da saída — o sistema continua respondendo, mas suas respostas se tornam cada vez mais imprecisas.
Robustez da inferência
BP-REL-01: Fallback multi-modelo
Justificativa
Qualquer model service individual pode sofrer indisponibilidade ou degradação de desempenho. Ao configurar uma estratégia de fallback de três camadas — modelo principal, modelo de backup e cache —, você garante a continuidade do negócio quando o service principal falha ou sofre degradação.
Implementação
Projete uma cadeia de fallback de três camadas: Modelo principal → Modelo de backup → Cache/Sistema baseado em regras. Em condições normais, o modelo principal lida com 100% do tráfego. Quando o modelo principal apresenta problemas, como timeouts, taxa de erro acima de um limiar ou queda na pontuação de qualidade, o tráfego muda automaticamente para o modelo de backup. O modelo de backup geralmente é um modelo de custo mais baixo que ainda pode suportar funções básicas do negócio, como fazer o downgrade de um modelo de parâmetros grandes para um de parâmetros médios. Se o modelo de backup também ficar indisponível, o sistema sofre degradação para um cache que retorna respostas pré-calculadas para perguntas comuns ou para um sistema baseado em regras que gera respostas padronizadas a partir de templates.
Use o padrão de circuit breaker para gerenciar a troca de modelos. Um circuit breaker mantém três estados: Closed (usa o modelo principal), Open (muda para o modelo de backup) e Half-Open (sonda o modelo principal para verificar a recuperação). O circuit breaker passa para o estado Open quando as condições são atendidas, como N requisições consecutivas com falha, taxa de erro excedendo um limiar em uma janela deslizante ou latência média ultrapassando o limite de SLO. Após um período definido, o circuit breaker entra no estado Half-Open e permite a passagem de um pequeno número de requisições para testar se o modelo principal se recuperou.
Garanta que os formatos de saída dos modelos principal e de backup sejam compatíveis. Se o modelo principal for da classe GPT-4 e o backup for da classe GPT-3.5, seus schemas de saída devem ser consistentes para que a lógica de negócio não precise ser ajustada para fazer o parse da saída quando ocorrer uma troca.
Antipadrões: depender de um único model service sem configuração de fallback, o que leva a uma interrupção total do negócio se o service falhar; ou configurar um fallback sem testes de compatibilidade, causando erros de parse downstream devido a incompatibilidades de schema quando ocorre uma troca.
Prática da Alibaba Cloud: O AI Gateway permite configurar múltiplos endpoints de modelo e implementar a troca principal/backup com lógica de roteamento personalizada. O PAI-EAS pode implantar múltiplas instâncias de model service, e o mecanismo de health check do Application Load Balancer (ALB) pode remover automaticamente as instâncias de backend não saudáveis.
BP-REL-02: Backpressure de cota e limitação de taxa
Justificativa
As cotas de API e a limitação de taxa são restrições inerentes aos cloud AI services. Padrões de tráfego mal gerenciados podem levar à rejeição de requisições críticas devido à exaustão da cota, enquanto requisições não críticas consomem cotas valiosas. Crie mecanismos de gerenciamento de cota no lado do cliente e de monitoramento de tráfego para lidar com a limitação de taxa upstream de forma controlada.
Implementação
Implemente a limitação de taxa no lado do cliente usando o algoritmo de token bucket. Com base em uma cota de API conhecida (por exemplo, 100 mil tokens por minuto), mantenha um token bucket no lado do cliente. Cada requisição adquire tokens com base em seu consumo estimado. Se o bucket estiver vazio, as requisições são colocadas em uma fila de espera em vez de falhar imediatamente. Essa abordagem transforma a limitação de taxa rígida da API (rejeição) em um limite flexível no lado do cliente (enfileiramento), proporcionando uma experiência de usuário mais fluida.
Use um mecanismo de backpressure. Quando o acúmulo na fila de requisições exceder um limiar, envie um sinal de "sistema ocupado" para o chamador upstream, como um usuário final ou outro service. O chamador pode então decidir se espera, tenta novamente ou usa um fallback. O sinal de backpressure deve incluir um tempo de espera estimado para ajudar o chamador a tomar uma decisão informada.
Defina prioridades de requisição para diferentes tipos de requisições. As requisições críticas do negócio, como chats de customer service em tempo real, devem ter acesso prioritário à cota. Requisições não realizadas em tempo real, como processamento de dados em lote ou geração de relatórios, podem ser executadas em horários de menor movimento. Uma fila de prioridade garante que as requisições críticas não sejam deslocadas pelas não críticas quando a cota estiver escassa.
Aqueça sua cota. Antes de picos de tráfego previsíveis, como promoções de e-commerce ou eventos de marketing, coordene com seu provedor de cloud para aumentar sua cota ou pré-implantar instâncias de inferência adicionais. Use padrões históricos de tráfego para prever a demanda e preparar os recursos antes que o pico chegue.
Antipadrão: enviar requisições em uma taxa descontrolada sem ter ciência dos limites de cota upstream. Isso leva a um alto número de rejeições, e as novas tentativas subsequentes podem exacerbar ainda mais o congestionamento, criando uma tempestade de retentativas.
Prática da Alibaba Cloud: O AI Gateway suporta uma API Rate Limiting Policy projetada para services de modelos grandes e cenários de alta concorrência. Ele fornece controle dinâmico com base em múltiplas dimensões, incluindo consumo de tokens, contagem de requisições e concorrência. Você pode configurar regras de limitação de taxa com base na identidade do consumidor, cabeçalhos de requisição, parâmetros de consulta, cookies, IP do cliente ou nome do modelo. Ele também oferece limitação de taxa global no nível da API. Essa abordagem multidimensional corresponde precisamente às características de consumo de recursos de modelos grandes, prevenindo de forma eficaz a sobrecarga do sistema, o abuso de API e chamadas maliciosas, ao mesmo tempo em que garante a estabilidade das operações principais do negócio em cenários complexos.
BP-REL-03: Implantação entre AZs e roteamento de health check
Justificativa
A implantação em uma única zona de disponibilidade expõe seu service ao risco de uma falha no nível do data center. Embora essas falhas sejam raras, seu raio de impacto é grande e a recuperação pode ser demorada. Uma implantação entre AZs para AI inference services garante a continuidade do negócio mesmo se uma zona de disponibilidade falhar.
Implementação
Implante seu inference service em pelo menos duas zonas de disponibilidade dentro da mesma região. Cada zona de disponibilidade deve ter uma implantação completa e independente do inference service, incluindo o carregamento do modelo e os recursos de GPU, em vez de uma simples configuração ativo-standby. Em condições normais, ambas as AZs lidam com o tráfego. Se uma AZ falhar, a outra assume toda a carga.
Use um balanceador de carga para health checks e roteamento de tráfego. Os health checks devem validar mais do que apenas a atividade do processo (sondas TCP/HTTP). Eles também devem incluir a verificação da disponibilidade do modelo, enviando periodicamente uma requisição de inferência leve para confirmar se o modelo foi carregado corretamente e se pode responder. Um health check TCP tradicional não consegue detectar um problema em que o processo está em execução, mas o modelo falhou ao carregar, por exemplo, devido a um problema no driver da GPU.
Planeje a capacidade entre AZs com redundância: cada zona de disponibilidade deve ser capaz de suportar a carga total de tráfego de forma independente (um modelo de capacidade N+1), em vez de presumir que todas as AZs estão sempre disponíveis. Caso contrário, se uma AZ falhar, a AZ restante ficará sobrecarregada, levando a uma falha em cascata.
Antipadrões: implantar todas as instâncias de inferência em uma única zona de disponibilidade; ou implantar entre AZs, mas com capacidade insuficiente em qualquer AZ individual para lidar com a carga total.
Prática da Alibaba Cloud: O PAI-EAS suporta implantação entre AZs para inference services; recomendamos a implantação em pelo menos duas zonas de disponibilidade. O Model Studio suporta PrivateLink, o que permite o acesso de rede multi-AZ para garantir a recuperação de desastres entre AZs. Combine isso com o Application Load Balancer (ALB) para distribuição de tráfego e roteamento baseado em health check. O ALB suporta caminhos de health check personalizados, que podem ser configurados para direcionar o endpoint de sonda de inferência de um model service.
Proteção da qualidade da saída
BP-REL-04: Validação de schema de saída estruturada
Justificativa
Quando a saída de uma IA deve ser consumida programaticamente por sistemas downstream, como uma resposta de API formatada em JSON ou um resultado de decisão estruturada, a confiabilidade do formato de saída impacta diretamente a estabilidade do sistema. Os large language models podem produzir conteúdo estruturado incompleto, com campos ausentes ou contendo tipos de dados incorretos, fazendo com que o parse downstream falhe.
Implementação
Use um JSON Schema para definir o formato de saída esperado, incluindo campos obrigatórios, tipos de dados, valores de enum e estruturas aninhadas. Ao chamar o modelo, use Function Calling ou um parâmetro de formato de resposta para especifique o schema de saída e restringir o modelo a gerar uma saída que esteja em conformidade com o schema.
Execute a validação de schema na saída do modelo antes de enviá-la para downstream. Se a validação falhar, inicie um fluxo de retentativa. Envie o erro de validação de volta para o modelo com requisitos de formato mais explícitos e regenere a saída. Defina um limite de retentativas, geralmente de 2 a 3 tentativas. Se as retentativas falharem, execute a lógica de fallback, como retornar um valor padrão ou notificar o usuário de que a requisição não pode ser processada.
Lide com saídas em streaming com cuidado. Uma geração em streaming pode ser interrompida no meio do caminho devido a limites de tokens ou problemas de rede, resultando em uma saída JSON incompleta. Valide a integridade da saída em streaming após ela ser totalmente recebida. Trate saídas incompletas como falhas e acione uma retentativa.
Para cenários críticos do negócio, considere o uso de técnicas de decodificação restrita. Isso garante que a saída gerada adira estritamente a uma gramática especificada, como a sintaxe JSON ou valores de enum específicos, eliminando erros de formato na origem.
Antipadrão: fazer o parse da saída do modelo diretamente usando concatenação de strings ou expressões regulares sem validação de formato. Uma pequena mudança no formato de saída, como um espaço extra ou uma ordem de campo diferente, pode fazer o parser falhar.
Prática da Alibaba Cloud: O recurso Function Calling no Model Studio permite definir o formato de retorno com um schema. A API do DashScope suporta o parâmetro response_format para especifique a saída JSON. No código da sua aplicação, você pode implementar um loop de validação e retentativa usando uma biblioteca de validação de JSON Schema.
BP-REL-05: Validação de autoconsistência para decisões críticas
Justificativa
Para cenários em que a saída influencia diretamente decisões de alto impacto, como pontuação de risco, julgamentos de conformidade ou recomendações de assistência médica, uma única inferência de modelo não é confiável o suficiente. Ao realizar múltiplas inferências e comparar os resultados quanto à consistência, você pode identificar casos em que a incerteza do modelo é alta e evitar tomar decisões críticas com base em uma única saída, potencialmente instável.
Implementação
Use a votação de autoconsistência: execute N inferências para a mesma entrada (N geralmente é de 3 a 5) e compare os resultados. Se a maioria dos resultados for consistente, use o resultado da maioria. Se os resultados forem diversos e não houver uma maioria clara, sinalize a saída como "modelo incerto" e encaminhe-a para um humano tomar a decisão ou solicite mais informações ao usuário.
Use a verificação cruzada de modelos. Execute a inferência na mesma entrada usando dois modelos diferentes e compare seus resultados. Modelos diferentes possuem dados de treinamento e padrões de viés diferentes, portanto, um resultado consistente de ambos é mais confiável. Se os resultados forem inconsistentes, acione uma revisão manual ou use um terceiro modelo como desempate.
Crie uma pontuação de consistência. Quantifique a consistência como uma pontuação (por exemplo, uma pontuação de 0,8 se quatro de cinco inferências forem consistentes). Defina limiares de consistência diferentes para diferentes cenários de negócio. Os resultados abaixo do limiar não devem ser executados automaticamente, mas devem incluir um aviso de incerteza ou ser escalados.
Controle os custos. Múltiplas inferências aumentam o custo. Você deve ativar as verificações de autoconsistência apenas para cenários críticos de tomada de decisão. Para casos de uso de baixo risco, como consultas de informações ou bate-papo casual, uma única inferência é suficiente. Controle a estratégia de validação por meio de camadas no nível do negócio.
Antipadrões: ativar verificações de multi-inferência para todas as requisições de forma indiscriminada, o que leva a custos incontroláveis; ou usar apenas uma única inferência para uma decisão crítica e executá-la diretamente, o que cria um risco inaceitável.
Prática da Alibaba Cloud: O AI Gateway permite configurar múltiplos endpoints de modelo. Você pode usar o Log Service (SLS) para registrar os resultados brutos de cada inferência para análise de consistência post-hoc e avaliação da qualidade do modelo.
BP-REL-06: Retentativa com variantes de prompt
Justificativa
Os modelos são sensíveis à redação do prompt — diferentes formulações do mesmo significado semântico podem levar a saídas de qualidade variada. Quando uma inferência falha (devido à baixa qualidade ou formato incorreto), tentar novamente com um prompt ajustado geralmente pode produzir um resultado melhor. Essa abordagem aproveita a sensibilidade do modelo aos prompts.
Implementação
Quando acionar retentativas de variantes: acione isso apenas quando a validação da saída falhar (devido a erros de formato, conteúdo incompleto ou falha na verificação de segurança), e não de forma proativa para todas as requisições. Use o prompt principal na primeira tentativa e mude para uma variante predefinida nas retentativas.
Projete estratégias de variantes: predefina de 2 a 3 variantes de prompt semanticamente equivalentes, mas com redações diferentes. As variações podem incluir mudanças na redação da instrução ("Por favor, gere" vs. "Por favor, forneça a saída"), ênfase no formato (adicionando exemplos de formato ou usando tags XML para envolver o formato desejado), orientação de cadeia de pensamento (adicionando "Vamos pensar passo a passo") ou reordenação de restrições. Projete variantes com base em evidências empíricas do que funciona melhor para um modelo específico.
Defina um orçamento de custos. Para cada requisição, defina um número máximo de retentativas e um orçamento máximo de consumo de tokens. Se o consumo acumulado de tokens se aproximar do orçamento durante as retentativas, pare e execute a lógica de fallback. Isso evita custos fora de controle devido a retentativas infinitas.
Intervalo de retentativa: você não precisa de um tempo de espera entre as retentativas de variantes (ao contrário das retentativas de rede), porque o objetivo não é esperar a recuperação do service, mas sim tentar uma redação diferente. No entanto, se a falha for causada por limitação de taxa upstream, você deve seguir uma estratégia de backoff.
Antipadrões: tentar novamente indefinidamente com exatamente o mesmo prompt, o que provavelmente produzirá o mesmo resultado de falha; ou usar variantes de prompt com diferenças semânticas significativas, o que pode fazer com que a função da requisição mude.
Prática da Alibaba Cloud: Configure múltiplos templates de prompt na sua aplicação do Model Studio. O código da aplicação implementa a lógica de validação, troca de variantes e retentativas. Use o Application Real-Time Monitoring Service (ARMS) para monitorar a taxa de retentativas e a taxa de sucesso final. Uma alta taxa de retentativas pode acionar um alerta para otimização de prompt.
Confiabilidade de dados e conhecimento
BP-REL-07: Monitoramento de SLO de atualização da base de conhecimento
Justificativa
A base de conhecimento é a base da precisão de um sistema RAG. O conteúdo desatualizado em uma base de conhecimento é um problema gradual — o sistema não falhará de repente, mas suas respostas se tornarão cada vez menos precisas. Sem um monitoramento proativo da atualização, você pode descobrir o problema apenas depois que um grande número de usuários tiver recebido informações incorretas.
Implementação
Defina um Service Level Objective (SLO) de atualização para cada base de conhecimento, que é a idade máxima aceitável do seu conteúdo. Diferencie os SLOs com base no tipo de conteúdo. Por exemplo, o SLO para informações de preços pode ser de 24 horas (deve ser atualizado diariamente), o SLO para políticas legais pode ser de 48 horas (deve ser ingerido em até dois dias úteis após a divulgação de uma nova regulamentação) e o SLO para documentação de product pode ser de 7 dias.
Monitore as atualizações do conteúdo da base de conhecimento. Registre o horário da última atualização de cada documento e o horário de modificação do seu documento de origem. Use uma tarefa agendada para verificar a base de conhecimento e checar se algum documento excedeu seu SLO. Documentos desatualizados devem acionar um alerta para o responsável pela atualização.
Detecte alterações nos documentos de origem. Faça crawling periodicamente ou use webhooks para monitorar as fontes do conteúdo da sua base de conhecimento, como sites oficiais, wikis internas ou sites de divulgação de políticas. Quando uma alteração for detectada, acione automaticamente um processo de atualização da base de conhecimento ou, pelo menos, um processo de revisão manual.
Marque o conteúdo desatualizado. Para documentos que excederam seu SLO, mas ainda não foram atualizados, adicione uma tag de "informação pode estar desatualizada" aos resultados de recuperação. Isso permite que o modelo inclua um aviso de incerteza em sua geração. Isso impede que o sistema apresente informações potencialmente desatualizadas com alto nível de confiança.
Antipadrões: ingerir a base de conhecimento uma vez e nunca fazer sua manutenção; ou depender da memória humana para decidir o que precisa ser atualizado.
Prática da Alibaba Cloud: Os recursos de monitoramento de qualidade de dados do DataWorks podem ser usados para monitorar a atualização do conteúdo da base de conhecimento. As bases de conhecimento do Model Studio suportam atualizações de documentos orientadas por API, que podem ser integradas a um pipeline de CI/CD para atualizações automatizadas. O Log Service (SLS) pode registrar eventos de alteração da base de conhecimento, e o Application Real-Time Monitoring Service (ARMS) pode ser configurado com regras de alerta de atualização.
BP-REL-08: Banco de dados vetorial de alta disponibilidade
Justificativa
O banco de dados vetorial é o motor de recuperação de um sistema RAG. Sua indisponibilidade impede que o sistema de IA responda a perguntas com base na base de conhecimento, forçando-o a confiar no conhecimento do próprio modelo, que pode ser impreciso ou desatualizado. Um design de alta disponibilidade para um banco de dados vetorial deve equilibrar a consistência dos dados e a continuidade do service.
Implementação
Use uma arquitetura de múltiplas réplicas. Mantenha pelo menos duas réplicas dos dados do banco de dados vetorial, distribuídas em diferentes zonas de disponibilidade. As requisições de leitura podem ter sua carga balanceada entre as réplicas, permitindo o dimensionamento de leitura e a recuperação de desastres no nível da AZ. Replique operações de escrita de forma síncrona ou assíncrona para todas as réplicas, dependendo dos seus requisitos de consistência.
Implante entre AZs. Distribua os nós do banco de dados vetorial em múltiplas zonas de disponibilidade na mesma região. Se uma zona de disponibilidade falhar, as réplicas nas outras zonas podem continuar a fornecer o service. Use um balanceador de carga com health checks para failover automático.
Implemente backup e recuperação de dados. Crie regularmente backups de snapshot completos do banco de dados vetorial para uma recuperação rápida. A frequência do snapshot deve ser baseada na taxa de alteração dos dados — snapshots de hora em hora para bases de conhecimento atualizadas com frequência e snapshots diários para bases estáveis. Você deve validar seu processo de recuperação de snapshot e medir sua duração.
Mantenha a capacidade de reconstrução de índice. Retenha a fonte de dados original para o banco de dados vetorial (os dados de texto não vetorizados). Isso garante que você possa reconstruir completamente o índice a partir dos dados originais se o banco de dados vetorial sofrer uma corrupção irrecuperável. O processo de reconstrução deve ser automatizado e ter um cronograma previsível.
Antipadrões: implantar o banco de dados vetorial como uma instância única em uma única zona de disponibilidade, sem réplicas ou backups; ou ter backups, mas nunca validar o processo de recuperação.
Prática da Alibaba Cloud: O Alibaba Cloud Vector Search suporta implantações de múltiplas réplicas e entre AZs. Você pode usar o Log Service (SLS) para monitorar a latência de consulta e as métricas de disponibilidade do banco de dados vetorial. Para backup de dados, você pode usar o Object Storage Service (OSS) como destino de armazenamento e executar tarefas periódicas de snapshot.
BP-REL-09: Degradação controlada para falhas de recuperação
Justificativa
A etapa de recuperação em um sistema RAG pode falhar de várias maneiras: o banco de dados vetorial pode atingir o timeout, a recuperação pode não gerar resultados se a base de conhecimento não tiver conteúdo relevante, ou os resultados recuperados podem ser de baixa qualidade, com todas as pontuações de similaridade abaixo de um limiar. Você precisa projetar estratégias claras de degradação para essas situações, em vez de deixar o modelo "improvisar" sem resultados de recuperação válidos.
Implementação
Degradar quando o banco de dados vetorial estiver indisponível. Se o banco de dados vetorial atingir o timeout ou retornar um erro, escolha uma estratégia de degradação com base no tipo de requisição. Para perguntas simples e comuns, mude para um cache de FAQ pré-calculado e retorne a resposta diretamente. Para perguntas complexas, informe honestamente ao usuário que a "base de conhecimento está temporariamente indisponível, então a resposta pode estar incompleta" e gere uma resposta com base no conhecimento do próprio modelo, incluindo um aviso de baixa confiança.
Lide com resultados de recuperação vazios. Quando nenhuma informação relevante for encontrada na base de conhecimento, informe claramente ao usuário, por exemplo, "Nenhuma informação relevante foi encontrada na base de conhecimento atual", em vez de deixar o modelo inventar uma resposta. Opcionalmente, você pode fornecer sugestões, como "Você pode tentar reformular sua pergunta com estas palavras-chave" ou "Esta pergunta pode exigir o contato com um agente humano".
Lide com resultados de recuperação de baixa qualidade. Se todos os resultados recuperados tiverem pontuações de similaridade abaixo de um limiar predefinido, julgue os resultados como não confiáveis. Ao gerar uma resposta, declare explicitamente que "As informações a seguir são apenas para referência, pois nenhum conhecimento altamente correspondente foi encontrado" e marque a resposta com um alto nível de incerteza.
Torne a degradação observável. Registre em log e monitore todos os eventos de degradação. Um pico repentino na taxa de degradação pode indicar um problema com a base de conhecimento (como um índice corrompido ou dados desatualizados) ou um problema com o service do banco de dados vetorial, exigindo uma investigação oportuna.
Antipadrão: ignorar silenciosamente as falhas de recuperação e deixar o modelo gerar uma resposta sem nenhum contexto recuperado. O usuário não consegue distinguir se a resposta é suportada por conhecimento ou se é uma alucinação do modelo.
Prática da Alibaba Cloud: Na configuração da base de conhecimento do Model Studio, você pode definir um limiar de pontuação de similaridade para os resultados de recuperação. Implemente a lógica de degradação no código da sua aplicação. Registre em log as métricas de qualidade de recuperação, como pontuações de similaridade e o número de itens retornados, no Log Service (SLS). Configure alertas de taxa de degradação no Application Real-Time Monitoring Service (ARMS).
Confiabilidade de agentes e fluxos de trabalho
BP-REL-10: Retomada de tarefas com checkpointing
Justificativa
Tarefas complexas executadas por um agente podem envolver múltiplas etapas e levar vários minutos ou até horas para serem concluídas. Uma falha em qualquer etapa intermediária não deve exigir que a tarefa inteira seja reiniciada do começo, especialmente se as etapas concluídas com sucesso tiverem efeitos colaterais externos, como um e-mail que já foi enviado ou dados que já foram commitados. O checkpointing garante que uma tarefa possa ser retomada a partir do último checkpoint bem-sucedido.
Implementação
Persista o estado da tarefa. Salve periodicamente o estado de execução da tarefa em um meio de armazenamento persistente, como um banco de dados ou object storage. O estado deve incluir uma lista de etapas concluídas, a saída de cada etapa, a etapa atualmente em execução e os parâmetros de entrada para a próxima etapa. Persista o estado imediatamente após a conclusão de cada etapa.
Projete checkpoints. Defina checkpoints entre as etapas de uma tarefa. Cada checkpoint deve registrar o estado de execução completo e os resultados intermediários até aquele ponto. Ao se recuperar de uma falha, carregue o estado a partir do checkpoint mais recente e continue a execução, pulando as etapas que já foram concluídas com sucesso.
Garanta a idempotência. Quando a execução for retomada, a etapa que falhou pode ser reexecutada. Portanto, cada etapa deve ser projetada para ser idempotente, o que significa que reexecutá-la não produz efeitos colaterais adicionais. Para operações que não são naturalmente idempotentes, como enviar um e-mail, verifique um log de execução para determinar se a etapa já foi concluída com sucesso e evitar duplicatas.
Forneça um mecanismo de recuperação manual. Ofereça uma UI ou API que permita aos operadores acionar manualmente a recuperação de uma tarefa. Eles devem poder escolher retomar a partir de um checkpoint específico ou pular uma etapa com falha e continuar com as etapas subsequentes. Para cenários que não podem ser recuperados automaticamente, como aqueles que exigem intervenção humana para corrigir um resultado intermediário, suporte a injeção de dados corrigidos antes de retomar a execução.
Antipadrões: ter uma tarefa de longa duração sem persistência de estado, forçando uma reinicialização completa em caso de falha; ou ter checkpoints, mas com uma lógica de recuperação com bugs que faz com que as etapas concluídas sejam reexecutadas, levando à duplicação de dados.
Prática da Alibaba Cloud: Use o Function Compute (FC) ou o Cloud Workflows para orquestração de tarefas e persistência de estado. Os workflows do Model Studio suportam o registro do estado de execução no nível da etapa. Registre em log a trajetória de execução da tarefa no Log Service (SLS) para diagnóstico de falhas e validação de recuperação.
BP-REL-11: Circuit breakers para chamadas de ferramentas externas
Justificativa
As ferramentas externas das quais um agente depende, como APIs, bancos de dados ou services de terceiros, podem ficar indisponíveis ou lentas para responder. Sem os controles adequados, o agente pode tentar repetidamente uma chamada de ferramenta com falha, desperdiçando recursos e aumentando o tempo de espera do usuário. O padrão de circuit breaker pode interromper prontamente as chamadas para uma ferramenta com falha, evitando o desperdício de recursos e acelerando a recuperação de falhas.
Implementação
Configure uma instância de circuit breaker separada para cada ferramenta externa. O circuit breaker deve registrar o status de sucesso, falha e timeout das chamadas de ferramenta e calcular a taxa de falha em uma janela deslizante.
Defina as condições de acionamento do circuit breaker. Dentro de uma janela deslizante (por exemplo, os últimos 30 segundos), se a taxa de falha da chamada de ferramenta exceder um limiar (por exemplo, 50%) ou a latência média ultrapassar o SLO (por exemplo, o dobro do valor de timeout), passe o circuit breaker para o estado Open.
Defina o comportamento durante um circuito aberto. Quando o circuit breaker está Open, as chamadas subsequentes para essa ferramenta não são realmente executadas. Em vez disso, elas retornam imediatamente um resultado de fallback predefinido. O resultado de fallback deve ser informativo, dizendo ao modelo que "a ferramenta está atualmente indisponível", em vez de retornar um resultado de sucesso falso. Ao receber essa informação, o modelo deve ser capaz de ajustar sua estratégia, como pular a etapa, usar uma alternativa ou informar ao usuário que a tarefa não pode ser concluída.
Implemente uma estratégia de recuperação. Após um período definido (por exemplo, 30 segundos), o circuit breaker deve entrar no estado Half-Open e permitir um pequeno número de requisições para testar se a ferramenta se recuperou. Se as requisições de teste forem bem-sucedidas, ele retorna ao estado Closed e retoma as chamadas normais. Se ainda falharem, ele permanece Open.
Classifique as dependências das ferramentas. Distinga entre "ferramentas obrigatórias" e "ferramentas opcionais". Se o circuit breaker de uma ferramenta obrigatória abrir, a tarefa inteira deve entrar em um estado de espera ou degradação. Se o circuit breaker de uma ferramenta opcional abrir, essa etapa pode ser pulada e as etapas subsequentes podem continuar.
Antipadrões: não ter timeout, limite de retentativas ou circuit breaker para chamadas de ferramenta, permitindo que uma única ferramenta com falha atrase a resposta de todo o agente; ou ter um circuit breaker de granulação grossa, em que a falha de um endpoint de uma ferramenta faz com que todas as chamadas para essa ferramenta sejam bloqueadas.
Prática da Alibaba Cloud: O Application Real-Time Monitoring Service (ARMS) fornece monitoramento de saúde para chamadas de service. No código da sua aplicação, você pode usar um componente de circuit breaker como o Sentinel para implementar estratégias de acionamento no nível da ferramenta. Registre em log o resultado e a latência de cada chamada de ferramenta no Log Service (SLS) e configure regras de alerta baseadas na taxa de falha no ARMS.
BP-REL-12: SLOs de agentes
Justificativa
A "qualidade de service" de um agente não pode ser medida apenas por métricas tradicionais de disponibilidade, como 99,9% de uptime. Um agente pode estar continuamente online (100% de disponibilidade), mas ter uma taxa de conclusão de tarefas de apenas 60% e um tempo médio de conclusão muito acima das expectativas do usuário. Você precisa definir Service Level Objectives (SLOs) específicos para IA para medir a qualidade de service de um agente de forma abrangente.
Implementação
Defina os Service Level Indicators (SLIs) principais, incluindo pelo menos o seguinte:
Taxa de conclusão de tarefas: A porcentagem de tarefas aceitas que o agente conclui com sucesso. Você deve definir claramente "conclusão" — significa que o modelo retornou um resultado ou que o resultado passou em uma validação de qualidade? Recomendamos o último.
Latência de ponta a ponta: O tempo total desde quando um usuário inicia uma requisição até quando recebe o resultado final. Para tarefas de múltiplas etapas, registre a latência total, não apenas a latência de etapas individuais. Defina metas para os percentis P50, P90 e P99.
Tempo até o primeiro token: Em cenários de streaming, este é o tempo que um usuário espera antes de ver o início de uma resposta. Isso afeta significativamente a percepção de capacidade de resposta do usuário.
Pontuação de qualidade da saída: Quantifique a qualidade da saída por meio de avaliação automatizada (como LLM-as-a-Judge) ou feedback do usuário (como avaliações de positivo/negativo). Você pode avaliar a qualidade em diferentes dimensões, incluindo precisão, integridade e relevância.
Defina metas de SLO com base nos seus SLIs. Por exemplo: Taxa de conclusão de tarefas >= 95%, Latência de ponta a ponta P90 <= 30 segundos e Pontuação de qualidade da saída >= 4,0/5,0. Diferencie as metas de SLO com base no cenário de negócio. Um assistente de customer service tem requisitos de latência mais rigorosos, enquanto uma tarefa de análise de dados tem requisitos de precisão mais rigorosos.
Estabeleça um mecanismo de orçamento de erros. Quando a margem do SLO estiver saudável, você pode fazer alterações agressivas, como atualizar um modelo ou otimizar um prompt. Quando o SLO estiver próximo do seu limiar, congele as alterações e foque em melhorar a estabilidade.
Antipadrão: depender apenas de métricas tradicionais de infraestrutura, como utilização de CPU, uso de memória e atividade de processos, para julgar a saúde de um sistema de IA. Isso torna impossível detectar um estado em que o sistema está "online, mas inútil".
Prática da Alibaba Cloud: O Application Real-Time Monitoring Service (ARMS) suporta a definição de métricas de negócio personalizadas para painéis de SLIs e SLOs. Use o Log Service (SLS) para coletar e calcular métricas como taxa de conclusão de tarefas e percentis de latência. Integre com o DingTalk para alertas, de modo que a equipe de plantão seja notificada em tempo real quando um SLO se deteriorar. Com sua compatibilidade com Prometheus, o ARMS permite que você incorpore SLIs de IA em um sistema unificado de observabilidade.
Práticas de estabilidade na Alibaba Cloud
Implantação multi-AZ e dimensionamento elástico do PAI-EAS
O PAI-EAS é o motor de inference service de IA da Alibaba Cloud, fornecendo a infraestrutura principal para a robustez da inferência. Sua capacidade de implantação multi-AZ garante que, se uma zona de disponibilidade falhar, o service faça failover automaticamente para uma AZ saudável e continue operando. Suas políticas de dimensionamento elástico suportam o dimensionamento automático com base em várias condições de acionamento, incluindo utilização de GPU, profundidade da fila de requisições e métricas personalizadas.
Em produção, recomendamos configurar as seguintes políticas: dimensionamento preditivo com base na utilização de memória da GPU para fazer scale-out antes que ocorra um erro de OOM, dimensionamento reativo com base no comprimento da fila de requisições para fazer scale-out imediatamente quando o acúmulo da fila exceder um limiar, e dimensionamento agendado para fazer pré-dimensionamento durante picos de negócio conhecidos. A política de scale-in deve incluir uma janela de proteção para evitar flutuações frequentes de dimensionamento (thrashing) devido à volatilidade do tráfego.
Para otimização do carregamento do modelo, o PAI-EAS suporta pré-carregamento de modelo e compartilhamento de pesos para reduzir os tempos de cold start. Para modelos grandes, você pode usar a quantização de modelo (INT8/INT4) para reduzir a memória de GPU necessária por instância, permitindo que você implante mais réplicas no mesmo hardware.
SLS e ARMS para observabilidade
O Log Service (SLS) e o Application Real-Time Monitoring Service (ARMS) formam juntos a base de observabilidade para sistemas de IA.
O SLS é responsável por coletar, armazenar e analisar volumes massivos de logs e métricas. Os logs principais para um sistema de IA incluem: as contagens de tokens de entrada e saída, latência, identificador do modelo e código de status para cada inferência; o vetor de consulta, número de itens retornados e maior pontuação de similaridade para recuperações da base de conhecimento; o nome da ferramenta, resumo dos parâmetros, status de retorno e latência para chamadas de ferramentas do agente; e a categoria acionada e a disposição para auditorias de segurança de conteúdo. Com esses logs, você pode criar uma visão de observabilidade full-stack do sistema de IA.
O ARMS é responsável pelo monitoramento e alertas em tempo real. Configure regras de alerta para cobrir sinais principais, como uma taxa de erro do inference service excedendo um limiar, um pico repentino na latência de inferência P99, alta utilização sustentada da GPU, uma queda na taxa de conclusão de tarefas e um aumento na taxa de degradação da recuperação. O ARMS é compatível com o ecossistema Prometheus, permitindo sua integração com ferramentas de visualização como o Grafana para criar painéis de SLO de IA.
Juntos, esses dois services permitem um loop completo de troubleshooting, desde "detectar uma anomalia nas métricas" até "localizar a causa raiz nos logs". Quando um alerta do ARMS é acionado, você pode usar consultas correlacionadas no SLS para detalhar os logs de requisições anômalas específicas e analisar se a causa raiz é um problema de modelo, um problema de dados ou um problema de infraestrutura.
AI Gateway e roteamento de health do ALB
O AI Gateway e o Application Load Balancer (ALB), como pontos de entrada de tráfego para AI services, desempenham um papel crítico na garantia de estabilidade. Seu valor principal reside em:
Health checks inteligentes: Ambos suportam a configuração de interfaces de health check personalizadas. Um AI inference service deve expor um endpoint de "deep health check" que não apenas retorne a atividade do processo, mas também verifique se o modelo foi carregado completamente e se a GPU está funcionando corretamente. O AI Gateway e o ALB usam os resultados desses health checks para remover automaticamente instâncias de backend não saudáveis e rotear o tráfego para as saudáveis.
Roteamento ponderado: Em cenários de implantação multi-modelo ou blue-green, o AI Gateway e o ALB suportam a distribuição de tráfego para diferentes grupos de backend por peso. Por exemplo, você pode rotear 10% do tráfego para uma nova versão do modelo para validação canário. Se a validação for bem-sucedida, você pode aumentar gradualmente o peso para 100%. Se ocorrerem problemas, você pode reverter rapidamente o tráfego para a versão antiga.
Tolerância a falhas no nível da conexão: Quando uma instância de backend retorna um erro, o AI Gateway e o ALB podem tentar novamente a requisição automaticamente em outra instância saudável com base em uma política de retentativa configurável. Isso permite que a aplicação suporte falhas de instância única de forma transparente.
Esses três componentes trabalham em conjunto: o PAI-EAS fornece robustez na camada de computação de inferência, o SLS e o ARMS fornecem observabilidade e detecção de falhas orientada por alertas, e o ALB fornece tolerância a falhas e controle de roteamento na camada de tráfego. Juntos, eles formam uma linha de defesa completa para a estabilidade do sistema de IA.