Autonomiczny benchmark bokserski stawia opóźnienia AI na ringu

Google znalazło się w tym tygodniu w nietypowym benchmarku — przynajmniej według jednego dewelopera testującego Gemini Flash Live w autonomicznej symulacji bokserskiej. Projekt zastępuje statyczne pytania zawodnikami, którzy muszą dostrzegać ataki, wybierać reakcje i działać, zanim symulowany cios dosięgnie celu.

To założenie czyni eksperyment ciekawszym, niż sugeruje jego brutalna tematyka. Proponowany horyzont Google jest mierzony ułamkami sekundy, a nie godzinami programowania ani tysiącami pytań akademickich. Model, który dobrze rozumuje, ale odpowiada zbyt późno, i tak zostaje trafiony.

Deweloper twierdzi, że Gemini Flash Live potrafi wykorzystywać informacje wizualne do uników i kontrataków. Lokalne modele uruchamiane na Nvidia GeForce RTX 5060 Ti z 8 GB pamięci mają podobno potrzebować więcej czasu na podjęcie decyzji. Początkowemu opisowi na Reddicie nie towarzyszyły jednak publiczna tabela wyników, odtwarzalny kod, pełne rezultaty ani niezależna walidacja.

To pozostawia projekt gdzieś między kreatywną demonstracją a obronionym benchmarkiem. Jego główne pytanie pozostaje wartościowe: gdy agent AI działa w zmiennym środowisku, czy czas reakcji powinien być uznawany za część inteligencji?

Symulacja bokserska zamienia opóźnienie w obrażenia

Eksperyment uwidacznia opóźnienia, przekładając powolną odpowiedź modelu na natychmiastową stratę w rywalizacji.

Twórca opisał sterowaną przez AI walkę bokserską, której celem jest testowanie szybkości podejmowania decyzji, adaptacyjności i strategii. Każdy model otrzymuje informacje o aktualnym stanie walki. Modele obsługujące obraz mogą otrzymywać dodatkowe dane wizualne, choć nie ujawniono dokładnego formatu ani częstotliwości próbkowania.

Symulacja korzysta z celowo luźnych „zasad ulicznych”. Wszystko jest dozwolone, a zawodnik nie przegrywa wyłącznie dlatego, że został powalony. Sędzia musi doliczyć do 10 albo przeciwnik musi zadać obrażenia równe 50 procentom zdrowia zawodnika po nokaucie.

Te zasady tworzą stałą presję. Model nie może traktować każdej wymiany jako odizolowanego promptu, ponieważ jego stan, pozycja, przeciwnik i dostępny czas nieustannie się zmieniają. Musi wybrać działanie, podczas gdy środowisko nadal się porusza.

Deweloper twierdzi, że celem było stworzenie bardziej rozrywkowego testu niż kolejnej kolekcji problemów o ustalonych odpowiedziach. Bokserska forma zapewnia też intuicyjne wyjaśnienie porażki. Opóźniona odpowiedź nie pojawia się jako abstrakcyjna liczba określająca opóźnienie; objawia się jako spóźniony blok lub niewybroniona kombinacja.

Ta przejrzystość jest użyteczna, lecz może również wprowadzać w błąd. Animowany zawodnik sprawia wrażenie, że model stale widzi, rozumie i kontroluje całą scenę. System bazowy może natomiast przekształcać stan gry w tekst, okresowo wysyłać obrazy albo ograniczać model do niewielkiego menu działań.

Te wybory implementacyjne określają, co system faktycznie mierzy. Model wybierający między „unik”, „blok” i „kontratak” staje przed innym problemem niż agent samodzielnie kontrolujący ruch, czas, kierunek i wybór ataku.

Post źródłowy nie ujawnia przestrzeni działań, formatu promptu, interwału aktualizacji, warunków sieciowych, ziarna losowego ani liczby walk. Nie zawiera też pełnego rozkładu wyników. Twierdzenia, że Gemini potrafi unikać i kontratakować, należy więc traktować jako obserwację twórcy, a nie ustalony ranking modeli.

