Conheça o Escritor: Ashton Chew, Engenheiro Fundador da Theta

Vamos começar! Conte-nos um pouco sobre si. Por exemplo, nome, profissão e interesses pessoais.

Olá! O meu nome é Ashton, e sou engenheiro fundador na Theta onde trabalho com infraestrutura de RL, RL e sistemas distribuídos. Foco-me especificamente no uso de computadores e uso de ferramentas. No meu passado, trabalhei na Amazon AGI e abordei infraestrutura de inferência e uso de ferramentas. No meu tempo livre, adoro design gráfico, projetos paralelos e escalada em bloco.

Interessante! Sobre o que foi a sua última história de destaque no Hackernoon?

A minha última história, "Será que a sua IA realmente consegue usar um computador? Um mapa de 2025 dos benchmarks de uso de computador", abordou um dos espaços mais quentes em VC neste momento: ambientes de RL e avaliações. Dei uma visão abrangente dos benchmarks de uso de computador mais utilizados, além de conselhos práticos sobre como escolher benchmarks para treinar e testar agentes de uso de computador.

Continuei a encontrar a mesma lacuna: não há muitos artigos que analisem os próprios benchmarks. E à medida que este campo cresce, é vital que estejamos realmente a avaliar a qualidade em vez de recompensar o que acontece ao manipular a métrica. Já estivemos aqui antes. Nos primeiros dias dos LLMs, os benchmarks eram suficientemente aleatórios e díspares que apenas refletiam fracamente o verdadeiro vencedor.

Os benchmarks tornaram-se no quadro de pontuação de facto para o "melhor modelo", e depois as pessoas perceberam que muitos deles não estavam a medir o que afirmavam.

Uma das falhas mais reveladoras da era inicial foi quando a "compreensão de leitura" se tornou silenciosamente em "correspondência de padrões na estrutura do conjunto de dados". Os investigadores executaram linhas de base intencionalmente provocativas (apenas pergunta, apenas última frase), e os resultados foram suficientemente altos para levantar uma possibilidade desconfortável: o benchmark não forçava consistentemente os modelos a usar a passagem completa. Numa crítica de 2018, o ponto não era que a leitura nunca importa, mas que alguns conjuntos de dados acidentalmente tornaram-na opcional ao recompensar excessivamente atalhos como recência e estereótipos de respostas anteriores.

\

# Tarefa suposta: responder à pergunta dada a passagem e pergunta Passagem (resumo): - Frases 1–8: O dia de John na escola (detalhes maioritariamente irrelevantes) - Frase 9: "Depois da escola, John foi para a cozinha." - Frase 10: "Ele comeu uma fatia de pizza antes de começar os trabalhos de casa." Pergunta: "O que é que o John comeu?" Resposta: "pizza"

O benchmark recompensa acidentalmente um atalho onde o modelo sobrevaloriza a última frase (porque a resposta está frequentemente perto do fim) e simplesmente extrai o objeto direto da ação mais recente ("comeu ___"), que neste caso resulta em "pizza".

E depois vem a linha de base ainda mais prejudicial: remover a passagem completamente e ver o que acontece. Se um modelo apenas com pergunta for competitivo, é um sinal de que o conjunto de dados está a vazar sinal através da repetição e conhecimentos prévios em vez de testar a compreensão baseada na passagem.

Pergunta: "O que é que o John comeu?"

Esta linha de base é basicamente uma verificação de sanidade: pode o modelo ainda pontuar bem apoiando-se em modelos de resposta de alta frequência sem se basear na passagem? Na prática, apenas adivinha um token que o conjunto de dados recompensa desproporcionalmente ("pizza", "sanduíche"), e se isso funcionar mais frequentemente do que deveria, não está a medir a compreensão tanto quanto está a medir os conhecimentos prévios do conjunto de dados.

As avaliações de uso de computador já produziram um atalho ainda mais literal: o agente tem um navegador, o benchmark é público, e a avaliação transforma-se num exame de livro aberto com uma chave de respostas na página final. No artigo do Holistic Agent Leaderboard (HAL), os autores relatam ter observado agentes que pesquisaram pelo benchmark no HuggingFace em vez de resolver a tarefa, um comportamento que só se apanha se inspecionar os registos.

