Nauka na podstawie rzeczywistych doświadczeń

Sposób, w jaki użytkownicy wchodzą w interakcje z naszymi produktami w świecie rzeczywistym, jest cennym źródłem danych do trenowania modeli. Dane te są obfite, odzwierciedlają rzeczywisty rozkład zadań użytkowników oraz rejestrują korektę użytkowników i awarie narzędzi, które środowiska syntetyczne mogą przeoczyć.

Powszechnym sposobem na uczenie się na danych ze świata rzeczywistego jest dostrajanie metodą próbkowania z odrzuceniem (rejection sampling fine-tuning): ocena wyniku każdej sesji, zachowanie udanych i trenowanie modelu w celu ich imitacji. Jednak udany wynik nie oznacza, że każdy krok był poprawny, więc imitowanie całej trajektorii grozi wzmocnieniem złych zachowań pośrednich obok tych dobrych. Odrzucanie nieudanych sesji powoduje również utratę kluczowych dowodów na to, gdzie model niedomaga.

Łączymy dostrajanie na podstawie próbkowania z odrzucaniem z autodystylacją kierowaną wskazówkami, aby uczyć się zarówno z udanych, jak i nieudanych sesji. Wskazówka to krótka instrukcja korygująca oparta na informacjach, które model posiadał już w momencie popełnienia błędu. Przydatne kroki z udanych sesji pozostają celami imitacji, podczas gdy zakorzenione wskazówki zamieniają unikalne błędy w cele korekty.

Korekty użytkowników i błędy narzędzi dodają nadzór dotyczący tego, co poszło nie tak po drodze, oprócz samej informacji, czy zadanie ostatecznie zakończyło się sukcesem. Stosujemy ten etap po uczeniu przez wzmacnianie w środowiskach syntetycznych, aby pomóc domknąć lukę między tymi środowiskami a użytkowaniem w świecie rzeczywistym.

W rzeczywistych zastosowaniach późniejszy punkt kontrolny po treningu (post-trained) GLM-5.2 zmniejszył liczbę błędów wywołań narzędzi o 21,2% w stosunku do wcześniejszego punktu kontrolnego. W przypadku GLM-5.3 trening pooperacyjny zmniejszył liczbę błędów wywołań narzędzi o 33,0%, a średnie szacowane prawdopodobieństwo średniego lub wysokiego niezadowolenia użytkownika o 17,2% w stosunku do modelu bazowego.

Zadania syntetyczne pozwalają nam tworzyć kontrolowane problemy z łatwymi do zweryfikowania wynikami, jednak zazwyczaj ograniczone są do pojedynczego promptu i mogą obejmować tylko te scenariusze, które sami wyraźnie zaprojektujemy.

Natomiast użytkownicy w sesjach w świecie rzeczywistym wnoszą różnorodne instrukcje, kontekst i kombinacje narzędzi do sesji rozwijających się na przestrzeni wielu tur interakcji. Takie użytkowanie w świecie rzeczywistym naturalnie przynosi dwa cenne sygnały o błędach: korekty użytkowników ujawniają, gdzie agent nie dostarczył tego, czego oczekiwali, a błędy narzędzi pokazują, gdzie jego działania zawiodły w rzeczywistych środowiskach. Nasz potok próbkowania szanuje prywatność użytkowników i ich wybory dotyczące treningu, wykluczając sesje zawierające informacje umożliwiające identyfikację osoby (PII) oraz pochodzące od użytkowników, którzy zrezygnowali.

Dane ze świata rzeczywistego zapewniają nam zatem przypadki błędów, których środowisko syntetyczne może nie ujawnić, i często zawierają już wbudowane miejsce wystąpienia błędu.

Podczas treningu na danych ze świata rzeczywistego standardowe dostrajanie metodą próbkowania z odrzuceniem (RFT) wybiera udane sesje na podstawie ich ostatecznych wyników, bez wyraźnego używania opinii użytkowników i narzędzi do odróżnienia dobrych działań pośrednich od złych. Agent może dojść do siebie po złym wywołaniu narzędzia lub skorygować błąd po opinii użytkownika i nadal dostarczyć właściwy wynik na końcu.

Odrzucanie nieudanych sesji ogranicza również wydajność próby. Sesja, która nigdy nie osiąga dobrego rezultatu, nadal może ujawnić wyraźny, możliwy do uniknięcia błąd jako użyteczny sygnał treningowy.

