Gdzie agenci kodujący pomagają, a gdzie zawodzą

Pedro Alves od 25 lat intensywnie pracuje z AI. Obecnie jest dyrektorem technicznym w Thoth AI oraz twórcą Last Week in AI.

Usiedliśmy z Pedro, aby porozmawiać o agentach programistycznych — i o tym, dlaczego tak ważne jest, aby wiedzieć, co potrafią, a czego nie potrafią. Oto, co nam powiedział.

Zanim „AI” stała się czymś, co ludzie umieszczali na slajdach

Jestem Pedro, dyrektorem technicznym w Thoth AI. Pracowałem z AI, zanim stała się czymś, co ludzie umieszczali na slajdach — w 2001 roku, jako student informatyki, stworzyłem mały świat pełen agentów i pozwoliłem im uczyć się wzajemnego pokonywania, tworząc swego rodzaju cyfrową grę w życie, której głównym celem było obserwowanie, jak stają się coraz lepsi. To było 25 lat temu, a ja wciąż poszukuję odpowiedzi na to samo pytanie: jak sprawić, aby system się doskonalił?

Kiedy nadszedł czas na studia magisterskie, wszyscy zakładali, że zrobię doktorat z uczenia maszynowego. Nie zrobiłem tego. Ta dziedzina wydawała mi się zbyt wąska i zbyt teoretyczna. Chciałem nauczyć się rzemiosła, pracując na najbogatszych i najbardziej chaotycznych danych, jakie mogłem znaleźć, więc zająłem się biologią obliczeniową: proteomiką na studiach magisterskich i genomiką podczas doktoratu. Zdobywałem wiedzę z zakresu uczenia maszynowego, statystyki i nauki o danych, stosując ją — do sieci interakcji gen-gen, inżynierii cech, sieci neuronowych i metod zespołowych — w problemach, w których błąd miał swoją cenę.

To właśnie wtedy nauczyłem się lekcji, która od tamtej pory kształtuje wszystko, co robię. W medycynie tworzyłem modele progresji chorób, a standardowa miara — ogólna dokładność — była bezużyteczna. „Dobry” model według tej miary jedynie potwierdzał przypadki, o których lekarze już wiedzieli, podczas gdy cała wartość tkwiła w przypadkach, które przeoczyli. Zamiast więc optymalizować dokładność, optymalizowałem częściowe AUC — zasadniczo umiejętność modelu w odniesieniu do przypadków, które miały znaczenie. Wskaźnik, który ktoś ci przekazuje, niemal nigdy nie jest prawdziwym celem.

Stamtąd odwiedzałem różne branże: wspomniane modele medyczne, pracę konsultingową dla profesjonalnej drużyny piłkarskiej, następnie Dolinę Krzemową i lata spędzone przy widzeniu komputerowym — w czasach, gdy aby w ogóle uruchomić wykrywanie i klasyfikację, trzeba było wprowadzać innowacje w sposobie trenowania, a nawet inicjalizowania wag sieci. Pracowałem z danymi z sieci społecznościowych, handlu detalicznego, mody i materiałów wideo. Przez rok budowałem algorytmy transakcyjne z wykorzystaniem algorytmów genetycznych i optymalizacji rojem cząstek — nieparametrycznych metod optymalizacji, o których pisałem prace podczas studiów doktoranckich. W końcu założyłem własną firmę, tworząc narzędzia AI dla osób, które nie były analitykami danych.

To właśnie szerokie doświadczenie łączy wszystkie te elementy. Po pracy w kilkunastu dziedzinach wciąż widzę ten sam problem w różnych odsłonach — sztuczka oczywista w genomice okazuje się kluczem w widzeniu komputerowym. Bardziej interesuje mnie sposób sformułowania problemu niż jego rozwiązanie, ponieważ to właśnie w sposobie sformułowania kryje się dźwignia.

To właśnie sprowadza mnie do Thoth. Na papierze jesteśmy firmą zajmującą się adnotacją danych. Uważam jednak, że problem, który rozwiązuje cała ta branża, jest niewłaściwie określony. Nikt nie chce opatrzonych adnotacjami danych — dane są tylko etapem pośrednim. Ludzie chcą lepszego modelu. Dlatego dążę do przyszłości, w której system sam ustali, jakich danych potrzebuje twój model, aby się doskonalić, i zajmie się tym za ciebie, abyś mógł skupić się na modelu zamiast na etykietowaniu.

