Nuta
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować się zalogować lub zmienić katalog.
Dostęp do tej strony wymaga autoryzacji. Możesz spróbować zmienić katalogi.
Ten artykuł uzupełnia przepływy pracy metodyki MLOps w usłudze Databricks poprzez dodanie informacji specyficznych dla przepływów pracy LLMOps. Aby uzyskać więcej informacji, zobacz The Big Book of MLOps.
Jak zmienia się przepływ pracy MLOps dla LLMs?
LLMs to klasa modeli przetwarzania języka naturalnego (NLP), które znacznie przewyższyły swoich poprzedników pod względem wielkości i wydajności w zakresie różnych zadań, takich jak udzielanie otwartych odpowiedzi na pytania, podsumowywanie oraz wykonywanie instrukcji.
Programowanie i ocena LLM-ów różni się na kilka ważnych sposobów od tradycyjnych modeli uczenia maszynowego. W tej sekcji krótko podsumowano niektóre kluczowe właściwości LLMs oraz ich implikacje dla MLOps.
| Kluczowe właściwości LLMs | Implikacje dotyczące metodyki MLOps |
|---|---|
Modele LLM są dostępne w wielu formach.
|
Proces rozwoju: Projekty często rozwijają się przyrostowo, począwszy od istniejących, zewnętrznych lub modeli typu open source, a kończąc na niestandardowo dostosowanych modelach. |
| Wiele LLM-ów przyjmuje ogólne zapytania języka naturalnego i instrukcje jako dane wejściowe. Te zapytania mogą zawierać starannie opracowane wskazówki, aby wywołać żądane odpowiedzi. |
Proces rozwoju: Projektowanie szablonów tekstowych do zapytań przy użyciu LLM jest często ważną częścią tworzenia nowych potoków LLM. Pakietowanie 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ą okazać się pipeline'ami, zamiast modeli. |
| Wiele modeli LLM może otrzymywać 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 indeksy wektorowe, aby wyszukać odpowiedni kontekst. |
| Zewnętrzne interfejsy API udostępniają zastrzeżone i otwartoźródłowe modele. | Zarządzanie API: Korzystanie ze scentralizowanego zarządzania API umożliwia łatwe przełączanie się między dostawcami API. |
| Modele LLM to bardzo duże modele uczenia głębokiego, często zajmujące od kilku 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ń. |
| Modele językowe LLM są trudne do oceny za pomocą tradycyjnych metryk uczenia maszynowego, ponieważ często nie ma jednej „właściwej” odpowiedzi. | Informacja zwrotna od ludzi: Informacja zwrotna od ludzi jest niezbędna do oceny i testowania LLM-ów. 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. |
Podobieństwa między MLOps a LLMOps
Wiele aspektów procesów MLOps nie zmienia się w przypadku maszyn LLM. Na przykład: następujące wytyczne dotyczą również LLMów:
- Używaj oddzielnych środowisk do rozwoju, testowania i produkcji.
- Użyj narzędzia Git do kontroli wersji.
- Zarządzaj rozwojem modeli za pomocą platformy MLflow i zarządzaj cyklem życia modelu przy użyciu Modeli w katalogu Unity.
- Przechowuj dane w architekturze lakehouse przy użyciu tabel Delta.
- Istniejąca infrastruktura CI/CD nie powinna wymagać żadnych zmian.
- Modułowa struktura MLOps pozostaje taka sama, z potokami do cechowania, trenowania modelu, wnioskowanie modelu itd.
Diagramy architektury referencyjnej
W tej sekcji użyto dwóch aplikacji opartych na LLM, aby zilustrować pewne dostosowania architektury referencyjnej tradycyjnej metodyki MLOps. Diagramy przedstawiają architekturę produkcyjną dla 1) aplikacji generacji wspomaganej wyszukiwaniem (RAG) za pomocą API zewnętrznego dostawcy oraz 2) aplikacji RAG z wykorzystaniem własnego, dostrojonego modelu hostowanego lokalnie. Oba diagramy pokazują opcjonalną bazę danych wektorów — ten element można zastąpić bezpośrednim zapytaniem do LLM za pośrednictwem punktu końcowego obsługi modelu.
RAG z zewnętrznym 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.
RAG z dostosowanym modelem open source
Na diagramie przedstawiono architekturę produkcyjną aplikacji RAG, która dostraja model open source.
Zmiany architektury produkcyjnej z LLMOps na 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 Unity Catalog i na markecie Databricks. 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 Uzyskiwanie dostępu do modeli generatywnej AI i LLM z wykazu Unity.
Indeks wektorowy
Niektóre aplikacje LLM używają indeksów wektorów do szybkiego wyszukiwania podobieństwa, na przykład w celu zapewnienia wiedzy kontekstowej lub domeny w zapytaniach LLM. Usługa Databricks udostępnia zintegrowaną funkcjonalność wyszukiwania wektorów, która umożliwia używanie dowolnej tabeli Delta w katalogu Unity jako indeksu wektorowego. 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 indeksu wektorowego 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 lakeflow. Walidacja dostosowanego modelu przed wdrożeniem jest często procesem ręcznym.
Databricks oferuje dostrajanie Modelu Fundamentowego, co umożliwia wykorzystanie własnych danych do dostosowania istniejącego modelu LLM w celu zoptymalizowania jego wydajności dla Twojej specyficznej 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ługi modelu do wewnętrznych bądź zewnętrznych 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 Obsługa modelu AI Mosaic.
Opinie ludzi na temat monitorowania i oceny
Pętle sprzężenia zwrotnego ludzkiego są niezbędne w większości aplikacji opartych na LLM. Opinia zwrotna od ludzi powinna być zarządzana jak inne dane, najlepiej włączona do monitorowania w oparciu o strumieniowanie danych niemal w czasie rzeczywistym.
Aplikacja recenzująca platformę agenta AI Mosaic pomaga w zbieraniu opinii od recenzentów. Aby uzyskać szczegółowe informacje, zobacz Użyj aplikacji przeglądającej do przeglądów ludzkich aplikacji gen AI (MLflow 2).