Rozwiązujemy te ograniczenia, oddzielając od siebie dwie decyzje: które sesje zawierają zachowania warte naśladowania oraz które tury zawierają błędy warte skorygowania. Potok danych podejmuje te decyzje osobno, a następnie przypisuje turom modelu jeden z trzech zabiegów:

Naśladuj: tury bez błędów w udanych sesjach otrzymują zwykłą stratę entropii krzyżowej (CE), zwiększając prawdopodobieństwo zarejestrowanych tokenów.
Poprawne: zarówno w udanych, jak i nieudanych sesjach tury błędów z ważną podpowiedzią otrzymują stratę dywergencji Kullbacka-Leiblera (KL), przesuwając model w kierunku przewidywań następnego tokena, jakie generuje on, gdy widzi podpowiedź.
Zachowaj jako kontekst: tury w nieudanych sesjach, które nie mają zweryfikowanej podpowiedzi, oraz oznaczone złe tury bez zweryfikowanej podpowiedzi w obu typach sesji, służą jako kontekst, ale nie otrzymują żadnej ze strat.

W rezultacie udane sesje mogą dostarczać zarówno celów imitacji, jak i korekty, podczas gdy nieudane sesje dostarczają wyłącznie celów korekty. Wszystkie pozostałe tury, w tym dane wyjściowe systemu, użytkownika i narzędzia, pozostają jako kontekst.

Diagram routingu sesji: udane sesje zapewniają imitację CE i uprawnione skorygowane podpowiedzi; nieudane sesje zapewniają wyłącznie uprawnione korekty. — Bieżący routing sesji i maski zawartości asystenta. Udane sesje wnoszą cele imitacji; zachowane zapisy opinii mogą wnosić podpowiedzi korygujące nawet wtedy, gdy sesja nie powiodła się. Pozostała zawartość pozostaje jako kontekst. Niekompletne sesje są wykluczane. Nieprzedstawiony jest wyjątek CE dla niekońcowego tokena yield/stop, a ten diagram nie ustala mieszanki używanej przez wcześniejszy punkt kontrolny.

Część imitacyjna wykorzystuje standardowy RFT. Część korygująca wykorzystuje On-Policy Self-Distillation (OPSD): ten sam model działa jako nauczyciel i uczeń, przy czym nauczyciel otrzymuje poufne informacje. W tym przypadku ową poufną informacją jest krótka podpowiedź wyjaśniająca błąd, którego można było uniknąć. Trenujemy ucznia tak, aby dopasował się do przewidywań następnego tokena nauczyciela bez otrzymywania podpowiedzi.

Obie części mają znaczenie. Trening oparty wyłącznie na korekcie może ujawnić drogę na skróty: nauczyciel i uczeń mogą dojść do zgody poprzez ignorowanie kontekstu zamiast uczenia się korekty. Człon CE zakotwicza trening w użytecznym zachowaniu, pomagając zniechęcić do osiągania zgody wynikającej z ignorowania kontekstu.

Przeszkolony uczeń staje się wówczas opcją modelu w Computer. Nowe sesje z użycia na żywo przechodzą przez te same filtry kwalifikowalności i prywatności przed wejściem do kolejnej rundy potoku treningowego.

Następnie przechodzimy przez konkretny przykład, który zawiera zarówno imitację, jak i korektę.

Rozważmy ostatecznie udaną sesję, w której użytkownik prosi o porównanie zmian w asyncio w Pythonie 3.13 przy użyciu oficjalnej dokumentacji. Nasza dokumentacja narzędzia stwierdza, że search.web zwraca listę wyników (hits), z których każdy ma pole url.

Model najpierw przeprowadza ważne wyszukiwanie dla jednej wersji w ramach gromadzenia dowodów do porównania, co jest dobrym zachowaniem do naśladowania.

Jednak kolejne wywołanie wykonania kodu błędnie traktuje tę listę jak słownik. Narzędzie kodu zwraca TypeError: list indices must be integers or slices, not str. Ponieważ typ zwracany został udokumentowany przed wywołaniem, jest to błąd, którego model powinien móc uniknąć. Można wygenerować podpowiedź z odpowiednim wywołaniem, aby skorygować to działanie.

