A Marcha dos Nove de Karpathy mostra por que 90% de confiabilidade da IA ​​não está nem perto do suficiente

“Quando você recebe uma demonstração e algo funciona 90% das vezes, são apenas os primeiros nove.” – Andrej Karpatia

A “Marcha dos Nove” enquadra uma realidade de produção comum: você pode alcançar os primeiros 90% de confiabilidade com uma demonstração forte, e cada nove adicionais geralmente exigem um esforço de engenharia comparável. Para equipes empresariais, a distância entre “normalmente funciona” e “opera como software confiável” determina a adoção.

A matemática composta por trás da Marcha dos Nove

“Cada nove é a mesma quantidade de trabalho.” -Andréj Karpathy

Fluxos de trabalho agentes agravam falhas. Um fluxo empresarial típico pode incluir: análise de intenção, recuperação de contexto, planejamento, uma ou mais chamadas de ferramenta, validação, formatação e registro de auditoria. Se um fluxo de trabalho tiver n etapas e cada etapa for bem-sucedida com probabilidade po sucesso de ponta a ponta é aproximadamente p^n.

Em um fluxo de trabalho de 10 etapas, o sucesso de ponta a ponta aumenta devido às falhas de cada etapa. Interrupções correlacionadas (autenticação, limites de taxa, conectores) dominarão, a menos que você reforce as dependências compartilhadas.

Defina confiabilidade como SLOs mensuráveis

“Faz muito mais sentido gastar um pouco mais de tempo para ser mais concreto em suas instruções.” – Andrej Karpatia

As equipes alcançam resultados mais elevados transformando a confiabilidade em objetivos mensuráveis ​​e, em seguida, investindo em controles que reduzem a variância. Comece com um pequeno conjunto de SLIs que descrevem o comportamento do modelo e o sistema circundante:

• Taxa de conclusão do fluxo de trabalho (sucesso ou escalonamento explícito).

• Taxa de sucesso de chamada de ferramenta dentro do tempo limite, com validação de esquema rigorosa em entradas e saídas.

• Taxa de saída válida para esquema para cada resposta estruturada (JSON/argumentos).

• Taxa de conformidade com políticas (PII, segredos e restrições de segurança).

• Latência ponta a ponta p95 e custo por fluxo de trabalho.

• Taxa de fallback (modelo mais seguro, dados em cache ou revisão humana).

Defina metas de SLO por nível de fluxo de trabalho (impacto baixo/médio/alto) e gerencie um orçamento de erros para que os experimentos permaneçam controlados.

Nove alavancas que adicionam noves de forma confiável

1) Restringir a autonomia com um gráfico de fluxo de trabalho explícito

A confiabilidade aumenta quando o sistema tem estados limitados e tratamento determinístico para novas tentativas, tempos limite e resultados terminais.

• As chamadas de modelo ficam dentro de uma máquina de estado ou DAG, onde cada nó define ferramentas permitidas, número máximo de tentativas e um predicado de sucesso.

• Persista o estado com chaves idempotentes para que as novas tentativas sejam seguras e depuráveis.

2) Fazer cumprir contratos em todas as fronteiras

A maioria das falhas de produção começa como desvio de interface: JSON malformado, campos ausentes, unidades erradas ou identificadores inventados.

• Use JSON Schema/protobuf para cada saída estruturada e valide no lado do servidor antes da execução de qualquer ferramenta.

• Use enums, IDs canônicos e normalize o tempo (ISO-8601 + fuso horário) e unidades (SI).

3) Validadores de camada: sintaxe, semântica, regras de negócio

A validação do esquema captura a formatação. As verificações semânticas e de regras de negócios evitam respostas plausíveis que quebram os sistemas.

• Verificações semânticas: integridade referencial, limites numéricos, verificações de permissão e junções determinísticas por ID, quando disponíveis.

• Regras de negócios: aprovações para ações de gravação, restrições de residência de dados e restrições de nível de cliente.

4) Rota por risco usando sinais de incerteza

Ações de alto impacto merecem maior garantia. O roteamento baseado em risco transforma a incerteza em um recurso do produto.

• Use sinais de confiança (classificadores, verificações de consistência ou um verificador de segundo modelo) para decidir o roteamento.

• Garanta etapas arriscadas por trás de modelos mais fortes, verificação adicional ou aprovação humana.

5) Chamadas de ferramentas de engenharia como sistemas distribuídos

Conectores e dependências geralmente dominam as taxas de falha em sistemas agentes.

• Aplique tempos limite por ferramenta, espera com jitter, disjuntores e limites de simultaneidade.

• Versão de esquemas de ferramentas e validação de respostas de ferramentas para evitar quebras silenciosas quando as APIs mudam.

6) Torne a recuperação previsível e observável

A qualidade da recuperação determina o quão fundamentada será sua aplicação. Trate-o como um produto de dados versionado com métricas de cobertura.

