Ile danych z teleoperacji naprawdę potrzeba, żeby wytrenować politykę robota

Pytanie pada zwykle w trzecim tygodniu projektu: „zebraliśmy trzysta demonstracji, chwytak dalej gubi detal na co czwartym podejściu — dosypać kolejne trzysta?“. To nie jest pytanie badawcze, tylko budżetowe. Każda demonstracja to roboczogodzina operatora, zajęta cela, wstrzymana linia i kolejny dzień, w którym wdrożenie się nie zaczyna.

Odpowiedź „im więcej, tym lepiej” jest kosztowna i zwykle nieprawdziwa. Poniżej: rzędy wielkości z publikacji, które można sprawdzić, oraz test, który po dwóch dniach powie Ci, czy Twoim ograniczeniem jest liczba demonstracji, czy coś zupełnie innego.

Krótka odpowiedź

Dla jednego wąskiego zadania manipulacyjnego w stałej scenie punktem wyjścia jest 50–150 demonstracji, a nie tysiące. Zespół, który opracował platformę ALOHA i algorytm ACT, raportował wyuczenie precyzyjnych zadań montażowych z około 50 demonstracji na zadanie; prace o Diffusion Policy operują tym samym rzędem wielkości — dziesiątkami, nie tysiącami przykładów. Skokowy wzrost zapotrzebowania pojawia się dopiero wtedy, gdy zmieniasz nie liczbę powtórzeń, lecz liczbę wariantów: nowe oświetlenie, nowy egzemplarz detalu, nowe ustawienie kamery, nowa hala. Wtedy rośnie nie „ile razy”, tylko „w ilu różnych warunkach”, a to jest zupełnie inny koszt.

Innymi słowy: liczba demonstracji na scenę nasyca się szybko, liczba scen — nie. Jeśli chcesz polityki, która działa tylko na jednej stacji przy stałym świetle, mówimy o dniach zbierania danych. Jeśli chcesz polityki odpornej na zmianę zakładu, mówimy o skali, której pojedynczy zespół wdrożeniowy nie osiągnie samodzielnie — i wtedy właściwym ruchem jest dostrojenie gotowego modelu bazowego, nie trening od zera.

Trzy progi budżetowe

Traktuj to jako mapę decyzyjną, nie jako gwarancję. Rzędy wielkości pochodzą z publicznie opisanych zbiorów i eksperymentów, warunki brzegowe zawsze zweryfikuj u siebie.

Cel	Rząd wielkości danych	Realne ograniczenie	Sygnał, że to wystarczy
Demonstrator wykonalności: jedno zadanie, jedna scena, stałe światło	50–150 demonstracji	Powtarzalność operatora i kalibracja kamer	Skuteczność rośnie o mniej niż 5 pkt proc. między 50% a 100% zbioru
Produkcyjna stacja: jedno zadanie, zmienne egzemplarze i pozycje detalu	300–1500 demonstracji rozłożonych na kilkanaście–kilkadziesiąt wariantów sceny	Liczba wariantów, nie liczba powtórzeń	Polityka utrzymuje skuteczność na wariancie odłożonym na bok (nietrenowanym)
Polityka wielozadaniowa / ogólna	Setki tysięcy–miliony trajektorii	Nieosiągalne własnymi siłami	Nie buduj tego sam — dostrajaj model bazowy

Skala trzeciego wiersza nie jest abstrakcją. RT-1 trenowano na około 130 tysiącach epizodów zbieranych 17 miesięcy przez flotę kilkunastu robotów. Zbiór Open X-Embodiment zebrał ponad milion trajektorii z 22 platform sprzętowych dzięki współpracy ponad dwudziestu ośrodków. Zbiór DROID to około 76 tysięcy trajektorii z ponad 500 różnych scen. Model OpenVLA był pretrenowany na blisko milionie epizodów z tego ekosystemu. Żadna z tych liczb nie jest budżetem pojedynczego wdrożenia — to budżet konsorcjum.

Praktyczny wniosek dla zespołu w Polsce: nie próbuj odtwarzać zbioru pretreningowego. Twoim zadaniem jest dołożyć 50–1500 demonstracji tam, gdzie Twoja aplikacja różni się od świata i dostroić model, który już zna fizykę chwytania. Więcej o samych modelach — w tekście o modelach wizja-język-akcja.

