Projektowanie wspierające cykl życia modelu podstawowego

Modele podstawowe to wersjonowane zależności, które wykorzystujesz w ramach obciążeń związanych ze sztuczną inteligencją. Każdy model podstawowy ma cykl życia, który należy rozważyć. Podobnie jak biblioteki kodu i inne zależności w Twoim środowisku pracy, modele bazowe otrzymują aktualizacje pomniejszych wersji, które zapewniają ulepszenia wydajności i optymalizacje. Aktualizacje wersji głównej wprowadzają istotne zmiany dotyczące możliwości, wydajności lub aktualności danych treningowych. Z czasem modele podstaw mogą zostać wycofane z użycia z powodu przestarzałości lub preferencji hosta modelu, które są niezależne od ciebie.

Musisz zaprojektować obciążenie, aby obsługiwać udokumentowane cykle życia modeli wybieranych jako zależności. Jeśli nie rozważasz cykli życia modeli, możesz niepotrzebnie wykonywać ryzykowne uaktualnienia, wprowadzać nietestowane zmiany zachowania, podejmować niepotrzebne przestoje obciążeń lub doświadczać awarii ze względu na sposób, w jaki platforma hostingowa obsługuje modele końca życia.

Obciążenie zaprojektowane do wspierania cykli życia modeli ułatwia eksperymentowanie i bezpieczną migrację do nowych modeli podstawowych w miarę ich wprowadzania na rynek.

Typy aktualizacji modelu

Zakres aktualizacji modelu w Twoim rozwiązaniu z generatywną sztuczną inteligencją może się znacząco różnić, od drobnej zmiany wersji do wyboru nowej rodziny modeli. Istnieje wiele powodów, dla których możesz zdecydować się na uaktualnienie modelu w rozwiązaniu. W poniższej tabeli wymieniono różne zakresy aktualizacji wraz z przykładem i korzyściami wprowadzania tego uaktualnienia.

Zakres zmian	Zalety aktualizowania modelu	Przykład
Aktualizacja drobnej wersji	Zapewnia lepszą wydajność i ulepszone możliwości, zwykle bez konieczności wprowadzania istotnych zmian w istniejącej implementacji	Przejście z GPT-4o v2024-08-06 do GPT-4o v2024-11-20
Aktualizacja wersji pośredniej	Zapewnia znaczne ulepszenia wydajności, nowe możliwości i zwiększoną niezawodność przy zachowaniu większości zgodności z poprzednimi wersjami i wymaga tylko umiarkowanych korekt implementacji	Przejście z GPT-3 do GPT-3.5
Aktualizacja wersji głównej	Zapewnia przełomowe ulepszenia w zakresie rozumowania, możliwości, zakresu kontekstu i wydajności, które uzasadniają istotne zmiany w implementacji i dostosowanie komunikatów	Przechodzenie z GPT-3 do GPT-4
Aktualizacja wariantu	Zapewnia wyspecjalizowane optymalizacje, takie jak zwiększona szybkość przetwarzania i mniejsze opóźnienie, zachowując podstawową architekturę i zwykle zapewniając zgodność z poprzednimi wersjami modelu podstawowego	Przejście z GPT-4 do GPT-4-Turbo
Aktualizacja wersji generacyjnej	Zapewnia znaczące ulepszenia w zakresie rozumowania, możliwości wielomodalnych i wydajności, które zasadniczo rozszerzają narzędzie modelu, a jednocześnie potencjalnie wymagają całkowitego ponownego opracowywania strategii implementacji	Przechodzenie z GPT-4 do GPT-4o
Ogólna zmiana modelu	Zapewnia dostęp do wyspecjalizowanych możliwości, różnych współczynników wydajności cen i potencjalnie lepszego dopasowania do określonych przypadków użycia	Przechodzenie z GPT-4 do deepSeek
Zmiana wyspecjalizowanego modelu	Zapewnia optymalizację specyficzną dla domeny, zwiększoną wydajność określonych zadań i potencjalnie niższe koszty w porównaniu z użyciem modeli ogólnego przeznaczenia dla wyspecjalizowanych aplikacji	Przechodzenie z GPT-4 do prizedata
Zmiana opcji wdrożenia	Zapewnia większą kontrolę nad infrastrukturą, opcjami dostosowywania i potencjalnymi oszczędnościami kosztów przy jednoczesnym zwiększeniu optymalizacji i zwiększonej prywatności danych kosztem zwiększonej odpowiedzialności za zarządzanie	Przejście z LLaMa-1 hostowanego jako zarządzanego punktu końcowego online w usłudze Azure AI Foundry do samodzielnego hostowania LLaMa-1 na maszynie wirtualnej

