Jak przygotować dane treningowe do modeli AI, żeby wyniki miały sens biznesowy

Scenka otwierająca: model „idealny” na papierze, bezużyteczny w firmie

Model churnowy właśnie trafił na spotkanie z zarządem: dokładność wysoka, slajdy kolorowe, zespół data science dumny. Mija kwartał – handlowcy dalej dzwonią „na czuja”, retencja się nie poprawia, a do działu analityki wraca komunikat: „to wasze AI nic nie daje”. W raportach wszystko wygląda perfekcyjnie, w biznesie – zero zmiany.

Po kilku rozmowach wychodzi na jaw, że model przewiduje „ryzyko odejścia klienta” definiowane jako brak transakcji przez 30 dni. Problem w tym, że w tym biznesie od zawsze normalnym cyklem zamówień jest 45–60 dni, a część kluczowych klientów kupuje sezonowo. Dane treningowe zostały przygotowane z czysto techniczną definicją churnu, kompletnie oderwaną od realnego zachowania klientów i logiki przychodów.

Algorytm jako taki działał poprawnie: uczył się z tego, co dostał. Tyle że „prawda”, nad którą pracował, była źle zaprojektowana. Etykieta „odejście klienta” nie miała sensu biznesowego, a użyte cechy nie odzwierciedlały decyzji, jakie firma naprawdę podejmuje. Model zoptymalizowany pod ładne metryki w testach stał się drogą ciekawostką, bo dane treningowe nie były zakorzenione w realnym procesie decyzyjnym.

Sensowny model AI startuje nie od algorytmu, lecz od sensownie przygotowanych danych: takich, które wynikają z jasnej definicji problemu biznesowego, odzwierciedlają realne procesy i są zebrane w sposób powtarzalny. Bez tego każda, nawet najbardziej zaawansowana sieć neuronowa, będzie jedynie efektownym, ale bezużytecznym eksperymentem.

Od intencji biznesowej do pytania, na które odpowie model

Rozmowa z biznesem zamiast „strzelania” modelami

Większość nieudanych projektów AI zaczyna się od zdania: „chcemy coś z AI w sprzedaży/obsłudze/ryzyku”. Brakuje jednego kluczowego elementu: decyzji, która ma się realnie zmienić po wdrożeniu modelu. Dlatego pierwszym krokiem przy przygotowaniu danych treningowych jest rozmowa z właścicielami procesu, nie z bazą danych.

Podczas takiej rozmowy dobrze jest dopytać o bardzo konkretne kwestie:

• Jaką pojedynczą decyzję operacyjną ma wesprzeć model? (np. „którego klienta zadzwonić pierwszego?” zamiast ogólnego „zwiększyć sprzedaż”).
• Jak wygląda obecny sposób podejmowania tej decyzji? Kto ją podejmuje, na podstawie jakich sygnałów, w jakim narzędziu?
• Gdzie teraz pojawia się największy ból: strata czasu, pieniądza, frustracja klientów, ryzyko prawne?
• Jakie są obecne reguły „na czuja” (heurystyki) używane przez ludzi? One często wskazują, które cechy danych mogą być sensowne.

Ogólne hasło „AI w sprzedaży” trzeba przełożyć na pytanie w rodzaju: „którym leadom nie warto dzwonić w pierwszej kolejności, bo i tak nie odbiorą / nie kupią, więc marnujemy czas handlowca?”. Albo: „które zgłoszenia na helpdesku mają największe ryzyko eskalacji, jeśli nie obsłużymy ich w ciągu 2 godzin?”.

Drugim elementem jest świadome zarysowanie granicy problemu. Model nie musi przewidywać wszystkiego – ma robić jedną rzecz dobrze. Jeżeli budujesz model priorytetyzacji leadów, nie wciągaj na siłę tematu rekomendacji produktu, scoringu ryzyka i prognozy lifetime value. Każdy z tych problemów wymaga innego zestawu danych treningowych i innej definicji „prawdy”.

Dopiero na końcu rozmowy powinny paść liczby. Nie „accuracy”, tylko KPI biznesowe: dodatkowy przychód, oszczędzony czas pracy, obniżony koszt obsługi, zmniejszone ryzyko. Przykładowo:

• „Jeśli model obetnie 30% najgorszych leadów z kolejki, handlowcy odzyskają o 2 godziny dziennie każdy.”
• „Jeśli model poprawnie wyłapie 20% najbardziej problematycznych paczek, zredukujemy liczbę reklamacji o kilka tysięcy rocznie.”

Takie liczby później determinują, które metryki techniczne są naprawdę ważne (np. czułość vs precyzja, koszt false positive), a to z kolei wpływa na to, jak przygotować dane treningowe i jak zbalansować klasy.

Przekład na język danych

Gdy wiadomo, jaką decyzję ma zmienić model, czas przełożyć to na język kolumn, tabel i logów. Kluczowe pytanie brzmi: co musimy wiedzieć o obiekcie decyzyjnym w momencie decyzji, żeby rozstrzygnąć go lepiej niż dziś? Ten „moment” jest krytyczny przy budowaniu zbioru treningowego.

Przykład: model ma wskazywać, którym leadom NIE dzwonić jako pierwszym. Decyzja zapada w momencie, gdy lead wpada do CRM. Dane treningowe muszą więc zawierać wyłącznie informacje dostępne w tym momencie: źródło leada, kampanię, godzinę, prostą historię wcześniejszych kontaktów z tym klientem, parametry formularza. Wszystko, co wydarzyło się później (np. notatki handlowca, maile po pierwszym kontakcie), nie może wejść jako cecha do modelu, bo generowałoby nieszczelność czasową (data leakage).

Czas tworzy też naturalną ramę dla definicji etykiety. Jeżeli „sukcesem” jest zakup w ciągu 14 dni od pierwszego kontaktu, zbiór treningowy musi mieć wyraźnie zaznaczone, kiedy lead trafił do systemu i czy w ciągu kolejnych 14 dni kupił. To wymaga odpowiednich pól w danych (timestamp kontaktu, timestamp transakcji) oraz umiejętnego łączenia tabel z różnych systemów.

Na tym etapie wychodzą pierwsze ograniczenia: części rzeczy po prostu nie ma. Nie ma historii kontaktu z leadem sprzed migracji CRM. Nie ma jawnej informacji o tym, czy klient negocjował cenę. Nie ma danych o aktywności konkurencji. Dodatkowo część danych nie może być użyta, nawet jeśli kusi technicznie, bo narusza RODO lub zasady etyczne (np. wrażliwe dane osobowe, informacje o zdrowiu, pochodzeniu etnicznym, przekonaniach).

