langchain-core==1.7.5 Nadaje odmowom modeli standardowy format

LangChain wydał langchain-core==1.7.5 4 listopada, dodając ustandaryzowane odmowy modeli oraz poprawki dotyczące anulowanych narzędzi i międzyjęzykowego ładowania wiadomości. Kluczowa zmiana dotyczy mylącego rezultatu: żądanie może zakończyć się pomyślnie po stronie dostawcy, nie dostarczając jednak niczego, co aplikacja mogłaby wykorzystać.

To rozróżnienie ma znaczenie dla zespołów budujących agentów, czyli aplikacje pozwalające modelom wybierać działania i wywoływać zewnętrzne funkcje. Zakończone żądanie nie musi oznaczać zakończonego zadania. Odmowa, przerwana operacja i przywracanie uszkodzonej konwersacji wymagają różnych reakcji.

Wydanie zwraca uwagę na różnice w odpowiedziach OpenAI, Anthropic i Google, nie czyniąc ich zachowania identycznym. Jego praktyczne znaczenie polega na wyraźniejszej granicy między otrzymaniem odpowiedzi a zrozumieniem, co się wydarzyło. Zespoły aplikacyjne nadal muszą zdecydować, co taki wynik oznacza dla użytkowników.

Co langchain-core==1.7.5 zmienia poza numerem wersji

Wydanie poprawia sposób, w jaki aplikacje rozpoznają nieudane wyniki, zamiast obiecywać lepsze odpowiedzi modeli.

Opublikowane zmiany w wydaniu wskazują cztery istotne aktualizacje od wersji 1.7.4. Obejmują one standaryzację odmów, tłumaczenie blokad bezpieczeństwa Gemini, anulowanie narzędzi oraz ładowanie obiektu wiadomości serializowanego przez LangChain.js. Pozostały wpis na liście dotyczy samego wydania.

Zmiany te dotyczą różnych granic w oprogramowaniu. Obsługa odmów dotyczy granicy między odpowiedzią modelu a logiką aplikacji. Anulowanie dotyczy granicy między wykonaniem a monitorowaniem. Ładowanie wiadomości dotyczy granicy między JavaScriptem a Pythonem.

Ich wspólnym tematem jest zachowanie znaczenia, gdy operacja nie przynosi oczekiwanego rezultatu. Odpowiedź powinna informować, że model odmówił. Anulowana operacja powinna przestać wyglądać na aktywną. Zapisana wiadomość powinna pozostać rozpoznawalna, gdy odczytuje ją inne środowisko uruchomieniowe.

Czyni to z tej wersji ukierunkowane wydanie konserwacyjne z ważnym dodatkiem z perspektywy aplikacji. Informacje o wydaniu nie potwierdzają szybszego generowania, lepszego rozumowania ani wyższej dokładności odpowiedzi. Wymagałoby to odrębnych dowodów i nie powinno stanowić uzasadnienia aktualizacji.

Dla dewelopera użytecznym punktem wyjścia jest pytanie, czy aplikacja zależy od którejkolwiek z objętych zmianą granic. Prototyp działający wyłącznie na tekście może nie zauważyć natychmiast dużej różnicy. Agent, który analizuje odpowiedzi, przesyła wyniki strumieniowo i przywraca zapisane konwersacje, ma więcej zachowań do zbadania.

Moment wydania ma też konkretne wyjaśnienie. Zmiana dotycząca standaryzacji odmów została scalona 3 listopada, a następnie 4 listopada wprowadzono zmianę tłumaczenia Gemini. Wydanie łączy te powiązane zmiany w jeden pakiet. Ta sekwencja wyjaśnia zakres bez konieczności spekulowania o szerszej strategii firmy.

Numer poprawkowy może sprawiać, że praca ta wydaje się operacyjnie niewielka. Klasyfikacja błędów wpływa jednak na decyzje daleko wykraczające poza procedurę obsługi wyjątków, czyli kod reagujący na zgłoszony podczas wykonania problem. Może oddziaływać na komunikaty dla użytkowników, eskalację, monitorowanie oraz decyzję o rozpoczęciu kolejnego żądania.

Właściwa interpretacja jest zatem konkretna. LangChain czyni kilka wcześniej niejednoznacznych wyników bardziej wyraźnymi. Wydanie nie rozstrzyga, jak każda aplikacja powinna reagować, a jego zmian nie należy mylić z kompletnym systemem bezpieczeństwa agentów.