Ilustratywna sesja kodowania: dane wejściowe systemu i użytkownika oraz błędy narzędzi pozostają kontekstem; użyteczne zarejestrowane wywołania wyszukiwania i odzyskiwania otrzymują CE w udanej sesji; oznaczone błędne wyszukiwanie listy otrzymuje KL w kierunku nauczyciela, któremu podano ugruntowaną podpowiedź. — Ilustratywna sesja kodowania pokazuje trzy role treningowe: dane wejściowe i wyjścia narzędzi będące wyłącznie kontekstem (szare), imitację CE użytecznych zarejestrowanych wywołań (ciemne) oraz korektę KL oznaczonego błędu (turkusowe). W tym przypadku model błędnie traktuje listę wyników wyszukiwania jak słownik; podpowiedź przeznaczona wyłącznie dla nauczyciela, ugruntowana we wcześniejszej dokumentacji narzędzia, kieruje korektą. Cele CE mają zastosowanie tylko wtedy, gdy ukończona sesja zostanie uznana za udaną, podczas gdy nieudana sesja nadal może dostarczyć uprawnionego celu korekty KL.

Potok treningowy składa się z czterech etapów: wyboru sesji i oceny ich wyników, identyfikacji błędów i tworzenia podpowiedzi na podstawie opinii użytkowników i błędów narzędzi, generowania prawdopodobieństw następnego tokena zarówno od nauczyciela, jak i od ucznia, oraz trenowania modelu za pomocą połączonej straty CE i KL.

Potok próbkowania pobiera dane z kwalifikującego się do treningu podzbioru rzeczywistych sesji Computer obsługiwanych przez GLM 5.2. Rezygnacje z treningu oraz wykluczenia związane z PII w potoku są stosowane przed wybraniem przykładów do tego przepływu pracy.

Początkowy proces selekcji wybiera kandydatów ocenionych na 4 lub 5 w pięciopunktowej skali trudności zadania przez sędziego LLM i dzieli ich na 2 grupy:

Grupa opinii użytkowników zawiera sesje z autentyczną kontynuacją ze strony użytkownika lub flagą średniego bądź wysokiego niezadowolenia. Uważamy te kontynuacje o wysokiej intencji za szczególnie użyteczne do nauki: użytkownicy aktywnie próbują ukończyć zadanie, a ich korekty precyzyjnie wskazują, co model pominął.
Grupa błędów narzędzi zawiera sesje z nieudanymi wywołaniami oznaczonymi przez sprawdzenia oparte na regułach, z wyłączeniem rozpoznanych awarii infrastruktury i odrzuconych autoryzacji.

Następnie dwóch sędziów będących dużymi modelami językowymi (LLM) ocenia końcowy wynik pod kątem żądania użytkownika; obaj sędziowie muszą wydać pozytywny werdykt, aby oznaczyć sesję jako „udaną”. W przypadku sesji dostarczających artefakty, etap wyników może zrekonstruować i sprawdzić dostarczony materiał, powracając do ocen tekstowych w przypadku niepowodzenia tego etapu. Sesje zaklasyfikowane jako niekompletne, takie jak praca oczekująca na użytkownika, są wykluczane.

Ten krok identyfikuje potencjalne źródła sygnałów edukacyjnych; jednak nie każdy błąd można przypisać modelowi, ponieważ niektóre wynikają z niejednoznacznych instrukcji lub awarii infrastruktury. Późniejsza adnotacja określa, które kandydackie błędy są faktycznie do uniknięcia i nadają się do treningu.

Rozważmy przykładową sesję w grupie opinii użytkowników, w której użytkownik pyta: „How do I find my w3 on paychex”. Model traktuje „w3” jako literówkę W-2, wyszukuje instrukcje dotyczące W-2 i wyjaśnia, jak znaleźć ten formularz. Kolejne pytanie użytkownika: „I meant the W-3 transmittal form,” wskazuje na błąd, nawet jeśli sesja ostatecznie zakończy się sukcesem.

Skarga pomaga zlokalizować błąd, ale przyczyną źródłową jest wcześniejsza decyzja o zinterpretowaniu „w3” jako W-2. Oryginalne żądanie sprawia, że błąd można było uniknąć: model mógł zachować W-3 lub poprosić o wyjaśnienie. Okazuje się, że ostatna tura asystenta przed skargą jest przyczyną źródłową tylko w około połowie przypadków.

Nasz potok adnotacji systematycznie odwzorowuje przyczynę i skutek w ramach każdej sesji opinii użytkowników. Ankieter najpierw sprawdza, czy nie wystąpiło pominięcie wymagania lub intencji wspieranej przez wcześniejszy kontekst. Następnie trzech sędziów LLM identyfikuje odpowiedzialne tury, wymagając zgody co najmniej dwóch z nich co do danej tury. Czasami wcześniejsza wypowiedź wyraźnie ustala wymaganie. W innych przypadkach żadna pojedyncza wcześniejsza wypowiedź tego nie robi, ale wiele elementów poprzedniej konwersacji wspólnie sprawia, że zamierzone zachowanie staje się wnioskowalne. Taki projekt pozwala im połączyć skargę z wcześniejszym błędem źródłowym zamiast przypisywać ją wyłącznie do ostatniej odpowiedzi.

