Onde os agentes de programação ajudam e onde falham

Pedro Alves trabalha extensivamente com IA há 25 anos. Atualmente, é CTO da Thoth AI e o criador de Last Week in AI.

Sentámo-nos com Pedro para falar sobre agentes de programação — e sobre a importância de saber o que podem e não podem fazer. Foi isto que nos disse.

Antes de a “IA” ser algo que as pessoas colocavam em apresentações

Sou o Pedro, CTO da Thoth AI. Trabalhava com IA antes de ser algo que as pessoas colocavam em apresentações — em 2001, quando era estudante de licenciatura em informática, construí um pequeno mundo cheio de agentes simulado e deixei-os aprender a superar-se uns aos outros, uma espécie de jogo da vida digital cujo objetivo era vê-los melhorar. Isso foi há 25 anos e continuo a perseguir a mesma questão: como se consegue fazer com que um sistema melhore?

Quando chegou a altura de frequentar a pós-graduação, todos presumiam que faria um doutoramento em aprendizagem automática. Não fiz. Parecia-me demasiado limitado e demasiado teórico. Queria aprender a prática com os dados mais ricos e complexos que conseguisse encontrar, por isso dediquei-me à biologia computacional: proteómica no mestrado e genómica no doutoramento. Aprendi aprendizagem automática, estatística e ciência de dados aplicando-as — redes de interação entre genes, engenharia de características, redes neuronais e métodos de conjunto — a problemas em que errar tinha consequências.

Foi aí que aprendi a lição que moldou tudo desde então. Na medicina, criei modelos de progressão de doenças e a métrica padrão — a precisão global — era inútil. Um modelo “bom” segundo essa medida limitava-se a reconfirmar os casos que os médicos já conheciam, quando o verdadeiro valor estava nos casos que não detetariam. Por isso, em vez de otimizar a precisão, otimizei a AUC parcial — essencialmente, a capacidade do modelo nos casos que importavam. A métrica que alguém lhe apresenta quase nunca é o verdadeiro objetivo.

A partir daí, percorri vários setores: esses modelos médicos, um período como consultor de uma equipa profissional de futebol, depois Silicon Valley e anos dedicados à visão computacional — numa altura em que ainda era necessário inovar na forma como se treinavam e até inicializavam os pesos de uma rede para conseguir pôr a deteção e a classificação a funcionar. Trabalhei com dados de redes sociais, comércio a retalho, moda e vídeo. Passei um ano a criar algoritmos de negociação com algoritmos genéticos e otimização por enxame de partículas — métodos de otimização não paramétrica sobre os quais tinha escrito artigos na pós-graduação. Por fim, criei a minha própria empresa, desenvolvendo ferramentas de IA para pessoas que não eram cientistas de dados.

A amplitude liga tudo. Depois de uma dúzia de áreas, continuo a ver o mesmo problema com diferentes roupagens — um truque óbvio na genómica acaba por ser a chave na visão computacional. Preocupo-me mais com a forma como um problema é formulado do que com a forma como é resolvido, porque é na formulação que se esconde a alavancagem.

É isto que me traz à Thoth. No papel, somos uma empresa de anotação de dados. Mas penso que o problema que todo este setor resolve é o problema errado. Ninguém quer dados anotados — os dados são apenas a etapa intermédia. As pessoas querem um modelo melhor. Por isso, estou a trabalhar rumo a um futuro em que um sistema identifica de que dados o seu modelo precisa para melhorar e trata dessa parte por si, para que se possa concentrar no modelo em vez da anotação.

As duas vertentes da empresa

Estruturalmente, a Thoth AI tem duas vertentes. Uma delas é o motor de operações de dados, que funciona internacionalmente e em grande escala. É maior do que uma empresa emergente típica, mas ainda muito mais pequena do que os gigantes do setor, por isso diria que é de média dimensão. A outra vertente, aquela que estou a construir, é uma equipa de investigação e inovação completamente nova aqui na Baía de São Francisco — atualmente somos cinco, com mais pessoas a juntarem-se nos próximos meses. Aí, dedicamo-nos ao resto da melhoria dos modelos: tudo o que vai além da anotação.

