En las aplicaciones con agentes y en las conversaciones de varios turnos, nuestros modelos funcionan mejor cuando conservas el razonamiento entre solicitudes a la API y siempre agregas las nuevas acciones e instrucciones al final del contexto del modelo. Mantener intacto el prefijo es una práctica recomendada desde hace tiempo para el almacenamiento en caché de prompts. La caché busca coincidencias desde el inicio de cada solicitud, por lo que modificar el prefijo puede impedir que se reutilice el contenido almacenado a partir de ese punto. Si agregas los cambios al final, una mayor parte de la conversación se puede reutilizar desde la caché, lo que puede reducir considerablemente los costos de entrada y acelerar las respuestas.
Con los modelos de vanguardia más recientes, la API descarta los elementos de razonamiento que aparecen después del punto donde cambió el prefijo. Esto forma parte de nuestras medidas de protección contra la destilación de modelos. Cuando la API descarta esos elementos, es posible que el modelo tenga que repetir parte del razonamiento, lo que puede aumentar el consumo de tokens, el costo y la latencia. Si el modelo no logra recuperar el razonamiento perdido, la calidad de la respuesta también puede disminuir.
Para obtener el mejor rendimiento de nuestros modelos, te recomendamos evitar los cambios en el prefijo y, en la medida de lo posible, diseñar tu integración para que solo agregue contenido al final del contexto.
¿Qué es un cambio en el prefijo?
El prefijo de un elemento de razonamiento es la parte del historial de la conversación que precede a ese elemento. Modificas el prefijo cuando cambias esa parte del historial, por ejemplo, si acortas el resultado de una herramienta, reescribes un mensaje del desarrollador o reemplazas turnos anteriores por un resumen.
| Original conversation | Next request and API handling |
|---|---|
| User messageCheck the ledger total. | Same message |
| Reasoning before the tool call | Reusable |
Tool calllookup_ledger() | Same call |
Tool result[{"amount": 40}, {"amount": 50}] | Same rows |
| Reasoning after the tool result | Reusable |
Cómo actualizar tu integración para evitar cambios en el prefijo
Puedes modificar el prefijo sin querer al actualizar parámetros de la API de Responses como tools, instructions o text.format, o al editar elementos anteriores de input. Revisa tu integración para detectar estos cambios.
La siguiente tabla muestra en qué casos las integraciones suelen modificar el prefijo y cómo lograr el mismo objetivo agregando contenido al final del contexto cuando sea posible.
| Motivo habitual para modificar el prefijo | Cómo evitar el cambio en el prefijo |
|---|---|
| Cambiar el esfuerzo de razonamiento | En vez de cambiar el parámetro reasoning.effort en la API de Responses, agrega al final de la lista de elementos de entrada un elemento configuration_update con el nuevo esfuerzo de razonamiento. Conserva el valor original del parámetro de la solicitud. |
| Cambiar los esquemas de los resultados estructurados | En vez de cambiar el parámetro text.format en la API de Responses, agrega al final de la lista de elementos de entrada un elemento configuration_update con el nuevo esquema. Conserva el valor original del parámetro de la solicitud. |
| Cambiar las herramientas disponibles para el agente | En vez de cambiar el parámetro tools en la API de Responses, usa un elemento additional_tools para agregar herramientas, o usa tool_choice con allowed_tools para limitar las herramientas que el modelo puede invocar en un turno. Conserva el orden de las definiciones de herramientas existentes. Agrega al final el elemento additional_tools con el rol developer y un arreglo tools. Cuando vuelvas a enviarlo, conserva su posición original. |
| Actualizar las instrucciones del desarrollador | En vez de editar el mensaje original del desarrollador, agrega al final un nuevo mensaje con el rol developer en el que le pidas al modelo que ignore las instrucciones anteriores y siga las nuevas. Si las instrucciones solo se aplican a un turno, coloca un punto de corte explícito de la caché justo antes del mensaje más reciente del desarrollador para que el prefijo reutilizable termine antes de ese mensaje. |
| Compactación | La compactación modifica el prefijo, por lo que en estos casos es difícil evitar los fallos de caché. Compactación de OpenAI: si usas la compactación de OpenAI mediante /responses/compact o context_management, nuestros sistemas conservan los elementos de razonamiento posteriores aunque cambie el prefijo. Un elemento de compactación de OpenAI puede aparecer en cualquier parte del contexto. Cuando llames a /responses/compact, omite instructions y pasa la ventana de contexto que recibas a la siguiente solicitud en su orden original. Si tu historial contiene elementos configuration_update, sigue los requisitos de compactación para las actualizaciones de configuración.Compactación personalizada: si usas otra estrategia de compactación o desarrollaste una propia, coloca el elemento compactado al final del contexto del modelo, en vez de colocarlo antes de los turnos recientes. También puedes optar por colocarlo antes de esos turnos y aceptar que la API descarte los elementos de razonamiento del historial original que queden después de él. |
| Acortar resultados anteriores de herramientas o reducir el tamaño de archivos o imágenes ya enviados | Algunas integraciones recortan elementos anteriores, como resultados de herramientas, archivos o imágenes, en vez de usar la compactación. Estas modificaciones cambian el prefijo. Te recomendamos encarecidamente que uses la compactación o que acortes los resultados extensos de las herramientas y reduzcas el tamaño de las imágenes o los archivos antes de enviarlos al modelo por primera vez. |
Revisar tu integración para detectar cambios en el prefijo
Usa los diagnósticos del almacenamiento en caché de prompts para ver cuándo se producen fallos de caché e investigar los cambios en el prefijo. Para comparar una solicitud con una respuesta anterior, asigna el ID de esa respuesta a prompt_cache_options.comparison_response_id. Luego, revisa el motivo que indica el diagnóstico y la cantidad de tokens almacenados en caché. Usa esta información para reducir los cambios en el prefijo que realiza tu integración. Los diagnósticos informan de la primera diferencia que logran identificar, pero no pueden verificar si el modelo reutilizó el razonamiento.