Recenzja książki
LLMs w akcji. Od modeli językowych do dochodowych produktów
- Praktyka 6/10 ile da się wdrożyć
- Głębia 5/10 siła argumentu
- Aktualność 6/10 czy nie zestarzała się
To nie jest książka o giełdzie i wcale nie udaje, że jest. To książka o przepaści między działającym pokazem a działającym produktem, czyli o tym, co autorzy nazywają LLMOps, operacjami na dużych modelach językowych. Trzymamy ją w bibliotece z jednego warunkowego powodu. Dziś nie budujemy niczego na modelach językowych. Ale jeśli kiedyś dołożymy do systemu warstwę, która czyta newsy, raporty i nastroje rynku jako tekst, chcemy ją złożyć jak produkt, który działa za każdym razem, a nie jak demo, które zadziała raz na konferencji. Cała ta książka jest o tej jednej różnicy.
Demo działa raz, produkt za każdym razem
Tezę tej książki da się streścić jednym zdaniem, a autorzy sami je piszą:
Okazuje się, że zbudowanie prototypu pod kątem problemów związanych z językiem jest łatwe; zbudowanie działającego produktu jest natomiast bardzo, bardzo trudne.
Christopher Brousseau, Matt Sharp, Rozdział 1
To jest cały podtytuł „od modeli językowych do dochodowych produktów” rozpisany na dwanaście rozdziałów. Każdy, kto wkleił klucz API do OpenAI i w pół godziny zbudował chatbota, zna pierwszą połowę tego zdania. Druga połowa to reszta życia projektu: koszty, opóźnienia, awarie, halucynacje, wersje bibliotek, GPU, których nie ma. Autorzy pokazują tę asymetrię na własnym przykładzie, tłumacząc nawet, czemu akurat ChatGPT zrobił furorę, choć nie był wcale lepszym modelem niż GPT-3 sprzed lat. Ich odpowiedź nie dotyczy modelu, tylko inżynierii wokół niego.
Demonstracja musi zadziałać tylko raz, ale produkt musi działać za każdym razem, nawet gdy miliony użytkowników pokazują go swoim znajomym, mówiąc: „Zobacz to!”.
Christopher Brousseau, Matt Sharp, Rozdział 1
Dla nas to brzmi znajomo, bo to ta sama różnica, którą w warsztacie nazywamy przepaścią między backtestem a rachunkiem. Ładny wykres równości kapitału powstaje raz, na danych historycznych. Strategia musi przeżyć każdą kolejną sesję, na żywo, po kosztach. Książka opowiada tę samą prawdę w innym języku, dla innej technologii, i to jest pierwszy sygnał, że trafiła na właściwą półkę.
Podręcznik LLMOps, nie finansów
Powiem wprost, co się tu kupuje. To jest podręcznik inżynierii produkcyjnej, a nie finansów ani analizy rynku. Autorzy prowadzą czytelnika przez cały łańcuch budowy produktu opartego na modelu językowym: od podstaw modelowania języka i inżynierii danych, przez trenowanie i dostrajanie modelu, wystawianie go jako API, inżynierię promptów, aż po trzy duże projekty na końcu, łącznie z reimplementacją Llamy 3 i uruchomieniem modelu na Raspberry Pi. Sami opisują to jako podręcznik LLMOps, czyli operacji uczenia maszynowego przeskalowanych do rozmiaru dużych modeli językowych. I od razu studzą zapał, pisząc, że skalowanie to jedno z najtrudniejszych zadań w całej inżynierii oprogramowania.
Najwięcej miejsca dostaje pytanie, które większość kursów „AI w pięć minut” pomija: budować samemu czy kupić gotowe API. Książka jest po stronie budowania, bo tego uczy, ale uczciwie wykłada powody, dla których własny model ma sens tylko czasem: kontrola nad danymi, tajemnica handlowa, praca offline, koszty przy dużej skali. Dla zdecydowanej większości czytelników, nas także, rozsądną odpowiedzią pozostaje API. I to jest zdrowe, że autorzy mówią to wprost, zamiast sprzedawać marzenie o własnym GPT w garażu.
Jedno zdanie o inwestowaniu
Będę uczciwy. W kilkuset stronach o budowaniu produktów z modelami językowymi znajdziesz dokładnie jedno zdanie wprost o inwestowaniu. Ale jest to właściwe zdanie:
Na przykład możesz zdecydować się na użycie modelu do kategoryzowania opcji inwestycyjnych jako dobre lub złe, ale czy naprawdę będziesz chciał, aby na podstawie uzyskanych wyników model podejmował rzeczywiste decyzje inwestycyjne? Nie bez nadzoru, chyba że chcesz stać się bohaterem wiralowego wideo.
Christopher Brousseau, Matt Sharp, Rozdział 1
Pada ono w kontekście projektów wysokiego ryzyka, gdzie autorzy ostrzegają przed losowością modeli: na to samo pytanie potrafią dać różne odpowiedzi, bo odrobinę przypadkowości wpuszczamy świadomie, żeby były kreatywne. Można tę losowość wytłumić, ale wtedy model często staje się bezużyteczny. Dla kogoś, kto myśli o LLM-ie przy pieniądzach, to nie jest ciekawostka, tylko granica. Model językowy może streścić raport, wychwycić ton komunikatu banku centralnego, zgrupować newsy. Nie powinien naciskać przycisku. W momencie, w którym jego wynik staje się celem decyzji, przestaje być dobrym pomiarem, dokładnie jak w prawie Goodharta. To jedno zdanie warte jest u nas więcej niż cały rozdział, bo wyznacza miejsce LLM-a w systemie: pomocnik researchu, nigdy autonomiczny trader.
Rachunek przychodzi w GPU
Drugi wątek, który przenosi się do nas bez tłumaczenia, to pieniądze. Rozdział o operacjach jest w dużej części opowieścią o tym, że duże modele są drogie w samym utrzymaniu, zanim jeszcze zarobią pierwszą złotówkę. Procesorów graficznych brakuje, więc są kosztowne; ładowanie wielkiego modelu do pamięci potrafi trwać kwadranse; usługę często trzeba trzymać włączoną nawet przy zerowym ruchu, żeby była gotowa na skok obciążenia.
Błędy, takie jak pozostawienie włączonej usługi, zawsze mogły generować wysokie rachunki, ale przy wykorzystaniu GPU tego typu pomyłki są jeszcze bardziej kosztowne.
Christopher Brousseau, Matt Sharp, Rozdział 3
Zostawiony przez weekend serwer z GPU to nasz odpowiednik prowizji i poślizgu: cichy koszt, który nie pojawia się w demie, a decyduje o tym, czy całość ma sens. My liczymy każdą transakcję po kosztach w jednostkach R, bo koszt działa asymetrycznie i potrafi zjeść przewagę, której na wykresie nie widać. Książka uczy tej samej pokory wobec rachunku, tylko po stronie infrastruktury. Kto raz dostał fakturę za chmurę, której nie wyłączył, czyta ten fragment ze współczuciem.
Jak tego używamy
Po co praktyk od jednego kontraktu futures miałby trzymać podręcznik o budowaniu produktów z LLM-ami? Nie jako instrukcję na dziś. Rdzeń naszego systemu R&D na MES (kontrakt Micro E-mini S&P 500) to pomiary, koszty i logika setupów, i nie ma w nim ani jednego modelu językowego. Ta książka czeka na konkretny, opcjonalny etap: moment, w którym dołożymy warstwę czytającą tekst, czyli newsy, raporty, transkrypcje, nastroje, żeby dostarczała kontekst, a nie sygnał wejścia.
Trzy rzeczy bierzemy stąd już teraz, zanim cokolwiek zbudujemy. Pierwsza to twarda granica roli: model językowy może opisywać i porządkować, ale decyzję o pozycji podejmuje system po naszych regułach i nasza ręka, nigdy nie sam LLM bez nadzoru. Druga to ekonomia: gdybyśmy taką warstwę uruchomili, jej koszt musi być policzony tak samo bezlitośnie jak prowizja, w jednostkach R, bo inaczej zoptymalizujemy coś, czego na rachunku nie zobaczymy. Trzecia to wybór ścieżki: dla naszej skali to API, nie własny model trenowany od zera, i dobrze, że autorzy sami wskazują, kiedy budowanie nie ma sensu.
Czego książka za nas nie zrobi, to powie nam, jak odróżnić prawdziwy sygnał w tekście od fałszywego odkrycia. LLM równie gładko streści realną zmianę w fundamentach spółki, jak i wymyśli ją z niczego. Walidacja, czy warstwa tekstowa cokolwiek wnosi do wyniku po kosztach, zostaje po naszej stronie i jest dokładnie tak nudna oraz niewdzięczna jak reszta uczciwej roboty.
Gdzie książka pęka
Najuczciwiej o książce mówi się, wskazując, gdzie się łamie, a tu pęknięć dla naszego czytelnika jest kilka. Pierwsze jest wpisane w tytuł recenzji: ta książka nie mówi o rynkach. Finanse pojawiają się w jednym ostrzegawczym zdaniu, a reszta to ogólna inżynieria produktu. Kto liczy na pomysł na strategię albo na warstwę alfa z newsów, odłoży książkę z niczym. Wartość jest realna, ale leży piętro niżej, w infrastrukturze, nie w decyzji handlowej.
Drugie pęknięcie to szerokość kupiona kosztem głębi. Dwanaście rozdziałów od worka słów po Raspberry Pi znaczy, że każdy temat dostaje tyle miejsca, by zadziałał w przykładzie, rzadko tyle, by go zrozumieć do dna. Autorzy sami to deklarują, pisząc, że wolą praktykę od wymyślnych definicji. To świadomy wybór i czyni książkę przystępną, ale po teorię, na przykład po matematykę mechanizmu uwagi czy kwantyzacji, trzeba sięgnąć gdzie indziej.
Trzecie pęknięcie jest najgroźniejsze i sami autorzy nie próbują go ukryć. To jest najszybciej starzejąca się książka w naszej bibliotece. Pole zmienia się z miesiąca na miesiąc, a oni pisali ją, własnymi słowami, jak dom na ruchomych piaskach.
Wiemy, że niektóre fragmenty tej książki nieuchronnie się zdezaktualizują, dlatego staraliśmy się koncentrować na podstawowych koncepcjach — solidnych skałach w morzach piasku — które nigdy się nie zmienią.
Christopher Brousseau, Matt Sharp, Rozdział 12
Ta deklaracja to zarazem największa zaleta i największe ryzyko. Zasady przetrwają, bo różnica między demem a produktem jest wieczna. Konkrety, czyli wersje bibliotek, ceny GPU, modne frameworki, mają datę przydatności krótszą niż większość książek, które trzymamy obok. Czwarte, na koniec, to wysoki próg wejścia, którego autorzy nie ukrywają: zakładają Pythona, PyTorcha i podstawy głębokiego uczenia. Kto tego nie ma, utonie przed pierwszym projektem.
Werdykt
Praktyczność 6, głębia 5, aktualność 6.
Praktyczność pośrodku, i to świadomie. Książka jest gęsta od konkretu, kodu i decyzji architektonicznych, ale spora część tego konkretu, czyli trenowanie modelu od zera czy wdrożenie na Raspberry Pi, jest dla naszego zastosowania nadmiarowa. Gdybyśmy dokładali warstwę tekstową, poszlibyśmy ścieżką API, którą autorzy opisują uczciwie, lecz krócej. Stąd szóstka, niżej niż u McKinneya czy Jansena, których kod pracuje wprost na tym, co budujemy.
Głębię stawiam najniżej spośród naszych książek technicznych, bo to roadmapa, nie wykład. Autorzy świadomie wybierają zasięg zamiast dna i sami uprzedzają, że nie znajdziesz tu wymyślnych definicji. Robią to dobrze, książka jest przez to czytelna i kompletna jako mapa, ale do teorii trzeba sięgnąć gdzie indziej, więc piątka, nie wyżej.
Aktualność też pośrodku, mimo że temat jest najgorętszy w całej bibliotece. To nie sprzeczność. Sam przedmiot, modele językowe w produkcji, jest dziś maksymalnie na czasie, lecz dla naszego systemu pozostaje warstwą peryferyjną i opcjonalną, a treść starzeje się szybciej niż jakakolwiek inna u nas, co autorzy wpisali w ostatni rozdział. Te dwie siły się znoszą i lądują na szóstce, na równi z książką o uczeniu ze wzmocnieniem, która też czeka u nas na swój moment.
Komu polecić? Inżynierowi, który zna Pythona i chce zobaczyć cały łańcuch budowy produktu z modelem językowym w jednym miejscu, z uczciwym spisem miejsc, gdzie demo różni się od produktu. Kto szuka pomysłu na handel albo na alfa z newsów, niech nie zaczyna tutaj, bo tego tu nie ma. U nas ta pozycja ma rolę odłożoną na półkę z napisem „później”: nie na dziś, kiedy mierzymy koszty i setupy, lecz na etap, w którym tekst wejdzie do systemu jako kontekst. Wtedy przypomni jedną rzecz, którą warto wiedzieć wcześniej niż za późno: model językowy ma czytać, nie handlować.