BBest24
PLEN

YOLO26 w praktyce: od detekcji obiektu do decyzji systemu

Co naprawdę zwraca YOLO26, co zmienia względem poprzedników i jak przejść od ramek na obrazie do użytecznego systemu? Wdrożenia, pułapki pomiarów i alternatywy, które warto porównać.

  • BBest24
  • 15 min czytania
Dwa geometryczne opakowania na przenośniku, ujęte w narożniki ramek detekcji. Punktowy ślad przecina linię zliczania. Koncepcyjna ilustracja detektora i logiki systemu.

Ramka wokół przedmiotu to dopiero początek

Na przenośniku przesuwają się opakowania. Kamera pokazuje obraz, a program rysuje wokół każdego prostokąt i dopisuje nazwę. Demonstracja wygląda przekonująco. Dopiero po podłączeniu licznika okazuje się, że ta sama sztuka została policzona kilkanaście razy. Model poprawnie wykrył przedmiot na kolejnych klatkach. System błędnie uznał każde wykrycie za nową sztukę.

To dobry punkt wyjścia do rozmowy o YOLO26. YOLO dostarcza informacji o obrazie; użyteczna decyzja wymaga jeszcze określenia, co ta informacja oznacza w danym procesie. Rozdzielenie tych odpowiedzialności pomaga zarówno zrozumieć technologię, jak i uniknąć kosztownego wdrożenia, które świetnie wygląda wyłącznie na filmie.

Przykład przenośnika i obliczenia poniżej są hipotetyczne, nie pochodzą z realizacji BBest24. Udokumentowane zastosowania omówimy osobno. Przyjmujemy stan wiedzy na 19 maja 2026 r., a porównania techniczne opieramy między innymi na dokumentacji premierowego wydania, żeby późniejsze funkcje nie zmieniały znaczenia wcześniejszych wyników.

Co właściwie zwraca YOLO?

YOLO rozwija się jako You Only Look Once. W pierwotnej pracy Redmona i współautorów detekcję potraktowano jako bezpośrednie przewidywanie położenia i klas obiektów z obrazu. Zamiast osobno klasyfikować wiele proponowanych regionów, sieć wyznaczała zestaw przewidywań w jednym przebiegu. Dzisiejsze modele znacznie różnią się od oryginału; nazwa nie oznacza też, że cały program wykonuje tylko jedną operację.

Typowy detektor zwraca prostokątną ramkę, czyli bounding box, identyfikator klasy i wynik pewności. Ramka mówi, gdzie w obrazie znajduje się przewidywany obiekt. Klasa może oznaczać osobę, samochód albo kategorię opakowania, której model został nauczony. Wynik pewności służy do porządkowania i filtrowania przewidywań. Wartość 0,9 nie jest automatycznie dowodem, że dziewięć na dziesięć takich odpowiedzi na naszej hali będzie poprawnych: to wymaga sprawdzenia kalibracji na odpowiednich danych.

Pod wspólną nazwą rodziny występują różne zadania. Klasyfikacja przypisuje kategorię całemu obrazowi. Detekcja lokalizuje poszczególne obiekty. Segmentacja instancji wskazuje piksele należące do każdej sztuki, a estymacja pozy wyznacza punkty charakterystyczne, na przykład stawy człowieka. OBB to obrócona ramka, przydatna dla obiektów ustawionych pod różnymi kątami. Nie należy oczekiwać wszystkich tych wyników od jednego standardowego pliku wag detektora.

Ta różnica ma praktyczne znaczenie. Do policzenia odseparowanych pudełek może wystarczyć ramka. Do oceny ich widocznej powierzchni potrzebna bywa maska. Do pomiaru wymiarów w milimetrach dochodzą geometria stanowiska, kalibracja i kontrola perspektywy. Wybór zadania powinien poprzedzać wybór rozmiaru sieci.

Czym YOLO nie jest i czego nie załatwi za nas

YOLO nie jest modelem językowym prowadzącym rozmowę ani kompletną aplikacją do zarządzania produkcją. Standardowy detektor nie odczytuje dowolnego tekstu, nie zna numeru seryjnego przedmiotu i nie wyjaśnia przyczyny uszkodzenia. Może wskazać obszar dla OCR lub kolejnego modelu, ale to osobne etapy. Wyjątki i wyspecjalizowane warianty wymagają konkretnych danych oraz konfiguracji.