Dwie strony działalności

Strukturalnie Thoth AI ma dwie strony. Jedną z nich jest silnik operacji na danych, który działa na arenie międzynarodowej i na dużą skalę. Jest większy niż typowy startup, ale wciąż znacznie mniejszy od gigantów w tej branży, więc określiłbym go jako średniej wielkości. Druga strona, ta, którą buduję, to zupełnie nowy zespół badawczo-innowacyjny tutaj, w rejonie Zatoki San Francisco — obecnie liczący pięć osób, a w ciągu najbliższych kilku miesięcy dołączą do nas kolejne. Tam zajmujemy się pozostałą częścią doskonalenia modeli: wszystkim poza etykietowaniem.

Nasze badania koncentrują się na dwóch głównych kierunkach. Pierwszym jest robotyka: generowanie danych ucieleśnionych, ich ocena oraz wykorzystywanie aktywnego uczenia do automatycznego generowania najlepszych możliwych danych treningowych, aby roboty mogły uczyć się swoich zadań na możliwie najmniejszej ilości danych. Większość tych działań wykorzystuje dane egocentryczne (zasadniczo nagrania z perspektywy pierwszej osoby), a znaczną część naszej pracy poświęcamy tworzeniu danych egocentrycznych najwyższej możliwej jakości. Drugim kierunkiem jest niezawodność i wydajność modeli językowych: zrozumienie, co powoduje halucynacje i jak wyglądają, a także — po stronie wydajności — rozpoznawanie, kiedy mniejszy model może obsłużyć zapytanie, a następnie przeformułowanie go lub podzielenie na części, aby prostszy i tańszy model mógł na nie odpowiedzieć. Wszystko to jest obecnie przedmiotem badań, ukierunkowanych na produkty, które wprowadzimy na rynek w ramach tego zespołu.

Jeśli chodzi o etap rozwoju i wielkość: dział danych to ugruntowana, średniej wielkości międzynarodowa działalność, podczas gdy amerykański zespół badawczy jest celowo na wczesnym etapie. Obecnie pięcioro z nas pracuje w biurze w San Mateo, a w ciągu najbliższych kilku miesięcy dołączy do nas jeszcze jedna lub dwie osoby. Taki jest nasz obecny status.

Jak intensywne testowanie prowadzi do niezawodnych rezultatów

Pedro dzieli się doświadczeniami

Przygotowania w większości wykonują się teraz same. Ale to nie jest prawdziwa korzyść. Większa poprawa dotyczy jakości: spotkanie jest bardziej konkretne i skupione na najważniejszych kwestiach, a właściwe sprawy niezawodnie trafiają do CEO.

Wiele osób spieszy się z automatyzacją każdego zadania i procesu za pomocą AI, ale podchodzę do tego ostrożnie. AI sprawia, że tworzenie wersji demonstracyjnej jest banalnie proste. Zbudowanie czegoś niezawodnego do codziennego użytku to zupełnie inna sprawa. Gdy naprawdę korzystasz z tych narzędzi, napotykasz przypadki brzegowe i szczególne, w których automatyzacja niemal działa, ale jednak nie do końca. Dlatego przed zaufaniem czemukolwiek w rzeczywistym procesie pracy intensywnie to testuję.

W tym roku stworzyłem narzędzia AI na potrzeby naszego cotygodniowego spotkania przeglądowego z CEO, które spełniły ten standard. Narzędzia wysyłają e-maile do właścicieli poszczególnych obszarów, aby zebrać aktualizacje, automatycznie zestawiają odpowiedzi, przygotowują projekty raportów, podsumowań i agendy oraz śledzą wyniki w czasie.

Wcześniej wszystko to odbywało się ręcznie. Ktoś ponaglał ludzi w sprawie aktualizacji, ręcznie łączył odpowiedzi, pisał podsumowania i agendę oraz śledził rezultaty z tygodnia na tydzień. To działało, ale było powolne, a agenda łatwo przesuwała się w stronę tego, co było najświeższe, zamiast tego, co miało największe znaczenie.