Porządnie postawione pytanie biznesowe automatycznie eliminuje wiele złych pomysłów na dane treningowe. Jeżeli celem jest decyzja w momencie przyjęcia zgłoszenia, to dane powstające po zamknięciu zgłoszenia (ocena satysfakcji, komentarze wewnętrzne) nie mogą być cechami wejściowymi – mogą za to posłużyć jako element etykiety („klient niezadowolony / zadowolony”).

Inwentaryzacja danych – z czym faktycznie startuje firma

Gdzie realnie są dane i w jakim stanie

Zanim do gry wejdą modele, trzeba wykonać mało efektowną, ale kluczową pracę: sprawdzić, jakie dane naprawdę istnieją i w jakiej są kondycji. Często okazuje się, że to, co opisane jest w dokumentacji, ma niewiele wspólnego z tym, co faktycznie znajduje się w bazach i plikach.

Typowe źródła danych do modeli AI w firmach to:

• systemy CRM (informacje o klientach, leadach, transakcjach handlowych),
• systemy transakcyjne (płatności, zamówienia, zwroty),
• helpdesk / ticketing (zgłoszenia, statusy, czas obsługi),
• arkusze Excela i pliki CSV trzymane przez poszczególne działy,
• skrzynki mailowe i systemy pocztowe,
• logi aplikacji, systemów webowych, call center.

Inwentaryzacja danych powinna odpowiedzieć na trzy proste pytania:

1. Kto kontroluje dostęp do poszczególnych zasobów (właściciel systemu, administrator, dział prawny)?
2. Jak wygląda proces uzyskania zgody na wykorzystanie danych do AI (szczególnie danych osobowych)?
3. Jaki jest rzeczywisty stan jakości: ile jest braków, duplikatów, błędów, nietypowych wartości?

Tu często pojawia się pierwsze poważne zderzenie z rzeczywistością. Pól wymaganych w systemie nikt nie pilnował, więc użytkownicy wpisywali „-” lub „xxx”, byle przejść dalej. Daty w niektórych systemach są przechowywane jako tekst, w innych jako liczby. Kody statusów transakcji zmieniały się kilka razy w ciągu ostatnich lat bez jednoznacznego logu zmian. To wszystko ma bezpośredni wpływ na jakość danych treningowych.

Minimalna „kontrola sanitarna” przed budową modelu powinna obejmować:

W tym miejscu przyda się jeszcze jeden praktyczny punkt odniesienia: SHAP i LIME: jak wyjaśniać predykcje modelu w języku zrozumiałym dla biznesu.

• sprawdzenie udziału braków (missing values) w kluczowych kolumnach,
• przegląd przykładowych rekordów z nietypowymi wartościami (np. ujemne kwoty, daty z przyszłości),
• identyfikację potencjalnych duplikatów (np. ten sam klient w CRM pod kilkoma ID),
• porównanie słowników wartości (kody statusów, typy zgłoszeń) między systemami.

Bez tego dane treningowe będą mieszaniną poprawnych informacji, błędów i losowych wartości ratunkowych, co wprost odbije się na zachowaniu modelu.

Mapa przepływu danych pod konkretne zadanie

Inwentaryzacja to dopiero początek. Kolejny krok to zbudowanie prostej mapy przepływu danych wokół konkretnego zastosowania modelu. Chodzi o to, by zrozumieć, jakie dane powstają, w jakim momencie procesu i jak trafiają do centralnych systemów.

W praktyce wygląda to jak schemat blokowy, w którym zaznaczasz:

• punkt startowy (np. wypełnienie formularza leada na stronie),
• kolejne kroki procesu (telefon, spotkanie, oferta, zamówienie),
• systemy zaangażowane na każdym etapie,
• kluczowe zdarzenia i pola danych, które muszą trafić do zbioru treningowego,
• miejsca, gdzie dane są przepisywane ręcznie lub „obejściami” (np. notatki w Excelu, maile prywatne).

Mapa powinna też wyraźnie rozróżniać dane operacyjne od danych raportowych. Dane operacyjne to te, które powstają „na żywo” w procesie (zdarzenia, logi, pojedyncze transakcje). Dane raportowe to różnego rodzaju agregaty, przeliczniki i wskaźniki tworzone później, często w hurtowni danych lub narzędziach BI.

Dla modelu predykcyjnego kluczowe są dane operacyjne – to one odzwierciedlają stan obiektu w konkretnym momencie. Dane raportowe są przydatne, ale z nimi trzeba uważać: wiele z nich jest liczona z użyciem przyszłej informacji (np. „klient aktywny w danym miesiącu”), co łatwo prowadzi do podcieku danych.

Mapa przepływu zwykle ujawnia wąskie gardła jakościowe: miejsca ręcznego wprowadzania danych, pola „opcjonalne”, które faktycznie są krytyczne, ale nikt ich nie wypełnia, czy „tymczasowe” obejścia procesów, działające w firmie od lat. Bez zrozumienia tych punktów trudno zbudować stabilny, powtarzalny pipeline danych treningowych.

Efekt takiej mapy jest często zaskakujący dla zarządu: okazuje się, że problemem nie jest ilość danych, lecz sposób ich zbierania. AI brutalnie obnaża słabości procesów operacyjnych, bo nagle każde niedociągnięcie w polu formularza staje się błędem w zbiorze treningowym.

Projekt etykiety: co jest „prawdą”, którą ma naśladować model

Definicja zdarzenia docelowego (label)

Dane wejściowe można zawsze jakoś „posprzątać”. Jeżeli jednak sama etykieta – „prawda”, którą ma naśladować model – jest źle zdefiniowana, cała konstrukcja traci sens. To jeden z najczęściej bagatelizowanych, a zarazem najważniejszych elementów przygotowania danych treningowych.

Pierwsza decyzja: co konkretnie oznacza „sukces” i „porażka” dla danego modelu? W modelu churnowym może to być:

• brak transakcji przez 90 dni u klienta, który zwykle kupuje co 30–60 dni,
• złożenie wypowiedzenia umowy,
• przejście klienta do innego segmentu (np. obniżenie planu z premium na basic).

