Então você quer fazer pesquisa em IA? É verdade que ninguém realmente te ensina como. Não diretamente, pelo menos. Mas acontece que a forma de começar é bem simples: alguma combinação de (i) ler e (ii) construir coisas. Você não pode fazer um sem o outro. Você se torna um pesquisador através da combinação.
Acontece que o processo de se tornar um grande pesquisador não é tão diferente de aprender a meditar:
I.
Há um velho ditado zen que diz mais ou menos assim —
*nos dias em que encontramos insight, sentamos. nos dias em que não encontramos insight, sentamos.*
Fazer pesquisa é basicamente assim. Insights científicos podem surgir aparentemente ao acaso. Na maioria dos dias, eles não virão. Uma característica importante para o sucesso é apenas dedicar tempo e esforço. Como qualquer outra prática (música, esportes, vendas, etc.), se você quer se tornar nível mundial, vai exigir uma quantidade tremenda de disciplina.
Noam Shazeer faz uma bela menção à aleatoriedade inerente das ideias de pesquisa bem-sucedidas no artigo SwiGLU:
"Não oferecemos nenhuma explicação sobre por que essas arquiteturas parecem funcionar; atribuímos seu sucesso, como tudo mais, à benevolência divina."
Um comentário relacionado é que é possível ler artigos demais. Se você quer resolver um problema, o caminho testado e aprovado para o sucesso é tentar uma solução, testá-la, chegar a um gargalo, tentar resolvê-lo e só recorrer à literatura quando você mesmo tiver ficado sem ideias.
II.
Tudo bem, mas no que devo trabalhar?
Se você está começando, aqui está minha resposta honesta: acho que o tópico exato não importa muito.
Dito isso, eu te alertaria contra escolher coisas que são populares há menos de seis meses. A IA avança rápido, mas as ideias fundamentais não mudam há quarenta anos. Se você quer fazer carreira nisso, não aconselharia pensar demais nos conceitos de 2026: harnesses, agentes, engenharia de contexto, etc. Isso vai mudar.
Em vez disso, você aprenderá mais voltando ao básico: aprenda o que é entropia cruzada. Calcule-a manualmente para uma pequena distribuição. Entenda profundamente SVD, a ponto de conseguir visualizá-la mentalmente. Não pense muito em RL para programação especificamente; em vez disso, aprenda as ideias por trás dos policy gradients, por que são úteis e por que são populares há décadas.
Mais um comentário meta: se o melhor resultado possível do seu projeto de pesquisa é uma pontuação mais alta em um benchmark existente, você não está indo fundo o suficiente. Muitas vezes, conjuntos de dados existentes não testarão novas capacidades interessantes.
Jason Wei faz um ponto semelhante:
Uma habilidade subestimada, mas ocasionalmente decisiva, na pesquisa em IA (que realmente não existia há dez anos) é a capacidade de encontrar um conjunto de dados que realmente exercite um novo método no qual você está trabalhando.
Quanto a uma sugestão concreta, não posso dar uma; isso tem que vir de você. Vá fundo, foque no básico e não persiga benchmarks. Fique na água e as ideias virão.
III.
na mente do iniciante há muitas possibilidades; na mente do especialista há poucas – Suzuki
Algo repetido com frequência no Vale do Silício hoje em dia é como a experiência em pesquisa de IA pode ser contraproducente para uma boa intuição de pesquisa nos dias modernos. Observei partes disso de perto; muitos pesquisadores da era pré-escala continuam interessados em projetar métodos que funcionam em pequena escala, mas obviamente falharão quando testados em grande escala.
Uma coisa realmente impressionante sobre a OpenAI é que a maioria das pessoas que administram a empresa (pelo menos no lado técnico) tem menos de 35 anos. Muitos dos tomadores de decisão importantes por trás do ChatGPT têm menos de 30. Uma coisa que podemos aprender com isso é que, como a IA é um campo tão nascente (o ChatGPT tem menos de quatro anos!), ninguém tem uma grande vantagem, porque ninguém trabalhou nisso por muito tempo.
Em suma, segurar ideias por muito tempo pode ser contraproducente. Pratique a mente de iniciante. Mantenha-se aberto e recuse deixar o ego turvar seu julgamento.
IV.
A inspiração chega quando você menos espera.
Aqui estão dois exemplos históricos:
- A descoberta da estrutura do anel de benzeno veio famosamente em um sonho: a estrutura nunca tinha sido vista antes, mas foi imaginada como uma serpente mordendo o próprio rabo.
- Ozempic basicamente vem de lagartos. O hormônio GLP-1 que ele imita foi encontrado primeiro no veneno do monstro-de-gila, um lagarto do deserto que come apenas algumas vezes por ano. De alguma forma, descobrimos como fazer isso funcionar também para humanos.
Uma lição importante é que para fazer boa pesquisa, você precisa fazer outras coisas além de pesquisa. A maioria dos meus "momentos eureca" pessoais aconteceu longe do teclado, especialmente ao caminhar.
Darwin, Tesla, Feynman, Aristóteles. Muitos grandes pensadores da história proclamaram os enormes benefícios de esticar as pernas e dar uma volta. Mesmo que você não faça pesquisa, provavelmente deveria caminhar mais.
V.
Mesmo quando a inspiração chega, a natureza pode não ser benevolente: mesmo com uma implementação perfeita, nossa ideia pode simplesmente não ser verdadeira em algum sentido fundamental. Ou talvez foi, ou parece ser. Quando os resultados chegam, como devemos reagir?
Outro princípio que podemos emprestar do zen é a equanimidade (experimental).
Ao analisar um experimento:
Foi bem? Ótimo!
Foi mal? Também ótimo!
Ambos os resultados te ensinam a mesma quantidade de informação. Na verdade, muitas vezes é possível aprender mais com uma sequência de resultados negativos do que com um único resultado positivo. "Uau, ainda não está funcionando – incrível!" Essa é uma atitude saudável para a pesquisa.
O oposto disso é que você não deve ficar tão animado com resultados bons. Na verdade, a maioria dos resultados bons vem por causa de um bug; não é que os resultados em si foram bons, é que você mediu incorretamente e se convenceu. Todo mundo quer que suas ideias funcionem – e isso é uma coisa boa! – mas uma coisa que todos os pesquisadores experientes compartilham é o ceticismo extremo, especialmente diante de resultados que parecem bons demais para ser verdade. Infelizmente, quase sempre são.
VI.
Uma flor não pensa em competir com a flor ao lado. Ela apenas desabrocha.
A pesquisa é extremamente orientada a resultados. Especialmente na academia, é fácil olhar para os sucessos dos outros no papel e se deixar levar pelas emoções.
As pessoas têm sucesso por razões diferentes. Algumas têm sorte. O processo de revisão acadêmica, em particular, não é consistente nem justo. Quando uma nova pesquisa sair na sua área que você admira, pergunte a si mesmo:
Estou operando no nível de profundidade adequado para ter feito essa descoberta sozinho?
Agora há dois resultados possíveis. Se a resposta for sim – ótimo. Seu processo está sólido, mas você não fez essa descoberta; você estava ocupado, estava fazendo outra coisa, mas poderia ter feito.
E se a resposta for não – então use isso como motivação para ir mais fundo.
VII.
antes da iluminação, cortar lenha, carregar água. depois da iluminação, cortar lenha, carregar água.
Muitos projetos bem-sucedidos tipicamente envolvem centenas de horas de trabalho braçal nos bastidores. Andrej Karpathy rotulou manualmente uma parte nada trivial do ImageNet. Os criadores do SWEBench, que estavam à frente de seu tempo em muitos aspectos, passaram centenas de horas filtrando meticulosamente dados do GitHub para obter um conjunto pequeno e tratável de issues do GitHub úteis para avaliação.
Se você olhar a carreira de grandes pesquisadores, eles provavelmente passaram muito tempo trabalhando no anonimato antes de encontrar o sucesso. Acostume-se com isso. Quanto mais ambiciosa e inovadora for uma ideia, mais trabalho pode ser necessário para implementá-la e avaliá-la completamente. Essa dificuldade é uma característica, não um bug.
VIII.
Collin Raffel, um pesquisador incrível que respeito profundamente, mencionou certa vez que acredita que muitas ideias falham não por serem ruins, mas porque o código tem um bug que o pesquisador nunca encontrou.
Em geral, esse é um problema realmente difícil, especialmente no mundo dos LLMs. Uma pilha moderna de software de deep learning é extremamente complicada, e bugs podem estar em qualquer lugar: no treinamento, na inferência, nos harnesses, nos dados.
Se algo parecer errado, você não pode seguir em frente. Você pode e deve registrar muitas métricas e se esforçar para entender todas elas. Se algumas métricas parecerem diferentes do esperado, você precisa descobrir o porquê, porque algo pode estar errado. Já tuitei antes que uma das características mais importantes em um pesquisador é a paranoia saudável. Seja paranóico!
IX.
Um ponto prático é que a maioria dos experimentos que envolvem deep learning demora demais. Treinar modelos pode levar semanas ou meses. Hoje em dia, avaliar um modelo em uma única tarefa pode levar vários dias.
Especialmente ao programar com agentes, nosso instinto pode ser de iniciar muitos experimentos em paralelo e deixá-los rodar em um ritmo lento. Embora a paralelização simples ajude até certo ponto, a troca de contexto é um padrão prejudicial.
É de suma importância projetar fluxos de trabalho de pesquisa ergonômicos que suportem feedback experimental rápido. Reduza os tempos de inicialização a frio para treinamento, faça avaliações pequenas que retornem resultados rapidamente. Admiro muito o nanoGPT speedrun de Keller Jordan como um exemplo de quanto podemos aprender com ciclos de iteração rápidos.
(Dito isso, no final das contas, alguns resultados levam um tempo inevitavelmente longo. Quando possível, manter o estado ao longo de vários dias e entender os experimentos da semana passada quando eles terminam hoje é uma habilidade incrivelmente útil.)
X.
Agentes de programação ajudam você a se mover mais rápido, mas pioram dois problemas: temos mais dificuldade em entender detalhes básicos e trocamos de contexto com mais frequência. Um bom pesquisador trabalha ativamente para combater ambas as forças.
Codex pode escrever um script de treinamento para você; pode até executar o script, supervisioná-lo enquanto está rodando, interpretar os resultados e enviá-los para você em um e-mail. Mas talvez ele tenha encontrado um erro e encurtado o prompt do sistema sem te perguntar. Talvez ele tenha encurtado os comprimentos de sequência para fazer a avaliação rodar em um tempo razoável. Talvez ele tenha rodado a configuração errada porque você não especificou.
De uma perspectiva de engenharia, todos esses são pequenos erros com correção fácil. Mas de uma perspectiva científica, são graves: pequenas omissões como essas podem alterar materialmente resultados importantes de artigos e, portanto, não são aceitáveis. Cuidado com dragões. Mesmo que você não tenha escrito o código, se quiser entender seus resultados, precisa entender o sistema que os produziu.
Vou ser sincero com você – isso é difícil! É tentador terceirizar o entendimento para a máquina. Para muitas aplicações, é mais rápido. Mas fazer boa ciência exige aprender como todo o sistema funciona, para que você possa ter certeza de que as observações sobre ele são verdadeiras. Não há um caminho fácil para contornar isso.
XI.
TLDR: Talento não é tudo o que é preciso para se tornar um pesquisador de sucesso. Temperamento é muito subestimado. Mantenha-se curioso e persistente, permaneça atencioso e meticuloso, e as ideias virão.
