Salesforce i AI: deterministyczne prompty zamiast loterii

Największy problem z AI w procesach biznesowych nie polega na tym, że model czasem się myli, tylko że potrafi odpowiedzieć inaczej na ten sam prompt.

W Salesforce odpowiedzi mają być powtarzalne, więc punkt ciężkości przesuwa się z samego generowania tekstu na kontrolę promptu, parametrów modelu i sposobu osadzenia tego w automatyzacji.

Prompt jako szablon, nie luźna instrukcja

Jeśli model dostaje zbyt szerokie pole manewru, zaczyna rosnąć wariancja odpowiedzi. Dlatego prompt nie może być ogólnym poleceniem w stylu „napisz podsumowanie” albo „zaproponuj odpowiedź”. Ma prowadzić model do wąskiego, jasno opisanego wyniku.

Tu wchodzą twarde ograniczenia: konkretne wymagania, oczekiwana struktura i przykłady. Im mniej miejsca na interpretację, tym mniejsze ryzyko, że output rozjedzie się między jednym uruchomieniem a kolejnym. W zespołach, które budują automatyzacje dla obsługi klienta albo sprzedaży, to robi różnicę bardzo szybko – szczególnie gdy prompt trafia do Flow i przestaje być eksperymentem odpalanym ręcznie.

W polskich orgach ten problem widać zwłaszcza tam, gdzie AI ma wejść w powtarzalną pracę operacyjną. Jeśli case summary raz ma trzy zdania, a raz osiem, albo lead outreach raz trzyma ton marki, a raz odpływa, sam model staje się trudny do wpięcia w proces.

Temperature i top-k ograniczają losowość modelu

Samo dopracowanie promptu nie wystarcza. Druga warstwa kontroli siedzi w parametrach generowania. Niska albo zerowa temperature ogranicza losowość przy wyborze kolejnych tokenów, więc model częściej wybiera najbardziej prawdopodobną kontynuację zamiast próbować kilku wariantów.

Podobnie działa ograniczenie albo wyłączenie samplingu, w tym top-k. Chodzi o to, żeby model nie losował z szerokiego zestawu możliwych odpowiedzi, tylko trzymał się najstabilniejszej ścieżki. Kreatywność spada, ale w procesie biznesowym to zwykle uczciwa wymiana. Przy automatycznym wsparciu agenta service albo wiadomościach do leadów bardziej liczy się przewidywalność niż błyskotliwy styl.

Ten sam kierunek przewija się też w temacie ochrony danych w pipeline AI, gdzie użyteczność modelu zależy nie tylko od jakości odpowiedzi, ale też od kontroli nad całym mechanizmem generowania.

Fine-tuning i dane pod konkretny workflow

Salesforce dokłada do tego fine-tuning oraz prompt engineering dopasowany do konkretnych zastosowań. Model uczy się na kuratorowanych danych i przykładach, które odpowiadają realnym wymaganiom workflow. Efekt ma być prosty: mniej odchyleń od oczekiwanego formatu i mniej zaskoczeń w treści.

To ważne rozróżnienie. Nie chodzi o model, który „umie wszystko”, tylko o model, który w danym procesie odpowiada w przewidywalny sposób. Przy wdrożeniu oznacza to mniej wyjątków do obsługi, mniej ręcznych poprawek i łatwiejsze testowanie. Jeśli prompt ma działać jak komponent automatyzacji, trzeba go oceniać podobnie jak każdy inny element procesu.

Flow dostaje AI, które da się osadzić w procesie

Kiedy deterministyczne szablony promptów trafiają do frameworków automatyzacji takich jak Flow, AI przestaje być czarną skrzynką. Nadal generuje treść dynamicznie, ale w granicach, które da się przewidzieć. Agent obsługi może dostać spójne sugestie odpowiedzi albo stabilne podsumowanie sprawy. Zespół sprzedaży może automatyzować wiadomości do leadów bez ciągłego poprawiania tonu i układu tekstu.

To spina się z szerszym ruchem wokół AI osadzonego w CRM i workflow, gdzie wartość nie bierze się z samego modelu, tylko z tego, czy da się go bezpiecznie i przewidywalnie włączyć do działania orga.

Jeśli AI ma wejść do procesu, sprawdzenie samej jakości pojedynczej odpowiedzi nie wystarczy. Trzeba uruchomić ten sam prompt wielokrotnie, porównać odchylenia, ustawić parametry generowania i dopiero wtedy wkładać całość do Flow. Bez tego prompt zostaje demo. Z tym podejściem zaczyna działać jak szablon produkcyjny.