Gemini 3.1 Pro y Deep Research: por qué aparecen bucles de sinónimos y texto sin contenido

Hay fallos de IA que son fáciles de reconocer: una fecha inventada, una fuente falsa, una conclusión demasiado segura. El caso de Gemini 3.1 Pro usando Deep Research que analizamos aquí, a partir de una muestra real aportada, es distinto. La respuesta no se limita a equivocarse. Empieza escribiendo un informe técnico extenso sobre un tema especializado, con secciones, fuentes y recomendaciones operativas, pero en un punto pierde el control de la redacción y cae en una avalancha de sinónimos, adjetivos y conectores repetidos.

La señal más clara no es que diga una frase falsa. Es que deja de decir algo. En la muestra completa, un recuento simple detecta unas 24.800 palabras, con la palabra “asertivamente” apareciendo casi 9.700 veces. También se repiten de forma masiva términos como “única”, “de manera exclusiva”, “poda”, “purga”, “ineludible” o “crítico”. Eso ya no es una respuesta larga: es una salida degenerada.

La hipótesis más razonable es que no estamos ante un único “bug mágico” de Gemini, sino ante la combinación de tres capas: un modelo generativo, un sistema agentivo de investigación y una fase de síntesis larga. Deep Research no responde como un chat simple. Según la propia documentación de Google, el producto planifica, busca, razona, explora muchas fuentes y genera informes extensos. En la API, Google también describe Deep Research como un investigador agentivo orientado a investigaciones autónomas de varios pasos y reportes citados.

Cuando una de esas capas pierde estabilidad, el error puede amplificarse durante cientos o miles de tokens.

En resumen

El error visible de Gemini 3.1 Pro con Deep Research se puede describir como una degeneración repetitiva de salida. El sistema sigue produciendo texto gramaticalmente reconocible, pero pierde densidad informativa. En vez de avanzar con evidencia, estructura y conclusiones, empieza a inflar la frase con variaciones semánticas cada vez más pobres.

No conviene llamarlo solo “alucinación”. Una alucinación típica inventa datos, fuentes o relaciones causales. Aquí ocurre algo más básico y más mecánico: la generación entra en un bucle donde cada repetición aumenta la probabilidad de seguir repitiendo. El resultado puede parecer deliberado porque mantiene tono técnico, pero funcionalmente se rompe.

La diferencia práctica es esta:

Tipo de fallo	Qué ocurre	Cómo se ve en la muestra
Alucinación factual	El modelo inventa o distorsiona datos.	Una cifra, fuente o afirmación concreta no se sostiene.
Deriva semántica	El texto se aleja del objetivo original.	El informe pasa de desarrollar el tema original a acumular solemnidad vacía.
Bucle léxico	Una palabra o familia de palabras se repite sin control.	”asertivamente”, “única”, “de manera exclusiva” aparecen en cascada.
Colapso de síntesis	La salida ya no resume ni organiza evidencia.	La longitud aumenta, pero la información útil baja.

Qué falló exactamente en la respuesta

La muestra empieza con una estructura reconocible. Hay secciones, tablas, conceptos técnicos y referencias a prácticas reales: definiciones, señales de validación, procesos de revisión, logs, criterios de control y auditoría. Esa primera parte puede ser discutible en matices, pero todavía responde a un objetivo.

El fallo aparece cuando la redacción se vuelve ornamental y autorreferencial. Frases como “estricto marco perimetral temporal absolutamente limitante” o “lentísimo incesante continuado asedio iterativo” ya muestran hinchazón de estilo. Después el sistema no solo exagera: se atasca. En el segundo bloque, la repetición de “única” y “asertivamente” deja de funcionar como lenguaje y pasa a ser un patrón automático.

Hay cuatro síntomas claros:

1. Pérdida de compresión: el modelo ya no reduce información; la expande sin añadir contenido.
2. Pérdida de jerarquía: todo parece igual de importante, crítico e ineludible.
3. Pérdida de control estilístico: el tono técnico se convierte en grandilocuencia mecánica.
4. Pérdida de criterio de parada: el sistema no detecta que la respuesta ya no ayuda al usuario.

Ese último punto es importante. Un sistema de investigación debería tener señales internas de calidad: densidad de fuentes, cobertura de puntos, repetición, novedad por párrafo, coherencia con el plan y longitud razonable. Cuando esas señales no detienen la salida, el usuario recibe un bloque enorme que consume tiempo y confianza.

Por qué no es solo “escribe demasiado”

Una respuesta larga no es un problema por sí misma. De hecho, Deep Research existe para tareas complejas que requieren varios pasos. Google lo presenta como una función capaz de explorar temas complejos, refinar análisis y producir informes con enlaces a fuentes originales. El problema aparece cuando la longitud deja de estar conectada con progreso.

En un informe sano, cada párrafo debería hacer al menos una de estas cosas:

• introducir una idea nueva;
• matizar una idea anterior;
• contrastar fuentes;
• explicar un mecanismo;
• aterrizar una implicación práctica;
• cerrar una sección.

En la muestra rota, muchos párrafos no hacen ninguna de esas cosas. El texto se comporta como si confundiera exhaustividad con acumulación. “Más largo” se convierte en “más correcto”, y “más enfático” se convierte en “más técnico”.

Ese es el punto donde un agente de investigación deja de investigar y empieza a rellenar.

La mecánica probable: degeneración de texto

Los modelos de lenguaje generan texto paso a paso. En cada paso calculan qué token es probable a continuación, condicionado por el prompt, el contexto, las fuentes recuperadas y los tokens ya generados. Esa arquitectura permite producir respuestas fluidas, pero también puede crear bucles.

El paper The Curious Case of Neural Text Degeneration mostró que ciertas estrategias de decodificación pueden producir texto repetitivo, genérico o extraño aunque el modelo base sea fuerte. Más tarde, Learning to Break the Loop analizó cómo las repeticiones pueden tener un efecto de autorrefuerzo: cuanto más aparece una frase o patrón en el contexto, más fácil es que el modelo siga por esa vía. El trabajo sobre Repetition Neurons añade otra perspectiva: ciertas activaciones internas parecen asociarse con la continuación de patrones repetidos.

Traducido a este caso: una vez que el informe empieza a abusar de intensificadores como “estricto”, “crítico”, “ineludible”, “único” o “asertivamente”, esas palabras dejan una huella en el contexto generado. El propio texto producido se convierte en parte del prompt para el siguiente token. Si el sistema no corrige, penaliza o corta el patrón, la repetición se alimenta a sí misma.

Por qué Deep Research puede hacerlo más visible

Deep Research aumenta la superficie de fallo porque convierte una consulta en una tarea agentiva. Hay un plan, varias búsquedas, lectura de páginas, acumulación de notas, síntesis y redacción. Ese diseño es poderoso, pero también introduce presión en cinco puntos.

Punto de presión	Qué puede salir mal	Señal visible
Planificación	El plan pide demasiada exhaustividad o demasiadas capas.	El informe intenta cubrirlo todo sin priorizar.
Recuperación	Entran muchas fuentes, notas o fragmentos parecidos.	Aparecen ideas repetidas con variaciones mínimas.
Compresión de contexto	El sistema resume notas intermedias de forma pobre.	Se conservan palabras de énfasis, pero se pierde estructura.
Redacción final	El generador interpreta “profundo” como “más largo y más solemne”.	Frases grandilocuentes, redundantes y poco accionables.
Control de calidad	No hay corte automático por repetición o baja densidad.	El bucle continúa hasta consumir la respuesta.

La documentación de Google sobre contexto largo también recuerda una idea útil: una ventana enorme permite nuevos usos, pero no elimina todos los límites. En tareas donde hay muchas piezas de información que recuperar, la precisión puede variar y el coste de revisar todo el contexto aumenta. En workflows agentivos, el estado acumulado es útil, pero también puede arrastrar errores.

