Skip to main content
Fastino propose deux interfaces synchrones pour l’inférence GLiNER. Choisissez l’interface qui correspond à votre modèle et aux exigences de votre charge utile :
Commencez par /v1/chat/completions pour bénéficier d’une API cohérente entre les modèles de base et affinés. Utilisez /v1/gliner-2 lorsque vous avez spécifiquement besoin du contrat natif du modèle de base GLiNER2 fixe, de l’entrée par lots ou du traitement asynchrone.
Cette page documente ci-dessous le contrat HTTP brut de /v1/chat/completions. Les schémas natifs de /v1/gliner-2 sont publiés dans le document OpenAPI. L’utilisation du SDK, l’entraînement des modèles, l’évaluation, l’historique d’inférence et le feedback sortent du cadre de cette page.
POST /inference a été supprimé. N’envoyez pas ses champs hérités tels que model_id, text, task, format_results ou is_warmup.

Endpoint

Authentification

Envoyez une clé d’API Fastino en tant que bearer token :

Requête

string
requis
Un identifiant de modèle de base compatible avec l’inférence ou l’UUID d’une tâche d’entraînement Fastino terminée et déployable.
object[]
requis
Une liste de messages non vide. Pour l’inférence GLiNER, placez le texte à analyser dans le content d’un message utilisateur.
object
Définit des tâches d’encodeur personnalisées. Fournissez un dictionnaire contenant une ou plusieurs des clés entities, classifications, structures ou relations. Ne l’omettez que lorsque le modèle sélectionné a une tâche par défaut configurée.Un tableau plat d’étiquettes d’entités est déprécié. Utilisez toujours la forme dictionnaire.
number
défaut:"0.5"
Seuil de confiance de 0 à 1. Les valeurs plus basses favorisent le rappel ; les plus élevées favorisent la précision.
boolean
défaut:"true"
Inclut les valeurs de confiance dans les résultats extraits.
boolean
défaut:"true"
Inclut les décalages de caractères en intervalle semi-ouvert (start, end) dans les résultats d’entités.
boolean
défaut:"true"
Persiste l’inférence. Définissez sur false pour ne pas la conserver.

Schéma d’entités

Utilisez des définitions d’entités descriptives lorsque c’est possible :

Schéma de classification

Schéma d’extraction structurée

Les champs de structure utilisent des spécifications field::type::description :

Schéma de relations

Le schéma de relations le plus simple est une liste plate de noms de relations :
Vous pouvez également utiliser un dictionnaire pour ajouter des descriptions ou une configuration par relation :
N’envoyez pas d’objets de relation contenant des définitions head et tail.

Schéma combiné

Exécutez plusieurs tâches sur le même texte en combinant les clés :
Le schéma identifie l’opération automatiquement. N’envoyez pas task ni task_type.

Exemple

La valeur de model doit actuellement prendre en charge l’inférence hébergée. Utilisez le catalogue de modèles en direct plutôt que de supposer que chaque checkpoint Hugging Face est disponible :

Réponse

Le endpoint renvoie une enveloppe de chat completion. Le résultat GLiNER est sérialisé sous forme de chaîne JSON dans choices[0].message.content :
Analysez choices[0].message.content comme JSON avant de lire les résultats de la tâche. Lorsque store=true, x_pioneer.inference_id identifie l’inférence persistée.

Entrées répétées

Le endpoint accepte une conversation par requête. Il ne prend pas en charge la forme de lot text: string[] de l’endpoint natif supprimé. Envoyez des requêtes séparées en simultané lors du traitement de plusieurs entrées.

Démarrages à froid et nouvelles tentatives

Un modèle inactif ou récemment déployé peut subir un démarrage à froid. Utilisez un délai de lecture d’au moins 300 secondes et retentez les réponses 425, 429 et 503. Respectez l’en-tête de réponse Retry-After lorsqu’il est présent. Une requête expirée peut tout de même réchauffer le déploiement, permettant à la requête suivante d’aboutir. Ne retentez pas les erreurs d’authentification, de facturation, de validation, de modèle inconnu ou de tâche non déployable sans corriger le problème sous-jacent.

Erreurs

Migration des requêtes héritées