Detekcja nie daje trwałej tożsamości między klatkami. Tracker, taki jak ByteTrack, kojarzy obserwacje w czasie. Jego identyfikator oznacza ścieżkę śledzenia, nie potwierdzoną tożsamość osoby czy fabryczny numer produktu. Zasłonięcie i ponowne pojawienie się obiektu może skutkować nowym identyfikatorem. W liczniku trzeba obsłużyć także tę sytuację.

Podobnie brak ramki oznacza jedynie brak wykrycia przy danych warunkach i ustawieniach. Nie dowodzi, że na obrazie nie ma człowieka ani że produkt jest wolny od wad. Obiekt mógł być zbyt mały, niewyraźny, zasłonięty lub spoza znanych klas. System może też pracować na opóźnionej klatce, choć ekran nadal wygląda normalnie.

W zwykłym modelu uczonym na ustalonym zestawie klas pojawienie się nowego opakowania nie powoduje samoczynnego nauczenia się jego nazwy. Zmiana wymaga przygotowania danych, treningu lub dostrojenia i ponownej oceny. Odmiany obsługujące otwarte słownictwo poszerzają możliwości, ale nie znoszą potrzeby testowania konkretnego zadania. W szerszą relację tych pojęć wprowadza notatka AI a ML.

Numer wersji nie jest drabiną postępu

Rodzina YOLO nie ma jednej, nieprzerwanej linii autorów i architektur. YOLOv5, YOLOv8 oraz YOLO11 są związane z Ultralytics, natomiast YOLOv10 pochodzi z innego zespołu badawczego. Kolejne nazwy nie oznaczają automatycznie zgodności kodu, identycznej licencji ani przewagi na każdym urządzeniu. Oznaczenie YOLO26 nie jest dowodem istnienia dwudziestu pięciu wcześniejszych wydań tego samego produktu.

W razie potrzeby przewiń tabelę poziomo.

Rodzina Istotny punkt odniesienia Znaczenie przy porównaniu
YOLOv5 Utrwalony ekosystem detektorów opartych na anchorach Działające wdrożenie może mieć dobrze sprawdzony eksport i progi
YOLOv8 Detekcja anchor-free i wspólne narzędzia dla wielu zadań Zmiana modelu nie usuwa potrzeby oceny danych i końcowego runtime’u
YOLOv10 Detekcja end-to-end bez NMS YOLO26 nie wprowadza tej idei jako pierwsze
YOLO11 Bezpośredni punkt odniesienia Ultralytics dla YOLO26 Porównujemy konkretne zadanie i rozmiar, nie sam numer
YOLOv12 Badawcza architektura mocniej wykorzystująca attention Inny autor i kierunek projektu, a nie obowiązkowy etap migracji
YOLO26 Nacisk na uproszczenie inferencji i wdrożenia Trzeba rozróżniać tryb end-to-end, konfigurację eksportu i sprzęt

Punkty odniesienia opisują repozytorium YOLOv5, historyczna dokumentacja YOLOv8 i praca o YOLOv12. Litery n, s, m, l i x oznaczają rozmiary w obrębie danej rodziny. „Nano” dwóch producentów nie musi mieć podobnej liczby parametrów, zajętości pamięci ani rozdzielczości wejścia.

Co zmienia YOLO26 i dlaczego ma to znaczenie

Ultralytics ogłosiło premierę YOLO26 14 stycznia 2026 r.. Kierunek zmian obejmuje prostszy tor wykonania, usprawnienia treningu i odmiany dla różnych zadań. Dla projektanta urządzenia istotne jest nie tylko to, ile operacji wykonuje sieć, lecz również jakie operatory trzeba obsłużyć poza nią.

W wielu detektorach kilka nakładających się ramek opisuje ten sam obiekt. NMS, czyli non-maximum suppression, odrzuca część konkurencyjnych przewidywań według ocen i stopnia nakładania. W YOLO26 tryb end-to-end usuwa potrzebę tego etapu. To mniej logiki do przeniesienia między środowiskami. NMS-free nie oznacza jednak braku progów, przeliczenia współrzędnych ani błędów detekcji. Nie zastępuje też trackera: dotyczy przewidywań dla obrazu, nie tożsamości między klatkami.

