# Come testare streaming e chiamate agli strumenti prima di cambiare API LLM? > Testa una migrazione API LLM con casi di contratto registrati, non con una demo di chat. Verifica testo in streaming, uno strumento forzato, argomenti frammentati, chiamate multiple, continuazione dopo il risultato, annullamento, errori e conteggio dell’uso prima di inviare lavoro reale. Un test di chat di dieci minuti può nascondere problemi importanti: chiamate duplicate dopo un nuovo tentativo, JSON eseguito prima dell’evento finale, risultato restituito con il ruolo sbagliato o annullamento che lascia attiva una scrittura. Una buona porta di migrazione invia richieste fisse attraverso parser ed esecutore reali e valuta invarianti strutturali. La prima suite deve essere piccola, deterministica e confrontabile tra modelli. Non classifica l’intelligenza; dimostra che la nuova API può guidare in sicurezza il loop esistente. ## Definisci il contratto necessario Descrivi il comportamento esatto richiesto dal client prima di testare il provider. Evita etichette vaghe come “compatibile con OpenAI”. | Area | Invariante richiesto | Prova da conservare | |---|---|---| | Autenticazione | L’endpoint previsto accetta la chiave | Stato e ID richiesta | | Flusso testuale | I delta formano un messaggio finale | Eventi grezzi ordinati | | Flusso strumento | La chiamata termina prima dell’esecuzione | Buffer ed evento finale | | Correlazione | Il risultato torna alla chiamata corretta | Mappa degli ID | | Nuovo tentativo | Ogni chiamata viene eseguita al massimo una volta | Log di idempotenza | | Utilizzo | I contatori esistono o sono indicati come non disponibili | Metadati finali | Il supporto dipende dal modello. Atlas Cloud offre più formati, quindi consulta la guida attuale di [`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) prima di scegliere la rotta. ## Crea quattro strumenti deterministici Usa casi che mostrino errori diversi: * `echo_json`: restituisce invariati gli argomenti convalidati. * `read_fixture`: legge un file noto dalla sandbox. * `delayed_value`: termina dopo un ritardo controllato. * `always_error`: restituisce un errore strutturato stabile. Usa schemi rigorosi con `additionalProperties: false` e un ID univoco per rilevare duplicati. Nessun caso deve dipendere da meteo, ricerca o repository variabile. ## Esegui una matrice per fasi Prova senza streaming prima di abilitarlo e una chiamata prima di più chiamate. | Fase | Comportamento | Condizione di superamento | |---|---|---| | A | Restituisce testo | Arrivano testo finale e stato | | B | Forza `echo_json` | Arrivano nome e argomenti validi | | C | Trasmette `echo_json` | I frammenti vengono assemblati una volta | | D | Chiama due letture | Entrambi i risultati sono correlati | | E | Riceve un errore | Il modello corregge o termina bene | | F | Annulla a metà flusso | Nessuna esecuzione tardiva | Mantieni schema e intento uguali per tutti i candidati. Se il protocollo nativo richiede un altro involucro, adatta solo la rappresentazione di rete. ## Cattura gli eventi sotto l’SDK Gli oggetti di alto livello sono comodi, ma possono nascondere le differenze. Aggiungi un trasporto di debug che registri ogni evento con sequenza, ID risposta, indice output, ID chiamata, tipo e lunghezza del contenuto oscurato. Gli argomenti in streaming sono incrementali. Assemblali per chiamata e attendi l’evento finale. Questa macchina a stati è più sicura dell’analisi di ogni frammento: ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` Rifiuta transizioni all’indietro e doppie esecuzioni. Se la connessione cade dopo `EXECUTED` ma prima della consegna del risultato, usa una chiave di idempotenza invece di ripetere una scrittura. ## Testa l’andata e ritorno completo Una chiamata valida è solo metà del contratto. Restituisci il risultato nel tipo di messaggio atteso e richiedi una risposta finale che citi un campo noto. Prova risultati grandi, vuoti, Unicode ed errori strutturati. Limita la dimensione prima di reinserire il risultato nel contesto; la migrazione può sembrare corretta finché uno strumento non supera un’ipotesi dell’adattatore. ## Confronta invarianti, non la prosa Non bocciare la suite perché due modelli scrivono in modo diverso. Verifica proprietà osservabili: * È stato scelto lo strumento previsto. * Gli argomenti hanno superato JSON Schema. * Tutti gli ID erano univoci e correlati. * Ogni strumento è stato eseguito zero o una volta come previsto. * Il loop è terminato entro il budget. * La risposta finale ha usato il risultato del caso. Conserva snapshot specifici solo per il debug e mantieni criteri neutrali. ## Aggiungi errori e annullamenti Disconnetti dopo il primo frammento, dopo il completamento e dopo l’esecuzione. Inietta 429, timeout, JSON non valido e un nome sconosciuto. Controlla se il client ritenta, riprende in sicurezza o termina con un errore utile. Il difetto più pericoloso è un nuovo tentativo ambiguo che ripete un’azione con effetti. Richiedi idempotenza per le scritture e fallisci se l’identità di esecuzione è ignota. ## Usa la suite come porta di rilascio Mantieni un test rapido per ogni cambio di configurazione e una matrice completa per aggiornamenti SDK o gateway. Conserva modello, protocollo, URL base, hash schema, modalità streaming, versione client e orario. Atlas Cloud supporta richieste con e senza streaming e permette di esplorare candidati in un [catalogo di modelli](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). Esegui la stessa porta per ogni modello: l’accesso comune non implica capacità identiche. ## Conclusione Testa una migrazione LLM come cambio di protocollo con stato. Usa strumenti deterministici, registra eventi grezzi, assembla gli argomenti solo alla fine, verifica l’andata e ritorno e inietta tentativi e annullamenti. Promuovi il nuovo modello quando il contratto supera i test, non perché una risposta di chat sembra buona. ## FAQ ### Cosa deve coprire il primo test di compatibilità? Inizia con una richiesta testuale senza streaming e una chiamata forzata in sola lettura. Isolano problemi di endpoint, autenticazione, schema e formato base della risposta. ### Perché registrare gli eventi grezzi di streaming? Gli helper SDK possono nascondere ordine e differenze dei campi. Gli eventi grezzi mostrano come arrivano ID, frammenti, marcatori finali, errori e utilizzo. ### Posso confrontare i provider richiedendo lo stesso testo? In genere no. Confronta invarianti strutturali: chiamate valide, campi obbligatori, numero di esecuzioni, stato finale e risultato dell’attività. ### Come testare argomenti malformati? Restituisci un errore di convalida strutturato e verifica che il loop corregga o termini entro un budget definito, senza eseguire input non sicuri. ### La suite deve usare strumenti di scrittura? Inizia con strumenti deterministici in sola lettura. Aggiungi una scrittura isolata solo dopo che assemblaggio, convalida, deduplicazione e recupero sono riusciti. ### Quanto spesso vanno eseguiti i test? Esegui un sottoinsieme prima di ogni cambio di modello o protocollo e la suite completa quando cambiano SDK, schemi, gateway o parser.