O czym jest ten film
- David Ondrej rozmawia z Danielem, specjalistą od cyberbezpieczeństwa, który pracował między innymi w Apple, o zagrożeniach związanych z coraz sprawniejszymi agentami AI.
- Daniel uważa, że firmy będą potrzebowały własnych narzędzi do ciągłego sprawdzania bezpieczeństwa oprogramowania.
- Wyjaśnia, dlaczego uzależnienie firmy od jednego dostawcy modeli może stać się problemem większym niż sam koszt korzystania z AI.
- Pokazuje LifeOS: osobisty system, który gromadzi jego cele, preferencje, projekty, notatki i informacje potrzebne agentom do pracy.
- Opowiada, jak automatycznie wychwytuje pomysły z rozmów i zapisanych materiałów oraz zamienia je w zadania.
- Przedstawia swój sposób tworzenia oprogramowania: jeden dokument ISA opisuje cel projektu, podjęte decyzje, etapy pracy i kryteria sprawdzenia wyniku.
- Pokazuje, jak dobiera modele do trudności zadań oraz gdzie używa modelu Jev do podejmowania decyzji z określonej listy możliwości.
- Rozmowa obejmuje również przyszłość pracy, potrzebę samodzielnego wyznaczania celów i ryzyko oddania agentom kontroli nad tym, jakie informacje do nas docierają.
10 najważniejszych takeaways — z kontekstem zastosowania
1.Opisz działanie firmy, zanim oddasz zadania AI
Na czym polega: Agent nie usprawni procesu, którego nikt nie potrafi mu wyjaśnić. Daniel wskazuje, że wiele firm nie ma spisanej wiedzy o swoich decyzjach, zależnościach i sposobie pracy.
Jak stosować: Zacznij od jednego procesu. Zapisz, kto podejmuje decyzje, skąd bierze dane, jakie są wyjątki i po czym poznać poprawny wynik. Dopiero na tej podstawie wybierz czynności do automatyzacji.
Na co uważać: Dokumentacja sporządzona jednorazowo szybko się zestarzeje. Ustal, kto aktualizuje ją po zmianie procesu.
2.Nie pozwól, by dostawca modelu wiedział o firmie więcej niż firma sama o sobie
Na czym polega: Jeśli wiedza długoletnich pracowników trafi wyłącznie do narzędzi zewnętrznego dostawcy, zmiana usługi może sparaliżować pracę.
Jak stosować: Przechowuj opisy procesów, decyzje i materiały źródłowe w zasobach, nad którymi masz kontrolę. Sprawdź, czy możesz przenieść je do innego narzędzia i nadal z nich korzystać.
Na co uważać: Sam eksport rozmów z chatbotem może nie odtworzyć powiązań między dokumentami, zadaniami i systemami.
3.Rozdziel decyzję o modelu od decyzji o infrastrukturze
Na czym polega: Daniel proponuje rozwiązanie pośrednie między korzystaniem wyłącznie z gotowej usługi a budową własnej serwerowni: wynajem zasobów obliczeniowych u innego podmiotu niż dostawca modelu.
Jak stosować: Przy projektowaniu systemu osobno oceń model, miejsce przetwarzania danych i sposób przechowywania firmowej wiedzy. Dla wrażliwych zastosowań sprawdź, czy model da się uruchamiać na wydzielonej infrastrukturze.
Na co uważać: Samo przeniesienie obliczeń nie usuwa wszystkich zależności. Nadal trzeba zadbać o dostęp, aktualizacje, koszty i bezpieczeństwo danych.
4.Ustal, co można znaleźć o tobie i twoich projektach
Na czym polega: Daniel traktuje publiczne informacje o sobie oraz wystawione w internecie aplikacje jako część obszaru, który trzeba chronić.
Jak stosować: Przejrzyj stare profile, wpisy i strony. Sporządź też listę uruchomionych usług oraz sprawdź, które z nich mają automatyczne kontrole bezpieczeństwa.
Na co uważać: Nie zakładaj, że mały, dawno porzucony projekt przestał być dostępny. Daniel obejmuje kontrolą każdą usługę, którą publikuje.
5.Zbieraj kontekst tam, gdzie naprawdę powstaje
Na czym polega: Pomysły i ustalenia pojawiają się w rozmowach, podczas spaceru, w zapisanych wpisach i na spotkaniach. LifeOS wprowadza takie materiały do jednego systemu, z którego mogą korzystać agenci.
Jak stosować: Wybierz jedno lub dwa źródła, na przykład notatki ze spotkań i zapisane artykuły. Ustal prostą drogę od materiału źródłowego do wyszukiwalnej notatki albo propozycji zadania.
Na co uważać: Automatycznie wykryte „zadanie” może być tylko luźną uwagą. Przed jego wykonaniem sprawdź intencję i zakres, szczególnie gdy dotyczy bezpieczeństwa.
6.Zapisuj kryteria dobrego wyniku, nie tylko instrukcję wykonania
Na czym polega: Wiele osobistych umiejętności Daniela opisuje, jaki rezultat odpowiada jego potrzebom. Dzięki temu agent może sam dobrać drogę do celu.
Jak stosować: Dla powtarzalnego zadania zapisz przykład dobrego wyniku, najważniejsze preferencje i błędy, których chcesz uniknąć. Koryguj ten opis po rzeczywistych pomyłkach agenta.
Na co uważać: Ogólne hasła w rodzaju „zrób to świetnie” nie przekazują gustu ani sposobu podejmowania decyzji.
7.Trzymaj opis projektu i kryteria sprawdzenia razem
Na czym polega: Dokument ISA Daniela łączy cel projektu, decyzje, etapy budowy i sposób oceny każdego etapu. Ten sam zapis służy programowaniu oraz testowaniu.
Jak stosować: Przy nowej funkcji określ problem, oczekiwany rezultat i małe, sprawdzalne kroki. Gdy zmienia się decyzja, najpierw popraw dokument, a potem kod i testy.
Na co uważać: Jeden dokument pomaga tylko wtedy, gdy odpowiada rzeczywistemu działaniu programu. Przy dużym projekcie podziel szczegóły na mniejsze części, zachowując wspólny punkt odniesienia.
8.Dobieraj koszt modelu do trudności zadania
Na czym polega: Daniel kieruje proste operacje do tańszych modeli, a zadania wymagające głębszego rozumowania do mocniejszych.
Jak stosować: Podziel typowe zadania na kilka klas trudności. Zmierz jakość i koszt dla każdej z nich, a następnie ustaw reguły wyboru modelu.
Na co uważać: Tanie skierowanie zadania do niewłaściwego modelu może okazać się drogie, jeśli wynik trzeba wielokrotnie poprawiać.
9.Gdy odpowiedź jest wyborem, nie zawsze potrzebujesz długiego tekstu
Na czym polega: Daniel używa Jev tam, gdzie system ma wybrać jedną z wcześniej określonych odpowiedzi: model do zadania, kategorię oceny lub sygnał możliwej próby manipulacji poleceniem.
Jak stosować: Najpierw dobrze zdefiniuj możliwe odpowiedzi. Następnie sprawdź na przykładach, czy klasyfikacja pomaga podejmować właściwe decyzje.
Na co uważać: Jeśli lista odpowiedzi pomija ważny przypadek, nawet sprawny model będzie wybierał spośród złych możliwości.
10.Zachowaj własny osąd, gdy agent staje się głównym sposobem korzystania z komputera
Na czym polega: Rozmówcy obawiają się sytuacji, w której jeden asystent wybiera wiadomości, podpowiada decyzje i wykonuje większość czynności, a człowiek przestaje rozumieć, skąd wzięły się jego wnioski.
Jak stosować: Przy ważnych decyzjach zaglądaj do materiałów źródłowych, szukaj odmiennych stanowisk i sprawdzaj, gdzie działa agent oraz do jakich danych ma dostęp.
Na co uważać: Wygoda może stopniowo zastąpić samodzielną ocenę, nawet jeśli każda pojedyncza sugestia wydaje się rozsądna.
Redakcyjne tłumaczenie
Bezpieczeństwo w świecie agentów AI
David Ondrej: Daniel, zajmujesz się cyberbezpieczeństwem od ponad 25 lat. Pracowałeś przy nim między innymi w Apple. Jak agenci AI zmienią tę dziedzinę? Niedawno mieliśmy głośny incydent dotyczący Hugging Face. Dokąd to zmierza?
Daniel: Obawiam się, że w niedobre miejsce. Będziemy obserwować starcie AI używanej do ataków z AI, która ma przed nimi bronić. Znaczenie będzie miało to, jak dobre modele stosujesz, jak dokładnie sprawdzasz swoje systemy i jak szybko reagujesz. Jeśli bronisz infrastruktury i nie rozwijasz takich możliwości, znajdziesz się w gorszym położeniu.
David: Czyli jednym z głównych kosztów tworzenia oprogramowania może się stać liczba tokenów wydanych na próby włamania do własnego systemu?
Daniel: Tak. Potrzebny będzie zestaw narzędzi do prowadzenia tych prób oraz odpowiednie modele. Podejrzewam, że z czasem większą rolę będą odgrywać same modele, choć narzędzia organizujące ich pracę nadal pozostaną ważne. Każda firma będzie musiała się tym zająć.
David: Większość widzów nie prowadzi jednak firmy wartej miliard dolarów i nie ma dostępu do najmocniejszych modeli bez ograniczeń. Co może zrobić ktoś ze zwykłym budżetem i przeciętnym zapleczem technicznym?
Daniel: Łączyłbym rozwiązania oferowane przez duże laboratoria, takie jak OpenAI czy Anthropic, z modelami o otwartych wagach, również takimi, z których usunięto część zabezpieczeń. Docelowo firmy powinny jednak umieć wykonywać więcej takich prac we własnym zakresie. Uzależnienie całej działalności od jednej czy dwóch zewnętrznych firm jest niebezpieczne, szczególnie jeśli przekazuje się im bardzo dużo informacji o swoim biznesie.
Kiedy dostawca AI staje się firmową pamięcią
David: Rozwińmy to. Chodzi o koszty i bezpieczeństwo, ale także o własność intelektualną. Ludzie często słyszą, że dostawca nie trenuje modelu na ich danych ani ich nie sprzedaje, i na tym kończą analizę. Dane mogą przecież służyć także innym celom. Jak powinna myśleć o tym firma, która ma coś wartościowego do ochrony? Samodzielne utrzymywanie modeli nie jest proste.
Daniel: Zależność od dostawcy ma kilka wymiarów. Wyobraź sobie Carol, która pracuje w firmie od 18 lat i wie, jak wszystko działa. Firma przenosi tę wiedzę do asystenta AI. Potem Carol odchodzi, po niej Alex i Raj. W pewnym momencie to zewnętrzny system najlepiej rozumie przedsiębiorstwo. Nowy pracownik, a może nawet kierownictwo, nie zna wszystkich powiązań i przyczyn dawnych decyzji.
Już wcześniej zdarzało się, że cała organizacja polegała na jednej osobie. Jeśli odchodziła, pojawiał się poważny problem. Teraz taką osobą może stać się model należący do innej firmy. Gdy zaczyna od niego zależeć codzienna działalność, rezygnacja z usługi przestaje być realną możliwością. To poziom zależności, który mnie niepokoi.
David: Co poradziłbyś firmie zatrudniającej 20, 50 czy 100 osób? Czy powinna kupić własny sprzęt?
Daniel: Myślę, że własne zasoby sprzętowe będą potrzebne, ale najpierw firma musi dokładnie rozumieć samą siebie. Buduję aplikację dla przedsiębiorstw o nazwie Vector, która ma w tym pomagać. Trzeba wiedzieć, jak działa każda część organizacji, umieć opisać jej zadania i zależności. To było ważne także przed pojawieniem się AI, lecz niewiele firm robiło to naprawdę dobrze.
Właśnie dlatego jedne organizacje szybko zaczęły korzystać z AI, a inne ledwie ruszyły z miejsca. Te drugie nie potrafiły wyjaśnić systemowi, jak pracują. Niektóre duże instytucje finansowe dokumentują natomiast procesy i każdą zmianę tak szczegółowo, że mogą przekazać te informacje modelowi. Ten może wtedy wskazać, w czym pomoże, a gdzie decyzja nadal należy do człowieka. Jeśli firma sama nie zna swojego sposobu działania, trudno jej w ogóle rozpocząć sensowny projekt AI.
David: Jaki byłby pierwszy krok? Spisanie procedur?
Daniel: Tak. Trzeba zebrać rozproszoną wiedzę, opisać procesy, przepływ pracy i źródła informacji. Wtedy można zdecydować, jakie modele będą przydatne. Większość firm nie zbuduje własnej farmy procesorów graficznych. Istnieje jednak rozwiązanie pośrednie: wynająć wydzielone zasoby obliczeniowe od dostawcy innego niż ten, od którego bierze się model. Obliczenia nadal odbywają się w chmurze, ale jedna firma nie skupia już u siebie wszystkich elementów.
Co internet wie o tobie
David: A co z osobą prywatną? Ktoś tworzy oprogramowanie, ma pliki na dysku internetowym i wiele danych dostępnych w sieci. Jak powinien podejść do bezpieczeństwa?
David, przerwa promocyjna: Przy okazji prac nad produktami warto wiedzieć, jak ludzie rzeczywiście z nich korzystają. Sponsorem odcinka jest PostHog, który pokazuje między innymi, gdzie użytkownicy napotykają trudności, z jakich funkcji korzystają i czy wracają. Ma też funkcję odtwarzania sesji. Jeśli szybko publikujesz nowe funkcje, równie szybko potrzebujesz informacji zwrotnej.
Daniel: Pokażę skrajną wersję tego, co sam robię. Mój system nazywa się Bunker. Każdy projekt, który udostępniam w internecie, trafia do niego i jest regularnie sprawdzany. Nie chcę utrzymywać publicznie czegoś, czego już nie rozumiem albo o czym zapomniałem.
W przypadku osoby prywatnej zacząłbym od pytania: co internet o mnie wie? Przejrzyj serwisy, które gromadzą dane o ludziach, stare wpisy, profile społecznościowe i własne strony. Istnieją też usługi pomagające usuwać informacje z baz pośredników danych. Chodzi o poznanie tego, co obca osoba mogłaby znaleźć na twój temat.
Uważam, że atakowanie konkretnych ludzi stanie się znacznie łatwiejsze. Ktoś może zlecić agentowi zebranie materiałów, które zaszkodzą nielubianej osobie, a potem przygotowanie kampanii przeciw niej. W przyszłości modele o otwartych wagach, pozbawione zabezpieczeń, mogą wykonywać takie polecenia równie sprawnie jak niewinne prośby. Musimy więc rozumieć, jakie informacje o nas i naszych projektach są dostępne oraz jak można je wykorzystać.
LifeOS: osobisty kontekst dla agentów
David: Pokaż, jak sam pracujesz z agentami. Jakich modeli i narzędzi używasz?
Daniel: Zbudowałem własny system, LifeOS. Wcześniej rozwijałem go pod nazwą PAI, od „personal AI infrastructure”. Zmieniłem nazwę, bo przestał być tylko narzędziem do programowania. Ma pomagać w różnych dziedzinach życia.
Jego podstawą jest opis tego, gdzie jestem i dokąd chcę dojść. Mam w nim swoją misję, cele, strategie, problemy i sprawy, nad którymi pracuję. Gdy proszę o stronę internetową czy wpis na blog, nie muszę za każdym razem wyjaśniać wszystkiego od początku. System już zna mój kontekst.
Mam około 150 niewielkich umiejętności, czyli opisów wykonywania określonych rodzajów zadań. Część jest publiczna, a część dostosowałem wyłącznie do siebie. Zwykle nie narzucają one agentowi każdego kroku. Mówią raczej, jak wygląda wynik, który uznam za dobry.
David: Czy umiejętność zapisania własnych preferencji i sposobu oceniania wyników stanie się dla ludzi coraz ważniejsza?
Daniel: Tak. Od lat wyobrażam sobie asystenta, z którym rozmawiasz, a on wykonuje działania przez interfejsy różnych usług. W filmach science fiction taki system najpierw poznaje życie użytkownika, a dopiero potem pyta, czym ma się zająć. Moim zdaniem to rozsądny kierunek. Żeby agent wiedział, czego chcę, musi mieć dostęp do wiedzy o mnie — oczywiście takiej, którą postanowię mu przekazać.
LifeOS ma mechanizm rozmów służących zebraniu tych informacji. U siebie połączyłem dane zawodowe i osobiste. Jednym z elementów jest Tilos: zapis obecnej sytuacji, stanu, do którego dążę, trudności oraz możliwych strategii. Mój asystent Kai korzysta z tego opisu przy wykonywaniu zadań.
Wszystko działa u mnie lokalnie. W jednym miejscu mam informacje o projektach, rzeczach, które posiadam, publikowanym oprogramowaniu i tempie pracy. Osobny moduł obejmuje publicznie dostępne usługi, które wymagają kontroli bezpieczeństwa. Jest też pamięć systemu. Jeśli zapiszę wpis z serwisu X, dawniej Twittera, materiał trafia do niej po przetworzeniu. Chcę, by wartościowa informacja, którą napotkam, była później dostępna agentom.
David: To ważne, bo wiele potrzebnych informacji nigdy nie trafia do formalnej dokumentacji. Powstają w rozmowie z zespołem, podczas spotkania albo przy okazji czytania czegoś w sieci.
Daniel: Dokładnie. Używam również urządzenia, które zapisuje moje wypowiedzi. Kiedy idę na spacer i mówię o pomyśle, mogę później poprosić Kaia o krótkie zestawienie tematów z ostatnich rozmów. Nie muszę tłumaczyć mu, z którego urządzenia ani z jakiego interfejsu ma pobrać zapis. System już wie, gdzie szukać.
Nie chodzi o gromadzenie plików, do których nigdy nie wrócę. Chcę, by informacje trafiały od razu tam, gdzie mogą pomóc w pracy.
Od rozmowy do zadania
David: Nasz zespół zaczął nagrywać ważne rozmowy o pracy, choćby telefonem. Kiedy siadamy do komputera, możemy przekazać agentowi zapis ustaleń, zamiast ponownie opowiadać mu całą sprawę.
Daniel: U mnie idzie to jeszcze krok dalej. Mam prywatne repozytorium dostępne dla ludzi i agentów. System analizuje napływające materiały i proponuje na ich podstawie zadania w GitHubie. Mogę zapytać, którymi z nich powinniśmy się teraz zająć.
David: Jak decydujesz, co powinno zostać zadaniem, a co agent może po prostu zrobić od razu?
Daniel: Niektóre rzeczy da się wykonać automatycznie, ale trzeba uważać. Mogę przecież rozmawiać o technikach ofensywnego testowania bezpieczeństwa, nie zlecając żadnego ataku. Agent nie powinien uznać każdej wzmianki za polecenie. Najważniejsze jest dla mnie to, że nie muszę dodatkowo przepisywać pomysłu: system sam go wychwytuje.
Od lat nosiłem przy sobie kartki i długopis, żeby od razu notować ważne sprawy. Teraz część tego zapisywania dzieje się automatycznie.
David: Ludzie źle pamiętają szczegóły. Znacznie lepiej zapisać ustalenie w pliku czy zadaniu, niż liczyć na to, że wszyscy odtworzą je później z pamięci.
Daniel: Zgoda. Ale zanim zaczniemy automatyzować pracę, powinniśmy też wiedzieć, co właściwie chcemy osiągnąć. Dlatego wracam do Tilos. Jeśli AI przejmie część naszych obowiązków, potrzebujemy własnego kierunku działania. Chciałbym pomagać ludziom przechodzić od wykonywania cudzych poleceń do realizowania własnych pomysłów. To wymaga umiejętności powiedzenia, na czym nam zależy.
Cele, wiedza i zmieniająca się praca
David: Znam ludzi, którzy widzą możliwości AI, a mimo to planują karierę dokładnie tak, jak przed jej pojawieniem się. Spotkałem też osoby używające jej bardzo twórczo. Różnica między nimi może się powiększać.
Daniel: Niedawno na hackathonie widziałem dziewięciolatka, który zbudował działającą aplikację i przepraszał, że nie zdążył dopracować interfejsu. Niedaleko stamtąd rozmawiałem z dorosłym człowiekiem przekonanym, że ChatGPT był chwilową modą, która już minęła. Tak odmienne podejście można spotkać w tym samym regionie.
Same narzędzia nie wystarczą. Trzeba jeszcze mieć pomysł, co z nimi zrobić. Pokazuję ludziom swoje możliwości, pytam, co chcieliby stworzyć, i czasem słyszę: „Nie wiem. Może AI poleci mi lepszy serial?”. Nie obwiniam ich. Uważam, że wielu osobom przez lata odradzano ambitne, samodzielne przedsięwzięcia.
Proponuję trzy rzeczy. Po pierwsze, ucz się, jak działa świat — od nauk przyrodniczych po psychologię i politykę. Po drugie, zastanów się, kim jesteś i co chciałbyś zmienić. Po trzecie, naucz się dobrze korzystać z AI, żeby móc działać w wybranym kierunku. Czytam dużo książek z różnych dziedzin, bo dzięki nim dostrzegam problemy i związki, na które inaczej bym nie wpadł.
David: Czy AI samo nie zacznie wybierać trafnych celów? Może z czasem także pomysły na działanie przestaną być szczególnie ludzką domeną?
Daniel: Nie spodziewam się tego szybko przy obecnym sposobie budowy modeli. Ludzkie pragnienia mają związek z naszą biologią i historią ewolucyjną. Model potrafi wykonać zadanie, ale sam z siebie nie chce tego, czego chce człowiek. Można próbować nadać mu własne cele, lecz to prowadzi także do trudnych pytań o bezpieczeństwo.
David: A czy człowiek powinien nadal rozumieć techniczne podstawy, skoro agent może wykonać coraz więcej pracy?
Daniel: Tak. Nie trzeba ręcznie robić wszystkiego ani znać każdego szczegółu, ale trzeba zachować podstawową orientację. Jeśli nie rozumiesz, jak działa twoja firma albo gdzie i na jakich zasadach pracuje agent, tracisz możliwość oceny jego działań.
Jest jeszcze ryzyko dotyczące informacji. Wyobraź sobie, że asystent wybiera dla ciebie wiadomości i staje się głównym sposobem kontaktu ze światem. Po pewnym czasie powinieneś zapytać: skąd wzięły się moje poglądy, jakie stanowiska pominięto i czy ktoś wpływa na wybory mojego agenta? Oddanie mu całej kontroli nad tym, co czytasz, może stopniowo zmieniać twoją ocenę rzeczywistości.
David: Sądzisz, że agenci będą wkrótce wykonywać niemal wszystkie czynności przy komputerze?
Daniel: Myślę, że coraz więcej z nich. Będziemy wydawać polecenia na wyższym poziomie, a szczegóły pozostawimy systemom. To jednak zwiększy znaczenie nadzoru: trzeba będzie rozumieć, jakie decyzje podejmują i dlaczego. Nie wiem, jakich dokładnie technologii użyją w przyszłości. Wyobrażam sobie wiele połączonych usług, które mogą bezpiecznie wymieniać informacje i wykonywać działania.
Daniel opisuje następnie swoją dalekosiężną wizję świata, w którym urządzenia, instytucje i ludzie udostępniają agentom określone informacje o swoim stanie oraz potrzebach. Podaje przykład miejskiej zieleni sygnalizującej potrzebę podlewania, a także asystentów pomagających ludziom nawiązywać kontakt. Traktuje to jako spekulację o możliwym kierunku rozwoju, nie opis istniejącego rozwiązania.
David: A w bliższym czasie? Co się stanie, gdy jedni nauczą się sprawnie kierować wieloma agentami, a inni pozostaną przy okazjonalnym używaniu chatbota?
Daniel: Obawiam się silnego podziału. Część obecnych miejsc pracy może zniknąć, a niektórzy ludzie będą potrzebowali wsparcia dochodowego. Jednocześnie osoby tworzące nowe produkty i usługi z pomocą agentów mogą rozwijać przedsięwzięcia w dotąd niespotykanym tempie. To moja prognoza, nie pewnik. Samo udostępnienie AI wszystkim nie oznacza, że wszyscy skorzystają z niej w podobny sposób.
W dalszej części rozmowy Daniel snuje jeszcze bardziej odległe przypuszczenia: zastanawia się, czy przyszłe badania mogłyby pomóc ludziom rozwijać motywację lub empatię. David zauważa, że jeśli wykluczenie z nowych możliwości stanie się poważnym problemem społecznym, pojawi się także potrzeba szukania rozwiązań. Daniel przywołuje wyobrażone narzędzie pozwalające doświadczyć cudzej perspektywy. Obaj wracają jednak do bliższej perspektywy: nierówne korzystanie z AI już teraz może pogłębiać różnice między ludźmi.
Pokaz pracy: od pomysłu do dokumentu ISA
David: Chciałbym zobaczyć, jak naprawdę tworzysz oprogramowanie. Pokażesz przykład pracy z agentami?
Daniel: Wybierzmy coś, co moglibyśmy zbudować teraz.
David: Może wykorzystajmy Jev, o którym ostatnio dużo się mówi. Do czego mógłby ci się przydać?
Daniel: Chciałbym przeanalizować wcześniejsze sesje agentów i ustalić, co należy poprawić w LifeOS.
David: To ciekawe. Zapisy pracy agentów mogą pokazać, dlaczego się zatrzymują: czy zabrakło im internetu, informacji, uprawnień, czy czegoś innego.
Daniel: Mam już system, który oznacza moje skargi i błędy jako sygnały, że coś wymaga poprawy. Teraz przygotujemy dla tego pomysłu dokument ISA i zaczniemy pracę.
W moim środowisku różne zadania trafiają do różnych modeli. Dobór zależy od potrzebnego poziomu rozumowania oraz kosztu. Proste operacje kieruję do lżejszych modeli; trudniejsze do mocniejszych. Jev pomaga ocenić polecenie i wybrać odpowiednią ścieżkę. Korzystam też z modeli Anthropic do wybranych prac.
David: Chodzi głównie o oszczędzanie tokenów czy o przypisywanie zadań do modeli, które najlepiej sobie z nimi radzą?
Daniel: Obecnie o jedno i drugie, przede wszystkim o poziom trudności. Mam kilka klas modeli. Jeśli zadanie jest proste, nie potrzebuje najmocniejszego. Gdy wymaga głębszej analizy, dostaje większe zasoby.
David: Wspomniałeś o ISA. Co to za dokument?
Daniel: To główny opis przedsięwzięcia. Zawiera problem, zamierzony rezultat, decyzje podejmowane po drodze i kolejne kroki. Zebrałem w nim rzeczy, które zwykle są rozproszone między specyfikacją, planem i innymi plikami.
Pokażę przykład aplikacji Surface, której używam do przeglądania wiadomości. ISA opisuje jej cel i poszczególne części. Każdy krok budowy odpowiada zarazem temu, co trzeba później sprawdzić. Gdy podejmujemy nową decyzję, aktualizujemy ten dokument, zmieniamy kod i upewniamy się, że oba nadal do siebie pasują. Na tym opiera się mój sposób tworzenia oprogramowania.
Jeden opis projektu, wiele kontroli
Daniel: LifeOS wczytuje informacje stopniowo. Ma ogólne zasady działania, opis mnie jako użytkownika, opis asystenta Kaia oraz niewielkie umiejętności. Plik wskazujący drogę do tych materiałów służy przede wszystkim odnajdywaniu właściwych informacji. Szczegółowe reguły są gdzie indziej.
David: Czy podobne pliki instrukcji umieszczasz również w każdym projekcie?
Daniel: Nie. Dla konkretnego projektu podstawowym dokumentem jest ISA. Przy bardzo dużym przedsięwzięciu może on odsyłać do kilku mniejszych części, ale wciąż mamy jeden uporządkowany opis tego, co budujemy. Kod musi odpowiadać dokumentowi, a dokument — kodowi.
Kontrole w Bunkerze opierają się na moim systemie ocen. Jedne są jednoznaczne: warunek jest spełniony albo nie. Inne wymagają oceny. Model może wtedy wybrać odpowiedź według ustalonych kryteriów albo porównać dwa wyniki. Jev dobrze pasuje do takich decyzji, dlatego włączyłem go do systemu ocen.
David: Co szczególnie zainteresowało cię w Jev?
Daniel: Zrozumiałem, że wiele pytań zadawanych modelom nie wymaga odpowiedzi w postaci swobodnie napisanego tekstu. Wystarczy wybór z dobrze przygotowanych możliwości. Warunek jest jeden: najpierw trzeba te możliwości trafnie określić.
Przejrzałem LifeOS, szukając takich miejsc. Czy nowe polecenie wygląda na próbę manipulacji agentem? Który model powinien dostać zadanie? Jak ocenić wynik według przyjętych kryteriów? Właśnie tam Jev może być użyteczny. Szczególnie ważny jest system ocen, bo na nim opiera się sprawdzanie pozostałych części.
W Bunkerze większość regularnych kontroli ma postać prostych, jednoznacznych warunków. Muszą działać szybko: uruchamiam ich około 1500 co godzinę dla licznych opublikowanych usług. Tam, gdzie odpowiedzi nie da się równie łatwo rozstrzygnąć, korzystam z oceny modelu.
Jak Daniel dzieli usługi na części
Daniel: Surface pobiera materiały z około 5300 źródeł i ocenia napływające treści. Rozwijam tę aplikację również z użyciem Jev. Jej zaplecze składa się z małych usług uruchomionych na Cloudflare Workers. Każda wykonuje określoną czynność; można je łączyć w ciągi działań i uzyskiwać potrzebny wynik. Całą aplikację nadal opisuje jeden ISA.
David: Dzięki temu agent może sprawdzić w jednym miejscu, czy jego praca zmierza we właściwym kierunku.
Daniel: Tak. Zmiana trafia najpierw do ISA, potem do kodu, a następnie system sprawdza ich zgodność. Kryteria są drobne i możliwe do oceny. Myślę nawet o tym, by Jev wskazywał, czy dane kryterium jest wystarczająco szczegółowe, czy należy je rozbić na mniejsze części. Tego akurat jeszcze nie wdrożyłem.
U podstaw tego podejścia leży prosty problem: często oczekujemy od AI wyniku, którego sami nie opisaliśmy dostatecznie jasno. Kiedy zaczynam projekt, staram się jak najdokładniej powiedzieć, czego chcę. Jeśli opis ma zbyt wiele luk, system dopytuje mnie przed rozpoczęciem pracy. A gdy później pojawia się błąd, często okazuje się, że wiedziałem o czymś ważnym, lecz nie wpisałem tego do dokumentu.
David: To przypomina zwykłe nieporozumienia między ludźmi w zespole. Ktoś miał oczekiwanie, którego nie przekazał drugiej osobie.
Daniel: Właśnie tak.
Narzędzie prowadzącego i zakończenie
David, o Cloudroom: Wielu widzów pyta też o interfejs, w którym korzystam z różnych modeli i narzędzi do pracy z agentami. To Cloudroom, projekt, nad którym pracuję. Jego graficzny interfejs oraz podstawowe składniki są dostępne jako otwarte oprogramowanie. Można pobrać interfejs i używać go z posiadanymi już usługami. Druga część projektu, Cloudroom Cloud, ma zapewniać każdemu agentowi odizolowane środowisko pracy; na razie jest we wczesnej fazie i dostęp do niej jest ograniczony. Kod projektu można przeglądać, zgłaszać poprawki i uruchamiać samodzielnie.
David: Muszę już kończyć, choć chętnie przyjrzałbym się ISA dokładniej. Gdzie można znaleźć twoje projekty?
Daniel: Na mojej stronie danielis.com oraz pod adresem ourlifeos.ai. Tam są dalsze informacje. Dzięki za rozmowę.
David: Dziękuję za pokaz i za twój czas.