Gemini Robotics 2: o que os números da DeepMind mostram

O que o Gemini Robotics 2 realmente é

A nomenclatura não está fazendo nenhum favor a ninguém aqui, então, a versão simples. "Gemini Robotics 2" é o nome da família e também o nome de um modelo específico dentro dessa família. Três modelos foram lançados juntos no mesmo dia, e cada um faz um trabalho diferente.

Essa divisão importa, porque é a mesma arquitetura que eu desenharia para qualquer sistema de agentes sério. Um modelo raciocina sobre o que fazer, e acompanha se funcionou. Uma peça separada, mais rápida, faz a execução. A DeepMind é explícita ao dizer que o ER 2 "passa a execução dos motores para qualquer modelo de visão-linguagem-ação (VLA) de nível inferior dado", ou seja, o planejador permanece deliberadamente agnóstico em relação às mãos.

Um detalhe na documentação reformula tudo isso: o ER 2 é construído sobre o Gemini 3.5 Flash. Não é uma derivada de nível Pro. Também não é uma arquitetura sob encomenda. É um modelo de classe Flash, com raciocínio espacial, localização de momentos em vídeo e orquestração multirrobô ajustados nele. Quem acompanhou o Gemini 3.6 Flash já sabe mais ou menos como é o orçamento de computação por trás disso, e a linha Flash-Lite conta a mesma história.

O trabalho de apontar e de coordenadas vem da mesma linhagem da visão agêntica do Gemini. E se você está avaliando a família como um todo, eu mantenho uma lista atualizada de alternativas ao Gemini.

A afirmação de controle de corpo inteiro é real, e vale a pena esclarecer isso. Versões anteriores controlavam apenas a parte superior do corpo do humanoide, para trabalho de mesa. Esta também controla as pernas. O prompt de demonstração que a DeepMind publicou é "coloque o regador na caixa verde da estante de baixo", e o Apollo 2 da Apptronik caminha até a mesa, pega o regador, vai até as estantes e o coloca. O mesmo checkpoint do modelo também controla um Franka Duo equipado com garras de dois dedos, que é a parte mais discretamente impressionante disso tudo.

Os números que a DeepMind publicou sobre si mesma

Aqui está a tabela completa, exatamente como a DeepMind a reportou. Os três grupos de habilidades correm sobre um único checkpoint compartilhado, em três corpos de robô diferentes, e é por isso que a dispersão aqui é interessante em vez de constrangedora.

Leia o topo e a base do grupo de vários dedos juntos, porque esse único par conta toda a história de onde o aprendizado robótico está em 2026. Desparafusar uma lâmpada é 92%. Parafusar uma é 36%. Ambos usam a mesma mão SharpaWave de cinco dedos e 22 graus de liberdade, no mesmo robô. O que muda é o movimento. Desparafusar é solto e tolerante; parafusar exige manter um alinhamento enquanto se aplica torque. Um é uma pegada. O outro é um problema de controle.

O grupo de garra supera o grupo de mãos em quase tudo, e esse é o segundo dado que vale a pena parar para considerar. Uma garra Robotiq de dois dedos no Franka Duo atinge 89,6% em inserção de precisão, enquanto a mão antropomórfica só consegue 40% em um saco ziplock. Mais graus de liberdade compraram resultados piores no trabalho fino. Pelo menos por agora.

E a própria DeepMind disse isso. A legenda do gráfico diz: "Embora o Gemini Robotics 2 alcance uma taxa de sucesso média a alta em tarefas destras de corpo inteiro e baseadas em garra, a manipulação destra com vários dedos continua sendo um desafio." Em outro ponto da mesma página: "nossos robôs ainda têm mais a avançar em velocidade de movimento", com a destreza em nível humano formulada como uma meta, não como uma afirmação.

Por que um único número combinado teria escondido tudo isso

Faça a média dessas cinco tarefas de vários dedos em um único número e você chega em algum ponto na metade dos quarenta, sem ter aprendido nada. Você não saberia que o modelo está quase resolvido em um movimento e mal funcional em outro. Também não saberia em torno de qual tarefa evitar projetar seu produto.

Isso não é um problema de robótica, de forma alguma. É o estado padrão do marketing de IA em qualquer categoria, incluindo a minha, em que um único número de desvio de nível 1 esconde exatamente a mesma dispersão. Mova você mesmo os números e veja como é fácil direcionar a manchete:

Tente "Só as 4 favoráveis" e sai um número que qualquer equipe de marketing imprimiria com prazer. Mesmo modelo, mesmo dia, mesmo laboratório. Absolutamente nada foi fabricado para produzi-lo. Esse é o truque, e está disponível para qualquer fornecedor que reporte um único número.

O número mais interessante é sobre humanos, não sobre robôs

Enterrada nos benchmarks do ER 2 há uma comparação que a DeepMind executa de três formas. Ela mede o quão bem o modelo de raciocínio direciona um executor posterior, e o que muda é esse executor: primeiro um robô real, depois um simulado, depois um teleoperador humano.

O mesmo planejador é 14 pontos melhor dirigindo uma pessoa do que dirigindo um robô. O modelo não é pior em nenhum dos dois casos. O humano do outro lado simplesmente absorve a ambiguidade, se recupera de uma pegada ruim, completa qualquer intenção que a instrução deixou de fora.

Um comentarista do Reddit assistindo às imagens da demonstração chegou à mesma conclusão a partir de fora:

"The bottleneck seems to be software. So until we get ai good enough to pilot a robot, it's going to remain slow.

If you see robots piloted by humans, they are much faster."

u/dranaei, Reddit

Essa é a descoberta que eu colaria em uma parede, e não é realmente uma descoberta de robótica. É o argumento do copiloto de IA com um número anexado. Um modelo que planeja e depois passa para um humano capaz supera o mesmo modelo controlando o efetuador final por conta própria, e a diferença é mensurável. No trabalho de suporte, essa é a diferença entre um agente que redige uma resposta para alguém enviar, contra um agente que responde por conta própria. A resposta honesta sobre qual tem melhor desempenho é a mesma da DeepMind: a que tem uma pessoa no ciclo, até que os números por tarefa digam outra coisa.

Nada disso é um argumento contra a autonomia. É um argumento a favor de conhecer o número antes de escolher, e esse número muda rápido, rápido o suficiente para que os melhores agentes de IA de seis meses atrás não sejam os que você escolheria hoje.

O restante do conjunto de comparação do ER 2 é forte, e vale a pena reportá-lo de forma justa:

A classificação de progresso é a maior margem de toda a página: 57,4% contra 46,2% do melhor modelo não robótico. A métrica é "você consegue dizer até onde chegou em uma tarefa", pontuada por quadro em cinco categorias. Nada glamoroso, e é exatamente o que um agente precisa saber antes de decidir se continua ou pede ajuda. A DeepMind também reporta 91,3% de precisão na localização de momentos, com uma distância média absoluta de 0,96 segundos, a 4 vezes a velocidade de execução das categorias de modelos maiores.

Também vale notar que esses mesmos 57,4% significam que ele erra o progresso mais ou menos quatro em cada dez vezes. O melhor da categoria, e ainda assim erra com essa frequência, o que é um estado normal neste campo. É também exatamente o tipo de coisa que uma afirmação de uma linha sobre "estado da arte" apaga.

O salto de segurança sobre o qual ninguém está falando

Esse é o número que me fez sentar reto. Ainda não vi isso coberto em nenhum lugar.

O Gemini Robotics ER 1.6 seguia instruções de segurança 47,2% das vezes. Esse modelo foi lançado em abril de 2026, ou seja, quatro meses atrás, e ficou abaixo do Opus 5 e do GPT 5.6 Sol em ambas as métricas de segurança. Um modelo ajustado para robótica, pior em segurança robótica do que os modelos de texto de uso geral contra os quais foi comparado.

O ER 2 corrige isso a fundo, chegando a 97,9% e 93,0%. Bom. A leitura útil, porém, é o que o número da geração anterior diz sobre confiar em um rótulo de versão. "O modelo de robótica mais recente de um laboratório de ponta" era, até a semana passada, algo que seguia uma restrição de segurança menos da metade das vezes. A DeepMind também lançou um novo benchmark para isso, o ASIMOV-Agentic, publicado como um conjunto de dados público. Ele mede se o agente de raciocínio vai rejeitar uma chamada de ferramenta insegura, se consegue prever que uma tarefa é impossível, e depois se pede ajuda a um humano quando não tem certeza.