Przed zaakceptowaniem podpowiedzi potok sprawdza również, czy jej twierdzenia korygujące wynikają z informacji dostępnych przed oznaczoną turą. Sprawdzenia te mają na celu ograniczenie błędu z perspektywy czasu (hindsight bias), w którym nowa preferencja ujawniona w skardze jest traktowana jako coś, co model powinien już wiedzieć.

W tym przykładzie podpowiedź mówi modelowi, aby szukał formularza przesyłania W-3 na Paychex zamiast W-2, lub zapytał, który formularz ma na myśli użytkownik, jeśli żądanie jest niejednoznaczne. Korekta dotyczy wcześniejszej interpretacji i decyzji o wyszukiwaniu, a nie tylko ostatecznej odpowiedzi. Oryginalna tura pozostaje niezmieniona; adnotacja dodaje is_bad_turn: true oraz niepustą hint.

Żądanie W-3 jest błędnie interpretowane jako W-2; późniejsza skarga jest śledzona do wcześniejszej decyzji o wyszukiwaniu i sprawdzana pod kątem wcześniejszych dowodów. — Prawdziwa sesja pokazująca, jak skarga jest śledzona wstecz do wcześniejszego błędu, z nałożoną procedurą adnotacji. Użytkownik poprosił o „w3” na Paychex, ale model potraktował to jako literówkę W-2 i wyszukał niewłaściwy formularz. Konsensus proponujących lokalizuje przyczynę źródłową, podczas gdy dwa sprawdzenia ugruntowania oceniają, czy dowody poprzedzają błąd, a twierdzenia podpowiedzi wynikają z informacji dostępnych w tym momencie. Zaakceptowane adnotacje zachowują oryginalny tekst i dodają znaczniki oraz podpowiedzi, zamiast przepisanych celów.

Rozważmy kolejną sesję w grupie błędów narzędzi z wywołaniem wyszukiwania, w której agent szuka za pomocą recency_filter: "year", ale narzędzie odrzuca to, ponieważ dozwolone wartości to „day”, „week” lub „month”. Jest to wyraźne naruszenie schematu.

Ścieżka błędów narzędzi wykorzystuje deterministyczne reguły dla znanych błędów oraz ocenę modelu w przypadkach niejednoznacznych. Sam komunikat o błędzie również nie wystarcza, aby obwinić model; osądzona korekta musi wskazywać na coś, co model mógł wiedzieć ze schematu narzędzia, instrukcji systemowych lub wcześniejszej konwersacji.

Wywołanie wyszukiwania używa nieprawidłowej wartości recency_filter year; ugruntowana podpowiedź instruuje model, aby użył wymienionej wartości lub pominął opcjonalne pole. — Nieprawidłowy argument wyszukiwania w raporcie ilustruje obecną procedurę obsługi błędów narzędzi. Schemat sprawia, że ten błąd jest możliwy do uniknięcia; sama awaria by tego nie zapewniła. Oryginalne wywołanie pozostaje w rejestrze i otrzymuje ugruntowaną podpowiedź. Podpowiedź zezwala na użycie wymienionej wartości lub pominięcie, jeśli pole jest opcjonalne; nie wymaga słowa „month” dla każdego żądania.

Tutaj podpowiedź wymienia nieudane wywołanie, zawiera błąd walidacji i instruuje model, aby użył dozwolonej wartości lub pominął pole, jeśli jest ono opcjonalne.

Po oznaczeniu tury trener uruchamia ten sam punkt kontrolny dwukrotnie: raz jako nauczyciel i raz jako uczeń. Nauczyciel widzi wskazówkę, a uczeń nie.

Oba przejścia wykorzystują wymuszanie przez nauczyciela (teacher forcing), w ramach którego przekazujemy modelowi zarejestrowaną sesję zamiast pozwalać mu wybierać nowe tokeny. Przejście w przód nadal generuje pełny rozkład następnego tokena na każdym kroku, ale jest ono zawsze uwarunkowane stałym prefiksem z nagrania, a nie tokenami rozwijania (rollout).

W przykładzie wyszukiwania ten sam model przypisuje znacznie wyższe prawdopodobieństwo słowu „month” i mniejsze słowu „year”, gdy podana jest podpowiedź. Trening wykorzystuje to przesunięcie rozkładu jako cel miękki.

