GPT-5 vs Gemini 2.5: co pokazał mój test analityczny

W teście opublikowanym 10 sierpnia 2025 porównałem GPT-5 i Gemini 2.5 na czterech zadaniach związanych z analizą danych. Interesowało mnie, czy dostanę odpowiedź przydatną w pracy: podsumowanie pliku, propozycję poprawy SQL, analizę zależności oraz komentarz do danych o subskrypcjach. W tej konkretnej próbie bardziej odpowiadał mi Gemini. Ten wniosek zachowuję wraz z datą i zakresem testu.

Dzisiejsza redakcja porządkuje opis i rozwija sposób oceny. Nie przeprowadziłem tutaj nowego porównania tych modeli. Nie mam też podstaw, żeby wyniki czterech zadań zamieniać w aktualny ranking całego rynku AI. Zachowanie narzędzia zależy od wersji, ustawień, dostępnych funkcji i samego polecenia. Nazwa widoczna w aplikacji to zbyt mało, żeby wyjaśnić każdy wynik.

Poniżej najpierw odtwarzam obserwacje zapisane w pierwotnym artykule. Komentarze o tym, jak dokładniej sprawdzać wynik, są rozwinięciem metodycznym. Osobno oznaczam małe ćwiczenie syntetyczne. Dzięki temu wiadomo, co wydarzyło się w opublikowanej próbie, a co proponuję jako sposób pracy z podobnym zadaniem.

Co można ustalić o tamtym porównaniu

Zachowany opis wskazuje cztery rodzaje zadań i ocenę ich rezultatów. Nie zawiera jednak kompletnego pakietu pozwalającego odtworzyć eksperyment: wszystkich plików, pełnych promptów, odpowiedzi, ustawień i dokładnych identyfikatorów modeli. Nie podaję więc nowych współczynników, czasów wykonania ani liczby powtórzeń. Byłyby pozorną precyzją, której źródło nie uzasadnia.

Dotyczy to również nazwy Gemini 2.5. Google opisywało wtedy rodzinę obejmującą różne warianty, w tym Pro i Flash, co potwierdza komunikat z 17 czerwca 2025. Sam skrót użyty w artykule nie pozwala uczciwie dopisać konkretnego wariantu. Podobnie nie odtwarzam z pamięci trybu rozumowania GPT-5 ani konfiguracji aplikacji.

Koryguję przy okazji zbyt szerokie stwierdzenie z pierwotnego tekstu o braku multimodalności GPT-5. Materiał OpenAI z 7 sierpnia 2025 opisuje przyjmowanie tekstu i obrazów. To wystarcza, żeby tamtą tezę odrzucić. Nie oznacza natomiast, że każdy format, narzędzie i sposób generowania wyniku są tą samą funkcją modelu.

Moja ocena pozostaje użytkowa. Patrzyłem na to, czy odpowiedź pomaga wykonać konkretną pracę i ile wysiłku wymaga jej zrozumienie. To ważne kryterium, lecz zawiera element preferencji autora. Ktoś oczekujący gotowego kodu może inaczej ocenić ten sam rezultat niż osoba potrzebująca krótkiego wyjaśnienia dla odbiorcy biznesowego.

Zadanie pierwsze: plik Excel i podsumowanie sprzedaży

Pierwsze zadanie dotyczyło jednego pliku z danymi sprzedażowymi oraz podsumowania do publikacji na LinkedIn. W pierwotnej relacji oba narzędzia poradziły sobie z zadaniem. GPT-5 pokazał podejście oparte na kodzie, a Gemini szerzej wyjaśnił kroki. Różnica czasu odpowiedzi była niewielka; opis nie daje podstaw do wyliczania przewagi w sekundach lub procentach.

Bardziej podobał mi się styl Gemini: w mojej ocenie był bliższy profesjonalnemu podsumowaniu i wymagał mniej pracy redakcyjnej. To obserwacja dotycząca otrzymanych odpowiedzi. Nie dowodzi, że GPT-5 zawsze pisze w określonym stylu albo że Gemini zawsze lepiej komunikuje dane. Styl można zmieniać poleceniem, a pojedynczy rezultat ma ograniczoną wartość porównawczą.

Przy podobnym zadaniu oddzielam dziś trzy rzeczy: odczyt pliku, obliczenie miar i napisanie tekstu. Najpierw sprawdziłbym liczbę wierszy, okres oraz definicję sprzedaży. Następnie porównałbym sumę i wybrane rekordy ze źródłem. Dopiero na tej podstawie oceniałbym podsumowanie. Ładne zdanie o wzroście nie pomaga, jeśli model porównał pełny miesiąc z jego połową.

