Google transforma Gemini 3.5 Transcribe numa stack de voz para programadores

A Google lançou o Gemini 3.5 Transcribe, um modelo de conversão de voz em texto concebido especificamente para transcrição em direto e processamento de ficheiros de áudio, e não para raciocínio geral sobre áudio. Os programadores podem aceder-lhe através da Gemini API, com endpoints separados para ficheiros e streaming de baixa latência. A mudança prática é a integração, numa única superfície de modelo, de capacidades que normalmente exigem vários componentes: deteção automática de idioma, mudança de idioma durante a sessão, diarização de oradores, timestamps ao nível da palavra, custom vocabulary biasing e um modo “smart” capaz de transformar fala com hesitações em texto limpo e formatado.

A combinação é relevante para equipas que criam voice agents, sistemas de reuniões, análise de chamadas, ferramentas de acessibilidade, fluxos de media ou qualquer produto em que a fala seja um fluxo de dados de produção. O lançamento não demonstra que o Gemini 3.5 Transcribe é universalmente mais preciso do que sistemas concorrentes, e as alegações de desempenho da Google continuam a ser alegações do fornecedor. No entanto, o comportamento documentado da API altera materialmente o que pode ser construído sem manter pipelines separados para transcrição, diarização, normalização e formatação.

Uma família de modelos para ficheiros e streams em direto

A Google disponibiliza dois identificadores. gemini-3.5-transcribe processa ficheiros de áudio carregados, enquanto gemini-3.5-transcribe-live foi concebido para transcrição em streaming através da Gemini Live API. O endpoint de ficheiros aceita até uma hora de áudio por pedido, embora a ativação de diarização ou timestamps por palavra reduza o limite para 30 minutos. O endpoint live suporta sessões até 10 minutos.

A distinção é útil porque transcrição batch e real-time têm restrições de engenharia diferentes. O processamento de ficheiros pode executar pós-processamento mais completo e devolver etiquetas de orador e timestamps por palavra. O live privilegia saída incremental com baixa latência. A documentação da Google indica que o endpoint live suporta deteção automática de idioma, vocabulário personalizado e smart transcription, mas não diarização nem timestamps ao nível da palavra.

Para os programadores, isto significa que a mesma família pode abranger uma entrevista carregada, uma conversa de suporte em direto ou uma interface de voz, ao mesmo tempo que deixa explícitas as limitações específicas de cada modo.

Multilinguismo e vocabulário especializado entram na API principal

O Gemini 3.5 Transcribe suporta deteção automática em mais de 85 idiomas e pode alternar entre idiomas durante uma sessão. Para produtos destinados a utilizadores multilingues, isto é uma alteração real de workflow: deixa de ser necessário selecionar um único idioma antes de iniciar a transcrição.

O modelo também suporta custom vocabulary biasing com até 1.000 termos. A Google recomenda listas mais curtas para melhores resultados, mas a funcionalidade é importante em áreas onde nomes, acrónimos, códigos de produto, termos médicos, jurídicos ou jargão interno provocam erros recorrentes. Em vez de corrigir depois, a aplicação pode fornecer esses termos no pedido.

A Google documenta diarização até oito oradores em ficheiros, embora a atribuição para três ou mais seja experimental. Também existem timestamps ao nível da palavra, mas a empresa avisa que ativá-los pode reduzir a precisão global. Portanto, não existe uma configuração única com todas as funcionalidades sem compromissos; a equipa continua a ter de decidir quais os metadados que justificam o trade-off.

Smart transcription muda o resultado de fala bruta para texto utilizável

A funcionalidade mais interpretativa é o modo “smart transcription”. No modo verbatim, o modelo preserva filler words, falsos começos, repetições e a forma oral da conversa. No modo smart, remove disfluências, resolve auto-correções, aplica pontuação e capitalização e pode formatar listas, datas, moedas e números de forma mais legível.

Isto é útil, mas altera o contrato semântico. Uma transcrição bruta é um registo do que foi dito. Uma transcrição smart é uma representação interpretada do que o modelo considera que o orador pretendia dizer. Para notas, resumos de reuniões, ditado e interfaces de voz, pode ser exatamente o desejado. Para e-discovery jurídico, gravação de conformidade, jornalismo ou arquivos regulados, pode ser necessário manter separadamente a versão verbatim.

A Google explicita outra limitação: o modo smart não pode ser combinado com diarização ou timestamps por palavra. Surge assim uma escolha de arquitetura entre texto mais polido e metadados de proveniência mais ricos. Um sistema que precise de ambos poderá necessitar de duas passagens.

Integração direta com a stack de desenvolvimento da Google

A Google afirma que o modelo já suporta funcionalidades de voz como Rambler no Android e transcrição na aplicação Gemini em macOS. Os programadores podem usá-lo através do Google AI Studio e da Gemini API, e a empresa está a posicioná-lo para voice agents, legendagem em direto e post-call analytics.

A superfície de integração é mais importante do que os exemplos de consumo. O modelo live funciona através de WebSocket, tornando-o relevante para stacks de comunicação real-time e interfaces de agentes que necessitam de um fluxo contínuo de texto enquanto o utilizador fala. A documentação também menciona plataformas como Agora, LiveKit, Pipecat e Vercel.

A Ars Technica reportou independentemente o lançamento e destacou a mesma mudança de reconhecimento de voz tradicional para texto limpo e estruturado. Também referiu as alegações da Google sobre menor latência e taxa de erro em relação ao Chirp 3. Esses números devem ser tratados como alegações do fornecedor até serem reproduzidos independentemente, mas as funcionalidades disponibilizadas na API não dependem dessa comparação.

O que as equipas devem avaliar antes de mudar

A primeira pergunta não é se o Gemini 3.5 Transcribe vence um benchmark. É se o conjunto integrado de funcionalidades reduz a complexidade de uma aplicação real. Equipas que hoje mantêm etapas separadas de reconhecimento, diarização, adaptação de vocabulário, formatação e limpeza podem conseguir eliminar partes do pipeline. Equipas com ASR específico e muito afinado podem beneficiar menos.

Os testes devem abranger code-switching, sotaques, ambientes ruidosos, nomes próprios, vocabulário especializado, oradores sobrepostos, sessões longas e o comportamento de falha do smart transcription quando o significado é ambíguo. Em workflows regulados ou auditáveis, os programadores devem comparar as saídas verbatim e smart e decidir qual é o registo oficial.

A latência também deve ser medida end-to-end. Um modelo de baixa latência não garante uma aplicação rápida se a captura do microfone, transporte de rede, WebSocket, buffering, chamadas de agentes a jusante ou rendering da interface dominarem a experiência. O mesmo se aplica ao custo: o preço do modelo deve ser comparado com os componentes que a API integrada pode substituir.

A importância mais ampla do Gemini 3.5 Transcribe é, portanto, arquitetural. A Google está a transformar a transcrição de um primitive limitado de reconhecimento de voz numa API de modelo mais rica, capaz de fornecer texto e estrutura pronta para workflow. Para equipas de voice agents e produtos de áudio, isto cria um ponto de partida mais simples, mas também torna escolhas sobre proveniência, interpretação e trade-offs de funcionalidades parte central do desenho da aplicação.

Sources
- Intelligent transcription with Gemini 3.5 Transcribe
- Gemini 3.5 Transcribe model documentation
- Google announces Gemini 3.5 Transcribe for AI-powered speech-to-text