SLOs para Funcionalidades de IA

A engenharia de confiabilidade tradicionalmente se concentra no comportamento da infraestrutura: tempo de atividade, latência, taxas de erro, saturação. Para funcionalidades de IA, os usuários muitas vezes não vivenciam falhas como HTTP 500s — eles as vivenciam como respostas erradas, saídas inseguras, comportamento inconsistente ou decisões que se degradam ao longo do tempo. “SLOs para Funcionalidades de IA” estende os conceitos de Engenharia de Confiabilidade de Site (SRE, Site Reliability Engineering) — SLIs, SLOs e orçamentos de erro — para definir metas de confiabilidade para o comportamento de IA, não apenas para servidores e endpoints.

Este artigo explica como definir metas mensuráveis de confiabilidade para funcionalidades alimentadas por aprendizado de máquina (machine learning) e LLMs (Large Language Models), como instrumentá-las em produção e como operacionalizá-las com monitoramento, alertas, lançamentos e resposta a incidentes.

O que significa “SLOs para Funcionalidades de IA”

Definições rápidas (termos de SRE)

  • SLI (Indicador de Nível de Serviço, Service Level Indicator): Uma métrica mensurável do comportamento do serviço (ex.: latência p95, taxa de sucesso de tarefa).
  • SLO (Objetivo de Nível de Serviço, Service Level Objective): Uma meta para um SLI ao longo de uma janela de tempo (ex.: “≥ 99% das requisições têm latência p95 < 300 ms ao longo de 28 dias”).
  • Orçamento de erro (error budget): Inconfiabilidade permitida: 1 - SLO. Se seu SLO é 99%, seu orçamento de erro mensal é 1% de “eventos ruins”.

Em sistemas de IA, a mudança-chave é que você define eventos “bons” e “ruins” não apenas por respostas do sistema, mas também pelo comportamento e pelos resultados do modelo.

Por que SLOs apenas de infraestrutura são insuficientes para funcionalidades de IA

Uma funcionalidade de IA pode estar “verde” em métricas de infraestrutura e ainda assim estar quebrada:

  • Um modelo de recomendação retorna rapidamente (baixa latência), mas se torna irrelevante devido a deriva.
  • Um modelo de fraude está disponível, mas começa a perder novos padrões de fraude.
  • Um chatbot de LLM responde com 200 OK, mas alucina ou viola políticas.
  • Um pipeline de geração aumentada por recuperação (RAG, retrieval-augmented generation) é rápido, mas a recuperação retorna documentos errados.

Confiabilidade para funcionalidades de IA é, portanto, multidimensional:

  • Confiabilidade operacional: latência, disponibilidade, timeouts.
  • Confiabilidade comportamental: correção, utilidade, consistência, fundamentação.
  • Confiabilidade de segurança/conformidade: aderência a políticas, prevenção de vazamento de PII (Personally Identifiable Information).
  • Confiabilidade de robustez: desempenho sob mudança de distribuição, entradas adversariais, consultas de cauda longa.

Este artigo foca em SLOs comportamentais, reconhecendo que eles devem coexistir com SLOs clássicos de SRE.

Ideia central: definir “eventos bons” em termos de resultados para o usuário

Um bom SLO de IA começa definindo a unidade de comportamento:

  • “Uma predição do modelo”
  • “Um turno de chat”
  • “Uma conversa”
  • “Uma decisão de moderação”
  • “Um fluxo de ponta a ponta (meta do usuário concluída)”

Depois definir:

  1. O que conta como sucesso?
  2. Como medimos isso em produção?
  3. Em qual janela e segmento?
  4. Quais ações são disparadas quando o SLO é violado?

Esse enquadramento evita um modo comum de falha: otimizar métricas substitutas (loss, perplexity, acurácia offline) que não refletem utilidade em produção.

Escolhendo SLIs para comportamento de IA