To rozróżnienie utrzymuje wiadomość w realiach. Istotnym dodatkiem jest bardziej użyteczny kontrakt aplikacyjny, czyli wspólne oczekiwanie dotyczące zwracanych informacji. Kontrakt ten staje się wartościowy, gdy oprogramowanie rzeczywiście go odczytuje i na jego podstawie działa.

Obsługa odmów modeli wywiera presję na zespoły aplikacyjne

Rozpoznawalna odmowa daje deweloperom lepszy sygnał, ale zarazem utrudnia uzasadnianie ogólnej obsługi niepowodzeń.

Odmowa oznacza, że model odmawia dostarczenia żądanego wyniku. Ustrukturyzowany wynik to odpowiedź, która ma odpowiadać zdefiniowanemu wcześniej formatowi danych. Gdy te ścieżki się spotykają, traktowanie każdej nieoczekiwanej odpowiedzi jako problemu z formatowaniem może ukryć rzeczywistą przyczynę.

Scalona zmiana dotycząca obsługi odmów modeli wprowadza standardowy blok treści odmowy oraz dedykowany ModelRefusalError. Jej autor opisuje wcześniejsze przypadki, w których odmowy dostawców pojawiały się jako końcowe odpowiedzi lub ogólne błędy parsowania. Zmiana obejmuje również opcjonalne oprogramowanie pośredniczące agentów, warstwę przechwytującą, która może zamieniać rozpoznane odmowy w błędy.

Bezpośrednia presja spada na właścicieli aplikacji, a nie na użytkowników modeli. Deweloperzy muszą zdecydować, czy odmowa kończy przepływ pracy, wywołuje bezpieczniejsze przeformułowanie czy trafia do recenzenta-człowieka. Framework może ujawnić ten stan, nie wiedząc, która reakcja pasuje do produktu.

Rozważmy hipotetycznego wewnętrznego asystenta, który przekształca zgłoszenia techniczne w ustrukturyzowane elementy pracy. Prawidłowa odpowiedź tworzy robocze zgłoszenie. Nieprawidłowy format trafia na ścieżkę naprawy. Odmowa powinna otrzymać odrębne traktowanie, ponieważ naprawa formatowania nie odnosi się do decyzji o wstrzymaniu treści.

Bez tego rozróżnienia aplikacja może zadawać niewłaściwe pytanie. Może pytać, dlaczego odpowiedź nie przeszła walidacji, gdy istotne pytanie brzmi, dlaczego żądany wynik został odrzucony. To kieruje debugowanie ku schematom, czyli definicjom oczekiwanych danych, zamiast ku rzeczywistemu stanowi odpowiedzi.

Implikacja operacyjna jest prosta: zespoły powinny oddzielić decyzje o ponowieniu próby od samej obecności błędu. Powtórzenie żądania jest rozsądne w przypadku niektórych tymczasowych awarii. To inna decyzja, gdy model sam odmówił realizacji żądania.

Jest to osąd dotyczący projektowania aplikacji, a nie dowód, że każda odmowa jest prawidłowa. Modele mogą odmawiać uzasadnionych żądań. Użyteczny produkt potrzebuje więc sposobu na rozróżnienie między rozpoznaniem odmowy a poparciem leżącego u jej podstaw rozumowania.

Zespoły odpowiedzialne za doświadczenie użytkownika stoją przed podobnym wyborem. Pusta odpowiedź, ogólny komunikat o błędzie i wyraźne wyjaśnienie przekazują różne informacje. Ustandaryzowany sygnał może wspierać jaśniejsze komunikaty, ale nie potrafi napisać odpowiedniego wyjaśnienia dla każdego kontekstu.

Nabywcy korporacyjni powinni zadać równie konkretne pytanie: czy produkt potrafi odróżnić odrzucone żądanie od błędu wykonania? Szerokie twierdzenie, że asystent obsługuje błędy, mówi niewiele o tym zachowaniu. Różnica staje się widoczna dopiero wtedy, gdy przepływ pracy trafia na trudny przypadek.

Dla deweloperów utrzymujących przeszukiwalną bazę wiedzy decyzje te powinny znaleźć się obok notatek integracyjnych i znanych ograniczeń. Dokumentowanie oczekiwanych wyników pomaga zapobiec sytuacji, w której późniejsze zmiany łączą odmienne stany w ten sam ogólny komunikat.