Ten sam model ocenia zalogowaną turę z podpowiedzią i bez niej; odłączone prawdopodobieństwa nauczyciela dostarczają celów KL, podczas gdy CE zakotwicza imitację. — Dwa przejścia, jeden zestaw wag. Oba przejścia oceniają zalogowaną kontynuację; tylko nauczyciel otrzymuje podpowiedzi. Jego odłączone prawdopodobieństwa następnego tokena prowadzą ucznia poprzez forward KL. Oddzielne cele CE zakotwiczą imitację. Obie straty zasilają jedną aktualizację wag. Wcześniejsze podpowiedzi mogą pozostawać w obecnym segmencie nauczyciela; żadne przejście nie generuje zastępczej odpowiedzi treningowej.

Przewidywania nauczyciela są odłączone lub mają zatrzymany gradient: dostarczają cel, ale nie otrzymują aktualizacji w przebiegu nauczyciela. Po przebiegu ucznia jeden krok optymalizatora aktualizuje współdzielony model.

Strata CE traktuje zarejestrowane tokeny wybrane do imitacji jako cele będące prawdą ground-truth i karze model za przypisanie im niskich prawdopodobieństw. Tworzy to twardy cel imitacji.

Na pozycji tokena $i$ niech $p_i(v)$ oznacza prawdopodobieństwo tokena $v$ ucznia w pełnym słowniku $V$ . Zarejestrowany następny token w odpowiedzi lub wywołaniu narzędzia to $y_i$ , jednowymiarowy (one-hot) rozkład docelowy to $r_i$ .

r_i(v)=\mathbf{1}[v=y_i]

Entropia krzyżowa mierzy, jak dobrze uczeń przewiduje ten zarejestrowany token. Przy celu one-hot redukuje się ona do ujemnego logarytmu prawdopodobieństwa przypisanego do $y_i$ .

H(r_i,p_i)=-\sum_{v\in V}r_i(v)\log p_i(v)=-\log p_i(y_i)

Maska CE $m_i^{\mathrm{CE}}$ wynosi $1$ tam, gdzie token powinien być imitowany, oraz $0$ w przeciwnym razie. Sumowanie po wybranych pozycjach daje stratę imitacji.

\mathcal{L}_{\mathrm{CE}}=\sum_i m_i^{\mathrm{CE}}H(r_i,p_i)

Zamiast tego strata KL wykorzystuje pełny rozkład prawdopodobieństwa następnego tokena nauczyciela $q_i$ jako miękki cel korekty. Kontekst nauczyciela obejmuje bieżącą podpowiedź oraz wszelkie wcześniejsze podpowiedzi zachowane w tym segmencie treningowym; kontekst ucznia jest zawsze pozbawiony podpowiedzi.

Maska KL $m_i^{\mathrm{KL}}$ wynosi $1$ tam, gdzie token powinien zostać skorygowany, oraz $0$ w przeciwnym razie; maski CE i KL nie nakładają się na siebie. Na tych pozycjach forward KL karze brak zgody między nauczycielem a uczniem w całym słowniku:

\mathcal{L}_{\mathrm{KL}}=\sum_i m_i^{\mathrm{KL}}D_{\mathrm{KL}}(q_i\Vert p_i)=\sum_i m_i^{\mathrm{KL}}\sum_{v\in V}q_i(v)\log\frac{q_i(v)}{p_i(v)}

Oba człony dzielą jeden mianownik zamiast być normalizowane osobno. Mianownik ten zlicza całkowitą liczbę tokenów wybranych do imitacji w ramach globalnej partii treningowej. Waga $\lambda$ kontroluje wkład treningu korygującego względem imitacji.

Ta współdzielona normalizacja pasuje do interfejsu pojedynczego mianownika naszej infrastruktury treningowej i odtwarza standardową stratę SFT, gdy $\lambda=0$ , upraszczając porównania bazowe. Ponieważ tokeny CE są znacznie liczniejsze niż tokeny KL, użycie współdzielonego mianownika pozwala również uniknąć nadawania pojedynczym tokenom KL nieproporcjonalnie dużych wag w partiach z niewielką liczbą oznaczonych tokenów.

\mathcal{L}=\frac{\mathcal{L}_{\mathrm{CE}}+\lambda\mathcal{L}_{\mathrm{KL}}}{\sum_i m_i^{\mathrm{CE}}}