\

# Tarefa suposta: completar um fluxo de trabalho dentro do ambiente web Tarefa: "Configurar a definição X na aplicação e verificar se está ativada." Modo de falha: 1) Abrir um novo separador 2) Pesquisar por: "estado ativado esperado do benchmark X" / "HAL <benchmark> definição X" 3) Encontrar: repositório / descrição da tabela de classificação / cartão do conjunto de dados / tópico de problemas 4) Reproduzir o estado final esperado (resposta)

Nesse ponto, a avaliação estava a medir se consegue localizar a chave de resposta.

Tarefa: "Encontrar a página correta e extrair Y." Modo de falha: - Pesquisar: "<nome do benchmark> Y" - Copiar de um artefacto público (documentos, post de fórum, cartão do conjunto de dados) - Colar o valor na saída do agente como se viesse da interação

Se um agente consegue extrair o valor de um cartão de conjunto de dados ou repositório e ainda "passar", a verificação de sucesso está a classificar a plausibilidade, não a correção da interação. Tarefas públicas mais verificação superficial transformam a pesquisa web num exploit.

Estes dois exemplos são o tiro de aviso: se não mantivermos os benchmarks de uso de computador a padrões mais elevados desde cedo, repetiremos a era LLM apenas com melhores interfaces e formas mais elaboradas de fazer batota.

Costuma escrever sobre tópicos semelhantes? Se não, sobre o que costuma escrever?

Sim! Trabalhando nos ambientes de RL e infraestrutura de RL em torno do uso de computador, estou constantemente rodeado pelos melhores modelos de uso de computador e os ambientes de treino mais realistas. Por isso escrevi outro artigo, "O ecrã é a API", que é o caso para o uso de computador e porque é o futuro dos modelos de IA.

Este espaço é extremamente sub-reportado devido a duas razões:

1. Os modelos não são tão capazes no uso de computador como são noutras tarefas (codificação, matemática, etc.).
2. O uso de computador está em rápida evolução e é extremamente novo.

Quero mudar isso.

Ótimo! Como é a sua rotina habitual de escrita (se tiver uma)

Normalmente leio um monte de artigos de investigação e falo com os meus colegas da indústria sobre os seus pensamentos sobre um tópico. Além disso, passo muito tempo a ler artigos de grandes bloggers como PG. Por isso, normalmente tiro muita inspiração de outras pessoas na minha escrita.

Ser escritor em tecnologia pode ser um desafio. Frequentemente não é o nosso papel principal, mas um complemento a outro. Qual é o maior desafio que tem quando se trata de escrever?

Encontrar o tempo para me sentar e colocar a minha experiência vivida em palavras.

Qual é a próxima coisa que espera alcançar na sua carreira?

Enfrentar problemas mais difíceis com pessoas excelentes, aprender com essas pessoas e partilhar as minhas experiências.

Uau, isso é admirável. Agora, algo mais casual: Qual é o seu prazer culpado de eleição?

Ver filmes! O meu filme favorito neste momento é Catch Me If You Can (2002).

Tem algum hobby não relacionado com tecnologia? Se sim, qual é?

Adoro escalada em bloco porque me faz sentir como se fosse um agente humano de uso de computador a interagir com a parede de escalada. Estou a brincar. Acho que a escalada em bloco é muito divertida porque me permite desligar do trabalho e consolidar o meu pensamento.

O que pode a comunidade Hacker Noon esperar ler de si a seguir?

Estou atualmente a escrever outro artigo sobre infraestrutura de ambiente RL!

Qual é a sua opinião sobre o HackerNoon como plataforma para escritores?

Acho que a estrutura de revisão é fantástica, e foi um ótimo lugar para colocar os meus pensamentos perante leitores técnicos.

Obrigado por tirar tempo para se juntar à nossa série "Conheça o escritor". Foi um prazer. Tem algumas palavras finais?

Adoro escrever. Obrigado, HackerNoon!