Presja nie polega na dodawaniu wszędzie bardziej skomplikowanej obsługi wyjątków. Chodzi o jasne przypisanie odpowiedzialności. Ktoś musi odpowiadać za decyzję o tym, co dzieje się po odmowie, a decyzja ta powinna przetrwać zmiany dostawców lub komponentów aplikacji.

Bloki odmów Gemini ujawniają ograniczenia wspólnego formatu

Wspólna etykieta odmowy może uprościć decyzje aplikacji, nie zacierając specyfiki zachowania poszczególnych dostawców.

Główne napięcie techniczne występuje między wspólnym interfejsem a odmiennymi sygnałami faktycznie zwracanymi przez dostawców. Standaryzacja działa tylko wtedy, gdy tłumaczenie zachowuje wystarczająco dużo informacji, by wspierać prawidłowe decyzje. Znajoma etykieta jest użyteczna, lecz równie ważny jest jej zakres.

Zmiana dotycząca blokad bezpieczeństwa Gemini mapuje wskazane sygnały blokowania Google na bloki treści odmowy. Opis wymienia powody zakończenia SAFETY, PROHIBITED_CONTENT i BLOCKLIST, a także blokowanie promptów. Dokumentuje również potrzebę dalszej integracji, w której brak identyfikacji dostawcy uniemożliwia tłumaczenie na ścieżce z zablokowanym promptem.

To ograniczenie ma kluczowe znaczenie dla analizy wydania. Aplikacja nie może zakładać, że każda istotna ścieżka stanie się widoczna wyłącznie dlatego, że istnieje tłumaczenie w warstwie podstawowej. Odpowiedź musi dotrzeć do tego tłumaczenia z informacjami, których ono oczekuje.

OpenAI, Anthropic i Google pozostają również odmiennymi punktami odniesienia. Ich sygnały trafiają do frameworka przez różne struktury odpowiedzi. Celem inżynieryjnym jest spójna obsługa aplikacji, a nie twierdzenie, że bazowi dostawcy stosują identyczne polityki lub procesy decyzyjne.

Dla zespołów korzystających z własnego zestawu narzędzi programistycznych dostawcy, czyli biblioteki przeznaczonej do wywoływania jego usługi, bezpośredni dostęp pozostaje rozsądną alternatywą. Może zachować natychmiastową widoczność natywnych odpowiedzi. Kompromis polega na tym, że aplikacja musi samodzielnie obsłużyć większą część tłumaczenia.

Podejście LangChain przenosi część tej pracy do współdzielonych komponentów. Korzyścią jest potencjalne ograniczenie powtarzanych kontroli specyficznych dla dostawców. Kosztem jest kolejna zależność: aplikacje muszą ufać, że integracja rozpoznaje istotną odpowiedź i zachowuje użyteczne szczegóły.

Żadna z tych dróg nie eliminuje odpowiedzialności. Bezpośrednia integracja może błędnie zinterpretować pole dostawcy. Współdzielony framework może pominąć ścieżkę integracji. Istotne porównanie dotyczy miejsca tłumaczenia, sposobu jego testowania oraz tego, kto zauważy, gdy przestanie ono odpowiadać rzeczywistości.

Przykład Gemini czyni to porównanie namacalnym. Zespół może wspierać wysiłek standaryzacyjny, jednocześnie wymagając dowodu, że rzeczywista ścieżka odpowiedzi wdrożona w jego środowisku dociera do standardowej reprezentacji. Te stanowiska są zgodne, ponieważ projekt interfejsu i działająca integracja to odrębne twierdzenia.

To rozróżnienie wpływa również na monitorowanie. Łączenie rozpoznanych odmów we wspólną kategorię może ułatwić interpretację raportów aplikacyjnych. Jednak zbyt agresywne łączenie kategorii może ukryć, który warunek dostawcy wystąpił i jakie działanie naprawcze jest właściwe.

Praktyczna aplikacja powinna zatem zachować różnicę między wspólną decyzją a dowodami ją wspierającymi. Wspólną decyzją może być zatrzymanie automatycznego przetwarzania. Dowody nadal powinny wyjaśniać, która odpowiedź wywołała tę decyzję.

Dlatego obsługa odmów LangChain zasługuje na uwagę wykraczającą poza nazwę nowego typu. Wartość polega na połączeniu wyniku dostawcy ze znaczącą gałęzią aplikacji. Jeśli to połączenie zawiedzie, ustandaryzowany format pozostaje teoretycznie dostępny, podczas gdy użytkownik nadal otrzymuje niewyjaśniony pusty wynik.

