Hasłem przewodnim rozważań na temat stosowalności LLM w biznesie będzie “good enough”, czy dostatecznie dobre. Z jednej strony narzędzia takie, jak GPT, Claude, Grok, czy Llama oferują mnóstwo możliwości, z drugiej strony zapowiadana od roku rewolucja nie nadeszła wciąż. W dalszym ciągu “papierologia” obsługiwana jest przez ludzi, ludzie piszą kod, nawet obsługa klientów realizowana jest głównie przez ludzi.

Abstrahując od niesamowitego tempa adopcji i dojrzewania tej technologii, wszak pojawiła się raptem 3 lata temu, to oczekiwania i tzw. “hype” były dużo większe. Podsycane co i rusz wizją stworzenia ogólnej sztucznej inteligencji AGI.

W ramach stowarzyszenia Spichlerz zrobiliśmy w zeszłym roku badania użyteczności modeli LLM w biznesie i nasunęło się z niego kilka ciekawych wniosków na temat barier. Jedną z głównych przeszkód wdrażania jest bowiem obawa przed halucynacjami. Czyli sytuacja, gdy model językowy udzieli błędnej odpowiedzi i zrobi to z pełnym przekonaniem, że jest ona poprawna.

Teza i definicja jakości LLM

Teza, którą stawiam w tym tekście brzmi: LLM ma szansę być stosowany w zadanym obszarze dopiero, gdy osiągnie pewien minimalny poziom jakości, nazywany dalej “good enough”. Do szerszego opisu idei “good enough” i jej genezy w czasach drugiej wojny światowej odsyłam do mojej najnowszej książki “Bardziej niż Agile”.

Jak zatem zdefiniować jakość LLM? Najczęściej stosowane są benchmarki, które na podstawie zadanym zbiorów danych mierzą poprawność odpowiedzi algorytmów. Przykładem popularnego benchmarku jest AI2 Reasoning Challenge (ARC). Zawiera on zadania z obszaru logiki i ogólnej wiedzy o świecie, które są łatwe dla człowieka, ale sprawiają trudności algorytmom. Innym przykładem jest Massive Multitask Language Understanding (MMLU), który przypomina test wyboru. Testując LLM za pomocą MMLU zadaje się kilkanaście tysięcy pytań i mierzy, w ilu procentach model odpowiedział tak, jakby zrobił to człowiek. HumanEval to model, który mierzy zdolności programistyczne algorytmów przez pokazywanie im zadań i weryfikowanie, czy kod programistyczny, który wygenerowały jest poprawny i realizuje cele.

Zaletą benchmarków jest szybka i statystycznie istotna ocena porównawcza modeli. Dzięki nim widzimy, które modele językowe są lepsze od innych i w jakich zadaniach. Ale zarzut, jaki można spotkać, jest taki, że autorzy LLM mogą starać się trenować modele pod benchmarki. Drugi zarzut jest taki, że benchmarki mierzy abstrakcyjne problemy, a model ma działać w pewnej rzeczywistości biznesowej, czyli innymi słowy, że benchmarki nie mierzą tego, co jest istotne, wartości biznesowej.

Six Sigma a LLM

Jedną z prób mierzenia wartości biznesowej procesu, która korporacje wypracowały 20 lat było Six Sigma. Miara 6sigma pokazuje, że jeżeli dostarczamy klientom produkty bądź usługi za pośrednictwem procesów, to te procesy powinny mieć wyznaczony swój idealny przebieg. Jednak życie nie jest idealne i od tego wzorcowego przebiegu zdarzają się odstępstwa, tzw. Defekty.

