Gemini 4 Argon: milion tokenów, ucieczka do Rusta i pułapka pozornej logiki
Google zaprezentowało swój najnowszy model graniczny – Gemini 4 Argon. W cieniu głośnych deklaracji o rewolucji w programowaniu kryją się jednak dwie znacznie ciekawsze historie.
Lektura oficjalnego wpisu Google dała mi dwie myśli. Pierwsza: mamy do czynienia z bezprecedensową próba masowego przepisania jądra systemu operacyjnego na Rusta oraz druga: niebezpieczne złudzenie, że bezpieczeństwo pamięci jest tożsame z poprawnością logiczną kodu.
Większość branżowych doniesień sprowadziła premierę Gemini 4 Argon do standardowego odhaczenia tabelek wydajnościowych. Koray Kavukcuoglu, szef architektów AI w Google, położył jednak nacisk na zupełnie inny aspekt: przejście od prostego asystowania programistom do autonomicznych, długoterminowych procesów inżynieryjnych. Chodzi o inżynierię oprogramowania oczywiście.
Fakty: potężne okno wyjściowe i operacja na żywym organizmie
Z oficjalnego komunikatu Google wynika kilka kluczowych danych technicznych oraz operacyjnych:
- 1 milion tokenów na wyjściu: dotychczasowy limit wyjściowy (64 tysiące tokenów) został podniesiony do pełnego miliona. Pozwala to modelowi generować całe systemy i rozległe moduły w jednym nieprzerwanym procesie.
- Cena: usługa startuje z pułapem 2 dolarów za milion tokenów wejściowych i 10 dolarów za milion tokenów wyjściowych (z 95-procentowym rabatem dla zbuforowanego kontekstu wejściowego).
- Migracja na Rusta: agenci napędzani Argonem zostali zaprzęgnięci do przepisania krytycznych baz kodu wewnątrz Google. Prace obejmują biblioteki systemowe (m.in. re2, libgav1), a przede wszystkim ponad 800 tysięcy linii kodu C i C++ jądra Zircon, stanowiącego fundament eksperymentalnego systemu Fuchsia OS (ciekawe czy ktoś go pamięta, dla przypomnienia, poniżej tekst Pawła, sprzed… dekady).
Tutaj mała dygresja, bo dla części Czytelników pojęcie Rust może wydać się niezrozumiałe. Rust to język programowania zaprojektowany z myślą o bezpieczeństwie pamięci – jego kompilator potrafi wykrywać dużą część błędów, które w C i C++ mogą prowadzić do podatności, takich jak przepełnienia bufora czy nieprawidłowe użycie pamięci.
- Optymalizacja libgav1: w dekoderze wideo agenci zastąpili 32 tysiące linii niskopoziomowego asemblera SIMD kodem w języku Rust, uzyskując 2,7-krotne przyspieszenie względem wcześniejszego, ludzkiego portu (także zaprogramowanego w języku Rust).
- Cyberbezpieczeństwo bez filtrów: w ramach programu Fairwind (o którym pisałem w moim felietonie na łamach najnowszego wydania iMagazine) wybrani zaufani partnerzy, w tym firma Wiz, otrzymują dostęp do modelu całkowicie pozbawionego barier ochronnych (without cyber guardrails), by autonomicznie wyszukiwać i łatać luki w infrastrukturze krytycznej.
- Procedury kontrolne: Google wprost zastrzega, że wygenerowany kod jądra przechodzi rygorystyczne audyty automatyczne, manualne oraz testy emulacyjne przed trafieniem na produkcję. To nie jest puszczenie modelu z milionem tokenów wyjścia samopas. Dlaczego? Częściowej odpowiedzi udzielam w ostatniej części niniejszego tekstu.
Moja opinia: koniec ery chatbotów i technologiczny spychacz
Moim zdaniem podniesienie limitu wyjściowego do miliona tokenów definitywnie zamyka epokę traktowania modeli językowych jako interaktywnych okienek do pogawędek (nawet jeżeli ich celem jest stworzenie, bądź optymalizacja kodu). AI staje się maszynowym wykonawcą żmudnych zadań inżynieryjnych.
Przez ostatnie trzydzieści lat branża IT powtarzała mantrę: języki C i C++ odpowiadają za około 70 procent krytycznych luk w oprogramowaniu (błędy zarządzania pamięcią), ale koszt ich ręcznego przepisania na bezpieczniejsze alternatywy jest zaporowy. To, co Google demonstruje na przykładzie Zircona, jest próbą wykorzystania sztucznej inteligencji jako spychacza do likwidacji wieloletniego długu technologicznego.
Kompilator pilnuje pamięci, ale kto pilnuje logiki?
Wokół tej premiery rośnie jednak groźne uproszczenie, które bezkrytycznie stawia znak równości między „bezpieczeństwem pamięci” a „bezpieczeństwem programu”.
Rust rozwiązuje problem przepełnień bufora czy wycieków dzięki rygorystycznemu mechanizmowi kontroli (borrow checker). Należy jednak pamiętać o zasadniczej różnicy w przypadku, gdy do tworzenia kodu w Rust zatrudnimy wyłącznie AI.
Model AI (jakikolwiek) nie posiada wewnętrznego aparatu dedukcyjnego ani nie rozumie intencji biznesowej pisanego systemu. Działa w oparciu o probabilistykę – dobiera najbardziej prawdopodobne ciągi składniowe, które zaspokoją reguły kompilatora oraz zadane testy jednostkowe.
Kompilator Rusta bez najmniejszego błędu przepuści kod, który idealnie zarządza pamięcią, ale zawiera fundamentalny błąd logiczny – na przykład przyznaje uprawnienia administratora każdemu pakietowi w nietypowym scenariuszu brzegowym. W oprogramowaniu na poziomie jądra systemu operacyjnego (jak Zircon) bezpośrednia interakcja ze sprzętem wymusza stosowanie w kodzie tzw. bloków unsafe (to specjalne bloki, które wprost mówią kompilatorowi coś w stylu „nie sprawdzaj tu odwołań do pamięci, ja wiem lepiej co robię”; to tak w olbrzymim uproszczeniu). Innymi słowy oznacza to, że w tych fragmentach programista bierze na siebie odpowiedzialność za zachowanie bezpieczeństwa pamięci, którego kompilator nie jest już w stanie zweryfikować.
Nie trzeba być genialnym programistą, by dostrzec to strukturalne ryzyko. To związane z wpuszczeniem agentów AI do kodu systemowego nie polega na tym, że wygenerują oni kod wadliwy składniowo. Prawdziwym zagrożeniem jest kod syntaktycznie nieskazitelny, zoptymalizowany pod kompilator, lecz skrywający w setkach tysięcy wyplutych linii ciche, trudne do wychwycenia anomalie logiczne. Właśnie dlatego asekuracyjna wzmianka Google o konieczności wieloetapowego, ludzkiego audytu przed wdrożeniem do produkcji powinna być traktowana jako najważniejsze zdanie całego komunikatu. Na koniec warto zapamiętać dwie rzeczy: tak, Gemini 4 Argon zapowiada się rewelacyjnie jako wsparcie dla żmudnych długich, inżynieryjnych zadań. Dwa: absolutnie nie można zezwolić na kodowanie AI samopas. AI nie rozumie logiki.
