Rekomendacje następnego kroku w aplikacji: agent vs klasyczny ML (bandyty, sekwencje, reguły)

Czym jest „next best action” i typowe scenariusze użycia

Next best action (NBA) to mechanizm, który w danym momencie proponuje najbardziej sensowny kolejny krok dla użytkownika lub pracownika, aby osiągnąć cel biznesowy i jednocześnie utrzymać dobre doświadczenie. W przeciwieństwie do klasycznych rekomendacji „co pokazać” (np. produkt/treść), NBA odpowiada na pytanie: „co system powinien zrobić lub zasugerować teraz?”—może to być komunikat, kolejna funkcja w ścieżce, oferta, przypomnienie, eskalacja do konsultanta albo brak działania, jeśli to najlepsza opcja.

NBA jest zwykle podejmowane w kontekście: aktualnej sytuacji użytkownika (intencja, etap procesu), historii interakcji, ograniczeń operacyjnych (np. dostępność kanału, budżet, limity kontaktu) oraz reguł zgodności. Kluczowa cecha to decyzyjność: wynik ma formę konkretnej akcji, a nie tylko rankingu elementów.

W praktyce „najlepsza” akcja rzadko oznacza maksymalizację jednego wskaźnika. Często jest to kompromis między krótkoterminową konwersją a długoterminową relacją, obciążeniem operacji, ryzykiem i spójnością komunikacji. Dlatego NBA obejmuje zarówno dobór działania, jak i moment jego wykonania (timing) oraz kanał (in-app, e-mail, push, kontakt telefoniczny, czat).

Typowe scenariusze użycia

• Onboarding i aktywacja: wybór kolejnego kroku w aplikacji (np. dokończenie profilu, pierwsza kluczowa czynność), dostosowany do tego, co użytkownik już zrobił i gdzie utknął.
• Retencja i zapobieganie rezygnacji: reakcja na spadek aktywności (np. edukacyjny tip, przypomnienie wartości, oferta wsparcia), zamiast jednolitego „push do wszystkich”.
• Monetyzacja i upsell/cross-sell: wskazanie kolejnej propozycji (plan, funkcja premium, pakiet), ale tylko wtedy, gdy użytkownik jest w odpowiednim momencie i nie grozi to frustracją.
• Obsługa klienta i contact center: podpowiedź następnego kroku konsultantowi (pytanie doprecyzowujące, rekomendowana ścieżka rozwiązania, eskalacja), aby skrócić czas obsługi i poprawić jakość.
• Rekomendacje komunikacji: wybór, czy i kiedy wysłać wiadomość oraz jakim kanałem, uwzględniając limity kontaktu, strefę czasową i wcześniejsze reakcje.
• Bezpieczeństwo i nadużycia: decyzja o dodatkowej weryfikacji, ograniczeniu akcji lub skierowaniu do manualnej kontroli, gdy sygnały ryzyka przekraczają próg.
• Ścieżki transakcyjne: optymalizacja kolejnych kroków w procesach (np. płatność, wniosek, rezerwacja): podpowiedź dokumentu, skrótu, alternatywnej metody, czy wsparcia w kluczowym momencie.
• Edukacja i „product guidance”: mikro-interwencje w UI (tooltip, checklist, podpowiedź funkcji) dopasowane do celu użytkownika, a nie tylko do tego, co system chce promować.

Co odróżnia NBA od prostych automatyzacji

• Kontekstowość: decyzja zależy od bieżącej sytuacji i historii, a nie tylko od pojedynczego zdarzenia.
• Wielość możliwych akcji: system wybiera spośród zestawu działań (czasem także „nie rób nic”), zamiast uruchamiać jeden z góry ustalony scenariusz.
• Ciągłość: kolejne decyzje tworzą ścieżkę interakcji w czasie, a nie jednorazową rekomendację.
• Ograniczenia i odpowiedzialność: NBA zwykle musi respektować limity, polityki, ryzyka i spójność doświadczenia, bo jego wynik bezpośrednio wpływa na zachowanie systemu wobec użytkownika.

Tak rozumiane NBA jest „warstwą decyzyjną” pomiędzy danymi o użytkowniku a działaniami aplikacji lub zespołu operacyjnego. Jej zadaniem jest zamienić sygnały w konkretną, uzasadnioną i wykonalną akcję w odpowiednim momencie.

2. Trzy podejścia do NBA: reguły, klasyczny ML (bandyty i modele sekwencyjne) oraz agent LLM

„Next best action” można realizować na kilka sposobów, które różnią się poziomem automatyzacji, wymaganiami danych, przewidywalnością zachowania i łatwością utrzymania. Najczęściej spotyka się trzy rodziny rozwiązań: silniki reguł, klasyczne modele uczenia maszynowego (w tym bandyty i modele sekwencyjne) oraz agenty oparte o LLM. Wybór podejścia wpływa na to, czy system głównie egzekwuje politykę biznesową, optymalizuje mierzalny cel w danych, czy też elastycznie „rozumuje” w oparciu o kontekst i instrukcje. Ten artykuł powstał jako rozwinięcie jednego z najczęstszych tematów poruszanych podczas szkoleń Cognity.

1) Reguły (rule-based)

Podejście regułowe opiera się na z góry zdefiniowanych warunkach i priorytetach: jeśli użytkownik spełnia kryteria X, to zaproponuj akcję Y. Reguły są szczególnie użyteczne, gdy organizacja ma dobrze opisane procesy, ograniczoną ilość danych lub musi twardo egzekwować polityki (np. kolejność kroków, ograniczenia prawne, limity kontaktu).

• Najlepsze zastosowania: proste i stabilne procesy, krytyczne ograniczenia biznesowe, szybkie MVP bez rozbudowanej analityki.
• Mocne strony: przewidywalność, łatwa kontrola, szybkie wdrożenie.
• Typowe ograniczenia: trudność skalowania złożoności (rosnąca liczba wyjątków), słabsza personalizacja i adaptacja do zmian w zachowaniach użytkowników.

