Andrej Karpathy e o aprendizado profundo: lições para entregar IA

Por que o aprendizado profundo frequentemente parece difícil de usar em produtos reais

Uma demo de aprendizado profundo pode parecer mágica. Um modelo escreve um parágrafo limpo, reconhece um objeto ou responde a uma pergunta difícil. Aí você tenta transformar essa demo em um botão que as pessoas pressionam todo dia, e as coisas ficam confusas. O mesmo prompt se comporta de forma diferente, casos limites aparecem, e o momento “uau” vira um chamado de suporte.

Essa lacuna é por que o trabalho do Andrej Karpathy ressoou com quem constrói produtos. Ele promoveu uma mentalidade em que redes neurais não são artefatos misteriosos. São sistemas que você projeta, testa e mantém. Os modelos não são inúteis — produtos simplesmente exigem consistência.

Quando equipes dizem que querem IA “prática”, geralmente querem quatro coisas:

• Repetível: se comporta de forma previsível em entradas comuns, não apenas em demos selecionadas.
• Mensurável: você pode definir o que é “bom” com um número, não com uma sensação.
• Mantenível: você pode atualizar dados, prompts ou modelos sem quebrar tudo.
• Operável: você pode monitorar falhas, custo, latência e qualidade após o lançamento.

As equipes têm dificuldade porque aprendizado profundo é probabilístico e sensível ao contexto, enquanto produtos são avaliados pela confiabilidade. Um chatbot que responde bem 80% das perguntas ainda pode parecer quebrado se os outros 20% forem respostas confiantes, erradas e difíceis de detectar.

Pegue um assistente de “resposta automática” para suporte ao cliente. Ele fica ótimo em alguns tickets escolhidos à mão. Em produção, clientes escrevem em gíria, incluem screenshots, misturam idiomas ou perguntam sobre casos de política. Agora você precisa de limites, comportamento claro de recusa e uma forma de medir se o rascunho realmente ajudou o agente.

Trabalho inicial: tratar redes neurais como engenharia, não magia

Muita gente conheceu o trabalho do Karpathy por exemplos práticos, não por matemática abstrata. Mesmo projetos antigos faziam um ponto simples: redes neurais se tornam úteis quando você as trata como software que pode testar, quebrar e consertar.

Em vez de parar em “o modelo funciona”, o foco muda para fazê‑lo funcionar em dados bagunçados e reais. Isso inclui pipelines de dados, execuções de treinamento que falham por motivos chatos e resultados que mudam quando você mexe numa coisinha. Nesse mundo, aprendizado profundo para de soar místico e começa a parecer engenharia.

A abordagem ao estilo Karpathy é menos sobre truques secretos e mais sobre hábitos:

• Comece com um baseline que você possa superar, mesmo que seja simples.
• Escolha uma métrica que decida “melhor” vs “pior”.
• Mude uma coisa por vez para saber o que causou o resultado.
• Inspecione erros e exemplos, não apenas a pontuação final.

Essa base importa depois porque IA de produto é o mesmo jogo, só com apostas maiores. Se você não constrói o ofício cedo (entradas claras, saídas claras, execuções repetíveis), lançar uma funcionalidade de IA vira palpite.

Tornando redes neurais compreensíveis para engenheiros que mantêm o sistema

Uma grande parte do impacto do Karpathy foi tratar redes neurais como algo que você pode raciocinar. Explicações claras transformam o trabalho de um “sistema de crença” em engenharia.

Isso importa para equipes porque quem entrega o primeiro protótipo frequentemente não é quem o mantém. Se você não consegue explicar o que um modelo está fazendo, provavelmente não vai conseguir depurá‑lo e com certeza não vai conseguir dar suporte em produção.

Explique como se fosse manter

Forçe clareza cedo. Antes de construir a funcionalidade, escreva o que o modelo vê, o que ele produz e como você saberá se está melhorando. A maioria dos projetos de IA falha por questões básicas, não por matemática.

Uma checklist curta que compensa mais tarde:

• Qual é a entrada e a saída exatas (formato, limites, redacções)?
• Qual baseline você deve superar (regras, busca, templates ou um modelo menor)?
• O que significa “bom” (um número, uma rubrica ou ambos)?
• Quais falhas são inaceitáveis (segurança, privacidade, tom da marca)?
• Quem revisa resultados, e com que frequência?

