Passer au contenu principal
Il s’agit de l’endpoint d’inférence de GLiDE. Envoyez un state et une ou plusieurs questions nommées et typées ; lisez les décisions structurées dans answers. state peut être vide lorsque la question contient tout le contexte. GLiDE n’utilise pas /v1/chat/completions, messages ni un schema GLiNER. GLiDE coûte 0,04 $ par million de tokens d’entrée. Les tokens de sortie sont gratuits (0 $). Consultez Tarifs pour connaître les tarifs d’inférence actuels.

Voir le contrat d'API

Examinez le schéma exhaustif de requête et de réponse de POST /v1/systemone.

Recettes GLiDE

Requêtes de bout en bout testées pour le tri des tickets, le contrôle des actions d’agent et la détection d’injections de prompt.

Configurez votre clé d’API

  1. Créez un compte Fastino
  2. Obtenez votre clé d’API depuis Settings
Définissez votre clé comme variable d’environnement afin que les exemples ci-dessous fonctionnent tels quels :

Choisir un type de question

Chaque question n’accepte qu’un seul libellé et renvoie des probabilités. Choisissez la primitive selon la forme de réponse dont votre code a besoin : Il n’existe pas de primitive multi-libellé. Posez plusieurs questions nommées indépendamment dans une même requête lorsque vous avez besoin de plusieurs jugements sur le même state.

Requête

string
requis
Utilisez fastino/GLiDE ou l’ID d’un modèle GLiDE que vous avez déployé. S’il est omis, l’API renvoie 422 'model' must be provided. La réponse renvoie le nom du moteur sous la forme glide.
string | object | array
requis
La situation à évaluer. Utilisez une chaîne pour un passage unique, un objet pour des champs étiquetés, ou un tableau pour une séquence ordonnée de messages ou d’enregistrements. Une chaîne, un objet ou un tableau vide est accepté lorsque la question contient tout le contexte.
object
requis
Un objet non vide dont les clés sont des noms que vous choisissez. Chaque valeur doit contenir type et instructions ; Choice et Score exigent également criteria. Les mêmes clés apparaissent sous answers dans la réponse. Consultez Noul, Choice et Score pour la forme complète de requête et de réponse de chaque type.
boolean
défaut:"true"
Indique si Fastino conserve l’entrée et la sortie de cette requête. Définissez false pour ne conserver ni l’une ni l’autre. Consultez Exclure une requête du stockage.

Formes de state

state est le contenu au regard duquel chaque question est évaluée : considérez-le comme ce que vous remettriez à un panel d’experts avant de leur demander de porter un jugement. Utilisez un objet lorsque la décision dépend de la comparaison de plusieurs parties nommées (par exemple, un ticket et la politique au regard de laquelle il est évalué) : chaque partie reste ainsi identifiée et leurs relations restent claires. Une chaîne simple suffit lorsque le cas se résume à un passage unique et autonome. Toutes les questions d’une requête voient le même state et sont évaluées indépendamment au regard de celui-ci.

Images en entrée

Un tableau peut combiner des chaînes ou des parties texte avec jusqu’à quatre parties image_url. Chaque URL d’image peut être une URL HTTPS ou une data URL en base64 :
Une data URL transporte l’image dans la requête elle-même, au format data:<media type>;base64,<data> :
Pour construire cette requête à partir d’un fichier local, encodez le fichier et écrivez le corps dans un fichier. Envoyez-le avec -d @body.json, car une image de plusieurs mégaoctets peut être trop longue pour un argument de ligne de commande :
Chaque image doit respecter ces limites :
  • La limite de taille compte le base64 après la virgule, pas le préfixe data:.
  • La limite de taille porte sur les octets, pas sur les pixels. Les métadonnées intégrées et le remplissage comptent : une image 800×600 complétée jusqu’à 5 MiB est refusée.
  • Fastino lit les octets de chaque image et les compare au type de média déclaré. Un PNG envoyé comme data:image/jpeg est refusé.
  • Fastino télécharge lui-même les images par URL. L’hôte doit répondre 200 sans redirection, et certains hôtes refusent les téléchargements automatisés. Si une URL échoue, envoyez l’image sous forme de data URL.
