Dystylacja Amazon SageMaker AI zbliża agenta zakupowego 4B do jego nauczyciela

AWS opublikował 2 listopada przykład dystylacji Amazon SageMaker AI, pokazujący, że agent zakupowy 4B zbliża się wynikami benchmarkowymi do większego modelu nauczycielskiego. Dystylacja wiedzy polega na trenowaniu modelu ucznia tak, by naśladował wyniki modelu nauczyciela. Rezultat odpowiada na praktyczne napięcie: powtarzające się decyzje podejmowane przez agenta mogą sprawić, że obsługa zdolnego modelu będzie kosztowna.

Według AWS poddany dystylacji Qwen3.5-4B osiągnął średni wskaźnik sukcesu 54,1% w ShoppingBench, wobec 29,7% przed treningiem i 54,0% dla jego nauczyciela GLM-5.3 przy deterministycznym generowaniu. Ocena objęła 324 odłożone problemy testowe. AWS opisuje pojedyncze uruchomienie, przy spodziewanej zmienności.

Główne porównanie dotyczy powtarzanego wnioskowania z użyciem modelu frontierowego oraz początkowej inwestycji w wyspecjalizowany model ucznia. Anthropic oferuje inny punkt odniesienia: kierowanie rutynowych zapytań do mniejszych modeli przy jednoczesnym rezerwowaniu większych modeli dla trudniejszych zadań. Przykład AWS rodzi pokrewne pytanie. Jaka część powtarzalnego zadania agenta wymaga ogólnej inteligencji, a jaka staje się odtwarzalnym zachowaniem, gdy istnieją udane przykłady?

Dystylacja Amazon SageMaker AI uwzględnia specjalizację w ocenie

AWS przedstawia dowody dotyczące wyspecjalizowanego agenta zakupowego, a nie zastępstwa dla ogólnych możliwości modeli frontierowych.

W ramach procesu dystylacji agenta zakupowego zachowywane są udane trajektorie nauczyciela, czyli sekwencje działań i obserwacji. Trening wykorzystuje dystylację wiedzy na poziomie sekwencji, która używa wygenerowanych sekwencji jako przykładów szkoleniowych, i odbywa się na infrastrukturze serverless. Kod aplikacji nadal wykonuje działania narzędziowe. AWS informuje również o pewnej utracie ogólnej zdolności do wykonywania instrukcji.

Te szczegóły wyznaczają granice tego ogłoszenia. Benchmark zakupowy testuje zdefiniowane środowisko z rozpoznawalnymi zadaniami i systemem punktacji. Asystent korporacyjny działa w granicach ustalonych przez jego twórców. Im bardziej granice te przypominają stabilne, powtarzalne zadanie, tym bardziej istotny staje się ten eksperyment.

Rozważmy różnicę między rekomendowaniem produktu a obsługą nieograniczonego żądania klienta. Rekomendacja może podlegać wyraźnym ograniczeniom, które system weryfikuje względem informacji katalogowych. Nieograniczone żądanie może wymagać doprecyzowania, interpretacji zasad lub eskalacji. Podobne interfejsy mogą skrywać bardzo odmienne wymagania wobec modelu bazowego.

Dla zespołów produktowych użyteczna interpretacja jest więc warunkowa. Jeżeli powtarzalna praca podlega wzorcom możliwym do nauczenia, przykłady wygenerowane przez nauczyciela warto porównać z dalszym użyciem modelu frontierowego. Jeżeli żądania często wykraczają poza te wzorce, szersze możliwości modelu pozostają częścią wartości produktu.

To rozróżnienie zmienia sposób, w jaki kupujący powinni odczytywać wynik benchmarku. Dorównanie nauczycielowi w zadaniu nie dowodzi, że modele są wymienne. Ustanawia kandydata do zastąpienia w testowanych warunkach. Kolejna decyzja dotyczy tego, czy warunki te odpowiednio reprezentują zamierzoną usługę.

Istnieje też różnica między wykazaniem kompetencji w zadaniu a potwierdzeniem akceptowalnej jakości produktu. Wynik benchmarku opisuje działanie zgodnie z jego zasadami oceny. Właściciel produktu musi zdecydować, które błędy mają znaczenie, które wymagają interwencji, a które czynią usługę nieodpowiednią do wdrożenia.