Jak pokazano w tabeli, korzyści wynikające z przejścia do nowego modelu są zwykle kombinacją następujących czynników:

• Wydajność, taka jak szybkość i opóźnienie

• Pojemność, np. przepustowość mierzona w liczbie transakcji na minutę

• Dostępność limitu przydziału

• Efektywność kosztowa

• Dostępność regionalna

• Funkcje wielomodalne

• Zaktualizowana wiedza szkoleniowa

• Poprawki błędów

• Specjalizacja lub despecializacja, aby lepiej dopasować się do przypadku użycia

• Unikanie przestojów obciążeń z powodu zasad cyklu życia hosta modelu

Zachowanie związane z przechodzeniem na emeryturę

Zachowanie wycofywania modelu zależy od strategii wdrażania modelu. Istnieją trzy kluczowe strategie wdrażania modeli. Ważne jest, aby zrozumieć, jak każda strategia obsługuje wycofywanie wersji:

• Rozwiązania MaaS (model jako usługa) to wstępnie wytrenowane modele udostępniane jako interfejsy API, które zapewniają skalowalność i łatwość integracji. Mają oni kompromis w postaci potencjalnie wyższych kosztów i mniejszej kontroli nad modelami. Przykłady rozwiązań MaaS obejmują modele wdrożone w Azure OpenAI w modelach Foundry oraz modele z katalogu modeli wdrożone jako bezserwerowe interfejsy API.

• Rozwiązania MaaP (model jako platforma) to modele wdrażane i zarządzane na większej platformie, takie jak modele z katalogu modeli platformy Azure wdrożone w zarządzanych obliczeniach. To rozwiązanie zwykle zapewnia większą kontrolę nad modelami, ale wymaga więcej zarządzania niż rozwiązania MaaS.

• Modele samoobsługowego hostingu to modele wdrażane we własnej infrastrukturze. To wdrożenie zapewnia maksymalną kontrolę nad modelami, ale wymaga znacznej odpowiedzialności za infrastrukturę, zarządzanie i konserwację.

Strategie maaS i MaaP w modelach źródłowych platformy Azure z katalogu modeli usługi Azure AI. Modele w katalogu modeli przechodzą cykl życia, w którym stają się oznaczone jako przestarzałe, a następnie są wycofywane. Należy zaplanować te ewentualności w swoim obciążeniu pracą.

Ostrzeżenie

W przypadku usług MaaS, w tym modeli wdrożonych w usłudze Azure OpenAI i modeli wdrożonych przy użyciu modelu bezserwerowego interfejsu API, ważne jest, aby zrozumieć, że istniejące wdrożenia dla wycofanych modeli zwracają błędy HTTP. Jeśli nie uaktualnisz do obsługiwanego modelu, aplikacja nie działa już zgodnie z oczekiwaniami. W przypadku przestarzałych modeli nie można tworzyć nowych wdrożeń dla tych modeli, ale istniejące wdrożenia będą nadal działać, dopóki nie zostaną wycofane. Aby uzyskać więcej informacji, zobacz Przestarzałość i wycofanie modeli bezserwerowych interfejsów API oraz przestarzałość i wycofanie modeli usługi Azure OpenAI.

Jeśli samodzielnie hostujesz modele lub używasz zarządzanych obliczeń, zachowasz pełną kontrolę i nie musisz aktualizować modeli. Możesz jednak zreplikować cykl życia modelu, aby uzyskać dodatkowe korzyści, które nowszy model może przynieść twojemu obciążeniu pracą.

Zakres zmian aktualizacji modelu