GLiDE redimensionne chaque image entre 65 536 et 1 048 576 pixels (environ 1 mégapixel) avant de la lire. Chaque image ajoute donc entre 64 et 1 024 tokens d’entrée. Les tokens d’image comptent une fois par question, car GLiDE évalue chaque question séparément au regard de tout le state. Par exemple, la même photo 2048×1280 a utilisé 1 087 tokens d’entrée avec une question et 4 302 avec quatre. Les tokens d’image comptent aussi dans la limite de 65 536 tokens du prompt de chaque question.
Redimensionnez les images à environ 1 mégapixel, par exemple 1280×800, avant de les envoyer. Les images plus grandes coûtent les mêmes tokens et sont plus longues à téléverser. Lors des tests de Fastino, une photo 5388×3368 et sa copie 1280×800 ont utilisé les mêmes tokens et renvoyé les mêmes réponses.
Consultez Erreurs liées aux images GLiDE pour chaque message d’erreur d’image et sa correction.

Requête complète

Réponse

answers utilise les clés de question de votre requête. Pour ce Noul :
  • noul est la probabilité que le critère true soit vérifié. Ce n’est pas un booléen.
  • confidence est la certitude quant à l’un ou l’autre résultat : |2 × noul − 1|.
  • Ajustez les seuils d’action sur des données représentatives. Ne supposez pas que 0.5 est le bon seuil métier.
Choice et Score renvoient des champs différents. Consultez leurs pages de primitive pour les formes de réponse exactes et des exemples d’intégration.

Exclure une requête du stockage

Ajoutez "store": false au corps de la requête. Fastino ne conserve alors ni le state et les questions que vous avez envoyés, ni les answers renvoyées :
  • Aucune entrée n’est ajoutée à votre historique d’inférence.
  • La charge utile n’apparaît pas dans les journaux, les rapports d’erreurs ni les traces de Fastino.
  • La requête n’est jamais utilisée pour l’entraînement de la plateforme ni pour l’adaptation continue de vos modèles de tâches, quel que soit votre choix de désactivation de l’entraînement.
Fastino enregistre toujours les métadonnées d’utilisation pour la facturation : modèle, nombre de tokens, latence, statut et coût. L’en-tête de réponse X-Fastino-Data-Retention indique ce qui a été appliqué :

Combiner plusieurs questions

Posez plusieurs questions de types différents sur le même state en un seul appel. Toutes les questions sont évaluées ensemble en un seul aller-retour.
Réponse :

Limites et formes non prises en charge

  • Chaque prompt de question rendu (state plus cette question) doit tenir dans 65 536 tokens.
  • Choice exige 2 à 255 options ; une option unique ne peut représenter ni une décision ni un écart de confiance significatif. Score accepte au maximum 255 niveaux.
  • usage.input_tokens additionne les passes internes de toutes les questions ; il peut donc dépasser 65 536 même si chaque prompt rendu individuellement tient dans la limite.
  • state accepte jusqu’à 4 images d’au plus 3,75 MiB et 25 000 000 pixels chacune, en JPEG, PNG, GIF ou WebP. Consultez Images en entrée.
  • Une requête évalue un seul state partagé ; placez plusieurs questions sous questions.
  • /v1/systemone ne prend pas en charge le streaming et n’accepte pas de lot d’états indépendants.
  • Pour appeler un modèle GLiDE que vous avez entraîné, envoyez l’ID de son modèle déployé dans model, avec un state uniquement textuel. Voir Entraîner GLiDE.
Consultez Confiance et incertitude pour les formules de confiance et le routage fondé sur la confiance.

Migrer depuis TypeSafe

Jev de TypeSafe et GLiDE de Fastino utilisent la même structure System One : un state, des questions nommées et les answers correspondantes. La plupart des requêtes se transposent sans difficulté, mais l’intégration n’est pas un simple remplacement direct. Suivez cette liste de contrôle pour migrer en toute sécurité :
1

Conserver la structure de requête System One