Mimo to koncepcja ujawnia problem, który statyczne oceny często ukrywają. Wiele pytań benchmarkowych w praktyce zatrzymuje świat, gdy model myśli. Prawdziwe interfejsy, roboty, gry i asystenci działający na żywo nie oferują takiego przywileju.

Live API Google zostało zaprojektowane z myślą o interakcjach o niskim opóźnieniu z wykorzystaniem ciągłych strumieni audio, obrazu i tekstu. Środowisko bokserskie przekłada ten projekt na mierzalną konsekwencję: odpowiedz zbyt późno, a kolejny stan nadejdzie, zanim poprzednia decyzja przestanie mieć znaczenie.

Dlaczego horyzont Google mierzy się w milisekundach

Istotny horyzont Google nie dotyczy tego, jak długo Gemini może realizować zadanie, lecz tego, jak długo jego pętla percepcji i działania pozostaje użyteczna.

Badacze AI już używają pojęcia „horyzontu czasowego”, by omawiać możliwości agentów. METR definiuje horyzont czasowy ukończenia zadania jako czas trwania pracy wykonywanej przez człowieka, przy którym agent osiąga określone prawdopodobieństwo sukcesu. Jego obecne pomiary skupiają się głównie na inżynierii oprogramowania, uczeniu maszynowym i pracy z zakresu cyberbezpieczeństwa.

Ten schemat pyta, czy agent potrafi niezawodnie wykonywać zadania wymagające dłuższych okresów ludzkiej pracy. Projekt bokserski pyta o coś innego. Testuje, czy decyzja dociera w kurczącym się oknie czasowym, w którym nadal może wpłynąć na wynik.

Obie idee są ważne, ale nie powinny dzielić jednego wyniku bez wyjaśnienia. Agent programistyczny może poświęcić minuty na rewizję planu, ponieważ repozytorium zazwyczaj czeka. Zawodnik mierzący się z nadlatującym ciosem może mieć tylko jeden użyteczny moment na reakcję.

Powstają w ten sposób co najmniej cztery rodzaje opóźnień.

Po pierwsze, symulacja musi zebrać aktualny stan. Jeśli wykorzystywany jest obraz, musi przechwycić i zakodować obraz lub klatkę wideo. Nieaktualna klatka może podważyć dobrą decyzję, zanim rozpocznie się wnioskowanie.

Po drugie, aplikacja musi przesłać dane wejściowe. Wdrożenie lokalne eliminuje transmisję internetową, ale nadal ponosi koszty serializacji, harmonogramowania i pamięci. System hostowany dodaje zmienność sieciową.

Po trzecie, model musi wywnioskować działanie. Większe budżety rozumowania mogą poprawić planowanie, ale zużywają również czas. W środowisku działającym na żywo dodatkowy namysł może obniżyć praktyczną wydajność.

Po czwarte, aplikacja musi przetworzyć i wykonać odpowiedź. Rozbudowane wyjaśnienie jest bezużyteczne, jeśli gra potrzebuje zwięzłej komendy. Ograniczenia wyjścia, wywołania narzędzi i nieprawidłowo sformułowane odpowiedzi wpływają na końcowy czas działania.

Google opisywało wcześniej swoje Multimodal Live API jako stanową usługę WebSocket obsługującą dwukierunkowe strumienie. W poście dla deweloperów z 2024 roku firma podała czas do pierwszego tokena wynoszący 600 milisekund dla ówczesnej generacji tej usługi. Ta wartość opisuje deklarację platformy w nieokreślonych warunkach, a nie zmierzony czas reakcji całego systemu bokserskiego od początku do końca.

To rozróżnienie ma kluczowe znaczenie. Opóźnienie do pierwszego tokena nie jest równe opóźnieniu do ukończonego działania. Użyteczna ocena mierzyłaby czas od chwili, w której zagrożenie staje się widoczne, do momentu, gdy symulator zaakceptuje prawidłowe działanie obronne.