W zastosowaniu do wcześniejszych przykładów tury zawierające pomyłkę W-3/W-2 oraz nieprawidłowe wywołanie wyszukiwania otrzymują KL. Inna nieoznaczona zawartość asystenta w udanej sesji nadal otrzymuje CE. Inna zawartość asystenta w nieudanej sesji jest zachowywana jako kontekst, ale nie otrzymuje ani CE, ani KL.

Nasze ewaluacje odpowiadają na dwa oddzielne pytania. Po pierwsze, czy podpowiedź faktycznie pomaga modelowi skorygować błąd, gdy podpowiedź jest obecna? Po drugie, czy trening pomaga modelowi uniknąć tego błędu później, bez podpowiedzi? Pierwsze sprawdza, czy podpowiedzi dostarczają użytecznych sygnałów treningowych. Drugie sprawdza, czy model się z nich uczy.

Testujemy pierwsze pytanie przed rozpoczęciem treningu, aby upewnić się, że podpowiedzi faktycznie mogą odwieść model od popełniania błędów.

Wygenerowaliśmy ponownie oznaczone tury opinii użytkowników z podpowiedzią i bez niej, używając tego samego bazowego modelu GLM-5.2 w temperaturze zero. Ślepy sędzia widzi późniejszą skargę, ale ani podpowiedzi, ani warunku, który wygenerował odpowiedź.

W przykładzie W-3 podpowiedź przesuwa prawdopodobieństwo następnego tokena w stronę „3” i z dala od „2” po prefiksie „W-”.

Prawdopodobieństwa następnego tokena po W- przesuwają się w stronę 3, a nie 2, gdy niezmieniony model bazowy otrzymuje podpowiedź. — Podpowiedź zachowuje żądany formularz W-3. Słupki pokazują średnie prawdopodobieństwa następnego tokena w ośmiu przebiegach w przód; wąsy pokazują zaobserwowany zakres, a nie przedział ufności. Oba warunki używają niezmienionego modelu bazowego.

Na większej, wstrzymanej próbie 40 tur popartej wyraźnie stwierdzonymi wcześniejszymi dowodami, udział ocenionych jako naprawione lub zmierzające w dobrym kierunku rośnie z 40,0% bez podpowiedzi do 75,0% z podpowiedzią. Na kolejnych 40 turach popartych wnioskowaną intencją rośnie on z 32,5% do 80,0%.

Walidacja podpowiedzi: wskaźniki naprawionych lub zmierzających w dobrym kierunku przypadków rosną z 40,0% do 75,0% dla wyraźnych dowodów oraz z 32,5% do 80,0% dla intencji wnioskowanych. — Walidacja podpowiedzi, a nie ewaluacja post-training. Te same 40 oznaczonych tur w każdej grupie dowodowej jest generowanych ponownie z podpowiedzią i bez niej przy użyciu niezmienionego GLM-5.2 w temperaturze zero. Sędzia widzi skargę, ale nie podpowiedź ani warunek. Liczby pochodzą ze wskaźników i wielkości próby raportu; przedziały ufności nie są raportowane.

W przykładzie błędu narzędzia wyszukiwania podpowiedź rzeczywiście przenosi masę prawdopodobieństwa z tokena roku na token miesiąca.

Podpowiedź odsuwa prawdopodobieństwa następnego tokena niezmienionego modelu bazowego od roku i kieruje je w stronę dozwolonej wartości miesiąca. — Podpowiedź przesuwa prawdopodobieństwo w stronę dozwolonej wartości. Słupki pokazują średnie prawdopodobieństwa następnego tokena w ośmiu przebiegach w przód; wąsy pokazują zaobserwowany zakres, a nie przedział ufności. Oba warunki używają tego samego modelu bazowego; nie porównuje się żadnego wytrenowanego punktu kontrolnego.

Na większej, wstrzymanej próbie 985 tur wygenerowaliśmy każdą turę czterokrotnie z podpowiedzią i bez niej, używając tego samego modelu bazowego. Ślepy sędzia ocenia, czy każda regeneracja pozwala uniknąć oryginalnego błędu. Podpowiedzi zwiększają unikanie błędów z 75,1% do 93,7%, co stanowi sparowany zysk o 18,6 punktu procentowego, oraz zwiększają udział podejmowania skorygowanego działania z 60,6% do 82,3%. Zyski są największe w przypadku błędów, z którymi samo powtarzalne próbkowanie radzi sobie z trudem.

