# Hoe test je streaming en toolaanroepen voordat je van LLM-API wisselt? > Test een LLM-API-migratie met vastgelegde contractgevallen, niet met een chatdemo. Controleer tekststreaming, één geforceerde tool, gefragmenteerde argumenten, meerdere aanroepen, voortzetting na resultaten, annulering, fouten en gebruiksregistratie voordat je echt werk verstuurt. Een chattest van tien minuten kan belangrijke fouten missen: dubbele aanroepen na een retry, JSON dat vóór het finale event wordt uitgevoerd, een resultaat in de verkeerde rol of annulering terwijl een schrijfactie doorloopt. Een goede migratiepoort stuurt vaste requests door de echte parser en executor en beoordeelt structurele invarianten. De eerste suite moet klein, deterministisch en vergelijkbaar tussen modellen zijn. Ze rangschikt geen intelligentie, maar bewijst dat de nieuwe API de bestaande agentloop veilig kan aansturen. ## Definieer het vereiste contract Beschrijf exact welk gedrag de client nodig heeft voordat je de provider test. Vermijd vage labels zoals “OpenAI-compatibel”. | Gebied | Vereiste invariant | Te bewaren bewijs | |---|---|---| | Authenticatie | Verwachte endpoint accepteert de sleutel | Status en request-ID | | Tekststream | Delta’s vormen één finaal bericht | Geordende ruwe events | | Toolstream | Aanroep voltooit vóór uitvoering | Buffer en finaal event | | Correlatie | Resultaat hoort bij de juiste aanroep | ID-toewijzing | | Retry | Elke aanroep draait maximaal één keer | Idempotentielog | | Gebruik | Tellers bestaan of zijn niet beschikbaar | Finale metadata | Ondersteuning is modelspecifiek. Atlas Cloud biedt meerdere formaten; raadpleeg de actuele [`supported_apis`-gids](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) voordat je een route kiest. ## Maak vier deterministische tools Gebruik gevallen die verschillende fouten zichtbaar maken: * `echo_json`: geeft gevalideerde argumenten ongewijzigd terug. * `read_fixture`: leest één bekend bestand uit de sandbox. * `delayed_value`: eindigt na een gecontroleerde vertraging. * `always_error`: geeft een stabiele gestructureerde fout terug. Gebruik strikte schema’s met `additionalProperties: false` en een unieke ID om dubbele uitvoering te herkennen. Geen geval mag afhangen van weer, zoekresultaten of een veranderende repository. ## Voer een gefaseerde matrix uit Test zonder streaming vóór streaming en één aanroep vóór meerdere. | Fase | Gedrag | Slaagvoorwaarde | |---|---|---| | A | Geef tekst terug | Finale tekst en stopstatus komen aan | | B | Forceer `echo_json` | Naam en geldige argumenten komen aan | | C | Stream `echo_json` | Fragmenten worden één keer opgebouwd | | D | Roep twee leestools aan | Beide resultaten worden juist gekoppeld | | E | Ontvang één fout | Model herstelt of stopt schoon | | F | Annuleer halverwege | Geen late uitvoering | Houd schema en intentie gelijk voor alle kandidaten. Als het native protocol een andere envelop vereist, pas alleen de netwerkweergave aan. ## Leg events onder de SDK vast High-level objecten zijn handig, maar kunnen verschillen verbergen. Voeg een debugtransport toe dat elk event logt met volgnummer, response-ID, outputindex, call-ID, type en lengte van de afgeschermde payload. Streamingargumenten zijn incrementeel. Bouw ze per aanroep op en wacht op het finale event. Deze statusmachine is veiliger dan elk fragment analyseren: ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` Weiger terugwaartse overgangen en dubbele uitvoering. Valt de verbinding weg na `EXECUTED` maar vóór levering van het resultaat, gebruik dan een idempotentiesleutel in plaats van opnieuw te schrijven. ## Test de volledige terugkoppeling Een geldige aanroep is slechts de helft van het contract. Geef het resultaat terug in het verwachte berichttype en eis een finaal antwoord dat een bekend veld gebruikt. Test grote en lege resultaten, Unicode en gestructureerde fouten. Beperk de grootte vóór terugkeer naar de context; een migratie kan gezond lijken tot een tool een adapteraanname overschrijdt. ## Vergelijk invarianten, geen formuleringen Laat de suite niet falen omdat twee modellen anders schrijven. Controleer observeerbare eigenschappen: * De verwachte tool werd gekozen. * Argumenten slaagden voor JSON Schema. * Alle ID’s waren uniek en gekoppeld. * Elke tool draaide nul of één keer zoals bedoeld. * De loop eindigde binnen het budget. * Het finale antwoord gebruikte het testresultaat. Bewaar kandidaatspecifieke snapshots alleen voor debugging en houd criteria providerneutraal. ## Voeg fouten en annuleringen toe Verbreek de stream na het eerste fragment, na voltooiing en na uitvoering. Injecteer 429, timeout, ongeldige JSON en een onbekende toolnaam. Controleer of de client veilig retryt, hervat of stopt met een nuttige fout. Het gevaarlijkst is een dubbelzinnige retry die een schrijfactie herhaalt. Vereis expliciete idempotentie en laat de test falen wanneer de uitvoeringsidentiteit onbekend is. ## Gebruik de suite als releasepoort Behoud een snelle test voor elke configuratiewijziging en een volledige matrix voor SDK- of gateway-updates. Bewaar model, protocol, base URL, schemahash, streamingvlag, clientversie en tijdstip. Atlas Cloud ondersteunt requests met en zonder streaming en laat kandidaten verkennen in een [modelcatalogus](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). Voer dezelfde poort voor ieder model uit, want gedeelde toegang betekent geen identieke mogelijkheden. ## Conclusie Test een LLM-migratie als een statusdragende protocolwijziging. Gebruik deterministische tools, log ruwe events, bouw argumenten pas aan het einde op, controleer de terugkoppeling en injecteer retries en annuleringen. Promoveer het nieuwe model wanneer het contract slaagt, niet omdat één chatantwoord er goed uitziet. ## FAQ ### Wat moet de eerste compatibiliteitstest omvatten? Begin met een tekstrequest zonder streaming en één geforceerde alleen-lezen aanroep. Daarmee isoleer je endpoint-, authenticatie-, schema- en basisformatproblemen. ### Waarom ruwe streamingevents vastleggen? SDK-helpers kunnen volgorde en veldverschillen verbergen. Ruwe events tonen hoe ID’s, fragmenten, voltooiingsmarkeringen, fouten en gebruik werkelijk aankomen. ### Kan ik providers vergelijken op exact dezelfde tekst? Meestal niet. Vergelijk structurele invarianten zoals geldige aanroepen, verplichte velden, uitvoeringsaantal, eindstatus en taakresultaat. ### Hoe test ik ongeldige toolargumenten? Geef een gestructureerde validatiefout terug en controleer of de loop binnen een vast budget herstelt of stopt zonder onveilige invoer uit te voeren. ### Moet de suite schrijftools gebruiken? Begin met deterministische alleen-lezen tools. Voeg pas een geïsoleerde schrijfactie toe nadat opbouw, validatie, deduplicatie en herstel slagen. ### Hoe vaak moeten deze tests worden uitgevoerd? Voer een kleine set uit vóór elke model- of protocolwissel en de volledige suite wanneer SDK, schema, gateway of parser verandert.