Każda z tych definicji prowadzi do innego zbioru etykiet. Źle dobrane okno czasowe potrafi diametralnie zmienić obraz rzeczywistości. Jeżeli uznasz, że churn to brak transakcji przez 30 dni w biznesie, gdzie naturalny cykl zakupowy jest dłuższy, to większość aktywnych klientów będzie dla modelu „odchodząca”.

Drugim aspektem jest okno obserwacji. Etykieta „1” (zdarzenie wystąpiło) i „0” (zdarzenie nie wystąpiło) muszą mieć jasno określony horyzont czasowy. Przykład:

• Lead jest „skonwertowany” (1), jeśli w ciągu 14 dni od pierwszego kontaktu pojawi się zamówienie.
• Lead jest „nieskonwertowany” (0), jeśli minie 30 dni bez zamówienia – dla zachowania buforu bezpieczeństwa.

Dzięki takiej definicji unikasz przypadków „w zawieszeniu” i wiesz, kiedy możesz budować zbiór treningowy bez obawy, że część etykiet dopiero się zmieni.

Rozmyte etykiety i szara strefa przypadków „pomiędzy”

Podczas pierwszego warsztatu z biznesem wszystko wydawało się jasne: „sukces sprzedaży” to wygrana szansa w CRM. Dopiero gdy analityk wyciągnął losowe rekordy, wyszło, że połowa „przegranych” to w praktyce odłożone decyzje, a część „wygranych” nigdy nie przeszła w realną fakturę. Model miał uczyć się świata, którego nawet ludzie nie nazywali spójnie.

W niemal każdym procesie istnieje szara strefa przypadków „pomiędzy” klasycznym 0 i 1. Przykładowo:

• lead, który nie kupił w 14 dni, ale kupił w 6. tygodniu po kontakcie,
• reklamacja, która została formalnie zamknięta, ale klient ponownie zgłosił się po tygodniu z tym samym problemem,
• umowa, którą klient wypowiedział, lecz po kilku dniach wycofał rezygnację.

Jeżeli takie przypadki zostaną wrzucone losowo do kategorii „sukces” lub „porażka”, model będzie miał chaotyczny sygnał. Z zewnątrz wszystko będzie wyglądało poprawnie (etykieta jest, status jest, pipeline się buduje), ale decyzje modelu zaczną być nieprzewidywalne w kluczowych, granicznych sytuacjach.

Praktyczny sposób radzenia sobie z szarą strefą to jawne wprowadzenie trzeciej kategorii, np. „niejednoznaczne” lub „do wykluczenia”. W zależności od wolumenu danych można:

• wykluczyć te rekordy ze zbioru treningowego (mniej danych, ale czyściej),
• zostawić je, ale tylko do walidacji jakości etykiet czy audytu procesu,
• zbudować osobny model dla „pomiędzy” (np. model czasu do zakupu, zamiast prostej klasyfikacji).

Kluczowe, by decyzja o tym, co ląduje w szarej strefie, była jasno opisana i uzgodniona z biznesem. Inaczej co kwartał ktoś zmieni interpretację i nagle model, który „wczoraj działał”, dziś wydaje się bezwartościowy, chociaż matematycznie się nie zmienił – zmieniła się tylko definicja prawdy.

Źródło prawdy: z jakiego systemu bierzemy etykietę

W jednej firmie status transakcji był w trzech miejscach: w systemie sprzedażowym, w księgowości i w narzędziu do fakturowania. Na pytanie „gdzie jest prawda o tym, czy transakcja doszła do skutku?” trzy działy wskazały trzy różne systemy. Każdy z nich był „prawdziwy”, ale dla innej perspektywy.

Dla modelu AI trzeba wybrać jedno źródło prawdy dla etykiety. Jeśli etykietą jest „kupiono / nie kupiono”, to:

• dla działu sprzedaży „kupiono” to często podpisanie umowy,
• dla księgowości „kupiono” to zaksięgowana płatność,
• dla działu operacji „kupiono” to wykonanie usługi lub wysyłka towaru.

Każda z tych definicji jest biznesowo sensowna, ale prowadzi do innego zbioru etykiet, innych dat granicznych i innego wolumenu „sukcesów”. Zanim powstaną skrypty budujące zbiór, trzeba ustalić:

• z jakiego systemu pochodzi status,
• jaki konkretny kod / pole / kombinacja pól oznacza „1”, a jaki „0”,
• co robimy, gdy statusy się nie zgadzają (np. sprzedano, ale płatność nie przeszła).

Dobrą praktyką jest spisanie krótkiego „kontraktu etykiety” w prostym dokumencie: jednoznaczny opis słowny, wskazanie tabel i pól, przykłady rekordów z każdej kategorii. To później ratuje projekty, gdy po roku ktoś wraca do modelu i próbuje go odtworzyć w nowej wersji systemu.

Czas jako ukryty wymiar etykiety

W jednej z sieci retail analitycy dziwili się, że model „świetnie trafia” w ocenę rentowności klientów historycznych, a dużo gorzej dla nowych. Po dokładniejszym sprawdzeniu wyszło, że etykieta rentowności była liczona na podstawie rocznego przychodu, ale do treningu brała pod uwagę klientów obserwowanych w różnych długościach czasu. Dla jednych etykieta oznaczała 12 miesięcy, dla innych 3–4.

Etykieta to nie tylko 0/1, ale także okres, za który ją obserwujemy. Dwa kluczowe pytania:

1. Jak długo trzeba czekać, żeby z sensowną pewnością stwierdzić, czy zdarzenie nastąpiło?
2. Jakie są naturalne cykle biznesu (zakupowe, rozliczeniowe, sezonowe), które wpływają na ten czas?

Dla produktów subskrypcyjnych etykietę churnu często ustawia się na granicy cyklu rozliczeniowego (np. 1–2 miesiące po planowej dacie odnowienia). Dla zakupu dóbr trwałych – na kilka, a nawet kilkanaście miesięcy. Jeżeli model ma działać „w czasie rzeczywistym”, trzeba zbudować etykietę w taki sposób, by dało się ją policzyć na danych sprzed określonego czasu, nie podglądając przyszłości.

Dobrym testem jest symulacja: bierzesz dane sprzed roku i udajesz, że jesteś wtedy. Sprawdzasz, czy na podstawie dostępnych w tamtym momencie pól da się jednoznacznie przypisać etykietę zgodną z przyjętą definicją. Jeżeli nie – definicja jest zbyt ambitna lub opiera się na danych, których model w realnym czasie nie zobaczy.

