OpenAI prend en charge les sorties structurées dans l’API

• Introduction de "Structured Outputs" dans l’API
  • Nouvelle fonctionnalité permettant au modèle de produire une sortie correspondant exactement au schéma JSON fourni par le développeur
  • OpenAI avait présenté l’an dernier le mode JSON lors du DevDay, sans toutefois garantir des réponses conformes à un schéma précis
  • Les sorties structurées limitent la sortie du modèle au schéma fourni par le développeur et entraînent le modèle à mieux comprendre des schémas complexes
• Pourquoi les sorties structurées sont nécessaires
  • Générer des données structurées à partir d’entrées non structurées est l’un des principaux cas d’usage de l’IA
  • L’API OpenAI permet d’effectuer diverses tâches, comme la recherche de données, les questions-réponses, l’extraction de données ou la création de workflows multi-étapes
  • Jusqu’à présent, il fallait recourir à des outils open source, des prompts, des tentatives répétées, etc., pour obtenir un format de sortie interopérable avec les systèmes
  • Les sorties structurées résolvent ce problème en contraignant la sortie du modèle au schéma fourni par le développeur
• Évaluation des performances
  • Lors d’une évaluation portant sur le respect de schémas JSON complexes, le modèle gpt-4o-2024-08-06 a obtenu un score de 100 %
  • Le modèle gpt-4-0613 a obtenu un score inférieur à 40 %
• Comment utiliser les sorties structurées
  • Sorties structurées via function calling : définir strict: true dans la définition de fonction
    • Disponible sur les modèles prenant en charge les outils
• Sorties structurées sûres
  • Respecte les politiques de sécurité existantes d’OpenAI
  • Le modèle peut refuser des requêtes non sûres
  • La réponse de l’API inclut une valeur de chaîne de refus, ce qui permet de détecter par programme si le modèle a généré un refus
• Prise en charge native dans les SDK
  • Les SDK Python et Node prennent en charge nativement les sorties structurées
  • Il est possible de fournir des objets Pydantic ou Zod, convertis en schéma JSON, puis de sérialiser et d’analyser automatiquement la réponse JSON
• Limitations
  • Seule une partie du schéma JSON est prise en charge
  • Une latence supplémentaire peut survenir lors de la première réponse API avec un nouveau schéma
  • Le modèle peut refuser des requêtes non sûres
  • Non compatible avec les appels de fonctions parallèles
  • Les sorties structurées ne relèvent pas de Zero Data Retention (ZDR)
• Disponibilité
  • Les sorties structurées sont généralement disponibles dans l’API
  • Les sorties structurées via function calling sont disponibles sur tous les modèles prenant en charge le function calling
  • L’option de format de réponse est disponible sur les modèles les plus récents

Le résumé de GN⁺

• La nouvelle fonctionnalité d’OpenAI, les sorties structurées, permet d’aligner précisément la sortie du modèle sur un schéma JSON
• Les développeurs peuvent ainsi réaliser de manière plus fiable diverses tâches, comme la recherche de données, les questions-réponses ou l’extraction de données
• La prise en charge native dans les SDK Python et Node facilite le développement
• Il existe aussi divers cas d’usage supplémentaires, comme l’extraction de données structurées à partir de données non structurées
• La fonctionnalité utilise une technique de constrained decoding pour contraindre la sortie du modèle et ne générer qu’un JSON valide

[bluejoyq]

C’est une fonctionnalité intéressante.

[GN⁺]

Avis Hacker News

• Construction d’interfaces utilisateur dynamiques et de code avec GPT-4o

  • Fonctionne de manière fiable avec le mode JSON
  • Cela devrait aider à résoudre les problèmes de format avec GPT-4o-mini
  • En mode appel de fonction, le taux de réussite est plus faible qu’en mode JSON
  • Il y a beaucoup d’attentes autour de cette fonctionnalité

• Principaux changements de gpt-4o-2024-08-06

  • Les jetons de sortie passent de 4k à 16k
  • Baisse de 50 % du coût d’entrée et de 33 % du coût de sortie
  • Il s’agit d’un changement important pour les utilisateurs de l’API

• Retour d’expérience sur l’utilisation de Structured Output d’Outlines avec vLLM

  • Offre des fonctionnalités plus avancées que Structured Output d’OpenAI
  • Prise en charge limitée des types de champs
    • OpenAI ne prend en charge que les types de base comme String, Number, Boolean, etc.
    • Outlines permet de définir des motifs d’expression régulière
  • Coût élevé de configuration du schéma et latence
    • vLLM et Outlines ne coûtent presque rien
    • OpenAI met du temps à générer une grammaire sans contexte
  • C’est un bon début pour OpenAI, mais cela doit encore progresser

• Avis sur les performances de l’IA

  • Le fait de spécifier le format de sortie pour l’IA est une ancienne manière de résoudre le problème
  • Le traitement du langage naturel et les capacités de résolution de problèmes ont fait des progrès remarquables
  • Cependant, obtenir ce résultat demande une quantité énorme de calcul

• Avis sur l’approche d’OpenAI

  • Abandon de l’approche par fine-tuning pour les sorties structurées
  • llama.cpp implémente déjà cette fonctionnalité depuis 1,5 an

• Confusion autour de l’option "strict: true"

  • Comme c’est toujours le comportement souhaité, cela devrait être la valeur par défaut
  • Découverte des techniques de constrained decoding
    • Elles peuvent améliorer la fiabilité et réduire la latence

• Avis selon lequel coder en dur le JSON dans le modèle va à l’encontre de l’objectif AGI

• Inquiétudes concernant l’effet de verrouillage lors de l’utilisation des fonctionnalités d’OpenAI

  • Il n’est pas facile de passer à un autre LLM
  • Recommandation de ne l’utiliser que lorsque les prompts textuels ne suffisent pas

• Remarque sur une erreur de format JSON

  • {“val{“:2} est un JSON valide

• Question sur la raison pour laquelle le niveau supérieur doit être un objet

  • Il est peu pratique de devoir encapsuler un tableau dans un objet