Skąd nazwa 6sigma? Otóż mówi ona o tym, jakie jest prawdopodobieństwo popełnienia defektu. Sześć sigma, czyli sześć odchyleń standardowych od miary przeciętnej, mówi, że powinno ono być bardzo, bardzo, bardzo małe. Dosłownie 3,4 błędy na 1 milion możliwości. Praktyka gospodarcza pokazuje, że osiągnięcie poziomu 6 sigma jest mało realne i regularnie widywałem procesy w sektorze usługowym, które miały poziom 1 lub 2 sigma, a produkcyjnym, które miały 3 lub 4 sigma. I mimo tak niskiego poziomu, to było good enough. Klienci korzystali z takich usługi i kupowali takie produkty. A że czasem trzeba było zadzwonić z pretensjami na call center, albo zawieźć produkt do serwisu, to cóż… Konkurencja i tak nie jest lepsza.

Jakość LLM w kontekście sigma

A jak wyglądają LLM, gdyby je zmierzyć za pomocą sigm. Przykładowo Open LLM Leaderboard, benchmark prowadzony przez Hugging Face, zawiera setki modeli. W momencie, w którym pisałem ten artykuł najlepszy model miał średnią oceną zebraną z wielu wskaźników na poziomie 52,08%, a dla samego wskaźnika MMLU ów model miał ocenę 70,03%. Gdyby założyć normalny rozkład prawdopodobieństwa i zinterpretować wynik benchmarku jako szans na dostarczenie dobrego produktu, to 52,08% odpowiadałoby około 1,5 sigmie, albo bardziej obrazowo pół miliona defektów na milion możliwości, a 70,03% - troszkę ponad 2 sigma, czyli niemal 300 000 defektów na milion możliwości.

Napisze obrazowo, gdyby samochody lub pralki miały dzisiejszy poziom jakości najlepszych modeli LLM, to praktycznie co drugi lub co trzeci samochód po zjechaniu z linii montażowej miałby defekty. To nie jest poziom good enough, chyba, że sami majsterkujemy przy aucie i potrafimy w wyniku wielokrotnych iteracji usunąć wszystkie wady. Dla zwykłego kierowcy, byłoby to nie do zaakceptowania.

Zatem na dzisiaj nieco upraszczając analizy modele językowe są na poziomie 1,5 do 2 sigma, 1 na 2 lub 2 na 3 według benchmarków generują dobre rezultaty, reszta to błędy.

Wdrożenia LLM - rodzaje

Czy to jest bariera we wdrażaniu LLM? Wdrożenia LLM podzieliłbym na dwa rodzaje. Pierwszy to taki, w którym człowiek jest użytkownikiem świadomym, że korzysta z algorytmu i jest w stanie zaakceptować jego ułomności. W razie wadliwej odpowiedzi algorytmu po prostu zada pytanie w nieco inny sposób. Czasami nawet przejdzie kilkanaście cykli zanim uzyska pożądany rezultat. Ten rodzaj wykorzystania przypomina wyszukiwanie za pomocą Google. Jak raz nie znajdziemy wyniku, to nieco zmienimy zapytanie i ponownie spróbujemy i tak kilkukrotnie zanim nie przekonamy się, że w internecie chyba nie ma nic na dany temat, albo znajdziemy to, czego szukamy. Nazwę go “multi-shot”.

Drugi to taki, w którym użytkownik ma w nosie, czy po drugiej stronie znajduje się algorytm, czy operator ludzki. Człowiek w tym wypadku oczekuje poprawnego rezultatu za pierwszym razem. Analogiem tu może być telefon na call center dostawcy produktów AGD lub banku, nazwę go “one-shot”. Obie nazwy celowo nawiązują do różnych strategii promptowania.

Multi-shot

Przykładem zastosowań, w których użytkownik ma świadomość, że może być zmuszony wygenerować wiele zapytań jest na przykład generowanie obrazów lub wideo za pomocą LLM. W tym obszarze działa to całkiem nieźle i automatycznie generowane grafiki zawojowały rynek. Sam od ponad roku korzystam z nich do ilustrowania wpisów na moim blogu.

