Zazwyczaj staram się podchodzić do wszelkich nowych, błyszczących zabawek z pewną dozą sceptycyzmu. Dokładnie taki, do niedawna, był mój stosunek do systemów wieloagentowych. Powiedziałbym, że nie jest to zaskakujące, ponieważ wokół nich jest teraz mnóstwo szumu, a ja nie widziałem prawdziwie udanych przykładów takiego podejścia. Większość realizacji, które faktycznie działały, należała do jednego z następujących typów: Systemy agentowe działające według określonego planu. Czyli LLM z narzędziami, wytrenowane do automatyzacji konkretnego procesu. Dzięki temu każdy krok można testować osobno i weryfikować jego wyniki. Opisywane są takie systemy zazwyczaj w postaci skierowanego grafu acyklicznego (DAG), czasem dynamicznego, i tworzone przy użyciu już standardowych prymitywów z frameworków typu LangChain i Griptape1. Tak funkcjonowała wczesna implementacja Gemini Deep Research, w której najpierw tworzono plan wyszukiwania, następnie wykonywano samo wyszukiwanie, a na końcu składano wynik. Rozwiązania działające w systemach ze sprzężeniem zwrotnym. Różne Claude Code, Cursor i inne agenty operujące na kodzie. Im silniejsze sprzężenie zwrotne, czyli im lepszy tooling i surowsza kontrola typów, tym większe szanse, że ostatecznie nie zepsują wam bazy kodu2. Modele trenowane za pomocą Reinforcement Learning, takie jak modele z interleaved thinking, na przykład OpenAI o3. To osobna i bardzo ciekawa rozmowa, ale nawet takie modele mają jakieś modus operandi, określone przez specyfikę ich treningu. Tymczasem systemy wieloagentowe typu otwartego, ze względu na ich ogólną zawodność, istniały dotychczas głównie w formie proof of concept. W społeczności brakowało zrozumienia, gdzie je stosować i jak dokładnie je implementować. Aż pojawił się głęboki artykuł inżynierski od Anthropic o tym, jak tworzyli swój Deep Research. Zdefiniowano w nim wystarczająco jasne ramy do budowy takich systemów i to właśnie je dzisiaj przeanalizujemy. ...
W czasach, gdy słowa AI i hype stały się praktycznie synonimami, bardzo ważne jest mądre podejście do wyboru źródeł informacji. Wokół jest teraz zbyt wiele szumu informacyjnego, a wybranie czegoś naprawdę wartościowego z morza artykułów różnych ewangelistów AI i wygenerowanych śmieci jest niezwykle trudne. W tym wpisie opowiem, jakie materiały czytam, aby być na bieżąco z najnowszymi wydarzeniami. Blogi Dobry blog to sztabka złota. Stosunek sygnału do szumu dąży w nim do nieskończoności. Dlatego zacznę od listy blogów, które uważam za przydatne. ...
W poprzednim wpisie omówiłem podstawowe koncepcje frameworka AI Griptape, a teraz nadszedł czas, aby zastosować je w praktyce. Spróbujmy ich użyć do stworzenia małej aplikacji, która pomaga w prowadzeniu link-bloga na Telegramie. Aplikacja będzie otrzymywać adres URL, pobierać jego zawartość, przepuszczać przez LLM w celu wygenerowania skróconego podsumowania, tłumaczyć to podsumowanie na kilka innych języków, składać wszystko w całość i publikować na Telegramie za pomocą bota. Ogólny przepływ pracy można zobaczyć na poniższym schemacie: ...
Co to w ogóle jest ten Codex? Dobre pytanie, prawda? Chodzi o to, że do niedawna OpenAI miało model Codex, który był używany jako podstawa autouzupełniania w GitHub Copilot. Następnie OpenAI wypuściło konsolowego agenta do tworzenia oprogramowania, którego nazwali, żeby nikt nie pomylił, Codex. 1 Wszyscy pośmiali się z umiejętności OpenAI do dobierania nazw 2 i żyli dalej. Aż nadszedł pamiętny dzień, w którym na Twitterze pojawił się taki oto post od Sama Altmana: ...
No dobrze, dziś patrzymy na Griptape. Co to jest? A jest to frameworkiem do budowy aplikacji AI, oferującym czyste pythonowe API dla tych, którzy są zmęczeni poziomami abstrakcji LangChain. Proponuje prymitywy do budowy asystentów, systemów RAG i integracji z zewnętrznymi narzędziami. Szczerze mówiąc, z mojego doświadczenia, większość osób zmęczonych LangChainem przechodzi na własnoręcznie pisane wrappery wokół bibliotek niższego poziomu, takich jak OpenAI czy LiteLLM. Ale kto wie, może niepotrzebnie. Przyjrzyjmy się temu. ...
No to zaczynamy Wpadła mi w ręce Re:Camera od Seeed. W zasadzie to małe pudełeczko (kostka o krawędzi 4 cm), opasane radiatorem. W środku dwurdzeniowy MPU na bazie RISC-V (aktualizacja: w systemie widoczny jest tylko jeden rdzeń, drugi jest najprawdopodobniej zarezerwowany dla operacji specjalnych), wiekowy mikrokontroler 8051, sensor kamery od OmniVision, diody do podświetlenia, Wi-Fi, BT, no i różne peryferia. Pamięci RAM jest malutko, zaledwie 256 megabajtów, więc postawienie Greengrass będzie problematyczne. Można podłączyć Ethernet przez specjalny kabelek-przejściówkę, który ledwo się trzyma, ale do developmentu nie ma to sensu, bo kamera udostępnia sieć po USB typu C i prościej tak pracować. Jeśli brakuje pamięci (a urządzenie jest dostępne w wariantach z 8 GB i 64 GB wbudowanej pamięci), można wsadzić kartę MicroSD. Pudełko można też przyczepić do czegoś metalowego, bo z jednej strony ma magnesiki. ...