notícias

compilação de coração de máquina

autor: omar khattab

editor: molho de ovo, zenan

escrevendo um artigo? esse é apenas um pequeno passo.

durante a pós-graduação, muitas pessoas ficam frequentemente confusas sobre como estruturar suas próprias pesquisas. como deveríamos conduzir pesquisas para fazer a diferença no já lotado campo da inteligência artificial?

muitas pessoas acreditam que projetos de longo prazo, lançamentos de código adequados e benchmarks bem elaborados não são motivadores o suficiente - às vezes pode ser algo que você faz de forma rápida e culpada e depois volta a fazer pesquisas "reais".

recentemente, omar khattab, estudante de doutorado no grupo de pnl da universidade de stanford, publicou uma postagem no blog discutindo as opiniões dos principais estudiosos de ia sobre como fazer pesquisas impactantes.

vejamos o que ele disse:

o impacto da investigação assume muitas formas, e concentrar-me-ei apenas na medição do impacto da investigação na ia através de trabalho de código aberto (por exemplo, modelos, sistemas, estruturas ou benchmarks). como parte do meu objetivo é refinar minhas ideias, registrar sugestões específicas e coletar feedback, tornarei a declaração mais sucinta. se você tiver outras idéias, discuta-as na área de comentários.

primeiro, aqui estão os princípios orientadores:

• concentre-se em projetos, não em documentos.

• você pode “cavar um buraco” escolhendo um problema apropriado que tenha mais espaço para desenvolvimento.

• pense dois passos à frente e repita rapidamente.

• torne seu trabalho público e promova suas ideias.

• encontre maneiras de se motivar: aqui estão algumas dicas para aumentar sua pesquisa de código aberto.

• continue investindo em seu projeto com novos papéis.

• o quinto ponto, “dicas para desenvolver pesquisas de código aberto”, merece um artigo mais longo. posso escrever sobre isso em meu próximo post.

foco em projetos

em vez de um papel

esta é uma peça crucial de pensamento sobre a qual todo o resto se baseia.

os alunos iniciantes darão grande ênfase à publicação de seus primeiros artigos. isso faz sentido: é como você aprende a conduzir pesquisas, explorar as direções iniciais e demonstrar o progresso inicial. mas este é um estágio que você deve eventualmente abandonar: no longo prazo, suas conquistas e crescimento dependerão menos do grande número de artigos e mais do seu impacto e do contexto geral de pesquisa que você transmite.

infelizmente, muitos estudantes de doutorado consideram o comportamento potencialmente mais impactante como “desmotivador”. isso me confundiu até que percebi que o que eles queriam dizer era que essas ações poderiam retardar sua capacidade de publicar seu próximo artigo. mas a sua capacidade de publicar o seu próximo artigo tão rapidamente é menos importante.

sugiro que você não pense no seu trabalho como uma série de artigos isolados, mas pergunte-se: quais são as visões mais amplas que você vai liderar e quais são os subcampos ou paradigmas dentro delas? que diferença você quer fazer no seu trabalho? portanto, você publicará artigos individuais para explorar e estabelecer benchmarks, enquanto a visão mais ampla deve ser algo que você itere intencionalmente. precisa ser muito maior do que o papel carrega, e certamente é um problema que ainda não foi totalmente resolvido.

uma maneira de fazer isso é estruturar alguns artigos de pesquisa em torno de artefatos coerentes (como modelos, sistemas, estruturas ou benchmarks) que você mantém no domínio de código aberto. essa estratégia é mais cara do que “realizar alguns experimentos e lançar um repositório rápido e passageiro”, mas força você a encontrar um problema com impacto real e ajuda a garantir que a nova pesquisa que você faz seja realmente coerente e útil: você não se esforça na introdução de um pequeno recurso ou truque que é inútil para os artefatos que você vem desenvolvendo e mantendo.

escolha perguntas apropriadas com maior espaço para melhorias

pode "cavar um buraco"

nem todo artigo que você escreve vale a pena investir indefinidamente. muitos artigos são artigos exploratórios únicos. para encontrar direções que podem se transformar em projetos maiores, use os seguintes critérios.