2) Klasyczny ML: bandyty i modele sekwencyjne

W podejściu ML system uczy się z danych historycznych i/lub z sygnałów w trakcie działania, aby wybierać akcję maksymalizującą mierzalny efekt (np. konwersję, retencję, redukcję churnu). W ramach NBA często spotyka się dwa podtypy: bandyty kontekstowe oraz modele sekwencyjne.

Bandyty (contextual bandits) traktują wybór akcji jak problem kompromisu między eksploracją (testowaniem nowych akcji) a eksploatacją (wyborem tego, co działa najlepiej). Decyzja zależy od kontekstu użytkownika i sytuacji „tu i teraz”. To podejście bywa praktyczne, gdy akcje są względnie niezależne, a wynik pojawia się szybko (np. kliknięcie, rozpoczęcie ścieżki, przyjęcie oferty).

Modele sekwencyjne uwzględniają, że działania i zdarzenia tworzą ciąg, a efekt może zależeć od kolejności kroków oraz historii interakcji. Takie podejście jest naturalne, gdy NBA ma prowadzić użytkownika przez ścieżkę (onboarding, edukacja, kolejne funkcje) lub gdy istotna jest dynamika w czasie (np. zmiana intencji, „moment” na interwencję).

• Najlepsze zastosowania: personalizacja na dużą skalę, optymalizacja mierzalnych KPI, scenariusze z wystarczającą ilością danych i możliwością iteracji.
• Mocne strony: lepsza adaptacja do zachowań użytkowników, możliwość ciągłego uczenia i testowania, formalizacja celu optymalizacji.
• Typowe ograniczenia: zależność od jakości danych i poprawnego zdefiniowania celu, wrażliwość na przesunięcia danych w czasie, konieczność przemyślenia sygnału „nagrody” (co uznajemy za sukces).

3) Agent LLM (decyzje i orkiestracja na podstawie kontekstu)

Agent oparty o LLM wybiera „następny krok” poprzez interpretację bieżącego kontekstu (stan użytkownika, treść rozmowy, opis produktu, zasady) i podejmowanie decyzji w sposób bardziej elastyczny niż klasyczne modele. W praktyce agent może nie tylko wskazać akcję, ale też uzasadnić rekomendację, dopasować komunikację do użytkownika oraz orkiestruje użycie narzędzi (np. wyszukiwanie w bazie wiedzy, odczyt parametrów konta, wygenerowanie instrukcji).

To podejście jest kuszące szczególnie tam, gdzie kontekst jest częściowo nieustrukturyzowany (np. tekst w czacie, opis problemu), a przestrzeń możliwych działań jest duża lub często się zmienia. Agent może też łączyć sygnały: nie tylko „co zadziała statystycznie”, ale „co jest logicznie spójne” z celem i ograniczeniami.

• Najlepsze zastosowania: interfejsy konwersacyjne, wsparcie w złożonych procesach, personalizacja języka i argumentacji, rekomendacje zależne od opisowego kontekstu.
• Mocne strony: elastyczność, łatwiejsze wykorzystanie wiedzy opisowej i zasad w języku naturalnym, dobre dopasowanie do sytuacji „long tail”.
• Typowe ograniczenia: mniej deterministyczne zachowanie, ryzyko niespójnych lub niepożądanych decyzji bez odpowiednich ograniczeń, trudniejsza standaryzacja tego, co dokładnie jest „akcją” i jak mierzyć jej efekt.

W skrócie: reguły zapewniają prostą kontrolę i przewidywalność, klasyczny ML dostarcza optymalizacji opartej o dane i eksperymenty, a agent LLM wnosi elastyczne rozumowanie i pracę na nieustrukturyzowanym kontekście. W praktyce organizacje często traktują te podejścia jako komplementarne, a nie wykluczające się.

3. Dobór podejścia: dostępne dane, opóźnienia, koszty i ograniczenia operacyjne

Wybór między regułami, klasycznym ML (np. bandytami i modelami sekwencyjnymi) a agentem LLM zwykle nie jest decyzją „co jest najlepsze technologicznie”, tylko co jest wykonalne i opłacalne przy danych, opóźnieniach, budżecie oraz ograniczeniach operacyjnych. Poniżej znajduje się praktyczny zestaw kryteriów, które najczęściej przesądzają o decyzji.

Dostępne dane i sygnały: co masz dziś vs. co możesz zdobyć

Najważniejsze pytanie brzmi: czy potrafisz jednoznacznie zdefiniować cel (nagrodę) oraz zmierzyć efekty rekomendowanej akcji. Od tego zależy, czy podejście „uczące się z danych” w ogóle ma na czym stać.

• Reguły wygrywają, gdy masz mało danych, a wiedza domenowa jest silna (np. procesy, polityki, progi ryzyka). Wymagają minimum instrumentacji, ale potrzebują utrzymania i testowania zmian.
• Klasyczny ML wymaga stabilnych logów: kontekst → akcja → wynik. Jeśli umiesz mierzyć sukces (np. konwersję, retencję, spadek kosztu obsługi) i masz dość wolumenu, modele potrafią optymalizować decyzje w sposób powtarzalny.
• Agent LLM może działać nawet przy ograniczonych danych o wyniku (bo część „inteligencji” pochodzi z modelu bazowego), ale nadal potrzebuje danych o kontekście (profil, stan sesji, ograniczenia) oraz kontrolowanego feedbacku, jeśli ma się poprawiać w czasie.

W praktyce często startuje się od reguł lub prostych modeli, a dopiero potem dokłada sygnały (telemetrię, eventy, etykiety), by uruchomić pętlę uczenia.

Opóźnienia (latency) i tryb decyzji: online vs. „prawie online”

„Next best action” bywa podejmowane w bardzo różnych warunkach czasowych. Kluczowe jest, czy decyzja musi zapaść w czasie interakcji użytkownika, czy może być przygotowana wcześniej.