W przypadku asystenta zakupowego błędna rekomendacja może powodować niedogodności lub szkodzić zaufaniu. Proces, który zatwierdza nieodwracalne działanie, wymagałby innego progu akceptacji. Sam benchmark nie może wybrać tego progu za operatora.

Wartość informacyjna tej wiadomości polega na wystarczająco konkretnym przedstawieniu tej substytucji, aby można ją było ocenić. Zespół może porównać model ogólny z wyszkolonym specjalistą wokół tej samej funkcji biznesowej. Tworzy to bardziej użyteczną dyskusję niż porównywanie rozmiarów modeli bez określenia zadania.

Wywiera to również presję na znane założenie zakupowe: model wybrany dla udanego prototypu powinien pozostać odpowiedzialny za każdą decyzję produkcyjną. Eksperyment daje zespołom powód, by ponownie rozważyć to założenie. Nie zwalnia ich jednak z odpowiedzialności za walidację zastępstwa.

Powtarzalne decyzje wywierają presję kosztową na całe zadanie

Wydajność agenta SageMaker należy oceniać na podstawie kosztu ukończenia akceptowalnego zadania, uwzględniającego błędy i odzyskiwanie sprawności.

Wywołanie modelu jest tylko jednym elementem pracy agenta. Agent, czyli system wybierający działania w odpowiedzi na obserwacje, może przechodzić przez kilka decyzji. Każda decyzja tworzy kolejną okazję do użytecznego postępu, niepotrzebnej pracy lub błędu.

To sprawia, że tańsza pojedyncza odpowiedź jest niepełną miarą ekonomiczną. Mniejszy model, który potrzebuje wielokrotnych ponowień, może utracić pozorną przewagę. Droższy model, który niezawodnie kończy zadanie, może pozostać preferowany. Właściwe porównanie prowadzi od żądania użytkownika do akceptowalnego wyniku.

W przypadku zespołów rozważających specjalizację rachunek powinien obejmować generowanie przykładów, przegląd danych, trening, ocenę, hosting i utrzymanie. Koszty te występują w różnych momentach. Początkową inwestycję łatwiej uzasadnić, gdy wynikowe zachowanie obsługuje powtarzalny popyt bez częstej wymiany.

Znaczenie mają również wzorce ruchu. Usługa używana sporadycznie i usługa stale obciążona stawiają odmienne wymagania wobec sposobu hostowania. Zespoły powinny porównać rzeczywiste obciążenie z przepustowością, którą zamierzają utrzymywać. Sam rozmiar modelu nie może rozstrzygnąć tego porównania.

Presja najsilniej dotyczy właścicieli produktów, którzy mają już działające agenty, lecz mierzą się z niepewnymi marżami operacyjnymi. Muszą zachować użyteczne zachowanie, ograniczając jednocześnie zasoby potrzebne do jego dostarczenia. To węższy problem niż znalezienie najzdolniejszego dostępnego modelu.

Zespoły inżynieryjne stoją przed odpowiadającą temu zmianą odpowiedzialności. Kontynuowanie pracy z hostowanym modelem ogólnym pozostawia dużą część rozwoju modelu poza zespołem aplikacyjnym. Utrzymywanie specjalisty wprowadza odpowiedzialność za przykłady, decyzje ewaluacyjne i zmiany wersji. Każda ocena finansowa powinna uwzględniać tę dodatkową pracę.

Alternatywa nie ogranicza się do zastąpienia całego modelu. Wskazówki Anthropic dotyczące architektury agentów zalecają zaczynanie od prostych projektów i dodawanie złożoności, gdy jest potrzebna. Opisują też kierowanie żądań zgodnie z ich wymaganiami. Daje to użyteczny punkt porównania dla kupujących rozważających wyszkolonego specjalistę.

Routing, czyli kierowanie różnych żądań na różne ścieżki przetwarzania, zachowuje dostęp do szerszych możliwości dla trudnych przypadków. Dystylacja próbuje poprawić zachowanie mniejszego modelu w samym powtarzalnym zadaniu. Podejścia te mogą współistnieć, choć ich łączenie wprowadza kolejną decyzję wymagającą oceny.

Pytanie operacyjne brzmi, gdzie kończy się odpowiedzialność specjalisty. Usługa potrzebuje dającego się uzasadnić sposobu rozpoznawania nieobsługiwanych żądań lub braku postępu. W przeciwnym razie kolejne próby mogą zużywać zasoby, opóźniając pomoc, której użytkownik faktycznie potrzebuje.

