Czy inteligentniejsze modele zmniejszą znaczenie narzędzi agenta, czy sprawią, że staną się ważniejsze?

Kilka lat temu udoskonalanie funkcji opartych na sztucznej inteligencji oznaczało głównie poprawę samego modelu: wybór silniejszego modelu, jego dopasowanie, dostarczanie mu czystszych danych oraz udostępnienie go za pośrednictwem API. Dziś system produkcyjny oparty na modelu może obejmować funkcje wyszukiwania, pamięci, narzędzi, planowania, oceny, możliwości obserwacji, zasad bezpieczeństwa, prób ponownych, zarządzania kontekstem oraz kilku współpracujących agentów, a ogólnym terminem na tę warstwę otaczającą model nazywa się „harness”. To rodzi praktyczne pytanie dla każdego, kto decyduje, gdzie poświęcić czas na prace inżynieryjne: jeśli modele będą się dalej doskonalić, czy ta warstwa stanie się mniej istotna, czy też będzie najważniejszą częścią systemu? Ten tekst omawia obie strony tego argumentu i kończy się sposobem na określenie, które elementy własnego „harness” najprawdopodobniej się zmniejszą, a które będą rosły.

Czym jest harness i czym nie jest

Pas jest oprogramowaniem otaczającym model, które umożliwia mu niezawodne wykonywanie zadań. Model dostarcza rozumowanie; pas tworzy warunki, w których to rozumowanie przynosi użyteczne rezultaty. W praktyce obejmuje on kilka aspektów: dostęp do narzędzi i API; pobieranie danych, kontekst oraz pamięć; dzielenie pracy na zaplanowane kroki i śledzenie stanu; sprawdzanie wyników, przekazywanie błędów i ponawianie prób; egzekwowanie uprawnień i ograniczeń; a także mierzenie i obserwowanie tego, co się dzieje.

Kluczowym punktem jest to, że narzędzie takie jak harness nie ma na celu uczynienia modelu inteligentniejszym. Jego celem jest stworzenie systemu, który jako całość będzie bardziej zdolny, bardziej niezawodny i bezpieczniejszy. Weźmy pod uwagę przekształcanie tekstu na zapytania SQL. Model może już umieć pisać takie zapytania. Harness przekazuje mu schemat bazy danych, umożliwia mu sprawdzenie metadanych tabeli, wykonywa zapytanie, łapie błędy, zwraca wynik lub komunikat o błędzie, uruchamia ponowną próbę w razie potrzeby i pomaga ocenić, czy ostateczna odpowiedź jest wystarczająco dobra. Model rozumuje; harness dostarcza pętlę, w ramach której to rozumowanie odbywa się. Ta pętla ma największe znaczenie, gdy model robi coś więcej niż tylko wytwarza tekst.

Aby lepiej zrozumieć, jak rozkładają się obowiązki między modelem a narzędziem wspomagającym w pojedynczym agencie, zapoznaj się z tekstem na temat tego, skąd pochodzi niezawodne zachowanie sztucznej inteligencji. Tutaj skupiamy się na tym, jak ten rozkład zmienia się z upływem czasu.

Argumenty za lżejszym narzędziem wspomagającym

Całkowicie uzasadnione jest oczekiwanie, że lepsze modele będą potrzebować mniej wsparcia. Wyobraź sobie model, który niezawodnie wykonywałby wszystkie poniższe zadania:

• Przestrzega złożonych instrukcji.
• Zachowuje to, co istotne.
• Wybiera odpowiednie narzędzie.
• Planuje zadania składające się z wielu kroków.
• Odzyskuje funkcjonalność po awarii.
• Kontroluje własny wynik.
• Rozpoznaje momenty, gdy nie jest pewien.
• Pilnuje stanu podczas długotrwałych zadań.

Z takim modelem duża część dzisiejszych mechanizmów koordynacji wydaje się zbędna. Silniejsze mechanizmy rozumowania zmniejszają potrzebę wyraźnych warstw planowania. Lepsze wykorzystanie narzędzi natywnych ogranicza konieczność ręcznego projektowania logiki wyboru narzędzi. Poprawne radzenie sobie z długimi kontekstami zmniejsza potrzebę skomplikowanych systemów pamięciowych. Godne zaufania samoopisywanie zmniejsza konieczność zewnętrznych procesów weryfikacji.