A nossa investigação tem duas linhas principais. A primeira é a robótica: gerar dados incorporados, avaliá-los e utilizar aprendizagem ativa para gerar automaticamente os melhores dados de treino possíveis, para que os robôs possam aprender as suas tarefas com a menor quantidade possível de dados. A maior parte utiliza dados egocêntricos (essencialmente, imagens em primeira pessoa) e concentramos grande parte do nosso trabalho na produção dos dados egocêntricos da mais elevada qualidade possível. A segunda é a fiabilidade e a eficiência nos modelos de linguagem: compreender o que causa as alucinações e qual é o seu aspeto e, do lado da eficiência, reconhecer quando um modelo mais pequeno consegue tratar de uma consulta e, em seguida, reformulá-la ou dividi-la em partes para que um modelo mais simples e barato lhe possa responder. Tudo isto é investigação atualmente, com vista a produtos que lançaremos a partir desta equipa.

Quanto à fase e à dimensão: o lado dos dados é uma operação internacional estabelecida, de média dimensão, enquanto a equipa de investigação nos EUA está deliberadamente numa fase inicial. Somos cinco no nosso escritório de San Mateo, com mais uma ou duas contratações a juntarem-se nos próximos meses. Esse é o nosso estado atual.

Como os testes intensivos criam resultados fiáveis

O Pedro partilha

A preparação é agora, na sua maioria, feita automaticamente. Mas essa não é a verdadeira vantagem. A maior melhoria é a qualidade: a reunião é mais precisa e focada, e os assuntos certos chegam de forma consistente ao CEO.

Muitos apressam-se a automatizar todas as tarefas e funções com IA, mas eu sou cauteloso. A IA torna trivial a criação de uma demonstração. Criar algo fiável para utilização diária é diferente. Quando usamos estas ferramentas na prática, deparamo-nos com casos-limite e casos extremos em que a automatização funciona quase bem, mas não totalmente. Por isso, testo exaustivamente antes de confiar em qualquer coisa num fluxo de trabalho real.

Este ano, criei ferramentas de IA para a nossa reunião semanal de análise com o CEO que ultrapassaram esse critério. Enviam e-mails aos responsáveis de cada área para recolher atualizações, compilam automaticamente as respostas, elaboram relatórios, resumos e a agenda, e acompanham os resultados ao longo do tempo.

Antes, tudo isso era feito manualmente. Alguém tinha de insistir com as pessoas para obter atualizações, juntar manualmente as respostas, escrever os resumos e a agenda, e acompanhar os resultados semana após semana. Funcionava, mas era lento, e a agenda facilmente se inclinava para aquilo que era mais recente, em vez de se centrar no que era mais importante.

A preparação é agora, na sua maioria, feita automaticamente. Mas essa não é a verdadeira vantagem. A maior melhoria é a qualidade: a reunião é mais precisa e focada, e os assuntos certos chegam de forma consistente ao CEO. Por isso, o objetivo tem menos a ver com o tempo poupado e mais com orientar a atenção do CEO para as decisões que realmente importam.

Porque é que o discernimento continua a ser humano enquanto a IA acelera a programação

A IA alimenta agora a própria programação, praticamente em todo o lado. Os meus investigadores, os engenheiros que colocam o nosso trabalho em produção e eu utilizamos ferramentas de programação com IA. É o discernimento humano, e não uma categoria específica de tarefas, que determina como o código é criado, e esse padrão muda consoante o nível de exigência.

Na área da investigação, o objetivo costuma ser pôr algo a funcionar, muitas vezes através da criação de um repositório no GitHub para testar a viabilidade de uma ideia. Nada chega à produção, por isso sou pouco exigente em relação à forma como foi escrito. Se funcionar e responder à pergunta, é suficiente.

Em produção, é diferente. A forma como construímos algo é tão importante como o facto de funcionar, por isso utilizamos a IA com mais cuidado. Os engenheiros seniores são responsáveis pela arquitetura, pela qualidade e pelas revisões. A IA acelera o trabalho deles, mas não toma essas decisões. Essa parte continua a ser humana.

A experiência da equipa ajuda. Utilizam a IA de forma diferente das pessoas menos experientes. Já sabem como é um bom resultado, pelo que o modelo amplifica o seu discernimento, em vez de substituir o discernimento que ainda estão a desenvolver. Torna-os mais rápidos sem substituir a parte essencial.

Como utilizar agentes de programação de forma eficaz

