Inteligencja decyzyjna? Tak proszę.

Jestem stałym czytelnikiem Medium już od dłuższego czasu i dla mnie jednym z głównych powodów dołączenia było hojne dzielenie się ciężko zdobytymi doświadczeniami od ludzi.

Pamiętam na przykład, jak czytałem o „Co chciałbym wiedzieć, zanim wybrałem X”, gdzie „X” oznaczało wybór technologii, którego właśnie dokonaliśmy w mojej firmie. Artykuł miał obraz czegoś płonącego wysokimi płomieniami.

Dobre wglądy, zawsze należy brać z odrobiną soli i zawsze powtarzać sobie, że „OK, mieli pecha / za wcześnie / nie byli tacy mądrzy. Jesteśmy inni”. Chciałbyś…

Teraz nadszedł najwyższy czas, abym zaczął dawać coś od siebie, być może dając niektórym czytelnikom jakiś wgląd lub przynajmniej poczucie, że nie są sami, a może nawet ciepłe uczucie bycia o wiele lepszym niż ten facet i jego koledzy z drużyny.

A teraz, przechodząc do tytułu clickbait, wszystko, co zawiera „Inteligencję decyzyjną”, powinno słusznie wzbudzić zainteresowanie każdego, kto próbuje zarobić na życie w domenie analitycznej.

Zastrzeżenie, późno wiem, ten tekst jest tylko kolejnym potwierdzeniem wagi tego, co szczególnie Cassie Kozyrkov ( Cassie Kozyrkov ) tak dobrze artykułuje. Jeśli naprawdę chcesz dowiedzieć się więcej, przestań to czytać i przejdź tutaj .

No to ruszamy.

Impreza jest gotowa.

Mamy mnóstwo danych i ludzi, którzy są naprawdę dobrzy w sprawianiu, by dane „śpiewały”, mamy właścicieli danych, którzy nie chcą niczego więcej niż wprawienia ich w ruch — aby zobaczyć, co wszyscy możemy z tym zrobić. Mamy czarodziejów matematyki i hakerów, mamy biznesmenów i jednego lub dwóch „wiemy o tej dziedzinie więcej niż ktokolwiek inny”. Wielokrotnie omawialiśmy diagram Drew Conwaya Venna .

Ale gdzie Ty zaczynasz? Nasz pierwotny „sposób pracy” polegał na tym, że w dawnych (sic!) czasach jeziora danych najpierw zdobywaliśmy dane, a potem polowaliśmy na interesy. Nie było to łatwe z różnych powodów i ma swój własny temat (wskazówka: spróbuj przekonać właścicieli firm do wskoczenia do fajnego pociągu ML, właścicieli firm, którzy nadal nie są zbyt zadowoleni z wcześniejszych podróży BI).

Z biegiem czasu, po wielu telefonach i nieporozumieniach, poprawiliśmy się w opowiadaniu historii i przedstawianiu argumentów za MVP lub przynajmniej POC („Cmentarze POC” są/powinny już być omawiane tutaj na Medium, jeśli nie, dodaj to — główny powód dzisiejszych MLOps).

Porozmawiaj z właściwą osobą.

Oczywiste, prawda? Nie tak łatwo. W większych korporacjach między zespołem analitycznym a docelowym klientem jest wiele osób. Jestem pewien, że wszyscy ci ludzie są potrzebni, ale jako ktoś, kto chce coś zmienić za pomocą analityki, musimy porozmawiać z osobą, która podejmuje faktyczną decyzję, i osobą (osobami), która zna wszystkie istotne szczegóły dotyczące obszaru docelowego /system/proces/…

W jednym projekcie ja i mój kolega zajmujący się analizą danych spędziliśmy kilka (w końcu prawie 6 miesięcy) miesięcy, opracowując modele do przewidywania awarii w określonej usłudze telekomunikacyjnej. W pewnym momencie (w końcu) prezentowaliśmy demo na wewnętrznym zjeździe analityków, demonstrując to, nad czym pracujemy, i kilka fajnych technik głębokiego uczenia się prosto z arXiv, które chcielibyśmy wypróbować w niektórych projektach (jeśli ktokolwiek proszę zrozumieć, jakie to byłoby fajne).

Przyszedł starszy inżynier. Widział kilka wykresów z naszego trwającego projektu konserwacji zapobiegawczej. Był zainteresowany, ponieważ od lat miał bezpośredni kontakt z tą właśnie usługą telekomunikacyjną. Wiele. Lata. Uprzejmie zadał kilka pytań. Było jasne, że nie chciał nas zawstydzić, ale pytania były bardzo podstawowe i bardzo wyraźnie sprawiały, że nie wyglądaliśmy fajnie.

„Jakich danych pogodowych użyłeś? Wiesz, że śnieg ma wyraźny wpływ na te rzeczy. Nie wspominając już o gorących latach, chłopcze! Znów był po prostu ciekawy, jak każdy dobry inżynier. Kończąc komentarzem, który ostatecznie postawił nasz projekt pod dużym znakiem zapytania: „Wiesz, zawsze uruchamiamy te rzeczy z zapasowymi komponentami, na wypadek gdyby coś się zepsuło”.