primeiro, o problema deve ser de ponta. você pode defini-lo de várias maneiras, mas emiauma estratégia eficaz neste campo é encontrar um espaço problemático que estará “quente” dentro de 2-3 anos, mas que ainda não se tornou dominante.

em segundo lugar, o problema deve ter um grande potencial para cavar buracos, ou seja, um impacto potencial em muitos problemas a jusante. basicamente, os resultados dessas perguntas podem beneficiar ou ser de interesse para um número suficiente de pessoas. os pesquisadores e as pessoas se preocupam com o que os ajuda a atingir seus objetivos, então sua pergunta pode ser algo como ajudar outras pessoas a construir coisas ou a atingir metas de pesquisa ou produção. você pode aplicar esse filtro para estudar fundamentos teóricos, infraestrutura de sistema, novos benchmarks, novos modelos e muitas outras coisas.

terceiro, o problema deve ficar com uma margem maior. se você disser às pessoas que o sistema delas pode ser 1,5 vezes mais rápido ou 5% mais eficiente, isso provavelmente não será interessante. parece-me que você precisa encontrar problemas onde, pelo menos depois de anos de trabalho duro, você tenha uma esperança diferente de zero de fazer algo mais rápido, digamos 20x mais rápido ou 30% mais eficiente. é claro que você não precisa percorrer todo o caminho para ter sucesso e não deve esperar até chegar lá para publicar seu primeiro artigo ou lançar seu primeiro trabalho.

não quero ser muito abstrato, vamos usar o colbert para ilustrar. no final de 2019, as pesquisas sobre a aplicação do bert para recuperação eram muito populares, mas esses métodos são muito caros. naturalmente pergunta-se: podemos melhorar significativamente a eficiência desta abordagem? o que torna esta uma boa pergunta?

primeiro, é muito prefaciado. podemos prever corretamente que até 2021 (1,5 anos depois), muitos pesquisadores buscarão arquiteturas de recuperação eficientes baseadas no bert. em segundo lugar, tem muito espaço para desenvolvimento. os novos paradigmas de ml tendem a ser assim porque a maioria desses esforços ignora inicialmente a eficiência. na verdade, a abordagem original pode levar 30 segundos para responder a uma consulta, mas agora ela pode concluir recuperações de maior qualidade em 30 milissegundos, o que é 1.000 vezes mais rápido. terceiro, tem um grande fanout. a recuperação escalável é um bom problema de “fundação”: todos precisam construir algo em cima dos recuperadores, mas poucos querem construí-los.

pense dois passos à frente

e iterar rapidamente

agora que você tem um bom problema, não se apresse em escolher o fruto mais fácil à sua frente como abordagem! em algum momento, pelo menos muitas pessoas acabarão por considerar a abordagem “óbvia”.

em vez disso, pense pelo menos dois passos à frente. identifique o caminho que a maioria das pessoas provavelmente seguirá quando esta questão oportuna finalmente se tornar popular. em seguida, identifique as limitações do próprio caminho e trabalhe para compreender e resolver essas limitações.

como é isso na prática? vamos revisitar o caso colbert. a maneira óbvia de construir um recuperador eficiente usando bert é codificar documentos em vetores. curiosamente, até ao final de 2019, apenas um trabalho limitado de ri tinha conseguido este objetivo. por exemplo, o trabalho mais citado nesta categoria (dpr) só lançou seu primeiro preprint em abril de 2020.

diante disso, você pode pensar que a coisa certa a fazer em 2019 é construir um excelente modelo de ir de vetor único via bert. em contraste, pensar apenas dois passos à frente levanta a questão: mais cedo ou mais tarde todos constroem uma abordagem de vector único, então onde é que esta abordagem de vector único fica fundamentalmente presa? na verdade, esse problema levou a paradigmas de interação posteriores e modelos amplamente utilizados.