• Bardzo niskie opóźnienia (np. setki ms lub mniej) sprzyjają regułom i lekkim modelom ML uruchamianym lokalnie lub w szybkim serwisie scoringowym.
• Średnie opóźnienia (np. 300–1500 ms) bywają akceptowalne dla części przypadków użycia; tu można rozważyć agentów LLM, o ile ograniczysz długość kontekstu, liczbę wywołań oraz zapewnisz cache.
• Decyzje asynchroniczne (np. rekomendacje na kolejną sesję, powiadomienia, e-maile) pozwalają na bardziej złożone obliczenia i bogatsze konteksty.

Jeśli produkt wymaga twardych SLA, zmierz latencję end-to-end (sieć, autoryzacja, pobranie kontekstu, decyzja, logowanie) i dopiero potem dobieraj podejście.

Koszty: licencje, inferencja, eksperymenty i utrzymanie

Koszt NBA nie kończy się na „ile kosztuje predykcja”. Liczy się też koszt budowy, utrzymania i ryzyka błędnych decyzji.

• Reguły: niskie koszty runtime, ale rosnący koszt utrzymania (dług reguł, konflikty, konieczność przeglądów). Dobre tam, gdzie reguły są stabilne i rzadko się zmieniają.
• Klasyczny ML: umiarkowany koszt inferencji, ale istotny koszt danych (instrumentacja, ETL), walidacji i cyklu aktualizacji. Opłacalne, gdy skala decyzji jest duża, a nawet mała poprawa metryki daje wysoki zwrot.
• Agent LLM: koszt inferencji może być wysoki (zwłaszcza przy długim kontekście i wielu wywołaniach), dochodzą koszty bezpieczeństwa (filtrowanie, ograniczenia narzędzi) i testowania jakości. Opłacalne, gdy wartością jest elastyczność i personalizacja, a nie tylko surowa optymalizacja kliknięć.

Warto od razu policzyć „koszt na 1000 decyzji” oraz koszty pośrednie: logowanie, przechowywanie, obciążenie zespołu operacyjnego, obsługa incydentów.

Ograniczenia operacyjne: wdrożenie, zespół, compliance i środowisko

Nawet najlepszy algorytm przegra, jeśli nie da się go bezpiecznie uruchomić w realiach organizacji.

• Doświadczenie zespołu: reguły wymagają silnej wiedzy domenowej; klasyczny ML wymaga dojrzałości danych i MLOps; agent LLM wymaga kompetencji w zakresie promptingu, integracji narzędzi, oceny jakości i zabezpieczeń.
• Środowisko i integracje: jeśli NBA ma wywoływać akcje (np. zmieniać stan, inicjować proces), konieczne są stabilne API, uprawnienia i mechanizmy idempotencji/rollback. To potrafi ograniczyć użycie agentów w krytycznych ścieżkach.
• Prywatność i lokalizacja danych: jeśli dane nie mogą opuszczać określonego środowiska, wybór może paść na reguły lub ML on-prem. Przy LLM trzeba zweryfikować możliwość uruchomienia w wymaganym trybie oraz zasady przetwarzania danych.
• Zmiana produktu: gdy UI/flow często się zmienia, reguły i modele oparte o stabilne eventy mogą być łatwiejsze do utrzymania niż rozwiązania zależne od dynamicznych opisów ekranu lub treści.

Szybka mapa decyzyjna (heurystyki)

• Jeśli nie masz danych o wyniku i potrzebujesz przewidywalności → zacznij od reguł.
• Jeśli masz dużo decyzji, mierzalny cel i stabilne logi → preferuj klasyczny ML.
• Jeśli kluczowa jest elastyczna personalizacja, praca na tekście i kontekście, a latencja i koszt są akceptowalne → rozważ agenta LLM (zwłaszcza w kanałach asynchronicznych lub wspierających użytkownika).

Porównanie w pigułce

4. Wyjaśnialność, zgodność i ryzyko: porównanie kontroli, audytowalności i bezpieczeństwa

W systemach „next best action” decyzja bywa jednocześnie rekomendacją produktową i ingerencją w doświadczenie użytkownika. To sprawia, że wyjaśnialność (dlaczego ta akcja), zgodność (czy wolno ją zaproponować) oraz ryzyko (co może pójść źle) są równie ważne jak skuteczność. Różne podejścia (reguły, klasyczny ML, agent LLM) dają inny poziom kontroli nad tymi trzema obszarami — i właśnie w praktyce ten fragment architektury najczęściej decyduje o tym, czy rozwiązanie da się bezpiecznie wdrożyć i utrzymać. W czasie szkoleń Cognity ten temat bardzo często budzi ożywione dyskusje między uczestnikami.

4.1. Co znaczy „kontrola” w kontekście NBA

Kontrola to nie tylko możliwość zmiany rekomendacji, ale też zdolność do:

• Wymuszenia polityk (np. czego nie wolno rekomendować określonym segmentom, limity częstotliwości, ograniczenia prawne).
• Uzasadnienia decyzji w sposób zrozumiały dla biznesu, ryzyka i audytu (na poziomie „dlaczego użytkownik to zobaczył”).
• Powtarzalności (czy przy tych samych danych system zachowa się tak samo) oraz stabilności (czy drobne zmiany wejścia nie zmieniają drastycznie wyniku).
• Możliwości odtworzenia decyzji po czasie (logi, wersjonowanie modelu/promptu/reguł, ślad danych wejściowych).

4.2. Wyjaśnialność: od „bo tak ustawiliśmy” do „bo model tak uznał”

• Reguły oferują najwyższą wyjaśnialność: rekomendacja wynika z jawnych warunków (IF/THEN). To ułatwia komunikację z biznesem i ryzykiem, ale rośnie koszt utrzymania przy dużej liczbie wyjątków.
• Klasyczny ML (np. modele scoringowe, bandyci, modele sekwencyjne) daje wyjaśnialność „modelową”: można wskazać cechy/zdarzenia, które statystycznie wpłynęły na wynik, oraz opisać mechanikę eksploracji/eksploatacji. Jest to zwykle mniej intuicyjne niż reguły, ale często wystarczające dla audytu i kontroli, jeśli logujemy wejścia i wersje modeli.
• Agent LLM dobrze generuje narracyjne uzasadnienia („dlaczego to ma sens”), ale to nie jest automatycznie wyjaśnialność decyzji. Uzasadnienie może być przekonujące, a jednocześnie nie odzwierciedlać rzeczywistego procesu decyzyjnego. Dlatego kluczowe jest odróżnienie uzasadnienia dla użytkownika od dowodu dla audytu.

