Gemini 4 Argon: quem revisa uma saída de um milhão de tokens?

O Google anunciou o Gemini 4 Argon em 30 de setembro, com um limite de saída de um milhão de tokens, ante os 64K anteriores. O anúncio não especifica aqui se os tokens de raciocínio contam para esse limite. É um teto anunciado, não uma prova de um milhão de tokens de trabalho final e útil. [1]

Nosso argumento é que um orçamento maior de geração torna o planejamento do aceite mais importante. Uma equipe talvez possa solicitar uma mudança maior, mas alguém ainda precisa decidir o que foi concluído, o que foi verificado e o que pode entrar em uso com segurança. Essas são questões diferentes de quanto um modelo pode emitir.

Considere uma migração hipotética de repositório. Uma execução longa poderia produzir código, testes, documentação e um registro de alterações. Mais saída poderia reduzir interrupções, mas também deixar mais material para conciliar. O benefício depende de quanto desse material se torna uma mudança aceita; não testamos esse cenário com o Argon.

Antes de uma execução, defina a entrega e suas evidências: quais componentes devem mudar, quais testes devem passar, quais interfaces devem continuar compatíveis e quem aprova. Uma tarefa deve poder terminar bem abaixo do seu teto de saída. Consumir todo o orçamento disponível não é um critério de conclusão.

O mesmo raciocínio se aplica a um conjunto de materiais de pesquisa ou a um lote de conteúdo. As citações devem sustentar as afirmações, os registros devem concordar e as revisões devem preservar o sentido pretendido. Uma geração mais longa não transforma uma afirmação sem fundamento em evidência. Meça resultados utilizáveis e revisados, em vez de comemorar o tamanho de uma transcrição.

A página do modelo do Google informa 77,9% no DeepSWE v1.1 e 55,0% no FrontierSWE v2. São avaliações de programação diferentes. Elas não podem ser interpretadas como uma taxa universal de conclusão para seu repositório. A tabela também distingue as faixas de contexto do GraphWalks, que dizem respeito à entrada, não ao comprimento da saída. [2]

A metodologia usa 650 itens do GraphWalks com até 128K de contexto e 200 entre 256K e um milhão. Os resultados do Argon geralmente usam a configuração mais alta de raciocínio e pass@1, com exceções: o OSWorld informa uma pontuação parcial offline e considera o melhor resultado de três execuções. Alguns resultados comparativos vêm de outros fornecedores ou de classificações. [3]

Não encontramos nessa metodologia um teste de aceite de ponta a ponta para uma saída de um milhão de tokens. Isso é uma limitação das evidências revisadas, não uma afirmação de que esse trabalho seja impossível. Ganhos nas avaliações justificam investigar cargas de trabalho específicas; eles não eliminam a necessidade de testar correção, omissões e recuperação nas suas próprias condições.

Uma abordagem prática é dividir o aceite em unidades sem presumir que o modelo precise parar depois de cada uma. Em uma migração, essas unidades podem ser um módulo, seus testes e suas evidências de compatibilidade. Em um lote editorial, podem ser um artigo, suas fontes e sua revisão aprovada. Cada unidade precisa de um resultado identificável.

Use automação onde o sucesso puder ser verificado mecanicamente: verificações de compilação, validação de esquemas, detecção de duplicatas ou um inventário de arquivos obrigatórios. Reserve a revisão humana para significado, decisões importantes e afirmações que um teste mecânico não pode resolver. Uma compilação bem-sucedida responde a uma pergunta mais restrita do que se a mudança solicitada está correta.

A revisão deve mostrar o que continua inacabado. Uma passagem de trabalho útil lista as unidades aceitas, as rejeitadas, as dependências não resolvidas e o motivo do encerramento da execução. Caso contrário, um resumo final impressionante pode esconder trabalho parcial. O revisor precisa de evidências anexadas ao resultado, não apenas da garantia do modelo de que tudo foi feito.

Um trabalho longo precisa de condições explícitas de parada: limite de tempo, teto de custo, excesso de falhas repetidas ou uma decisão que exija nova autorização. Esses são controles de fluxo de trabalho recomendados; não estamos afirmando que o Argon ofereça uma API específica para eles.

Mantenha um ponto de controle recuperável antes de mudanças importantes. Registre qual saída foi aplicada e qual é apenas proposta, para que uma execução posterior não repita uma ação nem dependa de um resultado não aceito. Se a execução falhar no meio do caminho, a recuperação deve partir de um estado verificado, não da última frase otimista.

Conte o custo da revisão e da correção junto com o da geração. Um modelo pode ser mais barato por token e ainda produzir mais trabalho para inspecionar. Compare o tempo e o esforço totais por entrega aceita, incluindo execuções que falharam. O orçamento certo compra progresso confiável, não a maior quantidade de material gerado.

Na verificação, o acesso ao Argon pelo Fairwind estava restrito a parceiros confiáveis aprovados. Isso não equivale a acesso público geral. Equipes fora do programa não devem presumir que a publicação de uma página do modelo significa que podem implantá-lo hoje. [4]

Enquanto espera por um acesso para o qual seja elegível, prepare um pequeno conjunto de avaliação com trabalhos concluídos que você tenha permissão para usar. Inclua casos rotineiros, dependências difíceis e casos em que a resposta correta seja parar. Mantenha o fluxo de trabalho existente como referência e defina o aceite antes de ver a resposta do novo modelo.

Se o acesso ficar disponível, compare as mesmas tarefas, ferramentas e permissões. Registre o aceite na primeira execução, as correções, as omissões e o esforço de recuperação. Um orçamento maior de saída vale a pena se melhorar essas evidências. Não verificamos a disponibilidade do Argon pelo RouterShift e não afirmamos aqui que o produto o ofereça.

A objeção mais forte a mais pontos de controle é que eles podem interromper trabalhos que se beneficiam de uma única trajetória longa. É uma escolha de projeto com custos e benefícios reais. Pontos de controle e revisão não precisam fragmentar toda geração; um sistema pode preservar uma execução longa enquanto produz artefatos inspecionáveis ao longo dela.

Este artigo não pode estabelecer se o Argon melhorará um fluxo de trabalho empresarial específico. Não executamos o modelo, reproduzimos suas avaliações nem verificamos como o raciocínio é contabilizado no limite de saída. Nossa recomendação é uma forma de avaliar trabalhos longos, não uma conclusão sobre desempenho.

A possível mudança é passar de revisar uma resposta a aceitar um conjunto de trabalho. Mais capacidade amplia o que um modelo pode tentar. A adoção profissional dependerá de as equipes conseguirem ver, verificar e recuperar o que ele realmente entregou.