"Wiem już wszystko", czyli co nowego czeka w AI_devs 4?

Cześć, z tej strony Adam Gospodarczyk 👋

Trzecią edycję AI_devs można uznać za kompletną. Każdy kto ją ukończył, widzi całe generatywne AI z szerokiej perspektywy.

Dodatkowo, od czasu premiery trzeciej edycji, raczej nie zaobserwowaliśmy fundamentalnych zmian technologii, a "jedynie" inkrementalny rozwój modeli oraz narzędzi. Wydaje się zatem, że dla nowych osób, które jeszcze nie były w AI_devs, powtórzenie trzeciej edycji byłoby wystarczające. Z kolei osoby, które z nami były, wiedzą już co robić.

Zobacz, nad czym pracuję w kontekście treści AI_devs 4, bo na tej podstawie możesz samodzielnie ocenić, czy warto wziąć w niej udział.

AI_devs 3 vs 4 na jednym obrazku

Jeśli miałbym zestawić AI_devs 3 na jednym obrazku, zrobiłbym to z pomocą poniższego schematu rozbudowanego systemu, którego komponenty omawiamy i budujemy podczas Programu.

Elementy zaznaczone na czerwono, to nowości, bądź tematy mocno pogłębione i zaktualizowane o nowe techniki pracy. Pozostałe także ulegną pewnym zmianom, ale na poziomie koncepcji są raczej podobne do wcześniejszych edycji.

Nowości w AI_devs 4

Zatem nowości i aktualności obejmują:

  • nowe techniki budowania promptów oraz zarządzania kontekstem, szczególnie w kontekście wielowątkowych workflow oraz agentów i systemów wieloagentowych,
  • budowanie narzędzi dla agentów AI, uwzględniając techniki adresujące problem limitów okna kontekstowego oraz wzmacniania oczekiwanych zachowań agentów,
  • budowanie logiki agentów AI oraz zespołów agentów, wyspecjalizowanych w określonych zakresach procesów biznesowych oraz prywatnych,
  • techniki samodzielnego prowadzenia procesu rozumowania z pomocą planowania etapów działań, routingu zapytań czy ich dekompozycji, a także monitorowania postępów realizacji zadań,
  • wykorzystywanie wirtualnego systemu plików oraz sandboxów do uruchamiania kodu, jako narzędzi do rozumowania oraz interakcji agentów z otoczeniem,
  • monitoring oraz ewaluacja narzędzi na etapie projektowania i na etapie produkcyjnym, wymagającym ich utrzymania oraz rozwoju,
  • i wiele innych.

Poza tym w trakcie AI_devs 4 zbudujemy kilkadziesiąt narzędzi dla agentów AI, które będą mogły być przez nich użyte w niemal dowolnych konfiguracjach. Przynajmniej część z nich ma realną szansę stać się elementem codzienności.

Choć w generatywnym AI nie byliśmy świadkami oczywistych rewolucji, to rozwój inkrementacyjny otworzył nowe możliwości oraz zmienił sposób, w jaki podchodzimy do dotychczasowych problemów.

Co to dokładnie oznacza?

Dotychczasowe i nowe możliwości API