Zgodnie z dokumentacją v8.4.0 usunięcie DFL upraszcza regresję ramek, MuSGD łączy podejścia SGD i Muon, a ProgLoss/STAL dotyczą uczenia oraz małych obiektów. Opisane są też usprawnienia segmentacji instancji, pozy i OBB. Trzeba dobrać odpowiednią odmianę modelu.

DFL rozwija się jako Distribution Focal Loss i wiąże uczenie lokalizacji z rozkładem możliwych odległości do granic ramki. Uproszczenie tej reprezentacji zmniejsza złożoność głowicy. MuSGD jest optymalizatorem aktualizującym wagi podczas treningu; inspiracja metodami stosowanymi przy modelach językowych nie czyni z YOLO modelu językowego. STAL, Small-Target-Aware Label Assignment, dotyczy przypisywania przykładów małym obiektom. Z kolei kod straty end-to-end pokazuje stopniowe przesuwanie wagi uczenia od przypisania wielu predykcji jednemu obiektowi do przypisania jeden do jednego. To zmiany sposobu uczenia, nie dodatkowe procedury optymalizacji wykonywane przy każdej klatce.

Ważniejsza od listy skrótów jest konsekwencja projektowa. Prostszy graf może ułatwić eksport, lecz wsparcie operatorów przez konkretny akcelerator pozostaje warunkiem wdrożenia. Lepsze przypisanie małych obiektów podczas uczenia nie odzyska szczegółu, który zniknął przy pomniejszaniu obrazu. Nowy optymalizator nie naprawi niespójnych etykiet. Każdą korzyść trzeba przełożyć na test, który odpowiada problemowi stanowiska.

Nie należy też odczytywać deklaracji „do 43% szybciej na CPU” jako obietnicy skrócenia reakcji każdej aplikacji o 43%. To deklaracja producenta dotycząca określonego porównania. W innym runtime, rozdzielczości lub wariancie modelu wynik może być inny; dodatkowy czas kamery i logiki systemu nie znika.

Benchmark odpowiada na węższe pytanie niż wdrożenie

IoU, czyli intersection over union, to pole przecięcia przewidywanej i referencyjnej ramki podzielone przez pole ich sumy. Pozwala ocenić lokalizację. Precision opisuje udział poprawnych wykryć w zaakceptowanych przewidywaniach, a recall udział znalezionych obiektów wśród tych, które należało znaleźć. Podniesienie progu pewności może zmniejszyć liczbę fałszywych alarmów, ale także zwiększyć liczbę pominięć.

AP podsumowuje zależność precision od recall, a mAP uśrednia wyniki. W protokole COCO podstawowy wynik AP obejmuje progi IoU od 0,50 do 0,95. Nie jest tym samym co AP50 ani „procent zdjęć rozpoznanych poprawnie”. Różne sposoby liczenia tych miar potrafią zmienić pozorny ranking bez żadnej zmiany modelu.

Konkretny przykład: tabela premierowa podaje dla YOLO26n, wejścia 640 i zbioru COCO, 40,1 mAP w kolumnie end-to-end oraz 40,9 w osobnej kolumnie standardowej. Cytowanie wyłącznie wyższej wartości jako wyniku wariantu NMS-free zaciera różnicę konfiguracji. To liczby producenta, nie pomiar przeprowadzony na potrzeby tego artykułu.

Podobnie FPS i czas reakcji odpowiadają na różne pytania. Przetwarzanie dużych paczek może zwiększyć przepustowość, choć pojedynczy obraz dłużej czeka na wynik. W liczniku pracującym na żywo interesuje nas wiek klatki w chwili decyzji, także opóźnienia p95/p99 i zachowanie pod obciążeniem. Warto mierzyć osobno przechwycenie, dekodowanie, przygotowanie obrazu, inferencję, śledzenie i obsługę zdarzenia.

Załóżmy przenośnik poruszający się z prędkością 1 m/s. Jeżeli od ekspozycji obrazu do polecenia upływa 100 ms, przedmiot przemieszcza się o 1 m/s × 0,1 s = 0,1 m, czyli 10 cm. Doskonała ramka na nieaktualnym obrazie może więc nie wystarczyć do uruchomienia odrzutnika we właściwym momencie. Są to przykładowe założenia, nie parametry konkretnego urządzenia.

