TensorFlow jest biblioteką do budowania i trenowania modeli uczenia maszynowego. Decyzja o niej nie jest wyborem narzędzia programistycznego. Jest rozstrzygnięciem o tym, czy organizacja bierze na siebie odpowiedzialność za ocenę, którą od tej pory będzie wydawał model — razem z danymi, sprzętem i skutkami jego pomyłek.
Na skróty
Czego dowiesz się z artykułu:
- Jaki koszt organizacja ponosi na ocenach wydawanych ręcznie, zanim ktokolwiek wspomni o uczeniu maszynowym
- Jakie warunki muszą wystąpić razem, żeby własny model był właściwą odpowiedzią
- W jakich sytuacjach trenowanie własnego modelu nie odpowiada na realny problem
- Jakie alternatywy pozostają i jaką cenę niesie każda z nich
- Co organizacja podpisuje, utrzymując własny model na produkcji
Dla kogo ten artykuł:
- Kierownicy zespołów, w których ocena danych jest powtarzalną czynnością operacyjną
- Osoby odpowiadające za budżet analityki i automatyzacji
- Menedżerowie rozstrzygający między usługą gotową a rozwiązaniem własnym
Ile kosztuje ocena, którą ktoś wykonuje ręcznie i której reguły nie da się zapisać?
Rachunek zaczyna się od czynności, która wygląda niegroźnie: ktoś patrzy na dokument, zgłoszenie albo zdjęcie i rozstrzyga, do której kategorii to trafia. Czynność trwa chwilę i wraca setki razy w miesiącu. Nikt jej nie automatyzował, bo próba spisania reguły kończy się listą wyjątków dłuższą od samej reguły — a każdy wyjątek ma uzasadnienie, którego autor nie potrafi wypowiedzieć inaczej niż „bo tak wygląda”.
Do tego dochodzi koszt niewidoczny w żadnym zestawieniu: rozrzut ocen. Ta sama sprawa oceniona przez różne osoby dostaje różne rozstrzygnięcie, a przy większym nakładzie pracy różnica rośnie, bo rośnie zmęczenie. Organizacja nie ma z tego powodu awarii — ma powolne osuwanie się jakości, które ujawnia się dopiero w reklamacjach albo w audycie.
Problem ma odmiany, a ich pomylenie kosztuje najwięcej. Pierwsza odmiana to skala: reguła jest znana, ale liczba przypadków przerosła zespół. Druga to nieuchwytność reguły: przypadków jest niewiele, lecz nikt nie potrafi ich rozstrzygnięcia zapisać jako warunku. Trzecia to zmienność: reguła istnieje, ale przestaje pasować szybciej, niż zespół zdąży ją opisać. Rozstrzygnięcie nie zależy od tego, jak zaawansowane technicznie jest środowisko organizacji — zależy od tego, którą z tych odmian faktycznie ponosi.
Kiedy własny model uczenia maszynowego jest właściwą odpowiedzią?
Trenowanie własnego modelu jest właściwą odpowiedzią wtedy, gdy występują razem trzy warunki, a nie gdy spełniony jest którykolwiek z nich osobno:
- Organizacja ma własne, opisane dane historyczne. Przypadki z zapisaną decyzją, którą ktoś kiedyś podjął, w liczbie odpowiadającej skali problemu. Bez tego nie ma czego uczyć, a zakup cudzego zbioru przenosi do modelu cudze rozstrzygnięcia razem z ich błędami.
- Rozstrzygnięcie zależy od wzorca, a nie od przepisu. Gdy decyzję da się zapisać jako warunek, warunek jest tańszy, szybszy i wytłumaczalny. Model ma sens tam, gdzie ludzie rozstrzygają na podstawie tego, co widzieli wcześniej.
- Ocena jest częścią procesu, który zostanie z organizacją na lata. Model wymaga obserwacji, ponownego uczenia i dyżuru; przy zadaniu jednorazowym ten koszt nigdy się nie zwróci.
Dopiero gdy te warunki występują łącznie, sensu nabiera praca nad samym modelem: architektura sieci, przygotowanie zbioru uczącego, kontrola przeuczenia i ocena wyniku miarą związaną z procesem, a nie z konkursem. Ten zakres — od podstaw uczenia głębokiego po samodzielne trenowanie modeli na własnych danych — obejmuje szkolenie Deep Learning z TensorFlow: od podstaw do zaawansowanych technik.
Kiedy tej technologii nie wybierać?
Najczęstszym błędem jest sięgnięcie po własny model dlatego, że temat jest obecny w rozmowach zarządu, zanim ktokolwiek nazwał ocenę, którą model ma wydawać. Organizacja dostaje wtedy projekt badawczy bez odbiorcy, a jego zamknięcie jest trudniejsze niż start, bo nie ma kryterium, wobec którego można by ogłosić porażkę.
Poza tym są sytuacje, w których trenowanie własnego modelu nie odpowiada na realny problem. Zadanie rozwiązane przez regułę nie wymaga uczenia — warunek napisany wprost jest tańszy w utrzymaniu, natychmiast wytłumaczalny i nie psuje się przy zmianie rozkładu danych. Decyzja obciążona wymogiem uzasadnienia wobec klienta, regulatora albo audytu stawia organizację przed obowiązkiem wyjaśnienia rozstrzygnięcia, którego model nie podaje sam z siebie; dołożenie warstwy wyjaśniającej jest osobnym projektem, a nie ustawieniem parametru. Zespół bez planu utrzymania modelu dostanie wynik, który działa na danych z okresu uczenia i cicho traci trafność później; model bez dyżuru nie zgłasza awarii, tylko myli się coraz częściej. Żadnej z tych sytuacji nie zmienia to, ile pracy włożono już w prototyp. Co konkretnie oznacza utrzymanie modelu po wdrożeniu, rozkłada tekst o MLOps w praktyce, od notatnika do produkcji.
Jakie są alternatywy i ile kosztują?
Usługa gotowa u dostawcy chmurowego daje wynik bez trenowania i bez sprzętu, a rozliczenie jest za użycie. Ceną jest brak wpływu na zachowanie modelu, opłata rosnąca z ruchem oraz dane opuszczające organizację — co przy informacjach objętych umową z klientem bywa rozstrzygające. Model dostawcy dostrojony na własnych przykładach jest drogą pośrednią: krótszy czas do wyniku, kosztem uzależnienia od cennika i cyklu wydawniczego, na który nikt w organizacji nie ma wpływu. Klasyczne metody statystyczne bywają najtańsze i najczęściej pomijane — wymagają mniej danych, tłumaczą się same i wystarczają wszędzie tam, gdzie zależność jest prosta, a przewaga sieci neuronowej byłaby niemierzalna.
Ostatnia droga bywa najtańsza z wszystkich: uporządkowanie danych i procesu, zanim ktokolwiek wybierze narzędzie. Zwykle to ona decyduje o powodzeniu pozostałych, bo model uczy się z tego, co organizacja o sobie zapisała. Od czego zacząć takie uporządkowanie, rozkłada omówienie strategii danych dla sztucznej inteligencji.
Co organizacja podpisuje, utrzymując własny model na produkcji?
Podpisuje przede wszystkim obowiązek obserwacji. Model nie psuje się jak usługa — nie przestaje odpowiadać, tylko odpowiada gorzej, w miarę jak rzeczywistość odchodzi od danych, na których się uczył. Bez pomiaru trafności na świeżych przypadkach nikt tego nie zauważy, dopóki skutki nie wyjdą po stronie klienta.
Podpisuje też cykl, którego nikt nie planuje przy wdrożeniu: ponowne uczenie, wersjonowanie zbiorów, porównanie nowej wersji ze starą i decyzję, kto ma prawo ją wypuścić. Najdroższą pozycją nie jest jednak sprzęt ani czas uczenia, tylko kompetencja po stronie zespołu — bez niej organizacja ma model, którego nie umie ani ocenić, ani wycofać. Rolą, która ten rachunek obniża, jest umiejętność prowadzenia modelu jak elementu systemu, a nie eksperymentu — czyli zakres szkolenia MLOps i CI/CD dla uczenia maszynowego. Bez tego organizacja płaci podwójnie: za zbudowanie modelu i osobno za każdą jego pomyłkę.
FAQ — najczęściej zadawane pytania
Ile danych trzeba mieć, żeby zacząć?
Pytanie postawione tak nie ma odpowiedzi liczbowej, bo zależy ona od trudności zadania i od tego, jak bardzo przypadki się od siebie różnią. Praktyczny test jest inny: czy organizacja ma zapisane rozstrzygnięcia z przeszłości i czy ktoś potrafi potwierdzić, że są poprawne. Zbiór bez wiarygodnych etykiet nie jest zbiorem uczącym.
Czy potrzebny jest własny sprzęt?
Do nauki i do pierwszych modeli zwykle nie — wynajem mocy obliczeniowej jest tańszy niż zakup i nie zamraża budżetu. Własny sprzęt zaczyna się opłacać dopiero przy stałym, przewidywalnym obciążeniu albo przy danych, których nie wolno wyprowadzić poza organizację.
Po czym poznać, że model przestał działać poprawnie?
Po rozjeździe między trafnością mierzoną na świeżych przypadkach a tą z okresu uczenia. Warunkiem jest jednak stałe zbieranie prawdziwych rozstrzygnięć po wdrożeniu; bez tego organizacja nie ma jak zauważyć spadku i dowiaduje się o nim od odbiorcy.