Rejeitar, prever a falha, escalar quando há incerteza. Isso é uma melhor descrição de um agente de suporte bem construído do que a maioria da documentação de IA de suporte consegue, e se aplica diretamente à gestão de escalonamento. A transferência é uma disciplina própria além disso, e a transferência de chat é o caso que a maioria das equipes erra primeiro.

Vale a pena ser preciso sobre os limites aqui. O blog afirma que o ER 2 é o modelo de robótica mais seguro da DeepMind até hoje, mas não publica nenhuma pontuação numérica para os próprios resultados do ASIMOV-Agentic. Esses estão em um relatório técnico de segurança separado. E a documentação para desenvolvedores é direta sobre onde cai a responsabilidade: "é sua responsabilidade manter um ambiente seguro em torno do robô".

O que custa, e as pegadinhas na documentação

Só o ER 2 tem preço. Os dois modelos que tocam hardware não têm nenhum, pela simples razão de que você não pode comprá-los.

O preço dobrou. O ER 2 custa 2x o ER 1.6 tanto na entrada quanto na saída, embora a tarifa fixa de entrada signifique que trabalhos com muito áudio vejam um aumento relativo menor do que trabalhos com muita visão. A janela de contexto não cresceu nada. Também há um modelo irmão de streaming, gemini-robotics-er-2-streaming-preview, com a mesma tarifa principal, sem nível Batch e sem cache.

Quatro coisas na documentação que vão te custar uma tarde se você não as ler antes:

1. Uma chave de API sem restrições recebe um 403 direto. Robótica é a única superfície do Gemini que rejeita uma chave padrão, então adicione restrições no AI Studio antes da sua primeira chamada.
2. O endpoint de streaming limita a entrada de imagem a JPEG, 1 quadro por segundo. O que parece estranho contra todo o discurso de tempo real. Um robô transmitindo quadros de câmera a no máximo um por segundo.
3. O endpoint de streaming abandona saídas estruturadas e execução de código. Então o caminho de esquema JSON pertence ao modelo sem streaming, e o caminho de visão agêntica também.
4. A documentação recomenda um nível de raciocínio medium para latência, mas o exemplo de introdução vem com high. Copie e cole dele, e você herda o padrão lento.

Também há um aviso de privacidade anexado a esses modelos que nenhuma página comum do Gemini carrega. Como os modelos "utilizam dados de vídeo e áudio para operar e mover seu hardware", o Google exige que você não deixe pessoas identificáveis presentes em torno do robô até que tenham sido notificadas e dado consentimento, e pede ainda um borrão facial. Coloque isso ao lado do "usado para melhorar nossos produtos: sim" do nível gratuito. Um robô de nível gratuito com uma câmera apontada para pessoas se torna então um problema de consentimento, não de cota.

E uma nota de agenda que vale a pena anotar: gemini-robotics-er-1.6-preview desativa em 31 de agosto de 2026. O ER 1.5 já foi retirado em abril. Então, dois endpoints retirados em um ano, e todo código de modelo atual ainda carrega um sufixo -preview, sem nenhum alias estável para fixar.

Adaptação a novos robôs, e a parte multirrobô

O Gemini Robotics On-Device 2 é a peça que considero a mais discretamente significativa. Ele roda localmente, herda o trabalho de transferência de movimento do Gemini Robotics 1.5, e se adapta a um robô de dois braços completamente novo "com apenas algumas horas de tempo de adaptação, tipicamente com menos de 200 exemplos". Formas novas, sensores novos, graus de liberdade que não coincidem.

Menos de 200 demonstrações para colocar em funcionamento um novo corpo de robô, esse é o número que muda a economia do campo. As tarefas dessa grade rodaram em plataformas Dexmate, SO101 e Trossen, nenhuma delas o humanoide principal. Um dos painéis mostra um braço robótico clicando em uma caixa de seleção "eu sou um robô", o que eu presumo ser uma piada, e que eu aprecio.

A colaboração multirrobô é a outra capacidade nova. Robôs que se comunicam, reconhecem as forças físicas um do outro, e depois delegam tarefas entre si. Na demonstração, um humanoide Apollo 2 trabalha ao lado de um braço Franka, com um monitor mostrando o que o modelo vê.

