Czy GPT-4 w logice aplikacji produkcyjnych ma sens?

Generatywna Sztuczna Inteligencja (GenAI) już na tym etapie wywiera zauważalny wpływ na rynek pracy, a wczesne estymacje dalszego rozwoju sytuacji omówione w GPTs are GPTs pobudzają wyobraźnię.

Kilka tygodni temu, pojawił się także szkic publikacji mającej na celu sprawdzenie faktycznego wpływu AI na efektywność pracowników. Pojawiające się wnioski mówią o 25% większej wydajności i 40% większej jakości wykonywanych zadań (o ile te dotyczyły obszarów w których obecne AI faktycznie może pomóc) w porównaniu do osób niekorzystających z tej technologii.

Wygląda więc na to, że mądre korzystanie np. z ChatGPT ma pozytywny wpływ na ogólną efektywność realizowanych zadań. Pytanie więc, czy tak samo wygląda to w przypadku integracji Dużych Modeli Językowych w kodzie aplikacji i ogólnym budowaniu produktów AI, wykraczających poza robiące dobre pierwsze wrażenie prototypy.

Kontekst: Droga od Prototypu na Produkcję

Na kilka dni po premierze ChatGPT korzystałem z platform.openai.com i modelu text-davinci-002 za pośrednictwem API. Skuteczność, wydajność i stabilność tego modelu była praktycznie minimalna. W sieci brakowało jakichkolwiek przykładów zastosowania i narzędzi, a dokumentacja OpenAI była niepełna. W dodatku nawet proste operacje generowały znaczące koszty i już na etapie eksperymentów, rachunki OpenAI przekraczały u mnie kilkaset złotych. Wówczas o zastosowaniu produkcyjnym nie było mowy.

Na przestrzeni już niemal roku, sytuacja drastycznie się zmieniła:

• Pojawiło się GPT-3.5-Turbo, GPT-3.5-Turbo-16k, GPT-4
• OpenAI udostępniło wersje modeli wyspecjalizowane w tzw. Function Calling
• Pojawiła się możliwość fine-tuningu wersji GPT-3.5-Turbo
• Koszty znacząco spadły (choć produkcyjnie łatwo wygenerować duży rachunek)
• Znacznie wzrosła wydajność, skuteczność i stabilność API
• Rozwinęły się narzędzia (np. LangChain czy LlamaIndex), ale są jeszcze na wczesnych etapach rozwoju
• Rozwinęły się modele Open Source oraz plany Enterprise, które adresują (lub zaczynają adresować) wyzwania związane z prywatnością
• Pojawiły się jakościowe źródła wiedzy oraz techniki pracy, ułatwiające start oraz rozwój aplikacji
• Zainteresowanie biznesu jest wysokie, jednak wyższy jest ogólny poziom niezrozumienia możliwości i ograniczeń technologii z jaką mamy do czynienia
• Nadal jest ogromna przestrzeń do odkrywania nowych technik pracy i sterowania zachowaniem modeli, szczególnie w przypadku integracji LLM (Large Language Model) z kodem aplikacji

Powyższe punkty opieram o swoje własne doświadczenie w pracy nad projektami heyalice.app do której dostęp ma już ~3000 osób oraz asystenta eduweb.pl pracującego na ~25 milionach znaków treści. Duża część mojego doświadczenia z modelami AI pochodzi także z rozwoju rozbudowanej wersji Alice — asystentki AI dostępnej dla mnie na komputerze, telefonie i zegarku, dysponującej długoterminową pamięcią oraz zdolnością do samodzielnego posługiwania się ~50 akcjami (można to zobaczyć w praktyce na screenach w tym wątku).

Sterowność, przewidywalność i skuteczność obecnych modeli

Budowanie aplikacji wykorzystujących w swojej logice modele językowe, wymaga zrozumienia ich obecnych możliwości oraz ograniczeń. Posiadając taką wiedzę, możemy odpowiedzieć na pytanie, czy w ogóle warto korzystać z AI w naszym projekcie. Bardzo pomocne może być w tym zapoznanie się z prezentacją State of GPT, z której pochodzi poniższy, bardzo prawdziwy slajd.