Powinna też raportować rozkład, a nie tylko średnią. Zawodnik, który reaguje szybko w dziewięciu wymianach, a w dziesiątej zastyga, może przegrać walkę. Opóźnienie ogonowe, takie jak najwolniejsze pięć procent odpowiedzi, może lepiej przewidywać przetrwanie niż średnia.

Porównanie lokalne twórcy konkretyzuje ten problem. Post stwierdza, że modele uruchamiane na RTX 5060 Ti z 8 GB pamięci potrzebują czasu na wnioskowanie, co rodzi możliwość skalowania czasu. Spowolnienie symulacji pozwoliłoby tym modelom uczestniczyć, ale zmieniłoby charakter rywalizacji.

Skalowanie czasu może odpowiedzieć, czy lokalny model wybiera dobre działania, gdy otrzymuje równe możliwości namysłu. Gra w czasie rzeczywistym może odpowiedzieć, czy całe wdrożenie generuje użyteczne działania pod równą presją środowiska. To odrębne testy i powinny prowadzić do odrębnych rankingów.

Szybkie modele multimodalne wywierają presję na wolniejszych modeli rozumujących

Główna rywalizacja to szybkie systemy percepcji i działania kontra wolniejsze modele deliberatywne, a nie Google kontra jeden wskazany rywal.

Gemini Flash Live wydaje się dobrze dopasowane do eksperymentu, ponieważ Google stworzyło Live API do interakcji strumieniowych. Dokumentacja usługi wskazuje, że przetwarza ona ciągły dźwięk, obrazy i tekst, aby zapewniać natychmiastowe odpowiedzi. Połączenia klient-serwer mogą również ograniczać dodatkowy etap przejścia przez backend aplikacji.

Taka architektura daje Gemini istotną przewagę systemową. Nie dowodzi jednak lepszej strategii bokserskiej, ogólnego rozumowania ani adaptacyjności. Oznacza, że model i warstwa dostarczania zostały zaprojektowane dla obciążeń, w których napływające media nie czekają na ukończony cykl promptu i odpowiedzi.

Lokalne modele twórcy znajdują się po drugiej stronie porównania. Uruchamianie modelu na sprzęcie konsumenckim oferuje prywatność, kontrolę, powtarzalność i niezależność od dostępności zdalnej usługi. Ograniczenia pamięci mogą jednak ograniczać rozmiar modelu, kontekst, przetwarzanie obrazu lub wybór kwantyzacji.

Uczciwe porównanie musi wskazać, które ograniczenie ma znaczenie. Jeśli lokalny model otrzymuje tekst, a Gemini obrazy, benchmark miesza modalność ze sposobem wdrożenia. Jeśli oba widzą identyczne klatki, ale jeden działa przez zdalne strumieniowe API, wynik miesza możliwości modelu z infrastrukturą.

Żadne z tych porównań nie jest bezużyteczne. Odpowiadają po prostu na różne pytania.

Deweloper produktu wybierający technologię dla trenera działającego na żywo lub interaktywnej postaci interesuje się zintegrowanym rezultatem. Architektura modelu, sieć, sprzęt do wnioskowania i projekt interfejsu wpływają na doświadczenie użytkownika. Badacz porównujący zdolność rozumowania potrzebuje silniejszych kontroli.

Model czasu rzeczywistego OpenAI realtime model przedstawia inną dostępną drogę. Jego dokumentacja wskazuje, że akceptuje dane tekstowe, dźwiękowe i obrazowe, choć nie wymienia wejścia wideo. Implementacja bokserska musiałaby więc zdecydować, jak często przesyłać obrazy i jak synchronizować je ze zdarzeniami w grze.