Więc co się tutaj stało? Rozpoczęliśmy projekt z dobrą motywacją: wartość przewidywania awarii w tych systemach była oczywista, wszyscy o tym wiedzieli. Ponadto istniały plany, aby być może kupić rozwiązanie z zewnątrz, zamiast budować je we własnym zakresie.

Wartość — sprawdź.

Upewniając się, że pokonaliśmy zewnętrzne rozwiązanie, udowadniając naszą wartość dla firmy — tak, zrobimy to!

Rozmowa z właściwą osobą? Nie, oczywiście, że nie.

Uzyskaj właściwą metrykę. Uzyskaj potwierdzenie: cel do osiągnięcia, zobowiązanie do działania, jeśli cel zostanie osiągnięty.

Pierwszym znakiem ostrzegawczym (w tym samym projekcie, co powyżej) było to, że kiedy omawialiśmy mierniki sukcesu, naprawdę staraliśmy się uzyskać zobowiązanie ze strony biznesu do wykorzystania naszych przewidywań do faktycznego podejmowania decyzji, a aby się tam dostać, potrzebowaliśmy uzgodnionego miernika i wartość dołączona do tej metryki.

Znak ostrzegawczy pojawił się na jednym z pierwszych spotkań, kiedy zewnętrzny dostawca imponował naszej firmie „bardzo wysoką dokładnością”. Teraz. W tych środowiskach awarie są rzadkie (co dodatkowo utrudnia modelowanie predykcyjne). Bardzo rzadkie. Tak rzadkie, że każdy mógł przynieść domyślny model atrapy i mieć dużą dokładność. „Nie przewiduję żadnych porażek. Och, mam 99% dokładności, super!”. Nie, nie fajnie.

Tak więc w pewien sposób zasłużyliśmy na nasze miejsce w projekcie, zadając kilka pytań dotyczących właściwego wskaźnika, aby nasza firma zrozumiała, dlaczego był to tani trik ze strony dostawcy.

Teraz. Czy otrzymaliśmy miernik i cel do osiągnięcia? I czy były one ugruntowane w rzeczywistej wartości, jaką przyniosłoby to firmie, gdyby zostało wykorzystane, gdyby podejmowało decyzje na podstawie naszej analizy, na naszych danych?

Tak i nie. Najwyraźniej nie było to w pełni zrozumiane i uzasadnione, a ostatecznie wydajność naszych modeli (przebiła sprzedawcę) nie była wystarczająco wysoka, aby można ich było używać. Zaoszczędziliśmy firmie dużo pieniędzy, nie kupując zewnętrznego rozwiązania (które i tak nie zostałoby użyte). Ale mogliśmy skończyć kilka miesięcy wcześniej.

Więcej przykładów, te same błędy

W drugim przykładzie, jeśli już cię nie straciłem, szaleliśmy, próbując kilku architektur głębokiego uczenia się, całego (w tamtym czasie) shebangu, wszystko po to, aby pomóc w stworzeniu dobrego klasyfikatora tekstu (pomyśl o obszarze obsługi klienta ).

Ponownie wartość była jasna, a inni (zewnętrzny zespół analityki danych) spróbowali tego. Moglibyśmy zrobić dużo lepiej w znacznie krótszym czasie. Mamy w torbie nową serię nowych narzędzi i zamierzaliśmy ich użyć.

Ponownie. Tak, poszło nam o wiele lepiej niż konkurencja, a mnie zajęło to ułamek czasu, który im zajęło. Czyli był używany?

Nie. Tym razem było to spowodowane bardziej praktycznymi ograniczeniami: tak, mogliśmy podzielić teksty na ponad 40 rozsądnych grup, z których wszystkie miały doskonały sens dla pracowników obsługi. Ale w rzeczywistości wątki pocztowe przenosiły się na zajęcia, a pracownicy obsługi obsługiwali wiele zajęć równolegle (oczywiście) i — jak to często bywa — problem, który rozwiązywaliśmy, był daleki od problemów, które musieli rozwiązać w pierwszej kolejności. Zasadniczo sugerowaliśmy papier ścierny 240 przed 40.

Również w tym przypadku nie udało nam się do końca porozmawiać ze wszystkimi właściwymi osobami. I znowu nie uzgodniliśmy wcześniej zobowiązania do wykorzystania (jeśli jest wystarczająco dobre) tego, co opracowaliśmy.

Odrób swoją pracę domową

Może jeszcze jedna lekcja z góry brzmiałaby:

To, że inni próbowali wcześniej, nie gwarantuje, że problem został poprawnie sformułowany.

W obu przykładach mieliśmy lepsze wyniki niż wcześniejsze zespoły, a także w rywalizacji czołowej. Nie oznacza to jednak, że była to właściwa gra. Myślę, że lekcję można podsumować słowami: „Odrób swoją pracę domową!”.

Powyżej przykłady sprzed pięciu lat. Oczekuj więcej, zarówno od ostatnich pięciu lat, ale na pewno od przyszłych błędów.