Widzimy więc tutaj różnej kategorii problemy wynikające z samej natury modeli, oraz ich obecnego poziomu rozwoju. Generowanie błędnych odpowiedzi, błędy logiczne, niepodążanie za instrukcjami, ograniczenie bazowej wiedzy i podatności na ataki. Na wszystkie te punkty nie ma obecnie odpowiedzi, które w pełni je adresują, ale dysponujemy technikami umożliwiającymi zmniejszenie ich znaczenia. Pomimo tego, ogólne rekomendacje uwzględniają wykluczenie zastosowań modeli z krytycznych elementów procesów, traktowanie ich jako źródło inspiracji oraz zachowanie nadzoru i utrzymywanie w roli "copilota/asystenta", a nie agenta (agentem określamy systemy zdolne do autonomicznego działania).

Bezpośrednio z powyższych problemów wynikają kolejne konsekwencje, które łączą się z nadal wczesnym etapem rozwoju narzędzi umożliwiających interakcję z modelami z poziomu kodu. Przykładowo dopiero od kilku miesięcy mamy wygodną obsługę strumieniowania tokenów (w uproszczeniu, są to fragmenty słów) generowanych przez model, czyli mechaniki mającej istotny wpływ na doświadczenia użytkownika (UX). Podobnie też techniki przetwarzania danych na potrzeby LLM czy projektowania promptów, są jeszcze na etapie wczesnej eksploracji i mówimy raczej o wiedzy będącej zestawem rekomendacji, niż konkretnymi odpowiedziami na pytania.

Mając to wszystko na uwadze, można dojść do wniosku, że nawet tak potężny model jak GPT-4 nie nadaje się do produkcyjnych zastosowań. Ale czy na pewno?

Duże Modele Językowe, np. GPT-4 zostały zaprojektowane z myślą o przetwarzaniu i generowaniu danych. Patrząc z szerokiej perspektywy na programowanie i logikę aplikacji, które projektujemy na co dzień, możemy zauważyć, że są to systemy w których również chodzi o przetwarzanie i generowanie danych, oraz ich przepływ pomiędzy klientem a serwerem. Oznacza to, że mamy tutaj do czynienia z narzędziem zdolnym do adresowania dokładnie znanych już problemów, ale w nowy sposób. Andrej Karpathy w jednym ze swoich postów mówi o porównaniu LLM do całego systemu operacyjnego, który jest jeszcze na bardzo wczesnym etapie rozwoju.

Jeżeli jednak spojrzymy na konkretne problemy, które może adresować model taki jak GPT-4, to dochodzimy do bardzo interesującej listy rozwiązań, które możemy stosować już teraz.

• Narzędzia do tłumaczeń, korekty, podsumowań, klasyfikacji czy wzbogacania treści, wspierające pracę osób realizujących żmudne manualne aktywności, których dotychczas nie mogły być realizowane z pomocą kodu czy automatyzacji
• Interaktywne wyszukiwarki umożliwiające rozmowę z bazami danych (obecnie określane jako RAG lub HSRAG), ułatwiające pracę działów sprzedaży, marketingu czy obsługi klienta
• Narzędzia wspierające monitorowanie i nadzorowanie procesów wykraczające poza schematy możliwe do opisania kodem, bezpośrednio powiązane z przetwarzaniem naturalnego języka, oferujące korzyści związane z utrzymaniem standardów i jakości realizowanych procesów
• Rozwiązania działające z różnymi formatami treści (tekst /obrazy / audio / wideo), a nawet wchodzące w interakcję z urządzeniami