Badania Google DeepMind nad SIMA oferują bardziej bezpośredni historyczny punkt odniesienia. SIMA wykorzystuje obrazy ekranu i instrukcje w języku naturalnym, a następnie wykonuje działania za pomocą klawiatury i myszy w grach 3D. DeepMind podało wyniki ocen obejmujących 600 podstawowych umiejętności, przy czym początkowe zadania zaprojektowano tak, by zajmowały około 10 sekund.

Te badania SIMA pokazały również, dlaczego interaktywne środowiska przyciągają badaczy. Łączą percepcję, język, pamięć, działanie i konsekwencje w ramach kontrolowanego oprogramowania. Środowisko może rejestrować każdą obserwację i komendę.

Symulacja bokserska jeszcze bardziej kompresuje tę pętlę. Dziesięciosekundowe zadania nawigacyjne pozwalają odzyskać kontrolę po zawahaniu. Możliwość uniku może wygasnąć niemal natychmiast.

W tym miejscu wolniejsze modele rozumujące odczuwają presję. Benchmarki często nagradzają modele za przeznaczanie dodatkowych zasobów obliczeniowych na trudne pytania. Boks może karać to samo zachowanie, gdy marginalna poprawa pojawia się po zamknięciu okna działania.

Presja nie ogranicza się do dostawców modeli. Deweloperzy tworzący autonomiczne interfejsy muszą zdecydować, czy kierować każdy wybór przez duży model. Praktyczny system mógłby wykorzystywać szybki kontroler do natychmiastowej obrony, a następnie konsultować wolniejszy model w sprawie strategii między wymianami.

Taki hybrydowy system mógłby przewyższyć oba skrajne podejścia. Utrudniłby też przypisywanie wyników, ponieważ benchmark mierzyłby zaprojektowanego agenta, a nie pojedynczy model. To napięcie już istnieje w ocenach agentów, gdzie warstwa wspomagająca i projekt narzędzi silnie wpływają na wyniki.

Zabawna demonstracja nie jest jeszcze wiarygodnym benchmarkiem AI

Bez kontrolowanych danych wejściowych, powtarzanych prób i pełnych danych czasowych walka bokserska nie może oddzielić strategii od inżynierii systemowej.

Benchmark potrzebuje czegoś więcej niż środowiska i zwycięzcy. Potrzebuje zdefiniowanego konstruktu, czyli zdolności, którą wynik ma reprezentować. „Inteligencja bokserska” może odnosić się do szybkości reakcji, wyboru taktycznego, długoterminowej adaptacji, rozumienia obrazu lub ogólnego sukcesu w walce.

Te wyniki mogą być ze sobą sprzeczne. Model reaktywny może często unikać ciosów, ale nigdy nie tworzyć okazji do ataku. Model strategiczny może przyjąć ograniczone obrażenia, aby później wykorzystać wzorzec zachowania przeciwnika. Model wizyjny może sprawiać wrażenie adaptacyjnego, ponieważ otrzymuje bogatsze informacje niż uczestnik działający wyłącznie na tekście.

Reguły wprowadzają kolejny czynnik zakłócający. Zezwolenie na ataki po nokaucie i wymóg zadawania dodatkowych obrażeń tworzą nietypowe bodźce. Model wytrenowany na konwencjonalnej wiedzy bokserskiej może wybierać działania zgodne z zasadami sankcjonowanych pojedynków, lecz słabo radzić sobie w niestandardowych warunkach symulatora.

Nie unieważnia to tego środowiska. Nowe zasady mogą testować przestrzeganie instrukcji i zdolność adaptacji. Jednak prompt musi konsekwentnie określać te reguły, a ewaluatorzy muszą zweryfikować, czy model je zrozumiał.

Losowość stwarza kolejny problem. Gry walki często różnicują wykrywanie trafień, ruch, obrażenia i czas reakcji. O wyniku jednego pojedynku może zadecydować szczęśliwa sekwencja. Wiarygodne rankingi wymagają powtarzanych walk z odwróconymi pozycjami startowymi, kontrolowanymi ziarnami losowości i przedziałami ufności.

