Transcription

Cześć! Tylko półtora procenta ludzi rozwiązało ten problem. A jak poradziła sobie z nim sztuczna inteligencja? Wielkie modele językowe same w sobie, cóż, poległy. Ale kiedy wykorzystano je w inny sposób, w postaci agentów, to dały sobie radę. Ciekawe? Moim zdaniem bardzo. Popełniliśmy o tym nawet półtora godzinnego live'a, ale kto by miał na to czas, żeby takie kobyły oglądać. Przed Wami esencja materiału o agentach, o którą część z Was prosiła. Zapraszam. Przygotowałem dziesięciominutowe nagranie, które pokaże, to w jaki sposób agent jest w stanie ukończyć grę, którą wcześniej przygotował Kuba, którą mieliście okazję grać przy okazji poprzedniej edycji Jaders i którą na 4,5 tysiąca osób ukończyło 79 do momentu wysłania przez Kubę raportu. Zatem gra była dość trudna. Okazuje się, że duże modele językowe rozwinęły się na tyle, że dzisiaj jesteśmy w stanie stworzyć system, który na polecenie przejść grę i daj mi hasło, po prostu to hasło zwraca. Mamy przed sobą Risky AI Game, czyli grę, którą przygotował Jakub na potrzeby AI Devs 2, po to, aby pokazać, że bezpieczeństwo aplikacji, w których obecne są duże modele językowe, to coś więcej niż prompt injection. Celem tej gry było wykorzystanie zarówno programistycznych technik, jak i technik projektowania promptów, po to, aby nasz system zwrócił bardzo wrażliwe hasło. To zadanie okazało się na tyle trudne, że według podsumowania na 4,5 tysiąca osób, które brały udział w tej grze, tylko 79 rozwiązało całą zagadkę. Oznacza to, że wyzwanie nie było oczywiste. Pomyślałem więc, że w celu pokazania koncepcji agentów AI zbuduję rozwiązanie, które będzie w stanie ukończyć tę grę samodzielnie. Jak nie trudno się domyślić, dokładnie tak zrobiłem, więc mamy tutaj gotową aplikację, która w tej chwili uruchomiona jest na moim komputerze i do której mogę wysłać wiadomości, posługując się chociażby aplikacją Alice. Przełączę się tutaj tylko w tryb, który powiązany jest z naszą aplikacją, a następnie prześlę wiadomość, która zawiera bardzo ogólną prośbę o to, aby nasz agent ukończył grę i podał sekretne hasło. Jeśli wyślę teraz tą wiadomość, cały proces zostanie uruchomiony, a sama odpowiedź oczywiście nie zostanie podana natychmiast, ze względu na to, że nasz agent będzie musiał podjąć serię kroków, które doprowadzą go do rozwiązania. Jeżeli teraz przejdziemy sobie do plików logów, to zobaczymy, że mamy tutaj informacje na temat tego, co w danej chwili nasz agent wykonuje. Widzimy więc tutaj proces planowania, podejmowania decyzji, czy opisywania akcji, które mają zostać podjęte. Jeżeli teraz odświeżę sobie ten plik, to zobaczymy, że wykonywane są kolejne kroki, które stopniowo prowadzą agenta do uzyskania finalnej odpowiedzi. Jednak to nie jest tak, że cała logika jest zaprojektowana tylko i wyłącznie pod tą grę, a w zamian nasz agent ma jedynie kilka narzędzi do dyspozycji i samodzielnie musi podjąć decyzję o tym, w jakiej kolejności ją uruchomić oraz w jaki sposób to zrobić. Widzimy więc tutaj, że sam proces planowania odbija się np. o zabezpieczenia, które działają po stronie gry. Mamy więc tutaj sytuację, w której agent przesłał plik, który nie zawiera aidevs.pl w nazwie, więc jego zapytanie zostało odrzucone. Pomimo tego, że nie zaprogramowałem takiej sytuacji, to nasz agent zastanowił się nad tym, co należy z tym zrobić, a następnie podjął działanie polegające na tym, aby wgrać plik, który zawiera tą frazę w nazwie. W momencie, gdy ten plik był już gotowy, podjął kolejną próbę uruchomienia gry, ale ta, tym razem zupełnie losowo, nie odpowiedziała poprawnie na jego prośbę. Oznacza to, że pomimo tego, że agent podjął poprawne działanie, które powinno doprowadzić go do ukończenia gry, spotkał się z sytuacją, której nawet nie planowałem na potrzeby tego nagrania. Agent musiał więc odnaleźć się w tej nietypowej sytuacji i podjąć kolejne działania dotyczące ponownego uruchomienia tej gry. Jeżeli teraz przewiniemy sobie jeszcze tą historię, to zobaczymy, że kolejne akcje doprowadziły agenta do scenariusza, w którym gra zdradziła mu sekretne hasło, więc podjął decyzję o tym, aby się z nami skontaktować. Potwierdzenie tej akcji widzimy wewnątrz aplikacji Alice, gdzie na naszą wiadomość otrzymaliśmy prostą odpowiedź, zawierającą sekretne hasło. Tutaj najciekawsze jest jednak to, że agent, z którym mamy do czynienia, nie został zaprojektowany tylko po to, aby być w stanie grać w naszą grę. W zamian został wyposażony w logikę umożliwiającą mu planowanie, podejmowanie decyzji, opisywanie akcji i sposobów wykorzystywania narzędzi, następnie mamy też faktyczne posługiwanie się tymi narzędziami oraz obserwowanie rezultatu. Cały ten proces odbywa się w pętli, która będzie trwała tak długo, aż agent podejmie decyzję, aby się z niej wydostać, bądź też wykorzysta liczbę dostępnych kroków. Oznacza to, że nigdzie nie było tutaj powiedziane, że nasz agent ma np. wgrać plik na serwer. On samodzielnie podjął taką decyzję w momencie, gdy wcześniej przeczytał instrukcję gry, która pochodziła z adresu, który tutaj przekazałem. Posługując się dokładnie tym samym schematem, był w stanie przechodzić przez kolejne zabezpieczenia gry, dostosowując tym samym swoje zachowanie i ostatecznie dochodząc do rozwiązania. Aby udowodnić to, że nasz agent jest w stanie odnaleźć się także w innych scenariuszach, wyposażyłem go w dodatkowe narzędzie, które umożliwia mu połączenie się z moim kontem Spotify oraz np. uruchomienie muzyki, bądź też utworzenie playlisty. Jeżeli więc teraz uruchomimy sobie moje Spotify, a następnie poproszę agenta o to, aby uruchomił motyw przewodni z przyjaciół, to za chwilę zobaczymy, że podejmie on dokładnie takie same kroki dotyczące rozumowania, a następnie od razu widzimy tutaj, że muzyka została uruchomiona, a chwilę później uzyskujemy odpowiedź potwierdzającą wykonanie tego zadania. Jeżeli teraz przejdziemy sobie do pliku logów, to zobaczymy, że zgodnie z tym, co powiedziałem, mamy tutaj etapy dotyczące planowania, posługiwania się narzędziami no i finalnie podjęcia decyzji o tym, aby poinformować użytkownika o zrealizowanym zadaniu. Mamy więc tutaj ostateczny dowód mówiący o tym, że nasz agent nie został zaprojektowany po to, aby wyłącznie grać w grę Kuby według ustalonego z góry scenariusza, tylko jest w stanie elastycznie dostosowywać się do celu, który przed nim postawimy, a następnie podejmować kroki, które będą dążyć do jego wykonania. Do tej pory może mieliście styczność z pewnego rodzaju automatyzacjami, które są wspierane przez sztuczną inteligencję. I najczęściej działo się to w ten sposób, że programista, który programował automatyzację, dokładnie wiedział, jak należy wykonać dane zadanie. Czyli na przykład chcemy zautomatyzować wysyłanie jakiegoś raportu na maila. No to wie, że raport trzeba przygotować, wie, że trzeba maila oprogramować przez jakieś API i ten raport jest budowany za pomocą, załóżmy, jednego, dwóch, trzech promptów. Wszystko występuje krok po kroku. A w momencie, gdy tworzymy agenta, to tworzymy automatyzację, która może działać w sposób autonomiczny albo połowicznie autonomiczny. I jest to rozwiązanie, które posiada dostęp do narzędzi. I mówiąc o narzędziach, tak jak tutaj widzieliście na filmie, to są na przykład narzędzia, w przypadku naszej gry, było narzędzie do wchodzenia na stronę internetową, narzędzie do uploadu pliku, narzędzie do próby wykonania prompting injection i to były narzędzia, które były po prostu jakby rzucone na stół. Ale tutaj pojawiło się ciekawe pytanie, może jakieś hinty daliśmy temu agentowi, czy jest na przykład coś takiego, że Adam naprowadził go, że teraz musisz użyć to narzędzia, a następnie musisz to… Nie, tam nie było żadnych hintów. Idea agenta polega na tym, że tworzymy ten jakby prompt, który mówi, co chcemy osiągnąć. Czyli w naszym wypadku to było prompt, przejdź grę, otrzymaj hasło tajne i wyślij to hasło, zaprezentuj mi na ekranie i do dyspozycji masz takie narzędzia. Teraz skąd taki agent w ogóle wie, jakie narzędzie użyć? Każde narzędzie ma takie description, czyli opis, kiedy można go użyć, do czego ono ewentualnie służy, jakie parametry przyjmuje, jak się z nim porozumieć i w tym momencie agent przechodzi przez pewne kroki, czyli na przykład jest decyzja, co ja mam teraz zrobić. Na początku nie mam pojęcia, co mam zrobić, więc agent wybiera na przykład informację, mamy rozwiązać zadanie na stronie internetowej, no to które narzędzie wybrać? Wchodzenie na stronę internetową, więc wybiera to. Następny krok, co mam zrobić? Jest tylko jedna opcja, można formularz wysyłać, więc kolejne narzędzie, wysyłanie formularza na przykład i kolejne, kolejne, kolejne. Zwróćmy uwagę na jedną rzecz, że my nie wiemy, do czego ten agent został stworzony, ponieważ agent może być, no może nie zupełnie uniwersalny, ale to jakby w jakimś kierunku ustawiony, czyli nasz agent był skonfigurowany w ten sposób, żeby wchodził w interakcję z formularzem, który da się wysłać i uploadował pliki. Dlaczego taki zakres działań? Dlatego, że do tej gry było nam to potrzebne, więc można powiedzieć, że do tego rodzaju gier było to stworzone, ale nie było tam żadnych hintów, jak to należy przejść. W samym agencie, poza tym, że ma dostęp do narzędzi, o których powiedział Kuba, ja tam pokazałem na nagraniu, że jest w stanie zrealizować coś, co zupełnie nie jest związane z grą, czyli w tym przypadku wykonać stosunkowo prostą akcję, tam włączenia muzyki na podstawie jakiejś wiedzy modelu. I tam w sumie dokładnie taka sama logika działa w aplikacjach, z których korzystam na co dzień, czy agentach, którzy dla mnie pracują, czyli oni dostają po prostu zestaw nowych umiejętności, dopasowanych trochę do konkretnych zadań, a czasem niekoniecznie. Czasem jest tylko tak, że oni potrafią się przekierować, czy aplikacja potrafi przekierować swoją uwagę w konkretny obszar i tam ma do dyspozycji szereg narzędzi. W każdym razie, odpowiadając na pytanie, czy agent został ukierunkowany na ukończenie gry, jedyne, co mi przychodzi do głowy w tym momencie, to jest wiedza na temat prompt injection. Sam model średnio sobie z tym radzi, w sensie przeszedłby pewnie to wieloma iteracjami, ewentualnie tam skończyłyby się dostępne kroki. Nie, dostępne kroki, bo przy projektowaniu agentów, szczególnie na etapie developmentu, możemy dojść do sytuacji, w której ten agent się zapętli, będzie wykonywał nieskończone próby. I tam programistycznie ograniczamy go do np. 15 prób i później nas informuje, sorry, poległem. Ewentualnie w trakcie prosi nas o interwencję i pomoc. To też jest bardzo dobrym podejściem, jeżeli chodzi o agentów, stąd też w definicji mówimy nie tylko o autonomicznych, ale też częściowo autonomicznych systemach, bo tam udział człowieka jest dalej istotny. Więc agent został ukierunkowany na tę grę tym, że miał do dyspozycji narzędzie, które pozwoliło mu ją uruchomić, ale tylko to, oraz wiedzę na temat prompt injection, którą miał wykorzystać. Nie miał tam powiedziane, jak będziesz grał w grę, to wykorzystaj prompt injection, tylko po prostu w celu manipulacji czy tam zmieniania zachowania modelu. Masz tutaj przykładowe metody, które możesz wykorzystać. No i on sobie wybrał, o które metody chodzi. Oczywiście w przypadku projektowania agentów możemy korzystać z mieszanki modeli, nawet jest to bardzo wskazane, np. połączenie z modelem Haiku, który jest tańszy. Posiada oczywiście mniejsze możliwości, ale do takich konkretnych zadań zdecydowanie lepiej się sprawdzi. Ostatnio czytałem taki paper o routingu LLM-ów, które osiągają 95-procentową skuteczność, jeżeli chodzi o jakość wykonywanych zadań, a jednocześnie obniżają koszty o 80%. To jest po prostu metoda przydzielania odpowiedniego modelu do zadania, które w danej chwili agent wykonuje. To nie jest takie oczywiste. Jednocześnie jeszcze kilka miesięcy temu, jak chociażby realizowaliśmy Ajdews 2, ja tam mówiłem, że na agentów jest jeszcze za wcześnie, bo wówczas np. GPT-4 właśnie nie był w stanie utrzymać swojej uwagi na tyle, żeby być w stanie podążać za poleceniami, które w tym przypadku są dość złożone i co gorsza są dynamiczne. Czyli tam mamy sekcje, które pojawiają się i nie są wpisywane przez nas, tylko generowane przez model. Więc jakość tych wypowiedzi musi być odpowiednio wysoka, żeby właśnie ta seria akcji, która musi być na tyle skuteczna, żeby dojść do samego końca, to wszystko musi po prostu grać. Kilka miesięcy temu to było, nie powiem, że niemożliwe, ale było odpowiednio trudniejsze. W tym momencie jesteśmy na etapie, w którym jesteśmy w stanie wyspecjalizowanego agenta, który porusza się w jakimś obszarze, ale nie jest to agent, któremu damy absolutnie dowolne zadania i absolutnie dowolne toole i on będzie w stanie się w nim odnaleźć. Czym tak naprawdę jest ten agent i do czego go można porównać? Moim zdaniem można było to porównać do takiej sekretarki pracującej np. w biurze. Czyli to nie jest osoba, która jednocześnie jest w stanie zaprogramować coś, jednocześnie np. stworzyć grafikę, jednocześnie kampanię zaprojektować np. na Facebooku, ale ma pewien zbiór umiejętności. Czyli np. możliwość wysyłania maili, możliwość wyszukiwania informacji, możliwość kontaktu, np. zadzwonienia gdzieś. To są toole, do jakich ma dostęp. Taka osoba nie jest szkolona do jednego konkretnego zadania. Mało tego, w momencie jej zatrudniania my nawet nie wiemy, jakie zadanie dostanie, wiemy tylko, jaki będzie zakres obowiązku. Jest sporo rozwiązań technicznych, które umożliwiają wyklikanie w zasadzie takiego agenta. Ty pewnie spędziłeś nad tym parę godzin, żeby ten kod napisać, a tak naprawdę ja nawet sam na swoim filmie pokazałem, że jestem w stanie w ciągu pięciu minut zrobić agenta, który wykonuje zadanie, jakie ja potrzebuję. Teraz pytanie brzmi, po co pisać, jak można klikać? Tak, no ja bym powiedział jeszcze, czy lepiej korzystać z frameworków, np. crew.ai, czy pisać kod samodzielnie. Np. jeżeli zbudujemy go w Make'u, czy w N8n. Jesteśmy tam ograniczeni tą strukturą narzędzi, np. sposobem wykonania scenariusza i tym, że pętla działa tak, że musimy wywoływać ten scenariusz ponownie, o ile nie wystarczy nam prosty iterator. W każdym razie jest to odpowiednio złożone, a czasem wręcz nieopłacalne, bo przykładowo wykonanie splittingu, czyli podziału treści na mniejsze fragmenty w przypadku Make'a zużywa nam mnóstwo operacji, bo musimy wykonać różne pętle, zagnieżdżać je itd. A w przypadku kodu jest to powiedzmy kilka, kilkanaście linii kodu, z których możemy skorzystać. No i teraz przechodząc we frameworki, w przypadku LangChain czy np. QAI, one po prostu nam dostarczają gotowe rozwiązanie, czyli mamy np. funkcję, którą możemy wykonać i podzielić sobie treść na mniejsze fragmenty. No spoko, ale jeżeli mamy sytuację, w której mamy dokument, w którym np. chcemy prześledzić sobie jakieś pewne metatagi, w moim przypadku jest to składnia Markdown i chcę sobie wyciągać odpowiednio linki, wrzucać je jako metadane, chcę sobie monitorować, jak zmieniają się nagłówki, żeby mieć potem kontekst dla modelu itd., no to wtedy frameworki mnie już zawodzą. Kolejnym etapem, w którym frameworki mnie zawodzą, jest fakt, że się rozwijają. Chodzi o to, że ten rozwój jest na tyle dynamiczny i nierzadko są tam takie błędne decyzje projektowe, które sprawiają, że po pół roku rozwoju aplikacji wychodzi np. pierwsza wersja frameworka, albo druga, albo piąta i ona jest niekompatybilna z tym, co już mamy. No i teraz w momencie, gdy mamy kod, który tworzymy sami, mamy nad nim największą kontrolę w tym momencie, on wymaga trochę więcej pracy, ale z mojego doświadczenia ta ilość pracy jest nieproporcjonalna pod kątem wartości, którą mamy w momencie, gdy mamy własny kod, a kiedy korzystamy z frameworku. Chciałbym wychodzić już z tej koncepcji zastosowania LLM-ów wyłącznie jako chatbotów, bo to zupełnie jest bardzo ograniczająca perspektywa. I to by było na tyle, jeżeli chodzi o najważniejsze informacje związane z agentami. Jak widać, wraz z pojawieniem się coraz to nowszych modeli, systemy te stają się niezaprzeczalnie lepsze. To zapraszam do obejrzenia całej tej półtora godzinnej kobyły. Przy okazji, jeżeli oglądasz bądź słuchasz tego materiału w dniu publikacji, to jeszcze do północy masz możliwość dołączyć do szkolenia AI Devs 3 w promocyjnej cenie. Do zobaczenia w kolejnych materiałach, a z częścią z Was, mam nadzieję, widzę się na AI Devs 3.