4.3. Zgodność (compliance) i polityki: co łatwo wymusić, a co trudniej

W NBA typowe ograniczenia obejmują: komunikację marketingową, segmenty wrażliwe, limity kontaktu, wymagania dot. zgód, oraz ograniczenia produktowe (np. nie promuj działania, którego użytkownik nie może wykonać).

• Reguły: najprościej kodować polityki „twarde” (blokady, limity, kolejność priorytetów). Łatwe do przeglądu i zatwierdzania, ale trudne w skalowaniu, gdy polityki zależą od wielu kontekstów.
• Klasyczny ML: polityki zwykle realizuje się jako warstwę ograniczeń „przed” lub „po” modelu (np. filtrowanie akcji, re-ranking z karami). Zgodność jest osiągalna, ale wymaga dyscypliny w projektowaniu: jasnego katalogu akcji, cech zgodności i logowania powodów odrzucenia.
• Agent LLM: zgodność opiera się na instrukcjach, narzędziach (tooling) i guardrails. Problemem jest niedeterministyczność i podatność na obejścia (np. prompt injection), więc polityki krytyczne nie powinny zależeć wyłącznie od „posłuszeństwa” modelu.

4.4. Audytowalność i odtwarzalność decyzji

Audyt to możliwość odpowiedzi na pytania: co zostało zarekomendowane, komu, kiedy, na podstawie jakich danych, jaką wersją logiki oraz dlaczego.

• Reguły: audyt jest naturalny, jeśli logujesz „która reguła zadziałała” i w jakiej wersji. Odtwarzalność jest wysoka.
• Klasyczny ML: audyt wymaga wersjonowania modelu i cech (feature store / snapshot cech), logów wejść/wyjść oraz informacji o polityce eksploracji (w bandytach). Odtwarzalność jest dobra, jeśli dane wejściowe są zamrożone lub możliwe do odtworzenia.
• Agent LLM: audyt jest trudniejszy, bo decyzja może zależeć od wielu elementów kontekstu (prompt, retrieved dokumenty, narzędzia, stan rozmowy) oraz od parametrów generacji. Konieczne staje się wersjonowanie: promptów, zestawów instrukcji, narzędzi, źródeł wiedzy i konfiguracji modelu, a także pełne logi kontekstu wejściowego (z zachowaniem zasad prywatności).

4.5. Ryzyko: najczęstsze tryby awarii i powierzchnia ataku

• Reguły: ryzyko to głównie błędy logiczne, luki w wyjątkach oraz „dryf polityk” (reguły nie nadążają za zmianami produktu). Mniejsza powierzchnia ataku, ale ryzyko niespójności przy rozroście.
• Klasyczny ML: ryzyka obejmują bias w danych, pętle sprzężenia zwrotnego (model uczy się skutków własnych rekomendacji), degradację po zmianach w produkcie (data/model drift) oraz wrażliwość na błędne etykiety. W bandytach dochodzi ryzyko niekontrolowanej eksploracji, jeśli nie ma limitów.
• Agent LLM: oprócz typowych ryzyk danych dochodzą: halucynacje (wymyślone fakty/zasady), prompt injection i manipulacja kontekstem, wycieki danych wrażliwych w treści odpowiedzi, niezamierzone obejścia polityk oraz zmienność zachowania między wersjami modelu. To podnosi wymagania w zakresie sanitizacji wejść, izolacji narzędzi i testów bezpieczeństwa.

4.6. Porównanie w pigułce

4.7. Minimalne praktyki bezpieczeństwa i zgodności (niezależnie od podejścia)

• Katalog akcji z jednoznaczną semantyką i dozwolonymi kontekstami użycia.
• Polityki twarde jako warstwa niezależna od „inteligencji” (blokady, limity, zgody).
• Logowanie decyzji: wejścia (w granicach prywatności), wyjścia, wersje logiki/modelu/promptu, powody blokad.
• Testy negatywne: scenariusze zakazane, graniczne i odporność na manipulacje wejściem.
• Ograniczenie uprawnień (szczególnie przy agentach): najmniejsze niezbędne uprawnienia do narzędzi i danych.

5. Architektura hybrydowa: ML wybiera kandydatów, LLM uzasadnia i personalizuje w ramach guardrails

Architektura hybrydowa rozdziela odpowiedzialności: klasyczny ML (np. bandyta lub model sekwencyjny) odpowiada za wybór najbardziej obiecujących akcji na podstawie danych i celu optymalizacji, a LLM odpowiada za warstwę komunikacji i dopasowania — uzasadnienie, ton, format, kolejność kroków, doprecyzowania i mikropersonalizację. Taki podział ogranicza ryzyko „swobodnego” decydowania przez LLM, a jednocześnie pozwala wykorzystać jego moc w generowaniu spójnych, kontekstowych rekomendacji.

Podstawowy przepływ (ML → LLM)

• Kontekst: aplikacja zbiera sygnały (stan użytkownika, zdarzenia, etap procesu, ograniczenia, preferencje, kanał).
• Ranking kandydatów: model ML generuje listę top-N akcji wraz z oceną (np. expected value) i metadanymi (powód wyboru, segment, wymagania).
• Guardrails: przed użyciem LLM stosuje się filtry i polityki (dozwolone akcje, ograniczenia prawne/produktowe, limity częstotliwości, wykluczenia).
• Personalizacja i narracja: LLM dostaje wyłącznie listę dozwolonych kandydatów, kontekst oraz instrukcję „wybierz jedną z nich i uzasadnij”. Generuje rekomendację w odpowiedniej formie (UI copy, e-mail, podpowiedź w aplikacji, skrypt dla konsultanta).
• Egzekucja i logowanie: system wykonuje akcję (lub prosi o potwierdzenie), zapisuje decyzję, ekspozycję, a później wynik.