Wydanie należy więc oceniać na granicach integracji. Jego znaczenie rośnie, gdy pakiety dostawców, tłumaczenie odpowiedzi i logika aplikacji są zgodne. Aktualizacja odizolowanego komponentu sama w sobie nie ustanawia takiej zgodności.

Anulowane narzędzia i zapisane wiadomości mierzą się z tym samym problemem przejrzystości

Towarzyszące poprawki dotyczą powiązanego wymogu: oprogramowanie powinno dokładnie raportować, co się wydarzyło, gdy wykonanie opuszcza oczekiwaną ścieżkę.

Narzędzie to zewnętrzna funkcja, którą agent może wywołać. Zakres śledzenia to rekord monitorowania operacji. Jeśli anulowanie przerywa wykonanie bez zamknięcia tego rekordu, widok monitorowania może błędnie przedstawiać operację, która już się zatrzymała.

Poprawka anulowania narzędzia rozwiązuje tę rozbieżność. Jej opis wskazuje, że anulowane narzędzia wcześniej pomijały oczekiwane wywołania zwrotne po zakończeniu, ponieważ anulowanie używa szerszej kategorii wyjątków Pythona. Zmiana raportuje błąd i ponownie zgłasza pierwotny wyjątek, dzięki czemu anulowanie może nadal się propagować.

Ten zakres ma znaczenie. Zamknięcie rekordu monitoringu różni się od cofnięcia zewnętrznego działania. Wydanie nie dowodzi, że anulowanie narzędzia cofa wiadomość e-mail, aktualizację bazy danych lub żądanie już zaakceptowane gdzie indziej.

W przypadku hipotetycznego asystenta wsparcia użytkownik naciskający przycisk zatrzymania powinien zatem rodzić kilka odrębnych pytań. Czy lokalne wykonanie otrzymało anulowanie? Czy rekord monitoringu został zamknięty? Czy zewnętrzna usługa zdążyła już zaakceptować działanie? Jaśniejsza odpowiedź na jedno pytanie nie rozstrzyga pozostałych.

Korzyścią operacyjną jest lepsza interpretacja. Prawidłowo zamknięty rekord może pomóc odróżnić przerwane żądanie od pracy, która nadal trwa. Zespoły wciąż potrzebują osobnych dowodów, gdy badają, czy wystąpił efekt zewnętrzny.

Zmiana dotycząca zapisanych wiadomości odnosi się do innego rodzaju przerwanego rozumienia. Serializacja przekształca obiekt w reprezentację, którą można przechowywać lub przesyłać. Deserializacja go odtwarza. Zgodność zawodzi, gdy środowisko odbierające nie potrafi rozpoznać obiektu znanego środowisku wysyłającemu.

Poprawka ładowania wiadomości między językami dodaje w Pythonie obsługę ładowania obiektów RemoveMessage serializowanych przez LangChain.js. Autor wskazuje zapisany stan grafu zawierający te obiekty jako przypadek, którego to dotyczy. Poprawka dodaje również tę klasę do listy dozwolonych obsługiwanych wiadomości.

To wąska naprawa interoperacyjności, a nie ogólna obietnica, że każdy zapisany obiekt będzie swobodnie przenoszony między językami. Lista dozwolonych typów to jawny zestaw dopuszczonych typów obiektów. Dodanie jednego typu rozwiązuje konkretny brak mapowania.

Hipotetyczny zespół z aplikacją JavaScript i usługą analityczną Python ilustruje stawkę. Większość zapisanych rozmów może ładować się normalnie. Rzadsza operacja na wiadomości może ujawnić lukę zgodności dopiero po wejściu tej operacji do zapisanego stanu.

Wniosek jest taki, by oceniać reprezentatywny stan, a nie tylko reprezentatywny tekst. Rozmowa może zawierać informacje kontrolne obok widocznych wiadomości. Testowanie wyłącznie zwykłych wymian pytań i odpowiedzi pozostawia te mniej widoczne obiekty poza zakresem dowodów.

Łącznie poprawki sprawiają, że wydanie jest bardziej spójne, niż sugeruje niepowiązana lista zmian. Tłumaczenie odmów wyjaśnia wynik. Raportowanie anulowania wyjaśnia cykl życia operacji. Ładowanie między językami zachowuje możliwość interpretacji zapisanego stanu.