Ta analiza nie ustanawia uniwersalnego twierdzenia o oszczędnościach. Identyfikuje miarę, która mogłaby je potwierdzić: trwałe ograniczenie całkowitych zasobów przypadających na akceptowalne ukończenie zadania. Miara ta powinna uwzględniać pomoc człowieka, gdy automatyczna ścieżka zawodzi.

Dla nabywców korporacyjnych zmienia to rodzaj dowodów, o które warto prosić. Demonstracja płynnych odpowiedzi odpowiada na pytanie o możliwości. Zapisy dotyczące ukończenia, odzyskiwania sprawności i nakładu operacyjnego odpowiadają na pytanie o wdrożenie. To drugie określa, czy specjalizacja przynosi korzyść ekonomiczną.

Udane przykłady stają się zasobem, który zespoły muszą utrzymywać

Strategiczna wartość dystylacji zależy od tego, czy udane zachowanie można uchwycić, sprawdzić i ponownie wykorzystać.

Podstawowa idea poprzedza obecny rynek agentów. Yoon Kim i Alexander Rush badali dystylację wiedzy na poziomie sekwencji w tłumaczeniu maszynowym w 2016 roku. Ich praca analizowała przenoszenie zachowania generowania sekwencji z większych systemów do mniejszych modeli. Powiązanie historyczne ma znaczenie, ponieważ mechanizm ten ma ugruntowaną genealogię badawczą.

Nie wynika z tego, że rezultaty automatycznie przenoszą się między dziedzinami. Tłumaczenie i interaktywne używanie narzędzi mają odmienne warunki błędu. Istotnym powiązaniem jest wzorzec treningowy: silniejszy system dostarcza wyniki, które stają się nadzorem dla innego modelu.

W przypadku produktu agentowego sugeruje to zmianę w tym, co zespoły powinny uznawać za zasób wielokrotnego użycia. Zasobem nie jest po prostu archiwum transkrypcji. Jest nim zbiór przykładów, których dane wejściowe, działania, obserwacje i wyniki wspierają określony cel treningowy.

Przykład może wydawać się wiarygodny, nie będąc użytecznym nadzorem. Dopracowana odpowiedź końcowa może ukrywać niepotwierdzone założenie. Udany wynik może zależeć od informacji niedostępnych podczas wdrożenia. Przeglądanie wyłącznie ostatniej wiadomości pominęłoby te rozróżnienia.

Tworzy to pracę dla osób rozumiejących zadanie biznesowe. Muszą one zdefiniować, co oznacza sukces, zanim automatyczny filtr lub recenzent będzie mógł go egzekwować. Bez tej definicji zwiększanie liczby przykładów może poszerzać niejednoznaczność zamiast poprawiać ucznia.

Pojawia się również kwestia własności. Jeśli zadanie się zmienia, organizacja musi wiedzieć, które przykłady pozostają aktualne. Zmienione narzędzie, nowa polityka lub inna struktura katalogu mogą zmienić zachowanie warte naśladowania. Dane treningowe wymagają zatem procesu utrzymania.

W przypadku hipotetycznego wewnętrznego asystenta inżynieryjnego proces ten mógłby obejmować sprawdzanie, który dokument był autorytatywny w chwili zarejestrowania przykładu. Ten sam problem dotyczy przeszukiwalnej bazy wiedzy: jakość wyszukiwania zależy częściowo od udostępnionych informacji. Przykłady treningowe wymagają porównywalnej uwagi poświęconej pochodzeniu danych.

Tego powiązania nie należy mylić z twierdzeniem dotyczącym procesu treningowego konkretnego produktu. To praktyczna analogia. Zarówno systemy wyszukiwania, jak i wyspecjalizowane modele zależą od decyzji o tym, które informacje zasługują na zaufanie.

Metoda treningowa wpływa również na zakres eksperymentu. Adaptacja niskiego rzędu, czyli LoRA, trenuje kompaktowe aktualizacje, pozostawiając pierwotne wagi modelu bez zmian. Jej autorzy badali sposób ograniczenia liczby parametrów wymagających treningu podczas adaptacji.

Dla kupujących oznacza to, że specjalizację można oceniać bez zakładania, iż każda waga modelu musi się zmienić. Nie eliminuje to jednak zarządzania modelem. Zaadaptowane zachowanie nadal potrzebuje własnej tożsamości, testów i decyzji o wydaniu.