Przygotowania w większości wykonują się teraz same. Ale to nie jest prawdziwa korzyść. Większa poprawa dotyczy jakości: spotkanie jest bardziej konkretne i skupione na najważniejszych kwestiach, a właściwe sprawy niezawodnie trafiają do CEO. Chodzi więc mniej o zaoszczędzony czas, a bardziej o skierowanie uwagi CEO na decyzje, które naprawdę mają znaczenie.

Dlaczego ocena pozostaje domeną człowieka, podczas gdy AI przyspiesza programowanie

AI napędza teraz samo programowanie niemal wszędzie. Moi badacze, inżynierowie wdrażający nasze rozwiązania na środowisko produkcyjne oraz ja wszyscy korzystamy z narzędzi AI do programowania. To ludzka ocena, a nie konkretna kategoria zadań, decyduje o tym, jak powstaje kod, a standard ten zmienia się wraz ze stawką.

Po stronie badawczej celem jest zwykle uruchomienie czegoś, często poprzez skonfigurowanie repozytorium GitHub w celu sprawdzenia wykonalności pomysłu. Nic nie trafia na środowisko produkcyjne, więc łagodniej oceniam sposób napisania kodu. Jeśli działa i odpowiada na pytanie, to wystarczy.

Produkcja to coś innego. To, jak coś budujemy, ma równie duże znaczenie jak to, czy działa, dlatego ostrożniej korzystamy z AI. Starsi rangą inżynierowie odpowiadają za architekturę, jakość i przeglądy kodu. AI ich przyspiesza, ale nie podejmuje tych decyzji. Ta granica pozostaje domeną człowieka.

Pomaga doświadczenie zespołu. Jego członkowie korzystają z AI inaczej niż osoby mniej doświadczone. Już wiedzą, jak wygląda dobra praca, więc model wzmacnia ich istniejącą ocenę, zamiast zastępować ocenę, którą dopiero rozwijają. Przyspiesza ich pracę, nie zastępując jej kluczowego elementu.

Jak skutecznie korzystać z agentów programistycznych

Ogólnie skuteczność agentów programistycznych wynika z dyscypliny, z jaką podchodzę do mocnych i słabych stron tej technologii.

Myślę o tym jak o malowaniu obrazu. Cel jest zawsze taki sam: wyjaśnić sobie obraz, który mam w głowie, a następnie użyć AI do przełożenia tego zamiaru na działający kod tak szybko, jak to możliwe. Sukces zależy od jednej zmiennej: ile pracy twórczej zachowuję dla siebie, a ile przekazuję dalej.

AI świetnie sprawdza się na pierwszym poziomie. Widzę cały obraz i nakładam szerokie pociągnięcia pędzla, a AI uzupełnia szczegóły. Dokładnie wiem, co trzeba zbudować, a przełożenie zamiaru na kod jest w zasadzie schematyczne. W tym obszarze AI naprawdę zwielokrotnia możliwości, a większość mojej codziennej pracy mieści się właśnie tutaj.

Drugi poziom jest przydatny, ale wiąże się z większą zmiennością. Jest podobny, jednak celowo pozostawiam kilka obszarów płótna otwartych i proszę model, aby coś w nich namalował. Wymaga to pewnej kreatywności, ale moje wskazówki nadal wyznaczają ramy. Traktuję taki rezultat jako szkic, a nie odpowiedź.

Ostrzegam ludzi przed trzecim poziomem. Polega on na przekazaniu AI twórczego rdzenia: definicji projektu lub kluczowych decyzji projektowych. Dla osoby, która nie zna dogłębnie danej dziedziny, wygląda to imponująco, ale znacznie częściej zawodzi, niż odnosi sukces, ponieważ model wypełnia lukę, którą powinienem był wypełnić sam.