Na 985 wstrzymanych oznaczonych turach błędów narzędzi podpowiedzi zwiększają unikanie błędów z 75,1% do 93,7%, a wskaźniki skorygowanych działań z 60,6% do 82,3%. — Walidacja podpowiedzi dotyczących błędów narzędzi na 985 wstrzymanych oznaczonych turach, z czterema regeneracjami na warunek. Słupki pokazują unikanie błędów i wskaźniki skorygowanych działań dla niezmienionego modelu bazowego, z podpowiedziami i bez nich. Unikanie docelowego błędu nie gwarantuje sukcesu wywołania narzędzia ani zadania.

Następnie testujemy, czy wytrenowany model popełnia mniej błędów bez otrzymywania podpowiedzi. Oceniamy model podstawowy i różne checkpointy po treningu na offline’owych zadaniach benchmarkowych oraz w aktywnych sesjach użytkowników, sprawdzając, czy występuje mniej awarii narzędzi i mniejsze niezadowolenie użytkowników.

Ewaluacja offline wykorzystuje BrowseComp, Finch, WideSearch, DRACO, DSQA, SpreadsheetBench, HLE, reprezentatywny zestaw zadań Computer oraz sprawdza ładowanie skillów, przegląd dokumentów i cytowania w tekście. Mierzymy udział wywołań narzędzi, których wyniki są wyraźnie oznaczane jako błędy we wszystkich trajektoriach ewaluacji.

W tych ewaluacjach zarejestrowany wskaźnik błędów narzędzi wynosił 2,79% dla standardowego GLM 5.2, 1,35% dla punktu kontrolnego zawierającego wyłącznie RFT oraz 0,87% dla punktu kontrolnego RFT-plus-OPSD. Te punkty kontrolne były trenowane na różnych danych, więc nie jest to ablacja OPSD na dopasowanych danych. Wyniki benchmarków na poziomie zadań były mieszane, więc mniejsza liczba błędów narzędzi sama w sobie niekoniecznie przekłada się na szeroką poprawę sukcesu zadań.

Wskaźniki błędów narzędzi rejestrowane offline: 2,79% dla standardowego GLM 5.2, 1,35% dla samego RFT oraz 0,87% dla RFT plus OPSD; dane treningowe różnią się. — Wskaźniki błędów narzędzi offline dla punktów kontrolnych standardowego GLM-5.2, samego RFT oraz RFT-plus-OPSD. Dane treningowe różnią się między punktami kontrolnymi; nie jest to kontrolowana ablacja.

W przypadku modelu GLM-5.2 przeprowadziliśmy dwa osobne testy A/B z udziałem około stu tysięcy użytkowników w każdym warunku. W pierwszym z nich wczesny punkt kontrolny RFT plus OPSD miał nieco niższy wskaźnik awaryjności narzędzi niż standardowy model GLM 5.2 (2,82% w porównaniu do 2,94%), jednak różnica nie była statystycznie istotna.

W późniejszym teście porównaliśmy dwa punkty kontrolne RFT-plus-OPSD: wcześniejszy (punkt kontrolny pierwszy) i późniejszy (punkt kontrolny drugi). Błędy wywołań narzędzi spadły z 2,24% do 1,77% wywołań ze zarejestrowanym statusem. Była to statystycznie istotna względna redukcja o 21,2%. Nie porównaliśmy bezpośrednio punktu kontrolnego drugiego ze standardowym GLM 5.2 online.

Wyniki opinii użytkowników były mniej jednoznaczne. W drugim eksperymencie z modelem GLM-5.2 średnie prawdopodobieństwo silnego niezadowolenia (średniego lub wysokiego) wynosiło 2,58% dla pierwszego punktu kontrolnego i 2,54% dla drugiego, przy czym różnica nie była statystycznie istotna.

Dwa osobne testy A/B online; tylko późniejsze porównanie punktów kontrolnych wykazuje istotne zmniejszenie liczby awarii narzędzi, przy braku istotnej zmiany niezadowolenia MID+. — Dwa osobne testy A/B na żywo modelu GLM-5.2. Punkt kontrolny 1 jest porównywany ze standardowym modelem GLM-5.2; punkt kontrolny 2 jest porównywany z punktem kontrolnym 1. W tych dwóch testach tylko późniejsze zmniejszenie awaryjności narzędzi jest statystycznie istotne. Wskaźniki MID+ stanowią średnie szacowane prawdopodobieństwa średniego lub wysokiego niezadowolenia, a nie liczbę skarg.