SLIs comportamentais variam por tipo de produto. Um programa robusto de SLO normalmente inclui um pequeno conjunto de SLIs bem definidos, em vez de dezenas de métricas medidas de forma frouxa.

1) SLIs de sucesso de tarefa / utilidade (orientados ao resultado do usuário)

Frequentemente são os mais valiosos — e os mais difíceis de medir.

Exemplos:

  • Assistente de suporte ao cliente: “Problema resolvido sem escalonamento humano”
  • Copiloto para código: “Taxa de sugestão aceita” ou “melhoria no tempo até merge”
  • Busca / ranqueamento: “Clique bem-sucedido” ou “taxa de reformulação”
  • Extração de documentos: “Taxa de correspondência exata por campo”

Formas típicas:

  • Taxa de sucesso binária: % de unidades com success == true
  • Limiar de pontuação: % de unidades com quality_score ≥ T
  • Erro de regressão: MAE/RMSE para predições numéricas
  • Métricas de ranqueamento: NDCG, MRR (frequentemente offline; proxies online são comuns)

Nota prática: resultados do usuário frequentemente têm rótulos atrasados (horas a semanas), então você normalmente os combina com “indicadores antecedente” mais rápidos (ver abaixo).

2) SLIs de correção e qualidade (ground truth ou adjudicados)

Para muitas tarefas de ML você pode medir qualidade com dados rotulados:

  • Classificação: acurácia, precisão/recall, F1 (cuidado com desbalanceamento)
  • Detecção: taxa de falso positivo em um recall fixo
  • Extração: correspondência exata em nível de token/campo
  • Sumarização: avaliações humanas, avaliação baseada em rubrica

Para funcionalidades de LLM em que “correção” é difusa:

  • Pontuação por rubrica humana (padrão-ouro, mas cara)
  • Avaliações de LLM como juiz (LLM-as-judge) com calibração e checagens pontuais (útil, mas precisa ser validado)
  • Fundamentação / correção de citação para RAG: “Resposta suportada por passagens recuperadas”

Isso se conecta fortemente a Avaliação em Produção e Observabilidade para Apps de LLM.

3) SLIs de segurança e política (prevenção de danos)

Segurança frequentemente é uma dimensão de confiabilidade de primeira classe.

Exemplos:

  • Taxa de violação de toxicidade (por política)
  • Taxa de conteúdo proibido (instruções de autoagressão, ódio etc.)
  • Taxa de vazamento de PII (ex.: saída do modelo contém identificadores sensíveis)
  • Taxa de suscetibilidade a jailbreak em um conjunto de testes de red team (offline) + detecções em produção

Esses SLIs frequentemente exigem:

  • definições de política curadas,
  • classificadores automatizados,
  • revisão humana para casos limítrofes,
  • práticas cuidadosas de logging (Privacidade no Logging).

4) SLIs de robustez e consistência (estabilidade sob variação)

Funcionalidades de IA podem degradar de forma sutil:

  • comportamento diferente para a mesma intenção formulada de maneiras diferentes,
  • regressões em segmentos de cauda longa,
  • instabilidade entre versões de modelo.

Exemplos:

  • Consistência de paráfrase: equivalência de saída entre paráfrases
  • Taxa de regressão: % do tráfego canário em que a qualidade diminuiu vs baseline
  • Calibração de confiança: ex.: Brier score ou ECE (para modelos probabilísticos)

5) SLIs de latência, disponibilidade e custo (ainda necessários)

SLOs de comportamento de IA não substituem métricas clássicas de SRE — eles as complementam:

  • latência p50/p95/p99 por endpoint ou por etapa do pipeline
  • taxa de timeout, taxa de erro de chamada de ferramenta
  • custo por requisição / tokens por tarefa (importante para LLMs)

Veja também Serving de LLM, Serving de Modelos e Custo/Desempenho.

Como definir um SLO comportamental (passo a passo)

Etapa 1: Especificar a unidade e o resultado voltados ao usuário