Dla langchain-core==1.7.5 jest to szerszy motyw inżynieryjny: otaczający system potrzebuje dokładnego obrazu niekompletnej lub wyjątkowej pracy. Same lepsze odpowiedzi nie rozwiązałyby tych problemów, ponieważ każdy z nich występuje w oprogramowaniu odpowiedzialnym za interpretację aktywności sterowanej przez model.

Standardowa odmowa nie jest gwarancją bezpieczeństwa

Najbardziej sceptyczna interpretacja głosi, że jaśniejsza klasyfikacja pomaga tylko tam, gdzie cała ścieżka aplikacji wykorzystuje ją poprawnie.

Istnieją rozsądne powody, by pozytywnie przyjąć to wydanie. Rozpoznawalne wyniki dają programistom lepszy materiał do podejmowania decyzji. Istnieje też rozsądny zarzut: kolejny typ i kolejna opcjonalna integracja mogą zwiększyć złożoność, jeśli aplikacje nigdy nie wdrożą ich konsekwentnie.

Ten zarzut nie wymaga dowodów na nową usterkę. Wynika z architektury. Reprezentacja odpowiedzi nie może określić zachowania aplikacji, gdy późniejszy kod ją ignoruje, odrzuca lub przekształca w ogólny ciąg znaków.

Rozważmy hipotetyczny produkt, który wyświetla każdą odpowiedź modelu przez ten sam renderer tekstu, czyli komponent przygotowujący wynik dla użytkowników. Framework może poprawnie zachować odmowę. Produkt nadal może utracić to rozróżnienie, zanim użytkownik cokolwiek zobaczy.

Możliwy jest również odwrotny problem w projekcie aplikacji. Zespół może po usłyszeniu o zmianie traktować każdą pustą odpowiedź jako odmowę. Zastępowałoby to wyraźny sygnał domysłem i mogłoby ukrywać niepowiązane problemy.

Rozsądnym standardem są dowody w punkcie podejmowania decyzji. Programiści powinni ustalić, jakie informacje docierają do kodu, który ponawia próby, wyświetla, eskaluje lub zatrzymuje działanie. Potwierdzenie, że wcześniejszy komponent obsługuje bloki odmowy, jest przydatne, lecz niepełne.

Kolejne ograniczenie dotyczy polityki. Rozpoznanie, że dostawca odmówił, nie ustala, czy żądanie było szkodliwe, uzasadnione czy błędnie zrozumiane. Wydanie zmienia reprezentację i obsługę. Nie tworzy niezależnej oceny jakości każdej decyzji dostawcy.

Ma to znaczenie przy omawianiu twierdzeń o bezpieczeństwie z kupującymi. Produkt może poprawnie rozpoznawać odmowy, a mimo to źle obsługiwać inne ryzykowne żądania. Może też obsługiwać odmowy niespójnie na różnych ścieżkach. Żadna z tych możliwości nie zostaje rozwiązana samą obecnością standardowego typu bloku.

Zakres wersji wymaga równie dużej ostrożności. Szersze prace nad odmowami dotyczą podstawowej funkcjonalności, integracji dostawców i zachowania agentów. Zespoły powinny zweryfikować zainstalowane komponenty, od których zależą, zamiast zakładać, że jeden przypięty pakiet aktywuje każdą funkcję opisaną w scalonej zmianie.

Testowanie powinno obejmować również oczekiwany sukces. Wydanie skupione na wyjątkowych wynikach nadal trafia do aplikacji, która musi poprawnie zwracać zwykłe odpowiedzi. Użyteczna ocena sprawdza, czy rozróżnienia przynoszą poprawę bez nieoczekiwanej zmiany niepowiązanych wyników.

Nie przedstawiono tu niezależnego benchmarku produkcyjnego potwierdzającego mniejszą liczbę incydentów, niższe koszty operacyjne lub lepszą trafność odmów po wdrożeniu. Pozostają to wyniki, które zespoły muszą zmierzyć. Wydanie zapewnia konkretną zmianę inżynieryjną, a nie dowód na każdą korzyść biznesową, którą ktoś mógłby z nim powiązać.