Ta luka jest sednem sprawy. Niemal każdy projekt ma jedną wyjątkową rzecz, której potrzebuje: nieoczywistą obserwację lub decyzję, której wymaga problem. Domyślnie model zapewnia przeciętne rozwiązanie, najczęściej spotykany wzorzec ze swoich danych treningowych. To, co sprawia, że projekt działa, zazwyczaj nie jest przeciętne, a sztuczna inteligencja nie potrafi samodzielnie do tego dojść. To ja muszę znaleźć ten element. Następnie AI buduje wszystko, co wynika z tego elementu, szybciej i lepiej, niż mógłbym zrobić to sam.

Jak agenci programistyczni tworzą trudne do wykrycia błędy

Pedro dzieli się

Najbardziej oczywistym pozytywnym rezultatem korzystania z agentów programistycznych jest szybkość. Programowanie przebiega szybciej, co zwiększa częstotliwość wdrożeń, i nie chodzi tu wyłącznie o surową szybkość. Rzeczy, których konfiguracja była skomplikowana, są teraz znacznie łatwiejsze. Ta korzyść jest realna i ma znaczenie.

Najbardziej oczywistym pozytywnym rezultatem korzystania z agentów programistycznych jest szybkość. Programowanie przebiega szybciej, co zwiększa częstotliwość wdrożeń, i nie chodzi tu wyłącznie o surową szybkość. Rzeczy, których konfiguracja była skomplikowana, są teraz znacznie łatwiejsze. Ta korzyść jest realna i ma znaczenie.

Bardziej interesującym rezultatem jest to, jak zmieniły się nasze błędy. Wskaźnik defektów nie wzrósł, ale zmieniły się ich rodzaje. AI dba o to, by kod działał. Niemal zawsze sprawdza to, zanim przekaże kod użytkownikowi. Dlatego najprostsze błędy — te, które po prostu zgłaszają błąd lub uniemożliwiają uruchomienie — pojawiają się znacznie rzadziej. Pozostają błędy logiczne, przypadki, których model nie przemyślał, a ich wykrywanie jest trudniejsze właśnie dlatego, że kod działa bez zarzutu.

Na tym polega wada. Te błędy lepiej się ukrywają. Jeśli komuś brakuje doświadczenia lub zbyt mocno polega na narzędziu, widzi działający kod i zakłada, że jest poprawny, choć tak nie jest. Zagrożeniem nie jest większa liczba błędów, lecz fałszywa pewność. Potrzebujesz kogoś, kto wie, czego szukać, aby wykryć rzeczy, które przechodzą test „działa”, ale wciąż są niepoprawne.

Dlaczego AI należy wykorzystywać do zwiększania możliwości doświadczonych osób, zamiast rozwijać słabsze osoby

Najbardziej zaskoczyło mnie to, skąd bierze się efekt skali. Intuicyjnie można by pomyśleć, że AI obniża próg doświadczenia, pozwalając zatrudniać tańsze, mniej doświadczone zespoły i pozwalać narzędziom podnosić ich poziom. W praktyce okazało się odwrotnie. Doświadczenie ma teraz większe znaczenie, a nie mniejsze.

Sprowadza się to do niezawodności. Wykorzystanie AI do przekształcenia jednego starszego inżyniera w pięciu starszych inżynierów jest znacznie bardziej niezawodne niż przekształcenie młodszego inżyniera w starszego. AI zwielokrotnia osąd, który już posiadasz; nie wytwarza osądu, którego nie masz.

Dlatego zwiększam skalę działania moich najsilniejszych ludzi; nie próbuję podnosić poziomu najsłabszych. Kilka doświadczonych osób, z których każda osiąga kilkukrotnie większą wydajność niż wcześniej, za każdym razem pokonuje większy, zróżnicowany zespół.

Dlaczego kreatywność muszą wnosić ludzie — a nie AI

AI wyraźnie nie sprostało kreatywnym i łączącym aspektom badań. Gdy wykonuję pracę techniczną z pomocą AI, człowiek nadal musi połączyć poszczególne elementy: ustalić, jak rozwinąć cudzą pracę, połączyć dwa artykuły w sensowny sposób i wykonać logiczne skoki myślowe, które dla człowieka są oczywiste. Ta część nadal wymaga udziału człowieka.

