Amazon SageMaker Multi-Turn RL przenosi trenowanie poza pojedyncze odpowiedzi
Amazon opublikował 23 października przewodnik po SageMaker, który trenuje agenta na całych zadaniach zamiast oceniać pojedyncze, odizolowane odpowiedzi. Amazon SageMaker multi-turn RL, czyli uczenie ze wzmocnieniem obejmujące wzajemnie oddziałujące kroki, wykorzystuje Wordle, aby pokazać praktyczne konsekwencje tego podejścia. Główne wyzwanie przesuwa się w stronę definiowania sukcesu, zachowania użytecznych informacji zwrotnych i mierzenia zachowań, które faktycznie otrzymają użytkownicy.
Istotne porównanie dotyczy SageMaker i dostrajania nadzorowanego, metody uczącej modele naśladowania dostarczonych przykładów. Demonstracje nadal są użyteczne, ale wymagają decyzji, które udane zachowania należy pokazać. Trening oparty na wynikach wymaga natomiast od deweloperów stworzenia środowiska, w którym różne próby mogą otrzymać znaczące oceny.
Ta różnica wywiera presję na zespoły aplikacyjne obok inżynierów modeli. Specjalista wsparcia, właściciel procesu lub ewaluator musi pomóc ustalić, co oznacza pomyślne ukończenie zadania. AWS dostarcza konkretną implementację, ale firma, która ją adaptuje, nadal potrzebuje dowodów, że jej reguły oceny odzwierciedlają rzeczywistą pracę.
Amazon SageMaker Multi-Turn RL czyni pełne zadanie jednostką treningową
Znacząca zmiana dotyczy jednostki informacji zwrotnej: pełna próba może połączyć wcześniejsze decyzje z późniejszym wynikiem.
W swoim przewodniku po multi-turn RL AWS informuje o poprawie wskaźnika rozwiązywania Wordle przez gpt-oss-20b na zbiorze odłożonym z 61% do 84% przy średnim poziomie wysiłku rozumowania. Przy niskim poziomie wysiłku raportowana poprawa wynosi od 15% do 69%. Są to wyniki raportowane przez firmę na podstawie jej przykładu; nie przedstawiono tu niezależnej replikacji.
Liczby te opisują ograniczony eksperyment. Nie potwierdzają takiej samej poprawy w obsłudze klienta, przetwarzaniu wydatków, badaniach ani programowaniu. Ich znaczenie polega na pokazaniu działającej, specyficznej dla zadania ścieżki treningowej, którą deweloperzy mogą analizować i kwestionować.
Rozważmy przykładowy proces wsparcia. Asystent może sprawdzić konto, poprosić o doprecyzowanie, skonsultować dokumentację i podjąć próbę naprawy. Uprzejma odpowiedź na każdym pojedynczym etapie nie mówi kupującemu, czy problem został rozwiązany.
To samo rozróżnienie dotyczy nieudanej próby zawierającej użyteczne decyzje. Zadanie koniecznego pytania może wyglądać nieefektywnie, gdy ocenia się je osobno. W całej interakcji takie pytanie może zapobiec błędnemu działaniu lub możliwej do uniknięcia eskalacji.
Informacja zwrotna oparta na wyniku daje deweloperom sposób na wyrażenie tej zależności. Nie identyfikuje automatycznie przyczynowego znaczenia każdego działania. Zamiast tego trening porównuje próby i zmienia model zgodnie z sygnałami, które te próby generują.
Dzięki temu przykład jest istotny poza kontekstem gry, nie stając się jednocześnie dowodem ogólnej wydajności biznesowej. Przenośna idea dotyczy sposobu, w jaki aplikacja generuje informację zwrotną. Przenośny wynik nadal musi zmierzyć każdy zespół wdrażający rozwiązanie.
Ważny jest również czas. AWS ogłosił ogólną dostępność bezserwerowych sesji treningowych 22 października. Ta szersza oferta pozwala deweloperom koordynować logikę treningu, podczas gdy AWS zarządza zasobami obliczeniowymi i wykonaniem.
Sąsiadujące ogłoszenia wskazują na spójny kierunek produktowy: większą, specyficzną dla aplikacji kontrolę nad treningiem po wstępnym szkoleniu, czyli procesem dostosowywania już wytrenowanego modelu. Nadal należy je rozróżniać. Elastyczna sesja treningowa i konkretny proces Wordle to powiązane możliwości o odmiennych wyborach implementacyjnych.
Dla nabywców korporacyjnych zmienia to pytania, które warto zadawać podczas oceny. Pytanie, czy model potrafi wywołać narzędzie, jest jedynie punktem wyjścia. Kupujący muszą także wiedzieć, jak zachowuje się po otrzymaniu informacji zwrotnej, nieudanych działaniach, niepełnych informacjach i zmieniających się warunkach.
Ocena pełnego zadania może uporządkować te pytania, pod warunkiem że odzwierciedla wynik ceniony przez organizację. W przeciwnym razie skuteczniejszy optymalizator po prostu stanie się skuteczniejszy w realizowaniu niepełnego celu.
Praca przesuwa się od pisania demonstracji do definiowania sukcesu
Zmniejszenie zależności od przykładowych odpowiedzi zwiększa znaczenie projektowania środowiska i pomiaru wyników.
Porównanie SageMaker i dostrajania nadzorowanego jest zatem porównaniem strategii informacji zwrotnej. Nie jest uniwersalnym rankingiem metod treningowych. Różne części aplikacji mogą korzystać z demonstracji, nagród za wynik lub ich połączenia.
Przykładowa odpowiedź może uczyć formatowania, tonu lub wymaganej sekwencji. Jest to użyteczne, gdy organizacja wie, jak wygląda akceptowalne zachowanie. Staje się trudniejsze, gdy poprawnych ścieżek jest kilka, a właściwa zależy od pośrednich obserwacji.
Ocena wyniku może uwzględnić takie alternatywy. Jednak ktoś nadal musi zdecydować, czy próba zakończyła się sukcesem, które błędy mają znaczenie i jak liczyć próby nieukończone. Usunięcie narzuconej odpowiedzi nie usuwa osądu redakcyjnego ani operacyjnego.
Przykładowy proces rozliczania wydatków pokazuje tę różnicę. Ukończone zgłoszenie może przejść prostą automatyczną kontrolę, a jednocześnie używać niewłaściwej kategorii lub nie zawierać wymaganej zgody. Liczenie wyłącznie zgłoszeń nagradzałoby zachowanie, które tworzy dodatkową pracę porządkową gdzie indziej.
Silniejsza ewaluacja sprawdzałaby powstały rekord i jego wymagane warunki. Rozróżniałaby także uzasadnioną prośbę o wyjaśnienie od niepotrzebnego przerwania pracy. Są to proponowane kwestie projektowe, a nie wyniki zademonstrowane przez eksperyment Wordle.
Presja spada na osoby rozumiejące te warunki. Inżynierowie aplikacji mogą wdrożyć funkcję oceny, ale właściciele dziedzin muszą pomóc określić jej znaczenie. Ewaluatorzy muszą następnie szukać przypadków, w których implementacja i zamierzone znaczenie się rozchodzą.
Ten podział pracy powinien wpływać na planowanie projektu. Zespół mający dostępne zasoby obliczeniowe, ale słabo zdefiniowane kryteria sukcesu, nie jest gotowy wyłącznie dlatego, że trening jest dostępny. Najpierw potrzebuje zadania, które można wielokrotnie podejmować i konsekwentnie oceniać.
Odwrotnie, wąski proces z jasnymi kontrolami ukończenia stanowi łatwiejszy punkt wyjścia. Zespół może badać niepowodzenia, weryfikować swoje założenia i porównywać wyniki, nie twierdząc przy tym, że eksperyment reprezentuje każdy proces biznesowy.
Dokumentacja staje się częścią tego procesu informacji zwrotnej. Zespoły powinny zachowywać definicje zadań, decyzje dotyczące oceniania, odrzucone alternatywy i przykłady niejednoznacznych przypadków. Wspólna przeszukiwalna baza wiedzy może zapewnić recenzentom wspólny punkt odniesienia, gdy te definicje się zmieniają.
Praktyczna wartość polega na uwidacznianiu sporów. Jeśli dział operacyjny uznaje interakcję za udaną, a dział compliance za niedopuszczalną, trening nie powinien po cichu wybierać między nimi. Taka rozbieżność powinna znaleźć się w specyfikacji zadania przed rozpoczęciem optymalizacji.
Wyjaśnia to również, dlaczego mniejszy model specyficzny dla zadania pozostaje propozycją empiryczną. Jego przydatność zależy od wymaganego zachowania, dostępnej informacji zwrotnej i akceptowalnego wskaźnika błędów. Dostępność potoku treningowego nie rozstrzyga tych kwestii za kupującego.
Amazon SageMaker multi-turn RL daje więc zespołom aplikacyjnym kolejną opcję adaptacji. Jej użyteczność zależy od tego, czy ich proces ewaluacji potrafi odróżnić pożądane ukończenie od wyniku, który jedynie wygląda na ukończony.
AgentCore łączy środowisko, zbiór danych i pętlę treningową
Architektura przykładu oddziela trenowany model od aplikacji, która tworzy jego doświadczenie.
Próbka treningowa Wordle od AWS umieszcza grę, narzędzia i logikę nagrody w środowisku uruchomieniowym Amazon Bedrock AgentCore, hostowanym środowisku wykonawczym. SageMaker zarządza stroną treningową. Agent wywołuje model polityki, czyli model wybierający działania podczas próby.
Przykładowy zbiór danych zawiera 640 słów treningowych i 128 odrębnych słów walidacyjnych. Każde zadanie zawiera instrukcję, ukrytą odpowiedź dla środowiska oraz identyfikator. Model otrzymuje informację zwrotną z gry, a nie bezpośredni dostęp do odpowiedzi.
Repozytorium obejmuje lokalne kontrole środowiska, przygotowanie zbioru danych, wdrożenie, trening, ewaluację i komponenty czyszczenia. Wyraźnie opisuje projekt jako demonstrację, a nie implementację produkcyjną. To zastrzeżenie powinno towarzyszyć każdej decyzji o jego adaptacji.
Dla dewelopera lekcja architektoniczna dotyczy granic. Środowisko potrzebuje informacji, których model nie powinien otrzymywać bezpośrednio. Poprawna implementacja musi zachować to rozróżnienie podczas analizowania zadań, odpowiedzi narzędzi, rejestrowania i obsługi błędów.
Biznesowym odpowiednikiem może być oczekiwany stan konta lub prywatne kryterium ukończenia. Ewaluator może potrzebować tych informacji, aby określić sukces. Ujawnienie ich agentowi mogłoby zamienić zadanie wymagające rozumowania w wyszukiwanie odpowiedzi.
Przygotowanie zbioru danych obejmuje zatem więcej niż gromadzenie promptów. Deweloperzy muszą zdecydować, co należy do zadania, co należy do środowiska, a co pozostaje prywatne. Decyzje te kształtują zarówno trudność, jak i trafność eksperymentu.
Wdrożenie rodzi inne pytanie: czy aplikacja może niezawodnie wykonać próbę. Przed uznaniem słabych nagród za oznakę słabego rozumowania zespół powinien ustalić, że żądania docierają do modelu, a odpowiedzi narzędzi do agenta.
To rozróżnienie ma znaczenie, ponieważ awarie operacyjne i błędy decyzyjne wymagają różnych napraw. Problem z uwierzytelnianiem wymaga pracy nad infrastrukturą. Agent wybierający nieodpowiednie działanie wymaga zbadania zachowania, informacji zwrotnej lub projektu zadania.
Dokumentacja multi-turn RL od AWS opisuje zadania obejmujące interakcję, użycie narzędzi, odzyskiwanie po błędach i zależne decyzje. Rozróżnia również szerszego agenta od bazowego modelu. To słownictwo pomaga zespołom uniknąć przypisywania każdej awarii systemu jakości modelu.
Metoda treningowa dodaje kolejną granicę. Group Relative Policy Optimization, czyli GRPO, porównuje nagrody w grupach prób, aby kierować aktualizacjami. Badanie DeepSeekMath wprowadziło GRPO w pracach nad rozumowaniem matematycznym, zapewniając historyczny kontekst jego wykorzystania tutaj.
Mechanizm porównania sprawia, że funkcja oceny jest szczególnie istotna. Jeśli użyteczne i niepomocne próby otrzymują nierozróżnialne wyniki, informacja zwrotna oferuje niewielką podstawę do preferencji. Jeśli wprowadzające w błąd zachowanie otrzymuje wyższą ocenę, optymalizacja otrzymuje niewłaściwy kierunek.
Trening agentów SageMaker wyjaśniony przez tę architekturę staje się opowieścią o systemie. Zbiór danych rozpoczyna próbę, środowisko dostarcza obserwacje, a model wybiera działania. Ewaluacja musi badać ich wzajemne oddziaływanie, zamiast traktować wytrenowany model jako odizolowany artefakt.
Nagroda może faworyzować niewłaściwy rodzaj postępu
Funkcja punktacji musi zachowywać priorytety organizacji, nawet gdy agent znajdzie nieoczekiwaną ścieżkę.
AWS opisuje początkową nagrodę w Wordle, która kumulowała premie za kolejne próby. Mogła przyznać pozytywną ocenę przegranej rozgrywce i preferować późniejsze rozwiązanie nad wcześniejszym. Zmieniony projekt sprawia, że wynik ma decydujące znaczenie, oraz ogranicza dodatkowe nagrody za strategię.
Ten przykład ilustruje ogólny problem projektowy: lokalnie rozsądne zachęty mogą łącznie prowadzić do niepożądanej preferencji. Premia za zbieranie informacji brzmi sensownie. Bez odpowiednich ograniczeń może jednak nagradzać dalszą aktywność po uzyskaniu już użytecznych informacji.
W przykładowej aplikacji wsparcia odpowiednikiem byłoby nagradzanie każdego kroku diagnostycznego. Asystent mógłby zdobywać więcej punktów, przedłużając interakcję, niż rozwiązując problem bez zwłoki. To hipotetyczny tryb awarii, a nie zaobserwowany wynik wdrożeń biznesowych AWS.
Premia za zakończenie może również ukrywać problemy. Asystent mógłby zamknąć zgłoszenie, pozostawiając nierozwiązany problem źródłowy. Ewaluator potrzebuje dowodów osiągnięcia zamierzonego rezultatu, zamiast uznawać deklarację agenta za wystarczający dowód.
W tym miejscu wiedza dziedzinowa staje się technicznie istotna. Funkcja punktacji koduje priorytety, które ludzie mogliby inaczej wyrażać nieformalnie. Gdy priorytety te stają się celami optymalizacji, niewielkie niejednoznaczności mogą wpłynąć na to, które zachowanie otrzyma wzmocnienie.
Zespoły powinny analizować pary kontrastujących prób przed uruchomieniem większych eksperymentów. Prawidłowe ukończenie powinno mieć pierwszeństwo przed niepełną próbą, która gromadzi uboczne punkty. Wymagana eskalacja powinna również pozostawać preferowana wobec nieautoryzowanego działania, które osiąga pozorny cel.
Porównania te są proponowanymi praktykami ewaluacyjnymi. Nie gwarantują, że model będzie zachowywał się poprawnie poza testowanymi przypadkami. Ich celem jest ujawnienie sprzeczności w funkcji celu, gdy wciąż można je łatwo zbadać.
Szersza obawa pojawia się w badaniach Anthropic dotyczących reward hackingu, które analizują modele uczące się zdobywać nagrody bez realizowania zadań zgodnie z zamierzeniem. Ich środowisko eksperymentalne różni się od przykładu AWS z Wordle. Stanowią przestrogę dotyczącą projektowania funkcji celu, a nie dowód równoważnej awarii w SageMaker.
To rozróżnienie ma znaczenie dla neutralnej oceny. Przykład AWS nie dowodzi ogólnego problemu bezpieczeństwa tej usługi. Badania Anthropic również nie dowodzą, że każdy trening specyficzny dla zadania rozwija analizowane tam zachowania.
Łącznie materiały te wspierają węższy wniosek: ewaluacja musi badać, w jaki sposób wynik został uzyskany. Rosnąca nagroda może odzwierciedlać lepsze wykonanie zadania, zbyt hojny system punktacji lub mieszankę obu tych czynników. Sama wartość zbiorcza nie rozstrzyga tej niejednoznaczności.
Zespoły aplikacyjne powinny zatem zachowywać przykłady podważające ich interpretację sukcesu. Przypadki obejmujące niepotrzebne działania, przedwczesne zakończenie, brakujące dowody i niewłaściwą eskalację zasługują na wyraźną ocenę. Celem jest znalezienie słabości punktacji, zanim powtarzany trening wzmocni ich konsekwencje.
Główne napięcie pozostaje takie samo jak w adaptacji nadzorowanej: programiści potrzebują wiarygodnej informacji zwrotnej. Wieloturowe RL w Amazon SageMaker zmienia sposób generowania tej informacji zwrotnej, ale nie czyni jej znaczenia oczywistym.
Ustawienia obsługi należą do deklaracji wydajności
Raportowany wynik zadania wymaga konfiguracji, która go wygenerowała, obok modelu i zestawu ewaluacyjnego.
Przykład AWS stanowi wyraźne przypomnienie. Walidacja treningu zakończyła się wskaźnikiem rozwiązania na poziomie 37%, podczas gdy raportowana konfiguracja obsługi osiągnęła 84%. Ustawienia różniły się, w tym wysiłkiem rozumowania i temperaturą, parametrem kontrolującym losowość generowanych odpowiedzi.
Liczb tych nie należy odczytywać jako wymiennych pomiarów. Wyższy wynik nie powinien też wymazywać niższego. Odpowiadają na pytania dotyczące różnych warunków operacyjnych, a decyzja wdrożeniowa wymaga warunków odpowiadających zamierzonej aplikacji.
Wysiłek rozumowania wprowadza praktyczny wybór dotyczący tego, ile obliczeń model wykonuje przed odpowiedzią. Temperatura zmienia sposób próbkowania możliwych odpowiedzi. Ich interakcja może zmieniać sekwencję decyzji podejmowanych przez agenta w trakcie zadania.
Właściwe porównanie utrzymuje istotne warunki stałe między modelem bazowym a modelem adaptowanym. W przeciwnym razie pozorna poprawa treningu może częściowo wynikać ze zmiany konfiguracji. To kwestia projektu eksperymentu, a nie zarzut niewłaściwego postępowania w opublikowanym przykładzie.
Kupujący powinien zapytać o konfigurację operacyjną przed porównywaniem nagłówkowych wartości procentowych między dostawcami. Definicje narzędzi, dane wejściowe zadania, dostępny kontekst i reguły zatrzymania również pomagają określić, co agent może osiągnąć. Sama nazwa modelu pozostawia zbyt wiele niedookreślonego.
Staje się to szczególnie ważne przy ocenie modelu specyficznego dla zadania względem alternatywy ogólnego przeznaczenia. Starannie adaptowany mniejszy model i model o szerokich możliwościach odpowiadają na różne pytania produktowe. Porównanie musi ustalić, które zadanie, ograniczenia i budżet operacyjny mają znaczenie dla organizacji.
Ćwiczenie z Wordle nie ustanawia ogólnego rankingu względem Anthropic, Google ani innych dostawców modeli. Dostarcza dowodów dotyczących konkretnego eksperymentu adaptacyjnego. Rozszerzenie tych dowodów wymaga ewaluacji zaprojektowanych pod szersze twierdzenie.
Analiza porażek powinna towarzyszyć ogólnemu wskaźnikowi sukcesu. Aplikacja może poprawić średnią, zachowując niedopuszczalny wzorzec błędów w ważnym podzbiorze. Decyzja biznesowa wymaga wiedzy, czy pozostałe błędy obejmują nieszkodliwe ponowienia, nieprawidłowe rekordy czy działania wymagające naprawy przez człowieka.
Powtarzana ewaluacja pomaga również odróżnić stabilny zysk od zmienności generowanego zachowania. Zespoły powinny raportować niepewność tam, gdzie wspierają ją ich dowody. Powinny unikać pozornej precyzji lub traktowania niewielkiego zestawu udanych demonstracji jako wyniku dla całej populacji.
W przypadku SageMaker i dostrajania nadzorowanego porównanie wdrożeniowe powinno stosować ten sam standard. Pytanie brzmi, czy wybrana metoda adaptacji poprawia cały przepływ pracy w porównywalnych warunkach. Metryki treningowe pozostają użytecznym dowodem diagnostycznym, ale wymagania wdrożeniowe decydują o akceptacji.
Wyjaśnianie treningu agentów SageMaker wyłącznie poprzez rosnącą krzywą na pulpicie ominęłoby ten punkt. Dostarczony system obejmuje konfigurację, narzędzia, zachowanie środowiska i ścieżki odzyskiwania. Elementy te muszą pozostawać związane z deklaracją wydajności przez cały proces zakupu i przeglądu wydania.
Tworzy to również odpowiedzialność operacyjną po uruchomieniu. Jeśli zespół zmieni odpowiedzi narzędzi lub ustawienia generowania, powinien ponownie ocenić wcześniej zatwierdzone zachowanie. Stara ewaluacja opisuje wcześniejszy system, nawet gdy wagi modelu pozostają niezmienione.
Kolejne dowody powinny testować odtwarzalność, transfer i niezawodność
Najmocniejsze dalsze dowody ustaliłyby, czy zyski z przykładu utrzymują się przy niezależnej weryfikacji i użytecznych ograniczeniach przepływu pracy.
Pierwszym sygnałem do obserwacji jest odtworzenie w dopasowanych warunkach. Niezależne uruchomienie powinno zachować istotną konfigurację zadania i raportować konfigurację operacyjną. Podobne wyniki zwiększyłyby pewność, że opublikowany zysk jest odtwarzalny, a nie specyficzny dla nieudokumentowanego szczegółu implementacji.
Odtworzenie raportujące istotnie różne wyniki wymagałoby zbadania przed wyciągnięciem szerszych wniosków. Możliwe wyjaśnienia obejmują zmienione zależności, inne ustawienia lub różnice między uruchomieniami. Sama rozbieżność nie wskazywałaby, które wyjaśnienie jest poprawne.
Dla czytelników wartościowy artefakt zawierałby wystarczające informacje, by powiązać wyniki z systemem, który je wytworzył. Oznacza to zachowanie definicji zadań, wersji modeli, zachowania środowiska i konfiguracji. Zrzut ekranu końcowego wyniku pozostawiłby kluczowe pytania bez odpowiedzi.
Drugim sygnałem jest transfer do prywatnego przepływu pracy z wiarygodnymi kryteriami sukcesu. Ograniczone zadanie wewnętrzne byłoby bardziej informacyjne niż kolejne twierdzenie o ogólnej poprawie agentów. Powinno obejmować nieznane przypadki i kontrole, które nie powielają po prostu nagrody treningowej.
Pozytywne wyniki w takim przypadku wzmocniłyby argument za adaptacją specyficzną dla aplikacji. Słaby transfer zawęziłby twierdzenie do środowisk, w których sukces jest wyjątkowo łatwy do zweryfikowania. Każdy z wyników pomógłby kupującym ustalić, gdzie uzasadnione są dalsze eksperymenty.
Dowody powinny również odróżniać uczenie się od ekspozycji na materiał ewaluacyjny. Prywatny zestaw testowy wymaga ochrony, a ewaluatorzy powinni sprawdzać, co ujawnia środowisko. W przeciwnym razie nominalnie nieznane zadanie może mimo wszystko ujawniać informacje potrzebne do zaliczenia.
Trzecim sygnałem jest niezawodność, gdy otaczająca aplikacja działa niedoskonale. Kupujący muszą wiedzieć, co dzieje się po niedostępnych narzędziach, niejednoznacznych odpowiedziach lub przerwanych próbach. Sukces w idealnych warunkach nie opisuje pełnego obciążenia operacyjnego.
Ewaluacja zachowująca użyteczne zachowanie w tych warunkach wzmocniłaby praktyczne uzasadnienie. System wymagający częstych ręcznych napraw osłabiłby je, nawet jeśli jego wynik zadania w warunkach idealnych się poprawia. Istotne porównanie uwzględnia pracę pozostawioną ludziom.
W nadchodzących miesiącach sygnały te powinny kierować uwagę bardziej niż niepoparte przewidywania dotyczące tego, która metoda treningu zdominuje rynek. AWS przedstawiło możliwy do zbadania przykład i raportowany wynik. Kolejne dowody muszą pokazać, gdzie podejście pozostaje użyteczne, gdy środowisko staje się mniej uporządkowane.
Dla zespołów rozważających eksperyment punktem wyjścia powinien być ograniczony przepływ pracy, którego rezultat recenzenci mogą zweryfikować niezależnie. Zarejestruj zachowanie modelu bazowego przy zamierzonych ustawieniach obsługi, a następnie określ, jak wyglądałaby akceptowalna poprawa. Zachowaj trudne przypadki i analizuj działania stojące za udanymi wynikami. Użyj próbki AWS, aby zrozumieć integrację, traktując jej kod demonstracyjny jako punkt wyjścia do ewaluacji. Przed rozszerzeniem wieloturowego RL Amazon SageMaker na szerszy przepływ pracy zapytaj, czy zysk utrzymuje się przy nieznanych zadaniach, porównywalnych ustawieniach i niezależnych kontrolach wyników. Wybierz następny eksperyment wokół niepewności, która ma największe znaczenie dla osób zależnych od rezultatu.