W przypadku GLM-5.3 porównaliśmy punkt kontrolny po treningu bezpośrednio z bazowym GLM-5.3. Liczba błędów wywołań narzędzi spadła z 3,56% do 2,38% wywołań z zarejestrowanym statusem, co stanowi względne zmniejszenie o 33,04%. Wskaźnik MID+, będący średnim szacowanym prawdopodobieństwem średniego lub wysokiego niezadowolenia, spadł z 4,12% do 3,41%, co stanowi względne zmniejszenie o 17,2%. Obie obniżki były statystycznie istotne.

Test A/B GLM-5.3: wskaźnik błędów narzędzi spada z 3,56% do 2,38%, a wskaźnik MID+, czyli średnie szacowane prawdopodobieństwo średniego lub wysokiego niezadowolenia, spada z 4,12% do 3,41%. Względne spadki skorygowane metodą CUPED wynoszą odpowiednio 33,04% i 17,16%. Oba przedziały sekwencyjne 95% nie zawierają zera; główna metryka zaangażowania nie jest istotna. — Porównanie wytrenowanego modelu GLM-5.3 z bazowym GLM-5.3 w osobnym teście A/B online. Wskaźniki błędów narzędzi i MID+, zmiany względne oraz 95% sekwencyjne przedziały ufności wykorzystują korektę CUPED. Oba spadki są statystycznie istotne. Wskaźniki MID+ oznaczają średnie szacowane prawdopodobieństwa średniego lub wysokiego niezadowolenia w kwalifikujących się ocenionych wątkach kontynuacji, a nie liczbę skarg. Wskaźniki błędów narzędzi nie uwzględniają wywołań bez zarejestrowanego statusu sukcesu lub porażki.

Główną ideą jest uczenie się na poziomie decyzji, a nie tylko sesji.

Udany wynik może ukryć błędy, a nieudana sesja nadal może ujawnić, jak się poprawić. Zachowujemy użyteczne zachowanie z udanych sesji jako kotwicę, używamy skarg i błędów narzędzi do identyfikacji awarii, których można było uniknąć, i trenujemy model w kierunku przewidywań, jakie generuje, gdy te błędy i korekty zostaną wyraźnie zdefiniowane. Sukces zapewnia zachowanie, które należy zachować; porażka zapewnia kierunek poprawy.

Użytkowanie w świecie rzeczywistym czyni to podejście szczególnie użytecznym. Prawdziwi użytkownicy przynoszą cele, ograniczenia i przepływy pracy, które trudno przewidzieć w środowisku syntetycznym. Ich korekty ujawniają wymagania, które model pominął, podczas gdy błędy narzędzi obnażają przepaść między tym, co model usiłował zrobić, a tym, na co pozwala środowisko. Sygnały te uzupełniają trening oparty na wynikach: zamiast pytać tylko, czy zadanie zakończyło się sukcesem, możemy zapytać, gdzie model popełnił błąd i jakie informacje mogły pomóc mu podjąć lepszą decyzję.

Ograniczenia są równie ważne. Sędziowie mogą się mylić, a skorygowanie jednej tury nie gwarantuje pomyślnego zakończenia całego zadania. Celem nie jest wyłącznie agent, który wraca do działania po korekcie. Chodzi o agenta, który potrzebuje korekt rzadziej.

BibTeX

@online{perplexity2026LearningFromRealWorldExperience,
  author = {{Perplexity} and Senzeyu Zhang and Chuan Wang and Hang Wu and Hao Zhang and Yuan Liang and Yunfan Zhong and Phi Hoang and Claire Beamer and Jeremy Yang and Andrew Wilson and Denis Yarats},
  title = {{Learning from real-world experience}},
  date = {2026-09-21},
  url = {https://www.perplexity.ai/hub/blog/learning-from-real-world-experience}
}

Od danych syntetycznych do danych ze świata rzeczywistego

Naśladuj dobre kroki, koryguj złe

Przykład: jedna sesja może nauczyć obu lekcji

Jak działa trening

Wybierz sesje, a następnie oceń wynik

Znajdź błędy na podstawie opinii użytkowników

Znajdź błędy na podstawie błędów narzędzi

Dwa przejścia w przód

Funkcja straty

Strata CE

Strata KL

Połączona strata

Co pokazują ewaluacje

Podpowiedzi mogą odwieźć model od popełniania błędów

Opinie użytkowników

Błędy narzędzi

Niezawodność narzędzi i opinie użytkowników po trenowaniu

Ewaluacja offline

Ewaluacja online: GLM-5.2

Ewaluacja online: GLM-5.3

Wniosek

Cytat