Monitorowanie agentów AWS oddziela jakość od awarii infrastruktury
AWS wprowadził dwuwarstwowy wzorzec monitorowania agentów dla systemu rezerwacji lotniczych złożonego z czterech agentów, mierząc się z awariami, których zwykłe pulpity infrastruktury często nie wykrywają.
Podejście łączy Amazon Bedrock AgentCore Evaluations z AWS DevOps Agent. Jedna warstwa ocenia zachowanie agenta i jakość wyników. Druga bada zasoby chmurowe wspierające to działanie.
To rozdzielenie ma znaczenie, ponieważ agent AI może pozostawać dostępny, jednocześnie udzielając nieistotnych odpowiedzi, wybierając niewłaściwe narzędzie lub błędnie obsługując wieloetapowe zadanie. Z drugiej strony poprawny przepływ pracy agenta może zawieść, gdy przestanie działać usługa zależna, uprawnienie lub ścieżka sieciowa.
AWS faktycznie kwestionuje znany model operacyjny. Zespoły aplikacyjne zwykle traktują opóźnienia, błędy, logi i kondycję zasobów jako główne sygnały niezawodności produkcyjnej. Systemy agentowe wymagają tych sygnałów, ale potrzebują również dowodów na to, czy system podejmował właściwe decyzje.
Wzorzec monitorowania AWS przekuwa to rozróżnienie w przepływ pracy operacyjnej. Ciągła ewaluacja identyfikuje słabe sesje, natomiast autonomiczne badanie śledzi podejrzewane przyczyny infrastrukturalne.
Rezultatem nie jest jeden wszechwiedzący monitor. To podział odpowiedzialności między ocenę jakości a diagnozowanie infrastruktury. Ten podział stanowi główną obietnicę, ale też element, który przedsiębiorstwa muszą dokładnie przetestować.
Monitorowanie agentów AWS obejmuje teraz zachowanie i infrastrukturę
Istotna zmiana polega na tym, że monitorowanie agentów AWS traktuje jakość odpowiedzi i kondycję usługi jako odrębne sygnały produkcyjne.
Przykład wykorzystuje aplikację do rezerwacji lotniczych opartą na czterech agentach. Agent nadzorujący koordynuje wyspecjalizowanych agentów odpowiedzialnych za zadania związane z lotami, użytkownikami i rezerwacjami.
Taka struktura przypomina wiele powstających systemów korporacyjnych. Żądanie klienta trafia przez jeden interfejs, lecz zanim system zwróci odpowiedź, może w nim uczestniczyć kilku agentów i usług.
Agent lotów może pobierać dostępne trasy. Agent użytkownika może uzyskiwać dostęp do informacji o podróżnym. Agent rezerwacji może sfinalizować rezerwację po tym, jak agent nadzorujący wybierze kolejne działanie.
Architektura zwiększa specjalizację, ale rozszerza także powierzchnię awarii. Zły rezultat może wynikać z rozumowania, routingu, kontekstu, wyboru narzędzia, uprawnień, dostępu do danych lub niedostępnej usługi.
Tradycyjne monitorowanie może wskazać, czy żądanie zostało ukończone, ile trwało i który komponent zwrócił błąd. Te pomiary nadal są konieczne, lecz nie odpowiadają na pytanie, czy ukończone zadanie było użyteczne.
AgentCore Evaluations odpowiada na tę lukę behawioralną. Ewaluacja wykorzystuje zdefiniowane kryteria do oceny interakcji, śladów lub sesji agenta, zamiast oceniać wyłącznie dostępność systemu.
AWS przedstawia ewaluację online jako ciągłą część tego przepływu pracy. Zespoły mogą stosować ewaluatory do interakcji produkcyjnych i analizować rozkłady wyników w rzeczywistych sesjach.
Ewaluacja na żądanie zapewnia węższą ścieżkę. Operatorzy mogą wybrać sesję lub ślad do bliższej analizy, gdy wynik, skarga lub incydent wymagają zbadania.
To rozróżnienie daje zespołom dwa użyteczne widoki. Ocena zbiorcza może ujawnić pogarszający się trend, a analiza na poziomie sesji pomaga odtworzyć przebieg jednego słabego wyniku.
Pulpity w przykładzie pokazują podsumowania jakości i rozkłady, a nie prosty wskaźnik zaliczenia lub niezaliczenia. Ma to znaczenie, ponieważ jakość agentów często pogarsza się stopniowo.
Aktualizacja modelu może obniżyć zgodność z instrukcjami bez powodowania błędów aplikacji. Zmodyfikowany prompt może poprawić średnią jakość odpowiedzi, jednocześnie zmniejszając niezawodność jednego ważnego zadania.
Warstwa behawioralna tworzy zatem sygnał, którego samo monitorowanie infrastruktury nie jest w stanie wygenerować. Pyta, czy aplikacja spełniła swoje zamierzone przeznaczenie.
AWS DevOps Agent działa po drugiej stronie tej granicy. Analizuje dane operacyjne i relacje między zasobami, aby badać błędy w obsługującym środowisku AWS.
Przykład łączy to badanie z Amazon CloudWatch, który zbiera telemetrię aplikacyjną i infrastrukturalną. Agent DevOps może wykorzystywać te sygnały do zbudowania topologii i prześledzenia podejrzewanej ścieżki awarii.
Ten przepływ pracy przedstawia monitorowanie jako sekwencję. Najpierw wykryj istotny problem z jakością. Następnie ustal, czy infrastruktura się do niego przyczyniła. Potem przygotuj dowody i proponowane działania naprawcze do oceny przez człowieka.
To połączenie nie eliminuje istniejących praktyk obserwowalności. Dodaje ponad nimi ewaluację behawioralną oraz agenta dochodzeniowego działającego w ich obrębie.
Dla zespołów platformowych zmienia to minimalny standard produkcyjny. Zielony pulpit usługi nie oznacza już, że agent wykonał swoje faktyczne zadanie.
Czterech agentów tworzy więcej ścieżek awarii, niż pokazuje jeden pulpit
Wieloagentowy przepływ rezerwacyjny zamienia jedno żądanie użytkownika w łańcuch, w którym najsłabsza decyzja może przesądzić o końcowym wyniku.
Przykład linii lotniczych konkretyzuje problem operacyjny. Agent nadzorujący otrzymuje żądanie i kieruje pracę między trzema wyspecjalizowanymi agentami.
Taka hierarchia może ograniczać zakres odpowiedzialności każdego agenta. Oznacza jednak również, że końcowa odpowiedź zależy od skutecznej koordynacji przez kilka granic rozumowania i usług.
Załóżmy, że podróżny prosi o zmianę rezerwacji. Agent nadzorujący musi rozpoznać żądanie, zachować istotny kontekst, wybrać właściwego specjalistę i przekazać odpowiednie instrukcje.
Specjalista musi następnie wywołać właściwe narzędzie z prawidłowymi parametrami. Musi poprawnie zinterpretować wynik i zwrócić wystarczającą ilość informacji, aby agent nadzorujący mógł kontynuować.
Technicznie udane wywołanie nadal może skutkować złym doświadczeniem klienta. System może pobrać loty, lecz zignorować ograniczenie dotyczące daty podane wcześniej w rozmowie.
Może skontaktować się z właściwą usługą rezerwacyjną, używając błędnego identyfikatora pasażera. Może też wygenerować wiarygodnie wyglądające potwierdzenie bez wykonania podstawowego działania.
Żaden z tych rezultatów nie musi powodować wysokiego użycia CPU ani oczywistego błędu serwera. Niektóre mogą nawet zwracać zwykłe kody statusu i akceptowalne opóźnienia.
Dlatego ewaluacja agentów potrzebuje śladów, które rejestrują kroki podjęte podczas interakcji. Ślad może połączyć końcową odpowiedź z wyborami routingu, wywołaniami modelu, aktywnością narzędzi i usługami wspierającymi.
OpenTelemetry rozwija konwencje dla generatywnej AI służące do opisywania aktywności modeli i agentów za pomocą ustandaryzowanej telemetrii. Ten wysiłek pokazuje, dlaczego zwykłe pola aplikacyjne są niewystarczające dla przepływów pracy agentów.
Projekt linii lotniczych ujawnia także drugi problem. Niska jakość i awaria infrastruktury mogą z perspektywy użytkownika dawać podobne objawy.
Narzędzie rezerwacyjne może przekroczyć limit czasu, ponieważ jego usługa jest niedostępna. Alternatywnie agent może w ogóle nie wywołać tego narzędzia, ponieważ źle zrozumiał żądanie.
Użytkownik widzi jedynie, że rezerwacja się nie powiodła. Zespół operacyjny musi ustalić, która klasa awarii wystąpiła, zanim wybierze środek zaradczy.
To ustalenie wywiera presję na kilka zespołów jednocześnie. Inżynierowie AI odpowiadają za prompty, kryteria ewaluacji i orkiestrację agentów. Inżynierowie platformowi odpowiadają za środowiska uruchomieniowe, uprawnienia, telemetrię i usługi zależne.
Właściciele aplikacji nadal odpowiadają za rezultat dla klienta. Zespoły bezpieczeństwa mogą kontrolować tożsamości i polityki umożliwiające jednemu agentowi dostęp do innego zasobu.
Konwencjonalny alert może skierować wszystkie te zespoły na ten sam kanał incydentowy, nie ustalając miejsca, w którym rozpoczęła się awaria. Sprzyja to ręcznemu przeszukiwaniu logów i konkurującym hipotezom.
Dwuwarstwowy projekt AWS próbuje zapewnić lepszy punkt wyjścia. Niski wynik jakości wskazuje zachowanie warte zbadania, natomiast analiza infrastruktury testuje jedną kategorię przyczyn.
Podejście jest najcenniejsze, gdy zespoły zachowują związek między wynikami ewaluacji a śladami operacyjnymi. Bez tego połączenia otrzymują jedynie dwa niezależne strumienie alertów.
Ciągłość śladów jest szczególnie ważna w asynchronicznych lub rozproszonych przepływach pracy. Pierwotne żądanie użytkownika może przejść przez kilka procesów, zanim działanie zostanie ukończone.
Każde przekazanie wymaga stabilnego identyfikatora i użytecznych atrybutów. W przeciwnym razie osoby prowadzące dochodzenie nie mogą wiarygodnie połączyć nisko ocenionej sesji z dokładnymi zdarzeniami infrastrukturalnymi, które ją obsługiwały.
W tym miejscu architektura staje się czymś więcej niż demonstracją produktu. Definiuje kontrakt odpowiedzialności dla agentów produkcyjnych.
Warstwa ewaluacji wskazuje, czy system zachował się akceptowalnie. Warstwa obserwowalności pokazuje, co się wydarzyło. Warstwa dochodzeniowa proponuje, dlaczego infrastruktura zachowała się w ten sposób.
Ludzie nadal muszą zdecydować, czy dowody są wystarczające. Decydują też, czy rozwiązanie należy wprowadzić w prompcie, ewaluatorze, usłudze, polityce czy potoku danych.
Rzeczywistym mechanizmem jest przekazanie między dwoma dochodzeniami
Projekt AWS działa tylko wtedy, gdy ocena jakości przekazuje osobom prowadzącym dochodzenie konkretną sesję, ślad i przedział czasu do zbadania.
AgentCore Evaluations nie jest po prostu kolejną kontrolą kondycji. Stosuje ewaluatory, czyli reguły oceniania lub sędziów opartych na modelach, do interakcji agenta.
Ewaluator potrzebuje zdefiniowanego celu. W zależności od implementacji cel ten może obejmować ukończenie zadania, trafność, poprawność, pomocność lub inne kryterium specyficzne dla działalności.
Ciągła ewaluacja może ujawniać wzorce w ruchu produkcyjnym. Zespoły mogą sprawdzać, czy wyniki zmieniły się po korekcie promptu, zmianie modelu, aktualizacji narzędzia lub wdrożeniu.
Ścieżka online jest przydatna do wykrywania. Przekształca próbkowane interakcje produkcyjne w sygnał jakości, którego trend operatorzy mogą śledzić w czasie.
Ścieżka na żądanie wspiera diagnozowanie. Operator może ocenić wybrany ślad lub sesję po wykryciu nietypowego rezultatu.
Przykład AWS pokazuje także wspomaganą przez AI analizę wzorców dla nisko ocenianych sesji. Przedstawia rekomendacje dotyczące poprawy promptów jako możliwą odpowiedź na zebrane dowody.
Taka rekomendacja pozostaje hipotezą. Sugerowany prompt może rozwiązać problem niejasnych instrukcji, ale nie naprawi uszkodzonego uprawnienia ani niedostępnej zależności.
Kolejne przekazanie ma zatem znaczenie. Gdy dowody wskazują na błąd operacyjny, AWS DevOps Agent bada odpowiednie środowisko chmurowe.
Jego rola jest szersza niż podsumowanie pojedynczej linii logu. Zaprezentowany interfejs buduje graf topologii, analizuje dane CloudWatch i śledzi ścieżkę związaną z awarią.
Topologia ma znaczenie, ponieważ nowoczesne aplikacje agentowe rzadko działają jako pojedynczy, odizolowany proces. Zależą od środowisk uruchomieniowych, API, kontroli tożsamości, magazynów danych i ścieżek sieciowych.
Agent DevOps następnie przedstawia zidentyfikowaną przyczynę źródłową i prześledzoną ścieżkę awarii. Oferuje także kroki zapobiegawcze lub naprawcze do rozważenia.
Ta sekwencja odzwierciedla przepływ pracy doświadczonego osoby reagującej na incydenty. Ustalenie dotkniętej ścieżki, zebranie skorelowanych sygnałów, przetestowanie możliwych przyczyn i zarekomendowanie odpowiedzi.
Automatyzacja zmienia szybkość i zakres takiego dochodzenia. Nie zmienia potrzeby walidacji wniosku względem źródłowej telemetrii.
Mechanizm dwuwarstwowy jest najsilniejszy, gdy pierwszy system zawęża obszar poszukiwań drugiego. Niski wynik bez kontekstu śladu pozostawia agentowi infrastrukturalnemu zbyt dużą niejednoznaczność.
Odwrotna sytuacja również jest możliwa. Anomalia zasobów bez sygnału jakości może nie mieć żadnego istotnego wpływu na użytkowników.
Tworzy to praktyczny proces monitorowania:
Wyposażenie każdego przekazania między agentami i narzędziami w identyfikatory umożliwiające śledzenie.
Ocena interakcji produkcyjnych według jasno określonych kryteriów jakości.
Wykrywanie niskich wyników, zmian wyników lub powtarzających się wzorców błędów.
Analiza dotkniętej sesji i trajektorii działania jej agenta.
Eskalowanie podejrzewanych przyczyn infrastrukturalnych do autonomicznego zbadania.
Przegląd dowodów przed zmianą zachowania środowiska produkcyjnego.
ponowne uruchomienie ocen po wdrożeniu naprawy, aby zmierzyć rezultat.
Ostatni krok zamyka cykl życia. Naprawa jest niepełna, dopóki zespoły nie wykażą, że poprawiła docelowe zachowanie bez pogorszenia innego zadania.
Ta zasada dotyczy zmian w promptach w takim samym stopniu jak zmian infrastrukturalnych. Zmieniona instrukcja dla nadzorcy może naprawić kierowanie spraw dotyczących anulowania, ale osłabić kierowanie nowych rezerwacji.
Zbiory ewaluacyjne powinny zatem obejmować reprezentatywne zadania i ważne przypadki brzegowe. Próbkowanie produkcyjne może ujawnić nieoczekiwane zachowania, a kontrolowane zestawy testów regresyjnych chronią znane wymagania.
Szersza dokumentacja AgentCore firmy Amazon opisuje zbiór usług do wdrażania i obsługi agentów. Ewaluacje należą do tego szerszego środowiska operacyjnego.
Architektura opiera się również na CloudWatch jako fundamencie telemetrii. Wskazówki AWS dotyczące obserwowalności obejmują metryki, logi, alarmy i ślady wykorzystywane do zrozumienia aplikacji i zasobów.
Te fundamenty wyjaśniają podział produktu. AgentCore koncentruje się na zachowaniu systemu agentowego, podczas gdy analiza DevOps skupia się na środowisku, w którym to zachowanie działa.
Ten podział jest użyteczny, ale tworzy obowiązek integracyjny. Zespoły potrzebują spójnego kontekstu śledzenia, kontroli dostępu, zasad retencji i reguł eskalacji w obu warstwach.
Bez tych mechanizmów autonomiczna analiza może tworzyć dopracowane wyjaśnienia, które nadal trudno audytować. Mechanizm działa wtedy, gdy każdy wniosek prowadzi z powrotem do obserwowalnych dowodów.
Wyniki ewaluacji mogą tworzyć własne martwe punkty
Największa niepewność nie dotyczy tego, czy AWS potrafi obliczyć wynik, lecz tego, czy wynik ten reprezentuje rezultat, który firma faktycznie ceni.
Metryka ewaluacyjna jest skondensowaną oceną. Przekształca złożoną interakcję w etykietę, kategorię lub liczbę, którą zespoły mogą monitorować.
To uproszczenie ułatwia zarządzanie operacjami. Może jednak również ukrywać różnice zdań co do tego, czym jest sukces.
Asystent rezerwacyjny może otrzymać wysoką ocenę trafności, jednocześnie naruszając zasadę taryfową. Może brzmieć pomocnie, lecz nie zachować wybranego przez pasażera miejsca.
Ogólny ewaluator może nagrodzić zwięzłą odpowiedź, która pomija istotne ostrzeżenie. Inny ewaluator może ukarać poprawną odpowiedź, ponieważ oczekiwane sformułowanie jest zbyt wąskie.
Sędziowie oparci na modelach wprowadzają dodatkową niepewność. Ich oceny mogą się różnić zależnie od modelu oceniającego, instrukcji, kontekstu i przykładów użytych do zdefiniowania rubryki.
Zespoły muszą więc walidować ewaluatory na przypadkach zweryfikowanych przez ludzi. Powinny mierzyć rozbieżności, analizować fałszywie pozytywne wyniki i śledzić fałszywie negatywne wyniki dla zadań o dużym wpływie.
Progi również wymagają kontekstu. Niewielki spadek średniego wyniku może odzwierciedlać rzeczywistą regresję, nową strukturę ruchu lub zwykłą zmienność oceniania.
Agregaty mogą ukrywać skoncentrowane szkody. Asystent linii lotniczych może działać dobrze ogólnie, jednocześnie nieproporcjonalnie często zawodzić przy zmianach międzynarodowych lub skomplikowanych planach podróży rodzinnych.
Próbkowanie tworzy kolejny martwy punkt. Ciągła ewaluacja jest przydatna operacyjnie, ale zespoły mogą nie oceniać każdej interakcji każdym ewaluatorem.
Wybrana próbka musi obejmować wartościowe, ryzykowne i rzadkie procesy. W przeciwnym razie pulpity będą faworyzować najczęściej obserwowane, typowe żądania.
Przykład AWS przedstawia architekturę, a nie niezależny dowód, że takie połączenie wykrywa każdą klasę błędów. Organizacje nadal muszą testować je na własnych incydentach.
Analiza infrastruktury ma podobne ograniczenia. Korelacja logów i relacji między zasobami może wskazać przekonującą ścieżkę awarii, nie ustanawiając jedynej możliwej przyczyny.
Niepełna telemetria może zniekształcić analizę. Brakujący segment śladu, niespójny znacznik czasu lub nieobecny atrybut aplikacji mogą sprawić, że odpowiedzialny będzie wyglądał niewłaściwy komponent.
Projekt dostępu również wpływa na widoczność. Agent dochodzeniowy potrzebuje wystarczających uprawnień do sprawdzania istotnych zasobów, lecz nieograniczony dostęp tworzyłby niepotrzebne ryzyko bezpieczeństwa.
Przedsiębiorstwa powinny przyznawać dostęp do odczytu w wąskim zakresie i rejestrować zapytania agenta. Każde zautomatyzowane działanie naprawcze zasługuje na silniejsze zabezpieczenia niż dochodzenie.
Profil ryzyka AI NIST podkreśla znaczenie pomiarów, monitorowania, dokumentacji i nadzoru człowieka w systemach generatywnej AI. Te praktyki pozostają istotne, gdy AI ocenia lub bada inny system AI.
Najbardziej możliwe do obrony wdrożenie oddziela diagnozę od wykonania. Niech system zbiera dowody i rekomenduje działania, a następnie wymagaj zatwierdzenia dla istotnych zmian produkcyjnych.
Ta granica powinna odzwierciedlać możliwy wpływ. Restart bezstanowej usługi deweloperskiej różni się od zmiany polityki tożsamości lub modyfikacji procesu rezerwacyjnego.
Zespoły muszą także zarządzać wrażliwymi danymi zawartymi w śladach. Sesje agentów mogą zawierać dane klientów, informacje o rezerwacjach, argumenty narzędzi lub wyniki modeli.
Procesy ewaluacji i obserwowalności powinny minimalizować niepotrzebną zawartość. Zasady retencji, szyfrowania, dostępu i redakcji muszą obejmować również same dane monitorujące.
Koncentracja na jednym dostawcy stanowi strategiczny kompromis. Przedstawiony wzorzec wykorzystuje usługi AWS w środowisku uruchomieniowym, ewaluacji, telemetrii i badaniu infrastruktury.
Taka integracja może zmniejszyć tarcia operacyjne w przypadku obciążeń już skupionych wokół AWS. Może także utrudnić analizę między chmurami i migrację.
Otwarte formaty telemetrii mogą ograniczyć część zależności. Standaryzowane identyfikatory śladów i pola semantyczne ułatwiają eksport dowodów do istniejących systemów obserwowalności.
Jednak standardowy schemat zdarzeń nie standaryzuje znaczenia ewaluacji. Zespoły nadal muszą definiować jakość w odniesieniu do swojej aplikacji, użytkowników i ryzyk.
Decydujące pytanie nie brzmi więc, czy organizacja ma pulpit ewaluacyjny. Chodzi o to, czy inżynierowie potrafią wyjaśnić, co mierzy każdy wynik i kiedy zawodzi.
Wiarygodny program będzie utrzymywał wersjonowane ewaluatory, porównywał je z ludzkimi ocenami i przeglądał po zmianach w aplikacji.
Będzie również zachowywał surowe dowody wystarczająco długo, aby audytować poważne incydenty. Wyniki powinny kierować uwagę, a nie zastępować podstawowy zapis interakcji.
Agent DevOps AWS wywiera presję na istniejące procesy obserwowalności
Presja konkurencyjna dotyczy w mniejszym stopniu pojedynczego dostawcy monitoringu, a bardziej praktyki oddzielania jakości AI od operacji infrastrukturalnych.
Wiele organizacji już korzysta z monitorowania wydajności aplikacji, scentralizowanego logowania, śledzenia rozproszonego i platform zarządzania incydentami. Systemy te pozostają kluczowe dla operacji produkcyjnych.
Podejście AWS nie czyni ich przestarzałymi. Wskazuje, że ich obecne sygnały potrzebują warstwy jakości specyficznej dla agentów oraz bardziej autonomicznego interfejsu dochodzeniowego.
Dostawcy chmurowi są dobrze przygotowani, by formułować ten argument. Mogą uzyskiwać dostęp do relacji między usługami, natywnej telemetrii, kontekstu tożsamości i metadanych wdrożeniowych w ramach swoich platform.
Niezależni dostawcy rozwiązań obserwowalności mają inną przewagę. Często zapewniają jeden widok operacyjny obejmujący wiele chmur, usług, modeli i frameworków aplikacyjnych.
Strategiczna rywalizacja rozgrywa się więc między zintegrowanym kontekstem chmurowym a przenośnym kontekstem operacyjnym. Wzorzec AWS faworyzuje głęboką integrację we własnych usługach.
Stos międzyplatformowy sprzyja spójnemu dochodzeniu, gdy agenci korzystają z kilku dostawców modeli lub działają w różnych środowiskach. Żadna z tych ścieżek nie eliminuje potrzeby ewaluacji specyficznej dla aplikacji.
Platformy do tworzenia agentów również konkurują o warstwę behawioralną. Niektóre oferują śledzenie, zbiory danych, eksperymenty z promptami, ewaluatory i testy regresyjne wokół procesów agentowych.
AWS może połączyć te kwestie bezpośrednio ze swoim zarządzanym środowiskiem uruchomieniowym i usługami operacyjnymi. Wartość zależy od tego, jak płynnie zespoły mogą prześledzić jeden ślad przez każdą granicę.
Ta ciągłość zadecyduje, czy idea dwóch warstw stanie się rutynowym procesem, czy kolejnym zestawem pulpitów. Operatorzy niechętnie przyjmują narzędzia, które zwiększają przełączanie kontekstu podczas incydentów.
Agent DevOps zmienia również oczekiwania wobec reagowania na incydenty. System, który autonomicznie buduje topologię i proponuje przyczynę, może skrócić wstępne dochodzenie.
Może jednak także zwiększyć liczbę alertów, jeśli zespoły uruchamiają dochodzenia na podstawie źle skalibrowanych ewaluacji. Detekcja niskiej jakości będzie przekazywać incydenty niskiej jakości do drugiej warstwy.
To sprawia, że zarządzanie ewaluatorami staje się częścią zarządzania operacyjnego. Zespoły AI nie mogą dostrajać wyników niezależnie od inżynierów otrzymujących ich alerty.
Wspólne runbooki powinny określać, kiedy wynik tworzy zgłoszenie, kiedy rozpoczyna dochodzenie, a kiedy jedynie aktualizuje trend.
Powinny także rozróżniać incydenty jakościowe od infrastrukturalnych. Regresja jakości może wymagać wycofania promptu, wycofania modelu, naprawy narzędzia lub korekty danych.
Incydent infrastrukturalny może wymagać naprawy pojemności, konfiguracji, uprawnień, sieci lub usługi. Niektóre incydenty będą obejmować obie kategorie.
Użyteczna taksonomia zapobiega temu, by każdy niski wynik stawał się awarią chmury. Zapobiega też odrzucaniu każdego przekroczenia limitu czasu jako szumu infrastrukturalnego.
Przykład linii lotniczych z czterema agentami jest wartościowy, ponieważ ujawnia tę niejednoznaczność. Nadzorca może podjąć złą decyzję o kierowaniu, gdy wszystkie usługi są sprawne.
Specjalista może podjąć właściwą decyzję, ale ponieść porażkę, ponieważ jego zależność jest niesprawna. Dla klienta oba rezultaty mogą wyglądać identycznie.
Wkładem AWS jest wyraźny mechanizm rozdzielania tych możliwości. Presja rynkowa wynika z tego twierdzenia operacyjnego.
Dostawcy rozwiązań obserwowalności będą musieli pokazać, w jaki sposób ich platformy oceniają zachowanie agentów, a nie jedynie wyświetlają użycie tokenów i opóźnienia modeli.
Platformy agentowe będą musiały pokazać, jak ich ślady łączą się z dowodami infrastrukturalnymi. Ślad rozumowania, który kończy się na wywołaniu narzędzia, nie może wyjaśnić, co stało się wewnątrz narzędzia.
Nabywcy korporacyjni powinni oceniać pokrycie całego tego łańcucha. Muszą wiedzieć, która warstwa wykrywa awarię, która ją bada i który zespół odpowiada za naprawę.
Powinni również pytać, czy eksportowana telemetria zachowuje wystarczająco dużo znaczenia poza pierwotną platformą. Przenośność wpływa na audyty, przeglądy incydentów i przyszłe decyzje architektoniczne.
Dla zespołów inżynieryjnych intensywnie korzystających z wiedzy przeszukiwalny zapis wcześniejszych incydentów, decyzji i runbooków może uzupełniać telemetrię na żywo. Techniczna baza wiedzy pomaga zachować ludzki kontekst, którego narzędzia monitorujące rzadko rejestrują.
Ten kontekst nie zastępuje śladów. Wyjaśnia, dlaczego istnieją progi, które środki zaradcze wcześniej zawiodły i kto zatwierdził ważne zmiany operacyjne.
Zwycięski proces połączy dowody maszynowe z pamięcią instytucjonalną. Żadna z tych warstw nie wystarcza samodzielnie.
Trzy sygnały pokażą, czy model dwóch warstw działa
Kolejnym sprawdzianem będzie to, czy klienci AWS potrafią przekształcić demonstrację w mierzalne, możliwe do audytowania usprawnienia produkcyjne.
Pierwszym sygnałem jest stabilność ocen w obliczu zmian w aplikacji. Zespoły powinny obserwować, czy wyniki AgentCore pozostają miarodajne po zmianach promptów, modeli, narzędzi i wzorców ruchu.
Stabilność nie oznacza zamrożenia. Oznacza, że zmiany wyników odpowiadają ulepszeniom lub regresjom zweryfikowanym przez ludzi, a nie niewyjaśnionemu dryfowi ewaluatora.
Dowody na powtarzalną kalibrację wzmocniłyby argumentację AWS. Częste zmiany progów bez jasnej walidacji osłabiłyby zaufanie do warstwy behawioralnej.
Drugim sygnałem jest ciągłość śladu od słabego wyniku do ustalenia infrastrukturalnego. Przykład rezerwacji opiera się na przenoszeniu użytecznego kontekstu między supervisorem, wyspecjalizowanymi agentami, narzędziami i zasobami AWS.
Klienci powinni szukać analiz, które zaczynają się od jednej sesji z niską oceną, a kończą konkretną przyczyną potwierdzoną dowodami. Tę ścieżkę powinien móc odtworzyć operator.
Spójne powiązanie śladów wspierałoby model dwuwarstwowy. Brakujące segmenty śledzenia i słaba korelacja sprawiłyby, że zespoły nadal wykonywałyby te same ręczne wyszukiwania, tylko za nowym interfejsem.
Trzecim sygnałem jest odsetek zaakceptowanych rekomendacji naprawczych. AWS DevOps Agent może przedstawić narrację dotyczącą przyczyny źródłowej i kroki zapobiegawcze, ale operatorzy muszą zdecydować, czy te rekomendacje są poprawne.
Zespoły powinny śledzić, jak często inżynierowie akceptują, modyfikują lub odrzucają proponowane działania. Powinny również mierzyć, czy zaakceptowane zmiany zapobiegają powtórzeniu problemu bez powodowania nowych awarii jakości.
Sama wysoka akceptacja nie wystarczy. Lepsza miara łączy dokładność, oszczędność czasu, częstotliwość nawrotów oraz wyniki ewaluacji po zmianach.
Sygnały te powinny pojawiać się w przeglądach operacyjnych, a nie w demonstracjach promocyjnych. Dowody z produkcji pokażą, czy autonomiczne dochodzenie skraca czas trwania incydentów, czy jedynie przyspiesza sformułowanie pierwszej hipotezy.
Organizacje wdrażające ten wzorzec powinny zacząć od ograniczonych workflowów. Wyszukiwanie rezerwacji wiąże się z mniejszym ryzykiem niż nieodwracalne działanie, takie jak dokonanie rezerwacji lub płatności.
Mogą zdefiniować niewielki zestaw wyników biznesowych, stworzyć przypadki ewaluacyjne poddawane przeglądowi przez ludzi i zinstrumentować każde przekazanie. Następnie mogą połączyć niskie oceny z prowadzonymi tylko do odczytu analizami infrastruktury.
Takie etapowe podejście dostarcza dowodów przed przyznaniem szerszych uprawnień. Ujawnia też brakującą telemetrię i słabe kryteria ewaluacji, gdy wpływ pozostaje ograniczony.
Zespoły powinny dokumentować związek między każdym ewaluatorem a wynikiem dla klienta. Wynik trafności nie powinien zastępować poprawności transakcji.
Powinny także wersjonować razem prompty, ewaluatory, modele, narzędzia i runbooki. W przeciwnym razie przegląd incydentu nie będzie mógł odtworzyć, jakie założenia operacyjne obowiązywały w danym momencie.
Monitorowanie agentów AWS oferuje użyteczną odpowiedź na coraz bardziej widoczny problem. Agent może być dostępny, szybki i błędny, podczas gdy infrastruktura pod tym samym objawem może być zdrowa albo uszkodzona.
AgentCore Evaluations i AWS DevOps Agent dzielą ten problem na pomiar zachowania i dochodzenie operacyjne. Ten projekt jest wiarygodny, ponieważ każda warstwa odpowiada na inne pytanie.
Jego powodzenie będzie zależało od przekazania między nimi. Czy niska ocena może prowadzić do właściwego śladu, właściwych dowodów infrastrukturalnych i zweryfikowanej poprawy?
To pytanie, które zespoły korporacyjne powinny przetestować w następnej kolejności. Zacznij od jednego istotnego workflowu, zdefiniuj, co oznacza sukces, i sprawdź, czy te dwie warstwy prowadzą do jaśniejszej decyzji niż obecny proces obsługi incydentów.
