Aller au contenu principal
Dernière mise à jour le

Interroger un modèle avec l'API Open Responses

Cet article explique comment interroger des modèles de fondation à l'aide de l'API Open Responses et décrit le comportement spécifique au fournisseur à prendre en compte lorsque vous le faites.

L'Open Responses API est une implémentation ouverte et multi-fournisseur du format de requête de type réponses. Il utilise un champ input au lieu de messages et renvoie un tableau output structuré. Envoyez les requêtes au chemin /serving-endpoints/open-responses avec le nom de l'endpoint de mise en service du modèle dans le champ model du corps de la requête.

remarque

Pour les modèles OpenAI, utilisez directement l'OpenAI Responses API. Ce chemin est un passthrough natif et prend en charge l'ensemble complet des paramètres et outils d'OpenAI Responses. Cet article traite de l'API Open Responses, qui fonctionne avec différents fournisseurs mais prend en charge un ensemble de fonctionnalités ciblé.

Exemples de query​

L'exemple suivant interroge un Endpoint de modèle de fondation avec l'API Open Responses.

Bash
curl \
  -u token:$DATABRICKS_TOKEN \
  -X POST \
  -H "Content-Type: application/json" \
  -d '{
    "model": "databricks-claude-sonnet-4-5",
    "input": [
      {
        "role": "user",
        "content": "What is a mixture of experts model?"
      }
    ],
    "max_output_tokens": 256
  }' \
  https://<workspace_host>.databricks.com/serving-endpoints/open-responses

La réponse est un objet response avec un tableau output. Pour les requêtes de streaming (stream: true), la réponse est un text/event-stream où chaque événement est un fragment de réponse.

Comportement spécifique au fournisseur​

Databricks traduit la requête Open Responses au format natif de chaque fournisseur. Le comportement est cohérent pour la plupart des requêtes, mais les différences spécifiques au fournisseur suivantes s'appliquent.

Tous les fournisseurs​

  • **Les conversations sont sans état.** previous_response_id et le stockage de conversation côté serveur ne sont pas pris en charge. Envoyez la conversation complète dans le champ input à chaque tour.
  • **Certains champs spécifiques à OpenAI sont acceptés mais ignorés** sur les fournisseurs non-OpenAI. Des champs tels que user, safety_identifier, metadata et truncation sont renvoyés dans la réponse pour des raisons de portabilité, mais ne modifient pas le comportement du fournisseur.

Modèles hébergés par Databricks (open source)​

  • La prise en charge des fonctionnalités dépend du modèle. L'appel de fonctions, le raisonnement, la sortie structurée et l'entrée d'image sont activés par modèle. Une requête qui utilise une fonctionnalité non prise en charge par le modèle renvoie une erreur. Par exemple, un modèle qui prend en charge le raisonnement pourrait ne pas prendre en charge l'entrée d'images.
  • L'image d'entrée doit être une URL ou un URI de données. Fournissez les images via image_url en tant qu’URL https ou URI data:. Les références de fichier (file_id) et les entrées de document (input_file) ne sont pas prises en charge.

Modèles Anthropic Claude​

  • La température utilise une échelle de 0 à 2. Claude utilise une plage native de 0 à 1, c’est pourquoi Databricks rééchelonne la valeur en la divisant par deux —temperature: 1.0 se comporte comme 0.5.
  • Raisonnement itératif au fil des tournées. Pour permettre au modèle de raisonner sur sa réflexion antérieure dans une conversation à plusieurs tours, renvoyez les reasoning éléments retournés — dont encrypted_content est inchangé — dans le input de la requête suivante. Consultez la section Modèles de raisonnement de query.
  • Les entrées d'image et de document doivent être des URI de données base64. Fournir les images via image_url en tant qu'URI base64 data: et les documents via file_data en tant qu'URI base64 data:. Les URL https et les références file_id ne sont pas prises en charge.
  • La sortie structurée a des contraintes. text.format de type json_schema est pris en charge, mais json_object ne l'est pas et renvoie une erreur. La sortie structurée ne peut pas être combinée avec le streaming ou le raisonnement, et vous ne pouvez pas pin tool_choice à un outil spécifique lorsque vous l'utilisez. Voir les sorties structurées sur Databricks.
  • **Jetons de raisonnement** sont inclus dans usage.output_tokens plutôt que signalés séparément.

Modèles Google Gemini​

  • La température utilise une échelle de 0 à 2. Gemini utilise une plage native de 0–1, de sorte que Databricks divise la valeur par deux—temperature: 1.0 se comporte comme 0.5.
  • Raisonnement itératif au fil des tournées. Pour permettre au modèle de raisonner sur sa réflexion antérieure dans une conversation à plusieurs tours, renvoyez les reasoning éléments retournés — dont encrypted_content est inchangé — dans le input de la requête suivante. Consultez la section Modèles de raisonnement de query.
  • L'entrée d'image accepte à la fois les URLs https et les URI de données base64.
  • Les jetons de raisonnement sont signalés dans usage.output_tokens_details.reasoning_tokens.
important

Les appels d'outils à plusieurs tours avec Gemini nécessitent de préserver encrypted_content. Gemini renvoie une valeur encrypted_content sur chaque élément function_call qu'il produit. Lorsque vous renvoyez le résultat de l'outil pour le tour suivant, vous devez inclure l'élément function_call d'origine avec son champ encrypted_content inchangé. Les cadres d'agents qui reconstruisent les appels d'outils à partir de name, arguments et call_id uniquement, suppriment ce champ, ce qui entraîne le rejet de la requête de suivi.

L'exemple suivant préserve l'objet function_call (avec son encrypted_content) lors du retour du résultat de l'outil :

JSON
{
  "model": "databricks-gemini-2-5-pro",
  "input": [
    { "role": "user", "content": "What's the weather in San Francisco?" },
    {
      "type": "function_call",
      "call_id": "call_abc123",
      "name": "get_weather",
      "arguments": "{\"city\": \"San Francisco\"}",
      "encrypted_content": "<opaque-provider-signature>"
    },
    {
      "type": "function_call_output",
      "call_id": "call_abc123",
      "output": "{\"temp_f\": 64}"
    }
  ]
}

Outils​

L'API Open Responses prend en charge les outils de type functionchez les différents fournisseurs. Pour plus de détails et les modèles pris en charge, consultez Appels de fonction sur Databricks. Pour l'outil intégré de recherche web, consultez Recherche web sur Databricks.

Les autres types d'outils intégrés et personnalisés (par exemple custom, apply_patch, image_generation, et mcp) sont disponibles uniquement via l'OpenAI Responses API.

Modèles pris en charge​

L'API Open Responses est disponible pour l'ensemble des modèles de fondation Databricks, notamment Anthropic Claude, Google Gemini et les modèles open source hébergés par Databricks, et la prise en charge s'étendra aux nouveaux modèles à l'avenir. Pour la liste actuelle des modèles disponibles, consultez les types de modèles de fondation.

La prise en charge des fonctionnalités, telles que l'appel de fonction, le raisonnement, la sortie structurée et l'entrée d'image, dépend du modèle sous-jacent. Consultez le comportement spécifique au fournisseur.

Types d'entrée pris en charge​

Le support d'entrée dépend du modèle et du fournisseur. L'entrée de texte est prise en charge par tous les modèles. Pour l'entrée d'image, consultez les notes par fournisseur dans Comportement spécifique au fournisseur et les exigences de format et de taille dans Query vision models. Pour les types d'entrée par modèle, consultez les modèles de fondation hébergés par Databricks disponibles dans les API APIs.

Ressources supplémentaires​

Sur cette page