Uczciwy test zapisuje wersję wag i kodu, zbiór testowy, rozdzielczość, sprzęt, runtime, precyzję FP32/FP16/INT8, batch size i zakres mierzonego czasu. Liczbę parametrów warto uzupełnić szczytowym zużyciem pamięci: pamięć na aktywacje i bufory potrafi zmienić wybór urządzenia. Pomiar energii oraz stabilności po rozgrzaniu uzupełnia wynik uzyskany w pierwszej minucie.

Trzy wdrożenia i trzy różne role detektora

W opisach zastosowań trzeba oddzielić relację dostawcy od niezależnej oceny. Poniższe materiały opisują działające systemy, ale nie udostępniają kompletnego protokołu, danych testowych i historii każdej wersji modelu. Nie przypisujemy całej poprawy procesu samemu YOLO ani wcześniejszych wdrożeń wersji 26.

Chef Robotics: detekcja jako część manipulacji. W opisie z 12 marca 2026 r. YOLO pomaga lokalizować tacki i składniki przy automatyzacji przygotowywania posiłków. Za ruchem robota stoją również kalibracja, planowanie i dozowanie. Raportowane efekty dotyczą całego stanowiska. Materiał nie uzasadnia przenoszenia deklarowanej „accuracy” na COCO mAP ani na inną linię produkcyjną.

SiteAssist: obraz jako element procedury. Relacja z 15 kwietnia 2026 r. opisuje sprawdzanie zdjęć dokumentujących przygotowanie prac, rozpoznawanie wyposażenia i łączenie detekcji z OCR. Przetwarzanie odbywa się w backendzie chmurowym. Widoczna gaśnica nie potwierdza jednak jej sprawności: wykrycie przedmiotu i zatwierdzenie warunków pracy są różnymi odpowiedzialnościami. Zbiorczy wolumen obsłużonych zdjęć nie mierzy skuteczności jednej wersji modelu.

Kiwitron: detekcja blisko maszyny. W materiale o KiwiEye z 18 grudnia 2024 r. kamery i akceleratory Coral wspierają rozpoznawanie ludzi, pojazdów oraz oznaczeń przy maszynach przemysłowych. Tu liczą się ograniczenia urządzenia i szybkie ostrzeganie operatora. To zastosowanie rodziny YOLO sprzed premiery YOLO26; opis nie dowodzi migracji do nowej wersji ani certyfikacji bezpieczeństwa funkcjonalnego.

Wspólny wzorzec jest konkretny: model rozwiązuje ograniczone zadanie percepcji, a reszta produktu nadaje wynikowi znaczenie. Ten sam detektor może pomagać robotowi, weryfikować dokumentację albo zasilać ostrzeżenie. Nie oznacza to, że te trzy zastosowania mają takie same wymagania odbiorowe.

Od kilku linii Pythona do licznika na przenośniku

Na początek wystarczy pojedynczy lokalny obraz i model z gotowymi wagami. Poniższy przykład odczytuje ramki, klasy i pewność; nie liczy przejść i nie uruchamia robota. Wymaga Pythona, pakietu ultralytics obsługującego YOLO26 oraz pliku frame.jpg. Przy pierwszym użyciu biblioteka może pobrać wagi. Zapis API sprawdzono względem kodu wydania v8.4.0; nie jest to raport z uruchomienia ani benchmark.

from ultralytics import YOLO

model = YOLO("yolo26n.pt")
result = model.predict(
    source="frame.jpg",
    imgsz=640,
    conf=0.25,
    device="cpu",
    verbose=False,
)[0]

for box in result.boxes:
    class_id = int(box.cls[0].item())
    score = float(box.conf[0].item())
    xyxy = box.xyxy[0].tolist()
    print(result.names[class_id], round(score, 3), xyxy)

Gotowy detektor zna klasy swojego zbioru treningowego, nie dowolne oznaczenia SKU. Próg 0,25 w przykładzie jest ustawieniem demonstracyjnym. W projekcie ustala się go na danych walidacyjnych, uwzględniając koszt pominięcia i fałszywego wykrycia. Własne opakowania zwykle wymagają oznaczonych przykładów, obrazów negatywnych i dostrojenia modelu.

Przepływ od kamery przez przygotowanie obrazu, YOLO, tracker i regułę przekroczenia linii do zarejestrowanego zdarzenia
Przykładowy tor zliczania. YOLO lokalizuje obiekty; śledzenie i reguła przejścia tworzą zdarzenie. Schemat koncepcyjny, nie dokumentacja wdrożenia.