Możliwa do obrony przewaga konkurencyjna prawdopodobnie nie będzie więc polegać wyłącznie na wyborze modelu ucznia. Silniejsza przewaga łączyłaby wiedzę o zadaniu, wiarygodne przykłady, znaczącą ocenę i niezawodne zachowanie aplikacji. Te elementy wyjaśniają, dlaczego skopiowanie receptury treningowej nie prowadzi automatycznie do odtworzenia użytecznego produktu.

Zbliżona średnia pozostawia istotne pytania dotyczące niezawodności bez odpowiedzi

Kompromisy związane z destylacją w SageMaker stają się widoczne, gdy ocena wykracza poza nagłówkową średnią.

Średnia może podsumowywać wydajność, jednocześnie ukrywając różnice między kategoriami zadań. Dla nabywcy ważne jest pytanie, czy pozostałe błędy koncentrują się tam, gdzie produkt stwarza największe ryzyko. Równe wyniki ogólne nie oznaczają równych wzorców błędów.

Model wyspecjalizowany może dobrze radzić sobie z powtarzalnymi żądaniami, a jednocześnie mieć trudności z nieznanymi kombinacjami ograniczeń. Model ogólny może popełniać inne błędy. Przed zastąpieniem któregokolwiek systemu zespół powinien przeanalizować nieudane przypadki i ustalić, czy alternatywa poprawia błędy, które mają znaczenie.

Systemy interaktywne wprowadzają dodatkową komplikację. Działanie modelu zmienia to, co obserwuje on w kolejnym kroku. Jeśli wczesne działanie prowadzi do nietypowej sytuacji, późniejsze decyzje muszą poradzić sobie z tym nowym kontekstem. Ocena odizolowanych odpowiedzi nie jest w stanie w pełni uchwycić tej zależności.

Badania Stéphane’a Rossa, Geoffreya Gordona i J. Andrew Bagnella dotyczą tego zagadnienia w sekwencyjnym uczeniu przez naśladowanie. Ich praca wyjaśnia, dlaczego uczenie się na podstawie zachowań eksperta staje się trudne, gdy wcześniejsze przewidywania wpływają na późniejsze obserwacje. Stanowi ona istotny kontekst teoretyczny, a nie niezależną ocenę wyniku AWS.

W tym zastosowaniu problem jest prosty. Przykłady skutecznego zachowania eksperta nie muszą obejmować sytuacji powstałych wskutek błędów ucznia. Ocena wdrożenia powinna więc badać zarówno odzyskiwanie sprawności, jak i skuteczne naśladowanie.

Wyobraźmy sobie asystenta zakupowego przeszukującego nieodpowiednią kategorię. Kolejne użyteczne działanie może polegać na poprawieniu wyszukiwania, a nie na dalszym analizowaniu nieistotnych wyników. Model, który kompetentnie obsługuje zwykłe żądania, nadal potrzebuje sposobu na rozpoznanie, że obrana ścieżka zawiodła.

To ilustracyjny scenariusz błędu, a nie zgłoszony wynik eksperymentu AWS. Pokazuje, dlaczego ocena produktu powinna odróżniać dotarcie do odpowiedzi od odzyskania sprawności po błędzie. Oba te elementy wpływają na doświadczenie użytkownika i zużywane zasoby.

Ogólne wykonywanie instrukcji wymaga odrębnej uwagi. Specjalista może lepiej radzić sobie z wyznaczonym zadaniem, a jednocześnie mniej niezawodnie reagować na inne polecenia. To, czy taka zmiana jest akceptowalna, zależy od tego, jakie instrukcje musi respektować otaczający produkt.

Ocena wykonywania instrukcji, czyli IFEval, wykorzystuje instrukcje z wymaganiami, które można sprawdzać mechanicznie, aby ocenić tę zdolność. Jej autorzy opisują alternatywę dla całkowitego polegania na ocenach ludzi lub preferencjach innego modelu. Takie testy mogą uzupełniać ocenę zadań, nie zastępując jej.

Szersza lekcja jest taka, że ocena potrzebuje kilku spojrzeń na ten sam system. Sukces zadania sprawdza, czy osiągnięto pożądany rezultat. Kontrole instrukcji badają zgodność z wyraźnymi wymaganiami. Analiza odzyskiwania sprawności bada zachowanie po tym, jak postęp przebiega niewłaściwie.

