Przenoszenie dużych modeli językowych (LLM) do rzeczywistych aplikacji biznesowych

Duże modele językowe są wszędzie. Każda rozmowa z klientem lub prezentacja VC wiąże się z pytaniami o to, jak gotowa jest technologia LLM i jak będzie ona napędzać przyszłe zastosowania. Omówiłem kilka wzorców na ten temat mój poprzedni post. Tutaj omówię kilka rzeczywistych wzorców zastosowań w przemyśle farmaceutycznym, nad którymi pracowało Persistent Systems.

Modele dużego języka i podstawowe mocne strony

LLM są dobrzy w rozumieniu języka i to jest ich mocna strona. Najczęstszym wzorcem, jaki obserwujemy w przypadku aplikacji, jest generowanie rozszerzone wyszukiwania (RAG), w którym wiedza jest kompilowana zewnętrznie ze źródeł danych i dostarczana w kontekście jako zachęta dla LLM do sparafrazowania odpowiedzi. W tym przypadku superszybkie mechanizmy wyszukiwania, takie jak wektorowe bazy danych i silniki oparte na Elasticsearch, służą jako pierwsza linia wyszukiwania. Następnie wyniki wyszukiwania są kompilowane w monit i wysyłane do LLM głównie jako wywołanie API.

Innym wzorcem jest generowanie zapytania dotyczącego ustrukturyzowanych danych poprzez podanie LLM modelu danych jako zachęty i konkretnego zapytania użytkownika. Wzorzec ten można wykorzystać do opracowania zaawansowanego interfejsu „rozmawiaj ze swoimi danymi” dla baz danych SQL, takich jak Snowflake, a także grafowych baz danych, takich jak Neo4j.

Wykorzystanie wzorców LLM do wglądu w świat rzeczywisty

Firma Persistent Systems przyjrzała się ostatnio wzorowi Ruch Wybuchowy, firma zajmująca się telemetrią sportową (analiza wahań baseballu, golfa itp.), w której przeanalizowaliśmy dane szeregów czasowych podsumowań zawodników, aby uzyskać rekomendacje.

W przypadku bardziej złożonych aplikacji często musimy łączyć żądania LLM z przetwarzaniem pomiędzy wywołaniami. Dla firmy farmaceutycznej opracowaliśmy aplikację Smart Trails, która filtruje pacjentów do badań klinicznych na podstawie kryteriów pochodzących z dokumentu badania klinicznego. Tutaj zastosowaliśmy podejście oparte na łańcuchu LLM. Najpierw opracowaliśmy LLM do odczytania próbnego dokumentu PDF i wykorzystania wzorca RAG do wyodrębnienia kryteriów włączenia i wykluczenia.

W tym celu zastosowano stosunkowo prostszy LLM, taki jak GPT-3.5-Turbo (ChatGPT). Następnie połączyliśmy te wyodrębnione jednostki z modelem danych bazy danych SQL pacjentów w Snowflake, aby utworzyć podpowiedzi. Ten monit podawany do wydajniejszego LLM, takiego jak GPT4, daje nam zapytanie SQL do filtrowania pacjentów, które jest gotowe do uruchomienia w Snowflake. Ponieważ korzystamy z łączenia LLM, możemy zastosować wiele LLM na każdym etapie łańcucha, umożliwiając nam w ten sposób zarządzanie kosztami.

Obecnie zdecydowaliśmy się zachować determinizm tego łańcucha w celu zapewnienia lepszej kontroli. Oznacza to, że zdecydowaliśmy się na większą inteligencję w łańcuchach i utrzymanie orkiestracji bardzo prostej i przewidywalnej. Każdy element łańcucha jest sam w sobie złożoną aplikacją, której opracowanie zajęłoby kilka miesięcy w czasach poprzedzających LLM.

Zasilanie bardziej zaawansowanych przypadków użycia

W bardziej zaawansowanym przypadku moglibyśmy użyć agentów takich jak Reagować aby poprosić LLM o utworzenie instrukcji krok po kroku, które należy wykonać w przypadku konkretnego zapytania użytkownika. Wymagałoby to oczywiście wysokiej klasy LLM, takiego jak GPT4, Cohere lub Claude 2. Istnieje jednak ryzyko, że model wykona nieprawidłowy krok, który będzie musiał zostać zweryfikowany za pomocą poręczy. Jest to kompromis pomiędzy przeniesieniem inteligencji w kontrolowane ogniwa łańcucha lub uczynieniem całego łańcucha autonomicznym.

Dzisiaj, gdy przyzwyczailiśmy się do epoki generatywnej sztucznej inteligencji dla języka, branża zaczyna przyjmować aplikacje LLM z przewidywalnymi łańcuchami. W miarę wzrostu popularności wkrótce zaczniemy eksperymentować z większą autonomią tych sieci za pośrednictwem agentów. O to właśnie chodzi w debacie na temat AGI i jesteśmy ciekawi, jak to wszystko będzie ewoluować w czasie.