Tworzenie produktu opartego na generatywnej sztucznej inteligencji: co warto wiedzieć na początku

Wprowadzenie

Sztuczna inteligencja generatywna jest łatwa do wypróbowania, ale znacznie trudniej jest przekształcić ją w produkt, na którym ludzie mogą polegać. Zespół może w ciągu kilku dni połączyć model językowy z interfejsem czatu. Jednak sprawienie, by interfejs ten obsługiwał rzeczywiste zapytania klientów, przestrzegał uprawnień dostępu, współpracował z danymi firmowymi i radził sobie z błędnymi odpowiedziami, to zupełnie inna sprawa.

Dla firm rozważających wykorzystanie generatywnej sztucznej inteligencji w zastosowaniach biznesowych pierwszą decyzją nie jest wybór modelu. Chodzi o to, czy dany problem w ogóle wymaga stworzenia nowego produktu. Gotowe narzędzia oparte na sztucznej inteligencji mogą zaspokoić większość potrzeb, natomiast niestandardowe wdrożenie ma większy sens, gdy istniejące oprogramowanie nie jest w stanie dostosować się do wymaganego przepływu pracy. Firmy rozważające to drugie rozwiązanie mogą skonsultować się z inżynierami ds. generatywnej sztucznej inteligencji z firmy SysGears, aby zbadać wymagania techniczne produktu zbudowanego wokół ich konkretnego przypadku użycia.

Produkt oparty na generatywnej sztucznej inteligencji to znacznie więcej niż tylko umieszczenie modelu za interfejsem z logo firmy. Model może obsługiwać język, ale reszta aplikacji decyduje o tym, z jakich informacji może czerpać, czy może współpracować z innym oprogramowaniem oraz co się stanie, gdy jego odpowiedź nie będzie trafna. Te decyzje wpływają na użyteczność produktu w takim samym stopniu, jak sam wybór modelu.

Wewnętrzny asystent może wprowadzać pracowników w błąd, jeśli pobierze nieaktualny dokument regulaminowy. Jeśli zapewni mu się dostęp do danych klientów, uprawnienia dostępu staną się równie ważne jak jakość odpowiedzi. Jeśli aplikacja może również modyfikować dane, przekonująca, ale błędna odpowiedź może spowodować realne szkody.

Nie są to szczegóły, które można poprawić po uruchomieniu. Mają one wpływ na architekturę, nakład pracy inżynieryjnej oraz koszty rozwoju sztucznej inteligencji, w tym na to, co jest potrzebne do utrzymania produktu w działaniu. Firma powinna je przeanalizować przed podjęciem decyzji o rozpoczęciu prac rozwojowych, kiedy wciąż istnieje możliwość zawężenia zakresu projektu lub stwierdzenia, że istniejące narzędzie wystarczy do wykonania zadania.

Zacznij od problemu wymagającego generatywnej sztucznej inteligencji

Przekonująca prezentacja może przesłonić dość zwyczajny problem biznesowy. Jeśli na przykład pracownicy poświęcają zbyt dużo czasu na przeszukiwanie wewnętrznej dokumentacji, wystarczający może być system wyszukiwania semantycznego. Jeśli muszą interpretować długie dokumenty, wyodrębniać konkretne szczegóły i tworzyć odpowiedzi na podstawie informacji z kilku źródeł, model językowy może wnieść coś bardziej istotnego.

To rozróżnienie ma znaczenie od samego początku. Generatywna sztuczna inteligencja sprawdza się, gdy oprogramowanie musi nadać sens chaotycznym, nieuporządkowanym materiałom lub sporządzić coś, co zależy od kontekstu. Jednak w przypadku zadań podlegających ustalonym regułom zwykły skrypt jest często tańszy w eksploatacji i łatwiej mu zaufać.

Weźmy na przykład dystrybutora, który ma do czynienia ze stałym napływem zapytań dotyczących produktów. Klienci opisują ten sam produkt na wiele różnych sposobów, więc aplikacja oparta na generatywnej sztucznej inteligencji mogłaby zinterpretować ich prośby, wyszukać odpowiednie specyfikacje i przygotować odpowiedź. Stan zapasów to już inna sprawa. Dane te muszą pochodzić z aktualnych rejestrów magazynowych, a podana cena musi być zgodna z zasadami wyceny obowiązującymi w firmie, a nie z dowolną kwotą, jaką akurat wygeneruje model.

Warto jasno określić ten podział zadań: niech model zajmuje się językiem, a przewidywalne operacje, o ile to możliwe, pozostawmy konwencjonalnemu oprogramowaniu.

Zanim rozpocznie się jakikolwiek proces rozwoju, należy dokładnie określić, co faktycznie powinno ulec poprawie. Być może pracownicy działu sprzedaży będą potrzebowali mniej czasu na przygotowanie oferty; być może klienci otrzymają odpowiedź bez konieczności oczekiwania na kontakt z pracownikiem obsługi klienta. Niezależnie od tego, należy udokumentować, jak proces ten przebiega obecnie. W przeciwnym razie zespół może skończyć świętując wdrożenie nowego interfejsu opartego na sztucznej inteligencji, nie wiedząc, czy faktycznie ułatwiło to pracę.

Tworzyć czy kupować: jakiej kontroli faktycznie potrzebujesz?

Decyzja „zbudować czy kupić” jest często przedstawiana jako wybór między pełną własnością a wygodą. W praktyce istnieje kilka opcji pośrednich.