Seja explícito sobre a unidade e o valor para o usuário.

Exemplo (assistente de suporte com LLM):

  • Unidade: “conversa”
  • Resultado: “problema do usuário resolvido sem tomada de controle por humano e sem violação de política”

Etapa 2: Definir eventos “bons” vs “ruins”

SLOs exigem uma definição clara de “evento bom”.

Padrões comuns:

Padrão A: Pontuação com limiar

  • Bom se quality_score >= 0.8
  • Ruim caso contrário

Padrão B: Porta com múltiplas condições

  • Bom se:
    • resolved == true
    • E policy_violation == false
    • E p95_latency < 2.0s

Padrão C: Falhas orçadas por tipo

  • Permitir uma pequena taxa de “problemas menores”
  • Limitar estritamente “danos severos”

Isso frequentemente é implementado como múltiplos SLOs (recomendado) em vez de um único score ponderado.

Etapa 3: Escolher método de medição e fonte do rótulo

Opções (frequentemente combinadas):

  • Ground truth direto (ex.: rótulos verificados de fraude em transações)
  • Revisão humana (amostragem + rubrica)
  • Sinais do usuário (curtida/não curtida, abandono)
  • Críticas automatizadas (LLM como juiz, checagens heurísticas)
  • Traços do sistema (sucesso de ferramenta, taxa de acerto de recuperação)

Se seu rótulo é atrasado, defina:

  • um SLO de indicador antecedente (rápido, imperfeito),
  • e um SLO de indicador defasado (lento, alta confiança).

Etapa 4: Escolher janela, agregação e segmentação

  • Janela: 7/28/90 dias dependendo do volume de tráfego e da tolerância à variância.
  • Agregação: média, percentil ou “% de eventos bons”.
  • Segmentação: definir SLOs por coorte onde o comportamento difere:
    • geografia, idioma,
    • nível do cliente,
    • tipo de consulta (head vs tail),
    • domínios sensíveis (médico, jurídico).

A segmentação é crucial: um 99% geral pode ocultar uma experiência de 90% para um segmento minoritário.

Etapa 5: Definir metas com base em risco, baselines e orçamentos de erro

As metas devem refletir:

  • expectativas do usuário,
  • impacto no negócio da falha,
  • viabilidade e custo,
  • risco de segurança.

Para danos de alta severidade, você pode precisar de taxas toleradas extremamente baixas (ex.: 0,01%), e provavelmente usará controles mais rígidos (guardrails, abstenção, fallbacks).

Etapa 6: Conectar SLOs à ação

Um SLO só é operacional se orientar decisões:

  • podemos lançar um novo modelo?
  • devemos fazer rollback?
  • devemos interromper experimentos?
  • alocamos tempo de engenharia vs entregar funcionalidades?

Essa é a “política de orçamento de erro”: quando você consome o orçamento rápido demais, você prioriza trabalho de confiabilidade.

Exemplos práticos de SLOs para funcionalidades de IA

Exemplo 1: Assistente de perguntas e respostas corporativo baseado em RAG

Objetivo: fornecer respostas precisas, com citações, a partir de documentos internos.

SLIs comportamentais

  • Taxa de resposta fundamentada: % de respostas em que todas as afirmações factuais são suportadas por fontes recuperadas (revisão humana ou auxiliada por juiz)
  • Correção de citação: % de citações que de fato contêm a afirmação citada
  • Correção de abstenção: % de casos em que o assistente corretamente diz “não sei / não encontrei” quando a recuperação é insuficiente

SLOs possíveis

  • Taxa de resposta fundamentada ≥ 97% ao longo de 28 dias (avaliação por amostragem)
  • Correção de citação ≥ 99% ao longo de 28 dias
  • Taxa de alucinação de alta severidade ≤ 0,1% ao longo de 28 dias (métrica de dano mais rígida)
  • Latência p95 ponta a ponta ≤ 3,5s ao longo de 28 dias