A DeepMind agradeceu à Apptronik, Boston Dynamics e Agile Robots como parceiras, e em uma demonstração separada, um Spot da Boston Dynamics busca pipoca por meio de APIs orquestradas do Spot. Do lado do hardware: a Apptronik levantou uma Série A-X de 520 milhões de $ em fevereiro de 2026, o que leva seu total a quase 1 bilhão de $. Vale ressaltar que o Apollo 2 é uma plataforma de coleta de dados, e não a unidade comercial. A comercial é o Apollo 3, e não tem data anunciada. Sem especificações publicadas e sem preço publicado, de nenhum dos quatro fornecedores de hardware envolvidos.

O que os profissionais realmente disseram

A thread do Hacker News chegou a 619 pontos e 553 comentários, e é uma leitura melhor do que qualquer uma das coberturas. O comentário mais útil ali veio de alguém que trabalha nesses modelos:

"Plus we have no good reliable accuracy testing data in most cases (most tests occur on a few demos, but that isn't a good representation of how must things work), popular benchmarks, such as libero have been saturated, and nearly everything gets 95% there, most companies and researchers have their own benchmarks here."

adityashankar, Hacker News

Benchmarks saturados, e todo mundo corrigindo seu próprio dever de casa. Isso descreve também a avaliação de IA de software, quase palavra por palavra, e é por isso que a própria orientação de avaliação da OpenAI se apoia tanto em construir seu próprio conjunto de avaliação em vez de confiar em um ranking público.

A crítica mais afiada não é sobre o modelo, de forma alguma. É sobre a gramática do vídeo:

"This is why we need long continuous shots of robots interacting doing tasks, rather than the sizzle reels with 5 second shots. The long shots tell the true story of how far along the technology is, while the short shots make it look way more advanced than it really is. Still, great to see the progress being made."

u/edgroovergames, Reddit

Um comentarista do HN foi ainda mais longe, chamando as demonstrações de "pick and place glorificado com baixas taxas de sucesso em um robô inutilmente complexo", e dizendo que preferiria as imagens abertamente teleoperadas de um concorrente, porque estavam mais próximas de uma implantação real. Duro. Também não é irracional, dado o 45,7%.

Esse número de 36% então foi usado como evidência para um argumento mais amplo:

"A 36% success rate on screwing in a light bulb means there's probably something to LeCunn's take that VLM/VLA models aren't going to be the thing powering tomorrow's robots, but only time will tell."

cowboy_henk, Hacker News

A melhor réplica veio em uma linha, e é a que eu apostaria:

"It's still very early days. There are many benchmarks that LLMs scored 36% on just 18 months ago that they're now at 100% on."

heaney-555, Hacker News

E então um roboticista, explicando por que "lento e cuidadoso" é uma classe de problema diferente de "rápido e fluido":

"An algorithm to fold tshirts 90% of the time is easy. The cloth hangs down by gravity and you can just look for right angles (corners), find their coordinates with binocular matching, and move them to meet each other. Getting 99%, or folding them quickly, so that the fabric is actually moving instead of just hanging still- incredibly, incredibly more complex."

hwillis, Hacker News

Havia também uma boa dose de "o Figure já não tinha mostrado isso?" ali, o que me leva à comparação que realmente importa.

Ninguém mais publica essa tabela

Fui procurar os números equivalentes por tarefa de todos os outros laboratórios nesse espaço. Aqui está o que é público, tudo isso.

A DeepMind é a única que colocou taxas de falha absolutas por tarefa em sua própria página de lançamento. A Figure nomeia tarefas de destreza e mostra uma execução de quatro minutos com uma lava-louças em vídeo, sem anexar nenhum número a nada disso. A Tesla nunca nomeou um modelo Optimus, nunca mesmo. A Physical Intelligence até grafica taxas por tarefa, mas contra uma linha de base de especialista em RL, e com os valores renderizados no lado do cliente em vez de declarados.

Então a leitura honesta do Gemini Robotics 2 não é "o robô do Google está atrás". O Google é o único que mostra onde seu robô realmente está, e depois é criticado pelos números que escolheu divulgar. Esse é um incentivo ruim. Se isso persistir, o próximo laboratório vai simplesmente publicar vídeos.

O que isso significa se você está comprando agentes de IA

