Google lança API para escolha de ações com latência de 150–250 ms

A fila de chamados do suporte cresceu, e o LLM precisa decidir para onde enviar cada um: pagamento, departamento técnico ou gerente. Por causa de uma única escolha, a equipe configura a geração de JSON, valida o formato e trata as respostas malsucedidas. O Google oferece uma API separada para esse tipo de tarefa: o desenvolvedor define as opções permitidas e o modelo devolve a probabilidade de cada uma. É um candidato útil para experimentos onde o produto precisa escolher rapidamente a próxima ação.

No anúncio do Google, o novo serviço se chama Gemini Decisions API, e o modelo, Gemini Decision 1. Ele avalia as respostas propostas em uma única passada. A latência declarada é de 150–250 ms, mas há uma ressalva importante: as medições apresentadas se referem a contextos de até 16 mil tokens. Seria um erro transferir essa velocidade para qualquer documento longo.

Como isso aparece no produto

Imagine um serviço que triagem solicitações de clientes. Chega um e-mail com a captura de tela de uma cobrança. O desenvolvedor define três direções: dúvida sobre pagamento, problema técnico, outro. Também é possível perguntar se a solicitação exige reação urgente. Essas verificações dizem respeito ao mesmo material, por isso é conveniente reuni-las em uma única requisição.

Daí em diante vem a lógica de produto habitual. Se a pontuação da direção escolhida estiver acima do limiar definido, o chamado vai automaticamente para a fila certa. Se a confiança for insuficiente, ele é encaminhado a um operador. Por exemplo, a equipe pode começar com um limiar de 95% e depois ajustá-lo conforme os resultados da validação. É um exemplo hipotético de configuração, não um valor recomendado pelo Google.

A API aceita perguntas de «sim ou não», escolha em uma lista e avaliação em uma escala definida. Entre os formatos de entrada estão texto, imagens, áudio, vídeo e PDF. O sentido prático da multimodalidade é claro: o e-mail e a captura de tela anexada podem ser analisados em conjunto, preservando detalhes importantes para a decisão.

Ainda assim, o desenvolvedor terá de descrever as opções com clareza suficiente. Se duas categorias se sobrepõem, a mera existência de probabilidades não corrige a classificação. Primeiro é preciso definir qual é a diferença entre uma solicitação de reembolso e uma contestação de cobrança e só depois automatizar a distribuição.

O que verificar por trás das promessas de velocidade e preço

O Google indica o preço de US$ 0,10 por milhão de tokens de entrada e nenhuma cobrança pelos de saída. O material comum é pago uma vez por requisição, enquanto as perguntas adicionam suas próprias instruções e critérios. O serviço permite fazer até 1000 perguntas sobre uma mesma entrada; o contexto máximo é de 256 mil tokens.

Para a equipe, é um motivo para calcular o custo da sua operação específica. Quanto espaço a instrução ocupa? Quantas perguntas são realmente necessárias? Com que frequência o resultado terá de ser revisto por uma pessoa? Uma chamada barata pode render pouca economia se, depois dela, continuar existindo uma grande fila manual.

A afirmação sobre redução de custo de cinco vezes também exige contexto. Na fonte original, o Google compara o serviço com o Gemini 3.5 Flash-Lite em um conjunto geral de testes. Isso não é uma promessa de reduzir em cinco vezes os gastos de qualquer aplicação. Para o seu próprio cálculo, são necessários o modelo atual, documentos reais e requisitos de qualidade equivalentes.

A probabilidade precisa ser verificada com os seus dados

A parte mais interessante dessa interface é a possibilidade de controlar a automação por meio do limiar. Mas o número 95% na resposta ainda precisa ser comparado com a proporção real de decisões corretas nas suas solicitações. É especialmente útil verificar separadamente categorias raras e casos ambíguos: são eles que costumam gerar erros caros.

Eu começaria por uma operação restrita, como a distribuição de chamados entre departamentos. Reuniria uma amostra rotulada, compararia a API com a solução atual e observaria três indicadores: erros de roteamento, tempo de resposta e a parcela de solicitações que permanece com o operador. Depois disso, é possível escolher um limiar de trabalho.

Para o product manager, o resultado desse teste é muito mais útil do que uma tabela geral de benchmarks. Ele mostrará quantos chamados podem ser tratados automaticamente com um número aceitável de erros. E dará ao desenvolvedor uma base concreta para decidir se vale a pena incluir o novo serviço no sistema de produção.