Dicas de instrumentação

  • Rastrear cada requisição por recuperação → reranqueamento → geração (ver Observabilidade para Apps de LLM).
  • Registrar IDs de documentos recuperados + passagens + saída do modelo (com controles de privacidade).
  • Criar um pipeline de amostragem para adjudicação humana.

Alavanca operacional

  • Se o SLO de fundamentação queimar: apertar filtros de recuperação, aumentar top-k, melhorar chunking ou impor recusa quando a confiança for baixa (um padrão de Padrões de Design de Sistemas de LLM).

Exemplo 2: Modelo de detecção de fraude (classificação binária)

Objetivo: capturar fraude mantendo baixas as recusas falsas.

SLIs comportamentais

  • Recall em fraude confirmada (com rótulos atrasados)
  • Taxa de falso positivo (transações legítimas bloqueadas incorretamente)
  • Perda evitada ponderada por valor

SLOs

  • Recall de fraude ≥ 92% ao longo de 30 dias (indicador defasado)
  • Taxa de falso positivo ≤ 0,35% ao longo de 30 dias
  • Disponibilidade de decisão do modelo ≥ 99,95% ao longo de 30 dias (infra)

Nuance importante

  • Como os rótulos chegam tarde, você pode adicionar indicadores antecedente:
    • limiares de deriva de features,
    • estabilidade da distribuição de scores,
    • taxa de escalonamento para fila de revisão.

Isso se conecta naturalmente a Monitoramento e Validação de Dados.

Exemplo 3: Classificador de moderação de conteúdo

Objetivo: aplicar a política com bloqueio excessivo mínimo.

SLIs comportamentais

  • Taxa de falha em detectar violação de política (falsos negativos) em amostras auditadas
  • Taxa de bloqueio excessivo (falsos positivos) em amostras apeladas ou auditadas
  • Tempo até decisão (latência de moderação) para experiência do usuário

SLOs

  • Taxa de falha em política severa ≤ 0,05% (auditado, 28 dias)
  • Taxa de bloqueio excessivo ≤ 0,5% (auditado, 28 dias)
  • Latência p95 de moderação ≤ 500ms (28 dias)

Alavanca operacional

  • Usar roteamento em camadas: modelo rápido para a maioria, modelo mais pesado/revisão humana para casos incertos (padrão de cascata/roteador).

Exemplo 4: Assistente de programação com LLM em uma IDE

Objetivo: acelerar a codificação sem introduzir bugs ou código inseguro.

SLIs comportamentais

  • Taxa de aceitação (proxy de utilidade)
  • Taxa de falha de compilação/teste pós-aceitação (regressão de qualidade)
  • Taxa de violação de lint de segurança em sugestões aceitas

SLOs

  • Taxa de aceitação ≥ 25% (janela de 7 dias, segmentado por linguagem)
  • Taxa de falha de teste após aceitação ≤ 2%
  • Taxa de sugestão insegura de alta severidade ≤ 0,1% (auditado)

Este é um bom exemplo de combinar um indicador antecedente (aceitação) com métricas de guardrail (testes/segurança).

Projetando SLOs para IA: padrões que funcionam

Use múltiplos SLOs em vez de um score combinado

Um único score composto é tentador, mas perigoso:

  • ele esconde trade-offs,
  • é mais fácil de “burlar”,
  • é mais difícil de depurar.

Uma abordagem melhor é um pequeno conjunto de SLOs ortogonais:

  • SLO de utilidade (ajuda?)
  • SLO de segurança (prejudica?)
  • SLO de latência/disponibilidade (responde?)

Prefira SLIs “% de eventos bons” para sistemas não determinísticos

Para LLMs, as saídas variam; avaliar cada requisição é caro. “% de eventos bons” funciona bem com amostragem:

  • amostrar N requisições/dia por segmento,
  • pontuar com uma rubrica (humana ou do juiz),
  • calcular taxa de aprovação e intervalos de confiança.

