Obserwowalność Claude OpenTelemetry trafia do Databricks MLflow, ujawniając błędy agentów
Obserwowalność Claude OpenTelemetry łączy się teraz natywnie z Databricks MLflow, ujawniając szczegóły wykonania, które przekonująca odpowiedź końcowa może ukrywać. OpenTelemetry to otwarty standard rejestrowania i wymiany aktywności aplikacji. Integracja daje deweloperom kolejny sposób badania agentów, które pomijają dowody, powtarzają pracę lub kończą działanie niepełną odpowiedzią.
Databricks ogłosił obsługiwany cel docelowy 3 listopada 2026 r. Anthropic przedstawił szerszą funkcję natywnego śledzenia w publicznej becie 14 października. To rozróżnienie ma znaczenie: jest to integracja Databricks w ramach szerszego systemu eksportu, a nie wyłączne porozumienie dotyczące monitorowania.
Główne napięcie dotyczy tego, jak zespoły oceniają wydajność agentów. Dopracowana odpowiedź pokazuje, co dostarczył agent. Zapis wykonania pomaga wyjaśnić, jak do tego doszedł. Langfuse, Grafana i inne platformy obserwowalności już działają w tym obszarze. Databricks pozycjonuje MLflow, swoją platformę rozwoju i ewaluacji, jako miejsce do łączenia tych dowodów z badaniem i późniejszym testowaniem.
Obserwowalność Claude OpenTelemetry dodaje natywny cel Databricks
Według Databricks deweloperzy mogą wysyłać natywne zapisy wykonania Claude do MLflow z bibliotek programistycznych Anthropic, API Messages i Claude Managed Agents. API to interfejs używany przez aplikacje do żądania usługi. Managed Agents to hostowani przez Anthropic agenci realizujący zadania.
Natywna integracja śledzenia wykorzystuje Zerobus Ingest, usługę pobierania danych Databricks, do odbierania zapisów. Unity Catalog, jego system zarządzania danymi, przechowuje je w tabelach powiązanych z eksperymentem MLflow.
Zmiana daje aktywności Claude bezpośrednią drogę do istniejącego środowiska badawczego klasy korporacyjnej.
Ślad rejestruje wykonanie, podczas gdy span reprezentuje pojedynczą operację w ramach tego zapisu. Żądania do modelu i aktywność narzędzi mogą występować jako osobne spany. Ich relacje pozwalają badaczowi prześledzić sekwencję stojącą za odpowiedzią.
Dla zespołu programistycznego taka sekwencja zmienia punkt wyjścia rozmowy o debugowaniu. Zamiast prosić kogoś o odtworzenie nieudanej interakcji z pamięci, zespół może przeanalizować zarejestrowaną aktywność. Nie ustala to automatycznie właściwej diagnozy. Daje jednak diagnozie coś konkretnego, do czego może się odnieść.
To rozróżnienie staje się szczególnie przydatne, gdy odpowiedź wygląda rozsądnie. Oczywisty błąd od razu zachęca do zbadania sprawy. Wiarygodna odpowiedź może umknąć uwadze, nawet jeśli agent pominął decydujące źródło lub poświęcił niepotrzebny wysiłek na zbieranie informacji.
Rozważmy hipotetycznego wewnętrznego asystenta badawczego przygotowującego aktualizację produktu. Jego końcowe podsumowanie zawiera trafne tło, ale pomija niedawną informację o wydaniu. Samo przeczytanie podsumowania pozostawia kilka możliwych wyjaśnień. Asystent mógł nigdy nie znaleźć dokumentu, źle zrozumieć jego treść albo pominąć ustalenie podczas tworzenia odpowiedzi.
Zapis wykonania pomaga rozdzielić te możliwości. Każde wyjaśnienie wskazuje na inną interwencję. Zmiana instrukcji dotyczących pisania niewiele da, jeśli etap wyszukiwania nigdy nie ujawnił odpowiedniego dokumentu.
To jest operacyjne znaczenie ogłoszenia. Natywny eksport skraca dystans między interakcją z agentem a narzędziami używanymi do jej zbadania. Zespoły nadal muszą zdecydować, jakie zachowanie uznają za błąd.
Integracja wyznacza też wyraźną granicę wokół tej informacji. Nie ogłasza nowego modelu Claude, wyższego wyniku benchmarkowego ani niezależnie zmierzonej poprawy niezawodności. Jej bezpośrednim wkładem jest zbieranie danych dowodowych i dostęp do nich.
To węższe twierdzenie niż poprawa inteligencji, ale dotyczy praktycznej słabości wdrażania agentów. Zespoły nie mogą konsekwentnie poprawiać zachowania, którego z trudem są w stanie obserwować.
Właściciele agentów odczuwają presję, by wyjaśniać akceptowalne odpowiedzi
Bezpośrednia presja spada na deweloperów i właścicieli produktów, którzy zatwierdzają agentów do rzeczywistych przepływów pracy. Ich odpowiedzialność wykracza poza ocenę, czy odpowiedź brzmi użytecznie. Muszą wyjaśniać pominięte ustalenia, zmarnowaną pracę i błędy ujawniające się dopiero po wdrożeniu.
Natywne śledzenie podnosi standard dostępnych dowodów dla takich decyzji.
Demonstracja zazwyczaj prezentuje wybraną interakcję. Środowisko produkcyjne wprowadza zróżnicowane pytania, niepełne dokumenty, zmieniające się narzędzia i niejednoznaczne prośby. Agent, który dobrze radzi sobie ze znanym przykładem, nadal może mieć trudności, gdy zmieniają się warunki otoczenia.
Tworzy to problem zarządczy w takim samym stopniu jak inżynieryjny. Właściciele produktów muszą odróżnić tolerowalne ograniczenie od powtarzającej się wady. Deweloperzy potrzebują wystarczających dowodów, aby odtworzyć wadę. Eksperci dziedzinowi muszą określić, co powinna zawierać odpowiedź.
Bez wspólnego zapisu te grupy mogą mówić obok siebie. Recenzent zgłasza, że odpowiedź wydaje się niepełna. Inżynier widzi udane żądanie. Menedżer produktu widzi użytkownika, który ukończył przepływ pracy. Każda obserwacja może być trafna, a mimo to pozostawić podstawowy problem nierozwiązany.
Śledzenie agentów Claude oferuje wspólny obiekt dla tej rozmowy. Zespół może zbadać konkretne wykonanie i połączyć informację zwrotną z tym, co faktycznie się wydarzyło. Wartość wynika z uczynienia rozbieżności wystarczająco konkretną, aby można było ją zbadać.
Uruchomienie obserwowalności agentów przez Anthropic obejmuje relacje klientów z organizacji korzystających z różnych platform monitorujących. Foxglove opisuje analizowanie interakcji agentów obok aktywności produktu w PostHog. FloQast opisuje łączenie aktywności modelu z procesami księgowymi w Grafana Cloud.
Relacje te ilustrują różne priorytety. Zespół produktowy zajmujący się robotyką chce zrozumieć, gdzie wsparcie nie spełnia oczekiwań. Zespół odpowiedzialny za procesy finansowe chce mieć możliwy do obrony opis tego, co zrobił agent. Obie potrzeby wykraczają poza sprawdzenie tekstu końcowego.
Pozostają one jednak deklaracjami klientów przedstawionymi przez Anthropic, a nie niezależnymi ocenami integracji Databricks. Ustanawiają istotne przypadki użycia, nie dowodząc uniwersalnego rezultatu biznesowego.
Dla pracowników wiedzy ten sam problem pojawia się, gdy podsumowanie staje się podstawą kolejnej decyzji. Brakujące zastrzeżenie może trafić do dokumentu planistycznego, odpowiedzi dla klienta lub dyskusji inżynieryjnej. Płynny język może utrudniać zauważenie takiego pominięcia.
Zespoły organizujące przeszukiwalną bazę wiedzy stają przed podobnym pytaniem: które dokumenty wspierają odpowiedź? Operatorzy agentów muszą również badać, czy system uzyskał dostęp do tych dokumentów i właściwie z nich skorzystał.
Presja jest więc konkretna. Każdy, kto rozszerza zakres odpowiedzialności agenta, potrzebuje wiarygodnego sposobu badania błędów i ustalania priorytetów poprawek. Natywny eksport ułatwia rozpoczęcie takiego badania. Nie eliminuje jednak osądu potrzebnego do zdecydowania, czy agent zasługuje na większą odpowiedzialność.
Mechanizm łączy dowody wykonania z ewaluacją
Istotnym mechanizmem jest połączenie zarejestrowanego zachowania z powtarzalną decyzją rozwojową. Zbieranie aktywności ma ograniczoną wartość, jeśli dowody nigdy nie zmieniają sposobu, w jaki zespół bada lub testuje swojego agenta.
Analiza śladów MLflow staje się użyteczna, gdy ustalenie przekształca się w możliwe do przetestowania wyjaśnienie.
Wyobraźmy sobie hipotetycznego agenta badawczego, który wielokrotnie otwiera dokument, zanim utworzy niepełne podsumowanie. Powtarzający się dostęp jest widocznym zachowaniem. Jego przyczyna pozostaje pytaniem. Agent może nie mieć reguły zatrzymania, otrzymywać niespójne wyniki narzędzia albo zasadnie wracać do zmieniających się informacji.
Traktowanie każdego ponownego odczytu jako marnotrawstwa spłaszczałoby te wyjaśnienia do mylącego uproszczenia. Badacz musi zrozumieć, czy powtarzana operacja dostarczyła użytecznych dowodów. Pożądana poprawka zależy od tego rozróżnienia.
Użyteczne badanie łączy zatem zaobserwowane zachowanie z oczekiwanym wynikiem. Zespół powinien być w stanie wyjaśnić, co poszło nie tak, dlaczego proponowana zmiana temu zaradza i jakie dowody podważyłyby to wyjaśnienie.
Databricks dokumentuje wykrywanie powtarzających się problemów za pośrednictwem MLflow Issues, funkcji beta obsługiwanej przez Genie Code, jego asystenta programowania. System analizuje zarejestrowaną aktywność i grupuje dowody w problemy do zbadania.
Dokumentacja opisuje również monitory, które ustalają punkt odniesienia na podstawie niedawnych śladów i oceniają próbki napływającej aktywności. Skorer to funkcja oceniająca określone zachowanie lub wynik.
Te możliwości wspierają cykl rozwojowy, lecz nie należy ich mylić z automatyczną gwarancją. Detektor problemów proponuje użyteczny sposób grupowania obserwacji. Skorer operacjonalizuje definicję. Żaden z nich nie eliminuje potrzeby sprawdzenia, czy ta definicja odpowiada rzeczywistemu zadaniu.
Na przykład ewaluacja nagradzająca mniejszą liczbę wywołań narzędzi może zachęcać do przedwczesnych odpowiedzi. Lepsza ocena uwzględniałaby niepotrzebną pracę obok kompletności. W przeciwnym razie pozorna poprawa wydajności mogłaby po prostu odzwierciedlać mniej dokładne badanie.
To samo rozumowanie dotyczy szybkości odpowiedzi. Szybsze zakończenie jest wartościowe, gdy odpowiedź nadal spełnia prośbę. Jeśli agent pominie ważne źródło, krótsze wykonanie może ukryć regresję jakości.
Utrzymanie stałości zadania i kryteriów oceny pomaga uczynić porównania możliwymi do interpretacji. Zespół może zapytać, czy zmienione instrukcje poprawiają problematyczne zachowanie, nie osłabiając niezwiązanych wymagań. To bardziej informacyjne niż porównywanie niepowiązanych przykładów z różnych wersji.
Ekspertyza człowieka pozostaje konieczna wszędzie tam, gdzie poprawność zależy od kontekstu. Specjalista dziedzinowy może wskazać brakujący wyjątek lub wyjaśnić, dlaczego pozornie zbędne działanie było uzasadnione. Takie oceny pomagają zapobiec nagradzaniu niewłaściwego zachowania przez automatyczną ocenę.
Implikacja produktowa jest taka, że obserwowalność i ewaluacja należą do tej samej rozmowy rozwojowej. Dowody wykonania wyjaśniają wynik. Ewaluacja sprawdza, czy proponowana poprawka sprawdza się w reprezentatywnych zadaniach.
Dla kupujących istotne pytanie jest więc szersze niż to, czy platforma wyświetla atrakcyjne ślady. Chodzi o to, czy zespół potrafi przejść od nieudanej interakcji do uzasadnionej zmiany, a następnie zbadać jej konsekwencje.
Otwarte standardy przesuwają porównanie w stronę przepływu pracy i zarządzania
Projekt eksportu Anthropic nadaje temu ogłoszeniu kontekst konkurencyjny. Aktywność Claude może trafiać do wielu celów obserwowalności. Databricks musi więc konkurować tym, co dzieje się po dotarciu zapisów.
Wspólny standard eksportu sprawia, że przepływ pracy badawczej staje się bardziej znaczącym punktem porównania.
Integracja MLflow z OpenTelemetry dokumentuje zarówno pozyskiwanie danych, jak i eksport z użyciem tego standardu. Obsługuje też wspólne konwencje opisywania aktywności generatywnej AI. Konwencje te zapewniają kompatybilnym systemom wspólne nazwy i struktury istotnych informacji.
Stanowi to alternatywę dla traktowania każdej integracji modelu jako odrębnego projektu monitorowania. Zespół może rozważyć, jak aktywność modelu wpisuje się w pozostałe dowody dotyczące działania aplikacji.
Zgodność protokołów nie czyni jednak konkurencyjnych produktów wzajemnie wymiennymi. Rekord wykonania nadal potrzebuje użytecznego interfejsu, odpowiednich kontroli dostępu, zrozumiałych ocen oraz miejsca w codziennej pracy zespołu. Wymagania te mogą przeważyć nad wygodą początkowego eksportu.
Langfuse, Grafana Cloud i PostHog pojawiają się w materiałach premierowych Anthropic w przykładach klientów. Ich obecność pokazuje, że zespoły podchodzą do obserwowalności agentów z różnych punktów wyjścia. Niektóre zaczynają od oceny AI, inne od monitorowania infrastruktury lub analityki produktowej.
Szczególny argument Databricks dotyczy bliskości danych przedsiębiorstwa i mechanizmów zarządzania nimi. Dla organizacji, która już analizuje tam informacje operacyjne, rekordy agentów mogą stać się kolejnym zbiorem danych w ramach znanych procesów.
Dokumentacja Unity Catalog storage podaje, że dostęp do śladów jest zgodny z uprawnieniami do schematów i tabel. Użytkownicy mający dostęp do tych tabel mogą przeglądać swoje ślady we wszystkich powiązanych eksperymentach. Ten szczegół zasługuje na uwagę podczas przeglądu dostępu.
Dokumentacja obsługuje również odpytywanie przechowywanych rekordów za pomocą SQL, języka używanego do pobierania i analizowania danych strukturalnych. Daje to zespołom danych kolejną drogę do badania aktywności agentów wraz z informacjami, którymi już zarządzają.
Analityczna atrakcyjność jest oczywista. Zespół produktowy może chcieć połączyć wzorzec awarii z konkretnym przepływem pracy lub wydaniem aplikacji. Trudniejsze pytanie organizacyjne brzmi, czy istotne metadane są konsekwentnie rejestrowane i rozumiane.
Otwarty format sam w sobie nie zapewni takiej dyscypliny. Zespoły nadal potrzebują znaczących identyfikatorów, jasnej odpowiedzialności i uzgodnienia, które porównania są miarodajne. W przeciwnym razie większy zbiór rekordów może odtworzyć chaos rozproszonych logów.
Istnieje też różnica między elastycznością transportu a przenośnością organizacyjną. Przenoszenie spanów między kompatybilnymi systemami to jeden problem. Odtworzenie nawyków przeglądu, kryteriów oceny i zasad zarządzania to inny.
Ogranicza to szerokie twierdzenia o niezależności od dostawcy. Otwarty protokół zmniejsza konkretną barierę integracyjną. Kupujący powinni nadal sprawdzać, jak duża część ich procesu analizy zależy od funkcji specyficznych dla danej platformy.
Wniosek dotyczący konkurencji jest praktyczny, a nie dramatyczny. Natywny eksport Claude zmniejsza znaczenie samego własnościowego gromadzenia danych. Mocniejsze porównanie dotyczy tego, jak skutecznie każde miejsce docelowe pomaga użytkownikom dojść do decyzji rozwojowej i ją zweryfikować.
Status beta i niepełne rekordy ograniczają to, co ustalają ślady
Najważniejszym zastrzeżeniem jest różnica między gromadzeniem dowodów a potwierdzeniem poprawy. Ogłoszenie dokumentuje możliwości i przykłady. Nie przedstawia niezależnego badania pokazującego, jak integracja Databricks zmienia niezawodność agentów.
Ślad wspiera analizę; nie poświadcza, że analiza została zakończona.
Wpis Databricks zawiera szczególnie użyteczne ujawnienie. Demonstracja powtarzających się problemów została przygotowana ręcznie, a automatyczne Issue Detection nie zostało uruchomione dla tego przykładu. Ilustrację należy więc odczytywać jako demonstrację przepływu pracy.
To ujawnienie nie unieważnia podstawowej funkcji. Ogranicza jedynie to, co przykład dowodzi. Czytelnicy mogą zobaczyć zamierzony sposób prezentacji powiązanych awarii, nie traktując obrazu jako dowodu dokładności automatycznego wykrywania.
Podobne rozróżnienie dotyczy diagnoz generowanych przez maszyny. Przekonujące wyjaśnienie nieudanego wykonania nadal jest wyjaśnieniem wymagającym oceny. Osoby prowadzące analizę powinny sprawdzić, czy zarejestrowane dowody je potwierdzają oraz czy inne wyjaśnienia pozostają prawdopodobne.
Kolejnym ograniczeniem jest zasięg. Anthropic rozróżnia aktywność rejestrowaną przez swoją usługę od aktywności rejestrowanej w aplikacji dewelopera. Agent może obejmować oba środowiska, przez co różne części wykonania są widoczne dzięki różnemu instrumentowaniu.
Dla kupującego istotne pytanie brzmi, czy rekord obejmuje operacje ważne dla zadania. Szczegółowy opis aktywności modelu może nadal pozostawiać niepewność dotyczącą lokalnego narzędzia lub źródła informacji znajdującego się wyżej w łańcuchu.
Dokumentacja Anthropic dotycząca API tracing również rozróżnia eksport samych metadanych od eksportu pełnej treści. Metadane opisują aktywność, niekoniecznie uwzględniając prompty, odpowiedzi lub treść narzędzi potrzebną do głębszej diagnozy.
Gromadzenie pełnej treści wiąże się z odpowiadającą mu decyzją dotyczącą zarządzania danymi. Dokumentacja wyjaśnia, że przekazane informacje znajdują się u wybranego miejsca docelowego i podlegają zasadom przechowywania oraz kontroli dostępu tej usługi. Eksport zasługuje więc na taką samą uwagę jak inne transfery wrażliwych informacji aplikacyjnych.
Samo dostarczenie danych nie jest nieomylnym zapisem historycznym. Anthropic dokumentuje dostarczanie według zasady best-effort oraz możliwość występowania zduplikowanych spanów. Wyjaśnia również, że utraconych spanów nie można wysłać ponownie.
Wniosek ma znaczenie dla ustaleń negatywnych. Brak operacji nie dowodzi automatycznie, że agent nigdy jej nie wykonał. Przed wyciągnięciem takiego wniosku osoby prowadzące analizę muszą uwzględnić zasięg i dostarczanie danych.
Ograniczenia te sugerują użyteczny podział między dowodami do debugowania a silniejszymi twierdzeniami o zapewnieniu jakości. Ślady mogą pomóc wyjaśnić konkretną interakcję. Twierdzenia o pełnej audytowalności, konsekwentnym wykrywaniu lub lepszych wynikach biznesowych wymagają dodatkowych dowodów.
Kupujący powinni również oddzielać natywną dostępność od gotowości operacyjnej. Obsługiwane miejsce docelowe nie oznacza, że każdy zespół uzgodnił zasady przechowywania, dostęp recenzentów, odpowiedzialność za analizę czy eskalację. Decyzje te określają, czy możliwość stanie się rutynową praktyką.
Właściwy sceptycyzm powinien być konkretny. Należy pytać, co zarejestrowano, co pominięto, jak zidentyfikowano problem i jak przetestowano proponowaną korektę. Pytania te pozwalają ocenić obietnicę bez odrzucania praktycznej wartości.
Obserwuj zasięg, zweryfikowane poprawki i wdrożenie wykraczające poza demonstracje
W nadchodzących miesiącach najbardziej miarodajne sygnały będą dotyczyć zasięgu, zweryfikowanych usprawnień i trwałego wykorzystania. Każdy z nich odnosi się do innej części twierdzenia, że natywny eksport ułatwia obsługę agentów.
Najmocniejsze dowody połączą widoczną awarię z korektą, która sprawdza się przy reprezentatywnych obciążeniach.
Po pierwsze, warto obserwować, czy zespoły demonstrują spójne rekordy obejmujące aktywność modeli hostowanych przez usługę oraz własne narzędzia aplikacyjne. Analiza staje się bardziej użyteczna, gdy śledzi operację, która wygenerowała odpowiedź, a nie odizolowany fragment.
Dowody takiej ciągłości wzmocniłyby praktyczny argument za obserwowalnością Claude OpenTelemetry. Doniesienia o rozłączonych rekordach lub niewyjaśnionych brakach zawęziłyby zakres, w którym zespoły mogą na niej polegać.
Sygnał ten należy oceniać na podstawie rzeczywistych przykładów przepływów pracy. Udany eksport potwierdza, że informacje dotarły do miejsca docelowego. Użyteczna analiza pokazuje, że informacje odpowiedziały na pytanie operacyjne, którego rozwiązanie wcześniej sprawiało zespołowi trudność.
Po drugie, warto obserwować udokumentowane poprawki ze stabilnymi kryteriami oceny. Wiarygodny opis powinien wyjaśniać pierwotną awarię, interwencję i zachowanie zaobserwowane później. Powinien również uwzględniać konsekwencje wykraczające poza objaw będący celem działania.
Agent badawczy, który przestaje powtarzać odczyty, ale zaczyna pomijać ważne ustalenia, zamienił jedną wadę na inną. Użyteczny raport zbadałby oba rezultaty. Takie dowody wsparłyby pętlę rozwojową opisaną przez Databricks.
Niezależna replikacja dodatkowo wzmocniłaby to twierdzenie. Demonstracje dostawcy mogą potwierdzić zamierzone zachowanie, podczas gdy relacje zewnętrzne mogą ujawnić, jak przepływ pracy radzi sobie w mniej starannie przygotowanych warunkach. Obie formy dowodów są wartościowe, jeśli ich zakres pozostaje jasny.
Po trzecie, warto obserwować, czy organizacje czynią analizę i przegląd częścią zwykłej działalności. Dalsze używanie ma większe znaczenie niż początkowa decyzja o włączeniu eksportu. Zespoły potrzebują osoby odpowiedzialnej za przegląd ustaleń i decyzję, kiedy zmiana uzasadnia wydanie.
Konkretne dowody wdrożenia opisywałyby, jak problem przeszedł przez ten proces. Wskazywałyby odpowiednich recenzentów, wyjaśniały reakcję zespołu rozwojowego i pokazywały, jak zespół sprawdził późniejsze zachowanie.
Wzmocniłoby to argument, że analiza śladów MLflow przyczynia się do bieżącego utrzymania agentów. Zbiór imponujących zrzutów ekranu bez dalszych działań pozostawiłby korzyść operacyjną mniej potwierdzoną.
Dla deweloperów ogłoszenie stanowi użyteczny moment, by ponownie zastanowić się, co kwalifikuje się jako udane uruchomienie agenta. Poprawnie brzmiąca odpowiedź jest obserwacją. Uzasadniony opis sposobu działania agenta wspiera inny poziom zaufania.
Dla kupujących w przedsiębiorstwach odpowiadająca temu decyzja dotyczy dopasowania do przepływu pracy. Istniejące zasady zarządzania, kompetencje recenzentów i nawyki analityczne powinny wpływać na wybór miejsca docelowego obok natywnej łączności. Najlepszym dowodem jest rozwiązany problem, który rozpoznaje Twój zespół.
Zacznij od zadania agenta, którego niepowodzenie ma znaczenie i którego oczekiwany wynik potrafi wyjaśnić ekspert dziedzinowy. Sprawdź, czy obserwowalność Claude OpenTelemetry ujawnia wystarczającą część wykonania, aby odróżnić problem z pobieraniem informacji od problemu z rozumowaniem lub narzędziem. Następnie zapytaj, czy proponowana korekta poprawia reprezentatywne przypadki bez odrzucania niezbędnej pracy. Zachowaj powiązanie dowodów z pierwotnym zadaniem, zamiast z lepiej przygotowaną demonstracją stworzoną później. Takie podejście nadaje natywnemu śledzeniu konkretny cel i czyni porównania platform bardziej użytecznymi. Gdy agent tworzy odpowiedź, która brzmi poprawnie, czy Twój zespół potrafi wyjaśnić, jakie dowody rozważył, gdzie jego proces zawiódł i dlaczego kolejna wersja zasługuje na większe zaufanie?