Tożsamość modelu również wymaga bardziej rygorystycznego podejścia. „Gemini Flash Live” opisuje rodzinę modeli i tryb dostarczania, a niekoniecznie stałą wersję. Usługi w wersji preview mogą się zmieniać. Odtwarzalny wynik powinien zawierać dokładny identyfikator modelu, wersję API, datę, region, prompt systemowy, ustawienia generowania i schemat narzędzi.

Porównania sprzętowe wymagają równie dużej staranności. „Lokalny model na RTX 5060 Ti” nie określa modelu, liczby parametrów, kwantyzacji, silnika inferencyjnego, długości kontekstu ani enkodera obrazu. Każdy z tych elementów może istotnie zmienić czas odpowiedzi.

Wiarygodna publikacja powinna przedstawiać co najmniej trzy grupy wyników.

Jakość decyzji

• Zadane i otrzymane obrażenia

• Udane bloki, uniki i kontry

• Nieprawidłowe lub strategicznie niespójne działania

• Wyniki przeciwko wielu stylom przeciwników

Wydajność czasowa

• Opóźnienie przechwytywania stanu

• Opóźnienie sieciowe i kolejkowania

• Czas do pierwszego użytecznego działania

• Mediana oraz skrajne opóźnienie end-to-end

Wydajność adaptacji

• Poprawa między rundami

• Reakcja na powtarzające się wzorce przeciwnika

• Powrót do skuteczności po tym, jak taktyka przestaje działać

• Uogólnianie na nieznane zasady lub zawodników

Ewaluacja powinna także obejmować proste wartości bazowe. Ręcznie zakodowana polityka reaktywna mogłaby wykonywać unik zawsze, gdy atak przekracza określony próg. Polityka losowa wyznaczałaby dolną granicę. Skryptowana polityka taktyczna mogłaby pokazać, czy model językowy wnosi wartość wykraczającą poza przewidywalne reguły.

Jeśli AI nie potrafi niezawodnie pokonać tych wartości bazowych, efektowne zachowanie nie powinno ratować tego twierdzenia. Z kolei pokonanie ich w nieznanych warunkach uczyniłoby projekt czymś więcej niż wizualnym demem.

Pomocne byłoby porównanie z ludźmi, ale wymaga ono przemyślanego projektu. Na wynik wpływałyby czas reakcji człowieka, znajomość interfejsu i wiedza o grze. Ludzie powinni otrzymywać te same obserwowalne informacje i podlegać takim samym ograniczeniom działań jak modele.

Niepewność twórcy dotycząca skalowania czasu jest zatem produktywna. Wskazuje najważniejszy nierozstrzygnięty wybór benchmarku. Równy czas zegarowy ocenia gotowość do wdrożenia pod względem responsywności, podczas gdy czas znormalizowany ocenia jakość decyzji przy dostosowanych zasobach obliczeniowych.

Najlepszym rozwiązaniem jest opublikowanie obu wyników. Jedna kategoria może utrzymywać stały zegar symulacji. Druga może wstrzymywać lub skalować zdarzenia, jednocześnie śledząc zasoby obliczeniowe przyznane każdemu agentowi. Czytelnicy mogliby wtedy odróżnić inteligentną, lecz powolną politykę od szybkiej, ale powierzchownej.

Metodologia horyzontu czasowego METR pokazuje wartość definiowania prawdopodobieństwa sukcesu względem jednoznacznej miary zadania. Jej zadania programistyczne są bardzo różne, ale podstawowa lekcja pozostaje przenośna: wynik musi dokładnie określać, co oznacza czas trwania i jak szacowana jest niezawodność.

Projekt bokserski obecnie nie ma tej warstwy metodologicznej. Dopóki się nie pojawi, sformułowania takie jak „Gemini potrafi unikać ciosów” opisują zaobserwowany przebieg. Nie ustanawiają porównawczej zdolności.