Dlaczego to działa: rozdzielenie ról

Guardrails w praktyce: „LLM nie decyduje, LLM komunikuje”

Najważniejszą zasadą jest ograniczenie LLM do roli kompozytora i wyjaśniacza, a nie autonomicznego decydenta. Osiąga się to przez zestaw prostych mechanizmów:

• Dozwolony katalog akcji: LLM otrzymuje identyfikatory i opisy akcji, ale nie może wymyślać nowych.
• Wybór z listy: prompt wymusza wskazanie jednej akcji spośród kandydatów (np. przez zwrot JSON z action_id).
• Polityki częstotliwości i kolejności: limity (np. nie pokazuj tej samej akcji częściej niż X) i zależności (akcja B dopiero po A).
• Redakcja danych: LLM nie dostaje wrażliwych pól; zamiast tego dostaje cechy/etykiety (np. „wysoka intencja”, „niska znajomość funkcji”).
• Filtry treści: kontrola stylu i zakazanych sformułowań (np. obietnice wyniku, „diagnozy”, komunikaty ryzykowne).

Warianty hybrydy: od prostego do bardziej „agentowego”

• LLM jako generator copy: ML wybiera akcję, LLM tylko tworzy tekst/układ komunikatu w ramach szablonu.
• LLM jako selektor spośród top-N: ML daje top-N, LLM wybiera jedną, kierując się dodatkowymi instrukcjami (np. „preferuj krótsze kroki dla użytkowników mobile”).
• LLM jako orkiestrator mikrokroków: akcja jest stała, ale LLM dobiera sekwencję podkroków (np. 2–3 kroki zamiast 6) bez zmiany celu i bez wychodzenia poza dozwolone komponenty UI.

Minimalny kontrakt danych między ML i LLM

Żeby utrzymać kontrolę i audytowalność, warto zdefiniować prosty kontrakt: ML zwraca kandydatów z metadanymi, a LLM zwraca ustrukturyzowaną decyzję i tekst.

{
  "candidates": [
    {"action_id": "A1", "title": "Dokończ konfigurację", "score": 0.62, "constraints": ["requires_login"]},
    {"action_id": "A7", "title": "Pokaż skrót funkcji X", "score": 0.55, "constraints": []}
  ],
  "context": {
    "channel": "in_app",
    "ui_locale": "pl_PL",
    "user_stage": "onboarding",
    "tone": "krótko i konkretnie"
  },
  "guardrails": {
    "allowed_action_ids": ["A1", "A7"],
    "banned_phrases": ["gwarantujemy", "na pewno"],
    "max_length_chars": 240
  }
}

Gdzie taka hybryda sprawdza się najlepiej

• Wiele kanałów i formatów: ta sama decyzja (akcja) musi być opisana inaczej w pushu, w aplikacji i w e-mailu.
• Wysokie wymagania UX: potrzebne krótkie, jasne i spójne uzasadnienia dostosowane do kontekstu.
• Złożone katalogi działań: ML redukuje przestrzeń do kilku opcji, LLM tłumaczy i wybiera najlepszą narrację.
• Środowiska z ograniczeniami: gdy nie można pozwolić na „kreatywne” akcje, ale można pozwolić na elastyczną komunikację.

Pułapki i jak je ograniczać (na poziomie architektury)

• Dryf treści względem decyzji: LLM może opisać inną akcję niż wybrana — rozwiązaniem jest zwrot ustrukturyzowany (action_id) i renderowanie treści w oparciu o komponenty powiązane z akcją.
• „Uzasadnienia zmyślone”: LLM może dopowiadać przyczyny niepoparte danymi — ogranicz uzasadnienia do dostarczonych faktów (np. lista reasons z ML) i zakaz spekulacji.
• Niejawne użycie wrażliwych cech: jeśli LLM widzi zbyt dużo, może generować ryzykowne treści — minimalizuj kontekst do niezbędnych etykiet i stosuj redakcję.
• Rozjazd między polityką a generacją: guardrails muszą działać przed i po LLM (walidacja wejścia i wyjścia), a nie tylko w promptach.

6. Metryki i eksperymenty oceny: offline/online, A/B testy, kalibracja i metryki ryzyka

Ocena „next best action” różni się od klasycznych systemów rekomendacyjnych tym, że celem jest zmiana zachowania w czasie (kolejny krok użytkownika), często przy wielu celach naraz (konwersja, retencja, koszt obsługi, ryzyko). W praktyce potrzebujesz dwóch warstw oceny: offline (szybka iteracja i filtrowanie pomysłów) oraz online (weryfikacja przyczynowa w produkcji).

Offline vs online: kiedy co ma sens

• Offline: służy do selekcji kandydatów (modele/reguły/agenci) i wykrywania regresji. Daje szybki feedback, ale jest podatna na bias wynikający z historycznej polityki działania (to, co było pokazywane, determinuje to, co widać w danych).
• Online: mierzy realny wpływ na użytkowników i KPI. Jest wolniejsze i droższe, ale jako jedyne daje wiarygodną odpowiedź „czy to działa”.

Metryki produktowe: nie tylko CTR

Metryki NBA warto układać warstwowo: primary KPI (cel), secondary KPI (koszty/efektywność) oraz guardrails (bezpieczeństwo, ryzyko, jakość doświadczenia). Przykładowe kategorie:

• Wynik biznesowy: konwersja, przychód/ARPU, retencja, aktywacja, zmniejszenie czasu do wartości (time-to-value).
• Efektywność: koszt na efekt (CPA), liczba kroków do celu, obciążenie kanałów (np. contact rate do supportu), wykorzystanie budżetu.
• Długoterminowo: churn, re-engagement, LTV (ostrożnie z krótkimi testami), wskaźniki habituacji/zmęczenia komunikacją.
• Jakość doświadczenia: satysfakcja, skargi, „hide/close” dla komunikatów, opt-out, czas sesji w kontekście (czasem „więcej” to gorzej).