Żaden z tych pomiarów samodzielnie nie potwierdza gotowości do nieograniczonego wdrożenia. Zespoły muszą powiązać każdy wskaźnik z decyzją o akceptacji. Nieudana instrukcja formatowania i nieautoryzowane działanie nie powinny znikać w tej samej, nierozróżnionej średniej.

Właśnie tutaj ostrożna interpretacja wzmacnia tę historię. Benchmark sprawia, że specjalizacja staje się warta zbadania. Pozostawia operatorom konkretne pytania dotyczące pokrycia, odzyskiwania sprawności i akceptowalnego zachowania.

Hosting specjalisty zmienia warunki operacyjne

Mniejszy model przesuwa odpowiedzialności w obrębie systemu, zamiast je usuwać.

Ekonomiczna atrakcyjność specjalisty może skłaniać zespoły do skupiania się na artefakcie modelu. W środowisku produkcyjnym artefakt działa wewnątrz usługi wyposażonej w narzędzia, poświadczenia, źródła danych i oczekiwania użytkowników. Te otaczające elementy nadal określają, jakie działania stają się możliwe.

Model może proponować działanie, ale kod aplikacji musi zdecydować, jak ta propozycja staje się wykonaniem. To rozdzielenie daje operatorom miejsce do walidowania argumentów, egzekwowania uprawnień i obsługi niedostępnych usług. Jakość treningu nie zastępuje tych mechanizmów kontroli.

W przypadku produktu rekomendacyjnego granicą może być dostęp tylko do odczytu informacji katalogowych. W innym produkcie narzędzie może modyfikować rekord lub inicjować transakcję. Odpowiednie zasady wykonania zależą od tej różnicy, niezależnie od wielkości modelu.

Ma to znaczenie dla zakupów, ponieważ elastyczność hostingu może wiązać się z dodatkową odpowiedzialnością operacyjną. Zespół potrzebuje procesu wydań dla specjalisty, sposobu porównywania wersji oraz reakcji na pogorszenie zachowania. Te wymagania powinny wejść do pierwotnego uzasadnienia biznesowego.

Zmiany wersji zasługują również na szerszą definicję niż zastępowanie wag modelu. Zmiana opisu narzędzia może zmienić sposób, w jaki model wybiera działania. Zmiana informacji zwracanych przez wyszukiwanie może zmienić jego późniejsze decyzje. Oceniany system obejmuje te interfejsy.

Przydatny zapis wydania powinien zatem wskazywać model, przykłady treningowe, kontrakty narzędzi i warunki oceny. Celem jest praktyczna odtwarzalność. Gdy pojawia się błąd, inżynierowie muszą ustalić, która zmiana go wprowadziła i która wcześniejsza konfiguracja nadal jest odpowiednia.

Ta sama dyscyplina pomaga uniknąć mylącego porównania. Jeśli specjalista otrzymuje lepszy interfejs niż model bazowy, wynik odzwierciedla coś więcej niż adaptację modelu. Taka poprawa nadal może być wartościowa, ale nabywcy powinni rozumieć, co ją spowodowało.

Zespół przedsiębiorstwa powinien również odróżniać przewidywalną, powtarzalną pracę od żądań wymagających szerokiej interpretacji. Specjalista może mieć jasno określoną rolę operacyjną, nie stając się jedynym modelem w usłudze. Wyraźne utrzymanie tej roli ułatwia późniejszą ocenę twierdzeń dotyczących wydajności.

Właściciel biznesowy staje wtedy przed bardziej konkretnym kompromisem. Specjalizacja daje możliwość ograniczenia powtarzalnego zapotrzebowania na inferencję. W zamian organizacja bierze odpowiedzialność za utrzymanie węższego zestawu zachowań wobec zmieniających się wymagań.

Wydajność agentów SageMaker staje się znacząca, gdy działa cały ten układ. Model, który wypada dobrze, lecz wymaga ciągłej ręcznej naprawy, może nie poprawić usługi. Węższy model o stabilnych obowiązkach i możliwym do opanowania utrzymaniu może to zrobić.

To samo rozumowanie dotyczy doświadczenia programistów. Prototyp może tolerować dochodzenie przyczyn, gdy coś idzie nie tak. Zespół produkcyjny potrzebuje obserwowalnych błędów, odtwarzalnych konfiguracji i jasnej ścieżki eskalacji. Przejrzystość operacyjna jest częścią propozycji wartości.