Diagram przedstawia połączenie, które przechodzi od użytkownika, do inteligentnej aplikacji, a następnie do orkiestratora. Trzy pola wskazują koordynatora z liniami przerywanymi: konfiguracja, monit i logika aranżacji. Orkiestrator ma solidne linie wskazujące trzy różne modele sztucznej inteligencji: model-x-v1, model-x-v1.1 i model-y-v1. Orkiestrator ma również strzałkę, która wskazuje na pole z etykietą API lub agent. Pole interfejsu API lub agenta zawiera linię ciągłą wskazującą pole z etykietą bazy danych wiedzy. Pipeline z czterema etapami wskazuje bazę wiedzy linią przerywaną. Cztery kroki to: fragmentowanie dokumentów, wzbogacanie fragmentów, osadzanie fragmentów i utrwalanie fragmentów. Ponumerowane okręgi dodają adnotacje do kilku części diagramu. Pierwszy okrąg znajduje się obok modeli. Drugi okrąg znajduje się obok konfiguracji. Trzeci okrąg znajduje się obok monitu. Czwarty okrąg znajduje się obok logiki aranżacji. Piąty okrąg znajduje się obok linii przerywanej z potoku do bazy danych wiedzy. Szósty okrąg znajduje się poniżej modeli.

Musisz ocenić, jak aktualizacja modelu wpływa na obciążenie, aby można było zaplanować przejście ze starego modelu do nowego modelu. Zakres zmian obciążenia zależy od funkcjonalnych i niefunkcjonalnych różnic między starymi i nowymi modelami. Diagram przedstawia uproszczoną architekturę czatu zawierającą ponumerowane sekcje, które podkreślają obszary, w których aktualizacja modelu może mieć wpływ.

W przypadku każdego z tych obszarów rozważ przestój spowodowany aktualizacjami oraz sposób, w jaki zarządzasz żądaniami, które system aktualnie przetwarza. Jeśli okna konserwacyjne są dostępne dla twojego obciążenia, użyj tych okien, gdy zakres modyfikacji jest duży. Jeśli okna obsługi nie są dostępne, należy uwzględnić zmiany w tych obszarach, aby zachować funkcjonalność obciążenia i cele poziomu usług podczas aktualizacji modelu.

1. Model: Oczywista zmiana dotyczy samego modelu. Nowy model można wdrożyć przy użyciu wybranej strategii wdrażania modelu. Należy ocenić kompromisy między uaktualnieniami w miejscu a wdrożeniem równoległym.

   Po przejściu do nowej wersji modelu z dostosowanego modelu należy ponownie wykonać dostrajanie nowej wersji modelu przed jego użyciem. Podczas aktualizacji w celu użycia innego modelu należy określić, czy wymagane jest dostrajanie.

2. Konfiguracja modelu: Podczas aktualizowania modelu podstawowego w rozwiązaniu sztucznej inteligencji może być konieczne dostosowanie hiperparametrów lub konfiguracji w celu zoptymalizowania wydajności pod kątem architektury i możliwości nowego modelu. Na przykład przełączenie z modelu opartego na transformatorze do rekursowej sieci neuronowej może wymagać różnych wskaźników uczenia i rozmiarów partii w celu uzyskania optymalnych wyników.

3. Monit: Przy zmianie modeli podstawowych w obciążeniu może być konieczne dostosowanie monitów systemowych w orkiestratorach lub agentach tak, aby odpowiadały one zaletom i możliwościom nowego modelu.

   Wraz z aktualizowaniem konfiguracji modelu aktualizowanie monitu jest jedną z najbardziej typowych zmian podczas aktualizowania modeli. Podczas oceniania nowego modelu, nawet w przypadku aktualizacji wersji pomocniczej, przetestuj zmiany w wierszu polecenia, jeśli nie spełniają wymagań. Takie podejście zapewnia rozwiązanie problemów z wydajnością przed rozpoczęciem eksplorowania innych modyfikacji. Po zmianie na nowe modele trzeba odpowiedzieć na prośbę. Istnieje również prawdopodobieństwo, że podczas wprowadzania dużych zmian poprawek należy rozwiązać problem z monitem.

4. Logika aranżacji: Niektóre aktualizacje modelu, szczególnie w przypadku korzystania z nowych funkcji, wymagają wprowadzenia zmian w logice aranżacji lub agenta.

   Jeśli na przykład zaktualizujesz model do GPT-4 w celu skorzystania z wywoływania funkcji, musisz zmienić logikę aranżacji. Stary model zwrócił wynik, który można przekazać do wywołującego. W przypadku wywoływania funkcji wywołanie modelu zwraca funkcję, którą musi wywołać logika aranżacji. Na platformie Azure typowe jest zaimplementowanie logiki aranżacji w usłudze agenta usługi Azure AI Foundry lub przy użyciu rozwiązań opartych na kodzie, takich jak Semantic Kernel lub LangChain hostowane na platformie Azure.

