O que é Refém de um Provedor?
Refém de um Provedor (Single Provider Dependency) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Operação. Quando a API do modelo cai ou fica lenta, o produto inteiro para junto.
Conteúdo da trilha
Refém de um Provedor
Single Provider Dependency
Refém de um Provedor (Single Provider Dependency) é um smell de IA, ou seja, um sinal de problema em sistemas com LLM, do grupo Operação. Quando a API do modelo cai ou fica lenta, o produto inteiro para junto.
- Elemento
- 37/37
- Nível
- Intermediário
- Leitura
- 4 min
- Atualizado
Como reconhecer
O assistente de voz de um call center depende de um único provedor de modelo. Num dia de pico, o provedor teve instabilidade. O registro do incidente (anonimizado):
14:02 latência p95 do modelo sobe de 1,1 s para 9,8 s
14:05 taxa de erro 503 em 34%
14:06 ligações começam a cair por timeout no URA
14:30 time decide desligar o assistente; todas as ligações vão para a fila humana
14:31 fila humana: 412 pessoas aguardando, tempo médio 38 min
16:10 provedor normaliza; assistente religadoO sistema não tinha um caminho alternativo. Não havia outro modelo configurado, nem um modo degradado, nem um corte automático. A decisão de desligar foi manual, depois de meia hora de ligações perdidas.
No WhatsApp do mesmo banco, o bot de Pix teria o mesmo destino: silêncio no canal, fila humana, cliente achando que o pagamento falhou. Provedores de modelo já tiveram incidentes públicos longos o bastante para derrubar quem não tinha plano B. Em novembro de 2023, uma queda da API da OpenAI tirou do ar uma fatia visível dos produtos que dependiam só dela.
Sinais de Refém de um Provedor:
- Todo o produto depende de um único modelo, num único provedor, numa única região.
- Não existe plano para quando a API fica lenta, devolve erros ou atinge o limite de taxa.
- Timeouts são altos ou inexistentes, e as requisições ficam presas.
- Não há modo degradado (resposta simplificada, fila, mensagem fixa).
- Ninguém testou o sistema com o provedor fora do ar.
flowchart LR
U(["1. Ligações"]):::io --> A(["2. Assistente"]):::llm
A --> P["3. Provedor único"]:::tool
P -->|"lento ou fora"| X(["4. Produto inteiro para"]):::io
- Todo o tráfego chega ao assistente.
- O assistente depende de uma única API.
- Quando a API degrada, não há desvio.
- O produto para junto com ela.
Por que acontece
- Um provedor basta no começo. A disponibilidade é alta, e falhas parecem raras.
- Formato do provedor espalhado. Trocar de modelo exige reescrever o código, então ninguém prepara um segundo. Veja Vazamento de Formato do Provedor.
- Prompts ajustados a um modelo. Um modelo reserva daria respostas diferentes, sem avaliação prévia.
- Falha nunca foi ensaiada. Ninguém sabe o que o sistema faz quando a API não responde.
Erro comum: achar que outra região resolve
Mover o mesmo modelo para outra região cobre um data center. Não cobre conta suspensa, limite de taxa global, bug de API nem incidente no provedor inteiro. Outra região é um bom primeiro degrau. Não é independência.
Quanto custa ignorar
- Indisponibilidade total durante incidentes do provedor.
- Efeito cascata. Requisições presas consomem conexões e derrubam outros serviços.
- Clientes perdidos em canais de tempo real, como voz e chat.
- Decisões no pânico. Desligar tudo na mão, sem critério.
O pior minuto do incidente acima não foi o 503. Foi o intervalo 14:06 a 14:30, em que o produto ainda mandava tráfego para um provedor que já não respondia a tempo, enquanto a URA derrubava ligação atrás de ligação.
| Peça | O que evita | O que não evita |
|---|---|---|
| Timeout curto | Workers presos | Um provedor que responde errado rápido |
| Disjuntor | Continuar martelando o doente | Qualidade ruim do reserva |
| Outra região | Queda local | Incidente na conta ou na API global |
| Reserva avaliado | Ficar mudo quando o principal cai | Prompt e schema diferentes, se você não mediu |
Tratamento
| Refatoração | Escolha quando |
|---|---|
| Adicionar Caminho de Fallback | Sempre que o produto não pode parar. Defina o que acontece quando o modelo falha: outro modelo ou provedor avaliado, modo degradado, fila ou passagem para humano, com timeouts e um disjuntor que corta automaticamente. |
A ordem que de fato segura o canal:
- Timeout curto no cliente HTTP, compatível com o SLA da URA ou do WhatsApp. Sem isso, nada abaixo dispara.
- Disjuntor. Depois de N falhas ou de latência acima do limiar, pare de mandar tráfego ao provedor doente por um intervalo.
- Caminho degradado imediato. Mensagem fixa, fila, ou humano. O canal não some.
- Modelo reserva avaliado. Outro provedor ou outro modelo, com o prompt dele e o eval dele, já rodado. Sem eval, a troca é um segundo incidente.
Ensaie a falha: derrube a API de propósito num ambiente de teste e veja se o disjuntor abre, se o reserva responde no formato certo e se a URA não cai. O ensaio é o único jeito de saber se o plano existe de verdade.
O que você ganha
- O produto continua funcionando, talvez com qualidade menor, durante incidentes.
- Cortes automáticos em segundos, não decisões manuais em meia hora.
- Um modelo reserva já avaliado, sem surpresa na hora da troca.
- Um ensaio de falha que mostra o comportamento real.
Quando ignorar
- Tarefas assíncronas que podem esperar. Um job noturno pode simplesmente tentar de novo mais tarde.
- Ferramentas internas não críticas. Se ninguém se prejudica com uma hora de indisponibilidade, um timeout e uma mensagem clara bastam.
É esse smell?
Perguntas rápidas
Como corrigir Refém de um Provedor?
Com Adicionar Caminho de Fallback. Cada refatoração traz o passo a passo seguro, com eval antes e depois.
Onde Refém de um Provedor aparece na prática?
Nos cenários reais Assistente de voz de call center.
Para ir além
Relações
- Refatorações que tratam 1
- Aparece nos cenários 1
- Aparece nas trilhas 1