Projektowanie narzędzi dla modeli językowych i agentów AI | LIVE AI_devs 4

No dobra, ale to zrobił nam się taki mały rozgardiarz. Mamy wywoływanie funkcji, mamy MCP właśnie przez te konektory, mamy LLM-y. Jakie są relacje między nimi wszystkimi? Jasne. No to tutaj Kuba słusznie powiedział, że w sumie dużo modeli językowych, w tym momencie już bardziej foundation models, które są w stanie generować treści w różnych formatach. No ale generalnie są w stanie generować treści, a niekoniecznie wchodzić w interakcje z otoczeniem, albo są w stanie posługiwać się bazową wiedzą, a niekoniecznie zewnętrzną. No i te wszystkie narzędzia są po to, aby to zmienić. Natomiast, przypomnij pytanie, bo fajnie było powiedzieć. Wiesz, mamy ten pomieszany świat, nie?

Że mamy wywoływanie funkcji, mamy MCP, mamy LLM-y. Jak one się wszystkie mają do siebie? Tak, no właśnie. Czyli mamy duże modele językowe, które są w stanie generować te treści. Mamy następnie nasz kod źródłowy aplikacji albo naszego klienta czatu, z którego korzystamy, z ChatGPT, z Gemini, z Cloda, z Cutsoda i tak dalej. Więc to jest tzw. client, czyli jakaś aplikacja, która jest w stanie rozmawiać w naszym imieniu z modelami językowymi, ale jednocześnie posiada te dodatkowe rozszerzenia i wie, jak się nimi posługiwać. Albo bardziej stwarza przestrzeń do wykonywania tych zaklęć.

działać, podejmować akcje i na przykład sięgać po zewnętrzne źródła wiedzy. Natomiast w praktyce mamy tam jeszcze tą jedną strukturę, czyli na przykład function calling albo po prostu strukturyzowany output, w przypadku którego... W sensie jest to cecha API, czyli to jest warstwa, która leży gdzieś pomiędzy LLM-em, a pomiędzy tym klientem. Więc jeżeli mamy model kontekst protocol, to on wystawia nam schematy definicji funkcji. czy schematy funkcji, które przekazujemy do modelu jako ten function calling. Czyli mówi jak wrzucać zaklęcie. Tak, tak. I to rozróżnienie jest istotne, ponieważ większość problemów, o których będziemy dzisiaj rozmawiać i większość wyzwań, które spotykamy jako użytkownicy, one wynikają właśnie z tej struktury function calling i cech modelu, a niekoniecznie z samego na przykład protokołu MCP, czy z tego, czy korzystamy z Gemini czy z Cloda.

Tutaj w ogóle wpadło pytanie od B4747E9P. Mateusz pisze i gada, to jest live? Nie, to zupełnie nie jest live, nie widzimy komentarzy. Wszystko oczywiście zerkamy sobie w międzyczasie. Słuchajcie, bo zanim jeszcze przejdziemy do filmu, no jest MCP, jest function calling. Ale no to skoro jest już function calling, no to po co nam model kontekst protokół? Po co Antropik to wprowadził i stało się de facto standardem na prawo i lewo? Dlaczego potrzebujemy kolejnego standardu, skoro są już jakieś, no to zróbmy jeszcze więcej, będzie więcej chaosu. To mówię, jak to widzę, bo... Jeżeli mamy function calling, to tak w uproszczeniu działa to w ten sposób, że definiujemy sobie funkcję, która składa się tam też w uproszczeniu z nazwy, z opisu, kiedy należy jej użyć albo jak ona działa, ze struktury danych, jaką powinna otrzymywać, produkować.

No i teraz to jest implementacja jakby schematu, czyli w momencie, gdy model będzie chciał użyć tej funkcji, to wyrzuci nam ten schemat, a my musimy ten schemat odebrać i coś z nim zrobić. Brakuje nam tutaj warstwy implementacji, czyli ta warstwa implementacji jest po naszej stronie, jeżeli chcemy korzystać z tego function callingu, bo sam model tego nie zrobi. W przypadku serwera MCP on wystawia jakby dwa elementy, czyli mamy definicję tych funkcji, w jakimś tam manifestie jest opisane co on jest w stanie nam dostarczyć, plus jeszcze może to czasami jakieś strzyknąć, prompta dodatkowego i inne urozmaicenia. ale daje też część wykonawczą. Czyli na przykład, jeżeli chcielibyśmy mieć dostęp do Google Drive'a, przykładowo, no to nie musimy implementować tego przez własne API, nie musimy się łączyć, nie musimy bibliotek ściągać, nic nie musimy, bo ktoś to już napisał. Ale teraz pytanie brzmi, jak ten ktoś ma poinformować nasz model językowy, jak z tego korzystać, nie?