De um modo geral, a eficácia dos agentes de programação resulta da disciplina com que encaro os pontos fortes e fracos da tecnologia.

Penso nisto como se estivesse a pintar uma tela. O objetivo é sempre o mesmo: clarificar a imagem que tenho na cabeça e, depois, utilizar a IA para traduzir essa intenção em código funcional o mais rapidamente possível. O seu sucesso depende de uma variável: quanto trabalho criativo mantenho comigo e quanto delego.

A IA destaca-se no primeiro nível. Consigo ver o quadro completo e aplicar pinceladas largas, enquanto a IA preenche os detalhes. Sei exatamente o que precisa de ser construído, e traduzir a intenção em código é essencialmente algo baseado numa fórmula. É aqui que a IA funciona como um verdadeiro multiplicador de força, e a maior parte do meu trabalho quotidiano enquadra-se neste nível.

O segundo nível é útil, mas apresenta uma maior variabilidade. É semelhante, mas deixo intencionalmente algumas regiões da tela em aberto e digo ao modelo para pintar algo nessas áreas. Exige alguma criatividade, mas a minha orientação continua a delimitá-la. Trato esse resultado como um rascunho, não como uma resposta.

Advirto as pessoas relativamente ao terceiro nível. Este implica entregar à IA o núcleo criativo: a definição do projeto ou as principais decisões de conceção. Pode parecer impressionante a alguém que não conheça profundamente o domínio, mas tem um desempenho insuficiente com muito mais frequência do que é bem-sucedido, porque o modelo preenche uma lacuna que deveria ter sido preenchida por mim.

Essa lacuna é precisamente o objetivo. Quase todos os projetos têm algo único de que precisam: uma perceção ou decisão não óbvia que o problema exige. Por defeito, o modelo fornece a solução média, o padrão mais comum dos seus dados de treino. A parte que faz um projeto funcionar normalmente não é média, e a IA não consegue chegar lá por si só. Cabe-me encontrar essa peça. Depois, a IA constrói tudo o que vem a seguir mais depressa e melhor do que eu conseguiria sozinho.

Como os agentes de programação criam erros difíceis de encontrar

Pedro partilha

O resultado positivo mais evidente dos agentes de programação é a velocidade. A programação é mais rápida, o que aumenta a frequência das nossas implementações, e não se trata apenas de velocidade bruta. As coisas que eram complicadas de configurar são agora muito mais fáceis. Essa parte é real e é importante.

O resultado positivo mais evidente dos agentes de programação é a velocidade. A programação é mais rápida, o que aumenta a frequência das nossas implementações, e não se trata apenas de velocidade bruta. As coisas que eram complicadas de configurar são agora muito mais fáceis. Essa parte é real e é importante.

Um resultado mais interessante é a forma como os nossos erros mudaram. A taxa de defeitos não aumentou, mas os tipos de defeitos mudaram. A IA garante que o código é executado. Quase sempre verifica isso antes de o devolver. Assim, os erros mais simples — aqueles que simplesmente geram um erro ou não são executados — aparecem com muito menos frequência. O que resta são erros lógicos, casos que o modelo não ponderou, e estes são mais difíceis de detetar precisamente porque o código é executado sem problemas.

É aí que reside a desvantagem. Estes erros escondem-se melhor. Se alguém não tiver experiência ou depender demasiado da ferramenta, vê o código a ser executado e presume que está correto quando não está. O perigo não são mais erros; é a falsa confiança. É necessária uma pessoa que saiba o que procurar para detetar problemas que passam no teste do «funciona», mas que continuam errados.

Por que razão a IA deve ser utilizada para ampliar o trabalho de pessoas experientes em vez de melhorar pessoas menos preparadas

O que mais me surpreendeu foi perceber de onde vem o efeito multiplicador. Intuitivamente, poderíamos pensar que a IA reduz o nível de experiência necessário, permitindo contratar equipas mais baratas e juniores e deixar que as ferramentas as elevem de nível. A realidade revelou-se oposta. A experiência é agora mais importante, não menos.

Tudo se resume à fiabilidade. Utilizar a IA para transformar um engenheiro sénior em cinco engenheiros sénior é muito mais fiável do que transformar um engenheiro júnior num sénior. A IA multiplica o discernimento que já possui; não cria discernimento onde ele não existe.

