Una respuesta cortada de Gemini: límite de tokens y filtro de seguridad no son lo mismo
La documentación distingue MAX_TOKENS, SAFETY y STOP. Cómo registrar el motivo sin atribuir al sistema una causa no comprobada.
Cuando una respuesta de un modelo termina antes de lo esperado, el fragmento visible no basta para explicar la causa. La documentación de la API de Gemini incluye un campo finishReason para cada candidato. MAX_TOKENS señala que se ha alcanzado el máximo de tokens especificado en la petición; SAFETY indica que el contenido del candidato se ha marcado por razones de seguridad.
Otro valor, STOP, corresponde a una parada natural o a una secuencia de parada proporcionada. Por tanto, no conviene traducir cualquier final breve como censura, ni cualquier texto largo como una respuesta completa y comprobada. El campo describe una condición de finalización; no certifica por sí mismo la corrección de lo escrito.
Un registro útil para investigar el problema puede separar modelo, momento de la petición, límite configurado, motivo devuelto y parte de la estructura recibida. Conserva solo lo necesario y evita copiar claves o datos personales en un informe compartido. No hace falta publicar la conversación íntegra para anotar que un resultado terminó con un motivo concreto.
Pensemos en una automatización ficticia que espera una lista estructurada. Antes de utilizarla, debería comprobar que la estructura se puede leer y que contiene los campos previstos. Si el motivo es MAX_TOKENS, el dato disponible apunta al límite; si es SAFETY, esa explicación sería distinta. Aquí no se ha enviado ninguna petición ni medido qué cambios de configuración resolverían un caso real.
La guía propone un diagnóstico, no un método para eludir protecciones. Ante un bloqueo de seguridad, revisa el uso y las instrucciones pertinentes; ante una salida incompleta, evita tratar el fragmento como un documento terminado. En ambos casos, mantén separados el motivo técnico observado y las hipótesis que aún no has probado.