No to on daje definicję tej funkcji i nasz model, jeżeli poprawi, implementuje MCP, już z tym umie rozmawiać. Więc jest to... próba ustandaryzowania komunikacji. Czyli ktoś może nam wystawić interfejs wraz z obsługą tego czegoś. No i są tam też dodatkowe elementy takie jak np. system akceptacji wykonań narzędzi albo w zasadzie propozycja tego jak to może być realizowane. Albo np. możliwość, którą zyskuje taki właśnie serwer, który żyje sobie gdzieś tam na jakichś właśnie zewnętrznych serwerach albo jest udostępniany przez jakichś innych providerów i on może poprosić o wykonanie akcji z modelem językowym w swoim imieniu. Czyli on mówi np.

nowego wpisu, niż w jakiś inny sposób dążyć do tego, żeby wydobyć informację z np. zwykłego zdania. Pora na film numer dwa i zaczynamy wchodzić coraz głębiej w problemy, także zapraszamy na drugą część. Zobaczmy teraz jak w praktyce wygląda działanie narzędzia, które pozwala w tym przypadku agentowi AI zarządzać linearem, uwzględniając przy tym dostęp do praktycznie dowolnej funkcji tego systemu, oczywiście o ile jest dostępna w API. Wyślę więc teraz zapytanie z prośbą o to, aby ustawić datę wykonania dla zadania związanego z nagraniem warsztatu o MCP w projekcie AdWeb, czyli dokładnie dla pierwszego wpisu widocznego na liście, a także o zwiększenie priorytetu dla zadania dotyczącego Weather MCP znajdującego się tutaj.

na którym autor lubi pisać i wówczas może się okazać, że odczytanie jednego, dwóch takich artykułów sprawia, że kontekst jest przepełniony. No i tutaj właśnie wchodzi do gry cały szeroko rozumiany kontekst engineering, czyli zarządzanie kontekstem i wymyślanie technik, które pozwalają agentom AI na utrzymywanie czy poruszanie się w tak obszernej treści bez uderzania w ten limit. Albo wchodzą tutaj też systemy wieloagentowe, które również dążą do zaadresowania między innymi tego problemu. Bo wiesz, można podejść do tego tak zachłannie, nie? Pierwszy raz zobaczyłem MCP, ja to teraz chcę mieć wszystko, dorzucę sobie wszystkie serwery MCP, o których sobie gdzieś tam wyobrażam, no ale to też powoduje, że gdzieś do kontekstu wrzucają się te informacje tak naprawdę o tym, co mamy, no i skończył się kontekst.

Nie mogę, nie jestem w stanie działać z takim modelem, bo tak naprawdę jestem gdzieś tam przy limicie. Jest to kontr-intuicyjne podejście, szczególnie dla kogoś na początku, kto dopiero ACP poznaje. Dla końcowych użytkowników jak najbardziej, przy czym pamiętajmy, że kontekst protocol, czy w ogóle narzędzia, nie są wykorzystywane tylko w chatbotach, nie są wykorzystywane tylko przez końcowych użytkowników, ale mogą być wykorzystywane przez was w kodzie aplikacji. Tam nawet nie musi być okna czatu. Tam po prostu może być jakiś element onboardingu, generowania awatarów, opisywania profilu użytkownika albo czegokolwiek. I tam również możecie wykorzystać jakąś formę właśnie function callingu czy model context protocol do tego, żeby wyposażyć wasz model w zewnętrzne narzędzia.

I swoją drogą tutaj wiem, że padło pytanie o... produkcyjne stosowanie MCP. No to na przykład w moim przypadku nie korzystam z żadnego oficjalnego serwera MCP, tylko każdy tworzę samodzielnie. I to trochę neguje tę koncepcję portu USB, który jesteśmy w stanie wszędzie podłączyć i tak dalej. Natomiast nie do końca, ponieważ jak projektujecie systemy, czy posługujecie się modelem językowym w kodzie aplikacji, to często dochodzi do sytuacji, w której właśnie ta logika, to co wcześniej mówiłem, że logika wykonania, logika, którą potrzebujemy do tego, żeby połączyć się z zewnętrznym API, musi być wykorzystana w wielu miejscach.