5. Dane bazowe: Niektóre aktualizacje modelu i szeroko zakrojone zmiany mogą wymagać wprowadzenia zmian w danych bazowych lub dostrajania, bądź też w sposobie pobierania tych danych.

   Na przykład w przypadku przejścia z uogólnionego modelu do modelu specyficznego dla domeny, takiego jak model skoncentrowany na finansach lub medycynie, może już nie być konieczne przekazanie danych uziemienia specyficznych dla domeny do modelu. Innym przykładem jest to, że nowy model może obsłużyć większe okno kontekstowe. W tym scenariuszu możesz pobrać inne istotne fragmenty lub dostosować rozmiar fragmentów. Aby uzyskać więcej informacji, zobacz Projektowanie i opracowywanie rozwiązania do generowania rozszerzonego pobierania (RAG).

6. Sprzęt: W przypadku modeli uruchamianych w programie MaaP zmiana modelu może wymagać nowego sprzętu. Tylko określone jednostki SKU obliczeniowe są włączone dla modeli z wykazu. Ponadto sprzęt może być przestarzały, co wymaga uruchomienia modelu na nowym sprzęcie.

Projektowanie pod kątem zmian

Najprawdopodobniej zaktualizujesz modele w ramach swojego obciążenia. Jeśli używasz strategii wdrażania usługi MaaS na platformie Azure, modele zostaną wycofane i musisz przeprowadzić uaktualnienie do nowszej wersji. Możesz również przejść do różnych modeli lub wersji modelu, aby skorzystać z nowych funkcji, niższych cen lub lepszej wydajności. W każdym razie, architektura musi obsługiwać aktualizowanie modelu używanego przez obciążenie robocze generatywnej sztucznej inteligencji.

W poprzedniej sekcji omówiono różne zakresy zmian. Należy postępować zgodnie z odpowiednimi praktykami operacyjnymi uczenia maszynowego (MLOps), praktykami operacyjnymi danych (DataOps) i praktykami operacyjnymi generatywnej sztucznej inteligencji (GenAIOps), aby tworzyć i utrzymywać zautomatyzowane potoki na potrzeby dostrajania modelu, tworzenia promptów, zmiany hiperparametrów i zarządzania logiką orkiestracji.

Aktualizacje hiperparametrów i monitów są typowe w większości aktualizacji modelu. Ponieważ te zmiany są tak powszechne, architektura powinna obsługiwać kontrolowany mechanizm zmian dla tych obszarów. Ważną kwestią jest to, że monity i hiperparametry są dostosowane do określonych wersji modelu. Upewnij się, że monity i hiperparametry są zawsze używane z prawidłowym modelem i wersją.

Zautomatyzowane rurociągi

Zaimplementuj zautomatyzowane potoki, aby przetestować i ocenić różne aspekty generatywnej aplikacji AI.

• Metodyka MLOps: Postępuj zgodnie ze wskazówkami dotyczącymi usługi Azure MLOps , aby tworzyć potoki na potrzeby dostrajania modelu, jeśli ma to zastosowanie.

• GenAIOps: Zaimplementuj kolejne etapy GenAIOps, aby przetestować i ocenić zmiany modelu, hiperparametrów modelu, podpowiedzi i logiki orkiestracji.

• Metodyka DataOps: Wdrożyć potoki DataOps, aby przetestować i ocenić zmiany w danych bazowych RAG.

Powinieneś zaimplementować pipeline'y z następujących powodów:

• Aby ułatwić ci programowanie iteracyjne i eksperymentowanie (pętla wewnętrzna)
• Aby przeprowadzić bezpieczne wdrażanie i operacjonalizowanie rozwiązania generatywnej sztucznej inteligencji (pętla zewnętrzna)

Jeśli to możliwe, użyj tych samych danych bazowych, których używasz z aplikacją produkcyjną, aby przetestować zmiany w generowanej aplikacji sztucznej inteligencji. Takie podejście może nie być możliwe, jeśli zaktualizowana aplikacja używa nowych funkcji modelu, które wymagają zmiany danych.

Zagadnienia dotyczące architektury

