Dans les applications agentiques et les conversations à plusieurs tours, nos modèles donnent les meilleurs résultats lorsque vous conservez le raisonnement d’une requête API à l’autre et ajoutez systématiquement les nouvelles actions et instructions à la fin du contexte du modèle. Garder le préfixe intact est depuis longtemps une bonne pratique pour la mise en cache des prompts. Le cache compare les requêtes depuis le début. Si vous modifiez le préfixe, la réutilisation du cache peut donc s’arrêter à l’endroit de la modification. En ajoutant les changements à la fin, vous permettez au cache de réutiliser une plus grande partie de la conversation, ce qui peut réduire sensiblement le coût des entrées et accélérer les réponses.
Avec les modèles de pointe les plus récents, l’API écarte les éléments de raisonnement situés après une modification du préfixe. Cette mesure fait partie de nos protections contre la distillation. Le modèle peut alors devoir refaire une partie de son raisonnement, ce qui peut augmenter la consommation de tokens, le coût et la latence. Si le modèle ne parvient pas à reconstituer le raisonnement perdu, la qualité des réponses peut également diminuer.
Pour tirer le meilleur parti de nos modèles, nous vous recommandons de préserver le préfixe et, dans la mesure du possible, de concevoir votre intégration pour qu’elle ajoute tout nouvel élément à la fin du contexte.
Qu’est-ce qu’une modification du préfixe ?
Le préfixe d’un élément de raisonnement est la partie de l’historique de la conversation qui précède cet élément. Vous modifiez ce préfixe si, par exemple, vous raccourcissez un résultat d’outil, réécrivez un message du développeur ou remplacez des tours antérieurs par un résumé.
| 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 |
Adapter votre intégration pour préserver le préfixe
Vous pouvez modifier le préfixe sans le vouloir en changeant des paramètres de l’API Responses tels que tools, instructions ou text.format, ou en modifiant des éléments antérieurs de input. Vérifiez si votre intégration effectue de telles modifications.
Le tableau ci-dessous présente les situations courantes où une intégration modifie le préfixe et explique comment obtenir le même résultat, lorsque c’est possible, en ajoutant des éléments à la fin du contexte.
| Motif courant de modification du préfixe | Comment préserver le préfixe |
|---|---|
| Modifier l’effort de raisonnement | Conservez la valeur initiale du paramètre reasoning.effort au niveau de la requête dans l’API Responses. Ajoutez à la fin de la liste des éléments d’entrée un élément configuration_update qui indique le nouvel effort de raisonnement. |
| Modifier les schémas de sorties structurées | Conservez la valeur initiale du paramètre text.format au niveau de la requête dans l’API Responses. Ajoutez à la fin de la liste des éléments d’entrée un élément configuration_update qui contient le nouveau schéma. |
| Modifier les outils disponibles pour l’agent | Conservez la valeur du paramètre tools de l’API Responses. Utilisez un élément additional_tools pour ajouter des outils, ou utilisez tool_choice avec allowed_tools pour limiter les outils que le modèle peut appeler lors d’un tour. Conservez les définitions d’outils existantes dans leur ordre d’origine. Ajoutez à la fin du contexte un élément additional_tools avec le rôle developer et un tableau tools. Lorsque vous renvoyez cet élément, conservez sa position d’origine. |
| Mettre à jour les instructions du développeur | Conservez le message initial du développeur. Ajoutez à la fin du contexte un nouveau message developer qui demande au modèle d’ignorer les anciennes instructions et de suivre les nouvelles. Pour les instructions qui ne s’appliquent qu’à un seul tour, placez un point d’arrêt explicite du cache juste avant le dernier message du développeur afin que le préfixe réutilisable se termine avant ce message. |
| Compacter le contexte | Le compactage modifie le préfixe. Il est donc difficile d’éviter les défauts de cache dans ce cas. Compactage d’OpenAI : si vous utilisez le compactage d’OpenAI via /responses/compact ou context_management, nos systèmes conservent les éléments de raisonnement qui suivent la modification du préfixe. Un élément de compactage d’OpenAI peut se trouver n’importe où dans le contexte. Lorsque vous appelez /responses/compact, omettez instructions, puis transmettez la fenêtre de contexte renvoyée à la requête suivante en conservant l’ordre de ses éléments. Si votre historique contient des éléments configuration_update, respectez les exigences de compactage applicables aux mises à jour de configuration.Compactage personnalisé : si vous utilisez une autre stratégie de compactage ou si vous avez conçu la vôtre, placez l’élément compacté à la fin du contexte du modèle. Si vous choisissez de le placer avant les tours récents, l’API écartera les éléments de raisonnement de l’historique d’origine situés après cet élément. |
| Raccourcir des résultats d’outils antérieurs ou réduire la taille de fichiers ou d’images déjà envoyés | Certaines intégrations tronquent des éléments antérieurs, comme des résultats d’outils, des fichiers ou des images, au lieu d’utiliser le compactage. Ces modifications changent le préfixe. Nous vous recommandons vivement d’utiliser le compactage ou de raccourcir les longs résultats d’outils et de réduire la taille des images ou des fichiers avant leur premier envoi au modèle. |
Repérer les modifications du préfixe dans votre intégration
Utilisez les diagnostics de mise en cache des prompts pour repérer les défauts de cache et rechercher les modifications du préfixe. Pour comparer une requête à une réponse antérieure, attribuez à prompt_cache_options.comparison_response_id l’identifiant de cette réponse, puis examinez le motif indiqué par le diagnostic et le nombre de tokens mis en cache. Utilisez ces informations pour réduire les modifications du préfixe dans votre intégration. Les diagnostics signalent la première différence qu’ils parviennent à identifier. Ils ne permettent pas de vérifier si le modèle a réutilisé le raisonnement.