Tous les produits
Search
Centre de documentation

Platform For AI:Déployer un flux d'application

Dernière mise à jour :Aug 09, 2026

Après avoir développé un flux d'application, déployez-le en tant que service Elastic Algorithm Service (EAS). EAS propose la mise à l'échelle automatique et une surveillance complète des opérations et de la maintenance pour aider votre application à s'adapter avec souplesse aux évolutions et à la croissance de votre activité.

Prérequis

Créez et déboguez un flux d'application. Consultez la rubrique Développement de flux d'application.

Déployer un flux d'application

Accédez à LangStudio et sélectionnez un espace de travail. Dans l'onglet Application Flow, cliquez sur un flux d'application débogué, puis cliquez sur Deploy dans le coin supérieur droit. Assurez-vous que le runtime est démarré avant le déploiement. Les paramètres clés sont décrits ci-dessous.

image

Parameter

Description

Resource Information

Resource Type

Sélectionnez les public resources ou un dedicated resource group que vous avez créé.

Instances

Définissez le nombre d'instances de service. Pour la production, configurez plusieurs instances afin de réduire les risques liés à un point de défaillance unique.

Deployment Resources

Si le flux d'application est utilisé uniquement pour la planification des flux métier, sélectionnez des CPU resources appropriées en fonction de la complexité du flux. Les ressources CPU sont généralement plus rentables que les ressources GPU. Après le déploiement, la facturation des ressources s'applique. Consultez la rubrique Facturation d'Elastic Algorithm Service (EAS).

VPC : Le flux d'application est déployé en tant que service EAS. Pour garantir l'accès client, sélectionnez un VPC. Par défaut, les services EAS ne peuvent pas accéder à Internet. Pour activer l'accès à Internet, configurez un VPC disposant d'une connectivité Internet. Consultez la rubrique Accès EAS aux ressources publiques et privées.

Remarque

Si un flux d'application utilise une connexion à une base de données vectorielle (telle que Milvus), assurez-vous que le VPC configuré correspond au VPC de l'instance de base de données vectorielle ou que les deux VPC sont connectés.

History

Enable History

S'applique uniquement aux flux d'application de type chat. Lorsqu'elle est activée, cette option permet au système de stocker et de transmettre l'historique des conversations sur plusieurs tours. À utiliser conjointement avec le paramètre d'en-tête de requête.

History Storage

Le stockage local ne prend pas en charge le déploiement multi-instances. Pour les services de production, utilisez un stockage externe tel qu'ApsaraDB RDS. Pour plus d'informations, consultez l'Annexe : Historique des chats.

Important

Avec le stockage local, le déploiement multi-instances n'est pas pris en charge, et le passage d'une instance unique à plusieurs instances est également impossible. Sinon, l'historique des chats peut ne pas fonctionner correctement.

Enable Tracing : Lorsque cette option est activée, vous pouvez afficher les enregistrements de trace pour évaluer l'effet du flux d'application après le déploiement.

Rôles et autorisations : Dans le flux d'application, si vous utilisez une base de données vectorielle Faiss (sélectionnez une base de données vectorielle Faiss ou Milvus lors de la création d'une base de connaissances) ou « Alibaba Cloud IQS Search » (requis par le modèle Chatbot basé sur la recherche web IQS), vous devez sélectionner un rôle approprié.

Pour plus d'informations sur la configuration des paramètres, consultez la rubrique Déploiement personnalisé.

Débogage en ligne

Appeler le service

Débogage en ligne

Après un déploiement réussi, vous êtes redirigé vers PAI-EAS. Dans l'onglet Online Debugging, configurez et envoyez une requête. La clé dans le corps de la requête doit correspondre à la valeur du paramètre Chat Input dans le nœud de démarrage. Cette rubrique utilise le champ par défaut question.

image

