Wprowadzenie

Wyobraźmy sobie typową sytuację. Prezes twojej firmy wchodzi do twojego biura i kładzie na biurku dwa projekty. Jeden to wdrożenie nowego systemu CRM, klasyczny projekt IT. Drugi to system przewidywania odpływu klientów, wykorzystujący AI. Ten sam budżet, ten sam deadline. Ale sposób realizacji będzie kompletnie inny.

W Booking.com stanąłem przed podobnym wyzwaniem. Pracowaliśmy nad Channel Recommenderem, systemem, który decyduje, jak obsłużyć klienta: przez telefon, mail, czat, czy może samoobsługę. Stawka była wysoka. Każde przekierowanie klienta do droższego kanału to konkretne koszty, a każde złe przekierowanie to ryzyko utraty rezerwacji wartej setki euro.

Początkowo mieliśmy prosty system reguł if - else, jeżeli - to. Jeśli klient ma rezerwację za więcej niż 7 dni, rekomendujemy mail albo czat. Jeśli wartość rezerwacji przewyższa 1000 euro, rekomendujemy telefon. Klasyczne drzewo decyzyjne, jak quiz z kilkoma ścieżkami. Działało... okej.

Przełom nastąpił, gdy zdecydowaliśmy się na AI. I tutaj zaczęły się schody. Zamiast pisania reguł potrzebowaliśmy danych: tysięcy interakcji z klientami, historii ich rezerwacji, zapisów czatów, maili, połączeń. Każda zmienna mogła być istotna. Może pora dnia wpływa na skuteczność obsługi? Może kraj pochodzenia klienta? A może historia jego poprzednich interakcji?

Co nas najbardziej zaskoczyło? Nasz pierwszy model AI miał dość niską skuteczność. Na potrzeby naszego spotkania przyjmijmy, że 60%. W tradycyjnym IT projekt z takim wynikiem byłby katastrofą. Wyobraźcie sobie system księgowy, który poprawnie księguje tylko 60% faktur. Ale w świecie AI to był dopiero początek.

Kolejne miesiące to była seria eksperymentów. Model świetnie radził sobie z typowymi przypadkami, ale kompletnie gubił się w bardziej złożonych sytuacjach. Dostawaliśmy dane, dostrajaliśmy parametry. Po kilku miesiącach osiągnęliśmy ponownie, przyjmijmy na potrzeby tego wykładu, 82% skuteczności, ale tylko dla klientów, którzy mieli już historię kontaktów z nami.

To pokazuje fundamentalną różnicę między IT a AI. W tradycyjnym IT jesteś jak architekt: masz plan, wiesz, co budujesz, możesz precyzyjnie określić kolejne kroki. W AI jesteś jak naukowiec prowadzący eksperymenty. Stawiasz hipotezy, testujesz je, uczysz się na błędach. Nie możesz obiecać, że za 3 miesiące model będzie miał dokładnie 95% skuteczności. Możesz za to określić, kiedy model jest wystarczająco dobry, by przynieść wartość biznesową.

To jak różnica między budową domu a uprawą ogrodu. Przy budowie domu wiesz dokładnie, co dostaniesz. Masz projekt, harmonogram, jasno określone etapy. W ogrodzie? Tworzysz odpowiednie warunki, dbasz, pielęgnujesz, ale... natura może cię zaskoczyć. Czasem pozytywnie, czasem nie.

Zanim rzucimy się w wir projektów AI, zatrzymajmy się na chwilę. Z mojego doświadczenia wynika, że sukces projektu AI zależy od czterech kluczowych elementów. I uwaga, kolejność nie jest przypadkowa.

Pierwszy to jasny cel i zakres. Nie chcemy wdrożyć AI, ale mamy konkretny problem biznesowy do rozwiązania. W Booking.com naszym celem nie było zautomatyzowanie obsługi klienta, było nim znaczące zmniejszenie liczby połączeń telefonicznych bez pogorszenia satysfakcji klientów. Różnica? Ogromna. Od razu wiedzieliśmy, co mierzymy i kiedy odnieśliśmy sukces.

Drugi element to dane. I tutaj ciekawostka. Często firmy zaczynają od szukania data scientistów, a dopiero potem patrzą na swoje dane. To błąd. Jeśli firma chce przewidywać zachowania klientów, ale ma dane tylko z ostatnich trzech miesięcy, to... jak próba przewidzenia pogody na rok, patrząc tylko przez okno. Najpierw sprawdźcie, czy macie odpowiednie dane w odpowiedniej ilości i jakości.

Trzeci element to infrastruktura techniczna. Ale uwaga, nie chodzi o kupienie najdroższego sprzętu czy wszystkich możliwych narzędzi. W początkowej fazie często wystarczy laptop i dostęp do chmury. Kluczowe jest co innego: czy wasza infrastruktura pozwala na szybkie eksperymenty? Czy możecie łatwo trenować nowe modele? Czy macie gdzie przechowywać i przetwarzać dane?