Innym przykładem jest samodzielne promptowanie dla różnych potrzeb od tłumaczeń, przez streszczanie, przez wyszukiwanie treści, po generowanie nowych tekstów. Promptując użytkownik wie, że korzysta z narzędzia i w razie co inaczej wpisze prompta.

W takim przypadku użycia poziom “good enough” może być ulokowany dużo niżej, bo doświadczony użytkownik jest w stanie zrekompensować braki algorytmu. Odnoszę wrażenie, że jeśli jestem w stanie uzyskać pożądany rezultat szybciej niż, gdybym tworzył go ręcznie, to akceptują konieczność wielu iteracji z tekstem lub obrazkiem. W przypadku obrazków możliwość ich generowania na życzenie jest w ogóle objawieniem, bo zupełnie nie umiem rysować.

Jeżeli zaś po kolejnym prompcie efekt jest słaby i uznam, że szybciej bym to sam napisał, to następnym razem nie skorzystam z LLM.

Przy okazji dygresja, czym Google wygrał rynek? Wcale nie jakością wyszukiwania, tylko szybkością. Jego poprzednicy dostarczali nawet lepsze rezultaty, ale trzeba było czekać kilka minut na wyświetlenie wyniku. W wypadku Google w tym samym czasie mogłem zadać kilka zapytań, aż znalazłem to, co chciałem szybciej. Z czasem Google podciągnął również jakość wyszukiwania.

W przypadku dostawców LLM ten, kto mimo wielu iteracji dostarczy pożądany efekt szybciej, niż w drodze ręcznej pracy, ten wygra. Próbą automatyzacji wielu prób naraz jest strategia chain of thought albo tree of thought, gdzie wysyła się wiele równoległych promptów i z nich konsoliduje lepszą odpowiedź.

One-shot

W przypadku użytkowników, którzy oczekują dobrego rezultatu za pierwszym razem, problem good enough jest dużo większy. Wyobraźcie sobie, że macie chatbota, który udziela wartościowych odpowiedzi tylko co drugiemu klientowi. Co więcej, jeżeli ten sam klient zapyta o cztery rzeczy, to w dwóch przypadkach otrzyma błędną odpowiedź, co spowoduje, że jego postrzeganie obsługi będzie w całości negatywne.

Tu pojawia się pytanie, jak często można zawieźć klienta w obsłudze, że od nas nie odszedł. Czy 9 a 10 pozytywnych konwersacji to dużo, czy mało?

Albo inny przykład, wyobraź sobie, że organizacja wdrożyła LLM do przygotowywania umów dla podwykonawców. I okazuje się, że stosując najlepszy model na rynku, który w benchmarku ma 90%, osiągamy 2,8 sigma, albo około 100 tysięcy defektów na milion możliwości. Czy to wystarcza, aby bezrefleksyjnie zaufać LLMowi, czy jednak przygotowaną automatycznie umowę i tak musi zweryfikować prawnik? A jeżeli i tak musi zweryfikować, to czy warto ponosić koszt wdrożenia LLM?

Faktory wpływające na jakość LLM

Czynnikiem, który obniża wymogi good enough jest możliwość automatycznej weryfikacji wyniku. W sytuacji, gdy w oczywisty sposób użytkownik widzi, czy dostał dobrą, czy złą odpowiedź, ryzyko popełnienia błędu na podstawie odpowiedzi LLM jest dużo niższe, a więc i bariera wdrożenia LLM w organizacji dużo niższa.

Przykładowo, gdy model wygeneruje mi zdjęcie człowieka z dwunastoma palcami, albo gdy stworzy mi kod, który nie kompiluje się, to od razu wiem, że coś jest nie tak i mogę ponowić zapytanie. Ale gdy otrzymam umowę z błędem prawnym, albo gdy tłumaczenie tekstu na indonezyjski będzie zawierać przekręcone znaczenie, to mam problem.