Nie jest to zaskakujące, gdy pamięta się, czym są te modele. To maszyny probabilistyczne. Generują tekst, który z największym prawdopodobieństwem spodoba się czytelnikowi. Coraz lepiej radzimy sobie z trenowaniem ich do wykonywania innych rodzajów zadań, ale staje się to naprawdę trudne, gdy próbujemy nauczyć je samej kreatywności, ponieważ zbudowanie sygnału treningowego jest skomplikowane.

Rozważmy zbiory danych. Zbiór danych pokazujący, jak wygląda pies, jest łatwy do przygotowania. Zbierasz wiele zdjęć psów. Zbiór danych dotyczący kreatywności w rysowaniu psów stanowi inny problem. Weźmy na przykład kogoś, kto dodaje psu skrzydła. Sednem tego przykładu nie są skrzydła. Chodzi o abstrakcyjny ruch, który za nimi stoi: wzięcie czegoś, co nie pasuje, i umieszczenie tego tam, gdzie nikt się tego nie spodziewa. Aby model to zrozumiał, potrzebujesz ogromnej liczby przykładów, żeby nauczył się, że skrzydła nie mają znaczenia; znaczenie ma kreatywny gest.

Nawet jeśli do tego dojdzie, napotykasz kolejną przeszkodę. Teraz weź tę samą kreatywność i zastosuj ją do równania matematycznego lub fragmentu kodu z artykułu, wykorzystując ją do rozszerzenia czyjegoś algorytmu. Właśnie na takim przeniesieniu umiejętności wszystko się rozpada.

Ludzie polegają na maszynach dokładnie w tej części, w której są one najsłabsze. Paradoks polega na tym, że rozwiązanie jest tanie. Odrobina ludzkiej kreatywności może zdziałać bardzo wiele. Nie polegaj zbyt mocno na maszynie w tym obszarze, a zajdziesz zaskakująco daleko.

Dlaczego CTO muszą przeprojektować sposób przepływu możliwości AI w organizacjach

To nie będzie teraz popularna rada, ale uważam, że jest roztropna i najprawdopodobniej przyniesie najlepsze rezultaty: Bądź bardziej rozważny, niż skłania cię do tego chwila.

W tej chwili firmy wydają ogromne pieniądze, opierając się na prostym założeniu: każdy może zautomatyzować część swojej pracy za pomocą AI. Dlatego dyrektywa trafia do wszystkich. Do inżynierów, osób zajmujących się danymi, sprzedaży, marketingu — do całej firmy. Załóż konto, zautomatyzuj coś, zbuduj własne narzędzia, do dzieła. Rezultatem jest ogromna ilość zmarnowanego wysiłku: powielanie pracy, projekty, które donikąd nie prowadzą, oraz narzędzia, których nikt nie używa. Firmy spalają mnóstwo pieniędzy na wysiłek, czas i tokeny, które nie przynoszą żadnych trwałych rezultatów.

Nadajcie temu rzeczywisty proces. Scentralizujcie to. Utwórzcie mały centralny zespół, którego zadaniem będzie zwiększanie skuteczności wszystkich pozostałych zespołów dzięki AI. Zespół ten opracowuje przepływy pracy, kontekst wielokrotnego użytku, standardy i skuteczne wzorce, a następnie udostępnia je innym, dzięki czemu poszczególni inżynierowie nie muszą osobno ponosić kosztów odkrywania. To strukturalna wersja tego, co powiedziałem wcześniej o koncentrowaniu dźwigni na najsilniejszych pracownikach: kilku inżynierów biegle posługujących się AI podnosi skuteczność całej organizacji.

Przynosi to jednocześnie dwa rezultaty. Wykorzystanie zasobów rośnie, ponieważ zespoły stosują sprawdzone wzorce zamiast działać na chybił trafił. Odzyskujecie też znaczną ilość czasu, który po cichu traciliście na eksperymenty, których nie trzeba było przeprowadzać więcej niż raz.

Bądź na bieżąco

Możesz śledzić pracę Pedra Alvesa na LinkedInie lub zasubskrybować jego newsletter Miniony tydzień w AI. Sprawdź także Thoth AI.

Już wkrótce na The CTO Club pojawią się kolejne wywiady z ekspertami!