Eu não trabalho com robôs. Eu construo agentes de IA que lidam com tickets de suporte, e esse lançamento mudou sim o que eu penso que um fornecedor deveria ser obrigado a me mostrar.

Havia um cliente, uma equipe dinamarquesa B2B de telemática veicular processando cerca de 200 tickets por mês no Zendesk e escalando para 2.000, cujo agente começou a dizer com confiança aos clientes "sim, damos suporte ao seu modelo de carro" para marcas que não estavam no banco de dados deles. A base de conhecimento dizia "damos suporte a todos os modelos". O bot acreditou. O próprio resumo deles dessa configuração inicial foi "tentativa e erro no começo". Esse tipo de ticket teria pontuado um zero absoluto em uma tabela por tarefa, e no número combinado ele era simplesmente invisível. Essa é a forma de falha comum na automação do atendimento ao cliente, nada exótico, e é por isso que a prevenção de alucinações é mais uma questão de configuração do que de modelo.

É por isso que todo rollout da eesel roda primeiro uma simulação contra o próprio histórico de tickets do cliente. Pega-se um lote de tickets resolvidos, gera-se o que o agente teria dito, compara-se isso com o que o humano realmente enviou, pontua-se, e então se produz um relatório de lacunas antes que um único cliente real esteja envolvido. É a tabela da DeepMind, só que construída a partir dos seus tickets em vez de lâmpadas. Uma líder de CX em uma marca de suplementos D2C formulou essa exigência melhor do que eu conseguiria:

"The AI will never be able to answer 100% of the questions... I need an AI who is only handling the tickets that it's confident to handle and all the other ones, leave them alone."

Três coisas que eu levaria desse lançamento para qualquer compra de agente de IA, física ou não:

1. Peça a tabela por tarefa, não a manchete. Quando um fornecedor cita um único número de desvio, peça que seja dividido por intenção ou por tipo de ticket. A verdade está na dispersão, e as métricas de desempenho de IA só são úteis nesse nível de granularidade. O mesmo se aplica à resolução no primeiro contato.
2. Teste no seu próprio histórico antes de ir ao ar. Um benchmark rodado nas tarefas de outra pessoa não prevê nada sobre os casos extremos da sua política de reembolso. O mesmo instinto dos testes adversariais, e a razão pela qual avaliar agentes é melhor do que confiar em uma demonstração.
3. Projete para a tarefa de 32%, não a de 92%. Saiba qual trabalho o agente deveria rejeitar. Defina limiares de confiança deliberadamente, mantenha a transferência limpa. Prevenir uma resposta errada dita com confiança vale mais do que um ponto de cobertura.

Esse último ponto é o jogo todo. Um agente que resolve 60% dos tickets e depois escala de forma limpa o resto é um produto melhor do que um que tenta 100% e erra em um de cada cinco, e os clientes me dizem isso constantemente. A matemática do custo por resolução também funciona melhor, uma vez que você precifica os tickets que uma resposta ruim cria.

Se você quiser o quadro de medição mais completo, meu artigo sobre avaliação do atendimento ao cliente vai mais a fundo do que eu posso aqui, assim como a comparação de custo de agente versus humano. E se você ainda está escolhendo um modelo de base, qual LLM é melhor para suporte é uma pergunta de partida melhor do que qualquer benchmark de robótica.

Experimente a eesel

Se você está buscando um software de atendimento ao cliente agêntico, e quer a honestidade por tarefa que este post defende sem parar, é mais ou menos para isso que a eesel foi construída. Ela se conecta ao Zendesk ou a qualquer helpdesk que você já use, Freshdesk incluso. Ela aprende com seus macros e seus tickets passados. Depois ela roda uma simulação sobre seu histórico real, então você consegue ver a forma da precisão dela por tipo de ticket antes que ela responda a um único cliente.

A diferença concreta: você decide quais tipos de ticket ela toca e quais deixa em paz, e você recebe contagens de aprovação e rejeição por ação em vez de uma única porcentagem de desvio. A Gridwise viu 73% das solicitações de nível 1 resolvidas no primeiro mês, e sabia quais eram os 27% que não foram. O preço é por ticket, então você não está comprando lugares para um agente que só lida com uma fração da fila.

Experimente a eesel gratuitamente, ou apenas aponte-a para cem dos seus tickets antigos e veja o que o relatório de lacunas diz.