Reprodutibilidade faz parte da explicação

O pensamento claro aparece em experimentos disciplinados: um script que você pode executar de novo, conjuntos de avaliação fixos, prompts versionados e métricas registradas. Baselines te mantêm honesto e tornam o progresso visível.

De protótipos a produção: o que muda quando se lança

Um protótipo prova que uma ideia pode funcionar. Uma funcionalidade lançada prova que funciona para pessoas reais, em condições bagunçadas, todo dia. Essa lacuna é onde muitos projetos de IA estacionam.

Uma demo de pesquisa pode ser lenta, cara e frágil, desde que mostre capacidade. Produção inverte prioridades. O sistema precisa ser previsível, observável e seguro mesmo quando entradas são estranhas, usuários estão impacientes e o tráfego dispara.

As restrições que você passa a se importar

Em produção, latência é um recurso. Se o modelo demora 8 segundos, usuários desistem ou apertam o botão várias vezes, e você paga por cada tentativa. O custo também vira decisão de produto, porque uma pequena mudança no prompt pode dobrar sua fatura.

Monitoramento é não negociável. Você precisa saber não só que o serviço está no ar, mas que as saídas continuam dentro de uma qualidade aceitável ao longo do tempo. Mudanças no dado, novo comportamento de usuário e alterações a montante podem quebrar desempenho silenciosamente sem lançar um erro.

Checagens de segurança e conformidade passam de “bom ter” para obrigatórias. Você tem que lidar com pedidos prejudiciais, dados privados e casos limite de maneira consistente e testável.

Times normalmente acabam respondendo ao mesmo conjunto de perguntas:

• Qual é o tempo máximo de resposta aceitável e o custo por requisição?
• Qual fallback quando o modelo falha ou dá timeout?
• Quais métricas definem qualidade e que limiares disparam alertas?
• Como prevenir saídas inseguras ou não conformes?
• Como fazer rollback rápido se a qualidade cair?

É preciso mais do que habilidade com modelos

Um protótipo pode ser feito por uma pessoa. Lançar normalmente precisa de produto para definir sucesso, dados para validar entradas e conjuntos de avaliação, infraestrutura para rodar confiavelmente e QA para testar modos de falha.

“Funciona na minha máquina” não é critério de release. Um lançamento significa que funciona para usuários sob carga, com logging, guardrails e uma forma de medir se está ajudando ou prejudicando.

Cultura de engenharia: suposições, baselines e iteração

A influência do Karpathy é cultural, não só técnica. Ele tratava redes neurais como algo que você pode construir, testar e melhorar com a mesma disciplina que aplicaria a qualquer sistema de engenharia.

Começa por escrever suposições antes de escrever código. Se você não consegue afirmar o que precisa ser verdade para a funcionalidade funcionar, não vai conseguir depurá‑la depois. Exemplos:

• “Usuários aceitam uma resposta sugerida se estiver correta e combinar o tom.”
• “Latência abaixo de 800 ms é necessária ou as pessoas param de usar.”

Essas são afirmações testáveis.

Baselines vêm em seguida. Um baseline é a coisa mais simples que poderia funcionar e é seu cheque de realidade. Pode ser regras, um template de busca ou até “não fazer nada” com uma boa UI. Baselines fortes protegem você de gastar semanas numa solução elegante que não supera algo simples.

Instrumentação torna a iteração possível. Se você só olha demos, está guiando por sensações. Para muitas funcionalidades de IA, um pequeno conjunto de números já indica se você está melhorando:

• Adoção (quem testa e continua usando)
• Qualidade (taxa de aceitação, edições antes de enviar, polegares cima/baixo)
• Velocidade (latência e tempo até a primeira saída útil)
• Custo (tokens, compute, tempo de revisão humana)
• Segurança (violações de política, vazamento de dados sensíveis, tentativas de jailbreak)

Depois itere em ciclos curtos. Mude uma coisa, compare com o baseline e mantenha um registro simples do que tentou e o que mudou. Se o progresso for real, aparece em um gráfico.

Passo a passo: um fluxo simples para lançar uma funcionalidade de IA

Lançar IA funciona melhor quando você a trata como engenharia: metas claras, um baseline e loops de feedback rápidos.