I wreszcie... zespół. Ale nie chodzi tylko o zatrudnienie data scientista. Potrzebujecie też inżynierów danych, którzy przygotują i przetworzą informacje w waszej firmie. Potrzebujecie product managera lub analityka biznesowego, który rozumie specyfikę AI. I, co najważniejsze, potrzebujecie ekspertów dziedzinowych, którzy rozumieją wasz biznes. W przypadku Booking.com to byli agenci obsługi klienta. To oni wiedzieli dokładnie, które przypadki są najtrudniejsze i dlaczego.

Teraz pytanie, które często słyszę: od czego zacząć? Zacznijcie od celu i danych. Bez tego reszta nie ma sensu. Możecie mieć najlepszy zespół na świecie i nieograniczony budżet na infrastrukturę, ale jeśli nie macie jasnego celu lub odpowiednich danych, projekt się nie uda.

I jeszcze jedna rzecz. Te elementy muszą być zbalansowane. Świetne dane bez odpowiedniej infrastruktury? Problem. Świetny zespół bez jasnego celu? Strata czasu i pieniędzy. To jak próba ugotowania obiadu. Potrzebujesz składników i sprzętu i przepisu, i kucharza. Brak któregokolwiek elementu i... zamawiamy pizzę.

Często wrzucamy wszystkie projekty związane z AI do jednego worka. Ale jest zasadnicza różnica między klasycznym machine learningiem a tym, co robimy z modelami językowymi jak GPT. Pokażę wam to na konkretnym przykładzie.

Weźmy obsługę klienta. W klasycznym machine learning, nad którym pracowałem w Booking.com, uczyliśmy model konkretnego zadania: przewidywania najlepszego kanału komunikacji. Model dostawał konkretne zmienne: czas do przyjazdu, wartość rezerwacji, typ pokoju. Zwracał konkretną odpowiedź: telefon, mail czy czat. To jak wyspecjalizowany pracownik, który robi jedną rzecz, ale robi ją bardzo dobrze.

A modele językowe? To zupełnie inna historia. One są jak wszechstronny konsultant. Możesz je wykorzystać do różnych zadań bez trenowania. Weźmy przykład asystenta w obsłudze klienta. Nie uczysz go konkretnie odpowiadania na maile czy kategoryzowania zgłoszeń. Zamiast tego dajesz mu kontekst w postaci promptu: "Jesteś asystentem obsługi klienta firmy X, oto nasze procedury, oto nasz tone of voice itd."

Ale ta wszechstronność ma swoją cenę. W machine learningu mamy pełną kontrolę nad danymi treningowymi i możemy precyzyjnie zmierzyć skuteczność. Model albo dobrze przewidział kanał komunikacji, albo nie. A z modelami językowymi? Czasem odpowiedź może być technicznie poprawna, ale nie w stylu twojej firmy. Albo całkiem poprawna, ale nieoptymalna.

To przekłada się na sposób prowadzenia projektu. W machine learningu skupiasz się na jednym konkretnym problemie. Zbierasz dane, trenujesz model, mierzysz wyniki. Z LLM-ami kluczowe staje się m.in. projektowanie promptów, budowa zabezpieczeń przed halucynacjami, integracja z istniejącymi procesami czy testowanie różnych scenariuszy użycia.

W machine learningu sukces często mierzymy jedną liczbą: skutecznością modelu. W projektach z LLM patrzymy na szerszy obraz: jak bardzo zmniejszyło się obciążenie zespołu? Jak szybko otrzymują odpowiedź klienci? Ile przypadków wymaga ludzkiej interwencji?

Myślę o tym w ten sposób. Machine learning to jak budowa robota na linii produkcyjnej: wykonuje konkretne zadanie w konkretny sposób, z mierzalną precyzją. LLM to bardziej jak zatrudnienie asystenta: wszechstronnego, ale wymagającego odpowiedniego briefingu i nadzoru. Oba podejścia są wartościowe, ale wymagają zupełnie innego podejścia do zarządzania projektem.

Z racji mojego doświadczenia dzisiaj skupimy się na projektach machine learningowych. Pracowałem nad nimi zarówno w dużych organizacjach jak Booking.com, gdzie budowaliśmy własne modele od podstaw, jak i przy mniejszych projektach, gdzie korzystaliśmy z zewnętrznych rozwiązań. To, co zauważyłem to, że niezależnie czy budujecie własne modele, czy współpracujecie z dostawcami, zasady sukcesu są podobne. Dostawca może wam pomóc z techniczną stroną, ale to wy musicie wiedzieć, czego chcecie i jak to zmierzyć.

Trochę jak z remontem mieszkania. Możecie wszystko zrobić sami albo wynająć ekipę, ale w obu przypadkach musicie wiedzieć, co ma być efektem końcowym. Dlatego dzisiaj pokażę wam, jak uniknąć najczęstszych pułapek w projektach machine learning i na co zwracać szczególną uwagę. Niezależnie czy jutro będziecie rozmawiać z waszym zespołem data science, czy z potencjalnym dostawcą AI.