Interakcja z LLM przez API jeszcze do niedawna była raczej prosta. Wystarczyło przesłanie listy wiadomości i kilku podstawowych ustawień, aby wygenerować odpowiedź. Choć funkcjonalności takie jak Function Calling czy Structured Outputs są dostępne od dawna, teraz sytuacja jest nieco bardziej złożona, ponieważ:

  • Responses API stopniowo zastępuje Completions API i to nie tylko w OpenAI (np. w Gemini mamy Interactions API). Ich nowa struktura jest bardziej dopasowana do logiki agentów oraz multimodalnych treści. Responses API czy Interactions API to także opcjonalne zachowanie stanu konwersacji, które w niektórych sytuacjach może okazać się przydatne.
  • LRM (Large Reasoning Models) generują dodatkowe tokeny rozumowania, których ilość do pewnego stopnia możemy kontrolować, a ich treść nie może być modyfikowana (ze względu na wymaganą zgodność sygnatur). Rozumowanie wpływa na logikę agentów, czas odpowiedzi oraz koszty.
  • Natywne narzędzia, np. WebSearch czy natywne wsparcie Remote MCP dostępne są już niemal wszędzie. Ułatwiają one prace nad agentami AI, ale też często ograniczają nasz wpływ. Z drugiej strony, coraz częściej obserwujemy konieczność przechowywania sygnatur, co raczej komplikuje korzystanie z różnych providerów jednocześnie. Nieoczywista jest też decyzja, kiedy natywnie dostępne narzędzia są lepsze, a kiedy nie.
  • Multimodalność również bardzo rozwinęła się w ostatnich miesiącach. Jakość generowanych grafik, natywna sterowność modeli, a także dostępne ustawienia są teraz na zupełnie innym poziomie. Nie oznacza to jednak, że swobodna automatyzacja jest już możliwa, a wygenerowane materiały pozbawione glitch’y.
  • Modele są tak dobre w generowaniu kodu, że umiejętność ta jest wykorzystywana przy obsłudze narzędzi. Konieczne jest tu jednak stosowanie sandboxów, albo tych dostępnych natywnie w API, albo jako zewnętrzne usługi bądź własnych rozwiązań.
  • Jawny oraz niejawny prompt cache'ing jest obecnie fundamentem interakcji z LLM, szczególnie w przypadku logiki agentów AI. Choć sam mechanizm jest raczej prosty, nieoczywiste jest korzystanie z niego, szczególnie w wielowątkowych interakcjach.
  • Ogólna stabilność API nadal pozostawia wiele do życzenia, aczkolwiek postęp w dobrym kierunku jest widoczny. Biorąc jednak pod uwagę większą złożoność interakcji, nadal musimy stosować różne techniki radzenia sobie z ograniczeniami.
  • Ilość modeli ciągle wzrasta i mowa tutaj nie tylko o głównych providerach (OpenAI, Gemini, Anthropic czy xAI), ale także modelach takich jak GLM, MiniMax czy DeepSeek które zaczynają sprawdzać się także w warunkach produkcyjnych. Korzystanie z różnych modeli przekłada się na różne przewagi (np. optymalizację wydajności i kosztów) ale zwiększa złożoność chociażby ze względu na powody wymienione wyżej.
Schemat blokowy przedstawiający wieloetapowy proces wyszukiwania informacji przez AI

Powyższe zmiany to zaledwie ogólniki i jak zwykle w praktyce (szczególnie na produkcji) ujawniają się różne problemy o które trzeba zadbać. Choć duża część nowych możliwości API jest raczej ułatwieniem, tak w praktyce złożność posługiwania się API wzrasta, ponieważ wzrasta złożoność logiki aplikacji, które możemy rozwijać.

Dotychczasowe i nowe techniki pracy

Wzrost możliwości modeli oraz nowe narzędzia sprawiają, że istniejące techniki pracy zmieniają się, rozwijają bądź zostają zastąpione nowymi.

Przykładem jest łączenie bazy wiedzy z LLM (czyli Retrieval Augmented Generation, RAG). To najczęściej pojawiające się zastosowanie generatywnego AI z jakim się spotykam. Zwykle kojarzone jest ono z bazami wektorowymi bądź wyszukiwaniem hybrydowym. W obu przypadkach mowa o przygotowaniu bazy treści, ich transformacji (np. podziale na fragmenty), dodaniu do indeksów silników wyszukiwania oraz opracowaniu logiki budowania kontekstu. Zwykle to na podstawie najnowszej wiadomości użytkownika dochodzi do wyszukiwania potencjalnie istotnych treści, które wykorzystuje model.

Architektura RAG

Chociaż hybrydowe wyszukiwanie dopasowane do zestawów danych i określonego zakresu zadań sprawdza się na produkcji, tak posiada szereg wad i samo w sobie jest dość trudne do wdrożenia.

Obecnie możemy zauważać rozwój RAG w kierunku "Agentic RAG" obejmującym zarówno elementy wyszukiwania hybrydowego jak i pracę z systemem plików. Możemy obserwować to w narzędziach takich jak Cursor, którego agent eksploruje pliki posługując się wyrażeniami regularnymi oraz pytaniami w języku naturalnym.

Agentic RAG daje fundamentalną przewagę ze względu na możliwość pogłębionego wyszukiwania, które może dynamicznie dostosowywać się do bieżącej sytuacji, wykorzystując także w trakcie inne dostępne narzędzia, a nawet kontakt z użytkownikiem. Oczywiście nie jest to rozwiązanie doskonałe i nie sprawdzi się w każdym przypadku, natomiast adresuje ono dużą część problemów klasycznego RAG'a.