W prostych architekturach, takich jak poniższa architektura, klient bezpośrednio wywołuje model z poprawną wersją monitu i konfiguracją. W przypadku wprowadzenia zmian w wierszu polecenia zostanie wdrożony nowy klient z nowym monitem i wywoła nowy model. Łączenie monitu, konfiguracji i wersji modelu nie jest wyzwaniem.

Diagram przedstawia użytkownika łączącego się z inteligentną aplikacją, która łączy się bezpośrednio z modelem-x-v1. Trzy elementy za pomocą przerywanych linii wskazują inteligentną aplikację, co oznacza, że aplikacja zawiera te elementy. Elementy są konfiguracją, monitem i logiką aranżacji.

Architektury produkcyjne nie są proste. Zazwyczaj implementujesz koordynatora lub agenta, którego obowiązkiem jest zarządzanie przepływem interakcji między dowolną bazą danych wiedzy a modelami. Architektura może również implementować co najmniej jedną warstwę abstrakcji, taką jak router lub brama:

• Router: Router kieruje ruch do różnych wdrożeń orkiestratora. Router jest przydatny w strategiach wdrażania, takich jak wdrożenia niebiesko-zielone, w których można wybrać kierowanie określonego procentu ruchu do nowej wersji orkiestratora w ramach bezpiecznych praktyk wdrażania. Ten składnik może być również używany do testowania A/B lub dublowania ruchu w celu oceny przetestowanych, ale niewaleowanych zmian w ruchu produkcyjnym.

• Brama: Stosowanie serwerów proxy do uzyskiwania dostępu do modeli sztucznej inteligencji jest często spotykane z różnych powodów. Możesz na przykład równoważyć obciążenie lub włączyć przełączenie awaryjne między wieloma wystąpieniami zaplecza, zaimplementować niestandardowe uwierzytelnianie i autoryzację, albo wdrożyć logowanie i monitorowanie dla swoich modeli.

Diagram przedstawia użytkownika łączącego się z inteligentną aplikacją, która łączy się z routerem. Router łączy się z dwoma implementacjami w orchestracji. Każde wdrożenie łączy się z bramą. Brama łączy się z trzema różnymi modelami: model-x-v1, model-x-v1.1 i model-y-v1. Orkiestrator łączy się również z interfejsem API lub agentem, który łączy się z bazą danych wiedzy. Strzałki wskazują router i bramę z etykietą, która wskazuje typowe poziomy abstrakcji w obciążeniu roboczym generatywnej sztucznej inteligencji.

Ze względu na warstwy pośrednie należy zaprojektować architekturę w celu obsługi wysyłania określonych wersji monitów do określonych modeli lub wersji modelu. Na przykład w środowisku produkcyjnym może pojawić się monit, taki jak prompt1, zaprojektowany dla modelu, taki jak model1. Przy uaktualnieniu do modelu1.1 może być konieczne zastąpienie monitu1 monit2. W tym przykładzie twoja architektura zawsze musi używać „prompt1” z „model1” oraz „prompt2” z „model1.1”.

Router

Na poniższym diagramie przedstawiono architekturę, która używa routera do kierowania żądań do wielu wdrożeń. Innym przykładem tej architektury jest usługa Azure AI Foundry i używa zarządzanego punktu końcowego online jako routera. Różne wersje orkiestratora są wdrażane w zarządzane zasoby obliczeniowe.

Diagram przedstawia użytkownika łączącego się z inteligentną aplikacją, która łączy się z routerem (oznaczonym etykietą 1). Router łączy się z dwoma wdrożeniami w programie Orchestrator (oznaczonym jako 2). Każde wdrożenie zawiera konfigurację, monit (oznaczony etykietą 3) i logikę aranżacji (oznaczoną etykietą 4). Każde wdrożenie łączy się z określonym modelem (oznaczonym etykietą 5). Wdrożenie 1 łączy się z modelem-x-v1, a wdrożenie 2 łączy się z modelem-x-v1.1. Orkiestrator łączy się również z interfejsem API lub agentem, który łączy się z bazą danych wiedzy.

W poniższym przebiegu opisano, jak różne wdrożenia orkiestratora wywołują właściwy model. Każde wdrożenie ma własną wersję konfiguracji modelu i monit:

1. Użytkownik wysyła żądanie z aplikacji inteligentnej i wysyła je do routera.

2. Router kieruje do wdrożenia 1 lub wdrożenia 2 orkiestratora w zależności od jego logiki.