Metryki specyficzne dla rekomendacji akcji

• Take rate / compliance: czy użytkownik wykonał sugerowaną akcję (lub podjął krok w danym kierunku).
• Uplift per action: różnica względem kontroli dla danej klasy akcji (ważne, gdy akcje mają różne koszty i ryzyka).
• Coverage: odsetek przypadków, w których system potrafi zaproponować sensowną akcję (i nie wpada w fallback).
• Diversity / fatigue: powtarzalność rekomendacji (np. limit tej samej akcji w oknie czasu) oraz spadek skuteczności przy ekspozycji.
• Fairness/segment parity: stabilność wyników i ryzyka w segmentach (np. nowe vs powracające konta, różne kanały, regiony).

Offline: metryki modelowe i ocena z logów

W offline’ie stosuje się klasyczne metryki predykcyjne, ale trzeba je interpretować w kontekście NBA:

• Dla rankingu kandydatów: NDCG@k, MAP@k, precision@k (gdy masz etykiety „co zadziałało”).
• Dla predykcji wyniku akcji: AUC/PR-AUC, logloss, Brier score (gdy model przewiduje prawdopodobieństwo).
• Dla polityk uczonych na danych z ekspozycji: metody off-policy evaluation (np. IPS / doubly robust), o ile logi zawierają informację o prawdopodobieństwie wyboru akcji przez politykę zbierającą dane.

Ważne: wysoki wynik offline nie gwarantuje wzrostu online, jeśli dane są silnie zależne od dotychczasowej strategii (brak eksploracji, cenzurowanie alternatywnych akcji).

Online: A/B testy i warianty eksperymentów

W produkcji standardem jest A/B test, ale NBA często wymaga dopasowania do dynamiki decyzji:

• Randomizacja po użytkowniku: najczęstsza, ogranicza „przeciekanie” efektu między wariantami.
• Randomizacja po zdarzeniu/kontekście: przydatna, gdy decyzje są niezależne i chcesz szybszego zbierania danych, ale zwiększa ryzyko interferencji.
• Holdout globalny: stała grupa kontrolna do mierzenia dryfu i efektów długoterminowych.
• Ramp-up: stopniowe zwiększanie ruchu, szczególnie gdy akcje mogą generować koszty lub ryzyko (np. komunikacja wychodząca).
• Testy wielowariantowe: gdy porównujesz kilka polityk (np. reguły vs bandyta vs agent) i chcesz uniknąć serii binarnych testów.

Kalibracja: gdy „p=0.7” ma znaczenie operacyjne

W NBA prawdopodobieństwa są często używane do decyzji progowych (np. „wyślij ofertę tylko gdy szansa sukcesu > X”). Dlatego obok rankingów potrzebujesz kalibracji:

• Metryki kalibracji: Brier score, ECE (expected calibration error), reliability diagram.
• Kalibracja per segment: osobno dla kanałów, nowych użytkowników, różnych godzin/dni (tam, gdzie rozkłady się zmieniają).
• Kalibracja a koszty: progi decyzyjne ustawiaj na podstawie funkcji zysku/ryzyka (nie tylko „optymalnej” metryki statystycznej).

Metryki ryzyka i guardrails (szczególnie ważne dla agentów)

Poza KPI, NBA powinno mieć mierzalne ograniczenia bezpieczeństwa i jakości. Dla podejść generatywnych (agent) te metryki są często równie istotne jak wzrost konwersji:

• Policy compliance rate: odsetek rekomendacji zgodnych z zasadami (np. ograniczenia kanału, budżetu, wymogów prawnych).
• Incident rate: liczba przypadków wymagających interwencji (np. eskalacje do supportu, zgłoszenia, ręczne cofnięcia akcji).
• Safety/factuality checks: odsetek przypadków z błędnym uzasadnieniem, nieuprawnioną obietnicą lub niedozwoloną sugestią.
• Regret / negatywny uplift: udział decyzji, które pogarszają wynik vs kontrola (istotne przy optymalizacji „średniej”).
• Stability: wahania metryk przy zmianach ruchu lub sezonowości; monitoring outlierów i skoków w dystrybucji akcji.

Minimalny „zestaw pomiarowy” dla wdrożenia NBA

• Jednoznaczna definicja sukcesu: co liczy się jako wykonanie następnego kroku i w jakim oknie czasu.
• Instrumentacja ekspozycji: logowanie kontekstu, zaproponowanej akcji, pozycji/rankingu, czasu, kanału i wyniku.
• Primary KPI + 2–4 guardrails: metryki negatywne (koszt, skargi, opt-out, incydenty) muszą być częścią decyzji o wdrożeniu.
• Segmentacja wyników: przynajmniej nowe vs powracające, kanały, oraz segmenty wysokiego ryzyka.

// Przykładowy schemat zdarzenia do oceny NBA (pseudo-JSON)
{
  "event": "nba_exposure",
  "user_id": "...",
  "timestamp": "...",
  "context": {"channel": "in_app", "device": "mobile", "segment": "new"},
  "candidate_actions": ["A1", "A2", "A3"],
  "chosen_action": "A2",
  "policy": "bandit_v3",
  "propensity": 0.18, 
  "guardrails": {"budget_ok": true, "frequency_cap_ok": true}
}

Taki poziom logowania pozwala na podstawową ocenę offline, analizę segmentów oraz rzetelne eksperymenty online, a także na włączenie metryk ryzyka jako warunku wdrożenia.

7. Rekomendacje wdrożeniowe: od MVP do produkcji, monitoring, retraining i zarządzanie zmianą

Wdrożenie „next best action” to w praktyce połączenie decyzji produktowych, danych, infrastruktury i kontroli ryzyka. Niezależnie od tego, czy logika pochodzi z reguł, klasycznego ML czy agenta LLM, sukces zależy od tego, jak szybko potrafisz dostarczyć wartość w MVP, a potem utrzymać jakość i bezpieczeństwo w produkcji.