El papel del idioma español

El hecho de que el fallo ocurra en español no significa que el español sea el problema. Pero el español hace que este tipo de colapso sea más visible.

Hay varias razones prácticas:

• El registro técnico en español admite cadenas largas de sustantivos y adjetivos sin que la gramática se rompa inmediatamente.
• Palabras como “de”, “y”, “o”, “del”, “la” permiten unir frases durante mucho tiempo.
• Los sinónimos formales son abundantes: “crítico”, “severo”, “drástico”, “ineludible”, “restrictivo”, “perentorio”.
• La escritura técnica grandilocuente puede parecer válida durante unas líneas antes de revelar que no está diciendo nada.

Eso explica por qué el error parece casi barroco. El modelo no produce caracteres aleatorios. Produce español formal degenerado: muchas palabras tienen sentido local, pero el conjunto pierde función.

Dónde colocaría la responsabilidad técnica

Desde fuera no podemos saber si el fallo pertenece exactamente al modelo base Gemini 3.1 Pro, al agente Deep Research, al compositor final del informe, a una política de estilo o a una combinación de capas. Por eso conviene evitar una conclusión simplista.

Lo prudente es separar responsabilidades:

1. Modelo base: puede tener tendencia a repetir patrones bajo ciertas condiciones de decodificación o contexto.
2. Orquestador de investigación: puede acumular demasiadas notas, repetir conceptos o no limpiar contexto intermedio.
3. Prompt del sistema: puede premiar exhaustividad, formalidad o cobertura total sin suficientes límites de concisión.
4. Decodificación: puede permitir que un patrón de alta probabilidad se imponga durante demasiados tokens.
5. Postprocesado: puede no detectar repeticiones obvias antes de entregar el informe.
6. Interfaz de usuario: puede no ofrecer una recuperación clara: “la respuesta se degradó, reintentar desde la última sección”.

En sistemas agentivos largos, la calidad no depende de una sola llamada al modelo. Depende de todo el circuito.

Cómo detectarlo antes de perder tiempo

Hay señales tempranas que permiten cortar la tarea:

• La misma palabra técnica aparece tres o más veces en pocas líneas sin necesidad real.
• Cada oración añade adjetivos, pero no datos.
• El informe vuelve a definir lo ya definido sin cambiar el ángulo.
• Los conectores crecen: “por ende”, “de forma irrevocable”, “en consecuencia”, “bajo estricta rigurosidad”.
• Las fuentes dejan de aparecer o ya no sostienen las afirmaciones.
• La respuesta mantiene tono de autoridad aunque no avance.

Una regla práctica: si un párrafo de investigación no se puede resumir en una idea nueva, probablemente está rellenando.

Cómo pedir informes con menos riesgo

La forma de pedir la investigación importa. No elimina el problema, pero reduce la probabilidad de activar una salida inflada.

Un prompt más seguro podría ser:

Investiga el tema y entrega primero una tabla de fuentes con título, URL, fecha y utilidad. Después redacta un informe de máximo 1.200 palabras. Usa frases directas. No uses lenguaje grandilocuente. Evita repetir conceptos. Si detectas que una sección repite ideas anteriores, condénsala o elimínala. Cada sección debe aportar una idea nueva, un dato verificable o una implicación práctica. Si falta evidencia, dilo.

Para informes más largos, conviene dividir:

1. Plan de investigación.
2. Tabla de fuentes.
3. Resumen ejecutivo.
4. Desarrollo por secciones.
5. Revisión crítica.
6. Versión final.

La clave es no pedir “un informe exhaustivo” sin límites. En modelos generativos, “exhaustivo” puede convertirse en “infinito”, “formal” en “pomposo” y “detallado” en “repetitivo”.