Effectuer des appels API

  1. Dans l'onglet Overview, récupérez l'endpoint et le token.

    image

  2. Envoyez une requête API.

    Appelez le service en mode simple ou complet. Le tableau suivant décrit les différences.

    Property

    Simple Mode

    Complete Mode

    Request path

    <Endpoint>/

    <Endpoint>/run

    Feature description

    Renvoie directement les résultats de sortie du flux d'application.

    Renvoie une structure complexe, incluant l'état des nœuds, les messages d'erreur et les messages de sortie du flux d'application.

    Scenario

    • Seul le résultat final est nécessaire ; les détails du traitement interne ne sont pas importants.

    • Convient aux requêtes ou opérations simples pour obtenir rapidement des résultats.

    • Vous devez comprendre en détail le processus d'exécution du flux d'application, y compris l'état de chaque nœud et les éventuels messages d'erreur.

    • Adapté au débogage, à la surveillance ou à l'analyse de l'exécution du flux d'application.

    Advantages

    Simple d'utilisation, aucune nécessité d'analyser des structures complexes.

    • Fournit des informations complètes pour vous aider à comprendre en profondeur le processus d'exécution du flux d'application.

    • Aide à résoudre les problèmes et à optimiser les performances du flux d'application.

    Mode simple

    Commande cURL

    Le service de flux d'application EAS déployé prend en charge les appels en streaming ou non streaming à l'aide de commandes curl. Le tableau suivant fournit des exemples de requêtes et de réponses.

    Example

    Streaming

    Non-streaming

    Sample request

    curl -X POST \
         -H "Authorization: Bearer <your_token>" \
         -H "Content-Type: application/json" \
         -H "Accept: text/event-stream" \
         -d '{"question": "Where is the capital of France?"}' \
         "<your_endpoint>"
    curl -X POST \
         -H "Authorization: Bearer <your_token>" \
         -H "Content-Type: application/json" \
         -d '{"question": "Where is the capital of France?"}' \
         "<your_endpoint>"

    Sample response

    event: Message
    data: {"answer": ""}
    
    event: Message
    data: {"answer": "The"}
    
    event: Message
    data: {"answer": " capital"}
    
    event: Message
    data: {"answer": " of"}
    
    event: Message
    data: {"answer": " France"}
    
    event: Message
    data: {"answer": " is"}
    
    event: Message
    data: {"answer": " Paris"}
    
    event: Message
    data: {"answer": "."}
    
    event: Message
    data: {"answer": ""}
    {"answer":"The capital of France is Paris."}

    Le tableau suivant décrit les paramètres de requête.

    |
    **Parameter**
    |
    **Description**
    | | --- | --- | |
    -H "Authorization: Bearer <your_token>"
    |
    L'en-tête HTTP. Remplacez `` par le token que vous avez obtenu à l'étape 1.
    | |
    -H "Accept: text/event-stream"
    |
    Indique que le client accepte les requêtes SSE et que les informations renvoyées sont en **streaming**. **Remarque : le streaming n'est pris en charge que lorsqu'un nœud LLM est utilisé comme nœud de sortie du flux d'application (un nœud LLM est l'entrée directe du nœud final).**
    | |
    -d '{"question": "Where is the capital of France?"}'
    |
    Le corps de la requête, un objet JSON contenant une paire clé-valeur, qui est la chaîne de question. La clé doit correspondre au champ de paramètre « Chat Input » dans le « Start Node » du flux d'application. Dans ce cas, le champ par défaut `question` est utilisé.
    | |
    "<your_endpoint>"
    |
    L'URL de destination de la requête. Remplacez `` par l'endpoint que vous avez obtenu à l'étape 1.
    |



















    Code Python

    Les exemples suivants montrent comment utiliser la bibliothèque requests pour envoyer une requête POST à un service de flux d'application, en prenant en charge les appels en streaming ou non streaming. Assurez-vous d'avoir installé cette bibliothèque. Si ce n'est pas le cas, exécutez pip install requests pour l'installer.

    Example

    Streaming

    Non-streaming

    Sample request

    import requests
    import json
    
    url = "http://<your-endpoint-here>"
    token = "<your-token-here>"
    data = {"question": "Where is the capital of France?"}
    
    # Specify a request header, including the token of your application flow service.
    headers = {
        "Authorization": f"Bearer {token}",
        "Accept": "text/event-stream",
        "Content-Type": "application/json"
    }
    
    if __name__ == '__main__':
        with requests.post(url, json=data, headers=headers, stream=True) as r:
            for line in r.iter_lines(chunk_size=1024):
                print(line)
    
    import requests
    import json
    
    url = "http://<your-endpoint-here>"
    token = "<your-token-here>"
    data = {"question": "Where is the capital of France?"}
    
    # Specify a request header, including the token of your application flow service.
    headers = {
        "Authorization": f"Bearer {token}",
        "Content-Type": "application/json"
    }
    
    response = requests.post(url, json=data, headers=headers)
    
    if response.status_code == 200:
        print("Request is successful, results:")
        print(response.text)
    else:
        print(f"Request fails, status code: {response.status_code}")
    

    Sample response

    event: Message
    data: {"answer": ""}
    
    event: Message
    data: {"answer": "The"}
    
    event: Message
    data: {"answer": " capital"}
    
    event: Message
    data: {"answer": " of"}
    
    event: Message
    data: {"answer": " France"}
    
    event: Message
    data: {"answer": " is"}
    
    event: Message
    data: {"answer": " Paris"}
    
    event: Message
    data: {"answer": "."}
    
    event: Message
    data: {"answer": ""}
    {"answer":"The capital of France is Paris."}

    Le tableau suivant décrit les paramètres de requête.

    |
    **Parameter**
    |
    **Description**
    | | --- | --- | |
    url
    |
    L'URL de destination de la requête. Remplacez `` par l'endpoint que vous avez obtenu à l'étape 1.
    | |
    token
    |
    L'en-tête HTTP. Remplacez `` par le token que vous avez obtenu à l'étape 1.
    | |
    data
    |
    Le corps de la requête, un objet JSON contenant une paire clé-valeur, qui est la chaîne de question. La clé doit correspondre au champ de paramètre « Chat Input » dans le « Start Node » du flux d'application. Dans ce cas, le champ par défaut `question` est utilisé.
    | |
    "Accept": "text/event-stream"
    |
    Indique que le client accepte les requêtes SSE et que les informations renvoyées sont en **streaming**. **Remarque : le streaming n'est pris en charge que lorsqu'un nœud LLM est utilisé comme nœud de sortie du flux d'application (un nœud LLM est l'entrée directe du nœud final).**
    |



















    Mode complet

    Langstudio prend en charge les Server-Sent Events (SSE), qui permettent d'afficher l'état, les messages d'erreur et les messages de sortie de chaque nœud lors de l'exécution du flux d'application. Vous pouvez également personnaliser le contenu du node_run_infos dans les événements. L'exemple suivant utilise le débogage en ligne. Vous devez ajouter /run à l'adresse d'appel, puis modifier le corps de la requête :

    image

    Le tableau suivant décrit les paramètres du corps de la requête.

    Field Name

    Type

    Default Value

    Description

    inputs

    Mapping[str, Any]

    None

    Le dictionnaire de données d'entrée. Les clés doivent correspondre aux noms des champs d'entrée définis dans le flux d'application. Si le flux n'a pas d'entrées, ce champ est ignoré.

    stream

    bool

    True

    Contrôle le format de réponse. Valeur par défaut : Dynamic. Valeurs valides :

    • True : répond avec un streaming SSE. Le Content-Type dans l'en-tête de réponse est text/event-stream, et les données sont renvoyées au format DataOnly, divisées en différents événements : RunStarted, NodeUpdated, RunOutput et RunTerminated. Pour plus d'informations, consultez les tableaux ci-dessous.

    • False : répond avec un seul corps JSON. Le Content-Type dans l'en-tête de réponse est application/json. Vous pouvez consulter les informations de réponse dans la section Débogage en ligne.

    response_config

    Dict[str, Any]

    -

    Contrôle les informations détaillées sur les nœuds incluses dans la réponse en streaming (lorsque stream=True).

    ∟ include_node_description

    bool

    False

    (Dans response_config) Indique s'il faut inclure les descriptions des nœuds dans le flux d'événements SSE.

    ∟ include_node_display_name

    bool

    False

    (Dans response_config) Indique s'il faut inclure les noms d'affichage des nœuds dans le flux d'événements SSE.

    ∟ include_node_output

    bool

    False

    (Dans response_config) Indique s'il faut inclure les sorties des nœuds dans le flux d'événements SSE.

    ∟ exclude_nodes

    List[str]

    []

    (Dans response_config) Liste des noms de nœuds à exclure du flux d'événements SSE.

    Les données renvoyées sont divisées en différents événements : RunStarted, NodeUpdated, RunOutput et RunTerminated :

    Événement RunStarted

    • Définition : l'événement RunStarted marque le début de l'exécution. Il est généralement envoyé en tant que premier événement dans le flux SSE d'une exécution.

    • Exemple de charge utile :

      data: {"event": "RunStarted", "run_id": "fb745e15-3b3b-4a10-9e0d-0bea08d47411", "timestamp": "2025-06-12T08:15:07.223611Z", "flow_run_info": {"run_id": "fb745e15-3b3b-4a10-9e0d-0bea08d47411", "status": "Running", "error": null, "otel_trace_id": ""}}
    • Descriptions des champs :

      |
      **Field Name**
      |
      **Type**
      |
      **Description**
      | | --- | --- | --- | |
      event
      |
      string
      |
      Type d'événement, fixé à **RunStarted**.
      | |
      run_id
      |
      string
      |
      Identifiant unique de l'exécution actuelle.
      | |
      timestamp
      |
      string
      |
      Horodatage de l'occurrence de l'événement, conforme à la norme ISO 8601.
      | |
      flow_run_info
      |
      object
      |
      Contient les informations d'état final pour l'ensemble de l'exécution.
      | |
      ∟ run_id
      |
      string
      |
      (Dans flow_run_info) Identifiant unique de l'exécution (identique au `run_id` externe).
      | |
      ∟ status
      |
      string
      |
      (Dans flow_run_info) État initial de l'exécution, fixé à Running.
      | |
      ∟ error
      |
      object or null
      |
      (Dans flow_run_info) Si l'exécution échoue, contient un objet de message d'erreur ; sinon `null`.
      | |
      ∟ otel_trace_id
      |
      string
      |
      (Dans flow_run_info) ID de trace OpenTelemetry associé à cette exécution (peut être vide ou avoir une valeur nulle).
      |





















































    Événement NodeUpdated

    • Définition : l'événement NodeUpdated indique que l'état ou la sortie d'un ou plusieurs nœuds du flux a changé. Au cours d'une exécution, cet événement est généralement envoyé lorsque les nœuds commencent à s'exécuter (Running) ou terminent leur exécution (Completed/Failed). Si response_config est défini, cet événement peut également inclure les descriptions, les noms d'affichage et les sorties des nœuds. Remarque : si vous spécifiez exclude_nodes dans le response_config de la requête, les événements NodeUpdated pour ces nœuds ne seront pas renvoyés.

    • Exemple de charge utile :

      data: {"event": "NodeUpdated", "run_id": "8f92b1a6-4d69-422a-a080-50713e488b56", "timestamp": "2025-04-25T08:57:15.208601Z", "node_run_infos": [{"node_name": "custom_python", "node": "custom_python", "status": "Running", "error": null, "duration": 0.0, "description": null, "display_name": null, "output": null}]}
      data: {"event": "NodeUpdated", "run_id": "8f92b1a6-4d69-422a-a080-50713e488b56", "timestamp": "2025-04-25T08:57:15.209621Z", "node_run_infos": [{"node_name": "custom_python", "node": "custom_python", "status": "Completed", "error": null, "duration": 0.001246, "description": null, "display_name": null, "output": {"text": "echo:hello", "input_length": 2}}]}
    • Descriptions des champs :

      |
      **Field Name**
      |
      **Type**
      |
      **Description**
      | | --- | --- | --- | |
      event
      |
      string
      |
      Type d'événement, fixé à **NodeUpdated**.
      | |
      run_id
      |
      string
      |
      Identifiant unique de l'exécution actuelle.
      | |
      timestamp
      |
      string
      |
      Horodatage de l'occurrence de l'événement, conforme à la norme ISO 8601.
      | |
      node_run_infos
      |
      array[object]
      |
      Tableau contenant un ou plusieurs objets d'informations d'exécution de nœud. Chaque objet représente un nœud dont l'état ou la sortie a changé.
      | |
      ∟ node_name
      |
      string
      |
      (Dans node_run_infos) Nom du nœud (champ hérité, identique au champ `node`).
      | |
      ∟ node
      |
      string
      |
      (Dans node_run_infos) Nom du nœud.
      | |
      ∟ status
      |
      string
      |
      (Dans node_run_infos) État d'exécution actuel du nœud, tel que Running, Completed, Failed.
      | |
      ∟ error
      |
      object or null
      |
      (Dans node_run_infos) Si l'exécution du nœud échoue, contient un objet de message d'erreur ; sinon null.
      | |
      ∟ duration
      |
      float
      |
      (Dans node_run_infos) Temps consacré à l'exécution du nœud (en secondes). Pour l'état **Running**, cette valeur est généralement de 0,0.
      | |
      ∟ description
      |
      string or null
      |
      (Dans node_run_infos) Description du nœud. Inclus uniquement lorsque `response_config.include_node_description` est défini sur `true` dans la requête ; sinon `null`.
      | |
      ∟ display_name
      |
      string or null
      |
      (Dans node_run_infos) Nom d'affichage du nœud. Inclus uniquement lorsque `response_config.include_node_display_name` est défini sur `true` dans la requête ; sinon `null`.
      | |
      ∟ output
      |
      object or null
      |
      (Dans node_run_infos) Données de sortie du nœud. Inclus uniquement lorsque l'état du nœud est **Completed** et que `response_config.include_node_output` est défini sur `true` dans la requête ; sinon `null`.
      |













































































    Événement RunOutput

    • Définition : l'événement RunOutput indique que l'exécution a généré sa sortie finale. Il se produit généralement avant l'événement RunTerminated à la fin de l'exécution du flux.

    • Exemple de charge utile :

      data: {"event": "RunOutput", "run_id": "4c185c72-1bb0-4beb-a288-f7a73e37fc3b_llm_3ce063ad-bc9b-417d-9e68-08ce92c3db1b", "timestamp": "2025-04-30T11:55:24.745130Z", "outputs": {"answer": "What can"}, "output_metadata": {"answer": {"is_stream": true, "status": "Streaming"}}}
      
      data: {"event": "RunOutput", "run_id": "4c185c72-1bb0-4beb-a288-f7a73e37fc3b_llm_3ce063ad-bc9b-417d-9e68-08ce92c3db1b", "timestamp": "2025-04-30T11:55:24.829133Z", "outputs": {"answer": " I help you with?"}, "output_metadata": {"answer": {"is_stream": true, "status": "Streaming"}}}
      
      data: {"event": "RunOutput", "run_id": "4c185c72-1bb0-4beb-a288-f7a73e37fc3b_llm_3ce063ad-bc9b-417d-9e68-08ce92c3db1b", "timestamp": "2025-04-30T11:55:24.950055Z", "outputs": {"answer": ""}, "output_metadata": {"answer": {"is_stream": true, "status": "Streaming"}}}
      
      data: {"event": "RunOutput", "run_id": "4c185c72-1bb0-4beb-a288-f7a73e37fc3b_llm_3ce063ad-bc9b-417d-9e68-08ce92c3db1b", "timestamp": "2025-04-30T11:55:24.954983Z", "outputs": {}, "output_metadata": {"answer": {"is_stream": true, "status": "Finished"}}}
      
      data: {"event": "RunOutput", "run_id": "4c185c72-1bb0-4beb-a288-f7a73e37fc3b_python_oHG7_1c9fb0ac-0f45-4dbc-bf97-8e4175fd991c", "timestamp": "2025-04-30T11:55:24.957091Z", "outputs": {"python_output": "Hello: Hello! What can I help you with?"}, "output_metadata": {"python_output": {"is_stream": false, "status": "Finished"}}}
    • Descriptions des champs :

      |
      **Field Name**
      |
      **Type**
      |
      **Description**
      | | --- | --- | --- | |
      event
      |
      string
      |
      Type d'événement, fixé à **RunOutput**.
      | |
      run_id
      |
      string
      |
      Identifiant unique de l'exécution actuelle.
      | |
      timestamp
      |
      string
      |
      Horodatage de l'occurrence de l'événement, conforme à la norme ISO 8601.
      | |
      outputs
      |
      object
      |
      Dictionnaire contenant les résultats de sortie finaux du flux. Sa structure spécifique dépend des sorties définies lors de la conception du flux.
      | |
      output_metadata
      |
      object
      |
      Dictionnaire contenant les métadonnées de sortie du flux. Les clés sont les noms de sortie (correspondant aux clés dans `outputs`), et les valeurs sont des objets contenant les métadonnées pour cette sortie (telles que `is_stream` et `status`).
      |



































    Événement RunTerminated

    • Définition : l'événement RunTerminated marque la fin de l'exécution. Il est généralement envoyé en tant que dernier événement dans le flux SSE d'une exécution.

    • Exemple de charge utile :

      data: {"event": "RunTerminated", "run_id": "8f92b1a6-4d69-422a-a080-50713e488b56", "timestamp": "2025-04-25T08:57:15.212791Z", "flow_run_info": {"run_id": "8f92b1a6-4d69-422a-a080-50713e488b56", "status": "Completed", "error": null, "otel_trace_id": "0x00000000000000000000000000000000"}}
    • Descriptions des champs :

      |
      **Field Name**
      |
      **Type**
      |
      **Description**
      | | --- | --- | --- | |
      event
      |
      string
      |
      Type d'événement, fixé à **RunTerminate**.
      | |
      run_id
      |
      string
      |
      L'identifiant unique de l'exécution actuelle.
      | |
      timestamp
      |
      string
      |
      L'horodatage de l'occurrence, conforme à la norme ISO 8601.
      | |
      flow_run_info
      |
      object
      |
      Contient les informations d'état final de l'ensemble de l'exécution.
      | |
      ∟ run_id
      |
      string
      |
      L'identifiant unique de l'exécution (dans flow_run_info, identique au `run_id` externe).
      | |
      ∟ status
      |
      string
      |
      L'état final de l'exécution (dans flow_run_info), tel que Completed, Failed ou Canceled.
      | |
      ∟ error
      |
      object or null
      |
      (Dans flow_run_info) Si l'exécution a échoué, cela contient l'objet de message d'erreur ; sinon, c'est `null`.
      | |
      ∟ otel_trace_id
      |
      string
      |
      (Dans flow_run_info) L'ID de trace OpenTelemetry associé à cette exécution (peut être vide ou avoir une valeur nulle).
      |





















