Etykieta a interwencja człowieka: kiedy model uczy się własnego wpływu

W projektach, gdzie model ma wspierać działania ludzi (sprzedaż, windykacja, obsługa klienta), etykieta bardzo często odzwierciedla efekt wspólnej pracy człowieka i systemu. To rodzi subtelny problem: jeżeli w przeszłości najlepsi handlowcy ręcznie wybierali sobie „łatwe” leady, a trudne omijali, etykiety sukcesu są silnie uzależnione od tego wyboru, a nie tylko od cech leada.

Widać to dobrze przy modelach:

• priorytetyzacji leadów – leady, do których nikt nie zadzwonił, są oznaczone jako „porażka”, choć nikt im nie dał szansy,
• rekomendacji akcji windykacyjnych – tam, gdzie interweniował doświadczony negocjator, sukces jest częstszy niezależnie od charakterystyki sprawy,
• kolejkowania zgłoszeń – szybciej obsługiwane zgłoszenia wyglądają „łatwiejsze”, choć wcale takie nie były.

Jeżeli etykieta bezrefleksyjnie traktuje brak akcji człowieka jako „porażkę”, model zacznie „karać” segmenty klientów, których po prostu dotychczas nikt nie obsługiwał z braku zasobów. To przykład, jak historyczne decyzje operacyjne zakrzywiają „prawdę” dla AI.

Rozwiązania bywają różne, ale kilka prostych zabiegów pomaga ograniczyć zniekształcenia:

• oznaczenie, czy lead był w ogóle obsłużony (min. 1 kontakt), i rozważenie trenowania modelu tylko na tej podgrupie,
• oddzielne modele dla różnych kanałów lub poziomów doświadczania zespołu (np. nowi handlowcy vs seniorzy),
• analiza wpływu liczby interakcji na sukces i ewentualne wprowadzenie jej jako cechy kontrolnej lub kryterium filtracji.

Im bardziej decyzja człowieka wpływa na powstanie etykiety, tym bardziej trzeba uważać, by model nie utrwalał starych uprzedzeń, tylko realne sygnały z danych.

Pułapki etyczne i regulacyjne w definicji etykiety

W jednym z projektów scoringu klientów dział compliance zablokował pierwszą wersję etykiety, bo „ryzyko kredytowe” opierało się na wewnętrznych listach obserwacyjnych, które nie miały wystarczającej podstawy prawnej do takiego użycia. Technicznie wszystko działało; problemem była definicja prawdy, której model miał się uczyć.

Definiując etykietę, trzeba uwzględnić nie tylko biznes i dane, lecz także ramy prawne i etyczne. Ryzykowne obszary to zwłaszcza:

• modele dotyczące zdolności kredytowej, ubezpieczeń, zatrudnienia, oceny wiarygodności,
• wszelkie predykcje dotyczące zdrowia, dobrostanu, zachowań „ryzykownych”,
• systemy rekomendacji, które mogą pośrednio dyskryminować grupy klientów.

Jeżeli etykieta powstaje na bazie danych, których nie wolno użyć w danym kontekście (np. części danych z rejestrów publicznych, historii sporów sądowych, wewnętrznych czarnych list), model może być niezgodny z regulacjami, nawet jeśli wejściowe cechy wyglądają „czysto”. Prawo i audyt patrzą nie tylko na to, co model widzi, ale też na to, czego uczy się w tle.

Dobrym zwyczajem jest wspólne przejście definicji etykiety z działem prawnym i compliance – zanim powstaną zbiory treningowe. Krótka sesja „rozbioru etykiety na czynniki pierwsze” często wyłapuje potencjalne konflikty zanim firma zainwestuje miesiące pracy w coś, czego i tak nie można produkcyjnie zastosować.

Jak testować jakość etykiet zanim zaczniesz trenować modele

W pewnej firmie logistycznej zespół przez kilka tygodni optymalizował architekturę modelu opóźnień dostaw. Gdy w końcu ktoś zestawił losowe zamówienia z przypisanymi etykietami i ręczną oceną eksperta operacyjnego, wyszło, że ponad 20% etykiet „dostarczono na czas” było w praktyce spóźnionymi przesyłkami – tyle że w systemie nikt nie aktualizował statusu.

Zanim do gry wejdą zaawansowane algorytmy, można zastosować kilka prostych testów jakości etykiet:

• Próbkowanie eksperckie – losujesz kilkadziesiąt / kilkaset rekordów, pokazujesz osobom z biznesu i prosisz: „jak byś to zaklasyfikował?”. Porównujesz z etykietą z systemu.
• Test spójności między systemami – dla reprezentatywnej próbki sprawdzasz, czy ten sam przypadek ma tę samą klasyfikację w różnych źródłach (CRM, billing, helpdesk).
• Analiza rozkładów – patrzysz, czy rozkład etykiety w czasie i w segmentach ma sens (np. czy nagle nie ma +50% „porażek” w miesiącu migracji danych).
• Diff historyczny – jeżeli jest dostęp do logów zmian, analizujesz, jak często i dlaczego zmienia się status, który służy jako etykieta.

Jeżeli już na tym etapie widać niepokojące sygnały (duże rozbieżności z oceną ekspercką, skoki w czasie niezwiązane z biznesem, chaos w zmianach statusu), lepiej wrócić do definicji etykiety niż próbować „wyregulować” wszystko architekturą modelu. Model tylko wzmocni to, co jest w danych – jeżeli w etykiecie jest bałagan, dostaniemy elegancko uśredniony bałagan na wyjściu.

Etykieta a metryki sukcesu: czy model mierzymy tym samym, czego go uczymy

W jednej organizacji model oceniał leady jako „gorące”, „ciepłe” i „zimne”, ucząc się na etykiecie „czy pojawiło się zamówienie w 30 dni”. Zarząd jednak rozliczał projekt z tego, czy rośnie marża roczna na kliencie. Te dwa światy nie były spójne – model optymalizował krótki horyzont, a biznes patrzył na długi.

Na styku celów biznesowych i danych technicznych zaczyna się to, co często opisuje się jako „data literacy” w organizacji. Wiele firm, korzystając z materiałów takich jak więcej o informatyka, dopiero buduje most między językiem zarządu a praktyką danych, a jakość tego mostu wprost przekłada się na jakość zbioru treningowego.