1. Declare o problema do usuário em uma frase. Escreva como uma reclamação real: “Agentes de suporte gastam muito tempo redigindo respostas para perguntas comuns.” Se não conseguir dizer em uma frase, a funcionalidade provavelmente é grande demais.

2. Escolha um resultado mensurável. Pegue um número que possa acompanhar semanalmente. Boas escolhas incluem tempo economizado por tarefa, taxa de aceitação do primeiro rascunho, redução de edições ou taxa de desvio de tickets. Decida o que é “bom o suficiente” antes de construir.

3. Defina o baseline que precisa superar. Compare com um template simples, uma abordagem baseada em regras ou “somente humano.” Se a IA não superar o baseline na métrica escolhida, não lance.

4. Desenhe um teste pequeno com dados representativos. Colete exemplos que correspondam à realidade, incluindo casos bagunçados. Mantenha um pequeno conjunto de avaliação que você não “treine mentalmente” relendo todo dia. Registre o que conta como sucesso e como falha.

5. Lance atrás de uma flag, colete feedback e itere. Comece com um grupo interno pequeno ou uma pequena porcentagem de usuários. Registre a entrada, a saída e se ajudou. Corrija o modo de falha mais frequente primeiro e rerun o mesmo teste para ver progresso real.

Um padrão prático para ferramentas de rascunho: meça “segundos até enviar” e “percentual de rascunhos usados com edições mínimas”.

Suposições claras e saídas mensuráveis (o que escrever)

Muitas falhas de funcionalidades de IA não são falhas do modelo. São falhas do tipo “nunca concordamos sobre o que é sucesso”. Se quiser que aprendizado profundo pareça prático, escreva suposições e medidas antes de escrever mais prompts ou treinar mais modelos.

Comece com suposições que podem quebrar sua funcionalidade em uso real. Comuns são sobre dados e pessoas: texto de entrada em um idioma, usuários pedindo uma intenção por vez, a UI fornecendo contexto suficiente, casos limites raros e o padrão de ontem ainda sendo válido no mês que vem (drift). Também escreva o que você não vai lidar ainda, como sarcasmo, aconselhamento jurídico ou documentos longos.

Transforme cada suposição em algo que você pode testar. Um formato útil é: “Dado X, o sistema deve fazer Y, e podemos verificar por Z.” Mantenha concreto.

Cinco coisas que valem a pena escrever em uma página:

• Entradas: o que o modelo vê (campos, limites, redacções) e o que significa “limpo o suficiente”
• Contrato de saída: o que deve retornar (formato, tom, ações permitidas)
• Avaliação offline: um pequeno conjunto rotulado com regras de pontuação (passar/falhar mais uma métrica)
• Métrica online: o que usuários fazem (taxa de aceitação, edições, tempo salvo, tickets reabertos)
• Guardrails: quando recusar, perguntar ou cair para um fluxo mais simples

Mantenha offline e online separados de propósito. Métricas offline dizem se o sistema aprendeu a tarefa. Métricas online dizem se a funcionalidade ajuda humanos. Um modelo pode pontuar bem offline e ainda irritar usuários por ser lento, excessivamente confiante ou errado nos casos que importam.

Defina “bom o suficiente” como limiares e consequências. Exemplo: “Offline: pelo menos 85% corretas no conjunto de avaliação; Online: 30% dos rascunhos aceitos com edições mínimas.” Se perder o limiar, decida antes o que acontece: manter atrás de uma toggle, reduzir rollout, encaminhar casos de baixa confiança para um template ou pausar e coletar mais dados.

Erros comuns quando equipes adicionam IA a um produto

Equipes geralmente tratam uma funcionalidade de IA como um ajuste normal de UI: lance, veja o que acontece e ajuste depois. Isso quebra rápido porque o comportamento do modelo pode mudar com prompts, drift e pequenas alterações de configuração. O resultado é muito esforço sem prova clara de que ajudou.

Uma regra prática é simples: se não consegue nomear o baseline e a medição, você ainda não está pronto para lançar.

Os modos de falha mais comuns:

• Lançar sem um baseline não-AI, então a melhoria é impossível de provar.
• Perseguir qualidade ignorando latência e custo (um ganho de 3% não vale ficar 5x mais lento).
• Confiar em feedback vago (“usuários gostam”) em vez de instrumentação.
• Ajustar em um conjunto de testes pequeno ou escolhido a dedo que não corresponde ao tráfego real.
• Não ter plano de rollback quando um prompt ou atualização de modelo produz saídas estranhas.

Um exemplo concreto: adicionar IA para rascunhar respostas de suporte. Se você só monitora polegares para cima, pode perder que agentes demoram mais revisando rascunhos, ou que respostas estão corretas mas muito longas. Medidas melhores são “percentual enviado com edições mínimas” e “mediana do tempo até enviar”.

Checklist rápido antes do release

Trate o dia do lançamento como uma transição de engenharia, não uma demo. Você deve conseguir explicar, em palavras simples, o que a funcionalidade faz, como sabe que funciona e o que fará quando quebrar.

Antes de lançar, verifique:

• Uma declaração do problema em um parágrafo e usuários‑alvo claros.
• Um baseline medido (mesmo que simples).
• Uma métrica online principal ligada ao valor do usuário, mais logs que capturem entradas, saídas e resultados.
• Uma revisão de segurança: modos prováveis de falha, quem é prejudicado e o que a UI faz (avisar, bloquear, pedir confirmação).
• Um plano de rollback com um responsável: o que dispara rollback e o que checar na primeira hora.

Também mantenha um conjunto de avaliação offline que pareça com o tráfego real, inclua casos limites e permaneça estável o suficiente para comparar entre semanas. Quando mudar prompts, modelos ou limpeza de dados, rode o mesmo conjunto e veja o que mudou.

Exemplo: lançar uma funcionalidade de rascunho para suporte

Uma equipe de suporte quer um assistente que rascunhe respostas dentro da visualização do ticket. O agente não envia mensagens por conta própria. Ele sugere um rascunho, destaca fatos-chave que usou e pede que o agente revise e edite antes de enviar. Essa escolha mantém o risco baixo enquanto você aprende.

Comece decidindo o que “melhor” significa em números. Escolha resultados que possa medir desde o dia 1 usando logs existentes:

• Tempo médio de atendimento (aberto a resolvido)
• Taxa de edição (quanto os agentes mudam nos rascunhos antes de enviar)
• Taxa de escalonamento (tickets enviados para níveis superiores)
• Taxa de reabertura (tickets reabertos dentro de 7 dias)
• Score de satisfação do cliente (se você já rastreia)

Antes de incorporar um modelo, defina um baseline chato mas real: templates salvos mais uma camada simples de regras (detectar reembolso vs envio vs recuperação de senha e preencher o melhor template). Se a IA não bater esse baseline, não está pronta.

Execute um piloto pequeno. Torne opt‑in para alguns agentes, limitado a uma categoria de ticket primeiro (por exemplo, status do pedido). Adicione feedback rápido em cada rascunho: “útil” ou “não útil”, com uma razão curta. Capture o que o agente mudou, não só se clicou um botão.

Defina critérios de lançamento desde o início para não chutar depois. Por exemplo: tempo de atendimento melhora 10% sem aumentar escalonamentos ou reaberturas, e agentes aceitam rascunhos com edições mínimas pelo menos 30% das vezes.

Decida também o que dispara rollback: um pico em escalonamentos, queda na satisfação ou erros repetidos de política.

Próximos passos: aplique essas lições no seu próximo lançamento de IA

Escolha uma ideia de IA que consiga lançar em 2 a 4 semanas. Mantenha pequena para poder medir, debugar e reverter sem drama. O objetivo não é provar que o modelo é inteligente, é tornar um resultado de usuário consistentemente melhor que o que você já tem.

Transforme a ideia em um plano de uma página: o que a funcionalidade faz, o que não faz e como você saberá que está funcionando. Inclua um baseline e a métrica exata que vai acompanhar.

Se quiser avançar rápido na implementação, Koder.ai (koder.ai) é construído para criar apps web, servidor e mobile por uma interface de chat, com recursos como snapshots/rollback e exportação de código‑fonte quando precisar de controle mais profundo.

O hábito a manter é simples: toda mudança de IA deve vir com uma suposição escrita e uma saída mensurável. Assim aprendizado profundo para de parecer magia e passa a ser trabalho que você pode entregar.