MVP: zawęź zakres i zapewnij mierzalny efekt

• Zacznij od jednego scenariusza i jednego kanału (np. ekran w aplikacji albo e-mail), z jasno zdefiniowanym celem: konwersja, retencja, redukcja zgłoszeń, wzrost aktywacji.
• Zdefiniuj katalog akcji: krótka lista działań, które są możliwe operacyjnie, mają właściciela biznesowego i można je jednoznacznie wykonać oraz zmierzyć.
• Ustal prostą politykę fallback: co robisz, gdy system nie jest pewny, brakuje danych lub występuje błąd (np. brak rekomendacji, rekomendacja domyślna, eskalacja do bezpiecznej akcji).
• Logowanie od pierwszego dnia: zapisuj ekspozycję rekomendacji, kontekst, wybraną akcję, wynik oraz informację, czy użytkownik widział i mógł wykonać akcję. Bez tego nie będzie wiarygodnej oceny ani iteracji.

Od MVP do produkcji: stabilność, koszt i operacyjność

• Oddziel „decyzję” od „prezentacji”: warstwa decyzyjna wybiera akcję, a warstwa UI/komunikacji pilnuje treści, tonu i zgodności z wymaganiami kanału.
• Wprowadź wersjonowanie polityk/reguł/modeli/promptów oraz konfiguracji. Każda rekomendacja powinna dać się powiązać z konkretną wersją logiki.
• Zadbaj o limity i budżety: kontroluj koszty zapytań, opóźnienia i przepustowość. W praktyce oznacza to limity per użytkownik/segment/czas oraz mechanizmy degradacji jakości (np. prostsza logika przy obciążeniu).
• Zaprojektuj integrację z procesami biznesowymi: NBA często dotyka marketingu, obsługi klienta, ryzyka, produktu. Ustal jasne zasady: kto może dodać akcję, kto ją zatwierdza, kto odpowiada za skutki.

Monitoring: jakość decyzji, „health” systemu i skutki uboczne

• Monitoring techniczny: opóźnienia, błędy, timeouty, odsetek fallbacków, dostępność zależnych usług oraz spójność danych wejściowych.
• Monitoring jakości: stabilność rozkładów wejść (drift), zmiany w proporcjach wybieranych akcji, spadek skuteczności w segmentach, anomalia w wynikach.
• Monitoring zgodności i bezpieczeństwa: sygnały naruszeń polityk (np. rekomendacje niedozwolonych działań), wykrywanie niepożądanych treści, częstotliwość przypadków „nie na temat”.
• Monitoring produktu: fatigue użytkownika (zbyt częste bodźcowanie), wpływ na długoterminowe KPI oraz efekty uboczne (np. krótkoterminowa konwersja kosztem rezygnacji).

Retraining i utrzymanie: cykl życia rekomendacji

• Ustal rytm aktualizacji dopasowany do dynamiki biznesu: szybciej dla szybko zmieniających się ofert/produktów, wolniej dla stabilnych procesów. Kluczowe jest, aby aktualizacja nie była ad-hoc, tylko procesem.
• Waliduj przed wdrożeniem: zestaw minimalnych testów jakości i bezpieczeństwa, kontrola regresji oraz sprawdzenie, czy nowa wersja nie pogarsza krytycznych segmentów.
• Utrzymuj „złoty zestaw” przypadków: stały zbiór reprezentatywnych scenariuszy do porównań między wersjami logiki, aby wychwytywać subtelne pogorszenia.
• Planuj starzenie się akcji: akcje, komunikaty i oferty przestają być aktualne. Dodaj mechanizm wygaszania, przeglądów i wycofywania.

Zarządzanie zmianą: kontrola, odpowiedzialność i szybkość iteracji

• Ustal model governance: kto zatwierdza nowe akcje, kto zatwierdza zmiany logiki, jakie są progi ryzyka wymagające dodatkowej akceptacji.
• Wprowadź procedury awaryjne: szybkie wyłączenie systemu, przełączenie na tryb bezpieczny oraz komunikacja do interesariuszy, gdy wykryjesz niepożądane zachowanie.
• Komunikuj oczekiwania: NBA to nie „autopilot” produktu. Zespół powinien rozumieć, że rekomendacje są hipotezami testowanymi w czasie, a nie jednorazową funkcją.
• Zadbaj o spójność między zespołami: produkt, analityka, inżynieria, compliance i operacje muszą mieć wspólną definicję sukcesu, wspólne KPI oraz wspólny proces wprowadzania zmian.

Praktyczne minimum na start i na skalę

• Na start: wąski katalog akcji, jedno źródło prawdy dla zdarzeń, prosta logika i solidne logowanie oraz eksperymenty.
• Na skalę: wersjonowanie i audyt zmian, pełny monitoring jakości i ryzyka, automatyzacja walidacji, kontrola kosztów i procedury awaryjne.

Najlepsze wdrożenia NBA traktują system rekomendacji jak produkt długoterminowy: z iteracyjną poprawą, stałym nadzorem i jasnymi zasadami odpowiedzialności. Dzięki temu można bezpiecznie przejść od szybkiego MVP do stabilnej, mierzalnej wartości w produkcji.

8. Pipeline automatyzacji ewaluacji: generowanie wariantów, uruchamianie testów, scoring, raporty i CI/CD

Pipeline ewaluacji dla rekomendacji „next best action” to zautomatyzowany proces, który pozwala szybko i powtarzalnie sprawdzać jakość nowych wersji reguł, modeli ML lub agentów (w tym LLM) zanim trafią do użytkowników. Kluczowa różnica względem ad-hoc analiz polega na tym, że pipeline traktuje ewaluację jak produkt inżynieryjny: z wersjonowaniem, kontrolą zmian, bramkami jakości i raportowaniem w rytmie wydań.

Generowanie wariantów: co dokładnie porównujemy