como outro exemplo, podemos usar dspy. em fevereiro de 2022, à medida que as dicas se tornaram cada vez mais poderosas, ficou claro que as pessoas queriam usá-las para garantia de qualidade baseada na recuperação, em vez de fazer ajustes como antes. para fazer isso, naturalmente temos que estabelecer um método. indo dois passos adiante, perguntamos: onde essa abordagem fica presa? em última análise, a abordagem “recuperar e gerar” (ou rag) é provavelmente a abordagem mais simples envolvendo lm.

pelas mesmas razões que as pessoas estão interessadas nele, elas estarão obviamente cada vez mais interessadas em: (i) expressar combinações mais complexas de módulos (ii) descobrir o que deve ser feito através de prompt automático ou ajuste fino do lm como fazer subjacente; supervisionar ou otimizar o pipeline complexo resultante. este é o dspy.

a segunda metade desta regra é “iterar rapidamente”. este foi talvez o primeiro conselho de pesquisa que meu orientador matei zaharia (vencedor do prêmio sloan e fundador do apache spark) me deu durante a primeira semana do meu doutorado: identificando um tópico onde você pode iterar rapidamente e obter feedback (como atrasar ou verificar pontuação) do problema, o que pode melhorar muito suas chances de resolver o quebra-cabeça. isto é especialmente importante se você estiver pensando dois passos à frente, o que é bastante difícil e incerto.

torne seu trabalho público

deixe suas ideias penetrarem

neste ponto, você descobriu um bom problema e continuou iterando até descobrir algo interessante e escrever um artigo esclarecedor. não passe para o próximo artigo. em vez disso, concentre-se em divulgar os resultados do seu trabalho para o mundo e procure ter interações reais com as pessoas, não apenas sobre o seu único lançamento em papel, mas sobre o panorama geral que você está pesquisando ativamente. ou melhor ainda, informe as pessoas sobre uma ferramenta útil de código aberto que você está construindo e mantendo e que captura suas ideias principais.

um primeiro passo comum é publicar uma pré-impressão do seu artigo no arxiv e depois publicar uma “postagem” anunciando a publicação do seu artigo. ao fazer isso, certifique-se de iniciar sua postagem com uma afirmação específica, substancial e compreensível. o objetivo não é dizer às pessoas que você publicou um artigo que não tem valor intrínseco. o objetivo é transmitir seus principais argumentos de forma direta e envolvente. (sim, eu sei que é difícil, mas é necessário).

talvez o mais importante seja que o processo não termina com o primeiro “lançamento”, é apenas o começo. dado que agora você está investindo em projetos e não apenas em artigos, suas ideias e comunicação científica continuarão ao longo do ano, muito além de publicações isoladas em artigos.

quando ajudo estudantes de pós-graduação a twittar sobre seu trabalho, não é incomum que suas postagens iniciais não recebam a atenção que esperavam. os alunos muitas vezes veem isso como uma validação de seu medo de publicar suas pesquisas e interpretam isso como mais um sinal de que devem passar para o próximo artigo. obviamente, essa ideia está incorreta.

há uma riqueza de experiências pessoais, experiências de segunda mão e observações que mostram que faz muito sentido perseverar neste assunto (o que, aliás, muitas pessoas não fazem). ou seja, com raras exceções, a tração de boas ideias exige que você conte coisas importantes às pessoas várias vezes em diferentes contextos e refina continuamente sua ideia e sua entrega até que a comunidade seja capaz de crescer com o tempo, ou até que a comunidade seja capaz de crescer com o tempo. campo atinge o estágio certo de desenvolvimento onde essas idéias são mais facilmente compreendidas.

reúna entusiasmo

dicas para publicar pesquisas de código aberto

deixar as pessoas entusiasmadas com sua pesquisa é uma coisa boa, mas entregar suas ideias para aplicativos downstream relevantes por meio de publicação, contribuição e desenvolvimento de ferramentas de código aberto pode muitas vezes ter um impacto maior.

não é fácil fazer isso: simplesmente enviar os arquivos de código junto com o readme para o github não é suficiente. um bom repositório será a “casa” do seu projeto, mais importante do que qualquer artigo que você publicar.

uma boa pesquisa de código aberto requer duas qualidades quase independentes. primeiro, deve ser uma boa pesquisa, nova, oportuna, bem definida e precisa. em segundo lugar, precisa ter utilidade clara a jusante e baixo atrito.