Méthode d'appel compatible OpenAI

Les flux d'application de type chat déployés prennent en charge l'appel compatible OpenAI et peuvent être utilisés par des clients compatibles avec OpenAI.

Méthode basée sur l'API OpenAI

Cet exemple illustre les appels en streaming à l'aide de commandes curl. Voici des exemples de requêtes et de réponses :

Exemple de requête :

curl --location '<Endpoint>/v1/chat/completions' \
--header "Authorization: Bearer $DASHSCOPE_API_KEY" \
--header 'Content-Type: application/json' \
--data '{
    "model": "default",  
    "messages": [
        {
            "role": "system",
            "content": "You are a helpful assistant."
        },
        {
            "role": "user", 
            "content": "Who are you?"
        }
    ],
    "stream":true
}'

Le tableau suivant décrit les paramètres de requête.

|
**Parameter**
|
**Description**
| | --- | --- | |
--location '<Endpoint>/v1/chat/completions'
|
L'URL de destination de la requête. Remplacez `` par l'endpoint que vous avez obtenu à l'étape 1.
| |
--header "Authorization: Bearer $DASHSCOPE_API_KEY"
|
L'en-tête HTTP. Remplacez `$DASHSCOPE_API_KEY` par le token que vous avez obtenu à l'étape 1.
| |
"model": "default"
|
Le nom du modèle, qui est fixé à `default`.
| |
"stream":true
|
Indique si les informations renvoyées sont en **streaming**. **Remarque : le streaming n'est pris en charge que lorsqu'un nœud LLM est utilisé comme nœud de sortie du flux d'application (un nœud LLM est l'entrée directe du nœud final).**
|

