Udostępnij za pośrednictwem


Przepływy pracy LLMOps w usłudze Azure Databricks

Ten artykuł uzupełnia przepływy pracy metodyki MLOps w usłudze Databricks przez dodanie informacji specyficznych dla przepływów pracy LLMOps. Aby uzyskać więcej informacji, zobacz The Big Book of MLOps (Książka big book of MLOps).

Jak zmienia się przepływ pracy metodyki MLOps dla llMs?

LLMs to klasa modeli przetwarzania języka naturalnego (NLP), które znacznie przekroczyły ich poprzedniki wielkości i wydajności w różnych zadaniach, takich jak otwarte odpowiedzi na pytania, podsumowanie i wykonywanie instrukcji.

Programowanie i ocena llMs różni się w jakiś ważny sposób od tradycyjnych modeli uczenia maszynowego. W tej sekcji krótko podsumowano niektóre kluczowe właściwości funkcji LLMs i implikacje dotyczące metodyki MLOps.

Kluczowe właściwości llMs Implikacje dotyczące metodyki MLOps
Maszyny LLM są dostępne w wielu formach.

— Ogólne modele własności i systemów operacyjnych, do których uzyskuje się dostęp przy użyciu płatnych interfejsów API.
— Gotowe modele typu open source, które różnią się od ogólnych do konkretnych aplikacji.
— Niestandardowe modele, które zostały dostosowane do określonych aplikacji.
— Niestandardowe wstępnie wytrenowane aplikacje.
Proces programowania: Projekty często rozwijają się przyrostowo, począwszy od istniejących, innych firm lub modeli typu open source, a kończąc na niestandardowych dostosowanych modelach.
Wiele llMs pobiera ogólne zapytania języka naturalnego i instrukcje jako dane wejściowe. Te zapytania mogą zawierać starannie zaprojektowane monity o wywołanie żądanych odpowiedzi. Proces programowania: Projektowanie szablonów tekstowych na potrzeby wykonywania zapytań w usłudze LLMs jest często ważną częścią tworzenia nowych potoków LLM.

Tworzenie pakietów artefaktów uczenia maszynowego: wiele potoków LLM używa istniejących modułów LLM lub llM obsługujących punkty końcowe. Logika uczenia maszynowego opracowana dla tych potoków może skupić się na szablonach monitów, agentach lub łańcuchach zamiast samego modelu. Artefakty uczenia maszynowego spakowane i promowane do środowiska produkcyjnego mogą być tymi potokami, a nie modelami.
Wiele funkcji LLM może otrzymać monity z przykładami, kontekstem lub innymi informacjami, aby pomóc w udzieleniu odpowiedzi na zapytanie. Obsługa infrastruktury: podczas rozszerzania zapytań LLM z kontekstem można użyć dodatkowych narzędzi, takich jak bazy danych wektorów, aby wyszukać odpowiedni kontekst.
Interfejsy API innych firm udostępniają zastrzeżone i open source modele. Ład interfejsu API: korzystanie ze scentralizowanego ładu interfejsu API umożliwia łatwe przełączanie się między dostawcami interfejsu API.
Maszyny LLM są bardzo dużymi modelami uczenia głębokiego, często od gigabajtów do setek gigabajtów. Obsługa infrastruktury: moduły LLM mogą wymagać procesorów GPU do obsługi modeli w czasie rzeczywistym i szybkiego przechowywania modeli, które muszą być ładowane dynamicznie.

Kompromisy związane z kosztami/wydajnością: ponieważ większe modele wymagają większej liczby obliczeń i są droższe do obsługi, mogą być wymagane techniki zmniejszania rozmiaru modelu i obliczeń.
Maszyny LLM są trudne do oceny przy użyciu tradycyjnych metryk uczenia maszynowego, ponieważ często nie ma jednej "właściwej" odpowiedzi. Opinie człowieka: Opinie ludzi są niezbędne do oceny i testowania llMs. Opinie użytkowników należy uwzględnić bezpośrednio w procesie MLOps, w tym na potrzeby testowania, monitorowania i dostrajania w przyszłości.

Commonalities between MLOps and LLMOps

Wiele aspektów procesów MLOps nie zmienia się w przypadku maszyn LLM. Na przykład następujące wytyczne dotyczą również llMs:

  • Używaj oddzielnych środowisk do tworzenia, przemieszczania i produkcji.
  • Użyj narzędzia Git do kontroli wersji.
  • Zarządzanie programowaniem modeli za pomocą platformy MLflow i zarządzanie cyklem życia modelu przy użyciu modeli w katalogu aparatu Unity.
  • Przechowywanie danych w architekturze lakehouse przy użyciu tabel delty.
  • Istniejąca infrastruktura ciągłej integracji/ciągłego wdrażania nie powinna wymagać żadnych zmian.
  • Modułowa struktura metodyki MLOps pozostaje taka sama, a potoki do cechowania, trenowania modelu, wnioskowania modelu itd.

Diagramy architektury referencyjnej