Por isso, amplio o trabalho das minhas pessoas mais fortes; não tento elevar o nível das mais fracas. Algumas pessoas experientes, cada uma a produzir várias vezes mais do que antes, superam sempre uma equipa mista maior.

Por que razão a criatividade tem de vir dos seres humanos — e não da IA

É evidente que a IA não cumpriu as expectativas no que diz respeito aos aspetos criativos e de ligação da investigação. Quando realizo trabalho técnico com o apoio da IA, continua a ser necessária uma pessoa para ligar os pontos: perceber como prolongar o trabalho de outra pessoa, relacionar dois artigos de uma forma coerente e dar os saltos lógicos que normalmente consideraríamos óbvios. Essa parte continua a exigir uma pessoa.

Isso não é surpreendente quando nos lembramos do que são estes modelos. São máquinas de probabilidade. Produzem o texto com maior probabilidade de agradar ao leitor. Estamos a melhorar o seu treino para outros tipos de tarefas, mas torna-se genuinamente difícil quando tentamos ensiná-los a ser criativos, porque construir o sinal de treino é complicado.

Consideremos os conjuntos de dados. Um conjunto de dados sobre o aspeto de um cão é fácil de criar. Recolhem-se muitas fotografias de cães. Um conjunto de dados sobre criatividade ao desenhar cães apresenta um problema diferente. Por exemplo, consideremos alguém que acrescenta asas a um cão. O objetivo desse exemplo não são as asas. É o gesto abstrato por detrás delas: pegar em algo que não pertence a determinado contexto e colocá-lo onde não é esperado. Para fazer um modelo compreender isso, são necessários inúmeros exemplos, para que aprenda que as asas não são o elemento importante; o gesto criativo é que importa.

Mesmo que consiga chegar lá, deparamo-nos com o obstáculo seguinte. Agora, pegue nessa mesma criatividade e aplique-a a uma equação matemática ou a um fragmento de código de um artigo, utilizando-a para prolongar o algoritmo de outra pessoa. É nesse tipo de transferência que tudo se desmorona.

As pessoas recorrem às máquinas precisamente para a parte em que elas são mais fracas. A ironia é que a solução é simples. Uma pequena dose de criatividade humana pode levar-nos muito longe. Não dependa demasiado da máquina para essa parte e conseguirá avançar extraordinariamente.

Por que razão os CTO têm de reformular a forma como as capacidades de IA circulam nas organizações

Este não será o conselho mais popular neste momento, mas penso que é o mais prudente e o que terá maior probabilidade de compensar: seja mais ponderado do que o momento o leva a ser.

Neste momento, as empresas estão a gastar enormes quantias de dinheiro com base numa simples suposição: qualquer pessoa pode automatizar parte do seu trabalho com AI. Por isso, a diretiva é dirigida a todos. Engenheiros, profissionais de dados, vendas, marketing, toda a empresa. Criem uma conta, automatizem alguma coisa, criem as vossas próprias ferramentas, avancem. O resultado é uma enorme quantidade de esforço desperdiçado: trabalho duplicado, projetos que não chegam a lado nenhum, ferramentas que ninguém utiliza. As empresas queimam muito dinheiro em esforço, tempo e tokens que não produzem nada duradouro.

Estabeleça um processo sólido à volta disto. Centralize-o. Crie uma pequena equipa central cuja função seja tornar todas as outras equipas melhores com AI. Essa equipa desenvolve fluxos de trabalho, contexto reutilizável, normas e padrões eficazes, e depois distribui-os para que cada engenheiro não tenha de suportar individualmente o custo da descoberta. Esta é a versão estrutural do que disse anteriormente sobre concentrar a alavancagem nas pessoas mais fortes: alguns engenheiros fluentes em AI a elevar toda a organização.

Isto produz dois resultados em simultâneo. A utilização aumenta porque as equipas seguem padrões comprovados em vez de andarem a adivinhar. E recupera-se uma grande quantidade de tempo que se perde silenciosamente em experimentação que nunca deveria ter sido necessária mais do que uma vez.

Acompanhe

Pode acompanhar o trabalho de Pedro Alves no LinkedIn ou subscrever a sua newsletter, Last Week in AI. E não deixe de conhecer a Thoth AI.

Haverá mais entrevistas com especialistas no The CTO Club!