W każdym z wymienionych zastosowań mówimy tutaj o wspieraniu, optymalizacji lub częściowej automatyzacji procesów. Należy to mieć na szczególnej uwadze, ponieważ zwykle zapytania klientów wchodzą w obszary pełnej automatyzacji oraz bezpośredniego kontaktu modelu z klientem (np. poprzez czat na stronie). Wówczas warto rozważyć edukację mającą na celu uświadomienie potencjalnych zagrożeń i zasugerowanie rozwiązań funkcjonujących jako wsparcie istniejących procesów. Korzyści w postaci oszczędności czasu i pieniędzy oraz wzrostu jakości nadal będą znaczące, a ryzyko i trudność wdrożenia zdecydowanie niższe.

Bezpieczeństwo i prywatność

W kontekście biznesowym i zastosowaniach produkcyjnych, do gry wchodzą dodatkowe wątki, które można pominąć przy narzędziach budowanych na własne potrzeby.

Pierwszy do gry wchodzi wątek bezpieczeństwa, który na ten moment nie został w pełni zaadresowany. Jego rolę podkreślamy poprzez grę, w której można wziąć udział na stronie game.aidevs.pl. Pomimo tego, że została ona zaprojektowana tak, aby celowo uwzględnić pewne luki, to i tak obrona przed atakami w przypadku LLM jest bardzo trudna.

Aby zredukować ryzyka związane z wyzwaniami z obszaru bezpieczeństwa, należy podjąć następujące kroki:

• Jeżeli to możliwe, dobrze unikać bezpośredniego kontaktu użytkownika końcowego z LLM. Mowa więc tutaj o narzędziach działających wewnątrz firmy, które obsługują osoby posiadające niezbędną wiedzę na ich temat
• W przypadku systemów w których obecna jest bezpośrednia interakcja z użytkownikiem końcowym, konieczne jest wdrożenie pełnego monitorowania systemu, moderacji, oraz KYC (Know Your Customer), a także rekomendacji opisanych na stronie OpenAI
• Budując system zabezpieczeń warto uwzględnić programistyczne techniki, które zwiększają szansę na powstrzymanie ewentualnych ataków i które mogą wykorzystywać dodatkowe prompty np. weryfikujące czy zapytanie lub generowana odpowiedź jest zgodna z naszymi zasadami poprzez elementy Constitutional AI
• No i ostatecznie mamy także same prompty i zawarte w nich instrukcje, które powinny prowadzić model w taki sposób, by odmawiał realizowania poleceń, które nie są zgodne z naszymi założeniami. Chociaż obecnie stosunkowo łatwo można je ominąć, tak już w przypadku nowszych wersji modelu (np. GPT-4), sytuacja zauważalnie się poprawia.

Poza bezpieczeństwem, w zastosowaniach biznesowych do gry wchodzi jeszcze prywatność danych, którą obecnie można adresować na trzy sposoby:

• Poprzez plany Enterprise (np. Azure OpenAI Service czy ChatGPT Enterprise) dedykowane większym firmom
• Poprzez programistyczne rozwiązania i samą strukturę systemu, która może uwzględniać ograniczenie dostępu do wrażliwych danych firmowych. Mowa chociażby o wykorzystaniu opisów i/lub tagów dokumentów, do których model będzie mieć dostęp i będzie mógł się posługiwać zabezpieczonymi linkami do nich, ale nie będzie miał dostępu do samej treści
• Poprzez modele Open Source i możliwość ich dostosowania do własnych potrzeb poprzez fine-tuning
• Poprzez zrezygnowanie z jakiegokolwiek kontaktu modelu z danymi wrażliwymi i skupienie się na obszarach dostępnych publicznie (np. dokumentacje narzędzi czy ogólna wiedza firmowa)

Oczywiście powyższe punkty dotyczą pracy z gotowymi modelami, np. OpenAI i dość wysokopoziomowego poruszania się w obszarze Generative AI.

Wdrożenie rozwiązań AI do produktów oraz w procesy firmowe

Patrząc na zrealizowane przeze mnie projekty wykorzystujące, bądź nawet bazujące na Dużych Modelach Językowych, widać jasno, że 80-90% kodu uwzględnia dokładnie takie same mechaniki, jak w przypadku aplikacji nie mających nic wspólnego z AI.