W tej sekcji użyto dwóch aplikacji opartych na usłudze LLM, aby zilustrować niektóre korekty architektury referencyjnej tradycyjnej metodyki MLOps. Diagramy pokazują architekturę produkcyjną dla 1) aplikacji generacji rozszerzonej (RAG) pobierania przy użyciu interfejsu API innej firmy i 2) aplikacji RAG przy użyciu własnego modelu dostosowanego. Oba diagramy pokazują opcjonalną bazę danych wektorów — ten element można zamienić bezpośrednio na zapytanie dotyczące usługi LLM za pośrednictwem punktu końcowego obsługa modelu.

RAG z interfejsem API LLM innej firmy

Na diagramie przedstawiono architekturę produkcyjną aplikacji RAG, która łączy się z interfejsem API LLM innej firmy przy użyciu modeli zewnętrznych usługi Databricks.

Usługa LLM innej firmy korzystająca z modelu zewnętrznego

RAG z dostosowanym modelem open source

Na diagramie przedstawiono architekturę produkcyjną aplikacji RAG, która dostraja model open source.

dostrojenie modelu LLM opartego na modelu open source

Zmiany metodyki LLMOps w architekturze produkcyjnej metodyki MLOps

W tej sekcji przedstawiono główne zmiany architektury referencyjnej metodyki MLOps dla aplikacji LLMOps.

Centrum modelu

Aplikacje LLM często używają istniejących, wstępnie wytrenowanych modeli wybranych z wewnętrznego lub zewnętrznego centrum modelu. Model może być używany w taki sposób, jak jest lub dostrojony.

Usługa Databricks obejmuje wybór wysokiej jakości, wstępnie wytrenowanych modeli podstawowych w wykazie aparatu Unity i w witrynie Databricks Marketplace. Możesz użyć tych wstępnie wytrenowanych modeli, aby uzyskać dostęp do najnowocześniejszych funkcji sztucznej inteligencji, co pozwala zaoszczędzić czas i wydatki na tworzenie własnych modeli niestandardowych. Aby uzyskać szczegółowe informacje, zobacz Wstępnie wytrenowane modele w wykazie aparatu Unity i witrynie Marketplace.

Wektorowa baza danych

Niektóre aplikacje LLM używają baz danych wektorów do szybkiego wyszukiwania podobieństwa, na przykład w celu zapewnienia wiedzy o kontekście lub domenie w zapytaniach LLM. Usługa Databricks udostępnia zintegrowane funkcje wyszukiwania wektorów, które umożliwiają używanie dowolnej tabeli delty w wykazie aparatu Unity jako wektorowej bazy danych. Indeks wyszukiwania wektorowego jest automatycznie synchronizowany z tabelą delty. Aby uzyskać szczegółowe informacje, zobacz Wyszukiwanie wektorowe.

Możesz utworzyć artefakt modelu, który hermetyzuje logikę w celu pobrania informacji z bazy danych wektorów i dostarcza zwracane dane jako kontekst do usługi LLM. Następnie możesz zarejestrować model przy użyciu odmiany modelu MLflow LangChain lub PyFunc.

Dostrajanie llm

Ponieważ modele LLM są kosztowne i czasochłonne do utworzenia od podstaw, aplikacje LLM często dostrajają istniejący model w celu zwiększenia wydajności w konkretnym scenariuszu. W architekturze referencyjnej dostrajanie i wdrażanie modelu są reprezentowane jako odrębne zadania usługi Databricks. Walidacja dostosowanego modelu przed wdrożeniem jest często procesem ręcznym.

Usługa Databricks zapewnia dostrajanie modelu podstawowego, co umożliwia dostosowanie istniejącego modułu LLM w celu zoptymalizowania wydajności dla określonej aplikacji. Aby uzyskać szczegółowe informacje, zobacz Dostosowywanie modelu podstawowego.

Obsługa modelu

W scenariuszu RAG przy użyciu interfejsu API innej firmy ważna zmiana architektury polega na tym, że potok LLM wykonuje zewnętrzne wywołania interfejsu API z punktu końcowego obsługa modelu do wewnętrznych lub innych firm interfejsów API LLM. Zwiększa to złożoność, potencjalne opóźnienia i dodatkowe zarządzanie poświadczeniami.

Usługa Databricks udostępnia usługę Mosaic AI Model Serving, która udostępnia ujednolicony interfejs do wdrażania modeli sztucznej inteligencji, zarządzania nimi i wykonywania zapytań. Aby uzyskać szczegółowe informacje, zobacz Mozaika AI Model Serving( Obsługa modelu mozaiki sztucznej inteligencji).

Opinie ludzi na temat monitorowania i oceny

Pętle opinii człowieka są niezbędne w większości aplikacji LLM. Opinie ludzi powinny być zarządzane jak inne dane, najlepiej włączone do monitorowania w oparciu o przesyłanie strumieniowe niemal w czasie rzeczywistym.

Aplikacja Do przeglądu struktury agenta sztucznej inteligencji mozaiki ułatwia zbieranie opinii od recenzentów. Aby uzyskać szczegółowe informacje, zobacz Uzyskiwanie opinii na temat jakości aplikacji agenta.