Interaktywne benchmarki ujawniają to, czego nie widać w statycznych wynikach

Kontrolowana arena bokserska może ujawnić nieaktualną percepcję, opóźnione działanie i słabe odzyskiwanie skuteczności, które znikają w jednorazowych zestawach pytań.

Tradycyjne benchmarki modeli językowych zwykle przedstawiają stałe dane wejściowe i czekają na odpowiedź. Taka konstrukcja sprzyja powtarzalności i niedrogiemu ocenianiu. Eliminuje też koszt wahania.

Środowiska interaktywne przywracają ten koszt. Kolejna obserwacja zależy od poprzedniego działania, podczas gdy przeciwnik lub świat nadal się zmienia. Błędy kumulują się, zamiast kończyć się na jednej nieprawidłowej odpowiedzi.

To sprawia, że boks jest wiarygodnym środowiskiem testowym dla zachowania agentów, nawet jeśli jego prezentacja jest zabawowa. Model musi utrzymywać stan, wybierać działania, obserwować konsekwencje i korygować swoje podejście. Są to istotne wymagania dla robotów, agentów sterujących ekranem, asystentów działających na żywo i autonomicznych postaci w grach.

Środowisko może również ujawniać porażki, które ukrywa końcowy wskaźnik sukcesu. Model może wydawać sprzeczne polecenia, ponieważ nie zintegrował najnowszej klatki. Może powtarzać nieskuteczną taktykę, ponieważ jego pamięć nie zawiera użytecznego podsumowania. Może planować poprawnie, ale przegapić każde okno wykonania.

Stos Google do pracy w czasie rzeczywistym jest szczególnie istotny, ponieważ obsługuje ciągłe wielomodalne dane wejściowe. Jednak dostęp do strumienia na żywo nie gwarantuje trafnego rozumowania czasowego. Model musi określić, co się zmieniło, odróżnić ruch od szumu i powiązać niedawne obserwacje z właściwym działaniem.

Liczba klatek na sekundę ma tutaj znaczenie. Wysyłanie większej liczby obrazów może poprawić pokrycie czasowe, jednocześnie zwiększając obciążenie przepustowości i przetwarzania. Wysyłanie mniejszej liczby może zmniejszyć opóźnienie, lecz ukryć początek ataku. Optymalna częstotliwość zależy zarówno od modelu, jak i środowiska.

Projektanci ewaluacji muszą więc traktować potok obserwacji jako część agenta. Raportowanie wyłącznie nazwy modelu pomija decyzje, które mogą przesądzić o zwycięzcy jeszcze przed rozpoczęciem inferencji.

Format bokserski może także wyraźniej testować adaptację niż statyczne zestawy. Ewaluator mógłby zaprogramować przeciwników o różnych stylach, w tym agresywną presję, defensywne kontrataki, powtarzalne kombinacje lub zwodniczy ruch. Modele mogłyby najpierw mierzyć się ze znanymi stylami, a następnie z nieznanymi mieszankami.

Autentyczny wynik adaptacji mierzyłby zmianę zachowania po zgromadzeniu dowodów. Nie powinien nagradzać modelu jedynie za losowy wybór różnych działań. Późniejsze decyzje modelu muszą wykorzystywać wzorce, które nie były dostępne na początku.

Taki projekt połączyłby ten projekt z szerszą historią gier jako laboratoriów AI. DeepMind zauważa, że gry oferują responsywne środowiska działające w czasie rzeczywistym i zmieniające się cele. Zapewniają także instrumentację, której często brakuje w eksperymentach fizycznych.

Benchmark bokserski powinien jednak opierać się pokusie stania się kolejnym zamkniętym spektaklem. Bez środowisk dostępnych do pobrania, stałych protokołów i logów możliwych do odczytu przez maszyny widzowie nie mogą sprawdzić, dlaczego zawodnik wygrał. Wartość rozrywkowa przyciąga uwagę, lecz przejrzystość tworzy wartość naukową.

