GenAI/LLMy dziś to są konie pociągowe. O tym, jak dobrze działają, decyduje jakość uprzęży (aka harness).
To było widać w analizie wycieku z Claude Code, która wywołała wiele uśmieszków i komentarzy w stylu: „Jak to? Najlepsze narzędzie do okiełznania LLM-ów jest takie prostackie?”. Masa promptów, a do tego kod z w pełni deterministycznymi mechanizmami, jak wykrywanie frustracji przez przekleństwa...
Jakoś wielu komentatorom umykało, że ten pełny determinizm regexów jest mechanizmem kontroli, wymuszającym stabilność systemu. Fakt – ten do wykrywania frustracji był pewnie po prostu łatwiejszy do zaimplementowania lokalnie niż wysyłanie całego kontekstu do LLM-a tylko po to, by ten wyłapał kilka wulgaryzmów.
Ale jak się zastanowić, to nie jest dziwne.
Na dziś LLMy są świetne, ale jeszcze nie potrafią się same kontrolować. Nie mają zdrowego rozsądku, nie znają relacji przestrzennych, a nawet nie do końca rozumieją, że np. jeśli człowiek je i ma usta pełne jedzenia, to nie może jednocześnie mówić.
W pierwszej fazie zachwytów nad LLM-ami poszliśmy na żywioł. Korzystaliśmy maksymalnie z tego, że potrafią na podstawie poprzednich słów genialnie napisać kolejne. Taki LLM jest sprytniejszy od łańcuchów Markowa – choć nie rozumie per se tego, co pisze, to sama gramatyka i język kodują pewne informacje i zależności. To specyficzne „strukturalne zrozumienie” (nie kognitywne, lecz wynikające z wyczucia struktury) wynika stąd, że model widzi cały kontekst jednocześnie.
Okazało się też, że świetnie działa to na kodzie.
Szybko jednak wyszło na jaw, że to podejście sprawdza się głównie wtedy, gdy na wynik patrzy człowiek, weryfikuje go i na bieżąco przygląda się temu, co powstało.
To jest IMHO ten punkt, którego nie dostrzeżono na początku, gdy wielu uznawało, że LLM-y natychmiast wyprą ludzi. Bo coś, co modelowi zajmuje ułamki sekundy, człowiek musi robić przez 15-30 minut albo dłużej.
Sam pamiętam moje zdziwienie, gdy dałem LLM-owi zadanie, które dawaliśmy programistom podczas rekrutacji. Zrobił to w kilka sekund, razem z napisaniem kodu i wskazaniem ukrytych pułapek (gotchas)... (OK, sam, gdy dostałem to zadanie, rozwiązanie znałem po 1,5 sekundy, z czego całą sekundę spędziłem na szukaniu gotcha, ale faktem jest, że napisanie czystego kodu zajęło mi potem te 15-20 minut).
W tym miejscu nastąpił wysyp masy narzędzi, które działały... ale jednak nie do końca.
Pierwszym ruchem było dodawanie lepszych instrukcji i cały prompt engineering, który sprowadzał się do tego, by wyjaśnić LLM-owi, co dokładnie ma zrobić i jak ma weryfikować swoje działania. W końcu jeśli podamy modelowi precyzyjną instrukcję oraz kryteria sukcesu, to zazwyczaj dowiezie wynik.
Twórcy LLM-ów też to zauważyli. Dostrzegli, że często sam model potrafi rozbić problem na mniejsze części, co doprowadziło do rozwoju metod Chain of Thought. Dziś, w modelach z fazą „thinking”, AI samo wykonuje tę potężną pracę analityczną przed wypuszczeniem odpowiedzi.
Teraz zaś wchodzimy w moment, gdy dociera do nas, że LLM-y są świetne w generowaniu tekstu, ale musimy je kontrolować i zakładać im wspomnianą „uprząż”. To może być coś tak prostego jak regex czy inne deterministyczne metody walidacji, a mogą to być osobne prompty i modele obserwujące odpowiedź i reagujące na nią.
No bo jak na przykład testować coś, co pod spodem używa LLM-a?
Jedną z metod jest karmienie go znanymi przypadkami testowymi, gdzie z góry znamy oczekiwany rezultat – i nagle mamy klasyczny test regresyjny dla sztucznej inteligencji. To zadanie jest znacznie prostsze, gdy LLM wyrzuca ustrukturyzowane dane (np. JSON) albo gdy generuje zapytania do bazy danych, bo wtedy możemy po prostu zweryfikować końcowy wynik operacji na bazie.
Innym podejściem jest instruowanie modelu, by najpierw napisał testy, a później... kategoryczne zabronienie mu ich modyfikowania. To kluczowe, bo LLM-y są sprytne i domyślnie wybierają ścieżkę najmniejszego oporu. Jeśli kod nie przechodzi testu, model potrafi wpaść na pomysł, że najprościej będzie po prostu zmienić treść testu.
To znaczy... my, programiści, też tak czasem robimy. Różnica polega na tym, że człowiek z czasem uczy się, że test wolno zmienić tylko wtedy, gdy jego wywrotka jest faktycznie oczekiwanym rezultatem wprowadzonej zmiany w logice biznesowej. LLM tej etyki zawodowej jeszcze nie ma.
W ten sam trend wpisuje się podejście agentskie. Agent dostaje do dyspozycji konkretne narzędzia, a te narzędzia mają już twarde, kodowe ograniczenia. Jeśli na przykład funkcja do pobierania zawartości sieci dostanie zamiast poprawnego adresu URL bezpośredni link do lokalnego pliku, system od razu zgłosi błąd. Narzędzia są deterministyczne i ich użycie zmusza LLM do poruszania się w ściśle ograniczonej przestrzeni.
Co będzie dalej? Może – a w zasadzie to już się dzieje, bo sam łapię się na tym, że próbuję tak naprowadzać sztuczną inteligencję – kolejnym krokiem będzie okresowe odpytywanie LLM-a przez system nadzorujący: „Co Ty właściwie próbujesz w tym momencie zrobić i dlaczego?”. Odpowiedź, wraz z pełnym zapisem historii tej „rozmowy”, będzie następnie przekazywana do analizy innemu, niezależnemu modelowi pełniącemu funkcję sędziego.
Tu pojawia się pytanie, na które nie znamy jeszcze odpowiedzi, ale możemy się domyślać ;-)
No bo czy to możliwe, że LLM-y wciąż mają ogromną przestrzeń do autonomicznego wzrostu? Może w samym tym strukturalnym semi-zrozumieniu języka tkwi jeszcze więcej surowej mocy? Może same modele da się wytrenować tak, by realizowały część tych zadań kontrolnych i pilnowały same siebie?
A może, jeśli dotarliśmy już blisko fizycznych granic architektury transformerów, ta kontrola będzie zadaniem dla nas, programistów? Nasza rola ewoluje: to już nie tylko pisanie kodu, ale budowanie zamkniętych „tras”, po których bezpiecznie mogą poruszać się LLM-y i agenty.
Część mnie uważa, że przyszłością jest właśnie ta druga opcja.
Obecny wyścig gigantów GenAI wygląda już jak wojna na wyniszczenie. Nawet jeśli któryś z nich dotrze w końcu do mitycznego Graala, czyli prawdziwego AGI – systemu zdolnego rozwiązać dowolny problem i realnie „myślącego” w naszym ludzkim rozumieniu – to konkurencja zreplikuje ten sukces zaledwie 3 do 6 miesięcy później. Pierwszy gracz na miejscu po prostu nie zdąży wykopać fosy biznesowej. Cała idea zmonopolizowania rynku przez jedną „Superinteligencję” rozbija się o realia rynkowe.
Nawet jeśli takie AGI zaprojektuje w ułamku sekundy lepsze procesory i wydajniejsze źródła energii, to fizyczny czas oczekiwania na wolne linie produkcyjne w fabrykach sprawi, że rywale szybko dogonią lidera. A niewykluczone, że będą mieli po drodze większe zasoby finansowe.
Stąd wydaje mi się, że czytelny sygnał, jaki płynie z rynku – gdzie wszyscy masowo podnoszą ceny za tokeny – jest prosty: branża już zrozumiała, że rewolucyjne AGI nie czai się tuż za rogiem. Albo alternatywnie: mają już AGI, które jako pierwsze racjonalnie wytłumaczyło im, że pora zacząć w końcu zarabiać prawdziwe pieniądze.
Podobne postybeta
wait() i notify()/notifyAll() - najbardziej nierozumiane metody klasy Object ;-)
Miałem farta...
Nie, Scrum nas nie "uratował" od Waterfalla... za to powoli sam się nim staje ;-)
Chciałem popsuć G1 i mi się na razie nie udało ;-)
Agent by Agent ;-) czyli o tworzeniu agenta AI agentem AI ;-)
