Przerwana odpowiedź AI: odbiór wyniku przy transmisji strumieniowej

Na ekranie pojawia się zdanie: „Zamówienie można zatwierdzić”. Użytkownik już przesuwa kursor, gdy połączenie się urywa. Nie doczytał dalszej części, która mogła brzmieć: „dopiero po sprawdzeniu dostępności”. Kropka dopisana przez aplikację byłaby w tej sytuacji zaskakująco samodzielnym pracownikiem.

Transmisja strumieniowa pozwala pokazywać odpowiedź AI kawałkami, zanim powstanie całość. Użytkownik może zacząć czytać, zanim powstanie pełna odpowiedź. Otwiera też ważną granicę odbioru: fragment, który da się przeczytać, nie musi być wynikiem, którego wolno już użyć. Właściciel procesu powinien umieć wskazać, kiedy podgląd staje się gotowym materiałem oraz kto podejmuje następną decyzję.

Przyjrzyjmy się fikcyjnemu asystentowi pracowni przygotowującej wyposażenie wydarzeń. Narzędzie czyta opis zapytania i proponuje listę spraw do wyjaśnienia z klientem. Pracownik widzi powstającą odpowiedź. Docelowo ma skopiować kompletną listę do rekordu sprawy; asystent nie wysyła wiadomości ani nie zmienia zamówienia. Nawet przy tak ograniczonym zadaniu potrzebujemy więcej niż migającego kursora.

Który koniec oznacza gotowy wynik?

W dokumentacji strumieniowania OpenAI przyrosty tekstu i zdarzenie zakończenia odpowiedzi są odrębnymi zdarzeniami. Odbiorca może więc zobaczyć część treści przed zakończeniem jej tworzenia. To kontrakt konkretnego API; nazwy zdarzeń należy sprawdzić dla faktycznie używanej integracji.

Przy odbiorze rozdziel trzy rzeczy. Pierwsza to transport: aplikacja dostaje dane. Druga to zakończenie generowania z określonym statusem. Trzecia to przyjęcie wyniku do pracy po sprawdzeniu wymagań zadania. Te momenty mogą następować blisko siebie, lecz nie zastępują się wzajemnie. Zakończony tekst nadal może pomijać pozycję zamówienia. Z kolei poprawny początek listy nie potwierdza zakończenia odpowiedzi.

Referencja zdarzeń Responses API osobno opisuje response.completed, response.failed i response.incomplete. Ostatni status obejmuje między innymi przykład zatrzymania przez limit wyjścia. Samo ustanie dopływu znaków nie wystarcza zatem do przypisania sukcesu.

W pracowni przyjmijmy prostą regułę: do chwili potwierdzenia kompletności pracownik widzi „Powstaje szkic”. Po potwierdzonym zakończeniu generowania pojawia się „Lista gotowa do sprawdzenia”. Dopiero świadoma decyzja pracownika zapisuje ją przy sprawie. Etykiety opisują faktyczne etapy, a nie kolejne odcienie tej samej obietnicy.

Ustal również, czy wynik składa się z jednego tekstu, kilku części czy tekstu z wywołaniem narzędzia. Zakończenie jednej części nie powinno zatwierdzać całego zadania. W dokumentacji strumieniowania Claude blok zawartości ma własne zdarzenia początku, przyrostów i końca; całą wiadomość zamyka osobne message_stop. Opisano także błędy przesyłane wewnątrz strumienia.

Dlatego w karcie odbioru zapisz nie tylko nazwę sygnału końca, ale też zakres, który on zamyka. To może być koniec bloku tekstowego albo całej odpowiedzi. Osoba znająca integrację powinna przełożyć tę informację na zachowanie ekranu i zapisu. Nie trzeba uczyć całego zespołu składni zdarzeń, żeby uzgodnić sens napisu „gotowe”.

Co wolno zrobić z widocznym fragmentem?

Podgląd pomaga wcześniej zorientować się w kierunku odpowiedzi. Pracownik może zauważyć, że asystent analizuje niewłaściwą sprawę, i przerwać zadanie. Nie wynika z tego, że każdą widoczną pozycję należy natychmiast dopisywać do oficjalnej listy. W naszym przykładzie ta lista powinna być odbierana jako całość.

Przed demonstracją rozpisz dozwolone działania. Czy można zaznaczać tekst? Czy działa przycisk kopiowania? Czy fragment trafia do historii jako szkic? Czy eksport pozostaje zablokowany? Jeżeli kopiowanie jest możliwe w trakcie tworzenia, oznaczenie niepełności powinno pozostać zrozumiałe także poza ekranem. Sama szara etykieta znikająca przy wklejeniu słabo chroni przed potraktowaniem szkicu jako gotowego materiału.