Dla przenośnika najpierw określamy jednostkę zliczania: pełne opakowanie przekraczające linię w danym kierunku. Potem dobieramy kadr, ekspozycję, oświetlenie i prędkość próbkowania. Tracker łączy wykrycia. Reguła zdarzenia pamięta, po której stronie linii znajdował się obiekt, i zlicza potwierdzone przejście tylko raz. Pas tolerancji wokół granicy ogranicza wielokrotne zdarzenia spowodowane drganiem ramki.

Trzeba określić zachowanie przy postoju, ruchu wstecznym, zasłonięciu, utracie identyfikatora i restarcie aplikacji. Zdarzenie wysyłane do backendu potrzebuje identyfikatora pozwalającego odrzucić powtórzoną transmisję. Problem „ta sama sztuka dwa razy” może powstać zarówno w trackerze, jak i podczas ponowienia żądania sieciowego. To dwa oddzielne miejsca kontroli.

Po wytrenowaniu modelu eksport do ONNX lub TensorRT przenosi obliczenia do środowiska docelowego. ONNX jest formatem reprezentacji, a nie gwarancją jednakowej szybkości na każdym sprzęcie. Należy ponownie sprawdzić wyniki po eksporcie i ewentualnej kwantyzacji, w tym małe obiekty i przypadki blisko progu decyzji. Aplikacja musi też pilnować, czy model, mapowanie klas i przygotowanie obrazu pochodzą z tej samej wersji konfiguracji.

Najdroższe błędy często powstają poza siecią

Przypadkowy podział klatek jednego nagrania na trening i test daje złudzenie generalizacji. Sieć widzi prawie identyczne tło, obiekty i światło po obu stronach podziału. Lepiej rozdzielić nagrania, dni, partie lub lokalizacje, zgodnie z tym, gdzie rozwiązanie ma później działać. Zbiór testowy pozostaje zamknięty podczas dobierania progów i konfiguracji.

W odbiorze warto uwzględnić nakładające się opakowania, zmierzch, refleksy folii, zabrudzoną optykę, rozmycie i nowy wzór etykiety. Bardzo mały obiekt może po zmianie rozdzielczości zajmować kilka pikseli. Żaden ranking modeli nie zastąpi wówczas zmiany kadru, optyki lub sposobu podziału obrazu na fragmenty. Dla stabilnego stanowiska lepsze światło bywa bardziej wartościowe niż większa sieć.

Mierzmy to, co kupuje użytkownik. W liczniku: pominięcia, podwójne zliczenia, zgodność kierunku i czas dostarczenia zdarzenia. Gdy wśród 1000 sztuk pominiemy 20 i inne 20 policzymy dwukrotnie, końcowa liczba nadal wyniesie 1000. Pozornie idealna suma maskuje 40 błędnych historii przedmiotów. Potrzebujemy więc porównania zdarzeń, a nie tylko wartości końcowej.

Test ciągły powinien wykryć narastającą kolejkę, spadek wydajności po rozgrzaniu oraz utratę kamery. Przy przeciążeniu czasami lepiej odrzucić stare klatki, ale tylko jeśli pozostała częstotliwość pozwala uchwycić wymagane przejścia. Osobne liczniki odrzuconych klatek i wieku obrazu pomagają odróżnić „nie było obiektu” od „nie mamy wiarygodnej obserwacji”.

Po wdrożeniu zapisujmy wersję modelu, stan źródła obrazu i potrzebne metryki operacyjne. Próbki błędów pomagają ulepszać zbiór, lecz nie wymagają bezterminowego magazynowania wszystkich nagrań. W scenach z ludźmi zakres dostępu i retencję trzeba ustalić jako część projektu. Aktualizacja modelu powinna mieć porównanie z poprzednikiem i możliwość powrotu.

Alternatywy: co porównywać zamiast samych FPS

Alternatywę wybieramy do zadania i urządzenia. RT-DETR oraz RT-DETRv2 pokazują, że detekcja end-to-end w czasie rzeczywistym nie jest zarezerwowana dla YOLO. RF-DETR rozwija podejście transformerowe z naciskiem na dostosowanie do domen i relację jakości do opóźnienia. Wyniki prac są argumentem, by uwzględnić te modele w eksperymencie, nie dowodem zwycięstwa na naszym urządzeniu.