To może rzeczywiście się zdarzyć, a w niektórych obszarach już się to dzieje: sztuczki z promptami i rozwiązania alternatywne do parsowania, które były niezbędne dla wcześniejszych modeli, są obecnie często niepotrzebne. Możliwe jest, że najlepsze rozwiązania przyszłości będą znacznie prostsze od tych budowanych obecnie. To jednak jest tylko połowa obrazu.

Zdolności rozszerzają zakres

Gdy model staje się znacznie bardziej zdolny, zespoły rzadko wykorzystują te możliwości tylko po to, by wykonywać tę samą pracę taniej. Skupiają się na trudniejszych problemach.

• Model, który potrafi streszczać jeden dokument, wkrótce będzie musiał przeanalizować setkę.
• Model, który potrafi napisać pojedyncze zapytanie SQL, będzie musiał zbadać problem biznesowy obejmujący kilka systemów.
• Model, który potrafi wywołać jedną API, otrzyma całe środowisko programistyczne do obsługi.

Zakres zadań rośnie wraz ze zdolnościami modelu, co zmienia rolę systemów wspierających. Pytanie przesuwa się z tego, czy model potrafi odpowiedzieć na prośbę, na to, czy system pozwala mu bezpiecznie i niezawodnie realizować cel. To są różne problemy inżynieryjne – pierwszy dotyczy inteligencji, drugi kontroli, zaufania i odpowiedzialności.

Zdolne agenty stawiają pytania dotyczące systemów

Załóżmy, że coraz bardziej zdolnemu agentowi udostępniono przeglądarkę, bazę danych, wewnętrzne API, pliki, możliwość wykonywania kodu, narzędzia do komunikacji oraz pamięć długoterminową. Inteligencja nie jest już czynnikiem ograniczającym. Teraz trzeba odpowiedzieć na pytania takie jak:

• Które działania może podjąć agent?
• Jakie informacje może odczytać?
• Kiedy musi poprosić o zatwierdzenie?
• Co się dzieje, gdy narzędzie zawodzi?
• Jak zapobiega się pętlom i powtarzającym się działaniom?
• Jak ktokolwiek może odtworzyć powody podjęcia określonej decyzji?
• Jak ocenić proces pracy trwający 30 minut zamiast pojedynczej odpowiedzi?
• Co się dzieje, gdy model jest błędny, ale ma pewność co do swoich ustaleń?

Żaden z tych problemów nie zostanie rozwiązany dzięki inteligentniejszemu modelowi. Bardziej zaawansowany model może sprawić, że ostatnie pytanie stanie się jeszcze trudniejsze, ponieważ błędy popełniane płynnie i z pewnością siebie są trudniejsze do wykrycia. Są to problemy systemowe, i właśnie w nich narzędzie pomocnicze nabiera znaczenia zamiast go tracić.

Wiele dzisiejszych frameworki dla agentów koncentruje się na orkiestracji: decydowaniu o tym, co nastąpi dalej, jakie narzędzie zostanie wywołane i co zostanie przekazane z powrotem do modelu. W miarę jak modele stają się lepsze w samodzielnym planowaniu, ta logika sekwencjonowania jest tym elementem, który najprawdopodobniej będzie się kurczył. To, co pozostaje i rozwija się, jest bliższe projektowaniu środowiska. Narzędzie pomocnicze definiuje:

• Narzędzia: z czym agent może współpracować.
• Kontekst: jakie informacje są mu pokazywane.
• Stan: co agent pamięta między poszczególnymi krokami.
• Prawa dostępu: co agent może zmienić.

Komentarze: sposób, w jaki model dowiaduje się, że coś poszło nie tak.

Ocena: sposób mierzenia sukcesu.

Grenice: kiedy model musi przestać działać lub przekazać kontrolę człowiekowi.

W takim ujęciu model zyskuje autonomię, a narzędzia pomocnicze stają się granicami tej autonomii. Przestajemy określać ścieżkę, którą podąża agent, a zaczynamy kształtować przestrzeń, w której się porusza.

Złożoność ma tendencję do zmiany, a nie zanikania

Inżynieria oprogramowania wykazuje znajomy wzorzec: gdy jeden poziom staje się prostszy, złożoność zazwyczaj przenosi się w inne miejsce, zamiast zniknąć. Abstrakcje ukrywają złożoność, ale nie usuwają jej. Bazy danych zarządzane nie wyeliminowały potrzeby zrozumienia indeksów, a platformy chmurowe nie usunęły konieczności planowania przepustowości.