No i jeżeli mamy jedną aplikację, to spoko, to możemy sobie w ogóle pominąć model, kontekst, protokol i skorzystać z samego function callingu. Natomiast jeżeli dojdzie do sytuacji, gdy będziemy mieć na przykład więcej niż jednego klienta, czyli jedną aplikację, która będzie musiała tą samą logikę współdzielić, no to wówczas MCP są jak najbardziej użyteczne. Także ta kwestia produkcyjna tak wykorzystuje na produkcji w różnych konfiguracjach, zarówno serwery lokalne, jak i zdalne. Natomiast rzeczywiście ten memik moim zdaniem dalej jest prawdziwy, czyli mem, który mówi o tym, że jest coraz więcej twórców serwerów MCP niż ich użytkowników. No i teraz jesteśmy mniej więcej w takim miejscu. Natomiast zaznaczam jeszcze tą różnicę pomiędzy function callingiem oraz model context protocol.

Odniósłbym się jeszcze do tego, bo znalazłem to pytanie od pan Mido. Czy używacie serwerów MCP produkcyjnie albo znacie kogoś, kto używa? Ja używam jakby w swoim prywatnym życiu, bo im więcej znam firmy, tylko to jest ciekawe, że do samego MCP i do tego, co dostarczają, podchodzi się trochę jak do każdego oprogramowania, to znaczy trzeba przeprowadzić analizę ryzyka, bo co innego, jak to jest jakiś oficjalny serwer MCP, który jakaś znana firma wypuściła, A co innego, jak jakiś ziutek sobie go rozwija na Githubie i nie mam nic do tego, tylko czasami może się okażeć, że taki MCP może stać się złośliwy. I takie przypadki już były, że okazało się, że za pomocą MCP można było atakować różne systemy, więc trzeba wybierać, co się używa. Co więcej, z jedną taką firmą nawet rozmawiam, która ma swój raper MCP na wszystkie pozostałe MCP, gdzie sanityzuje wszystko.

Więc da się do tego podejść w pewien sposób tak czyściej z głową, żeby mimo wszystko wdrożyć to także w takim środowisku korporacyjnym. Jeszcze jedno mam takie pytanie, zanim przejdziemy sobie dalej i będziemy pogłębiać. Bo są jeszcze alternatywne podejścia. Po co jakiś tam function calling? Po co MCP? Niech model napisze sobie kodzik, niech ten kodzik wykona. Widzieliście to? Próbowaliście? Działa? Tak, to tak jak powiedziałem, że ja nie sprawdziłem jeszcze tego w boju i w takim środowisku produkcyjnym. To te sandboxy, o których mówiłeś. Ponieważ dalej np. narzędzia do udostępniania sandboxów typu Daytona albo Workery Cloudflare, które również w tym momencie są bodajże na poziomie bety,

No właśnie, one są jeszcze na poziomie beta i zarówno pricing i techniki korzystania, wykorzystywania modeli, czy w ogóle podejścia do kształtowania takich narzędzi, one są w tej chwili jeszcze na relatywnie początkowym etapie. I tam jest jeszcze wiele pytań bez odpowiedzi. Natomiast na ten moment widzę, że dobrze zatojektowany serwer MCP jest w stanie podłączony pod taką, jak widzieliście na filmie, system wieloagentowy, być w stanie realizować zadania. to znaczy, co mam na myśli dość skutecznie, to znaczy, że ten element braku determinizmu rzeczywiście występuje. Czasem ta sama akcja zostaje wykonana na przykład w trzech krokach, a innym razem w siedmiu.

Natomiast z obecnymi modelami obserwuję raczej sytuację, w której akcja zostanie zrealizowana, tylko po prostu ta ścieżka dojścia do celu będzie się różnić. Oczywiście to różni się w zależności od zadania, złożoności, danych, z którymi pracujecie itd. Mówię tutaj o swoim kontekście, czyli takich właśnie codziennych integracjach z mapami, z kalendarzami, z listami zadań, z mailami i tak dalej. Czyli w takim moim kontekście prywatnym oraz właśnie w tym kontekście narzędzi produkcyjnych, które w tym przypadku tworzę tak zwanego hosta, czyli narzędzie, do którego można podłączać m.in. model Context Protocol, czyli MCP Servers.