3. Każde wdrożenie ma własną wersję monitu i konfiguracji.

4. Orkiestrator jest skonfigurowany przy użyciu określonego modelu i wersji. Te informacje są używane do bezpośredniego wywoływania odpowiedniego modelu i wersji.

5. Ponieważ określona wersja monitu jest wdrażana wraz z koordynatorem skonfigurowanym z określonym modelem i wersją, prawidłowy monit jest wysyłany do prawidłowej wersji modelu.

Brama sieciowa

Na poniższym diagramie przedstawiono architekturę, która używa routera do kierowania żądań do wielu wdrożeń. Jednak w tej architekturze wszystkie żądania modelu są kierowane przez bramę. Dostęp serwera proxy do modeli sztucznej inteligencji jest powszechny z różnych powodów, w tym równoważenie obciążenia, włączanie trybu failover między wieloma wystąpieniami zaplecza w jednym regionie lub wielu regionach oraz implementowanie aprowizowanej jednostki przepływności ze strategią rozlania płatności zgodnie z rzeczywistym użyciem.

Diagram przedstawia użytkownika łączącego się z inteligentną aplikacją, która łączy się z routerem (oznaczonym etykietą 1). Router łączy się z dwoma wdrożeniami w programie Orchestrator (oznaczonym jako 2). Każde wdrożenie zawiera konfigurację, monit (oznaczony etykietą 3) i logikę aranżacji (oznaczoną etykietą 4). Każde wdrożenie łączy się z bramą (oznaczoną etykietą 5). Każdy wiersz łącznika ma etykietę zawierającą nagłówek HTTP, który wskazuje model i wersję. Wdrożenie 1 wskazuje model-x-v1, a wdrożenie 2 wskazuje model-x-v1.1. Brama łączy się z model-x-v1 i model-x-v1.1 (oznaczone etykietą 6). Orkiestrator łączy się z interfejsem API lub agentem, który łączy się z bazą danych wiedzy.

Następujący przepływ opisuje, jak różne wdrożenia orkiestratora wywołują prawidłowy model przez bramę. Każde wdrożenie ma własną wersję konfiguracji modelu i monit:

1. Użytkownik wysyła żądanie z aplikacji inteligentnej i wysyła je do routera.

2. Router kieruje do Wdrożenia 1 lub Wdrożenia 2 w zależności od logiki routera.

3. Każde wdrożenie ma własną wersję monitu.

4. Orkiestrator jest skonfigurowany przy użyciu określonego modelu i wersji. Te informacje są używane do ustawiania nagłówka HTTP wskazującego prawidłowy model i wersję do wywołania.

5. Orkiestrator wzywa bramę. Żądanie zawiera nagłówek HTTP, który wskazuje nazwę i wersję modelu do użycia.

6. Brama używa nagłówka HTTP do kierowania żądania do odpowiedniego modelu i wersji. Może również stosować konfigurację zdefiniowaną w bramie.

Wyniesienie konfiguracji na zewnątrz

Wzorzec projektowania chmury Zewnętrzny Sklep Konfiguracji jest dobrym sposobem na zarządzanie przechowywaniem żądań i konfiguracji. W przypadku niektórych zakresów zmian modelu może być możliwe koordynowanie wdrażania modelu za pomocą monitu systemowego i zmian konfiguracji, jeśli są one przechowywane w możliwej do aktualizacji lokalizacji poza kodem koordynatora lub agenta. Takie podejście nie działa, jeśli masz logikę orkiestracji do dostosowania, ale jest przydatne w wielu aktualizacjach modelu o mniejszym zakresie.

Wybór mocy obliczeniowej

W przypadku hostowania usługi MaaP modele są często ograniczone do podzestawu zasobów obliczeniowych udostępnianych przez hosta. Wszystkie obliczenia podlegają limitom przydziału, ograniczeniom dostępności i ogłoszeniami zakończenia wsparcia. Użyj wzorców routingu, aby obsługiwać przejście na nowy sprzęt, gdy bieżący sprzęt nie jest już obsługiwany lub istnieją ograniczenia, które uniemożliwiają dodatkowe skalowanie w poziomie.