Tekst przeznaczony do publikacji wymaga jeszcze jednej kontroli. Czy każda liczba ma podstawę w tabeli? Czy słowo „wzrost” odnosi się do właściwej bazy? Czy autor odpowiedzi nie dodał wyjaśnienia przyczyny, którego dane nie zawierają? Wygodne narzędzie skraca drogę do sprawdzonego komunikatu. Samo wygenerowanie kilku akapitów nie kończy analizy.

Zadanie drugie: propozycja poprawy długiego SQL

W drugim zadaniu przekazałem długie, działające zapytanie SQL do poprawy. Według zapisanej relacji Gemini odpowiedział szybciej i zaproponował rozwiązanie z praktycznymi komentarzami. GPT-5 przygotował odpowiedź, którą oceniłem jako poprawną, ale zbyt rozbudowaną względem potrzeby. Znów jest to opis konkretnej interakcji oraz mojej oceny użyteczności.

Ważne rozróżnienie dotyczy słowa „szybciej”. Czas oczekiwania na odpowiedź modelu i czas wykonania zapytania w bazie to osobne pomiary. Pierwotny artykuł nie publikuje planów wykonania ani porównywalnych pomiarów bazy. Nie można więc na jego podstawie stwierdzić, o ile szybszy był zaproponowany SQL. Krótsza odpowiedź również nie dowodzi mniejszego kosztu zapytania.

W dodatkowej kontroli zacząłbym od zachowania znaczenia. Czy oba zapytania zwracają te same rekordy? Jak traktują duplikaty, wartości NULL i remisy? Czy zmiana złączenia nie usuwa klientów bez zamówień? Dopiero po takim sprawdzeniu porównywałbym wydajność w tym samym środowisku. Inaczej łatwo zachwycić się zapytaniem, które działa szybciej, bo liczy coś innego.

Dokumentacja PostgreSQL pokazuje rolę planu wykonania i pomiarów z EXPLAIN ANALYZE. Ta druga forma rzeczywiście wykonuje zapytanie, więc wymaga odpowiedniego środowiska testowego. Podaję ją jako przykład metody sprawdzenia, bez sugerowania, że historyczny test odbywał się właśnie w PostgreSQL. Silnik bazy trzeba ustalić dla własnego przypadku.

Zadanie trzecie: wyświetlenia, blog i sprzedaż

Trzecie zadanie łączyło trzy pliki: dane z YouTube, odsłony bloga i sprzedaż. W relacji oba narzędzia wskazały bezpośrednią korelację bliską zeru. Gemini zaproponował szerszy kontekst i kolejne kierunki analizy. Odpowiedź GPT-5 zawierała kod oraz krótszy wniosek. Doceniłem inicjatywę Gemini, bo pomagała ustalić, co warto zbadać dalej.

W pierwotnym opisie odnotowałem również różnice między odpowiedziami przy ponawianiu pytania. Bez zapisanych ustawień i kompletu prób nie da się z tego policzyć miary powtarzalności ani przypisać przyczyny. Nie zamieniam tej obserwacji w twierdzenie, że jeden model jest zawsze stabilny, a drugi zawsze niestabilny. To sygnał, żeby w kolejnym badaniu zachować odpowiedzi i warunki wykonania.

Przy łączeniu takich danych pierwsze pytanie dotyczy czasu. Czy każdy plik obejmuje te same dni? Czy brak wiersza oznacza zero, brak pomiaru czy inną strefę czasową? Czy połączenie nie powiela sprzedaży dla kilku filmów z jednego dnia? Zanim zinterpretuję współczynnik, potrzebuję poprawnie zbudowanej tabeli. Błąd złączenia potrafi wyglądać jak interesujący wynik statystyczny.

Korelacja bliska zeru wymaga ostrożnego opisu. Dla korelacji Pearsona oznacza słabą zależność liniową w sprawdzonym zestawie; nie wyklucza każdej zależności. Sam związek statystyczny także nie ustala przyczyny. NIST pokazuje różne kształty zależności i ograniczenie wnioskowania przyczynowego. Obejrzenie punktów może powiedzieć więcej niż samotna liczba w podsumowaniu.

Pomysł sprawdzenia opóźnienia między publikacją a zakupem może być sensowną hipotezą. Trzeba jednak określić sposób jej oceny. Przesuwanie okna do chwili znalezienia ładnego wyniku zwiększa ryzyko przypadkowego odkrycia. Zapisuję więc plan, sprawdzam alternatywne wyjaśnienia i traktuję eksplorację jako początek pracy. Dobra sugestia modelu nadal potrzebuje danych oraz kontroli.

Zadanie czwarte: miesięczna i roczna subskrypcja