esta é a parte mais importante: as pessoas evitarão repetidamente (e outras usarão repetidamente) o seu trabalho oss por todas as razões “erradas”. por exemplo, sua pesquisa pode ser objetivamente “de última geração”, mas é muito provável que as pessoas priorizem alternativas com menos atrito. por outro lado, os estudantes de pós-graduação muitas vezes não entendem por que as pessoas estão usando sua ferramenta, por exemplo, porque não aproveitam ao máximo suas partes mais criativas. não é algo que valha a pena resistir, mas algo que vale a pena compreender e ter que melhorar.

com base nisso, gostaria de listar alguns marcos aos quais prestar atenção quando se trata de resultados de pesquisa de código aberto.

marco 0: disponibilizar o conteúdo publicado

não faz sentido liberar código que ninguém pode executar. na sua área de pesquisa, essas pessoas querem replicar seus resultados. talvez elas vão além do seu trabalho e citem os resultados da sua pesquisa. essas pessoas são mais pacientes do que outros tipos de usuários. ainda assim, você encontrará enormes diferenças no impacto acadêmico dependendo da facilidade de correção do código.

marco 1: torne o conteúdo publicado útil

além das pessoas do seu nicho, você deve garantir que seu lançamento seja útil para um público que deseja realmente usar o projeto para construir outras coisas. na pesquisa em inteligência artificial, esse marco raramente ocorre naturalmente. você deve dedicar muito tempo para pensar sobre os problemas que as pessoas estão tentando resolver (pesquisa, produção, etc.) e onde seus esforços de ia podem ajudar. se você conseguir fazer isso corretamente, terá muitos benefícios, desde a concepção do projeto até a api exposta e a documentação/exemplos apresentados.

marco 2: tornar os lançamentos compreensíveis

isto é difícil para os investigadores de ia, mas devemos perceber que uma versão útil, onde tudo está tecnicamente disponível e é de certa forma explicável, não significa que a maioria dos seus potenciais utilizadores irão encontrar isto. engajado em aprender ou experimentar.

o conhecido estudioso de ia andrej karpathy escreveu um artigo sobre este assunto: "você constrói algo e então precisa construir rampas para chegar até ele." ben clavie também escreveu extensivamente sobre isso e teve uma grande participação no trabalho que fizemos no colbert e em torná-lo mais acessível.

marco 3: descubra por que a alternativa óbvia falhou e seja paciente

começamos falando sobre pensar dois passos à frente. isto é crucial na minha opinião, mas também significa que a maioria das pessoas não compreenderá por que precisam de uma solução para um problema que ainda não conseguem observar claramente. acho que parte do seu trabalho ao longo do tempo é construir um caso. reúna evidências e explique de uma forma fácil de entender por que as alternativas óbvias (pense um passo de cada vez) irão falhar.

marco 4: compreender o tipo de usuários e aproveitar isso para o crescimento

quando comecei o colbert e o dspy, meu público inicial eram pesquisadores e engenheiros profissionais de ml. com o tempo, aprendi a abrir mão disso e a entender que você pode atingir um público maior, mas eles querem coisas diferentes. antes de fazer qualquer coisa, não bloqueie indireta ou mesmo diretamente diferentes categorias de usuários em potencial. essa situação é muito mais comum do que as pessoas pensam.

em segundo lugar, ao procurar utilizadores, precisamos de encontrar um equilíbrio entre os dois tipos de utilizadores. por um lado, construtores especializados com casos de uso avançados podem exigir que você invista muito dinheiro, mas tendem a avançar certos casos de uso no sentido de pesquisa, o que pode valer a pena. os construtores públicos, por outro lado, normalmente não são especialistas em ml, mas muitas vezes constroem e partilham as suas aprendizagens em público, são responsáveis ​​por uma maior parte do crescimento em grande escala e farão com que pense mais sobre a sua hipótese inicial. você precisa de ambos.

marco 5: transforme o interesse em uma comunidade crescente