Przykładem ogłoszenia dotyczącego zakończenia wsparcia produktu jest ogłoszenie serii NC A100 v4 dotyczące usług obliczeniowych. Jeśli hostujesz modele na tym sprzęcie, musisz przejść do innego obsługiwanego wariantu SKU, który nie jest wycofany z eksploatacji i jest bardziej dostępny. To przejście może również jednocześnie wymagać zmiany modelu, jeśli nowa jednostka SKU nie obsługuje bieżącego modelu.

Rekomendacje

• Dodaj warstwy abstrakcji i pośredniości, aby umożliwić kontrolowane modyfikacje określonych obszarów obciążenia roboczego. Obszary te obejmują aplikację kliencką, inteligentny interfejs API, orkiestrację, hosting modelu i wiedzę bazową.

• Wszystkie zmiany w wersjach modelu, promptach, konfiguracjach, logice orkiestracji i pobieraniu wiedzy podstawowej muszą być testowane przed użyciem w środowisku produkcyjnym. Upewnij się, że przetestowane kombinacje są przypięte razem w środowisku produkcyjnym, co oznacza, że pozostają ściśle połączone podczas wdrażania. Testy A/B, równoważenie obciążenia i wdrożenia blue-green nie mogą mieszać składników, aby uniknąć narażania użytkowników na nietestowane kombinacje.

• Przetestuj i oceń nowe wersje oraz nowe modele przy użyciu zautomatyzowanych procesów. Należy porównać wyniki z wynikami punktu odniesienia, aby upewnić się, że uzyskasz wymagane wyniki.

• Należy celowo aktualizować modele. Unikaj używania funkcji platformy, które automatycznie uaktualniają modele produkcyjne do nowych wersji bez możliwości testowania. Należy pamiętać o tym, jak każda aktualizacja modelu wpływa na obciążenie. Jeśli używasz Azure AI Foundry Models API, ustaw wdrożenia z określoną wersją i nie określaj polityki uaktualniania. Ta konfiguracja wymaga ręcznego uaktualnienia w przypadku wydania nowej wersji. W przypadku usługi Azure OpenAI ustaw wdrożenia na Brak automatycznej aktualizacji, aby wyłączyć automatyczne aktualizacje.

• Upewnij się, że rozwiązanie do obserwacji i rejestrowania zbiera wystarczającą ilość metadanych, aby skorelować zaobserwowane zachowanie z konkretnym monitem, konfiguracją, modelem i rozwiązaniem pobierania danych. Ta korelacja umożliwia zidentyfikowanie nieoczekiwanych regresji wydajności systemu.

Podsumowanie

Istnieje wiele powodów aktualizowania modelu bazowego w procesie generowania. Te przyczyny wahają się od wymaganych uaktualnień wersji po wycofaniu modeli do decyzji o przełączeniu się do innego modelu. W zależności od zakresu aktualizacji modelu może być konieczne zaimplementowanie i ocenę zmian w modelu, w tym zmian monitu, konfiguracji modelu, logiki aranżacji lub potoku danych. Należy postępować zgodnie ze wskazówkami dotyczącymi metodyki MLOps, metodyki DataOps i metodyki GenAIOps, aby tworzyć zautomatyzowane przepływy pracy dla różnych aspektów rozwiązania. Zautomatyzowane przepływy pracy umożliwiają testowanie, ocenianie i wdrażanie nowych wersji. Należy również upewnić się, że architektura obsługuje uruchamianie wielu wersji orchestratora, gdzie każda wersja łączy swoją konfigurację i wersję podpowiedzi z określoną wersją modelu.

Architektura powinna obsługiwać aktualizacje nowych lub różnych modeli oraz wszelkie niezbędne zmiany w konfiguracji monitu lub modelu bez konieczności modyfikowania inteligentnej aplikacji lub środowiska użytkownika. Te aktualizacje powinny być hermetyzowane w odpowiednich składnikach, a operacje powinny zautomatyzować testowanie, ocenę i wdrażanie tych zmian.

Współautorzy

Firma Microsoft utrzymuje ten artykuł. Następujący współautorzy napisali ten artykuł.

• Ritesh Modi | Główny inżynier oprogramowania

Aby wyświetlić niepubliczne profile serwisu LinkedIn, zaloguj się do serwisu LinkedIn.

Następny krok

• Przestarzałość i wycofanie modeli Azure OpenAI

Powiązane zasoby

• Podstawowa architektura referencyjna czatu AI Foundry
• Metodyka MLOps
• GenAIOps dla praktyków metodyki MLOps