Systemowa pętla rozumowania i narzędzi

Logika agentów staje się już standardem niemal wszędzie i obejmuje nie tylko systemy RAG, ale także systemy pamięci, generowanie obrazów, tworzenie dokumentów czy przeróżne odmiany mechanik z kategorii "deep research".

To wszystko przenosi nas także w zupełnie inne miejsce w temacie "zarządzania kontekstem". Choć w sieci z łatwością można znaleźć informacje o tym, że "Context Engineering zastępuje Prompt Engineering" tak w praktyce, przy budowaniu agentów, łatwo się przekonać, że nie ma to nic wspólnego z rzeczywistością. Po prostu określenie "Context Engineering" jest stosowane także w odniesieniu do programowania z pomocą LLM (LLM-assisted programming), gdzie obowiązują nieco inne zasady.

Gdy patrzę ze swojej perspektywy na cały rozwój Generatywnego AI oraz nawet struktury pierwszych edycji AI_devs, to jasno widzę, że fundamenty rozwoju generatywnych aplikacji pozostają praktycznie takie same. Wyraźnie jednak przesuwa się granica tego, co możliwe. Co ciekawe, nie zawsze odbywa się zgodnie z naszymi oczekiwaniami. Dobrym przykładem jest podejście opisane w "Solving a Million-Step Task With Zero Errors", opierające się o zastosowanie modelu gemini-4.1-mini (!!!) oraz dekompozycję problemu "Wieży Hanoi".

Artykuł

I choć można dyskutować na temat tego, czy sugerowane przez autorów podejście można przełożyć na inne problemy, tak zdecydowanie można wyciągnąć z niego wiele wartościowych lekcji. Jednak o tym, które z nich mają realne przełożenie na rzeczywistość można określić jedynie poprzez budowanie rozwiązań i obserwowanie ich skuteczności w praktyce.

To właśnie tym będziemy zajmować się w AI_devs 4.

Dokąd prowadzi AI_devs 4?

Priorytetem nadchodzącej edycji jest budowanie.

Dla absolwentów i absolwentek oznacza to przestrzeń na wykorzystanie oraz aktualizację posiadanych już umiejętności.

Z kolei dla osób, które są z nami po raz pierwszy, oznacza to głębokie poznanie generatywnego AI poprzez praktykę w otoczeniu osób, posiadających już doświadczenia w tym obszarze.

Mówiąc wprost, AI_devs 4 to podróż, która:

  • Polega na budowaniu narzędzi, które mogą stać się częścią Twojej codzienności. Np. zamiast jedynie mówić o wdrożeniu 'prywatnego newslettera', faktycznie go zbudujemy.
  • Pozwoli doświadczyć błędów i nieoczywistych problemów wynikających z natury modeli językowych. Np. korzystanie z agenta do zarządzania kalendarzem pokazuje, że niektóre modele mają trudność z określeniem "kiedy jest jutro" w ostatnim dniu miesiąca.
  • Wyjaśni najnowsze techniki pracy oraz strategie rozwiązywania problemów, np. poprzez skorzystanie z logiki agenta przy pracy z własną bazą wiedzy opartą o system plików.
  • Pozwoli doświadczyć problemów związanych z formatami danych czy ograniczeniami platform, np. trudnością zbudowania proaktywnych agentów AI, wychodzących z inicjatywą do użytkownika.
  • Przeprowadzi przez fundamenty działania modeli językowych oraz ich funkcjonowania w logice systemów wieloagentowych, których działanie może odbywać się asynchronicznie oraz oczekiwać na informacje ze strony człowieka.
  • Przybliży doświadczenia z budowy produkcyjnych rozwiązań, które etap "prototypu" mają już za sobą. Np. na czym polegają wyzwania rozwoju aplikacji, gdy główne funkcjonalności produktu zaczynają być natywnie realizowane przez model.
  • Wprost pokaże obszary w przypadku których nie znamy jeszcze jasnych odpowiedzi. Dzięki temu zbudujemy pełen obraz generatywnej sztucznej inteligencji i nie będziemy skupiać się wyłącznie na jej pozytywnej stronie.

To wszystko, i wiele innych, zostanie dostarczone w otoczeniu społeczności programistów oraz programistek, a także elementów fabuły oraz historii

"Agenta V".

Zapraszamy! Startujemy 9 marca.