• Rastreie a taxa de recuperação vazia, a atualização do documento e a taxa de acertos em consultas rotuladas.

• O índice de envio muda com canários, para que você saiba se algo irá falhar antes de falhar.

• Aplique acesso e redação com privilégios mínimos na camada de recuperação para reduzir o risco de vazamento.

7) Construa um pipeline de avaliação de produção

Os últimos noves dependem da localização rápida de falhas raras e da prevenção de regressões.

• Mantenha um conjunto dourado orientado a incidentes do tráfego de produção e execute-o em cada mudança.

• Execute o modo sombra e canários A/B com reversão automática em regressões SLI.

8) Investir em observabilidade e resposta operacional

Quando as falhas se tornam raras, a velocidade do diagnóstico e da remediação torna-se o fator limitante.

• Emita rastreamentos/extensões por etapa, armazene prompts editados e E/S de ferramentas com fortes controles de acesso e classifique cada falha em uma taxonomia.

• Use runbooks e alternâncias de “modo de segurança” (desative ferramentas arriscadas, alterne modelos, exija aprovação humana) para mitigação rápida.

9) Envie um controle deslizante de autonomia com alternativas determinísticas

Os sistemas falíveis precisam de supervisão e o software de produção precisa de uma forma segura de aumentar a autonomia ao longo do tempo. Trate a autonomia como um botão, não como um interruptor, e torne o caminho seguro o padrão.

• Padrão para ações somente leitura ou reversíveis, exige confirmação explícita (ou fluxos de trabalho de aprovação) para gravações e operações irreversíveis.

• Crie substitutos determinísticos: respostas somente de recuperação, respostas em cache, manipuladores baseados em regras ou escalonamento para revisão humana quando a confiança estiver baixa.

• Exponha modos de segurança por locatário: desative ferramentas/conectores arriscados, force um modelo mais forte, reduza a temperatura e reduza os tempos limite durante incidentes.

• Projete transferências retomáveis: persista o estado, mostre o plano/diferença e deixe um revisor aprovar e retomar a etapa exata com uma chave de idempotência.

Esboço de implementação: um wrapper de etapa limitado

Um pequeno wrapper em torno de cada etapa do modelo/ferramenta converte a imprevisibilidade em controle orientado por políticas: validação estrita, novas tentativas limitadas, tempos limite, telemetria e fallbacks explícitos.

def run_step(nome, tentativa_fn, validar_fn, *, max_attempts=3, timeout_s=15):

# rastreia todas as tentativas em um período

span = start_span(nome)

para tentativa em range(1, max_attempts + 1):

tentar:

# latência limitada para que uma etapa não possa paralisar o fluxo de trabalho

com prazo (timeout_s):

saída = tentativa_fn()

# gate: esquema + semântica + invariantes de negócio

validar_fn(fora)

# caminho de sucesso

métrica ("etapa_sucesso"nome, tentativa=tentativa)

retornar

exceto (TimeoutError, UpstreamError) como e:

# transitório: tente novamente com jitter para evitar tempestades de novas tentativas

span.log({"tentar": tentar, "errar": rua(s)})

dormir(jittered_backoff(tentativa))

exceto ValidationError como e:

# saída ruim: tente novamente uma vez no modo “mais seguro” (temperatura mais baixa/prompt mais rigoroso)

span.log({"tentar": tentar, "errar": rua(s)})

saída = tentativa_fn(modo="mais seguro")

# fallback: mantém o sistema seguro quando as novas tentativas se esgotam

métrica ("step_fallback"nome)

retornar EscalateToHuman(motivo=f"{nome} falhou")

Por que as empresas insistem nos últimos noves

As lacunas de confiabilidade se traduzem em riscos comerciais. Pesquisa global de 2025 da McKinsey relata que 51% das organizações que usam IA experimentaram pelo menos uma consequência negativa e quase um terço relatou consequências ligadas à imprecisão da IA. Esses resultados impulsionam a demanda por medições, proteções e controles operacionais mais fortes.

Lista de verificação de encerramento

• Escolha um fluxo de trabalho principal, defina seu SLO de conclusão e os códigos de status do terminal do instrumento.

• Adicione contratos + validadores em torno de cada saída de modelo e entrada/saída de ferramenta.

• Trate os conectores e a recuperação como um trabalho de confiabilidade de primeira classe (tempos limite, disjuntores, canários).

• Encaminhe ações de alto impacto por caminhos de maior garantia (verificação ou aprovação).

• Transforme cada incidente em um teste de regressão em seu conjunto dourado.

Os noves chegam por meio de engenharia disciplinada: fluxos de trabalho limitados, interfaces rígidas, dependências resilientes e ciclos rápidos de aprendizado operacional.

Nikhil Mungel vem construindo sistemas distribuídos e equipes de IA em empresas de SaaS há mais de 15 anos.

Fonte ==> Cyberseo