Inaczej potraktujesz robocze notatki, inaczej dane uruchamiające operację. Przy kontroli znaczenia danych w poprawnym JSON sprawdzasz gotowy rekord. Tutaj trzeba najpierw ustalić, czy w ogóle odebrano cały rekord. Próba odczytania fragmentu może kończyć się błędem albo przypadkowym przyjęciem części, która akurat ma poprawną składnię.

Przygotuj dwie podobne sprawy i nadaj im różne identyfikatory prób. Rozpocznij odpowiedź dla pierwszej, przejdź do drugiej i pozwól dotrzeć spóźnionemu fragmentowi. Oczekiwaniem jest zachowanie związku danych z pierwotnym zadaniem. Tekst nie powinien dopisywać się do aktualnie otwartego rekordu tylko dlatego, że ten ma teraz aktywne okno.

To rozróżnienie rozwija powiązanie wyniku wsadowego z rekordem. W strumieniu dochodzi wiele małych fragmentów tego samego wykonania. Każdy potrzebuje rozpoznawalnego miejsca w obrębie właściwej próby. Przełączenie widoku jest działaniem użytkownika, a nie dowodem, że wcześniejsza odpowiedź zmieniła właściciela.

Nie dodawaj automatycznej publikacji kolejnych zdań tylko po to, by wykorzystać wrażenie szybkości. Najpierw wybierz jednostkę wyniku potrzebną procesowi. Jeżeli pojedyncza pozycja rzeczywiście może być odebrana osobno, musi mieć własne warunki kompletności i kontroli. Podział na linie widoczny na ekranie sam w sobie nie ustanawia takich warunków.

W próbie kopiowania zaznacz fragment, zanim dopłynie dalsza część odpowiedzi. Sprawdź, czy zaznaczenie pozostaje czytelne i czy pracownik wie, z jakiej wersji pochodzi skopiowany tekst. Rosnąca lista może zmienić układ pod kursorem, a nowe zdanie doprecyzować wcześniejszą pozycję. Odbiór powinien obejmować rzeczywistą czynność człowieka, nie wyłącznie bierne patrzenie na animację. Jeśli fragment nie nadaje się do użycia poza podglądem, wyjaśnij to przy dostępnym działaniu. Nie pozostawiaj tej zasady wyłącznie w instrukcji schowanej w ustawieniach.

Jak pokazać przerwanie bez dopowiadania sukcesu?

W kontrolowanej próbie zatrzymaj połączenie po nagłówku, w połowie pozycji i po ostatnim widocznym zdaniu, lecz przed potwierdzonym zakończeniem. Ten trzeci przypadek łatwo przeoczyć. Tekst wygląda naturalnie, więc ręczny ogląd może uznać go za gotowy. Aplikacja powinna jednak rozpoznać brak potwierdzenia, zamiast odgadywać stan na podstawie interpunkcji.

Rozdziel potwierdzony błąd od braku wiedzy o zakończeniu. Komunikat „Nie udało się odebrać całej odpowiedzi” pozostawia miejsce na sprawdzenie stanu, jeżeli używane rozwiązanie je umożliwia. Kategoryczne „Model nie wykonał zadania” może opisywać zbyt wiele. Przerwa mogła wystąpić między gotowym wynikiem a jego dostarczeniem do konkretnego ekranu.

MDN opisuje zachowanie EventSource, w tym domyślne ponawianie połączenia oraz pole identyfikatora zdarzenia. Nie oznacza to automatycznie odtworzenia całego wyniku AI w dowolnej integracji. Trzeba osobno sprawdzić zachowanie faktycznie zastosowanego klienta i serwera.

Pracownik powinien wiedzieć, co stanie się z widocznym szkicem. Można go zachować jako niepełny materiał do wglądu albo odrzucić według reguły procesu. Nie zamieniaj zachowanego fragmentu w gotową listę przez samo zamknięcie ostrzeżenia. Stan niepełności powinien pozostać przy treści aż do wyraźnego rozstrzygnięcia.

Uzgodnij, co oznacza cisza w trakcie odbioru. Zespół może ustalić moment pokazania informacji o dłuższym oczekiwaniu, ale nie powinien po upływie umownego czasu samodzielnie zatwierdzać odpowiedzi. W próbie rozdziel wolny dopływ fragmentów od zerwanego połączenia i od potwierdzonego zakończenia. Każdy przypadek może wyglądać podobnie przez kilka sekund. Czas ostatniej aktualizacji pomaga opisać obserwację, natomiast nie zastępuje statusu zadania. Osoba odpowiedzialna za integrację powinna ustalić, jakie sygnały da się rzeczywiście odczytać i co użytkownik może zrobić, gdy ich zabraknie.

