Oceny Amazon AgentCore mierzą się z porażką, której nie wykrywa tradycyjny monitoring
Amazon opublikował dziewięcioetapowy schemat ocen Amazon AgentCore po odkryciu, że sprawna infrastruktura może skrywać pogarszającą się jakość odpowiedzi agentów. Opóźnienia mogą pozostawać normalne. Wskaźniki błędów mogą być stabilne. Agent wciąż odpowiada, lecz jego pewna siebie odpowiedź może wskazywać błędną liczbę lub niewłaściwego klienta.
Ten konflikt ma znaczenie, ponieważ tradycyjny monitoring wykrywa głównie awarie oprogramowania pozostawiające widoczne ślady techniczne. Autonomiczni agenci wprowadzają awarie semantyczne: aplikacja działa, ale jej rozumowanie, wybór narzędzi lub wnioski stają się mniej wiarygodne.
AWS zbudowało ten schemat wokół wewnętrznego systemu wieloagentowego używanego przez sprzedawców i liderów sprzedaży. Wyspecjalizowani agenci odpowiadają na pytania dotyczące wyników, klientów i danych strukturalnych za pośrednictwem wspólnego interfejsu konwersacyjnego. Jedno zdegradowane narzędzie lub podagent może zanieczyścić końcową odpowiedź bez powodowania awarii aplikacji.
Schemat oznacza przejście od oceniania agenta przed uruchomieniem do ciągłej oceny jego zachowania. Łączy eksperymenty rozwojowe, bramki wdrożeniowe, kanarki produkcyjne, kontrole adversarialne, wykrywanie dryfu, obserwowalność i automatyczne rekomendacje.
Prawdziwym przeciwnikiem nie jest inny dostawca chmury. Jest nim znane założenie, że czas dostępności, opóźnienia i udane żądania dostarczają wystarczających dowodów na zdrowie agenta. Przypadek Amazona pokazuje, że te sygnały opisują dostępność, a nie poprawność.
Oceny Amazon AgentCore czynią jakość warunkiem wydania
Istotna zmiana polega na tym, że AWS traktuje jakość odpowiedzi jako kontrolę operacyjną, a nie końcowy etap testów.
AWS opublikowało schemat 16 października 2026 roku, w oparciu o pracę z wewnętrznym systemem produkcyjnym. System obejmuje agentów Performance Insights, Customer Insights i Data Insights, obsługujących różne pytania biznesowe.
Agent Performance Insights obsługuje pytania dotyczące przychodów i wyników w obrębie określonego terytorium. Agent Customer Insights łączy sygnały dotyczące użycia produktów, wsparcia, umów i zaangażowania. Agent Data Insights przekształca pytania zadawane językiem naturalnym w zapytania SQL do ustrukturyzowanych zbiorów danych.
Agenci działają za jednym interfejsem, ale obszary ich możliwych awarii pozostają odrębne. Narzędzie do rozpoznawania klientów może wybrać niewłaściwą spółkę zależną. Komponent wyszukiwania może zwrócić słaby kontekst. Orkiestrator może poprawnie skierować żądanie, a następnie zniekształcić ustalenia podagentów podczas syntezy.
AWS ocenia więc system na trzech poziomach. Kontrole na poziomie narzędzi analizują możliwości takie jak wyszukiwanie, rozpoznawanie encji i generowanie SQL. Oceny na poziomie agenta punktują każdego wyspecjalizowanego agenta od żądania do odpowiedzi. Kontrole wieloagentowe oceniają trasowanie, przekazywanie kontekstu i końcową syntezę.
Każdy poziom otrzymuje własny zbiór danych oceny, progi i kryteria promocji. Ta struktura ma znaczenie, ponieważ korzystna średnia end-to-end może ukryć wadliwy komponent. Awaria może dotyczyć tylko jednego segmentu klientów, typu zapytania lub ścieżki orkiestracji.
Schemat mierzy również pięć wymiarów w całym cyklu życia. Są to bezpieczeństwo, jakość, wydajność, koszt i kontrola operacyjna. Jakość otrzymuje najbardziej szczegółowe omówienie, lecz AWS podkreśla, że bezpieczeństwo pozostaje warunkiem wydania.
Dziewięć etapów tworzy zamkniętą pętlę: definiowanie, eksperymentowanie, scalanie, bramka, kanarek, przeciwnik, dryf, puls i ulepszanie. Etapy rozciągają się od pierwszego commitu po monitoring produkcyjny i późniejsze poprawki.
AWS łączy je za pomocą AgentCore Evaluations, które obsługują tryby oceny kontrolowanej i na żywo. Ocena na żądanie działa na wybranych zbiorach danych, śladach lub sesjach. Ocena online stale próbuje interakcje produkcyjne.
Ta ciągłość jest kluczową deklaracją produktową. Zespół może stosować te same ewaluatory przed wdrożeniem i po zetknięciu się użytkowników z agentem. Standard oceny nie powinien się zmieniać tylko dlatego, że oprogramowanie przekroczyło granicę środowiska produkcyjnego.
AWS łączy także AgentCore z CloudWatch, S3, Redshift, Lambda i Amazon Quick. Usługi te obsługują ślady, wyniki ewaluatorów, trwałe przechowywanie, własne punktowanie, alarmy i dashboardy.
Nie jest to nowy model podstawowy ani architektura agenta. To model operacyjny służący do decydowania, czy agent nadal nadaje się do użycia. Ta węższa zmiana może okazać się bardziej znacząca dla przedsiębiorstw wychodzących poza demonstracje.
Dziewięcioetapowy schemat rozpoczyna się przed pierwszym uruchomieniem testu
Schemat Amazona zaczyna się od zdefiniowania awarii w kategoriach biznesowych, ponieważ niezdefiniowany cel jakościowy czyni każdą późniejszą bramkę arbitralną.
Etap pierwszy ustanawia kontrakt oceny. Zespoły definiują wyniki biznesowe, metryki oceny, progi awarii, zasady bezpieczeństwa, budżety opóźnień, cele kosztowe i reakcje operacyjne.
Dla sprzedawców AWS sukces oznacza otrzymywanie aktualnych i dokładnych informacji o klientach na odpowiednim poziomie szczegółowości. Użytkownicy z kierownictwa potrzebują wiarygodnych danych wejściowych do cotygodniowych i międzyobszarowych przeglądów bez rozległych ręcznych przygotowań.
Te wyniki są następnie przekładane na mierzalne kategorie awarii. AWS wskazuje zamiany metryk, niewłaściwe okresy, niewłaściwe encje, niepotwierdzone wartości, niepoprawne symbole i nieautoryzowane obliczenia.
Ta taksonomia jest bardziej praktyczna niż jeden ogólny wynik dokładności. Spadający wskaźnik zaliczeń mówi, że coś się zmieniło. Wynik na poziomie kategorii wskazuje, czy problem leży w wyszukiwaniu, rozpoznawaniu encji, interpretacji czasu, formatowaniu czy generowanym rozumowaniu.
AWS łączy kilka rodzajów ewaluatorów, ponieważ żadna pojedyncza metoda punktacji nie obejmuje każdego ryzyka. Wbudowane ewaluatory oceniają trafność, zgodność z faktami, pomocność, przestrzeganie instrukcji i wybór narzędzi. Dostosowane ewaluatory są ukierunkowane na błędy specyficzne dla domeny.
Kontrole deterministyczne porównują wyniki z dokładnie oczekiwanym rezultatem. Nadają się do identyfikatorów kont, dat umów, wartości przychodów, wyników SQL i ustrukturyzowanych formatów. Ocena LLM-as-a-judge wykorzystuje model i rubrykę, gdy kilka odpowiedzi może rozsądnie spełniać żądanie.
To rozróżnienie jest kluczowe. Proszenie innego modelu o weryfikację dokładnego identyfikatora dodaje niepewności tam, gdzie lepiej sprawdziłoby się proste porównanie. Stosowanie dokładnego dopasowania ciągów do oceny zniuansowanego rozumowania tworzy problem odwrotny.
AWS korzysta także z bibliotek ewaluatorów zewnętrznych firm oraz złotego zbioru, czyli wersjonowanej kolekcji reprezentatywnych zapytań z oczekiwanym zachowaniem. Zbiór obejmuje przykłady pochodzące z produkcji, awarie z poprzednich wydań i skonstruowane przypadki brzegowe.
Na poziomie narzędzi złoty zbiór testuje możliwości takie jak identyfikacja klienta. Na poziomie agenta AWS uwzględnia pytania kompleksowe, raportowe, wymagające rozumowania i niejednoznaczne. Awarie produkcyjne mogą stać się trwałymi przypadkami regresji.
Etap drugi porównuje proponowane zmiany z tym samym kontraktem oceny. Zmiany promptów, wymiany modeli, dodawanie narzędzi i aktualizacje zbiorów danych przechodzą ocenę na żądanie przed scaleniem.
Porównanie obejmuje jakość, opóźnienia, koszt i zużycie tokenów. Kandydat, który zwiększa dokładność przy jednoczesnym znacznym wzroście czasu odpowiedzi i kosztu, nie wygrywa automatycznie. Schemat wymusza uwzględnienie tych kompromisów w rejestrze decyzji.
AWS podaje, że trzy miesiące ukierunkowanych iteracji podniosły wskaźnik zaliczeń z 93 procent do 96 procent. Firma twierdzi także, że czyste halucynacje spadły ze 138 do mniej niż 52 na 10 000 odpowiedzi.
Nieautoryzowane obliczenia miały podobno spaść z 59 do mniej niż 44 na 10 000 odpowiedzi. Liczby te pochodzą z wewnętrznych danych AWS i nie zostały poddane niezależnemu audytowi.
To zastrzeżenie jest istotne, ponieważ źródło jest jednocześnie technicznym studium przypadku i argumentem produktowym. Wyniki pokazują, co AWS twierdzi, że osiągnęło w jednym środowisku. Nie ustanawiają uniwersalnego punktu odniesienia dla niezawodności agentów.
Mimo to projekt oceny pozostaje użyteczny poza AWS. Zespoły potrzebują wspólnej definicji akceptowalnego zachowania, zanim będą mogły porównywać prompty, modele, systemy wyszukiwania lub zmiany orkiestracji.
Dokumentowanie tego kontraktu tworzy również pamięć organizacyjną. Zespoły korzystające z przeszukiwalnej bazy wiedzy inżynierskiej mogą przechowywać definicje awarii, decyzje dotyczące oceny i dowody incydentów obok notatek implementacyjnych.
Bramki CI i kanarki atakują różne okna awarii
Bramki przed wydaniem zatrzymują znane regresje, podczas gdy kanarki produkcyjne szukają pogorszenia, którego nie wywołało żadne wdrożenie.
Etap trzeci umieszcza mniejszy zbiór wartowniczy w ciągłej integracji. AWS uruchamia ten zestaw automatycznie po wdrożeniach na środowisku staging, w tym po zmianach kodu, promptów, modeli, narzędzi lub konfiguracji.
Zbiór wartowniczy akcentuje scenariusze wysokiego ryzyka dotyczące jakości, bezpieczeństwa, opóźnień i kosztu. Działa szybciej niż pełny złoty zbiór, dzięki czemu nadaje się do częstych kontroli. Przekroczony próg może zablokować wdrożenie.
AWS utrzymuje odrębne zestawy wartownicze dla narzędzi, agentów i przepływów wieloagentowych. Wydanie nie może przejść wyłącznie dlatego, że końcowy wynik agenta wygląda akceptowalnie. Regresja w krytycznym narzędziu może niezależnie zatrzymać promocję.
Firma opisuje zmianę normalizacji danych, która wpłynęła na rozpoznawanie nazw klientów. Narzędzie zwracało nierozpoznane encje dla niektórych formatów, a agent zgadywał pasującego klienta. Takie zachowanie groziło zwróceniem dokładnych danych o niewłaściwym koncie.
Deterministyczny przypadek rozpoznawania encji wykrył problem przed produkcją. Przykład ten pokazuje, dlaczego testowanie agentów musi schodzić poniżej poziomu końcowej prozy. Płynna odpowiedź może wciąż być funkcjonalnie niepoprawna.
Etap czwarty rozszerza kontrolę wydania do pełnej bramki jakości. AWS ocenia kandydata względem kompletnego złotego zbioru i wykorzystuje zamrożone odpowiedzi narzędzi, aby odizolować zachowanie agenta.
Taki projekt odtwarzania usuwa z porównania dostępność działających narzędzi i zmieniające się dane źródłowe. Każdy kandydat otrzymuje te same zweryfikowane wyniki narzędzi. Różnice w punktacji powinny więc odzwierciedlać rozumowanie agenta, a nie zmienność środowiska.
AWS podaje, że jego bramka end-to-end obejmuje 200 pytań wstrzymanych na potrzeby oceny. Kandydat nie przechodzi, jeśli jego wynik zbiorczy ulegnie regresji, nie osiągnie poziomu bazowego produkcji albo pozostawi zbyt wiele pojedynczych pytań poniżej progu.
Ten ostatni warunek zapobiega ukrywaniu skoncentrowanej szkody przez średnie. Model może poprawić odpowiedzi na częste pytania, a jednocześnie stać się niewiarygodny dla jednego regionu, typu klienta lub formatu żądania.
Etap piąty zmienia środowisko. Kanarek działa w produkcji na ruchu na żywo i syntetycznych przypadkach, szukając awarii wywołanych przez zewnętrzne zależności lub zmiany danych.
AWS wybrało 30-minutowe okna oceny. Firma twierdzi, że 15-minutowe okna generowały nadmierną liczbę fałszywych alarmów, podczas gdy 60-minutowe opóźniały potwierdzenie rzeczywistego spadku.
Jedno nieudane okno nadal pozostaje sygnałem operacyjnym. AWS powiadamia zespół dyżurny dopiero po przekroczeniu progu w trzech kolejnych oknach. Oddzielne codzienne uruchomienie ocenia cały złoty zbiór według progów bramki wydania.
Ten projekt próbuje równoważyć czułość i zmęczenie alarmami. Kanarek powinien wykrywać trwałą utratę jakości bez uczenia inżynierów ignorowania hałaśliwych powiadomień.
AWS podaje przykład odświeżenia indeksu wyszukiwania. Odświeżone narzędzie zwracało ogólnie powiązane fragmenty zamiast precyzyjnego kontekstu wymaganego przez pytanie.
Metryki infrastruktury wyglądały normalnie. Opóźnienia pozostawały w oczekiwanym zakresie, a wskaźnik błędów technicznych utrzymywał się na poziomie zero. Agent nadal generował dopracowane odpowiedzi oparte na słabszych dowodach.
Kanarek wykrył niższy poziom ugruntowania odpowiedzi i precyzji wyszukiwania podczas pierwszego okna ewaluacyjnego. Ślad wykonania połączył następnie niski wynik z narzędziem wyszukiwania.
To kluczowe odwrócenie perspektywy w tym modelu. Udane żądanie może oznaczać porażkę produktu, a technicznie zdrowa zależność może mimo to obniżać jakość odpowiedzi.
Oddzielna implementacja AWS i Motorway stanowi kolejny konkretny punkt odniesienia. Jej plan produkcyjny wskazuje, że liczba nieprawidłowych wyników wyszukiwania spadła z jednego na osiem zapytań do jednego na 50.
Agent Motorway pomaga dealerom przeszukiwać ofertę pojazdów za pomocą języka naturalnego. Jego potok ewaluacyjny sprawdza użycie narzędzi, rozumowanie i jakość wyników w powtarzanych uruchomieniach. AWS twierdzi, że czas wykrywania problemów skrócił się z godzin do minut.
Te dwa przypadki nie są bezpośrednio porównywalne. Dotyczą różnych użytkowników, zbiorów danych, definicji awarii i architektur. Łącznie pokazują jednak, dlaczego testowanie wydań i ewaluacja produkcyjna rozwiązują odrębne problemy.
Ewaluacja na żywo ujawnia ograniczenia statycznych zestawów testowych
Złoty zestaw chroni przed zapamiętanymi awariami, lecz prawdziwi użytkownicy stale dostarczają dane wejściowe, których jego twórcy nie przewidzieli.
Etap szósty dotyczy zachowań adversarialnych. AWS stosuje mechanizmy kontroli wejść i wyjść, aby filtrować żądania, chronić dane wrażliwe i wykrywać próby manipulowania instrukcjami agenta.
Model wykorzystuje Bedrock Guardrails do filtrowania treści i wykrywania ataków na prompty. AWS twierdzi, że kontrole te synchronicznie obejmują cały ruch, zanim odpowiedź dotrze do użytkownika.
Model zagrożeń obejmuje bezpośrednie próby jailbreaku oraz instrukcje ukryte w pobranych dokumentach. Uwzględnia także próby wyodrębnienia wewnętrznych promptów lub ujawnienia danych poza zakresem uprawnień użytkownika.
AWS słusznie zauważa, że bezpieczeństwo nie ogranicza się do jednego etapu. Zasady są definiowane na poziomie fundamentów, testowane podczas integracji i wdrożenia, a następnie egzekwowane w produkcji. Etap szósty wyraźnie wskazuje warstwę ochrony przed zachowaniami adversarialnymi.
Etap siódmy koncentruje się na dryfie, czyli utrzymującej się zmianie zachowania względem ustalonego punktu odniesienia. Dryf może wynikać z aktualizacji danych, zmieniających się zachowań użytkowników, nieaktualnych założeń lub rzadkich żądań nieuwzględnionych w złotym zestawie.
AWS twierdzi, że próbuje 10 procent ruchu na żywo na potrzeby ewaluacji online. Wyniki jakości, opóźnień i kosztów zasilają obliczenie stanu jakości przy użyciu tej samej struktury 30-minutowych okien.
Jeden z wewnętrznych przykładów dotyczył identyfikacji klientów. Testy syntetyczne obejmowały warianty nazw, spółki zależne i skróty. Użytkownicy na żywo podawali również symbole giełdowe, skrócone nazwy i błędy typograficzne.
Raportowana dokładność spadła z 98 procent w jednym oknie do 81 procent, a następnie do 80 procent w dwóch kolejnych oknach. CloudWatch zaalarmował zespół dyżurny po przekroczeniu kroczącego progu.
AWS twierdzi, że ślady ujawniły obsługę tickerów i skróconych nazw jako główne źródło błędu. Zespół zaktualizował logikę normalizacji i przeniósł sesje z niskimi wynikami do złotego zestawu.
Według doniesień dokładność wróciła do poziomu bazowego w następnym cyklu ewaluacyjnym. Ponownie jest to zgłoszony przez AWS wynik operacyjny, a nie niezależnie odtworzone ustalenie.
Etap siódmy wspiera także kontrolowaną ekspozycję na ruch na żywo. Po przejściu przez kandydata bramki offline brama kieruje część żądań między obecną a proponowaną wersją.
Kandydat musi dorównać wersji produkcyjnej lub ją przewyższyć w wybranych wymiarach. Ewaluacja offline testuje znane przypadki, natomiast porównanie na żywo wprowadza nieznane sformułowania i zachowania.
Proces ten przypomina ugruntowane kanarki programistyczne i monitorowanie modeli, lecz agenci poszerzają zakres mierzonego obiektu. Zespoły muszą oceniać trajektorie, wywołania narzędzi, pobrany kontekst, końcowe odpowiedzi i wyniki sesji.
Szerszy zakres tworzy problem pomiarowy. Sędziowie oparci na LLM mogą się nie zgadzać, przejmować uprzedzenia modeli lub nagradzać cechy stylistyczne, które nie odzwierciedlają poprawności biznesowej. Rubryki mogą również się zdezaktualizować wraz ze zmianą produktów i użytkowników.
Próbkowanie wprowadza kolejne ograniczenie. Ewaluacja 10 procent ruchu obniża koszty przetwarzania, lecz rzadkie i szkodliwe awarie mogą nie trafić do próbki. Wyniki zbiorcze mogą też ukrywać grupy użytkowników o małej liczebności.
Prywatność i zarządzanie danymi wymagają równie dużej uwagi. Ślady produkcyjne mogą zawierać prompty, pobrane dokumenty, wyniki narzędzi, identyfikatory kont i inne wrażliwe elementy kontekstu. Kontrole retencji i dostępu muszą odpowiadać charakterowi danych.
Model uwzględnia bezpieczeństwo i kontrolę operacyjną, ale jakość wdrożenia nadal zależy od każdej organizacji. AgentCore zapewnia infrastrukturę ewaluacyjną. Nie może w imieniu klienta definiować akceptowalnego zachowania ani wiarygodnej prawdy referencyjnej.
Czego model Amazon nadal nie potrafi udowodnić
Przypadek Amazon wspiera ciągłą ewaluację, lecz nie dowodzi, że automatyczni ewaluatorzy mogą w pełni mierzyć zaufanie.
Pierwszym ograniczeniem jest niezależność dowodów. Główny model, implementacja i wyniki wydajności pochodzą od AWS. Firma obsługuje system i sprzedaje wspierającą go platformę.
Ta relacja nie unieważnia wyników. Oznacza jednak, że czytelnicy powinni traktować zgłaszane ulepszenia jako ustalenia ze studium przypadku, a nie neutralne benchmarki wobec konkurencyjnych stosów ewaluacyjnych.
Drugie ograniczenie dotyczy trafności ewaluatorów. Wynik jest użyteczny tylko wtedy, gdy koreluje z zachowaniem, które użytkownicy faktycznie cenią. Precyzyjny pulpit może tworzyć fałszywe poczucie pewności, jeśli jego rubryka mierzy niewłaściwy rezultat.
AWS próbuje ograniczyć to ryzyko, zaczynając od celów biznesowych i łącząc deterministyczne, dostosowane oraz oparte na modelach ewaluatory. Zespoły nadal muszą walidować każdego sędziego względem eksperckiej oceny człowieka.
Cennym sygnałem byłaby zgodność między oceniającymi. Jeśli ewaluatorzy, eksperci dziedzinowi i użytkownicy często się nie zgadzają, zautomatyzowany wynik nie powinien samodzielnie kontrolować wdrożeń. Wpis AWS nie przedstawia danych o tej zgodności.
Trzecim ograniczeniem jest pokrycie. Model testuje znane kategorie awarii i z czasem włącza nowe przypadki produkcyjne. Nie może zagwarantować wykrycia każdego nowego zachowania przed wystąpieniem szkody.
Złoty zestaw również może zostać pośrednio zoptymalizowany. Powtarzane zmiany promptów i modeli mogą poprawiać wyniki na znanych przykładach, nie zapewniając szerszej niezawodności. Przypadki odłożone do walidacji i okresowo odświeżane zbiory danych mogą ograniczyć to ryzyko.
Czwartym ograniczeniem jest koszt. Ciągła ewaluacja zwiększa liczbę wywołań modeli, potrzebę przechowywania śladów, przetwarzania danych, pulpitów i pracy inżynierskiej. AWS śledzi koszt na zapytanie i koszt na udaną odpowiedź, ale nie publikuje pełnego kosztu implementacji.
Mniejszy zespół może nie potrzebować od razu wszystkich dziewięciu etapów. Może zacząć od specyficznej dla domeny taksonomii awarii, deterministycznych testów krytycznych faktów, bramki wydania i próbkowanego przeglądu produkcyjnego.
Piątym ograniczeniem są uprawnienia do naprawy. Etap dziewiąty może generować rekomendacje dotyczące promptów systemowych i opisów narzędzi na podstawie nieudanych śladów. Rekomendacje nie są tym samym co bezpieczne, autonomiczne zmiany.
Sugerowana rewizja promptu może naprawić jedną awarię, jednocześnie wprowadzając inną. Powinna przejść przez tę samą sekwencję eksperymentu, scalenia, bramki i kanarka przed szerokim wdrożeniem.
Automatyczny rollback również wymaga ostrożnych granic. Cofnięcie promptu lub modelu jest względnie ograniczone. Odwrócenie działania agenta w systemie biznesowym może dotyczyć płatności, wiadomości, rekordów lub uprawnień.
Te kwestie oddzielają ewaluację od zarządzania. Ewaluacja szacuje, czy agent zachował się właściwie. Zarządzanie określa, co agent może zrobić, jakie dowody należy zachować i gdzie zatwierdzenie człowieka pozostaje obowiązkowe.
Szersze wytyczne AgentOps AWS umieszczają ewaluację obok bezpieczeństwa, wersjonowanych artefaktów, obserwowalności i przeglądu przez człowieka. Takie ujęcie jest bardziej wiarygodne niż traktowanie jednego wyniku jako certyfikatu zaufania.
Zaufanie nie jest właściwością, którą AgentCore może przypisać agentowi. Jest skumulowaną oceną opartą na wynikach, kontrolach, obsłudze incydentów i przejrzystości. Ewaluacja dostarcza dowodów na potrzeby tej oceny.
Dla kupujących właściwe pytanie nie brzmi więc, czy platforma oferuje ewaluacje. Trudniejsze pytanie dotyczy tego, czy jej pomiary obejmują rzeczywiste koszty awarii organizacji i pozostają wiarygodne w warunkach zmian.
Trzy sygnały pokażą, czy zamknięta pętla działa
Wartość modelu będzie zależeć od wiarygodności ewaluatorów, wdrożenia produkcyjnego oraz dowodów, że informacja zwrotna poprawia wyniki w nieznanych przypadkach.
Pierwszym sygnałem jest niezależna walidacja automatycznych ewaluatorów. Przedsiębiorstwa powinny obserwować publikowane porównania między wynikami AgentCore, ocenami ekspertów dziedzinowych i rzeczywistymi wynikami użytkowników.
Wysoka zgodność wzmocniłaby twierdzenie AWS, że ewaluacje mogą zarządzać wydaniami. Utrzymująca się niezgodność osłabiłaby automatyczne bramki i zwiększyła potrzebę przeglądu przez człowieka.
Porównanie powinno obejmować więcej niż ogólną użyteczność. Powinno testować rozpoznawanie encji, granice autoryzacji, wybór narzędzi, ugruntowane obliczenia, wyniki sesji i syntezę wieloagentową.
Drugim sygnałem jest wdrożenie wykraczające poza przykłady opracowane przez AWS. Raporty produkcyjne z regulowanych branż, od dużych dostawców oprogramowania i mniejszych zespołów inżynierskich pokazałyby, na ile przenośny jest model dziewięciu etapów.
Użyteczne raporty powinny ujawniać konstrukcję zbioru danych, wskaźniki próbkowania, fałszywe alarmy, pominięte incydenty, czas naprawy i narzut ewaluacji. Procentowa poprawa bez tych szczegółów zapewnia ograniczone wskazówki.
Konfiguracja online AgentCore może stale przetwarzać ślady z punktu końcowego agenta lub wybranych grup logów CloudWatch. Mechanizmy kontroli ewaluacji online obsługują również konfigurowalne ewaluatory, próbkowanie i status wykonania.
Istotną miarą wdrożenia nie jest liczba włączonych konfiguracji. Jest nią to, czy zespoły wykrywają błędy semantyczne, zanim zgłoszą je użytkownicy, oraz rozwiązują je bez tworzenia nowych regresji.
Trzecim sygnałem jest wydajność zamkniętej pętli na nieznanym ruchu. AWS twierdzi, że jego system rekomendacji może analizować ślady i sugerować zmienione prompty lub bardziej przejrzyste opisy narzędzi.
W jednym zgłoszonym przykładzie zakodowane na stałe wartości w przykładach few-shot pojawiały się w niepowiązanych odpowiedziach. AWS zastąpił te wartości symbolami zastępczymi i zaobserwował mniej halucynacji oraz silniejsze ugruntowanie.
Kolejnym testem jest to, czy podobne rekomendacje poprawiają interakcje odłożone do walidacji i interakcje na żywo, a nie tylko ślady, które je wygenerowały. Każda rekomendacja powinna przejść przez pierwotną pętlę ewaluacyjną.
Etap ósmy zapewnia operacyjny fundament dla tego testu. AgentCore Observability rejestruje ustrukturyzowane dane wykonawcze za pośrednictwem OpenTelemetry, otwartego standardu dla śladów, metryk i logów.
AWS twierdzi, że jego pulpity łączą alarm z odpowiednim śladem agenta, w tym kolejnością narzędzi, wejściami, wyjściami, opóźnieniem i użyciem tokenów. Wyniki ewaluatorów przechodzą osobnym potokiem do CloudWatch i magazynu długoterminowego.
Firma podaje, że średni czas wykrywania spadł z dni lub tygodni do mniej niż czterech godzin. Dąży również do automatycznego wykrywania, zanim skargi użytkowników staną się głównym sygnałem incydentu.
Wyniki te oddają najbardziej uzasadnioną obietnicę modelu. Ewaluacje Amazon AgentCore nie gwarantują, że autonomiczny system zawsze udzieli poprawnej odpowiedzi. Sprawiają, że ciche pogorszenie staje się na tyle obserwowalne, by można je było zbadać, zablokować lub odwrócić.
Deweloperzy powinni zacząć od wskazania błędnej odpowiedzi, która mogłaby wyrządzić największą szkodę. Nabywcy korporacyjni powinni zapytać dostawców, jak takie niepowodzenie jest mierzone przed wdrożeniem i wykrywane po nim.
Pracownicy wiedzy powinni zachować ostrożność, gdy agent brzmi pewnie. Płynny język nadal nie daje gwarancji, że pod odpowiedzią znajdują się właściwe narzędzie, klient, okres lub źródło.
Kolejna generacja platform agentowych będzie konkurować nie tylko dostępem do modeli i orkiestracją. Będzie rywalizować także tym, czy zespoły potrafią wyjaśniać awarie, odtwarzać je i zapobiegać ich ponownemu wystąpieniu.
Jeśli Twoja organizacja już korzysta z agentów, przeanalizuj ostatni incydent, który dotarł do użytkownika. Czy monitoring opóźnień lub błędów by go wykrył? Jeśli nie, ta luka jest punktem wyjścia do stworzenia realnego kontraktu ewaluacyjnego.