Agenty najprawdopodobniej będą podążać tą samą ścieżką. Lepsze modele mogą uczynić niepotrzebną część logiki agentów napisanej ręcznie, jednocześnie zwiększając zapotrzebowanie na bardziej skuteczne metody oceny, zabezpieczenia, możliwości obserwacji, zarządzanie pamięcią, kontrolę kosztów, inżynierię niezawodności oraz wsparcie dla zadań trwających długo. Narzędzie to może stać się mniej widoczne dla programistów aplikacji, być może dlatego, że dostawcy i frameworki je wchłaniają, jednocześnie stając się ważniejszym elementem funkcjonowania systemu. Prostsze doświadczenie programisty nie oznacza koniecznie prostszej architektury w tle.

Mniej ważne pod pewnymi względami, bardziej pod innymi

Szczerza odpowiedź brzmi, że nie chodzi o jedno ani drugie. Framework traci na znaczeniu jako narzędzie do ręcznej korekty słabych modeli. Zyskuje natomiast na znaczeniu jako podstawa, która umożliwia modelom o wysokich możliwościach działanie w rzeczywistym świecie bez stawania się niebezpiecznymi, niewiarygodnymi lub marnotrawczymi. Przyszłe frameworki mogą oferować mniej sztywną organizację procesów oraz znacznie bardziej zaawansowaną ocenę, uprawnienia, zarządzanie stanem, informacje zwrotne, możliwości obserwacji oraz kontrolę środowiska.

Ogólny rozwój wygląda następująco:

• Wcześniej: model był połączony niemal bezpośrednio z aplikacją.
• Dziś: model znajduje się za interfejsami wprowadzania zapytań, technologiami RAG, narzędziami, agentami oraz mechanizmami oceny, zanim dotrze do aplikacji.
• W przyszłości: model w połączeniu z frameworkiem utworzy autonomiczny system.

Ostatni krok jest tym najważniejszym. Gdy sztuczna inteligencja przechodzi od generowania odpowiedzi do podejmowania działań, kluczowym pytaniem nie jest już tylko to, na ile inteligentny jest model, ale jak dobrze zaprojektowano otaczające go środowisko.

Praktyczny test dla twojego własnego zestawu narzędzi

Aby zdecydować, gdzie inwestować, podziel każdy element zestawu na jedną z dwóch grup:

• Części kompensacyjne istnieją, ponieważ obecny model ma słabe strony: sztywne planery krok po kroku, skomplikowana logika analizy i naprawy wyników, kierowanie narzędziami na podstawie słów kluczowych, rozwiązania workaround dla promptów. Zachowaj je proste i łatwe do usunięcia, oraz ponownie je przetestuj przy każdej aktualizacji modeli, ponieważ to one najprawdopodobniej staną się ciężarem.

Części trwałe istnieją, ponieważ zadanie ma konsekwencje w rzeczywistym świecie: uprawnienia i izolacja, bramy zatwierdzania, logi audytowe i śledzenie, limity kosztów i pętli, zestawy oceny, trwałość stanu. Należy odpowiednio zainwestować w nie, ponieważ bardziej zaawansowany model zwiększa, a nie zmniejsza ich wartość.

Cennym wskaźnikiem jest pytanie, czy komponent nadal byłby potrzebny, gdyby model doskonale radził sobie z rozumowaniem. Jeśli odpowiedź brzmi tak, jak w przypadku kontroli dostępu, możliwości audytowania i mierzenia sukcesu, to komponent należy do trwałej istoty całego systemu.

Główne wnioski

• System integracyjny nie czyni modelu mądrzejszym; sprawia, że cały system staje się bardziej zdolny, niezawodny i bezpieczny.
• Lepsze modele prawdopodobnie zmniejszą ilość logiki orkiestracji i rozwiązań tymczasowych, co warto uwzględnić w planowaniu.
• Zwiększone możliwości otwierają szerszy zakres działania, co rodzi pytania dotyczące uprawnień, radzenia sobie z błędami, oceny i odpowiedzialności, na które żadna poprawa modelu nie daje odpowiedzi.
• Narzędzia te przechodzą od pisania skryptów dla każdego kroku do projektowania środowiska: narzędzi, kontekstu, stanu, uprawnień, informacji zwrotnej, mechanizmów oceny oraz ograniczeń.
• Oczekuj, że złożoność przeniesie się do infrastruktury zamiast zniknąć, i buduj trwałe elementy swoich narzędzi z tym faktem w uwadze.