Parámetros de muestreo

Resumen

Ninguno de estos es obligatorio. Omitir un campo por completo significa que el modelo usa su propio valor por defecto para ese ajuste, lo cual es la opción correcta para la mayoría de las solicitudes; recurra a estos cuando una solicitud concreta realmente necesite más determinismo, más variedad, o una condición de parada estricta. Cada valor aquí se valida al entrar: un valor de tipo incorrecto, o un número fuera del rango aceptado, se ignora silenciosamente solo para ese campo en lugar de hacer fallar toda la solicitud, de modo que un parámetro de muestreo mal formado nunca convierte una solicitud que funciona en una rota. Si una solicitud se comporta como si un parámetro que envió no hubiera tenido efecto, lo primero que hay que verificar es que esté dentro del rango aceptado que se indica abajo.

Campo	Tipo	Rango	Efecto
temperature	number	0–2	Valores más altos hacen que la salida sea más variada y menos predecible; valores más bajos la hacen más enfocada y determinista. 0 está cerca de elegir siempre el siguiente token más probable.
top_p	number	0–1	Muestreo por núcleo (nucleus sampling): restringe las opciones al conjunto más pequeño de tokens cuya probabilidad combinada alcanza este valor. Una palanca alternativa a temperature para controlar la variedad; la mayoría de las solicitudes deberían configurar una u otra, no ambas.
presence_penalty	number	-2–2	Los valores positivos reducen la probabilidad de un token que ya apareció en cualquier parte de la respuesta hasta el momento, fomentando que el modelo introduzca temas nuevos en lugar de insistir en los ya mencionados.
frequency_penalty	number	-2–2	Los valores positivos reducen la probabilidad de un token en proporción a cuántas veces ya apareció, desalentando la repetición de las mismas palabras y frases.
seed	integer	cualquier entero	Solicitar la misma seed con una solicitud por lo demás idéntica hace que la salida sea más reproducible entre ejecuciones. No es una garantía estricta de una salida idéntica byte a byte cada vez, pero reduce de forma significativa la variación para pruebas y depuración.
stop	string o array de cadenas	hasta unas pocas secuencias cortas	La generación se detiene en el momento en que cualquiera de estas secuencias aparecería en la salida. La secuencia en sí no se incluye en el texto devuelto.

Ejemplo

{
  "model": "tai-4.1",
  "messages": [{"role": "user", "content": "Bir ürün açıklaması yaz"}],
  "temperature": 0.3,
  "presence_penalty": 0.4,
  "stop": ["###"]
}

Cuándo usar cada uno

Para cualquier caso en el que la consistencia importe más que la variedad, extracción, clasificación, salida estructurada, código, mantener temperature bajo (0 a alrededor de 0,3) suele ser lo correcto. Para escritura abierta, lluvia de ideas, o cualquier cosa en la que prefiera ver un rango de salidas plausibles a lo largo de llamadas repetidas, un temperature más alto (0,7 a 1,0 o más) tiende a producir una variedad más interesante. Vale la pena recurrir a presence_penalty y frequency_penalty específicamente cuando un modelo está produciendo texto repetitivo, dando vueltas sobre la misma frase, o reiterando el mismo punto; son menos útiles como valor por defecto de uso general que temperature. seed es útil principalmente durante el desarrollo y las pruebas, donde reproducir la misma salida entre ejecuciones hace que depurar un cambio de prompt sea mucho más fácil que tener que averiguar si una diferencia en la salida vino de su cambio o de la variación normal del muestreo.

No compatible actualmente

Unos pocos campos relacionados con el muestreo que existen en la propia API de OpenAI no se aceptan actualmente: n (varios completions candidatos por solicitud; tAI siempre devuelve exactamente uno), logprobs / top_logprobs, y response_format (salida en modo JSON estructurado). Enviar cualquiera de estos no tiene efecto; no se validan ni se aplican. Consulte la página Compatibilidad con el SDK de OpenAI para ver la lista completa de qué se admite y qué no si está migrando una integración existente.