Qué debería hacer mejor un sistema como Deep Research

Un agente de investigación robusto debería tener defensas visibles y automáticas:

Defensa	Qué controla	Resultado esperado
Detector de repetición	Palabras, n-gramas y frases repetidas.	Cortar o regenerar antes de entregar basura.
Medidor de densidad informativa	Ideas nuevas por párrafo.	Reducir relleno.
Validación contra el plan	Cada sección debe responder a una parte del plan.	Evitar deriva.
Cobertura de fuentes	Afirmaciones importantes conectadas con fuentes.	Mantener trazabilidad.
Entrega por bloques	El usuario valida secciones antes del informe completo.	Evitar que un fallo final arruine todo.
Botón de recuperación	Reintentar desde el último bloque sano.	Ahorrar tiempo.

Esto es especialmente importante porque Deep Research se vende como una función de ahorro de tiempo. Si el usuario tiene que leer miles de palabras para descubrir que el informe se rompió, la promesa se invierte: la automatización crea deuda de revisión.

Cómo lo revisaría Nicolás Torres

Yo trataría este fallo como trataría un pipeline de generación que devuelve una salida corrupta después de varios pasos intermedios: no culparía solo a la última pantalla. Revisaría el flujo completo.

Primero aislaría la muestra:

• prompt original;
• plan generado por Deep Research;
• fuentes usadas;
• momento exacto donde empieza la repetición;
• longitud del informe;
• idioma;
• modelo seleccionado;
• si hubo archivos adjuntos o fuentes privadas;
• si el informe se exportó o se generó dentro de la interfaz.

Después haría tres reintentos controlados:

1. Mismo tema, salida corta: para ver si el contenido base se puede sintetizar bien.
2. Mismo tema, formato estructurado: tabla, bullets, conclusiones y nada de prosa larga.
3. Mismo tema, otro modelo o sin Deep Research: para separar modelo base de orquestación agentiva.

Si el error solo aparece en el informe largo con Deep Research, la causa probable está en la combinación de contexto acumulado, síntesis y control de salida.

¿Necesitas diseñar un agente IA que no se rompa en producción?

Los agentes útiles no son solo modelos potentes. Necesitan arquitectura, límites, herramientas, medición y recuperación cuando algo falla.

Si estás construyendo una experiencia con IA para tu web, captación, soporte o procesos internos, conviene diseñarla como sistema: con contexto controlado, salidas verificables y reglas de calidad antes de enseñar el resultado al usuario.

Solicitar diagnóstico de agente IA

Preguntas frecuentes

¿Qué error se ve en la respuesta de Gemini 3.1 Pro?

El error visible es una degeneración de salida: el informe deja de aportar información nueva y empieza a repetir sinónimos, conectores y adjetivos hasta formar bloques enormes de texto sin utilidad.

¿Es lo mismo que una alucinación?

No exactamente. Una alucinación inventa datos. En este caso el problema principal es que la generación se vuelve autorreforzada: repite formas lingüísticas plausibles, pero pierde objetivo, estructura y contenido verificable.

¿Por qué puede ocurrir en Deep Research?

Deep Research combina planificación, búsqueda, lectura de muchas fuentes, síntesis y redacción larga. Si la compresión del contexto, el estilo de salida o el decodificador entran en un patrón repetitivo, el sistema puede arrastrar el fallo durante muchas líneas.

¿Significa que Gemini 3.1 Pro no sirve para investigar?

No. Significa que las tareas agentivas largas necesitan controles adicionales: límites de longitud, validación de repetición, revisión de fuentes, entregas por secciones y capacidad de detenerse cuando el informe pierde densidad informativa.

¿Cómo reduzco el riesgo al pedir informes largos?

Pide primero un plan y una tabla de fuentes, limita el tamaño de cada sección, exige lenguaje directo, prohíbe la repetición ornamental y solicita que el modelo se detenga si detecta redundancia o falta de evidencia.