Introduction

Les API d'inférence ont initialement promis une simplicité : envoyer des entrées, recevoir des sorties. Cependant, cette abstraction n'a jamais été entièrement vraie. Les caches de prompts, la tokenisation et l'échantillonnage diffèrent entre les modèles, rendant les sessions non portables.

Problèmes de portabilité

Les API d'inférence sont de plus en plus frustrantes, car elles retournent un mélange de texte et d'état lié au fournisseur, intentionnellement non portable. Cela inclut des jetons de raisonnement opaques, des recherches web où le modèle voit des matériaux que le client ne voit pas, et des références de fichiers et de caches qui ne peuvent pas être résolues ailleurs.

Tests de portabilité

Une session portable signifie qu'un autre modèle peut continuer le travail à partir d'une archive intelligible. Cela nécessite cinq tests : inspection, exportation, replay, audit et suppression. Un ID de réponse n'est pas un transcript, un texte chiffré que l'utilisateur ne peut pas déchiffrer n'est pas un état contrôlé par l'utilisateur.

Encryption et confidentialité

L'encryption des données peut être trompeuse. Le terme « état scellé par le fournisseur » est plus approprié. Cette encryption cache les données à l'utilisateur, pas au fournisseur. Les conversations stockées transforment un transcript en pointeur, rendant les données non portables.

const first = responses.create({
  model: "frontier-model",
  input: "Investigate this production failure",
  store: true,
});

Les applications envoient moins de données, mais l'état caché et les outils sont préservés par le fournisseur, rendant les sessions non portables.