Gotowe narzędzia AI stanowią rozsądny punkt wyjścia, gdy firma potrzebuje znanych funkcji, takich jak pomoc w pisaniu, podsumowania spotkań, analiza dokumentów lub badania ogólnego przeznaczenia. Produkty te zazwyczaj wymagają mniejszego nakładu prac inżynieryjnych, a ich dostawcy zajmują się większością infrastruktury bazowej. Firma może sprawdzić, czy pracownicy uznają daną funkcję za przydatną, bez konieczności finansowania od razu dedykowanego projektu rozwojowego.

Kłopoty zaczynają się, gdy ogólne narzędzie musi zostać dostosowane do procesu, do którego nie zostało zaprojektowane. Może na przykład nie współpracować ze starszą bazą danych lub nie stosować odpowiednich uprawnień dostępu, gdy pracownicy pełnią różne role. Jego wyniki mogą również wymagać przekształcenia, zanim inny system biznesowy będzie mógł z nich skorzystać. Interfejsy API i opcje konfiguracyjne mogą pomóc w wypełnieniu tych luk, ale niekoniecznie uwzględnią specyfikę ustalonego przepływu pracy.

Niestandardowy produkt oparty na sztucznej inteligencji staje się bardziej uzasadniony, gdy sam przepływ pracy stanowi przewagę konkurencyjną, gdy istniejące produkty nie są w stanie spełnić istotnych wymagań lub gdy aplikacja wymaga ścisłej integracji z własnymi danymi i systemami wewnętrznymi.

Trzecią opcją jest stworzenie własnej aplikacji w oparciu o model hostowany przez zewnętrznego dostawcę. Firma opracowuje interfejs i logikę działania, integruje system z istniejącym oprogramowaniem oraz ustala własny sposób testowania wyników. Dostęp do samego modelu odbywa się za pośrednictwem interfejsu API, więc nie ma potrzeby szkolenia modelu bazowego od podstaw. Daje to firmie swobodę dostosowania produktu do własnego przepływu pracy, choć nadal zależy to od cennika dostawcy, dostępności modeli i limitów usług.

Ta ostatnia różnica zasługuje na uwagę. Opracowanie niestandardowej aplikacji opartej na sztucznej inteligencji a stworzenie nowego modelu AI to dwa różne przedsięwzięcia. Trenowanie modelu bazowego wymaga znacznych zasobów obliczeniowych, specjalistycznej wiedzy, odpowiednich danych oraz ciągłego eksperymentowania. Większość firm nie musi brać na siebie tego obciążenia. Istniejący model, uzupełniony o funkcję wyszukiwania w dokumentach firmowych lub starannie zaprojektowany dostęp do narzędzi, może okazać się wystarczający.

Wybierz architekturę dostosowaną do procesu pracy

Gdy uzasadnienie biznesowe jest już jasne, kolejnym wyzwaniem jest podjęcie decyzji o tym, jak aplikacja będzie działać. Model jest tylko jednym z elementów i niekoniecznie tym, który pochłania najwięcej czasu inżynierów.

W przypadku asystenta dokumentacyjnego często warto rozważyć generowanie wzbogacone o wyniki wyszukiwania (RAG). Zamiast polegać wyłącznie na tym, czego model nauczył się podczas szkolenia, aplikacja pobiera odpowiednie fragmenty z zatwierdzonego źródła informacji i dołącza je do zapytania. Następnie model formułuje odpowiedź, korzystając z tych materiałów.

Odpowiedzi oparte na wewnętrznych zasadach lub aktualnych informacjach o produktach mogą być bardziej trafne, pod warunkiem że wyszukiwanie działa prawidłowo. Nie jest to jednak pewne. Wyszukiwanie może wyświetlić nieaktualny dokument, pominąć kluczowe zastrzeżenie lub dostarczyć modelowi fragment, który ten następnie zinterpretuje nieprawidłowo.

Pobieranie informacji wymaga osobnego testowania. Sposób podziału dokumentów na fragmenty może wpływać na to, co system znajdzie, a nawet dobry wynik wyszukiwania jest bezużyteczny, jeśli pochodzi ze źródła, do którego użytkownik nie powinien mieć dostępu. Uprawnienia dostępu pracownika muszą obowiązywać również w procesie pobierania informacji, a nie być pomijane tylko dlatego, że wyszukiwanie przypadkowo ujawniło materiały o ograniczonym dostępie. To sama aplikacja musi egzekwować autoryzację. Nie należy polegać na modelu w podejmowaniu tej decyzji.

Dostrajanie służy innemu celowi. Może pomóc w dostosowaniu zachowania modelu, formatu odpowiedzi lub obsługi powtarzających się wzorców zadań, gdy dostępne są odpowiednie przykłady szkoleniowe. Nie jest to bezpośredni substytut wyszukiwania, gdy głównym problemem jest dostęp do zmieniających się faktów. Model dostrojony na podstawie zeszłorocznego katalogu produktów nie będzie automatycznie wiedział, co zmieniło się dziś rano.

Prompt i interfejs API modelu mogą być wszystkim, czego potrzebuje aplikacja o wąskim zakresie działania, przynajmniej na początku. Zależy to od tego, na ile przewidywalne są dane wejściowe i czego oczekuje się od systemu w zakresie wyników. Jeśli każda odpowiedź musi zostać zweryfikowana w oparciu o obszerny zbiór dokumentacji wewnętrznej, wyszukiwanie może stać się konieczne; w przypadku prostszego zadania mogłoby to po prostu stanowić dodatkowe obciążenie.

Pierwsza wersja powinna być oszczędna i należy ją przetestować na prawdziwych zapytaniach, a nie tylko na dopracowanych danych demonstracyjnych. Sprawdź, jak radzi sobie z niejasnymi pytaniami lub brakującymi informacjami. Jeśli model udaje, że zna odpowiedź, zamiast przyznać się do luki w wiedzy, należy to naprawić przed dodaniem kolejnych elementów.