o verdadeiro sucesso do trabalho do oss reside na presença de uma comunidade e no seu crescimento contínuo independente dos seus esforços. de modo geral, uma boa comunidade deve ser orgânica, mas você precisa trabalhar ativamente para ajudá-la a se formar, como acolher contribuições e discussões e procurar oportunidades para transformar o interesse em contribuições ou em algum tipo de fórum (como discord ou github).

marco 6: converter o interesse em projetos downstream ativos, colaborativos e modulares

provavelmente, o seu projeto oss em seus estágios iniciais não resolve todos os problemas da sua visão original. um projeto bem elaborado geralmente terá múltiplas partes modulares que permitem iniciar colaborações de pesquisa (ou outros empreendimentos) e permitir que novos membros da equipe não apenas avancem no projeto, mas também possuam partes significativas do projeto, tornando-o mais rápido ou com maior influência. suas idéias enquanto melhoram dramaticamente o projeto. por exemplo, o dspy atualmente tem equipes separadas liderando esforços de p&d em otimização just-in-time, abstração de programação e aprendizagem por reforço. os componentes do colbert, como interfaces de programação de aplicativos externos, infraestrutura de recuperação subjacente e modelagem central, são conduzidos principalmente por pessoas diferentes em projetos diferentes.

venha, resumir. a adoção da pesquisa de código aberto requer boas pesquisas e bons resultados de código aberto. esse equilíbrio é difícil de ser alcançado, mas uma vez acertado, pode ser muito gratificante. pessoalmente, demorei muito para compreender e internalizar isso. isso ocorreu graças aos repetidos comentários de meus orientadores de doutorado, chris potts e matei zaharia, bem como às valiosas contribuições de heather miller e jeremy howard.

o critério para avaliar a investigação é o “incremento” em comparação com o conhecimento anterior, mas antes que se possa explorar significativamente o “incremento”, o próprio software deve ser eficaz. para que o software seja eficaz, sua documentação também deve ser eficaz: as pessoas não verão todas as maneiras subsequentes pelas quais deveriam usar o software, a menos que você o mostre a elas. isto é, até que essas tarefas possam ser desenvolvidas por uma comunidade independente.

dito tudo isso, a habilidade mais importante nesta seção é “publicar”, publicar de verdade, publicar com frequência e aprender com isso.

publicar novo artigo

continue investindo em seus próprios projetos

ao ler a quinta regra, é natural perguntar: onde os estudantes de pós-graduação passam tanto tempo com software de código aberto? quando a pesquisa real pode ser feita?

a resposta prática é que a maior parte do tempo gasto em código aberto poderia ser usado para conduzir pesquisas novas e interessantes. os dois não são tão separados quanto parecem. por que você diz isso?

primeiro, estar na vanguarda desse tipo de trabalho de software de código aberto permite identificar intuitivamente novos problemas desde o início. você entenderá o problema mais instintivamente do que faria de outra forma. além disso, a comunidade que você constrói geralmente fornece feedback direto sobre seus próprios protótipos de métodos e dá acesso a colaboradores talentosos que entendem a importância do problema. você também terá acesso a “canais de distribuição” úteis para garantir que cada novo artigo publicado nesta área alcance seu público e fortaleça sua plataforma existente.

por exemplo, “colbert” não é apenas um artigo do início de 2020. atualmente, ele tem provavelmente cerca de dez artigos relacionados a acompanhamento, investindo em treinamento aprimorado, menor consumo de memória, infraestrutura de recuperação mais rápida, melhor adaptabilidade de domínio e melhor correspondência com tarefas posteriores de pnl. da mesma forma, dspy não é um artigo, mas uma coleção de artigos sobre abstração de programação, otimização de dicas e programas downstream. muitos desses artigos foram escritos por vários autores excelentes e seu trabalho teve um enorme impacto, em parte pela criação de um grande público por meio de canais de software de código aberto.

assim, uma boa ferramenta de código aberto pode criar trabalhos modulares que podem ser explorados, possuídos e desenvolvidos por novos pesquisadores e colaboradores.

texto original de referência: https://github.com/okhat/blog/blob/main/2024.09.impact.md