Há falhas de IA fáceis de reconhecer: uma data inventada, uma fonte falsa, uma conclusão demasiado confiante. O caso de Gemini 3.1 Pro com Deep Research analisado aqui, a partir de uma amostra real fornecida pelo utilizador, é diferente. A resposta não se limita a errar. Começa como um relatório técnico extenso sobre um tema especializado, com secções, fontes e recomendações operacionais, mas a certa altura perde o controlo da escrita e cai numa avalanche de sinónimos, adjetivos e conectores repetidos.
O sinal mais claro não é uma frase falsa. É o facto de o texto deixar de dizer algo. Na amostra completa, uma contagem simples deteta cerca de 24.800 palavras, com a palavra espanhola “asertivamente” a aparecer quase 9.700 vezes. Também se repetem de forma massiva termos como “única”, “de manera exclusiva”, “poda”, “purga”, “ineludible” ou “crítico”. Isto já não é uma resposta longa: é uma saída degenerada.
A hipótese mais razoável é que não estamos perante um único “bug mágico” do Gemini, mas sim perante a combinação de três camadas: um modelo generativo, um sistema agentivo de investigação e uma fase de síntese longa. O Deep Research não responde como um chat simples. Segundo a documentação da Google, o produto planeia, pesquisa, raciocina, explora muitas fontes e gera relatórios extensos. Na API, a Google também descreve o Deep Research como um investigador agentivo orientado para investigações autónomas de vários passos e relatórios citados.
Quando uma dessas camadas perde estabilidade, o erro pode amplificar-se durante centenas ou milhares de tokens.
Em resumo
O erro visível de Gemini 3.1 Pro com Deep Research pode ser descrito como degeneração repetitiva de saída. O sistema continua a produzir texto gramaticalmente reconhecível, mas perde densidade informativa. Em vez de avançar com evidência, estrutura e conclusões, começa a inflacionar frases com variações semânticas cada vez mais fracas.
Não convém chamar-lhe apenas “alucinação”. Uma alucinação típica inventa dados, fontes ou relações causais. Aqui acontece algo mais básico e mecânico: a geração entra num loop em que cada repetição aumenta a probabilidade de continuar a repetir. O resultado pode parecer deliberado porque mantém tom técnico, mas funcionalmente está partido.
| Tipo de falha | O que acontece | Como aparece na amostra |
|---|---|---|
| Alucinação factual | O modelo inventa ou distorce dados. | Uma cifra, fonte ou afirmação concreta não se sustenta. |
| Deriva semântica | O texto afasta-se do objetivo original. | O relatório passa de desenvolver o tema original para acumular solenidade vazia. |
| Loop lexical | Uma palavra ou família de palavras repete-se sem controlo. | ”asertivamente”, “única” e “de manera exclusiva” aparecem em cascata. |
| Colapso de síntese | A saída já não resume nem organiza evidência. | A extensão aumenta, mas a informação útil diminui. |
O que falhou exatamente na resposta
A amostra começa com uma estrutura reconhecível. Há secções, tabelas, conceitos técnicos e referências a práticas reais: definições, sinais de validação, processos de revisão, logs, critérios de controlo e auditoria. Essa primeira parte pode ter matizes discutíveis, mas ainda responde a um objetivo.
A falha aparece quando a escrita se torna ornamental e autorreferencial. Expressões longas e solenes deixam de compactar informação e começam a produzir ruído. Depois o sistema não só exagera: fica preso. A repetição de palavras como “única” e “asertivamente” deixa de funcionar como linguagem e passa a ser um padrão automático.
Há quatro sintomas claros:
- Perda de compressão: o modelo já não reduz informação; expande sem acrescentar conteúdo.
- Perda de hierarquia: tudo parece igualmente crítico, inegociável e definitivo.
- Perda de controlo estilístico: o tom técnico converte-se em grandiloquência mecânica.
- Perda de critério de paragem: o sistema não deteta que a resposta já não ajuda o utilizador.
Esse último ponto é essencial. Um sistema de investigação deveria ter sinais internos de qualidade: densidade de fontes, cobertura do plano, repetição, novidade por parágrafo, coerência e extensão razoável. Quando esses sinais não travam a saída, o utilizador recebe um bloco enorme que consome tempo e confiança.
Porque não é apenas “escrever demais”
Uma resposta longa não é, por si só, um problema. O Deep Research existe precisamente para tarefas complexas que exigem vários passos. O problema aparece quando a extensão deixa de estar ligada a progresso.
Num relatório saudável, cada parágrafo deveria fazer pelo menos uma destas coisas:
- introduzir uma ideia nova;
- resumir uma fonte;
- comparar posições;
- explicar uma consequência;
- transformar dados em decisão;
- mostrar uma limitação.
Na amostra, depois do ponto de rutura, o texto deixa de cumprir estas funções. Há muitas palavras, mas pouca movimentação conceptual. A frase cresce como uma cadeia de adjetivos. O sistema parece otimizar uma aparência de rigor em vez de produzir rigor real.
A mecânica provável: degeneração de texto
Os modelos de linguagem geram texto passo a passo. Cada nova palavra depende do prompt, do contexto acumulado e da saída já produzida. Isto é poderoso, mas cria uma fragilidade: se a própria saída começa a ficar repetitiva, essa repetição também passa a ser contexto para a próxima decisão.
A investigação sobre degeneração de texto mostrou que modelos neurais podem cair em sequências repetitivas, especialmente quando a geração longa não é bem controlada. O fenómeno não exige que o modelo “queira” repetir. Basta que o caminho probabilístico local fique preso numa região em que repetir parece cada vez mais provável.
Na prática, isso pode acontecer por várias razões:
- um estilo demasiado solene que recompensa palavras ornamentais;
- uma instrução para ser “exaustivo” sem limites de extensão;
- síntese de muitas fontes sem compressão forte;
- ausência de verificação de repetição;
- falta de paragem quando a densidade informativa cai;
- acumulação de contexto em língua com muitos conectores e adjetivos próximos.
O resultado é um texto que parece técnico de longe, mas que perde função quando é lido de perto.
Porque o Deep Research pode tornar o problema mais visível
O Deep Research tem uma ambição maior do que uma resposta normal. Planeia, procura, lê, acumula contexto e redige. Essa arquitetura é útil quando o sistema mantém controlo, mas também aumenta a superfície de falha.
Um chat curto pode falhar numa frase. Um relatório de investigação pode falhar numa cadeia inteira. Se a fase de síntese entra num loop, o erro não ocupa uma linha: ocupa páginas. O utilizador só percebe tarde, depois de ter investido tempo a ler.
Isto não significa que a funcionalidade seja inútil. Significa que relatórios longos precisam de guardrails específicos:
- limite de palavras por secção;
- medição de repetição lexical;
- validação contra o plano inicial;
- citações ligadas a afirmações importantes;
- revisão por blocos;
- possibilidade de recuperar a partir do último bloco saudável.
O papel da língua espanhola
A amostra está em espanhol e isso importa. O espanhol permite cadeias longas de adjetivos, nominalizações e conectores formais. Um modelo que tenta soar técnico pode abusar desse espaço estilístico: “estrito”, “crítico”, “ineludível”, “absoluto”, “irrevogável”, “exclusivo”.
O problema não é o espanhol em si. O problema é a combinação entre prosa formal, baixa densidade informativa e ausência de travão. Quando o modelo descobre um registo que parece académico, pode continuar a ornamentar em vez de sintetizar.
Por isso, uma instrução útil não é apenas “responde em espanhol” ou “responde em português”. É melhor pedir linguagem direta, frases curtas, poucos adjetivos e uma regra explícita: se uma frase não acrescenta uma ideia verificável, deve ser eliminada.
Onde colocaria a responsabilidade técnica
Eu não colocaria toda a responsabilidade no modelo base nem toda no produto Deep Research. O erro parece nascer na interação entre várias camadas.
| Camada | Possível contribuição | Controlo necessário |
|---|---|---|
| Prompt do utilizador | Pedido demasiado amplo ou estilo formal. | Limites, formato e critérios de paragem. |
| Planeamento | Plano demasiado extenso ou pouco hierarquizado. | Plano editável e foco por secção. |
| Recuperação de fontes | Contexto abundante e difícil de comprimir. | Tabela de fontes e descarte explícito. |
| Síntese | Perda de densidade e deriva retórica. | Validação de novidade por parágrafo. |
| Geração | Loop lexical autorreforçado. | Detetor de repetição e regeneração parcial. |
| UI do produto | Entrega final sem avisar degradação. | Avisos, corte automático e recuperação. |
A lição é clara: um agente de investigação não deveria ser avaliado apenas pela qualidade média quando tudo corre bem, mas também pela forma como falha quando o contexto cresce.
Como detetar antes de perder tempo
O utilizador não precisa de saber teoria de modelos para identificar o problema. Há sinais simples:
- a mesma palavra aparece muitas vezes em poucas linhas;
- as frases ficam cada vez mais compridas;
- os adjetivos substituem evidência;
- o relatório repete a mesma tese sem avançar;
- há tom de autoridade sem fontes novas;
- a conclusão parece mais enfática do que informativa.
Uma regra prática: se ao cortar 70% de um parágrafo não se perde nenhuma ideia, esse parágrafo é ruído. Num relatório de investigação, o texto deve ficar mais claro quando avança, não mais espesso.
Como pedir relatórios com menos risco
Um prompt mais seguro seria:
Investiga o tema e entrega primeiro uma tabela de fontes com título, URL, data e utilidade. Depois escreve um relatório de no máximo 1.200 palavras. Usa frases diretas. Não uses linguagem grandiosa. Evita repetir conceitos. Se uma secção repetir ideias anteriores, condensa-a ou elimina-a. Cada secção deve acrescentar uma ideia nova, um dado verificável ou uma implicação prática. Se faltar evidência, diz isso.
Para relatórios longos, divide o trabalho:
- Plano de investigação.
- Tabela de fontes.
- Resumo executivo.
- Desenvolvimento por secções.
- Revisão crítica.
- Versão final.
A chave é não pedir “um relatório exaustivo” sem limites. Em modelos generativos, “exaustivo” pode transformar-se em “infinito”, “formal” em “pomposo” e “detalhado” em “repetitivo”.
O que um sistema como Deep Research deveria fazer melhor
Um agente de investigação robusto deveria ter defesas visíveis e automáticas:
| Defesa | O que controla | Resultado esperado |
|---|---|---|
| Detetor de repetição | Palavras, n-gramas e frases repetidas. | Cortar ou regenerar antes de entregar lixo. |
| Medidor de densidade informativa | Ideias novas por parágrafo. | Reduzir enchimento. |
| Validação contra o plano | Cada secção deve responder a uma parte do plano. | Evitar deriva. |
| Cobertura de fontes | Afirmações importantes ligadas a fontes. | Manter rastreabilidade. |
| Entrega por blocos | O utilizador valida secções antes do relatório completo. | Evitar que uma falha final arruíne tudo. |
| Botão de recuperação | Repetir a partir do último bloco saudável. | Poupar tempo. |
Isto é importante porque o Deep Research é apresentado como uma função para poupar tempo. Se o utilizador precisa de ler milhares de palavras para descobrir que o relatório se partiu, a promessa inverte-se: a automação cria dívida de revisão.
Como Nicolás Torres o reveria
Eu trataria esta falha como trataria um pipeline de geração que devolve uma saída corrompida depois de vários passos intermédios: não culparia apenas o ecrã final. Reveria o fluxo completo.
Primeiro isolaria a amostra:
- prompt original;
- plano gerado pelo Deep Research;
- fontes usadas;
- ponto exato em que a repetição começa;
- extensão do relatório;
- idioma;
- modelo selecionado;
- se houve ficheiros anexados ou fontes privadas;
- se o relatório foi exportado ou gerado dentro da interface.
Depois faria três novas tentativas controladas:
- Mesmo tema, saída curta: para ver se o conteúdo base pode ser bem sintetizado.
- Mesmo tema, formato estruturado: tabela, bullets, conclusões e nada de prosa longa.
- Mesmo tema, outro modelo ou sem Deep Research: para separar modelo base de orquestração agentiva.
Se o erro só aparece no relatório longo com Deep Research, a causa provável está na combinação de contexto acumulado, síntese e controlo de saída.
Perguntas frequentes
Que erro se vê na resposta do Gemini 3.1 Pro?
O erro visível é uma degeneração de saída: o relatório deixa de acrescentar informação nova e começa a repetir sinónimos, conectores e adjetivos até formar blocos enormes de texto sem utilidade.
Isto é o mesmo que uma alucinação?
Não exatamente. Uma alucinação inventa factos. Neste caso o problema principal é a geração autorreforçada: repete formas linguísticas plausíveis, mas perde objetivo, estrutura e conteúdo verificável.
Porque pode acontecer no Deep Research?
O Deep Research combina planeamento, pesquisa, leitura de muitas fontes, síntese e redação longa. Se a compressão de contexto, o estilo de saída ou o decodificador entram num padrão repetitivo, o sistema pode arrastar a falha durante muitas linhas.
Isto significa que o Gemini 3.1 Pro não serve para investigar?
Não. Significa que tarefas agentivas longas precisam de controlos adicionais: limites de extensão, validação de repetição, revisão de fontes, entregas por secções e capacidade de parar quando o relatório perde densidade informativa.
Como reduzo o risco ao pedir relatórios longos?
Peça primeiro um plano e uma tabela de fontes, limite o tamanho de cada secção, exija linguagem direta, proíba repetição ornamental e peça ao modelo que pare se detetar redundância ou falta de evidência.
Precisas de desenhar um agente IA que não se parta em produção?
Agentes úteis não são apenas modelos potentes. Precisam de arquitetura, limites, ferramentas, medição e recuperação quando algo falha.
Se estás a construir uma experiência com IA para a tua web, captação, suporte ou processos internos, convém desenhá-la como sistema: com contexto controlado, saídas verificáveis e regras de qualidade antes de mostrar o resultado ao utilizador.
Solicitar diagnóstico de agente IA
Perguntas frequentes
- Que erro se vê na resposta do Gemini 3.1 Pro?
- O erro visível é uma degeneração de saída: o relatório deixa de acrescentar informação nova e começa a repetir sinónimos, conectores e adjetivos até formar blocos enormes de texto sem utilidade.
- Isto é o mesmo que uma alucinação?
- Não exatamente. Uma alucinação inventa factos. Neste caso, o problema principal é a geração autorreforçada: o modelo repete formas linguísticas plausíveis, mas perde objetivo, estrutura e conteúdo verificável.
- Porque pode acontecer no Deep Research?
- O Deep Research combina planeamento, pesquisa, leitura de muitas fontes, síntese e redação longa. Se a compressão de contexto, o estilo de saída ou a geração entram num padrão repetitivo, o sistema pode arrastar a falha durante muitas linhas.
- Isto significa que o Gemini 3.1 Pro não serve para investigar?
- Não. Significa que tarefas agentivas longas precisam de controlos adicionais: limites de extensão, validação de repetição, revisão de fontes, entrega por secções e capacidade de parar quando o relatório perde densidade informativa.
- Como reduzo o risco ao pedir relatórios longos?
- Peça primeiro um plano e uma tabela de fontes, limite cada secção, exija linguagem direta, proíba repetição ornamental e peça ao modelo que pare se detetar redundância ou falta de evidência.