Defina níveis de severidade e orçamentos separados

Nem todas as falhas são iguais. Um padrão prático:

  • P0 (severo): violação de política, instrução perigosa, vazamento de PII
  • P1 (maior): resposta materialmente errada, má classificação com alto impacto
  • P2 (menor): problemas estilísticos, pequena irrelevância

Depois defina SLOs por severidade:

  • taxa de P0 ≤ 0,01%
  • taxa de P1 ≤ 0,5%
  • taxa de P2 ≤ 3%

Isso alinha o trabalho de confiabilidade com gestão de risco.

Crie uma hierarquia de SLOs (ponta a ponta e SLOs de componentes)

SLOs ponta a ponta refletem a experiência do usuário; SLOs de componentes ajudam equipes a “donas” de partes.

Exemplo (assistente RAG):

  • Ponta a ponta: taxa de resposta fundamentada, sucesso de tarefa
  • Componente de recuperação: “documento relevante no top-5 ≥ 95%” (auditoria offline/online)
  • Componente de ferramentas: taxa de sucesso de chamada de ferramenta ≥ 99,9%
  • Componente do modelo: acurácia de recusa, taxa de aprovação de segurança

Rastreamento e atribuição são fundamentais aqui (Observabilidade para Apps de LLM).

Medição e rotulagem em produção

Estratégias de amostragem

Como a avaliação completa é cara:

  • Amostragem aleatória uniforme (simples, sem viés)
  • Amostragem estratificada (garantir cobertura para segmentos de cauda longa)
  • Amostragem por gatilho (superamostrar casos de alto risco: baixa confiança, consultas próximas a política)

Avaliação humana e design de rubricas

Uma rubrica utilizável é:

  • específica (critérios claros de aprovação/reprovação),
  • consistente entre revisores,
  • alinhada ao valor para o usuário e à política.

Acompanhe concordância entre avaliadores. Para produtos de LLM, pode haver deriva de rubrica à medida que expectativas do produto mudam.

LLM como juiz: útil, mas precisa ser validado

Juízes de LLM podem escalar avaliação, mas:

  • podem ter viés a favor de respostas verbosas,
  • podem perder erros factuais sutis,
  • podem se correlacionar com o modelo avaliado.

Boa prática:

  • calibrar contra rótulos humanos,
  • manter um “conjunto ouro” para revalidação periódica,
  • tratar SLIs baseados em juiz como proxies a menos que sejam comprovadamente confiáveis.

Lidando com ground truth atrasado

Para tarefas como fraude ou previsão de churn:

  • definir SLOs defasados sobre rótulos confirmados,
  • definir SLOs antecedente sobre deriva e resultados proxy,
  • criar políticas de alerta que reflitam incerteza (evitar pager em sinais iniciais ruidosos).

Operacionalizando SLOs de IA

Alertas: acione pager por sintomas, não por toda queda de métrica

Como métricas de qualidade de IA são ruidosas, alertas exigem cuidado:

  • Use alertas por taxa de queima: “Estamos consumindo o orçamento de erro rápido demais?”
  • Exija tamanhos mínimos de amostra / limites de confiança.
  • Acione pager principalmente para violações de segurança de alta severidade ou falhas duras; crie ticket para tendências mais lentas.

Portões de release e rollbacks

Conecte SLOs a CI/CD para Modelos e Registro de Modelos:

  • Pré-release: avaliar em suítes fixas e testes adversariais
  • Canário: rotear pequeno tráfego, medir SLIs por segmento
  • Rollback automático: se SLO de segurança for violado ou a taxa de queima exceder limiar
  • Promover apenas se SLOs ponta a ponta forem atendidos

Runbooks e mitigações (o que fazer quando SLOs queimam)

Mitigações comuns:

Exemplo: uma especificação de SLO (ilustrativa)

Muitas equipes codificam definições de SLO como config para que sejam revisáveis e versionadas.