Exemple de réponse :

data: {"choices":[{"delta":{"content":"","role":"assistant"},"index":0,"logprobs":null,"finish_reason":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: {"choices":[{"finish_reason":null,"delta":{"content":"I am"},"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: {"choices":[{"delta":{"content":"a large"},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: {"choices":[{"delta":{"content":"language model"},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: {"choices":[{"delta":{"content":"created by Alibaba Cloud"},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: {"choices":[{"delta":{"content":". I am called Qwen."},"finish_reason":null,"index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: {"choices":[{"delta":{"content":""},"finish_reason":"stop","index":0,"logprobs":null}],"object":"chat.completion.chunk","usage":null,"created":1715931028,"system_fingerprint":null,"model":"qwen-plus","id":"chatcmpl-3bb05cf5cd819fbca5f0b8d67a025022"}

data: [DONE]




















Intégration avec d'autres clients

Cet exemple illustre l'intégration avec ChatBox v1.13.4 sur la plateforme Windows.

  1. Téléchargez et installez Chatbox.

  2. Ouvrez ChatBox et configurez le nom du fournisseur de modèle, par exemple LangStudio, comme suit.

    image

  3. Sélectionnez le fournisseur de modèle configuré et définissez les paramètres de requête de service.

    image

    Le tableau suivant décrit les paramètres clés.

    |
    **Parameter**
    |
    **Description**
    | | --- | --- | |
    API Mode
    |
    Fixé à `OpenAI API Compatible`.
    | |
    API Key
    |
    Définissez-le sur le token du service déployé, consultez la section Obtenir l'endpoint et le token dans l'onglet Overview.
    | |
    API Host
    |
    Définissez-le sur l'endpoint du service déployé (voir Obtenir l'endpoint et le token dans l'onglet Overview.) et ajoutez le suffixe `/v1` à la fin. Cet exemple utilise un endpoint Internet. Par conséquent, l'hôte API est `http://langstudio-20250319153409-xdcp.115770327099****.cn-hangzhou.pai-eas.aliyuncs.com/v1`.
    | |
    API Path
    |
    Fixé à `/chat/completions`.
    | |
    Model
    |
    Cliquez sur **New** et saisissez un **Model ID** personnalisé, par exemple qwen3-8b.
    |























  4. Appelez le service déployé dans la boîte de dialogue de chat.

    image

Afficher les enregistrements de trace

Après avoir appelé un service, le système génère automatiquement un enregistrement de trace. Dans l'onglet New, recherchez l'enregistrement de trace que vous souhaitez gérer et cliquez sur Model ID dans la colonne Tracing Analysis.

image

Les données de trace vous permettent d'afficher les informations d'entrée et de sortie de chaque nœud du flux d'application, telles que les résultats de rappel de la base de données vectorielle ou les informations d'entrée et de sortie du nœud LLM.

Annexe : Historique des chats

Pour les flux d'application basés sur le chat, LangStudio propose une fonctionnalité permettant de stocker l'historique des conversations multitudes. Vous pouvez choisir d'utiliser un stockage local ou externe pour enregistrer l'historique des chats.

Types de stockage

  • Stockage local : le service utilise le disque local pour créer automatiquement une base de données SQLite nommée chat_history.db sur l'instance EAS où le flux d'application est déployé, afin d'enregistrer l'historique des chats. Le chemin de stockage par défaut est /langstudio/flow/ . Notez que le stockage local ne prend pas en charge le déploiement multi-instances. Vérifiez régulièrement l'utilisation du disque local. Vous pouvez également afficher ou supprimer l'historique des chats à l'aide de l'API fournie ci-dessous. Si une instance EAS est supprimée, l'historique des chats associé est également effacé.

  • Stockage externe : prend en charge ApsaraDB RDS for MySQL. Pour utiliser le stockage externe, vous devez configurer une connexion RDS MySQL pour stocker l'historique des chats lors du déploiement d'un service. Pour plus d'informations, consultez la rubrique Configuration de la connexion au service - Base de données. Le service crée automatiquement des tables suffixées par le nom du service dans la base de données RDS MySQL que vous avez configurée. Par exemple, le service crée la table langstudio_chat_session_<Nom du service> pour stocker la session de chat et la table langstudio_chat_history_<Nom du service> pour stocker l'historique des chats.

Prise en charge des sessions ou des utilisateurs

Chaque requête de chat adressée à un flux d'application est sans état. Si vous souhaitez que plusieurs requêtes soient traitées comme faisant partie de la même conversation, vous devez configurer manuellement l'en-tête de requête. Pour savoir comment effectuer des appels, consultez la section Effectuer des appels API.

|
**Request header**
|
**Data type**
|
**Description**
|
**Note**
| | --- | --- | --- | --- | |
Chat-Session-Id
|
String
|
L'ID de session. Pour chaque requête de service, le système attribue automatiquement un identifiant unique à la session pour distinguer les différentes sessions, et le renvoie via le champ `Chat-Session-Id` dans l'en-tête de réponse.
|
Les IDs de session personnalisés sont pris en charge. Pour garantir l'unicité, un ID de session doit comporter entre 32 et 255 caractères et peut contenir des lettres, des chiffres, des traits de soulignement (_), des tirets (-) et des deux-points (:).
| |
Chat-User-Id
|
String
|
L'ID utilisateur, qui identifie l'utilisateur auquel appartient le chat. Le système n'attribue pas automatiquement d'ID utilisateur. Les IDs utilisateur personnalisés sont pris en charge.
|
-
|

API d'historique des chats

Le service de flux d'application fournit également des opérations API de gestion des données d'historique des chats, qui vous permettent d'afficher et de supprimer facilement ces données. Vous pouvez obtenir le schéma API complet en envoyant une requête GET à {Endpoint}/openapi.json. Ce schéma est construit selon la norme Swagger. Pour une compréhension et une exploration plus intuitives de ces opérations API, nous vous recommandons d'utiliser Swagger UI pour effectuer des opérations de visualisation, rendant les actions plus simples et plus claires.