Obserwuj replikację, ekonomikę ukończonych zadań i zmieniające się obciążenia

Kolejne użyteczne dowody powinny badać odtwarzalność, wartość operacyjną i trwałość — w tej kolejności.

Po pierwsze, obserwuj powtarzane oceny prowadzone w stałych warunkach oraz z wyraźnie rozdzielonym materiałem treningowym i testowym. Pokażą one, czy zgłoszona zależność utrzymuje się przy zmianach próbkowania i zróżnicowaniu treningu. Niezależna reprodukcja zwiększyłaby zaufanie bardziej niż kolejna relacja z tego samego eksperymentu.

Ważnym sygnałem jest spójność, a nie pojedynczy korzystny wynik. Jeśli porównywalni uczniowie wielokrotnie zbliżają się do nauczyciela w udokumentowanych warunkach, argument za specjalizacją zadań staje się silniejszy. Jeśli wyniki są bardzo zróżnicowane, operatorzy będą musieli zrozumieć, które warunki decydują o sukcesie.

Replikacja powinna również zachować granice porównania. Nowy eksperyment dotyczący innego zadania może być wartościowy, nie potwierdzając bezpośrednio pierwotnego wyniku. Jasne raportowanie powinno odróżniać odtwarzanie ustalenia od rozszerzania ogólnej idei.

Po drugie, obserwuj pomiary śledzące żądania aż do ich ukończenia. Powinny one obejmować nieudane próby, eskalację oraz wysiłek potrzebny do utrzymania wytrenowanego systemu. Takie dowody połączyłyby wydajność modelu z ekonomiczną motywacją stojącą za destylacją.

Istotnym wynikiem jest trwała przewaga operacyjna przy akceptowalnym poziomie jakości. Sama tańsza odpowiedź jej nie potwierdza. Mniejszy całkowity wysiłek na ukończone zadanie stanowiłby silniejszy powód, by zespół produktowy zmienił architekturę.

Nabywcy powinni sprawdzić, kiedy zebrano te pomiary. Spokojne okresy, szczytowe zapotrzebowanie i zmieniająca się mieszanka żądań mogą tworzyć odmienne warunki. Przydatny opis operacyjny wyjaśnia obciążenie wystarczająco dobrze, aby inna organizacja mogła ocenić jego znaczenie.

Po trzecie, obserwuj, jak specjaliści reagują, gdy zmienia się środowisko. Zmienione narzędzia, zaktualizowane katalogi, nieznane żądania i nowe reguły biznesowe mogą ujawnić zależność od przykładów treningowych. Dowody dotyczące adaptacji wyjaśniłyby, jak trwała staje się początkowa inwestycja.

Jeśli zespół może aktualizować specjalistę przy jednoczesnym zachowaniu zaakceptowanego zachowania, długoterminowe uzasadnienie się poprawia. Jeśli niewielkie zmiany wymagają rozległej rekonstrukcji, utrzymanie będzie miało większą wagę w decyzji. To centralne pytanie o trwałość wytrenowanego agenta.

W nadchodzących miesiącach sygnały te zasługują na większą uwagę niż kolejna odizolowana pozycja w rankingu. Destylacja Amazon SageMaker AI dostarczyła konkretnego powodu do oceny wyspecjalizowanych uczniów. Kolejny etap wymaga dowodów łączących tę zdolność z niezawodnym działaniem usługi.

Dla programistów praktyczną odpowiedzią jest zidentyfikowanie powtarzalnego zadania z możliwym do obrony warunkiem sukcesu. Porównaj jego obecny system ze specjalistą przy tych samych narzędziach i założeniach dotyczących obciążenia. Przeanalizuj błędy, zanim potraktujesz zbliżoną średnią jako pozwolenie na zastąpienie istniejącego modelu.

Dla nabywców przedsiębiorstw: poproś dostawców o wyjaśnienie, gdzie kończy się odpowiedzialność specjalisty i jak utrzymują oni tę granicę. Poproś o dowody dotyczące odzyskiwania sprawności, zmian i ekonomiki ukończonych zadań obok wyników benchmarków. Włącz do tej dyskusji osoby definiujące akceptowalne rezultaty. Które powtarzalne decyzje zasługują na wytrenowanego specjalistę, a które nadal uzasadniają szersze możliwości modelu?