Gemini: cambiar temperature no siempre cambia la generación
La referencia actual de la API avisa de que Gemini 3.6 Flash y modelos posteriores ignoran ese campo; conviene comprobar compatibilidad.
Un parámetro puede aparecer en una petición y no tener efecto en el modelo elegido. La referencia actual de GenerationConfig de Gemini describe temperature como control de aleatoriedad, pero añade una excepción concreta: deja de estar soportado y se ignora en Gemini 3.6 Flash y modelos posteriores. Cambiar su número no demuestra, por tanto, que se haya modificado el comportamiento de esos modelos.
Antes de atribuir una respuesta distinta a un ajuste, comprueba el identificador exacto del modelo y la documentación de los campos admitidos. Que una biblioteca permita escribir una propiedad no basta para acreditar que el servicio la utiliza en todas sus versiones. Esta guía recoge lo que indica la referencia consultada; no presenta una prueba ejecutada contra la API ni una comparación de rendimiento.
Una ficha de ensayo útil separa modelo, fecha, instrucciones, campo enviado y soporte documentado. Si comparas dos salidas, conserva ambas y evita afirmar que el parámetro produjo la diferencia cuando está marcado como ignorado. También resulta útil distinguir la configuración que se pretendía aplicar de la que consta compatible con esa versión.
El control de aleatoriedad tampoco debe leerse como un porcentaje de verdad de la respuesta. La documentación lo define por su papel en la generación, no como certificación factual. Para una afirmación sobre fechas, normas o cálculos siguen haciendo falta comprobaciones de contenido. Si una aplicación se actualiza a otro modelo, revisa de nuevo esas condiciones antes de reutilizar conclusiones de ensayos anteriores: conservar el mismo nombre de campo no garantiza conservar su efecto.