Sprawdź także powrót po przeładowaniu strony. Czy użytkownik odzyskuje szkic, wynik czy wyłącznie informację o próbie? Czy rozpoznaje, którą sprawę obsługiwał? Podobną drogę od strony interfejsu omawiamy przy długim zadaniu, przerwaniu i powrocie. Tutaj dodatkowym warunkiem jest zachowanie granicy między częścią odpowiedzi a całością.

Odmowa wykonania i brak odpowiedzi także potrzebują rozpoznawalnego zakończenia. Nie uzupełniaj listy pustymi pozycjami, żeby formularz dało się zatwierdzić. Człowiek powinien zobaczyć, czy dostał materiał do pracy, komunikat wyjaśniający niewykonanie czy niepełny strumień. Te sytuacje prowadzą do różnych następnych kroków.

Czy ponowienie jest dalszym ciągiem tej samej pracy?

Przycisk „Spróbuj ponownie” powinien wyjaśniać swój skutek. Może rozpocząć nową odpowiedź z tym samym wejściem albo uruchomić udokumentowaną ścieżkę kontynuacji. Nie nazywaj nowej generacji odzyskaniem identycznego wyniku. Zmieniony kontekst, instrukcja lub sam przebieg wykonania mogą prowadzić do innego tekstu.

W pracowni zachowajmy niepełną próbę jako zamkniętą i oznaczoną. Nowa dostaje własny identyfikator oraz związek z poprzednią. Pracownik może porównać oba zapisy, ale oficjalna lista odwołuje się do jednej przyjętej wersji. Sklejanie końca nowej odpowiedzi z początkiem starej wymagałoby osobnej, jawnie sprawdzonej reguły.

Jeżeli narzędzie wykonuje już działania, sam restart odpowiedzi może nie wystarczyć. Granicę między tekstem a skutkiem rozwija częściowe wykonanie agenta w kilku systemach. Przerwanie transmisji nie dowodzi, że wcześniej zlecone operacje zostały cofnięte. W takiej sytuacji pierwszym krokiem jest odczyt potwierdzonych skutków.

Osobno zmierz oczekiwanie na pierwszy fragment i na pełny materiał. Szybko pojawiające się zdanie nie mówi, jak długo pracownik czeka na gotową listę. Ocena AI pod obciążeniem pomaga rozdzielić te czasy. Przy odbiorze strumienia interesuje nas dodatkowo, czy wcześniejszy podgląd realnie pomaga w pracy.

Zespół może woleć krótsze oczekiwanie na kompletną listę od długiej animacji jej powstawania. Może też korzystać z podglądu do wczesnego przerwania błędnego kierunku. Porównaj konkretne zadanie i możliwości użytkownika. Nie traktuj włączenia strumieniowania jako poprawy, której nie trzeba już sprawdzać.

Z czym zakończyć odbiór?

W Aeneia Audit punktem wyjścia może być jedna droga od zapytania do zapisanej listy. Do jej przejrzenia przygotuj opis używanej integracji, przykładowe niepoufne wejście i regułę przekazania wyniku dalej. Najważniejsza jest możliwość przypisania każdego widocznego stanu do konkretnego dowodu.

Zapis odbioru powinien wskazywać dla każdej próby wejście, identyfikator wykonania, ostatni potwierdzony etap, zachowany materiał i następne dozwolone działanie. Jeżeli nie ma podstawy do oznaczenia zakończenia, wpisz brak potwierdzenia. Pozornie bardziej stanowczy raport nie poprawi wiedzy o tym, co naprawdę się wydarzyło.

Przed oddaniem rozwiązania sprawdź pięć przebiegów: poprawną odpowiedź, przerwanie, potwierdzony błąd, spóźniony fragment po zmianie sprawy oraz nowe wykonanie po nieudanej próbie. Zachowaj obserwacje z kontrolowanego środowiska, zamiast deklarować wykonanie tych prób na podstawie samego planu. Dopiero rzeczywisty przebieg pozwala sprawdzić zgodność etykiet z działaniem.

Na koniec wróć do pierwszego zdania na ekranie. Czy użytkownik wie, że wciąż czyta szkic? Czy aplikacja umie zatrzymać dalsze użycie, kiedy zabraknie zakończenia? Dobrze odebrany strumień może wyglądać płynnie i przyjemnie. Ma też umieć uczciwie powiedzieć: to jeszcze nie całość.