Préservez state, les clés de question et les types de primitive. state peut être vide lorsque la question contient tout le contexte. Chaque valeur instructions peut être une chaîne non vide ou un objet JSON non vide ; GLiDE sérialise les objets en texte JSON compact. Convertissez les instructions omises, nulles ou sous forme de tableau en chaîne ou en objet. Conservez les critères Choice sous forme d’objet. Les critères Noul sont facultatifs, mais leurs valeurs true et false doivent être des chaînes. Privilégiez un tableau ordonné pour les critères Score. N’envoyez que les champs de requête documentés dont votre intégration a besoin. Les champs de premier niveau non pris en charge renvoient 422 ; ne copiez donc pas d’options arbitraires du client TypeSafe dans le corps JSON.
2

Changer l'endpoint, l'identifiant et le modèle

Dirigez la requête vers Fastino, lisez FASTINO_API_KEY, envoyez-la avec X-API-Key et définissez model sur fastino/GLiDE. Fastino accepte aussi l’en-tête Bearer si conserver ce style simplifie une migration HTTP directe. Attendez-vous à model: "glide" dans la réponse.
3

Mettre à jour le traitement des réponses Score

Le score de TypeSafe est un nombre à virgule flottante pondéré par les probabilités. Son équivalent GLiDE est expected_level. Le score de GLiDE est en revanche l’indice entier du niveau le plus probable. GLiDE renvoie les descriptions de la légende Score sous forme de chaînes ; mettez donc à jour les consommateurs qui attendent des valeurs de légende structurées. Pour les requêtes Score, GLiDE accepte aussi des objets de critères avec des clés numériques sous forme de chaîne, comme {"1": "low", "3": "medium", "5": "high"}. Les clés sont triées puis ignorées, et la réponse est réindexée de 0 à N-1. Utilisez un tableau ordonné lorsque les valeurs numériques d’origine ne doivent pas être confondues avec les indices de niveau renvoyés.
4

Vérifier les clés de niveau et le comportement des nouvelles tentatives

GLiDE renvoie les probabilities et la legend de Score avec des clés de type chaîne, comme "0" et "1". La réponse HTTP brute de TypeSafe fait de même, mais son SDK Python peut exposer des clés entières. Convertissez les clés uniquement si l’application a besoin de maps à clés entières. Remplacez la gestion des nouvelles tentatives sur 529 de TypeSafe par la gestion de 425 et 503 de Fastino, et conservez un backoff borné pour 429. Respectez Retry-After lorsqu’il est présent et appliquez le même budget de nouvelles tentatives aux défaillances de transport.
5

Revalider les seuils de décision

Gardez les actions métier existantes intactes pendant le portage, puis testez GLiDE sur des cas représentatifs avant le déploiement. Ne supposez pas que des seuils calibrés pour Jev se transposent tels quels à un modèle différent.
Ne faites pas correspondre le score à virgule flottante de TypeSafe au score de GLiDE. Lisez answers.&lt;key&gt;.expected_level lorsque le code existant attend un score pondéré. Lisez answers.&lt;key&gt;.score uniquement lorsque le code a besoin de l’indice du seul niveau gagnant.

Remplacer l’utilisation du SDK TypeSafe

Si le projet utilise un SDK TypeSafe :
  1. Recherchez typesafe-sdk, @typesafe-ai/sdk, TypeSafeClient, AsyncTypeSafeClient et les constructeurs de questions TypeSafe dans les manifestes, les imports, le code applicatif et les tests.
  2. Remplacez les constructeurs du SDK et l’accès typé aux réponses par le client HTTP du projet et le JSON décodé.
  3. Supprimez les packages et imports TypeSafe uniquement lorsqu’il ne reste plus aucune référence.
Les règles d’endpoint, de validation, de nouvelles tentatives et de Score ci-dessus s’appliquent toujours.

Erreurs

Une première requête vers un modèle à froid peut renvoyer 425 model_warming pendant son préchauffage ; réessayez après environ 60 secondes. Utilisez un délai de lecture d’au moins 300 secondes et un backoff borné pour 425, 429 et 503. Ne retentez pas 401, 402, 403, 404 ou 422 sans corriger le problème sous-jacent.

Pour aller plus loin

Présentation de GLiDE

Découvrez GLiDE, choisissez une primitive et consultez les recommandations propres au modèle.

Noul

Intégrez une probabilité oui/non.

Choice

Routez vers une option nommée.

Score

Évaluez selon une grille ordonnée.