Nasze projekty · 25 września 2026

Skalper pod nadzorem: sprawdzamy działanie systemu i jakość jego nauki

Sam wynik na ekranie nie wystarcza, żeby ocenić automatyczny system. Trzeba jeszcze wiedzieć, kiedy został zaktualizowany, czy po drodze nie brakowało danych i na czym opiera się ocena jego skuteczności. Dlatego 24 września dodaliśmy do naszego skalpera panel „Nadzór i jakość nauki”. To kolejny krok w rozwoju projektu, który przedstawiliśmy kilka dni temu.

Co zmienia nowy panel?

Dotychczas opisywaliśmy skalpera przede wszystkim jako działający projekt testowany na danych rynkowych. Teraz dokładamy widok, który pomaga oceniać sam przebieg tych testów. W jednym miejscu zbieramy informacje o pracy automatu, aktualności zapisów i jakości danych wykorzystywanych do nauki.

Panel nie jest nowym agentem podejmującym decyzje. Odczytuje istniejące informacje i na ich podstawie przygotowuje raport. Nie otwiera ani nie zamyka pozycji, nie zmienia strategii i nie poprawia samodzielnie modelu. Jego zadaniem jest pokazać, co wymaga sprawdzenia, zanim wyciągniemy wnioski z wyników.

To ważne rozróżnienie: rozwijanie automatyzacji nie zawsze oznacza dodawanie kolejnych działań. Czasem potrzebujemy przede wszystkim lepszego wglądu w to, co system już robi.

Czy widzimy aktualny stan?

Pierwsza część nadzoru dotyczy działania technicznego. Raport sprawdza, jak świeże są zapisane dane, kiedy automat zakończył pracę oraz czy otwarte pozycje mają aktualną kontrolę. Dzięki temu samo wyświetlenie tabeli nie jest traktowane jako potwierdzenie, że wszystko działa prawidłowo.

Wyobraźmy sobie hipotetyczną sytuację: ekran nadal pokazuje ostatnią wycenę, ale od pewnego czasu nie udało się jej odświeżyć. Bez dodatkowego oznaczenia łatwo uznać ją za bieżącą. Nowy panel potrafi wskazać brak aktualnej kontroli, a przy nieaktualnym raporcie wyraźnie zaznacza, że obecnego stanu nie można potwierdzić.

Takie ostrzeżenie nie zawsze oznacza awarię. Brak świeżych danych może mieć różne przyczyny, także zamknięcie rynku. Panel sygnalizuje problem z aktualnością, ale nie udaje, że w każdym przypadku zna jego źródło.

Więcej obserwacji to nie wszystko

Druga część dotyczy danych do nauki. Sam rosnący licznik obserwacji nie odpowiada na pytanie, czy wszystkie zapisy nadają się do jednakowej oceny. Dlatego raport sprawdza między innymi brakujące identyfikatory, powtórzone wpisy i zgodność liczników z dostępną historią.

Pokazuje również oznaczone przerwy w monitorowaniu oraz transakcje z niepełnymi kosztami lub szacowanym finansowaniem. Nie usuwa ich z historii ani nie zmienia salda. Pozwala natomiast zobaczyć, że część materiału wymaga ostrożniejszej interpretacji.

Możemy dzięki temu oddzielić pytanie „ile danych zebraliśmy?” od pytania „co wiemy o ich jakości?”. Brak ostrzeżenia nie jest przy tym gwarancją idealnych danych. Raport pracuje na zachowanych zapisach i nie odtworzy informacji, których wcześniej nie zebrano.

Sprawdzamy wcześniejsze przewidywania

Nowy widok pomaga też oceniać trafność zapisanych przewidywań modelu. Istotna jest kolejność: najpierw powstaje ocena, a dopiero później poznajemy wynik. Raport korzysta z oceny zachowanej przy rozpoczęciu transakcji, zamiast tworzyć ją ponownie po fakcie.

To daje bardziej użyteczną podstawę do rozmowy o nauce niż samo stwierdzenie, że model przeanalizował kolejne przypadki. Nadal jednak oceniamy konkretny rodzaj przewidywania, a nie dowodzimy, że cały system będzie zarabiał.

Panel przedstawia także dostępne porównania wariantów zakończenia transakcji. Pokazuje postęp i sprawdza zgodność liczników porównywanych grup. Ponieważ są to dane wykorzystywane do nauki, nie przedstawiamy ich jako niezależnego testu przewagi.

Raport, do którego można wrócić

Z panelu można pobrać raport do dalszej analizy. Pomaga to zachować obraz sytuacji z danego momentu i wrócić do niego podczas przeglądu projektu. Nie trzeba opierać całej rozmowy na pojedynczym ekranie z wynikiem.

Ten nadzór ma jasno określone granice. Nie jest osobną usługą alarmową, która niezależnie powiadomi o zatrzymaniu serwera. Nie naprawia błędów, nie odtwarza pełnej historii awarii i nie zastępuje kontroli człowieka. Skalper nadal działa w trybie symulacji, więc jego rezultaty nie są wynikami rzeczywistego rachunku.

Co z tego wynika dla małej firmy?

Podobne pytania warto zadawać przy każdej automatyzacji. Jeśli system przygotowuje raport sprzedaży, dobrze wiedzieć, czy odczytał wszystkie źródła. Jeśli porządkuje zapytania, przydaje się informacja o ostatnim udanym pobraniu wiadomości. To przykłady zastosowania tej zasady, nie opis dodatkowych wdrożeń FindAI.

W naszym projekcie nowy panel daje przede wszystkim większą przejrzystość: pokazuje, co jest aktualne, czego brakuje i gdzie ocena wymaga zastrzeżenia. Dopiero z takim kontekstem wynik staje się naprawdę użyteczną informacją.

Jeśli planujesz automatyzację w swojej firmie, opisz FindAI nie tylko zadanie, ale też sposób sprawdzania jego wykonania. Warto od początku ustalić, po czym poznasz, że proces działa, oraz jak zauważysz, że przestał.

Stan na 25 września 2026. Opis funkcji zweryfikowano w dokumentacji projektu i działającym panelu testowym skalpera. Artykuł dotyczy rozwoju oprogramowania, nie stanowi rekomendacji inwestycyjnej.

Poprzedni artykuł: zbudowaliśmy skalpera i testujemy go na trzech rynkach. Zobacz także: raport produkcji bez przepisywania danych.