W razie potrzeby przewiń tabelę poziomo.

Podejście Kiedy warto je sprawdzić Główny koszt lub ograniczenie
YOLO26 Detekcja na żywo, różne rozmiary modeli i wspólne narzędzia dla kilku zadań Walidacja eksportu, danych i wariantu; warunki licencji Ultralytics
RT-DETR / RT-DETRv2 Detekcja end-to-end, szczególnie gdy dostępne jest GPU Pamięć, rzeczywiste opóźnienie i obsługa operatorów na docelowym urządzeniu
RF-DETR Dostrajanie detektora do własnej domeny; alternatywa transformerowa Rozdzielczość, pamięć i koszt wykonania konkretnego wariantu
Faster R-CNN Referencyjny detektor dwuetapowy, gdy budżet czasu jest mniej restrykcyjny Propozycje regionów i drugi etap mogą utrudniać osiągnięcie niskiego opóźnienia
SSD z MobileNet Małe urządzenia lub istniejący, dobrze wspierany stos wykonawczy Trzeba sprawdzić stratę jakości, zwłaszcza dla małych obiektów
Klasyczne przetwarzanie obrazu Kontrolowane światło, prosty kształt, przewidywalne tło Ręczne reguły mogą być kruche przy zmianie wyglądu sceny

Faster R-CNN, SSD i MobileNets opisują różne elementy tej mapy: MobileNet jest rodziną lekkich sieci mogących pełnić rolę backbone’u, nie samodzielnym synonimem detektora. Prosty licznik może też korzystać z progowania, konturów i geometrii, bez uczenia głębokiego. Taki punkt odniesienia pokaże, czy złożoność ML rzeczywiście się opłaca.

Licencja należy do implementacji i artefaktów, nie do ogólnej idei architektury. Kod Ultralytics v8.4.0 jest udostępniany na AGPL-3.0; dostawca oferuje także licencję Enterprise. Oficjalne repozytorium RT-DETR i podstawowe wydania RF-DETR używają Apache-2.0. Dla Faster R-CNN i SSD można wybrać implementacje, np. z Torchvision na BSD-3-Clause. Przed wyborem należy sprawdzić także wagi, dane i zależności. Komercyjne użycie nie jest automatycznie zakazane przez AGPL, ale obowiązków nie usuwa sam eksport wag.

Gdy potrzebujemy wskazać obiekt opisem tekstowym, warto rozważyć Grounding DINO. Gdy potrzebujemy maski obiektu wskazanego punktem lub ramką, właściwym narzędziem może być SAM. Mogą pomagać w anotacji albo stanowić część większego potoku. Nie są prostymi zamiennikami detektora o stałych klasach i tym samym budżecie obliczeń; jakość promptu, opóźnienie i koszty nadal wymagają oceny.

Kiedy wybrać YOLO26, a kiedy pozostać przy innym rozwiązaniu

YOLO26 jest rozsądnym kandydatem do nowego projektu, gdy potrzebujemy szybkiej lokalizacji znanych kategorii i potrafimy zebrać reprezentatywne dane. Zaczęlibyśmy od małego wariantu, prostego rozwiązania referencyjnego oraz przynajmniej jednego konkurencyjnego detektora. Porównanie powinno obejmować końcowy runtime i warunki pracy, a nie wyłącznie notebook.

Działającego YOLO11 lub YOLOv8 nie trzeba wymieniać dlatego, że pojawił się następca. Migracja ma sens, jeśli poprawia konkretny wynik: wykrywalność istotnych obiektów, zużycie zasobów, opóźnienie lub koszt utrzymania. Powinna też zachować zachowanie trackera, progów i eksportu po ponownej walidacji. Stabilny detektor z dobrze poznanymi błędami jest wartościowym punktem odniesienia.

Wybierzmy inne podejście, gdy pytanie dotyczy tekstu, swobodnego opisu sceny, precyzyjnej metrologii albo prostego kontrastu na kontrolowanym tle. Najważniejszym wynikiem projektu nie jest wtedy nazwa modelu, lecz dowód, że system poprawnie rozpoznaje sytuację i podejmuje użyteczną decyzję. W naszym przykładzie oznacza to policzenie każdej sztuki raz, we właściwym kierunku i na czas.

Źródła

Wszystkie notatki →