Etykieta to techniczne ucieleśnienie tego, co chcesz maksymalizować lub minimalizować. Jeżeli tym, co naprawdę liczy się dla firmy, jest:

• marża, a nie sam przychód,
• długość relacji z klientem, a nie pojedyncza transakcja,
• liczba zgłoszeń reklamacyjnych, a nie tylko czas pierwszej odpowiedzi,

to właśnie te wielkości (lub ich rozsądne przybliżenia) powinny być punktem odniesienia dla etykiety. W przeciwnym razie model będzie „dobry” według metryk technicznych (accuracy, AUC, F1), ale słaby biznesowo, bo optymalizuje nie to, co trzeba.

Spójność etykiety z metrykami biznesowymi można zweryfikować na prostym ćwiczeniu: dla kilku rzeczywistych przypadków, znanych z życia firmy (konkretnych klientów, spraw, zgłoszeń), zespół biznesowy ocenia, czy dany przypadek był „sukcesem” według ich intuicji i KPI. Następnie porównuje się to z etykietą zdefiniowaną na potrzeby modelu. Jeżeli rozbieżności są częste, definicję trzeba skorygować, nawet jeśli z technicznego punktu widzenia wydaje się elegancka.

Automatyzacja tworzenia etykiet: od jednorazowego projektu do stałego procesu

W wielu firmach pierwsza wersja zbioru treningowego powstaje w trybie „jednorazowego heroizmu”: analityk klei kilka skryptów SQL, trochę Pythona, spina systemy i po tygodniach pracy wypluwa plik CSV z etykietami. Model powstaje, robi dobre wrażenie, a po kilku miesiącach pojawia się prośba: „zaktualizujmy go na nowych danych”. I wtedy wszyscy odkrywają, że nikt nie zapisał dokładnie, jak były tworzone etykiety.

Jeżeli model ma żyć dłużej niż jeden pilotaż, generowanie etykiet musi być procesem powtarzalnym. Kilka elementów decyduje, czy to się uda:

• skrypty budujące etykietę trzymane w repozytorium kodu (Git), a nie w prywatnym notatniku analityka,

Versioning etykiet i cech: ten sam model, inne dane, inne wnioski

Po roku od wdrożenia modelu churnu w dużej firmie SaaS zespół analityczny zauważył, że skuteczność dramatycznie spadła. Po długim śledztwie wyszło, że „churn” w raporcie finansowym zaczął znaczyć coś innego niż rok wcześniej, a skrypty do budowy etykiet zostały cicho zmodyfikowane podczas zmiany billingowego systemu.

To częsty scenariusz: biznes redefiniuje pojęcia, systemy zmieniają pola, raporty dostosowują się do nowych potrzeb, a modele dalej uczą się „po staremu” lub – co gorsza – na miksie starych i nowych definicji. Bez jawnego versioningu etykiet i cech trudno potem zrozumieć, czemu nowy retraining nie jest porównywalny z poprzednim.

Przy budowaniu danych treningowych dobrze jest przyjąć kilka prostych zasad, które narzucają porządek:

• każda istotna zmiana definicji etykiety (logika SQL, progi czasowe, progi wartości) dostaje numer wersji i opis „co, kiedy, dlaczego”,
• to samo dotyczy cech wejściowych – jeśli zmienia się sposób liczenia „aktywności klienta”, warto oznaczyć, który model korzystał z której wersji,
• w metadanych eksperymentu modelowego zapisuje się: wersję etykiety, wersję zbioru cech, zakres czasowy danych, listę wykluczeń (np. „bez okresu lockdownu”).

Dzięki temu porównanie modeli „v1 vs v2” naprawdę znaczy porównanie algorytmów, a nie definicji prawdy. Wiele kryzysów z „magicznie pogorszonym” modelem okazywało się w praktyce zmianą etykiety w tle.

Logika czasowa: jak nie pozwolić modelowi oszukiwać na etykiecie

Analityk uruchomił szybki prototyp modelu predykcji rezygnacji klienta. Wyniki – bajka, AUC blisko ideału. Dopiero po chwili okazało się, że jedna z cech, „data zgłoszonej rezygnacji”, trafia do zbioru treningowego razem z etykietą „czy klient zrezygnował w ciągu 30 dni”. Model po prostu czytał przyszłość.

Problem wycieków czasowych (data leakage) jest bardziej podstępny niż pojedyncze oczywiste przypadki. Często wynika właśnie z tego, jak budowana jest etykieta i jakie okna czasowe są przy niej stosowane. Jeżeli etykieta mówi „co stało się w ciągu 60 dni od wydarzenia X”, to:

• cechy muszą być policzone wyłącznie z informacji dostępnych przed wydarzeniem X,
• w etl-u budującym featury trzeba twardo przyciąć daty (np. „bierzemy dane do dnia X-1, 23:59”),
• dane agregowane miesięcznie lub tygodniowo muszą mieć jasne okna (np. „poprzednie pełne 3 miesiące”).

Dobrym testem sanity check jest przejście krok po kroku po jednym rekordzie: „na jaką datę robimy predykcję, co klient mógł wtedy już ‘zostawić’ w systemach, a czego jeszcze nie było?”. Jeżeli w featurach pojawiają się pola uzupełniane dopiero po zdarzeniu docelowym (np. powód rezygnacji, status windykacji), to znak, że definicja cech jest sprzeczna z definicją etykiety.

Modele działające w produkcji żyją w konkretnym czasie. Dane treningowe muszą ten czas symulować. Bez tego mamy świetne wyniki na testach i bardzo słabe w realnym świecie.

Balans klas i reprezentatywność: kiedy etykieta jest rzadkim zjawiskiem

W firmie e‑commerce model miał przewidywać fraudy płatnicze. W danych historycznych oszustwa stanowiły ułamek promila wszystkich transakcji. Model trenowany „po bożemu” z oryginalnym rozkładem etykiety nauczył się sprytnej strategii: zawsze przewiduj „brak fraudu” i ciesz się gigantyczną dokładnością.

Gdy etykieta opisuje rzadkie zjawisko (fraud, poważna reklamacja, duża utrata klienta, „whale” w grach), czysta statystyka przestaje działać na naszą korzyść. Zanim zacznie się eksperymenty z algorytmami, opłaca się przyjrzeć dwóm podstawowym rzeczom:

• proporcjom klas – ile jest „jedynek” do „zer”? przy skrajnych dysproporcjach zwykłe metryki (accuracy) przestają mieć sens,
• spójności „pozytywnych” przypadków – czy wszystkie fraudy są podobne, czy mamy mieszankę zupełnie różnych scenariuszy pod tą samą etykietą.

Jeżeli etykieta jest bardzo rzadka, trzeba zdecydować, jak sztucznie „wyciągnąć ją na wierzch”, nie tracąc sensu biznesowego. Kilka praktycznych zabiegów:

• nadpróbkowanie klasy pozytywnej (np. wszystkie fraudy + losowa próbka niefraudów, a nie pełen zbiór),
• sensowne undersampling klasy negatywnej (np. pełne pokrycie rzadkich segmentów, mniej przypadków z głównych, oczywistych grup),
• segmentacja etykiety – osobne modele dla różnych typów fraudu zamiast jednego modelu dla „wszystkich razem”.

Każda z tych decyzji podważa czystą statystykę, ale wzmacnia sens biznesowy. Model ma pomóc złapać realne, kosztowne przypadki, a nie maksymalizować eleganckie metryki na zbalansowanym, lecz sztucznym zbiorze.

Przecięcie etykiety segmentami: różne prawdy dla różnych grup

W firmie telekomunikacyjnej ta sama etykieta „odejście klienta w 90 dni” miała zupełnie inne znaczenie w segmencie pre-paid i w biznesie kontraktowym. Dla pre-paida „odejście” bywało zwykłym brakiem doładowania na wakacjach, dla kontraktów – często świadomą decyzją po złym doświadczeniu serwisowym.

Ta sama definicja etykiety w różnych segmentach może więc opisywać inne zjawiska. Dla danych treningowych oznacza to jedno: warto rozcinać etykietę po sensownych wymiarach i sprawdzać, czy nie kryją się pod nią różne światy. Typowe wymiary to:

• typ klienta (B2B vs B2C, klienci masowi vs VIP),
• kanał pozyskania (online, sprzedaż terenowa, partnerzy),
• produkt lub pakiet usług, który dominuje w relacji.

Jeżeli po takim rozcięciu widać, że etykieta zachowuje się zupełnie inaczej (inne częstotliwości, inne wzorce w czasie, inne typowe ścieżki klientów), lepiej rozważyć osobne modele lub przynajmniej osobne warstwy logiki dla segmentów. Jeden „uniwersalny” model z jedną etykietą często jest wygodny dla zespołu technicznego, ale zupełnie nieczytelny dla biznesu.

Konsekwencją takiego podejścia jest też uczciwsza komunikacja: zamiast jednego „prawdopodobieństwa odejścia” można pokazać „prawdopodobieństwo odejścia w segmencie A wg definicji X”. Mniej marketingowo, ale znacznie bardziej zrozumiale dla osób, które operacyjnie korzystają z predykcji.

Etykieta w środowisku wielomodelowym: gdy definicji prawdy jest kilka

W średniej wielkości banku powstały trzy modele związane z klientem detalicznym: predykcja churnu, propensity to buy dla cross-sellu i model wartości życiowej klienta. Każdy zespół liczył „aktywnych klientów” trochę inaczej, bo każdy miał inną etykietę i swoje potrzeby analityczne.

W praktyce coraz więcej firm ma nie jeden, ale kilkanaście lub kilkadziesiąt modeli, które dotykają tego samego obszaru biznesowego. Jeżeli dla każdego z nich definicje etykiet i bazowe pojęcia („aktywny klient”, „wniosek złożony”, „fraud potwierdzony”) są budowane oddzielnie, powstaje analityczny chaos:

Do kompletu polecam jeszcze: Kiedy wolno użyć cudzej grafiki i fontów w aplikacji? Praktyczny przewodnik dla devów — znajdziesz tam dodatkowe wskazówki.

• raporty z modeli nie dają się łatwo porównać między sobą,
• zespoły dyskutują, kto „ma rację”, zamiast rozmawiać o akcjach biznesowych,
• każda zmiana definicji w jednym modelu nie jest przenoszona do innych.

Rozwiązaniem jest zbudowanie małego „słownika prawd” – wspólnej warstwy semantycznej, gdzie najważniejsze etykiety i ich operacyjne definicje są spisane, zcentralizowane i wersjonowane. Modele odwołują się wtedy do wspólnych definicji, zamiast każdy po swojemu odkrywać Amerykę.

W praktyce często oznacza to osobny moduł w hurtowni danych lub warstwę „feature store”, gdzie nie tylko cechy, ale i kluczowe etykiety są przygotowywane według uzgodnionych reguł. Techniczny narzut jest niewielki, a oszczędza miesiące dyskusji „czemu nasz churn jest inny niż churn z modelu kolegów”.

Granica między etykietą a regułami biznesowymi: co zostawić ludziom

W jednym z projektów scoringu leadów dział sprzedaży uparł się, by „wszystkich obecnych klientów strategicznych” zawsze traktować jako gorące leady, niezależnie od historii. Zespół ML dodał więc do etykiety ręczną korektę: jeśli klient jest strategiczny, to etykieta sukcesu jest zawsze 1. Model nauczył się błyskawicznie, że „strategiczny = super”. W praktyce zaburzyło to całe rozumienie, co naprawdę napędza sukces sprzedaży.

Etykieta ma odzwierciedlać prawdę o świecie, nie decyzje polityczne czy preferencje konkretnej grupy interesariuszy. Oczywiście są sytuacje, w których pewne reguły biznesowe muszą pozostać poza modelem – np. zakaz oferowania danego produktu określonym grupom z przyczyn regulacyjnych. Kluczowe jest jednak, by rozróżnić:

• co ma być „prawdą”, której model się uczy (np. które leady realnie kończą się sprzedażą z dobrą marżą),
• a co ma być dodatkowym filtrem lub priorytetem nakładanym po predykcji (np. „strategiczni klienci zawsze trafiają do top kolejki, niezależnie od wyniku modelu”).

Jeśli wciśniemy drugą kategorię do etykiety, model staje się narzędziem do reprodukowania decyzji politycznych, a nie do odkrywania sygnałów w danych. Zdrowym kompromisem bywa:

• trenowanie modelu na „czystej” etykiecie,
• zdefiniowanie warstwy post-processingu, gdzie wynik modelu jest łączony z regułami biznesowymi,
• jawne raportowanie, jaka część decyzji wynika z modelu, a jaka z „twardych” reguł.