Dlaczego 500 przeciętnych demonstracji przegrywa z 80 czystymi

Klonowanie zachowań ma wadę znaną od kilkunastu lat: błędy się kumulują. Ross i Bagnell pokazali, że przy uczeniu z demonstracji odchylenie od rozkładu danych narasta z horyzontem zadania kwadratowo — polityka, która raz zboczy, trafia w stan, jakiego nigdy nie widziała, i dalej już tylko pogłębia pomyłkę. Dlatego długie zadania (dwadzieścia sekund, pięć podetapów) są nieproporcjonalnie trudniejsze od krótkich.

Konsekwencja jest brutalna: dane pełne wahań, cofnięć i „prawie” nie uczą polityki niczego dobrego, a psują rozkład, z którego się ona uczy. Badanie robomimic pokazało, że zbiory od wielu operatorów o zróżnicowanej wprawie są istotnie trudniejsze do wykorzystania niż zbiory od jednego wprawnego operatora — ta sama liczba epizodów, wyraźnie różny wynik.

Nie oznacza to, że każda demonstracja ma być idealna. Oznacza, że musisz świadomie zdecydować, czy uczysz polityki wykonania (wtedy tniesz nieudane przebiegi), czy polityki odzyskiwania po błędzie (wtedy celowo dokładasz nagrania, w których operator wychodzi z pozycji nieoptymalnej — ale robi to konsekwentnie, jednym stylem). Mieszanka bez decyzji to najgorszy wariant.

Znak rozpoznawczy złego zbioru

Cztery objawy widać bez trenowania czegokolwiek: różne tempo tej samej czynności między dniami zbierania, przesunięte kadrowanie kamery po serwisie stanowiska, epizody bez oznaczenia sukcesu i porażki, brak jednolitego znacznika czasu między strumieniem obrazu a odczytem enkoderów. Każde z tych czterech potrafi zjeść efekt kilkuset demonstracji.

Test, który mówi, czy brakuje danych

Zanim zamówisz kolejny tydzień teleoperacji, wykonaj ablację ilości. Wytrenuj tę samą politykę na 25%, 50%, 75% i 100% posiadanego zbioru i zmierz skuteczność na tym samym zestawie prób rzeczywistych. Otrzymujesz krzywą nasycenia — najtańsze narzędzie decyzyjne w całym projekcie.

Jeśli krzywa wciąż rośnie stromo między 75% a 100% — dokładanie danych ma sens, zbieraj dalej w tym samym reżimie. Jeśli krzywa jest płaska od 50% — masz już dość demonstracji i problem leży gdzie indziej: w reprezentacji obserwacji, częstotliwości sterowania, kalibracji, horyzoncie akcji albo w samym zadaniu. Dosypanie danych w tym stanie to spalanie budżetu.

Drugi test, równie tani: odłóż jeden wariant sceny w całości poza trening (inny egzemplarz detalu albo inne oświetlenie) i sprawdź na nim skuteczność. Duża różnica między sceną znaną a odłożoną oznacza, że Twoim problemem jest różnorodność, nie liczebność — i że kolejne 300 powtórzeń w tej samej scenie niczego nie zmieni.

Praca o prawach skalowania w uczeniu przez naśladowanie w manipulacji (Lin i współautorzy, 2024) idzie dokładnie w tę stronę: skuteczność na nowych obiektach i w nowych otoczeniach rośnie wraz z liczbą różnych środowisk i obiektów według zależności potęgowej, a po przekroczeniu kilkudziesięciu wariantów dokładanie kolejnych demonstracji w scenach już znanych przynosi niewiele. Warto tę pracę przeczytać w oryginale, zanim przyjmiesz konkretne progi jako własne — jej warunki eksperymentalne mogą odbiegać od Twojej aplikacji.

Co realnie podnosi jakość danych z teleoperacji

Kolejność ma znaczenie — to lista od najtańszego do najdroższego.