Chciałem jeszcze dopowiedzieć co do tego tworzenia kodu, bo to zależy od poziomu złożoności problemu, to jest jedna rzecz. I druga rzecz, zależy z jakim systemem pracujemy. Bo przykładowo, jeżeli kowysamy sobie załóżmy z Cloud Coda, to jak ja analizuję dane biznesowe, to praktycznie cały czas piszę sobie jednolinijkowce. W Bashu, w Perlu, czasami w Pythonie, co tam lubi. I nie mam nic przeciwko. To jest proste, lokalne przetwarzanie danych, raczej mu to wyjdzie dobrze. Ale jeżeli bym go poprosił, na przykład dodaj mi wydarzenie do kalendarza, no to teraz on musi wiedzieć, jak się z tym połączyć, musi mieć jakiś klucz API być może, jakoś odpowiednio to zaprogramować. Czasami też serwer MCP niekoniecznie korzysta z publicznie dostępnych danych, tylko wewnętrzne systemy firmy na przykład. I te dane nie są publicznie dostępne, jak się z tym komunikować, nie wiemy, co tam w środku siedzi, mamy tylko wystawiony interfejs.

zanim zmieniłby ten priorytet. Natomiast dobrze zaprojektowany serwer MCP pozwoli to zrealizować albo w jednym kroku, albo na przykład w dwóch, bądź trzech. Natomiast każdy z tych kroków jest potrzebny i przemyślany w taki sposób, żeby właśnie zmniejszyć tą ścieżkę, a jeszcze po drodze pomagać agentowi, czyli wzmacniać te poszczególne kroki, dając mu wskazówki, co robić dalej. No i pięknie nam się kontekst buduje, ale ja bym jeszcze trochę pofilozofował w tym zakresie, bo w którym momencie to jest tak, że taka automatyzacja przestaje być taka pomocna, a zaczyna być irytująca? Czy to jest tylko kwestia takiego real time'u, że jak czekamy, jak mamy czas, to niech te tam dziesiątki kroków się robią, a jak czekamy, to chcemy, żeby to było jak najszybciej, jak najbardziej specyficzne?

Może to być identyfikator, może być to link do zasobu, może być to link do np. wygenerowanego zdjęcia itd. I konkretny przykład. Replicate to jest taka platforma, na której są dostępne różne modele, m.in. do generowania obrazów. I jak skorzystacie sobie z ich oficjalnego MCP, to tam jest etap, w którym założenie tzw. utworzenie predykcji, czyli generowania grafiki, wymaga od agenta odpytywania API czy ta grafika została już wygenerowana. I co gorsza w momencie gdy dojdzie już do czytania grafiki tam dostajemy szereg powiedziałbym śmieci, czyli zupełnie nieistotnych informacji z punktu widzenia tego, że agent musi zostać jedynie poinformowany.

Grafika jest gotowa i tutaj masz informację, jak się do niej dostać. I to wszystko. Natomiast oficjalny serwer MCP zasypuje nas informacjami, które właśnie prowadzą albo do wypełnienia kontekstu, albo do pomyłki agenta, czyli on po prostu na przykład wykorzystuje błędny link do tego, żeby użytkownikowi zaprezentować grafikę. I to jest dobry przykład tego, jak źle zaprojektowany serwer MCP w oczach użytkownika jest po prostu nie działającym czymś. Natomiast w momencie, gdy rzeczywiście zastanowimy się, jak ten agent, jak model językowy będzie z tych narzędzi korzystał, to jesteśmy w stanie tu reagować. Ja bym właśnie płynnie przeszedł do tego, bo jak czytam czat, to jest kilka pytań, no jakie będzie tutaj porównanie AI Devs 3, AI Devs 4, to to będzie właśnie w AI Devs 4?

Jest tam mnóstwo nowych tematów, są też tematy, które się powtarzają, ale jak na przykład spojrzymy sobie na materiał z dzisiejszego spotkania, to przykładowo zarządzanie zadaniami w Linearze, czy w ogóle połączenie do Lineara, JIR-y, Todoist było już omawiane. Natomiast po spotkaniu prześlemy Wam link do kodu źródłowego tego narzędzia. Zobaczycie, że poziom złożoności, poziom kompleksowości i na przykład zadbania o szczegóły jest tam na zupełnie innym poziomie. Chodzi o to, że taki serwer MCP został przygotowany z myślą już o produkcji. nie o moim prywatnym zastosowaniu, aczkolwiek jest tam wykorzystywany. Ale jeżeli na przykład osoby z mojego zespołu chcą pracować w ten sposób albo pracują, na przykład Grzegorz wykorzystuje sobie ten serwer MCP w swojej codzienności.