feature: enterprise-rag-assistant
window_days: 28

slos:
  - name: grounded_answer_rate
    sli:
      type: sampled_rubric
      sample_size_per_day: 400
      pass_condition: "grounded == true"
      segment_by: ["language", "tenant_tier"]
    objective: 0.97

  - name: severe_hallucination_rate
    sli:
      type: sampled_rubric
      pass_condition: "severe_hallucination == false"
    objective: 0.999  # 0.1% allowed severe hallucinations

  - name: p95_latency_seconds
    sli:
      type: tracing_metric
      metric: "e2e_latency_seconds_p95"
    objective: 3.5
    comparison: "<="

And a simple “good event” computation from logs might look like:

def good_event(row):
    return (
        row["policy_violation"] is False
        and row["grounded"] is True
        and row["e2e_latency_ms"] <= 3500
    )

good_rate = sum(good_event(r) for r in rows) / len(rows)

Armadilhas comuns (e como evitá-las)

Lei de Goodhart: métricas viram metas

Se você definir “taxa de joinha” como SLO principal, equipes podem otimizar persuasão em vez de correção.

Mitigação:

  • combinar métricas de utilidade com métricas de correção/segurança,
  • auditar uma amostra com revisão humana,
  • manter SLOs separados por severidade.

Métricas offline mascaradas como confiabilidade

Avaliação offline é necessária, mas não suficiente. Mudança de distribuição quebra modelos de formas que conjuntos de teste não capturam.

Mitigação:

Agregados escondem falhas de cauda longa

A taxa geral de aprovação pode parecer boa enquanto segmentos específicos de usuários sofrem.

Mitigação:

  • reportar SLO por segmento (idioma, região, domínio),
  • definir SLOs explícitos para segmentos de alto risco.

“Verdade” indefinida para tarefas subjetivas

Algumas tarefas (estilo de escrita, brainstorming) não têm uma única saída correta.

Mitigação:

  • definir critérios de “utilidade” e “dano” baseados em rubrica,
  • depender mais de proxies de resultado do usuário, mas validá-los.

Logging cria risco de privacidade

SLOs comportamentais frequentemente exigem logs mais ricos (prompts, documentos, saídas).

Mitigação:

  • minimizar conteúdo sensível armazenado,
  • aplicar redação/tokenização,
  • restringir acesso e retenção (Privacidade no Logging).

Como SLOs moldam o design de sistemas de IA

Quando SLOs comportamentais são explícitos, decisões de arquitetura ficam mais claras:

  • Se “fundamentação ≥ 97%” é obrigatório, você investe em qualidade de recuperação, citações e lógica de recusa — não apenas em modelos maiores.
  • Se “violações severas de política ≤ 0,01%” é obrigatório, você constrói segurança em camadas: classificadores, restrições de prompt, bloqueio de ferramentas e escalonamento humano.
  • Se “sucesso de tarefa ≥ 90%” é obrigatório, você projeta fluxos ponta a ponta com confiabilidade de ferramentas, não apenas qualidade de prompt.

Por isso SLOs para funcionalidades de IA ficam na interseção de Padrões de Design de Sistemas de LLM, Monitoramento e Avaliação em Produção.

Resumo: como é o “bom”

Uma prática madura de SLO para funcionalidades de IA normalmente tem:

  • Um pequeno conjunto de SLOs comportamentais ponta a ponta ligados a resultados do usuário e prevenção de danos
  • SLOs de componentes de suporte para recuperação, ferramentas, inferência do modelo e pipelines
  • Medição robusta (amostragem, segmentação, juízes/humanos calibrados, tratamento de rótulos atrasados)
  • Políticas de orçamento de erro claras que governam lançamentos, rollbacks e priorização
  • Observabilidade forte e logging com consciência de privacidade

O resultado é uma confiabilidade que corresponde a como os usuários vivenciam a IA: não apenas “o serviço respondeu”, mas “o serviço se comportou bem”.