Pierwszym krokiem jest zdefiniowanie „wariantów” (kandydatów do wdrożenia), które mogą obejmować:

• Warianty logiki decyzyjnej: zmiany reguł, priorytetów, ograniczeń, polityk wyboru akcji.
• Warianty modelu: różne algorytmy, hiperparametry, okna czasowe treningu, zestawy cech.
• Warianty promptów i ustawień LLM: instrukcje, format odpowiedzi, temperatura, limity długości, style uzasadnień.
• Warianty guardrails: polityki bezpieczeństwa, filtry treści, limity ryzyka, blokady akcji.

Ważne jest, aby pipeline potrafił odróżnić zmianę „merytoryczną” (wpływającą na decyzję) od „kosmetycznej” (np. drobne przestawienie tekstu), ponieważ te zmiany wymagają innej intensywności testów i innych progów akceptacji.

Uruchamianie testów: od walidacji wejść po testy scenariuszowe

Automatyczne testy powinny obejmować kilka warstw, dzięki czemu błąd jest wyłapywany jak najwcześniej:

• Testy kontraktowe: sprawdzają zgodność schematów wejść/wyjść (np. czy rekomendacja ma wymagane pola, czy spełnia format i ograniczenia).
• Testy deterministyczności i stabilności: oceniają, czy system nie „pływa” przy tych samych danych (szczególnie ważne przy agentach i LLM).
• Testy scenariuszowe: zestaw reprezentatywnych sytuacji użytkownika (w tym przypadki brzegowe), na których porównuje się zachowanie wariantów.
• Testy bezpieczeństwa i zgodności: wykrywają niedozwolone akcje, wrażliwe treści, naruszenia polityk oraz sytuacje wymagające odmowy lub eskalacji.
• Testy obciążeniowe i kosztowe: mierzą opóźnienia, przepustowość oraz koszty wywołań (np. LLM), aby uniknąć regresji operacyjnych.

W pipeline warto rozdzielać testy szybkie (uruchamiane przy każdej zmianie) od testów cięższych (np. nocnych lub przed wydaniem), aby utrzymać tempo iteracji.

Scoring: jak zamienić wyniki w decyzję „przepuszczamy/odrzucamy”

Scoring polega na przypisaniu liczbowych ocen i statusów do wyników testów, tak aby dało się wprowadzić bramki jakości. W praktyce obejmuje to:

• Metryki jakości rekomendacji: trafność, spójność, zgodność z celem, kompletność (na danych offline i/lub w symulacjach).
• Metryki ryzyka: częstość naruszeń polityk, „niebezpieczne” rekomendacje, przekroczenia limitów, niepewność w trudnych przypadkach.
• Metryki stabilności: wariancja odpowiedzi, wrażliwość na drobne zmiany danych wejściowych, powtarzalność.
• Metryki wydajności i kosztu: p95/p99 opóźnienia, czas generacji, liczba kroków agenta, koszt jednostkowy rekomendacji.

Najważniejszą zasadą jest rozdzielenie progów: inne limity stosuje się dla jakości (chcemy wzrostu), a inne dla ryzyka (często wymagamy braku regresji lub spadku do zera w krytycznych kategoriach). Dzięki temu pipeline może automatycznie blokować wdrożenia, które poprawiają metryki biznesowe kosztem bezpieczeństwa lub zgodności.

Raporty: porównania wariantów i diagnoza regresji

Same wyniki testów są mało użyteczne bez raportów, które pokazują co się zmieniło i dlaczego. Raporty pipeline’u powinny umożliwiać:

• Porównanie wariantów w ujęciu agregatów i segmentów (np. nowi vs powracający użytkownicy, różne kanały, różne typy intencji).
• Listę przykładów regresji: konkretne przypadki, w których nowa wersja zachowuje się gorzej, wraz z kontekstem wejściowym.
• Ścieżkę audytu: wersje artefaktów (model/prompt/reguły), konfiguracje testów, daty, autor zmiany, wyniki bramek jakości.
• Podsumowanie operacyjne: wpływ na opóźnienia i koszty, przewidywane ryzyko przekroczenia budżetów.

Dobry raport nie tylko mówi „pass/fail”, ale skraca czas naprawy: wskazuje, czy problemem jest dane wejściowe, warstwa wyboru akcji, warstwa uzasadnienia, czy guardrails.

CI/CD: wpięcie ewaluacji w cykl dostarczania

Automatyzacja ma największy sens, gdy jest elementem CI/CD i wymusza standard jakości:

• Weryfikacja przy zmianie: każda modyfikacja reguł, modelu, konfiguracji lub promptu uruchamia odpowiedni zestaw testów.
• Bramki jakości: pipeline blokuje merge lub wdrożenie, jeśli progi jakości/ryzyka/wydajności nie są spełnione.
• Wersjonowanie artefaktów: modele, prompty i polityki są traktowane jak artefakty wdrożeniowe z możliwością szybkiego rollbacku.
• Stopniowe wdrożenia: możliwość kontrolowanego wypuszczania zmian (np. mały ruch) i automatycznego zatrzymania przy wykryciu nieprawidłowości.

W praktyce pipeline staje się „pasem bezpieczeństwa” dla rozwoju NBA: pozwala iterować szybciej, ale jednocześnie ogranicza ryzyko wdrożenia rekomendacji, które są niezgodne, kosztowne lub niestabilne. Dla systemów opartych o LLM szczególnie ważne jest, aby CI/CD obejmowało zarówno testy jakościowe, jak i testy ryzyka, ponieważ regresje potrafią pojawiać się bez zmian w kodzie (np. przy aktualizacji modelu bazowego lub zależności). Na zakończenie – w Cognity wierzymy, że wiedza najlepiej działa wtedy, gdy jest osadzona w codziennej pracy. Dlatego szkolimy praktycznie.

LLM dla analityków: jak robić „data Q&A” z kontrolą definicji KPI i słownika metryk 25 kwietnia 2026

Ewaluacja multimodalna: jak testować modele, które czytają obrazy, wykresy i skany umów 23 kwietnia 2026