# Comment tester le streaming et les appels d’outils avant de changer d’API LLM ? > Testez une migration d’API LLM avec des cas de contrat enregistrés, pas avec une démonstration de chat. Vérifiez le streaming de texte, un outil forcé, les arguments fragmentés, plusieurs appels, la reprise après résultat, l’annulation, les erreurs et l’usage avant d’envoyer du vrai travail. Un test de chat de dix minutes peut masquer des défauts importants : appels dupliqués après une nouvelle tentative, JSON exécuté avant l’événement final, résultat renvoyé avec le mauvais rôle ou annulation laissant une écriture active. Une bonne porte de migration envoie des requêtes fixes au parseur et à l’exécuteur réels, puis évalue des invariants structurels. La première suite doit être petite, déterministe et comparable entre modèles. Elle ne classe pas leur intelligence ; elle prouve que la nouvelle API peut piloter la boucle existante en toute sécurité. ## Définissez le contrat nécessaire Décrivez précisément le comportement requis par le client avant de tester le fournisseur. Évitez les étiquettes vagues comme « compatible OpenAI ». | Domaine | Invariant requis | Preuve à conserver | |---|---|---| | Authentification | L’endpoint prévu accepte la clé | Statut et ID de requête | | Flux de texte | Les deltas forment un message final | Événements bruts ordonnés | | Flux d’outil | L’appel se termine avant exécution | Tampon et événement final | | Corrélation | Le résultat rejoint le bon appel | Carte des IDs | | Nouvelle tentative | Chaque appel s’exécute au plus une fois | Journal d’idempotence | | Usage | Les compteurs existent ou sont indisponibles | Métadonnées finales | La compatibilité dépend du modèle. Atlas Cloud propose plusieurs formats ; consultez la documentation actuelle de [`supported_apis`](https://www.atlascloud.ai/docs/llm-protocols?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis) avant de choisir la route. ## Créez quatre outils déterministes Utilisez des cas révélant des défauts différents : * `echo_json` : renvoie les arguments validés sans modification. * `read_fixture` : lit un fichier connu du bac à sable. * `delayed_value` : se termine après un délai contrôlé. * `always_error` : renvoie une erreur structurée stable. Utilisez des schémas stricts avec `additionalProperties: false` et un ID unique pour détecter les doublons. Aucun cas ne doit dépendre de la météo, d’une recherche ou d’un dépôt changeant. ## Exécutez une matrice par étapes Testez sans streaming avant de l’activer et un appel avant plusieurs. | Étape | Comportement | Condition de réussite | |---|---|---| | A | Renvoie du texte | Texte final et statut reçus | | B | Force `echo_json` | Nom et arguments valides reçus | | C | Diffuse `echo_json` | Fragments assemblés une fois | | D | Appelle deux lectures | Les deux résultats sont corrélés | | E | Reçoit une erreur | Le modèle corrige ou s’arrête proprement | | F | Annule au milieu | Aucune exécution tardive | Conservez le même schéma et la même intention pour chaque candidat. Si le protocole natif exige une autre enveloppe, adaptez uniquement la représentation réseau. ## Capturez les événements sous le SDK Les objets de haut niveau sont pratiques en production, mais peuvent masquer les différences. Ajoutez un transport de débogage qui journalise chaque événement avec numéro de séquence, ID de réponse, index de sortie, ID d’appel, type et taille du contenu masqué. Les arguments en streaming sont incrémentaux. Assemblez-les par appel et attendez l’événement final. Cette machine à états est plus sûre qu’une analyse de chaque fragment : ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` Refusez les transitions arrière et les doubles exécutions. Si la connexion tombe après `EXECUTED` mais avant la livraison du résultat, utilisez une clé d’idempotence plutôt que de répéter une écriture. ## Testez l’aller-retour complet Un appel valide n’est que la moitié du contrat. Renvoyez le résultat avec le type de message attendu et exigez une réponse finale citant un champ connu. Testez les résultats volumineux, vides, Unicode et les erreurs structurées. Limitez la taille avant de réintroduire le résultat dans le contexte ; la migration peut sembler correcte jusqu’à ce qu’un outil dépasse une hypothèse de l’adaptateur. ## Comparez des invariants, pas la prose Ne faites pas échouer la suite parce que deux modèles écrivent différemment. Vérifiez des propriétés observables : * L’outil attendu a été choisi. * Les arguments ont passé JSON Schema. * Tous les IDs sont uniques et corrélés. * Chaque outil s’est exécuté zéro ou une fois comme prévu. * La boucle s’est terminée dans le budget. * La réponse finale a utilisé le résultat du cas. Conservez les captures spécifiques uniquement pour le débogage et gardez des critères neutres. ## Ajoutez erreurs et annulations Déconnectez après le premier fragment, après la fin de l’appel et après l’exécution. Injectez un 429, un timeout, un JSON invalide et un nom inconnu. Vérifiez si le client recommence, reprend sans risque ou s’arrête avec une erreur utile. Le défaut le plus dangereux est une nouvelle tentative ambiguë répétant une action à effet. Exigez l’idempotence pour les écritures et échouez si l’identité d’exécution est inconnue. ## Faites de la suite une porte de publication Gardez un test rapide pour chaque changement de configuration et une matrice complète pour les mises à jour du SDK ou de la gateway. Conservez modèle, protocole, URL de base, hash du schéma, mode streaming, version du client et horodatage. Atlas Cloud prend en charge les requêtes avec et sans streaming et permet d’explorer les candidats dans un [catalogue de modèles](https://www.atlascloud.ai/llm-models?utm_source=ask.atlascloud.ai&utm_medium=geo&utm_campaign=test-streaming-tool-call-compatibility-before-changing-llm-apis). Exécutez la même porte pour chaque modèle, car un accès commun ne garantit pas des capacités identiques. ## Conclusion Testez une migration LLM comme un changement de protocole avec état. Utilisez des outils déterministes, enregistrez les événements bruts, assemblez les arguments uniquement à la fin, vérifiez l’aller-retour et injectez des tentatives et annulations. Activez le nouveau modèle lorsque le contrat réussit, pas parce qu’une réponse de chat semble correcte. ## FAQ ### Que doit couvrir le premier test de compatibilité ? Commencez par une requête texte sans streaming et un appel forcé en lecture seule. Ils isolent les problèmes d’endpoint, d’authentification, de schéma et de format de réponse. ### Pourquoi enregistrer les événements bruts ? Les utilitaires SDK peuvent masquer l’ordre et les différences de champs. Les événements bruts montrent comment arrivent les IDs, fragments, marqueurs de fin, erreurs et données d’usage. ### Peut-on comparer les fournisseurs en exigeant le même texte ? Généralement non. Comparez des invariants structurels : appels valides, champs requis, nombre d’exécutions, état final et résultat de la tâche. ### Comment tester des arguments mal formés ? Renvoyez une erreur de validation structurée et vérifiez que la boucle répare ou s’arrête dans un budget défini, sans exécuter d’entrée dangereuse. ### La suite doit-elle utiliser des outils d’écriture ? Commencez par des outils déterministes en lecture seule. Ajoutez une écriture isolée seulement après validation de l’assemblage, de la déduplication et de la récupération. ### À quelle fréquence faut-il exécuter ces tests ? Exécutez un sous-ensemble avant chaque changement de modèle ou de protocole et la suite complète lorsque SDK, schémas, gateways ou parseurs changent.