Ostatnie zadanie dotyczyło oceny wprowadzenia tańszego wariantu miesięcznego obok planu rocznego. Dane wymagały uporządkowania. W opisanej próbie GPT-5 zatrzymał się na problemie z przetwarzaniem i nie dostarczył kompletnej analizy. Gemini przygotował wykres oraz komentarz biznesowy, choć przy jego pracy również pojawił się techniczny problem z wykresem. Zachowuję oba szczegóły, bo sukces nie był bezbłędny.

Komentarz Gemini sugerował możliwość pozyskania nowych klientów i dodatkowego przychodu, przy jednoczesnym ryzyku przenoszenia zakupów z planu rocznego na miesięczny. Traktuję to jako treść odpowiedzi otrzymanej podczas testu. Sam opublikowany opis nie pozwala niezależnie potwierdzić skutku biznesowego ani wyliczyć opłacalności zmiany. Nie jest też rekomendacją obecnej polityki cenowej.

W rozwinięciu analizy rozdzieliłbym nowych klientów, odnowienia i osoby zmieniające plan. Ustaliłbym okres obserwacji, sposób traktowania zwrotów oraz definicję każdej miary. Liczba płatności miesięcznych i liczba klientów to różne rzeczy. Porównanie wymaga też wspólnego horyzontu, bo pojedyncza wpłata roczna obejmuje inny okres niż pojedyncza wpłata miesięczna.

Wykres powinien pokazywać dokładnie to, co opisuje tekst. Sprawdzam zakres dat, jednostki, podpisy serii i zgodność z tabelą. Jeśli narzędzie naprawia błąd rysowania, ponownie kontroluję liczby. Udane wyświetlenie obrazu potwierdza tylko techniczne ukończenie jednego kroku. Wniosek o zachowaniu klientów wymaga jeszcze poprawnej definicji grup i wiarygodnego porównania.

Jak przygotowałbym dokładniejszy test

Poniższa procedura jest propozycją dla kolejnego porównania. Nie opisuje dodatkowych działań wykonanych w sierpniu 2025. Zacząłbym od małego zestawu zadań z oczekiwanym rezultatem oraz osobnej listy kryteriów. Przed zobaczeniem odpowiedzi ustaliłbym, które błędy dyskwalifikują wynik, a które wymagają jedynie poprawy prezentacji. To ogranicza pokusę zmieniania zasad pod ulubione narzędzie.

Zapisałbym dokładne nazwy modeli, datę, interfejs, dostępne narzędzia, ustawienia i pełne polecenia. Obie strony dostałyby ten sam zakres informacji oraz takie same zasady dodatkowych pytań. Zachowałbym pierwszą odpowiedź i późniejsze poprawki oddzielnie. Wynik uzyskany po kilku podpowiedziach człowieka powinien być opisany inaczej niż poprawna odpowiedź za pierwszym razem.

Oceniałbym osobno ukończenie zadania, poprawność danych, poprawność obliczeń, uzasadnienie wniosku i czytelność. Brak pliku wynikowego przy zadaniu wymagającym pliku jest konkretną porażką. Zbyt długi komentarz może być niewygodny, ale ma inny ciężar niż błędna suma. Jedna ocena punktowa łatwo ukrywa tę różnicę, zwłaszcza gdy nie ustalono wag.

Do czasu odpowiedzi doliczyłbym własną pracę. Narzędzie może skończyć szybko, a potem wymagać długiego poprawiania kolumn i sprawdzania wniosków. Inne odpowie później, ale zostawi jasne kroki i wynik łatwy do odtworzenia. Mierzyłbym czas dojścia do rezultatu spełniającego kryteria. Powtarzałbym próby według ustalonego planu i pokazywał rozrzut, zamiast wybierać najbardziej efektowną odpowiedź.

Co zapisać obok każdej odpowiedzi

Własny arkusz oceny zacząłbym od pytania biznesowego oraz oczekiwanego formatu rezultatu. „Przeanalizuj sprzedaż” pozostawia ogromną dowolność. Prośba o sumę podpisanych wartości według kanału, dla określonego okresu i z opisem korekt, znacznie lepiej wyznacza zadanie. Nie próbuję w ten sposób odtworzyć dawnego promptu. Pokazuję, jak ograniczyć niejasność przy następnym porównaniu i ocenić odpowiedź względem wcześniej zapisanej potrzeby.

Następnie opisałbym pochodzenie oraz zakres danych. Ważne są liczba rekordów, znaczenie pojedynczego wiersza, klucze łączenia i reguły wykluczania obserwacji. Jeśli model sam przyjmuje założenie, powinno być widoczne w wyniku. Usunięcie duplikatu może naprawić problem albo skasować prawidłową pozycję zamówienia. Ocena zależy od definicji tabeli. Bez niej trudno nawet powiedzieć, czy model wykonał potrzebne czyszczenie, czy zmienił badany zbiór.