Routing, middleware, warstwa serwisowa, repozytoria, encje, walidacje, uwierzytelnienie, autoryzacja, struktury bazy danych czy ogólna logika, nie różnią się praktycznie niczym. Dopiero na końcowym etapie wchodzą do gry prompty, strukturyzowanie danych czy mechaniki wyszukiwania uwzględniające embedding oraz bazy wektorowe (aczkolwiek to również bardzo przypomina pracę z np. Algolią).

Oznacza to mniej więcej tyle, że obecność LLM w kodzie aplikacji  jest elementem większej układanki, który wprost powinien być wspierany logiką opisaną programistycznie. Mówimy tutaj o pewnego rodzaju wzajemnym uzupełnianiu: ustrukturyzowany kod pomaga w pracy z niedeterministyczną naturą modeli, a przetwarzanie i generowanie języka naturalnego daje przestrzeń do adresowania ograniczeń logiki opisywanej kodem.

Poza tym, w aplikacjach korzystających z Dużych Modeli Językowych, zwykle bardzo istotną rolę odgrywa organizacja i przetwarzanie danych. Poniżej znajduje się przykład dokumentu, który powstał na podstawie treści strony aidevs.pl. Aby móc wykorzystać go na potrzeby dynamicznego kontekstu dla LLM, treść została podzielona na mniejsze fragmenty, opisana metadanymi oraz zoptymalizowana poprzez placeholdery dla adresów URL.

Ostatnim z najbardziej istotnych elementów produkcyjnego zastosowania LLM jest utrzymanie stabilności systemu oraz kontrola kosztów. Niestety na ich omówienie oraz znaczne pogłębienie wcześniejszych, nie mamy już więcej czasu. Dlatego jeżeli chcesz rozwinąć swoją wiedzę i umiejętności związane z praktycznym zastosowaniem modeli OpenAI, to serdecznie zapraszamy Cię do AI_Devs 2.

AI_Devs 2 — Połącz GPT-4 z logiką aplikacji i automatyzacji

23 października startuje druga edycja AI_Devs, 5-tygodniowego, praktycznego szkolenia z łączenia narzędzi Generative AI (w szczególności modeli OpenAI) z logiką aplikacji oraz narzędziami automatyzacji. Mówimy więc tutaj o bezpośrednim rozszerzeniu wszystkich wymienionych wyżej zagadnień oraz stosowania LLM (eng. Large Language Model) zarówno w celu optymalizacji swojej codziennej pracy i nauki, jak i zastosowań biznesowych.

‍AI_Devs 2 całkowicie rezygnuje z wykorzystania ChatGPT na rzecz bezpośredniego połączenia z modelami poprzez API. Szkolenie ma formę tzw. kursu kohortowego, a jego główna treść ma formę rozbudowanych wpisów, przeplatanych materiałami wideo, przykładami kodu i praktycznymi zadaniami.

W pierwszej edycji szkolenia wzięło udział 950 osób. Ponad 850 osób dołączyło już do drugiej edycji – zapowiada się grubo ponad 1000!

AI Devs 2 współtworzymy w zespole:

• Adam "overment" Gospodarczyk (YouTube)
• Jakub "unknow" Mrugalski (YouTube)
• Mateusz Chrobok (YouTube)

W drugiej edycji dołączą do nas również goście specjalni!

• Kacper Łukawski (Developer Advocate w Qdrant)
• Bartek Pucek (CEO Forward Operators AI Lab)
• Bartek Rozkrut (CTO & Co-founder Edward.ai)

Do 18 października trwa promocja -300 zł, zmniejszająca cenę szkolenia do 1490 zł brutto. Więcej informacji na temat szkolenia, opinie uczestników i uczestniczek oraz szczegółową agendę, znajdziesz na stronie poniżej, zapraszamy! :)

👉 Dołącz teraz do AI_Devs