1. Ujednolić kadr i kalibrację. Zapisz pozycje kamer, sprawdzaj je codziennie rano i po każdym serwisie stanowiska. Przesunięta kamera unieważnia dane zebrane wcześniej.
2. Zsynchronizować strumienie. Obraz, pozy i sygnał chwytaka muszą mieć wspólną oś czasu. Dryf 50 ms uczy politykę reagować z opóźnieniem, którego nie ma.
3. Oznaczać wynik epizodu przy zbieraniu, nie po tygodniu. Sukces, porażka, przyczyna porażki — trzy pola, jedno kliknięcie operatora.
4. Ustalić jeden styl wykonania i trzymać się go. Jeśli dwóch operatorów podchodzi do detalu z dwóch stron, uczysz politykę dwóch sprzecznych zachowań naraz.
5. Zbierać wariantami, nie seriami. Zamiast 200 powtórzeń jednego ustawienia — 20 ustawień po 10 powtórzeń. Ten sam koszt, inna wartość.
6. Dopiero potem dokładać wolumen. I tylko wtedy, gdy krzywa nasycenia to uzasadnia.

Warto od początku trzymać dane w standardowym formacie (na przykład LeRobotDataset z otwartej biblioteki LeRobot), żeby nie zamykać sobie drogi do dostrajania publicznych modeli bazowych — otwarte wagi π0 udostępnione przez Physical Intelligence czy OpenVLA to realna alternatywa dla treningu od zera. Szczegóły samego zbierania opisaliśmy w tekście o teleoperacji i zbieraniu danych.

Polskie realia: RODO, monitoring i własność danych

Nagranie z celi produkcyjnej to nie tylko dane techniczne. Jeśli w kadrze pojawia się pracownik, przetwarzasz jego wizerunek. Monitoring w zakładzie pracy reguluje art. 22² Kodeksu pracy: cele, zakres i sposób zastosowania trzeba określić w układzie zbiorowym pracy, regulaminie pracy albo obwieszczeniu, poinformować pracowników nie później niż dwa tygodnie przed uruchomieniem, a pomieszczenia objęte monitoringiem — oznaczyć. Do tego dochodzą obowiązki z RODO, w tym ocena skutków dla ochrony danych przy systematycznym monitorowaniu.

Praktyczne obejście, które warto rozważyć na etapie projektowania stanowiska: kadruj kamery tak, żeby obejmowały strefę roboczą, a nie twarz i sylwetkę operatora. To tańsze niż anonimizacja tysięcy godzin nagrań po fakcie.

Druga rzecz do sprawdzenia przed pierwszą demonstracją: komu przysługują prawa do zebranego zbioru. W umowach z integratorami zapis o własności danych z uruchomienia bywa nieobecny albo domyślnie przypisuje je dostawcy. Zbiór demonstracji to najczęściej najdroższy i najtrwalszy element całego wdrożenia — droższy niż sama polityka, którą można przetrenować.

Trzecia: tryby współpracy człowiek–robot opisane w ISO 10218 i ISO/TS 15066 nakładają ograniczenia prędkości, które zmieniają tempo demonstracji względem trybu przemysłowego. Politykę wytrenowaną na szybkich przebiegach trzeba będzie zweryfikować w reżimie docelowym. Warto też z wyprzedzeniem sprawdzić harmonogram stosowania rozporządzenia maszynowego (UE) 2023/1230 oraz kwalifikację systemu AI będącego elementem bezpieczeństwa maszyny na gruncie aktu o sztucznej inteligencji (rozporządzenie (UE) 2024/1689) — u własnego prawnika, nie z artykułu.

Kiedy przestać zbierać

Przestań, gdy spełnione są trzy warunki naraz: krzywa nasycenia jest płaska od połowy zbioru, skuteczność na odłożonym wariancie sceny jest zbliżona do skuteczności na wariantach znanych, a pozostałe porażki mają wspólną, nazwaną przyczynę (na przykład jeden typ detalu albo jedno położenie graniczne). Trzeci warunek jest najważniejszy: jeśli potrafisz nazwać przyczynę, tańsza jest celowana dozbiórka 30 demonstracji tego konkretnego przypadku niż kolejne 300 losowych.

Jeżeli natomiast po ablacji okaże się, że dane w ogóle nie są wąskim gardłem, kolejnym miejscem do sprawdzenia jest zwykle różnica między symulacją a rzeczywistością — to osobny temat, opisany w tekście o luce sim-to-real.