Technologia sportowa obiecuje dane, ale trudniejsze pytanie brzmi: kto trzyma klucze

Technologia sportowa od lat sprzedaje tę samą obietnicę: więcej danych, szybsze odpowiedzi, mądrzejsze decyzje. Nagłówki z badań rynkowych, które co tydzień trafiają na biurko, opierają się na wskaźnikach wzrostu i skrótach. Rzeczywistość inżynieryjna jest bardziej nieuporządkowana. Dwa dokumenty z tegorocznego stosu warto czytać razem, bo opisują przeciwne sposoby podawania agentowi AI liczb, na których organizacje sportowe coraz częściej twierdzą, że pracują.

Starburst opublikował 11 września analizę dwóch architektur agentowej analizy danych. Tekst jest napisany dla zespołów danych w firmach, nie dla klubów czy lig, ale użyty w nim przykład jest celowo zwyczajny: sklep spożywczy pyta, czy promocja jajek w zeszłym tygodniu była opłacalna. Odpowiedź wymaga wiedzy, czy wyprzedaż przyciągnęła klientów, którzy inaczej by nie przyszli, czy nowi klienci wrócili, co jeszcze kupili w tej samej transakcji, gdzie te towary leżą w sklepie i jak są opłacalne. To łańcuch pytań uzupełniających rozciągnięty na więcej niż jeden zbiór danych. Taki sam kształt ma problem organizacji sportowej, która pyta, dlaczego kampania sponsorska ruszyła sprzedaż biletów.

Opcja 0: wyślij dane do modelu

Pierwsze podejście, które Starburst nazywa opcją 0, polega na wyciągnięciu odpowiednich tabel i wysłaniu surowych danych do agenta jako pliku albo bezpośredniego strumienia, żeby agent przetworzył je sam. Firma mówi wprost o kompromisach. Wysyłanie terabajtów danych do agenta może być zaporowo drogie, gdy agent rozlicza się za każdy otrzymany lub przetworzony element danych. Starburst twierdzi, że wady wydajnościowe ograniczają praktyczność tego podejścia do tego stopnia, że nie jest ono dobre. Dlatego nosi etykietę opcji 0, a nie opcji 1.

Dla drużyn sportowych rachunek i tak wypada niekorzystnie. Jeden mecz generuje teraz dane śledzące, zdarzenia wyliczone z wideo, zapisy biletowe, transakcje merchandisingowe i telemetrię aplikacji, a osób zadających o to pytania jest niewiele. Płacenie za każdy wiersz przy przenoszeniu tego do modelu to pozycja w budżecie, której większość działów analitycznych nie obroni.

Drugie podejście to to, które Starburst rekomenduje. Daj agentowi bezpośredni dostęp do systemu bazodanowego i pozwól mu pisać własny SQL, powtarzając zapytania w miarę zawężania celu. Silnik bazy robi to, do czego powstał: przetwarza lokalne dane z użyciem zoptymalizowanych planów zapytań. Agent nadzoruje pracę i wysyła kolejne lub równoległe żądania, aż dostanie coś, co warto zwrócić. Starburst przyznaje znany minus: agenci mogą być znacznie bardziej wymagający niż ludzie i zalać bazę spekulacyjnymi zapytaniami, gdy pracują.

Branża bazodanowa jest w tej chwili maksymalnie skupiona na obsłudze agentowych obciążeń, a nowoczesne systemy baz danych coraz lepiej radzą sobie z takim skalowalnym przetwarzaniem danych.

To argument w jednym zdaniu i tyle samo sprzedażowy, co inżynieryjny. Starburst sprzedaje systemy baz danych. Mimo to trudno podważyć tezę o tym, gdzie mieszka optymalizacja: agenci się poprawiają, ale nie zaczną przetwarzać terabajtów danych strukturalnych równie wydajnie jak silniki zbudowane na dziesięcioleciach badań nad zapytaniami.

Jak faktycznie wyglądają narzędzia

Dwa projekty open source z tegorocznego stosu pokazują, jak tę instalację składa się na mniejszym końcu skali. Adaca Analytics, opublikowany na GitHubie 8 września na licencji MIT, odtwarza stare pulpity Google Analytics na danych GA4. Dzienne agregacje z GA4 Data API albo eksportu do BigQuery trafiają do bazy D1, którą operator ma, a dane czasu rzeczywistego zostają na Google. Sześć pulpitów jest dostępnych od razu, każda liczba otwiera stronę szczegółów z własnym trendem i podziałami, a całość działa na Cloudflare Workers za Cloudflare Access albo wbudowanym Basic Auth. Nie ma logowania.

Plainoldanalytics, opublikowany na GitHubie 13 września, idzie odwrotną drogą: analityka webowa dokładana do aplikacji w Go. Jest niezależny od magazynu danych, więc import rdzenia nigdy nie ściąga backendu, a adaptery istnieją dla gin i chi. Ruch trafia na dysk mniej więcej raz na sekundę. Operatorzy mogą ustawiać właściwości klucza i wartości przy każdym żądaniu, wyłączać trasy z logowania albo zapisywać dosłowne ścieżki tras zamiast parametrów ścieżki.

Żaden z tych projektów nie jest produktem sportowym. Oba są istotne, bo pokazują zmianę domyślnego założenia: dane zostają tam, gdzie umieścił je operator, a warstwa analityczna jest czymś, co uruchamiasz, a nie czymś, co wynajmujesz.

Pytanie o prywatność, którego nikt nie mierzy

DataZen, lokalny klient bazodanowy opublikowany na Hacker News 29 sierpnia, stawia problem wprost: gdzie trafiają moje dane? Narzędzie działa na licencji GPLv3, nie wymaga konta i domyślnie obsługuje PostgreSQL, MySQL, SQLite oraz Redis, z opcjonalnymi sterownikami dla MongoDB, ClickHouse, DuckDB i SQL Server. Zawiera wbudowany serwer MCP, więc agenci tacy jak Claude, Cursor i Cline mogą odpytywać bazy przez Model Context Protocol, a sam może też działać jako klient MCP. Poświadczenia są szyfrowane AES-256-GCM w pęku kluczy systemu operacyjnego, a projekt twierdzi, że dostawcy AI wybranemu przez użytkownika udostępniany jest tylko schemat i kontekst zapytania.

To ostatnie rozróżnienie jest tym, o które organizacje sportowe powinny pytać. Schemat i kontekst zapytania to nie to samo co surowe dane, ale to też nie nic. Schemat zdradza, co klub mierzy: jakie atrybuty kibiców przechowuje, jak dzieli kupujących bilety, co śledzi w obciążeniu zawodników. W sporcie, gdzie dane o kontuzjach i negocjacje kontraktowe leżą w tym samym majątku co system biletowy, metadane same w sobie są wrażliwe handlowo.

Dossier nie mówi, co faktycznie wdrożył jakikolwiek klub czy liga, a materiały dostawców stojące za prognozami rynkowymi nie są dowodem na adopcję. Pokazuje za to podział. Jeden obóz przekonuje, że agenci powinni sterować bazą, a nowoczesne silniki udźwigną to obciążenie. Drugi buduje narzędzia, które trzymają dane lokalnie i wysyłają na zewnątrz tylko kontekst. Technologia sportowa odziedziczy tę odpowiedź, którą wybiorą jej zespoły danych. Wybór zapada teraz, w repozytoriach open source, nie w komunikatach prasowych.