To porządkuje dyskusję: jeśli wynik nie jest po myśli któregoś działu, jasne jest, czy chodzi o sam model, czy o reguły poza nim.

Związek etykiety z interfejsem użytkownika: jak dane treningowe rodzą zachowania ludzi

W organizacji call center pojawił się model sugerujący priorytet zgłoszeń. Po kilku miesiącach etykieta „rozwiązano w 1. kontakcie” zaczęła się poprawiać, ale pracownicy zgłaszali, że system „pcha” ich w prostsze sprawy, a trudniejsze zostają na koniec dnia. Model, ucząc się na historycznej etykiecie, w połączeniu z interfejsem stworzył nowe, nieplanowane zachowanie.

Projektując etykietę, opieramy się na przeszłości. Ale po wdrożeniu modelu zaczynamy tę przyszłość zmieniać. Jeżeli interfejs użytkownika (CRM, panel windykatora, aplikacja sprzedawcy) silnie opiera się na wyniku modelu, ludzie zaczną w jego rytmie układać swoją pracę. Kilka praktycznych pytań, które dobrze zadać, zanim dane treningowe zostaną wylane w produkcję:

• czy etykieta nie nagradza zbyt prostych sukcesów (np. krótkich, łatwych zgłoszeń) kosztem długoterminowego efektu (jakości obsługi trudnych spraw),
• czy interfejs nie „zamyka” ludzi w wąskiej pętli – podaje im tylko to, co model uważa za „łatwe” lub „opłacalne”, przez co dane o innych przypadkach przestają napływać,
• czy przewidziano mechanizmy eksploracji (np. losowy przydział części przypadków), które pozwalają modelowi zobaczyć także te rejony, których wcześniej nie obsługiwano.

Dane treningowe z kolejnych miesięcy będą odzwierciedleniem nie tylko zachowań klientów, lecz przede wszystkim reakcji ludzi na podpowiedzi modelu. Jeżeli etykieta premiuje tylko krótkoterminową wygodę, nowa iteracja modelu będzie jeszcze silniej ciągnąć organizację w tę stronę.

Etykieta a zmieniający się świat: jak radzić sobie z przesunięciem kontekstu

Firma z branży eventowej zbudowała przed pandemią świetny model prognozujący frekwencję na wydarzeniach. Po kilku miesiącach globalnych ograniczeń wszystkie jego predykcje stały się całkowicie oderwane od rzeczywistości. Etykieta „czy klient pojawi się na wydarzeniu” przestała znaczyć to samo – decyzja klienta była zdominowana przez czynniki zewnętrzne.

Dynamiczne otoczenie wymusza regularne zadawanie pytania: czy etykieta wciąż opisuje to samo zjawisko biznesowe, co rok temu? Zmiany regulacyjne, nowe produkty, nietypowe zdarzenia (lockdowny, kryzysy, zmiany kanałów sprzedaży) mogą sprawić, że dane historyczne zaczną reprezentować zupełnie inny świat. Kilka zdroworozsądkowych praktyk:

• oznaczanie w danych okresów „niereprezentatywnych” (np. ekstremalne lockdowny, migracje systemów, kampanie jednorazowe) i możliwość ich wykluczenia z treningu,
• analiza „driftu etykiety” – jak zmienia się częstość pozytywnej klasy w czasie i segmentach, czy nie ma przełomowych punktów,

Najczęściej zadawane pytania (FAQ)

Jak zacząć przygotowanie danych treningowych pod AI od strony biznesu, a nie technicznej?

Typowy scenariusz wygląda tak: zarząd mówi „zróbmy coś z AI”, a zespół techniczny od razu szuka algorytmu i danych. Po kilku miesiącach powstaje model, który świetnie działa w raportach, ale nikt go realnie nie używa, bo nie wspiera żadnej konkretnej decyzji w procesie.

Start powinien wyglądać odwrotnie: najpierw jedno precyzyjne pytanie o decyzję, która ma się zmienić (np. „kogo powinienem obdzwonić jako pierwszego rano?”), potem opis obecnego sposobu podejmowania tej decyzji i bólu z nią związanego. Dopiero z tego wyciąga się wymagane KPI biznesowe (oszczędzony czas, mniej reklamacji, więcej przychodu), a następnie przekłada je na wymagania wobec danych treningowych i metryk technicznych.

Jak zdefiniować etykietę (target) w modelu AI, żeby miała sens biznesowy?

Najczęstszy błąd: ktoś technicznie „przycina” dane i mówi, że churn to brak transakcji przez 30 dni, bo tak łatwo policzyć w SQL-u. Potem okazuje się, że normalny cykl zakupowy w tej branży to 60 dni, a kluczowi klienci kupują sezonowo – więc model przewiduje fikcyjny problem, a nie realne odejście.

Żeby etykieta miała sens biznesowy, musi wynikać z realnego procesu i sposobu zarabiania pieniędzy. W praktyce oznacza to rozmowę z właścicielami procesu o tym, co faktycznie uznajemy za sukces/porażkę (np. „zakup w ciągu 14 dni od pierwszego kontaktu”, „zgłoszenie, które eskaluje do drugiej linii”) oraz jakie są naturalne ramy czasowe tego zjawiska. Dopiero na tej podstawie buduje się definicję etykiety i wybiera dane, które pozwolą ją policzyć.

Jakie dane mogę wykorzystać do trenowania modelu, a jakich lepiej nie ruszać?

W praktyce przydatne okazują się dane z codziennych systemów operacyjnych: CRM, systemów transakcyjnych, helpdesku, logów aplikacji czy nawet prostych excelowych „tabelek działowych”. To z nich zwykle da się wyciągnąć informacje o zachowaniach klientów, historii kontaktu, czasach reakcji czy statusach zgłoszeń.

Są też dane, których lepiej nie używać, nawet jeśli technicznie kuszą: dane wrażliwe (zdrowie, przekonania, pochodzenie) oraz wszystko, co może łamać RODO lub lokalne regulacje. Dodatkowo nie powinno się podawać modelowi informacji, które powstają po momencie podejmowania decyzji (np. notatka handlowca po spotkaniu), bo prowadzi to do nieszczelności czasowej i nienaturalnie „przewidującego przyszłość” modelu, który rozsypuje się po wdrożeniu.

Jak uniknąć data leakage (nieszczelności czasowej) przy budowie zbioru treningowego?

