Temperatura, top-p y safety settings

1. El problema de negocio

Una cadena de moda online usa el mismo asistente generativo para varias tareas. Al clasificar las solicitudes de devolución por motivo, una misma solicitud recibe categorías distintas en cada ejecución; al proponer ideas para campañas, en cambio, las sugerencias salen casi idénticas. Además, los resúmenes de opiniones que se publican en la web reproducen a veces insultos de los clientes, y el departamento financiero vigila el coste de cada petición.

2. Solución de Google: Parámetros de muestreo y safety settings del modelo

Servicio

Parámetros de muestreo y safety settings del modelo

Capa

Modelos

Por qué

Ajustes de cada llamada, sin desarrollo ni reentrenamiento: temperatura baja para clasificar con más estabilidad y alta para idear; top-p, que también regula la aleatoriedad; safety settings con umbrales por categoría contra el odio y el acoso. Ampliación, fuera del exam guide: en los modelos Gemini más recientes Google recomienda el muestreo por defecto y esos filtros vienen desactivados.

3. Límites

No la uses si

El objetivo es recortar el coste por petición: la temperatura, el top-p y los safety settings cambian cómo se genera la respuesta, pero no son la palanca directa de cuántos tokens consume.

Variable que fuerza el cambio

Coste

Alternativa

Controlar el número de tokens: una longitud de salida máxima acotada y prompts más breves.

4. La trampa habitual

[✗] Distractor

Bajar al mínimo la temperatura en todas las tareas del asistente para acabar con las respuestas inconsistentes.

Por qué tienta

Un único ajuste parece resolver de golpe la inestabilidad de la clasificación de devoluciones.

Por qué es incorrecto

Las ideas de campaña necesitan variedad y una temperatura mínima las volvería aún más repetitivas: cada tarea pide su propia configuración, baja para clasificar y alta para idear.

5. Micro-check