Kolejnym czynnikiem poprawiającym jakość jest wplatanie do promptów treści pochodzących z danej organizacji lub wręcz danego procesu. Tu kłania się architektura CAG lub RAG, w której częścią prompta są teksty zawierające potencjalnie poszukiwaną odpowiedź. Słabością tego podejścia jest to, że gdy w prompcie jednak nie ma odpowiedzi, to jest ryzyko, że LLM będzie halucynował.

Podsumowanie

Zatem podsumowując, wydaje mi się, że w przypadku wdrożeń typu multi-shot oraz w sytuacjach, w których użytkownik jest w stanie samodzielnie ocenić jakość wyniku, LLMy są już na poziomie good enough. Tam warto tylko przeliczyć koszt wdrożenia i porównać do kosztu operacyjnego ponoszonego dzisiaj i podejmować decyzję o zastosowaniu modeli językowych.

Natomiast tam, gdzie użytkownik nie wybacza błędów, one-shot, warto albo go edukować, że przecież rozmawia z automatem, że powinien się sam bardziej postarać itd., albo dwa razy przeanalizować pomysł wdrożenia LLM.

To w takim razie kiedy, ta technologia osiągnie poziom, gdy będzie działać równie dobrze, jak produkcja aut. Przykładowo weźmy jedno z najgorszych aut według rankingu TUV, 14,7% dwuletnich Tesli nie przechodzi badań technicznych. Rzeczywisty wskaźnik awaryjności musi być dużo wyższy, bo aby auto nie przeszło badań, usterka musi być naprawdę poważna i tylko te poważne usterki pokazuje 14,7%. Ale te 14,7%, czyli 85,3% dobrych dwuletnich aut oznacza poziom około 2,5 sigma. Żaden model nie zbliżył się w średniej ocenie LLM Leaderboard do tego poziomu, ale w przypadku pojedynczych wskaźników już jest lepiej.

Przykładowo wskaźnik IFEval LLama3.3-70B ma na poziomie 89,98%, czyli jest mniej awaryjna niż dwuletnia Tesla dla tego typu zadań. IFEval mierzy zdolność modelu do interpretacji złożonych poleceń, czyli czy model „rozumie”, czego dokładnie od niego oczekujemy i czy umie podążać za tymi instrukcjami. Zatem jeżeli potrzebujemy model dostarczał odpowiedzi spełniające zadane kryteria w prompcie, np. “napisz mi odpowiedź składającą się z 20 słów”, to wg tego benchmarku już możemy mu zaufać.

Obserwując tempo rozwoju LLM, mogę nieśmiało przewidywać, że poziom Tesli na uśrednionych wskaźnikach benchmarkowych najlepsze modele osiągną za rok lub dwa lata. Tylko, że benchmarki też się zmieniają i z roku na rok same testy są coraz bardziej krytyczne i coraz lepiej rozumiemy, jak wiele brakuje modelom językowym do naszego sposobu myślenia.

Co to oznacza dla wdrożeń LLM w praktyce? Zanim zaczniemy wdrażać warto przeanalizować, do jakich celów chcemy wykorzystać model językowy, a potem znaleźć benchmark, który mierzy podobne zadania. Jeżeli w tym benchmarku, znajdziemy model, który ma jakość na poziomie good enough, to jesteśmy w domu. Jeżeli jednak nawet najlepszy model odstaje od oczekiwań, to poczekałbym z wdrażaniem sztucznej inteligencji.

W trakcie wdrażania warto opracować zestaw testowych promptów i wzorcowych odpowiedzi. Po to, aby przed upublicznieniem rozwiązania sprawdzić, ile jest defektów i czy użytkownicy zaakceptują ten poziom jakości.

W tym artykule skupiam się na LLM, czyli dużych modelach językowych, ze względu na łatwość i uniwersalność ich implementacji w biznesie, natomiast przy odrobinie wyobraźni można rozciągnąć konkluzje tu zawarte na inne obszary sztucznej inteligencji jak machine learning.

Wróć do wszystkich artykułów