Zapisałbym też miejsce pierwszego błędu. Nieudany odczyt pliku, błędna agregacja i zbyt daleki wniosek wymagają różnych poprawek. Taki podział pomaga ustalić, w czym narzędzie rzeczywiście wspiera analityka. Model może dobrze wyjaśniać SQL, lecz potrzebować pomocy przy formacie eksportu. Może również poprawnie przygotować tabelę i potem opisać ją zbyt kategorycznie. Jedno ogólne „nie działa” nie daje wystarczającej informacji do wyboru zastosowania.

Osobne miejsce zostawiłbym na interwencje człowieka. Jeśli muszę wskazać błędną kolumnę, dopisać definicję miary albo poprosić o ponowne narysowanie wykresu, zapisuję tę czynność i jej powód. Pomoc udzielona jednemu narzędziu zmienia warunki porównania, jeśli drugie jej nie otrzymało. Można badać zarówno samodzielne wykonanie, jak i współpracę z analitykiem, ale warto wyraźnie nazwać, który z tych procesów właśnie oceniam.

Na końcu zapisałbym decyzję o wykorzystaniu odpowiedzi. Czasem wystarczy poprawić nazwę kolumny. Innym razem trzeba ponownie policzyć całość albo odrzucić wniosek. Tę decyzję wiążę z dowodem: kontrolną sumą, porównaniem rekordów, sprawdzonym planem lub informacją od właściciela procesu. Pozwala to wrócić do oceny po tygodniu i zrozumieć jej uzasadnienie. Sam kolor komórki z oceną szybko traci znaczenie, jeśli nie zachowam tego, co za nim stało.

Taki zapis przydaje się również wtedy, gdy oba narzędzia mają rację. Mogły poprawnie policzyć wynik, a różnić się sposobem pokazania założeń i łatwością dalszej pracy. Wtedy wybór zależy od mojego procesu oraz odbiorcy. Dla osoby utrzymującej skrypt ważna będzie możliwość odtworzenia kroków, dla odbiorcy raportu jasna definicja miary i zakresu. Nie muszę sztucznie ogłaszać jednej odpowiedzi zwycięską we wszystkich kategoriach.

Ćwiczenie: zero korelacji i widoczna zależność

Ten przykład jest nowym ćwiczeniem syntetycznym. Nie pochodzi z plików wykorzystanych w historycznym teście i nie jest wynikiem ponownego uruchomienia modeli. Przyjmij cztery pary: X ma wartości 1, 2, 3, 4, a Y odpowiednio 4, 1, 1, 4. Obie zmienne mają zmienność, więc korelacja Pearsona jest tutaj określona.

Średnia X wynosi 2,5, średnia Y również 2,5. Iloczyny odchyleń sumują się do zera, a współczynnik korelacji Pearsona wynosi 0. Po narysowaniu punktów widać jednak symetryczny kształt przypominający literę U. Ten mały przykład pomaga sprawdzić, czy komentarz odróżnia brak zależności liniowej od braku jakiejkolwiek struktury.

Poproś wybrane narzędzie o obliczenie współczynnika, wykres i krótką interpretację. Następnie samodzielnie porównaj cztery pary z rysunkiem. Zwróć uwagę, czy model nie dopisuje przyczyny, której ćwiczenie nie zawiera. Zapisz odpowiedź przed poprawianiem polecenia. W ten sposób ćwiczysz kontrolę wyniku, a nie tylko umiejętność uzyskania przekonująco brzmiącego akapitu.

Co zabieram z tego porównania do własnej pracy

Moja historyczna preferencja dla Gemini wynikała z użyteczności otrzymanych odpowiedzi w czterech zadaniach. Doceniłem praktyczne komentarze, propozycje dalszej analizy i doprowadzenie trudniejszego zadania do wyniku. Zachowuję ten osąd, ale nie rozszerzam go na każdy model, każde ustawienie i wszystkie możliwe zastosowania. Do wyboru narzędzia potrzebuję prób odpowiadających rzeczywistej pracy.

Najbardziej przydatna odpowiedź pozwala mi prześledzić drogę od źródła do wniosku. Pokazuje, co zostało policzone, czego brakuje i które stwierdzenie jest hipotezą. Jeśli model brzmi pewnie, a tej drogi nie umiem odtworzyć, mam więcej sprawdzania do wykonania. Kompetencje analityczne pomagają ocenić AI równie mocno jak samodzielnie przygotować raport.

Dlatego rozwijanie warsztatu nadal ma sens. Przy plikach przydaje się praktyczna kontrola danych w Excelu, przy zapytaniach rozumienie złączeń SQL, a przy obliczeniach podstawy Pythona. Z taką bazą łatwiej wykorzystać dobrą sugestię modelu i zauważyć moment, w którym przekonująca odpowiedź przestaje mieć oparcie w danych.