Ta sama lekcja dotyczy testowania agentów korporacyjnych. Agent ekranowy, który ostatecznie kończy przepływ pracy, może nadal frustrować użytkowników, jeśli zatrzymuje się nieprzewidywalnie lub działa na podstawie nieaktualnych informacji. Zespoły potrzebują śladów pokazujących obserwacje, decyzje, czas działania i odzyskiwanie skuteczności.

Wizualna arena ułatwia zrozumienie takich śladów. Obserwowanie, jak agent nie blokuje ciosu, jest bardziej intuicyjne niż czytanie wykresu percentyli. Szansą jest zachowanie tej przystępności przy jednoczesnym dodaniu mechanizmów kontroli wymaganych do sensownego porównania.

Co sprawiłoby, że wynik byłby godny zaufania

Trzy sygnały zdecydują o tym, czy ten projekt stanie się użyteczną ewaluacją, czy pozostanie pomysłową demonstracją w mediach społecznościowych.

Pierwszym sygnałem jest odtwarzalna publikacja. Twórca powinien opublikować środowisko, reguły, prompty, schemat działań, logikę czasu i stałe konfiguracje modeli. Powtórki powinny obejmować obserwacje opatrzone znacznikami czasu oraz zaakceptowane działania.

Taka publikacja wzmocniłaby twierdzenie, gdyby niezależni użytkownicy odtworzyli podobne rankingi. Osłabiłaby je, gdyby niewielkie zmiany promptu lub sieci odwracały wyniki.

Drugim sygnałem jest tabela wyników z dwiema ścieżkami. Jedna ścieżka powinna wymuszać identyczne warunki czasu rzeczywistego. Druga powinna normalizować lub ujawniać zasoby obliczeniowe, aby ewaluatorzy mogli porównywać jakość działań niezależnie od szybkości.

Rozwiązałoby to kwestię skalowania czasu bez udawania, że istnieje tylko jedna definicja uczciwości. Stabilne rankingi w obu ścieżkach wspierałyby szerokie twierdzenie o zdolnościach. Rozbieżne rankingi pokazałyby, że opóźnienie i jakość rozumowania nadal są odrębnymi cechami.

Trzecim sygnałem jest szersze pokrycie modeli i wartości bazowych. Gemini Flash Live powinien zmierzyć się ze stałymi wersjami modeli od innych hostowanych dostawców, ujawnionymi modelami lokalnymi, ręcznie kodowanymi kontrolerami i politykami losowymi. Każdy system powinien otrzymywać porównywalne obserwacje, chyba że osobna kategoria wielomodalna zostanie wyraźnie oznaczona.

Jeśli Gemini pozostanie konkurencyjny przy powtarzanych ziarnach losowości, nieznanych przeciwnikach i przejrzystych pomiarach opóźnień, perspektywa Google stanie się znacząca. Jeśli wygrywa tylko dzięki bogatszej wizji lub korzystnemu czasowi, benchmark udokumentuje raczej przewagę integracyjną.

Żaden zweryfikowany wynik obecnie nie potwierdza żadnego z tych wniosków. Źródłem jest opis pracy w toku przedstawiony przez dewelopera, a kluczowe twierdzenia dotyczące wydajności nie zostały niezależnie sprawdzone. Ta niepewność powinna zachęcać do lepszych pomiarów, a nie do lekceważenia projektu.

Kolejny użyteczny krok jest prosty: zachować zabawę, a następnie odsłonić mechanizmy. Opublikować logi, oddzielić szybkość od strategii i pozwolić innym deweloperom rozegrać te same walki. Czy model dominujący w zatrzymanym pojedynku przetrwałby, gdy zegar nadal tyka? To pytanie wykracza poza symulowany boks. Testuje, czy AI działająca w czasie rzeczywistym potrafi przekształcić percepcję w działanie, zanim świat znów się zmieni.