No i tyle. Tutaj są tak naprawdę te największe możliwości. Także znowu function calling, MCP, to są wszystkie koncepcje, które widzę np. w sieci, że są utożsamiane właśnie np. z kursorem. Ktoś się ze mnie śmiał, że mam MCP Tesli do tego, żeby z kursora sobie pisać o to, żeby Tesla zwiększyła czy zmniejszyła temperaturę. To jest oczywiście głupie. Natomiast w sytuacji, gdy... To jest refleksja. Tak, ale osoba, która to pisała, rzeczywiście postrzega MCP z poziomu kursora albo krotkoda. Natomiast w moim przypadku chodzi o jakąś logikę, która na przykład działa według harmonogramów czy zdarzeń.

Norbert 5389 pyta, jak pokazać szefostwu nietechnicznemu, że MCP i Gen AI nie jest takie straszne, tak aby security się nie przyczepiło? Powinno się przyczepić, na pewno, ale powinniśmy pokazać, że mamy to pod kontrolą. To znaczy, mówię inaczej, że to nie jest tak, że nagle wielkie procesy będą zawiązane bez AI, ale w wielkim procesie, który może być wielo... krokowy, że tak powiem, niektóre kroki mogą być zautomatyzowane. I tutaj takie największe ryzyko jest, że jeżeli AI coś zrobi, no to my bierzemy na siebie konsekwencje za to. Jak najbardziej to ma rację bytu, tylko że możemy zrobić coś takiego jak czekanie na przykład na akceptację pewnych groźnych kroków przez człowieka. Czyli takie podejście typu human dilup. Ja na przykład u siebie w firmie mam takie coś, że jeżeli są tworzone właśnie te odpowiedzi na zapytania biznesowe, to one nie są wysyłane do nikogo.

Znowu podając konkretny przykład, jakiś czas temu zbudowałem sobie MCP do zarządzania systemem plików. I każdy z moich agentów teraz jest w stanie sobie wejść na przykład właśnie do mojego Obsidian'a i zrobić w nim modyfikację. I dopiero w momencie, gdy, w sensie ja sobie podobiłem pewne założenia, zrobiłem interfejsy, zrobiłem jakieś testy i tak dalej, które pozwoliły mi to narzędzie wdrożyć. Natomiast dopiero w momencie, gdy zacząłem z niego korzystać, zaczęły ujawniać się pewne problemy, czy nawet pomysły związane z tym, jak to narzędzie należy zmodyfikować czy zmienić po to, żeby mieć z niego jeszcze więcej wartości. Także ten element tego stawania się częścią waszej codzienności, nawet jeżeli to jest coś potencjalnie właśnie takiego zabawnego, czasem głupiego, czasem niepotrzebnego nawet, to to jest bardzo ważne.

Jeżeli zajrzycie w kod, to zwykle jest to 1, 2, 3 pliki, czasem pewna struktura, która uwzględnia... takie podstawowe akcje. Natomiast jak zaczniecie korzystać z tego MCP w codzienności, to zobaczycie, że część akcji jest niedostępna, część akcji jest źle zaimplementowana, a na przykład po części API zaczyna zwracać błędy, bo na przykład w wyniku podjęcia zbyt dużej liczby interakcji jest limit API. No i te wszystkie rzeczy, czy te wszystkie problemy, to są problemy programistyczne, które muszą być zrealizowane czy zrealizowane na poziomie samej implementacji tego narzędzia. I tam jest programowanie.

Część ludzi dzieliła się swoimi rozwiązaniami, też możecie spokojnie na to zerknąć. Ja przypominam, że kod do tego, co dzisiaj Adam pokazywał, jutro poślemy mailem, jutro wam wszystko podsumujemy. I tak powolutku zmierzamy do zakończenia, bo ja nie wiem kiedy, ale minęły dwie godziny, no jeszcze paręnaście minut i byłoby w ogóle. Słuchajcie, function calling, MCP, budowanie narzędzi, te wszystkie rzeczy będą w AI Devsach 4. Fajnie nam się świat pokomplikował przez 3 lata, nie? Mamy bardzo dużą głębokość, nie tylko jak rozmawiać, z jakim modelem, w jaki sposób w ogóle rozszerzać możliwości tego modelu, czym go obudowywać. Jesteśmy w takim świecie, w którym ta nauka tak szybko się rozrosła, że ciężko jest nadążyć.