Klasyczna historia: model scoringu leadów osiąga fantastyczne wyniki, ale w produkcji traci moc. Po chwili analizy wychodzi, że w cechach znalazły się dane, które w realnym życiu są znane dopiero po podjęciu decyzji – na przykład wynik pierwszej rozmowy z klientem albo informacje z późniejszych etapów procesu sprzedaży.

Bezpieczne podejście jest proste: definiujesz konkretny „moment decyzji” (np. przyjęcie leada do systemu, rejestracja zgłoszenia, złożenie zamówienia) i do modelu dopuszczasz wyłącznie dane, które w tym momencie są już znane. Wszystko, co powstaje później, może trafić tylko do etykiety (czy doszło do zakupu, czy zgłoszenie eskalowało), ale nigdy jako cecha wejściowa.

Jak sprawdzić, czy moje dane firmowe nadają się w ogóle na trening modeli AI?

Wiele firm odkrywa przy pierwszym projekcie AI, że to, co jest w dokumentacji systemu, nijak się ma do realnej zawartości baz. Pola „wymagane” są wypełnione myślnikami, daty przechowywane jako teksty, a statusy zmieniały się kilka razy bez archiwizacji.

Na start potrzebna jest prosta inwentaryzacja: lista głównych źródeł (CRM, systemy sprzedażowe, helpdesk, logi), informacja o właścicielach tych systemów i realna kontrola jakości danych (braki, duplikaty, sprzeczne wartości). Już ten „sanitarny przegląd” pokaże, gdzie da się budować sensowny zbiór treningowy, a gdzie najpierw trzeba naprawić podstawową higienę danych, zanim w ogóle pomyśli się o modelach.

Jak połączyć KPI biznesowe z metrykami modelu (accuracy, precision, recall itd.)?

Sam wysoki accuracy niewiele znaczy, jeśli nie da się go przełożyć na pieniądze, czas albo ryzyko. Przykładowo: model churnowy z „super” dokładnością może być bezużyteczny, jeśli myli się akurat przy tych klientach, których odejście zaboli najbardziej finansowo.

Podejście praktyczne jest takie: najpierw liczysz spodziewany efekt biznesowy (np. „obcinamy 30% najgorszych leadów, zyskujemy 2 godziny pracy handlowca dziennie”), a dopiero potem dobierasz metryki modelu, które ten efekt odzwierciedlają. W jednym przypadku ważniejsza będzie czułość (żeby wychwycić jak najwięcej problematycznych paczek), w innym precyzja (żeby nie marnować czasu na fałszywe alarmy) – i pod to świadomie przygotowuje się dane treningowe oraz balans klas.

Co zrobić, jeśli brakuje mi części danych potrzebnych do dobrego modelu?

Często okazuje się, że idealne dane istnieją tylko „w głowach ludzi” albo w starym systemie sprzed migracji. Handlowcy mają swoje heurystyki, dział obsługi klienta intuicyjnie wie, które zgłoszenia są groźne – ale nigdzie nie zapisuje tego w strukturze, którą można łatwo wykorzystać w modelu.

W takiej sytuacji można pójść dwoma ścieżkami równolegle: po pierwsze, wyciągnąć maksimum z tego, co dostępne (nawet jeśli dane są częściowe) i zbudować pierwszy, prostszy model, który już coś poprawia. Po drugie, zmodyfikować procesy tak, aby od dziś zbierały brakujące informacje w powtarzalny sposób – na przykład dodać kilka kluczowych pól do formularza w CRM lub wymusić rejestrowanie określonych statusów. Dzięki temu kolejne iteracje modeli będą coraz bardziej zasilane sensownymi danymi, a nie domysłami.

Kluczowe Wnioski

• Model może mieć świetne metryki na papierze i jednocześnie zero wpływu na biznes, jeśli dane treningowe są oparte na sztucznej definicji problemu (np. churn liczony „bo tak było wygodnie w SQL”, a nie tak, jak realnie zachowują się klienci i przychody).
• Punktem startu są rozmowy z właścicielami procesu, a nie z bazą danych: trzeba nazwać jedną konkretną decyzję, którą model ma wesprzeć (np. kolejność dzwonienia do leadów), oraz zrozumieć, jak dziś ludzie ją podejmują i na jakich sygnałach się opierają.
• Trzeba jasno zawęzić problem – jeden model ma rozwiązywać jedno zadanie decyzyjne; mieszanie w jednym projekcie priorytetyzacji leadów, rekomendacji produktu i scoringu ryzyka kończy się chaosem w danych i rozmyciem „prawdy” treningowej.
• KPI biznesowe (dodatowy przychód, zaoszczędzone godziny pracy, mniej reklamacji) muszą być zdefiniowane przed projektowaniem modelu – to one później narzucają, jakie metryki techniczne są naprawdę istotne i jak przygotować zbiór treningowy (np. balans klas, koszt błędów).
• Dane treningowe muszą odpowiadać na pytanie: co wiemy o obiekcie w MOMENCIE podejmowania decyzji; wszystko, co wydarza się później (np. notatki handlowca po rozmowie), nie może być cechą modelu, bo prowadzi do nieszczelności czasowej.
• Czas jest szkieletem całego zbioru: konieczne są poprawne znaczniki (timestampy) zdarzeń i spójne łączenie tabel tak, by jasno było, co wydarzyło się przed decyzją, a co po niej – inaczej „sukces” lub „porażka” będą źle zdefiniowane.

Opracowano na podstawie

• CRISP-DM 1.0: Step-by-step data mining guide. SPSS (2000) – Klasyczny proces przygotowania danych i projektów data mining/ML.
• ISO/IEC 20546:2019 Information technology – Big data – Overview and vocabulary. ISO (2019) – Standardowe pojęcia dot. danych, jakości i cyklu życia analityki.
• Data Preparation for Data Mining. Morgan Kaufmann (1999) – Piatetsky-Shapiro i in.; praktyczne techniki przygotowania zbiorów treningowych.
• Feature Engineering for Machine Learning: Principles and Techniques for Data Scientists. O’Reilly Media (2018) – Książka o projektowaniu cech, wycieku danych i ramie czasowej w ML.
• Machine Learning Yearning. DeepLearning.AI – Andrew Ng; przekład problemu biznesowego na zadanie ML i dane treningowe.
• The Discipline of Machine Learning (CMU-ML-06-108). Carnegie Mellon University (2006) – Mitchell; podstawy formułowania problemu, etykiet i oceny modeli.