Incidente: Bucles repetitivos de Gemma 4 E4B-it en Auto-Plan (sampling greedy)

Resumen

Al migrar el backend de Auto-Plan a llama-server self-hosted con Gemma 4 E4B-it (sesión 41), el modelo entraba en bucles repetitivos al procesar imágenes de planos de sala reales con el prompt EXHAUSTIVE. Generaba 3 000+ tokens sin terminar, provocando que Daphne timeoutara antes de recibir respuesta válida.

Síntomas

• _analyze_with_ollama() no retornaba en prompts con imágenes reales.
• Daphne lanzaba timeout antes de obtener respuesta del LLM.
• Logs mostraban el modelo generando tokens durante decenas de segundos sin stop_reason.

Diagnóstico

Prueba de aislamiento: con una imagen dummy 1×1 px el modelo respondía correctamente en ~14 s con JSON válido y completo.

Causa raíz: el sampling greedy por defecto (top_p=1.0, sin top_k, sin repeat_penalty) hacía que Gemma 4 E4B-it se atascara en bucles cuando el prompt EXHAUSTIVE enumera 60+ entidades similares (racks, conexiones, walls, texts). El modelo repetía tokens de alta probabilidad sin llegar al token de parada.

Esto es un patrón conocido en modelos de la familia Gemma cuando se usan con llama.cpp/llama-server sin ajuste de sampling.

Fix aplicado

Cambios en blueprints/services/autoplan.py (commit 111ba05):

# Antes
temperature=0.1,
max_tokens=16384,
extra_body={
    "num_ctx": 32768,
    "chat_template_kwargs": {"enable_thinking": False},
}

# Después
temperature=0.1,
top_p=0.9,          # nucleus sampling — elimina tokens de baja prob.
max_tokens=8192,    # reducido de 16384; JSON Auto-Plan cabe holgado
extra_body={
    "top_k": 40,          # limita candidatos por step
    "repeat_penalty": 1.15,  # penaliza repetición de tokens recientes
    "num_ctx": 32768,
    "chat_template_kwargs": {"enable_thinking": False},
}

Parámetros siguiendo recomendaciones estándar de llama.cpp para evitar degenerate repetition.

Razonamiento de cada parámetro

Impacto del fix

• Auto-Plan con Gemma 4 E4B-it vuelve a responder correctamente con planos reales.
• No hay cambio de comportamiento para los backends OpenRouter, Gemini y DeepSeek: los parámetros top_k y repeat_penalty se pasan en extra_body y sólo los consume llama-server.
• El límite max_tokens=8192 no supone riesgo de truncado: el JSON de un plano con 60+ entidades en modo EXHAUSTIVE se genera dentro de ese límite en tests verificados.

Lecciones aprendidas

1. El sampling greedy es peligroso con modelos instruction-tuned en tareas de enumeración larga. Siempre configurar top_p, top_k y repeat_penalty al integrar un nuevo modelo local.
2. Diagnóstico por aislamiento de input: la prueba con imagen dummy 1×1 permitió descartar el stack de inferencia y apuntar al prompt/contenido como variable determinante.
3. max_tokens debe reflejar el output real esperado, no el límite técnico del modelo. Un budget excesivo amplifica los bucles.
4. La guía OLLAMA_SELF_HOSTED_AI.md debería actualizarse para incluir estos parámetros de sampling como configuración base recomendada.

Véase también

• [[entity—blueprints—service—autoplan]]
• [[feature—blueprints—autoplan]]
• [[entity—blueprints—model—aiprompt]]
• [[entity—blueprints—model—blueprint]]