Właściwy argument za aktualizacją jest zatem węższy i łatwiejszy do obrony. Przyjmij wydanie, ponieważ jego udokumentowane zmiany dotyczą istotnego zachowania aplikacji, a następnie zweryfikuj to zachowanie w kontekście. Unikaj twierdzenia, że sama standaryzacja czyni agenta niezawodnym.

Na co programiści powinni zwracać uwagę po wydaniu

Kolejne użyteczne sygnały dotyczą zakresu integracji, zachowania aplikacji i powtarzalnych wyników zgodności.

Pierwszym sygnałem jest dalsza realizacja udokumentowanych prac nad integracją Google. Zespoły powinny obserwować, czy kolejne zmiany dotyczą identyfikacji dostawcy w odpowiedziach zablokowanych przez prompt oraz obsługi bloków odmowy, gdy wiadomości wracają do Gemini.

Takie dowody wzmocniłyby tezę, że wspólna reprezentacja obejmuje właściwy przepływ pracy, a nie jedynie odizolowane tłumaczenie odpowiedzi. Utrzymujące się luki zawęziłyby praktyczną korzyść dla dotkniętych integracji Google.

Istotna jest obserwacja zachowania w całej ścieżce żądania. Informacje o wydaniu dotyczące dalszych prac są użytecznymi wskazówkami. Powtarzalny wynik z zainstalowanej integracji stanowi mocniejszy dowód, że ścieżka aplikacji dla zablokowanej odpowiedzi działa teraz zgodnie z zamierzeniem.

Drugim sygnałem jest przyjęcie przez aplikacje jawnych decyzji dotyczących odmowy. Użyteczne dowody pokażą, że odmowy prowadzą do odrębnego wyniku produktu, zamiast pojawiać się jako puste odpowiedzi lub ogólne błędy formatowania. To właśnie tutaj wsparcie frameworka staje się widoczną dla użytkownika poprawą.

Zespoły mogą ocenić to rozróżnienie bez publikowania szerokiej oceny niezawodności. Mogą sprawdzić, czy odrzucone żądanie zatrzymuje się właściwie, zachowuje istotne informacje diagnostyczne i unika automatycznego działania przeznaczonego dla innej kategorii błędów.

Jeśli aplikacje nadal będą łączyć te wyniki, szerszy argument za standaryzacją osłabnie. Framework nadal będzie ujawniał więcej informacji, ale produkt nie przekształci tych informacji w lepsze decyzje.

Trzecim sygnałem są dowody regresji dla anulowanych narzędzi i stanu między językami. Kontrola regresji weryfikuje, czy wcześniej poprawione zachowanie pozostaje poprawne. W tym przypadku użyteczne przykłady obejmowałyby przerwane wykonanie oraz zapisany stan zawierający obiekt wiadomości, którego dotyczy problem.

Pozytywny wynik wsparłby konkretne twierdzenia dotyczące utrzymania. Powtarzalna awaria pomogłaby ustalić, czy problem leży w pakiecie podstawowym, sąsiedniej integracji czy założeniach aplikacji. Żaden z wyników nie powinien przeradzać się w twierdzenie dotyczące każdego możliwego przepływu pracy.

W ciągu najbliższych kilku miesięcy te sygnały zapewnią lepszą ocenę niż liczba pobrań czy ogólny entuzjazm. Pytają, czy zmiany docierają do ludzi i systemów, które na nich polegają. Utrzymują też ocenę w granicach udokumentowanego zakresu.

Dla zespołów rozważających langchain-core==1.7.5 punktem wyjścia powinny być decyzje podejmowane przez aplikację, gdy oczekiwana praca nie nadchodzi. Przeanalizuj, jak rozróżnia ona odmowę, przerwane działanie i nieczytelną zapisaną rozmowę. Następnie prześledź te wyniki przez komponenty, które rzeczywiście widzą użytkownicy i operatorzy.

Zachowaj ocenę na tyle niewielką, by była zrozumiała, i na tyle realistyczną, by miała znaczenie. Uwzględnij zwykłe udane żądania obok przypadków, których dotyczą zmiany, i zapisuj wersje pakietów, które wygenerowały każdy wynik. Zachowuj szczegóły dostawcy tam, gdzie wspierają diagnozę, jednocześnie utrzymując jasność komunikatów dla użytkowników. Wykorzystaj te dowody, aby zdecydować, które gałęzie aplikacji wymagają zmian. Które z tych wyników Twój system potrafi dziś wyjaśnić, a które nadal znikają za ogólnym komunikatem o błędzie?