# Jak przetestować strumieniowanie i wywołania narzędzi przed zmianą API LLM? > Testuj migrację API LLM za pomocą zapisanych przypadków kontraktowych, a nie demonstracji czatu. Przed wysłaniem prawdziwej pracy sprawdź strumień tekstu, wymuszone narzędzie, fragmenty argumentów, wiele wywołań, kontynuację po wyniku, anulowanie, błędy i dane użycia. Dziesięciominutowy test czatu może pominąć ważne problemy: zdublowane wywołania po ponowieniu, JSON wykonany przed zdarzeniem końcowym, wynik zwrócony z błędną rolą albo anulowanie pozostawiające aktywny zapis. Dobra bramka migracji przepuszcza stałe żądania przez rzeczywisty parser i wykonawcę, a potem ocenia niezmienniki strukturalne. Pierwszy zestaw powinien być mały, deterministyczny i porównywalny między modelami. Nie mierzy inteligencji; dowodzi, że nowe API może bezpiecznie sterować istniejącą pętlą. ## Zdefiniuj wymagany kontrakt Opisz dokładne zachowanie potrzebne klientowi przed testem dostawcy. Unikaj ogólnych etykiet, takich jak „zgodny z OpenAI”. | Obszar | Wymagany niezmiennik | Dowód do zachowania | |---|---|---| | Uwierzytelnianie | Oczekiwany endpoint przyjmuje klucz | Status i ID żądania | | Strumień tekstu | Delty tworzą jedną końcową wiadomość | Uporządkowane surowe zdarzenia | | Strumień narzędzia | Wywołanie kończy się przed wykonaniem | Bufor i zdarzenie końcowe | | Korelacja | Wynik trafia do właściwego wywołania | Mapa ID | | Ponowienie | Każde wywołanie działa najwyżej raz | Log idempotencji | | Użycie | Liczniki istnieją lub są oznaczone jako niedostępne | Metadane końcowe | Obsługa zależy od modelu. Atlas Cloud oferuje wiele formatów, więc przed wyborem trasy sprawdź aktualną dokumentację [`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). ## Utwórz cztery deterministyczne narzędzia Użyj przypadków pokazujących różne błędy: * `echo_json`: zwraca zwalidowane argumenty bez zmian. * `read_fixture`: odczytuje znany plik z piaskownicy. * `delayed_value`: kończy po kontrolowanym opóźnieniu. * `always_error`: zwraca stabilny ustrukturyzowany błąd. Stosuj ścisłe schematy z `additionalProperties: false` oraz unikalnym ID do wykrywania duplikatów. Żaden przypadek nie powinien zależeć od pogody, wyszukiwania lub zmiennego repozytorium. ## Uruchom macierz etapami Testuj bez strumienia przed strumieniem i jedno wywołanie przed wieloma. | Etap | Zachowanie | Warunek zaliczenia | |---|---|---| | A | Zwraca tekst | Przychodzi tekst końcowy i status | | B | Wymusza `echo_json` | Przychodzą nazwa i poprawne argumenty | | C | Strumieniuje `echo_json` | Fragmenty składają się raz | | D | Wywołuje dwa odczyty | Oba wyniki są poprawnie powiązane | | E | Otrzymuje błąd | Model naprawia lub czysto kończy | | F | Anuluje w trakcie | Brak spóźnionego wykonania | Zachowaj ten sam schemat i sens dla wszystkich kandydatów. Jeśli natywny protokół wymaga innej otoczki, dostosuj tylko reprezentację sieciową. ## Rejestruj zdarzenia poniżej SDK Obiekty wysokiego poziomu są wygodne, lecz mogą ukrywać różnice. Dodaj transport diagnostyczny, który zapisuje każde zdarzenie z numerem, ID odpowiedzi, indeksem wyjścia, ID wywołania, typem i długością ukrytego ładunku. Argumenty strumieniowe są przyrostowe. Składaj je według wywołania i czekaj na zdarzenie końcowe. Taka maszyna stanów jest bezpieczniejsza niż analizowanie każdego fragmentu: ```text START -> CALL_OPEN -> ARGUMENT_DELTAS -> CALL_DONE -> VALIDATED -> EXECUTED | | +-> CANCELLED <---+ ``` Odrzucaj przejścia wstecz i podwójne wykonania. Jeśli połączenie zerwie się po `EXECUTED`, ale przed dostarczeniem wyniku, użyj klucza idempotencji zamiast powtarzać zapis. ## Testuj pełny obieg wyniku Poprawne wywołanie to tylko połowa kontraktu. Zwróć wynik w oczekiwanym typie wiadomości i wymagaj odpowiedzi końcowej wykorzystującej znane pole. Testuj duże i puste wyniki, Unicode oraz błędy strukturalne. Ogranicz rozmiar przed ponownym wprowadzeniem do kontekstu; migracja może wyglądać dobrze, dopóki narzędzie nie przekroczy założenia adaptera. ## Porównuj niezmienniki, nie styl Nie odrzucaj testu, bo modele piszą inaczej. Sprawdzaj cechy obserwowalne: * Wybrano oczekiwane narzędzie. * Argumenty przeszły JSON Schema. * Wszystkie ID były unikalne i powiązane. * Każde narzędzie wykonało się zero lub jeden raz. * Pętla zakończyła się w budżecie. * Odpowiedź końcowa użyła wyniku testu. Migawki zależne od kandydata zachowuj tylko do diagnostyki, a kryteria utrzymuj neutralne. ## Dodaj błędy i anulowanie Rozłącz strumień po pierwszym fragmencie, po zakończeniu wywołania i po wykonaniu. Wstrzyknij 429, timeout, błędny JSON i nieznaną nazwę. Sprawdź, czy klient bezpiecznie ponawia, wznawia lub zatrzymuje się z użytecznym błędem. Najgroźniejsze jest niejednoznaczne ponowienie powtarzające operację ze skutkiem. Wymagaj idempotencji dla zapisów i odrzuć test, jeśli tożsamość wykonania jest nieznana. ## Użyj zestawu jako bramki wydania Zachowaj szybki test dla każdej zmiany konfiguracji i pełną macierz dla aktualizacji SDK lub gatewaya. Zapisuj model, protokół, adres bazowy, hash schematu, tryb strumienia, wersję klienta i czas. Atlas Cloud obsługuje żądania ze strumieniem i bez oraz pozwala badać kandydatów w [katalogu modeli](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). Uruchamiaj tę samą bramkę dla każdego modelu, bo wspólny dostęp nie oznacza identycznych możliwości. ## Podsumowanie Testuj migrację LLM jak zmianę protokołu ze stanem. Używaj deterministycznych narzędzi, zapisuj surowe zdarzenia, składaj argumenty dopiero na końcu, sprawdzaj pełny obieg i wstrzykuj ponowienia oraz anulowania. Włącz nowy model po przejściu kontraktu, a nie po jednym dobrym czacie. ## FAQ ### Co powinien obejmować pierwszy test zgodności? Zacznij od żądania tekstowego bez strumienia i wymuszonego wywołania tylko do odczytu. Izolują problemy endpointu, uwierzytelniania, schematu i formatu odpowiedzi. ### Dlaczego zapisywać surowe zdarzenia strumieniowe? Warstwa SDK może ukrywać kolejność i różnice pól. Surowe zdarzenia pokazują, jak naprawdę przychodzą ID, fragmenty, znaczniki końca, błędy i użycie. ### Czy można porównywać dostawców po identycznym tekście? Zwykle nie. Porównuj niezmienniki strukturalne: poprawne wywołania, wymagane pola, liczbę wykonań, stan końcowy i wynik zadania. ### Jak testować błędne argumenty narzędzia? Zwróć ustrukturyzowany błąd walidacji i sprawdź, czy pętla naprawi go lub zakończy się w określonym budżecie bez wykonania niebezpiecznych danych. ### Czy zestaw powinien używać narzędzi zapisujących? Zacznij od deterministycznych narzędzi tylko do odczytu. Dodaj izolowany zapis dopiero po przejściu składania, walidacji, deduplikacji i odzyskiwania. ### Jak często uruchamiać te testy? Uruchamiaj mały podzbiór przed każdą zmianą modelu lub protokołu, a pełny zestaw po zmianach SDK, schematów, gatewaya lub parsera.