DevOps ze sztuczną inteligencją i LLMOps: od potoku do modelu, który przemawia

Informatec Digital » Zasoby » DevOps ze sztuczną inteligencją i LLMOps: od potoku do modelu, który przemawia

Pojawienie się generatywnej sztucznej inteligencji i rozbudowanych modeli językowych całkowicie zmieniło sposób tworzenia, wdrażania i obsługi oprogramowania. Posiadanie dobrych rzeczy już nie wystarcza. Procesy DevOps ani stosując klasyczne MLOpsGdy do równania wprowadzisz LLM, wkraczasz w sferę, w której model mówi, rozumuje, improwizuje i czasami zachowuje się w nieprzewidywalny sposób.

W tym nowym scenariuszu, Zespoły muszą łączyć metodykę DevOps, sztuczną inteligencję i podejście LLMOps, aby zarządzać całym cyklem życia aplikacji opartych na podejściu LLM.Od eksperymentów i szybkiej inżynierii po wdrażanie, monitorowanie, bezpieczeństwo i optymalizację kosztów — ten artykuł sprowadza cały ten szum na ziemię i krok po kroku przeprowadzi Cię przez proces wdrażania ChatOps, DevOps, MLOps, GenAIOps i LLMOps w nowoczesnym przedsiębiorstwie.

Od DevOps i MLOps do LLMOps: dlaczego model nie jest już statyczny

Przez lata priorytetem zespołów inżynierskich było automatyzacja dostarczania oprogramowania i zmniejszyć tarcie między rozwojem a infrastrukturąTak narodził się DevOps: ciągła integracja, ciągłe wdrażanie, infrastruktura jako kod, możliwość obserwacji i kultura współpracy, która wyeliminowała niekończące się przekazywanie zadań między działami.

Gdy dane stały się częścią produktu, pojawiły się MLOps jako odpowiedź na potrzebę powtarzalności i śledzenia modeli uczenia maszynowegoStandaryzowano praktyki takie jak wersjonowanie zbiorów danych, koordynacja procesu szkoleniowego, wykrywanie dryfu i ciągła ocena modeli predykcyjnych.

Problemem jest LLM-y łamią wiele założeń zawartych w DevOps i MLOpsNie są to statyczne interfejsy API ani proste funkcje zwracające określoną liczbę: reagują w języku naturalnym, łączą w czasie rzeczywistym kontekst, instrukcje, narzędzia i dane oraz mogą generować dwa różne wyniki dla tych samych danych wejściowych.

To daje do zrozumienia ze Sama zmiana modelu i jego wagi nie wystarczyNależy również kontrolować monity, szablony, zasady bezpieczeństwa semantycznego, ograniczenia, podłączone narzędzia, wstrzykiwany kontekst, a nawet reguły biznesowe, które warunkują zachowanie systemu.

Czym jest LLMOps i co właściwie rozwiązuje?

Możemy zobaczyć LLMOps jako struktura operacyjna umożliwiająca bezpieczne, kontrolowane i zrównoważone wdrażanie, konserwację i skalowanie aplikacji opartych na LLMJest to kompleks, pod którym współistnieją praktyki DevOps, MLOps i nowe możliwości specyficzne dla modeli generatywnych.

W istocie LLMOps koncentruje się mniej na „wyszkoleniu idealnego modelu”, a bardziej na kontrolowaniu jego zachowania w środowisku produkcyjnym.Obejmuje ona sposób projektowania i wersjonowania przepływów natychmiastowych, sposób łączenia LLM z wewnętrznymi źródłami danych, sposób monitorowania kosztów tokenów i opóźnień oraz sposób zarządzania ryzykiem semantycznym (halucynacje, wycieki informacji, stronniczość, toksyczne reakcje itp.).

Potrzeby, które zaspokaja LLMOps, a których nie zaspokajają same DevOps/MLOps, obejmują: aspekty tak różnorodne, jak śledzenie konwersacji, automatyczna ocena jakości odpowiedzi lub porównanie wariantów zachowań metodą A/BNie chodzi nam wyłącznie o klasyczną dokładność, ale także o spójność, dopasowanie do potrzeb firmy i bezpieczeństwo.

Ponadto, Koszty nie ograniczają się już tylko do szkolenia i hostingu modeluKażdy monit, każdy rozszerzony kontekst i każde jednoczesne wywołanie wyzwala zużycie GPU lub tokenów w komercyjnych interfejsach API. Bez warstwy LLMOps, która uwidacznia to zużycie i łączy je ze sprzętem, usługami i przypadkami użycia, rachunek rośnie nieprzewidywalnie.

ChatOps + LLMOps + DevOps: operacje stają się konwersacją

Jednym z najpotężniejszych trendów jest integracja ChatOps i LLMOps w kulturze DevOpsZamiast ograniczać się do pulpitów nawigacyjnych, skryptów i potoków, zespoły zaczynają obsługiwać znaczną część systemu za pośrednictwem kanałów czatu, takich jak Slack, Microsoft Teams lub Discord.

ChatOps proponuje codzienne operacje (wdrożenia, zapytania do dzienników, ponowne uruchomienia, zmiany konfiguracji) są wykonywane przez boty w obrębie samego kanału komunikacji, transparentnie dla całego zespołu. Każde polecenie, działanie i wynik są rejestrowane w rozmowie.

Gdy do tego podejścia dodamy LLM, pojawia się nowy poziom inteligencji: Chatboty rozumiejące język naturalny, interpretujące intencje i potrafiące wykonywać złożone polecenia lub analizować sytuacje bez konieczności zapamiętywania przez operatora każdego dokładnego skryptu lub flagi.

Typowe przykłady tej konwergencji obejmują: bot oparty na LLM odczytuje metryki Prometheusa i logi Lokiego Gdy ktoś pisze „usługa grupy X jest powolna” i sugeruje działania, takie jak eskalacja replik, wycofanie zmian lub uruchomienie konkretnych testów, wszystko jest wyjaśnione w języku naturalnym.

Na poziomie kulturowym i operacyjnym przekłada się to na Szybsze podejmowanie decyzji, mniej ręcznych interwencji w powtarzalnych zadaniach i płynniejsze działanie zespołów DevOps, którzy przechodzą od ciągłego gaszenia pożarów do pracy nad strategicznymi ulepszeniami.

Kluczowe zasady cyklu życia LLM w produkcji

Prowadzenie poważnego programu LLM nie jest jednorazowym projektem, to cykl, który się powtarza i w którym każda zmiana może zmienić zachowanie systemuMimo że każda organizacja dostosowuje go do własnej rzeczywistości, zwykle wyróżnia się sześć głównych etapów, które wzajemnie na siebie oddziałują.

Pierwsza to faza szkolenia lub adaptacji modeluMoże to obejmować zarówno korzystanie z modelu podstawowego, jak i zastosowanie dostrajania, LoRa lub innych technik dostrajania z wykorzystaniem własnych danych. Ważna jest tu nie tylko wydajność, ale także pozostawienie kompletnego zapisu: zestawów danych, zastosowanych filtrów, hiperparametrów, wersji tokenizera, przetestowanych architektur itp.

Jeżeli ta faza jest improwizowana i nie jest udokumentowana, model rodzi się bez zarządzaniaPóźniej będzie już prawie niemożliwe wyjaśnienie, dlaczego reaguje w taki sposób lub powtórzenie konkretnego wyniku, gdy będzie to potrzebne podczas audytu.

Drugim etapem jest wdrożenie, podczas którego model opuszcza laboratorium i trafia do produkcji. W LLMOps nie chodzi tylko o „umieszczenie go w kontenerze”: Musimy zdecydować jaki sprzęt użyćJak zarządzać pamięcią w przypadku długotrwałych kontekstów, jaką topologię klastra zastosować i jak skalować w oparciu o ruch bez gwałtownego wzrostu opóźnień i sytuacji, w której koszty staną się nieosiągalne.

To właśnie tutaj wchodzą w grę rzeczy ciągły monitoring zorientowany na zachowanieNie wystarczy przyglądać się procesorowi i pamięci RAM; konieczne jest monitorowanie jakości semantycznej odpowiedzi, stabilności stylu, współczynnika błędów, zmian kosztu za token, pojawiania się niebezpiecznych lub niespójnych odpowiedzi i zmian czasu odpowiedzi przy różnych wzorcach użytkowania.

W późniejszych fazach wykonywane są zadania optymalizacyjne i dostrajające: dotknij monit, dostosuj RAG, przetestuj warianty modelu, kwantyzuj, przeprowadź testy A/B, zmień zasady bezpieczeństwa semantycznego lub udoskonal zasady biznesoweTo proces niemal rzemieślniczy, w którym dane, inżynieria i biznes spotykają się, aby wspólnie zdecydować, co jest priorytetem.

Na koniec wszystko to mieści się w warstwy bezpieczeństwa i zarządzania (kontrola dostępu, audyt, zapobieganie wyciekom, limity użytkowania, zgodność z przepisami) oraz w logice ciągłej aktualizacji, w której model i jego ekosystem są dostosowywane do zmian danych, przepisów i wewnętrznych potrzeb.

GenAIOps i podejście do przepływu powiadomień w usłudze Azure

W środowisku LLMOps istnieją bardzo konkretne propozycje dotyczące strukturyzowania tego cyklu życia. Jedną z najbardziej zaawansowanych w środowisku korporacyjnym jest GenAIOps z szybkim przepływem w usłudze Azure Machine Learning zintegrowanej z usługą Azure DevOps, który proponuje bardzo systematyczne podejście do tworzenia aplikacji opartych na LLM.

Przepływ monitu to nie tylko edytor monitu; to kompletna platforma do projektowania, testowania, wersjonowania i wdrażania przepływów interakcji LLMod prostych przypadków (pojedynczy monit) do złożonych orkiestracji z wieloma węzłami, narzędziami zewnętrznymi, elementami sterującymi i automatycznymi ocenami.

Krytyczną cechą jest scentralizowane repozytorium przepływówktóra działa jak biblioteka korporacyjna. Zamiast, aby każdy zespół miał swoje podpowiedzi w oddzielnych dokumentach lub własnych repozytoriach, są one konsolidowane w jednym zarządzanym repozytorium z przejrzystymi gałęziami, rewizjami i historiami.

Ponadto platforma dodaje możliwości eksperymentowania z wariantami i hiperparametrami: Można testować różne kombinacje monitów, modeli, ustawień temperatury lub zasad bezpieczeństwa w wielu węzłach przepływu i porównywać wyniki za pomocą przejrzystych metryk.

W odniesieniu do wdrożenia, GenAIOps z przepływem powiadomień Generuje obrazy Dockera, które obejmują zarówno przepływ pracy, jak i sesję procesu.Są one gotowe do uruchomienia w środowiskach takich jak Azure App Services, Kubernetes czy procesy zarządzane. Na tej podstawie możliwe są wdrożenia A/B, umożliwiające porównywanie wersji przepływów w rzeczywistych środowiskach.

Kolejną zaletą jest zarządzanie relacjami między zbiorami danych i przepływami. Każdy przepływ ewaluacji może współpracować z wieloma standardowymi i testowymi zestawami danychPozwala to na weryfikację zachowań w różnych scenariuszach przed przekazaniem produktu użytkownikom końcowym.

Platforma automatycznie rejestruje nowe wersje zestawów danych i przepływów tylko wtedy, gdy zachodzą rzeczywiste zmiany, Generuje kompleksowe raporty w formatach CSV i HTML. aby wspierać decyzje oparte na danych, a nie intuicji.

Cztery fazy GenAIOps z przepływem powiadomień

Podejście GenAIOps dzieli cykl życia na cztery wyraźnie zróżnicowane etapy, co pomaga uniknąć typowego chaosu polegającego na tym, że „wypróbowujemy różne rozwiązania ze sztuczną inteligencją i zobaczymy, co się stanie”.

Pierwsza faza, inicjalizacja, skupia się na Precyzyjnie zdefiniuj cel biznesowy i zbierz reprezentatywne przykłady danychW tym miejscu zarysowano podstawową strukturę przepływu komunikatów i zaprojektowano architekturę, która następnie zostanie udoskonalona.

W fazie eksperymentalnej przepływ jest stosowany do danych próbki i Oceniane są różne warianty monitów, modeli i konfiguracji.Proces ten jest nieustannie powtarzany, aż do znalezienia akceptowalnej kombinacji spełniającej minimalne standardy jakości i spójności.

Następnie następuje faza oceny i udoskonalania, w której Do przeprowadzania rygorystycznych testów porównawczych wykorzystuje się większe i bardziej zróżnicowane zbiory danychDopiero gdy przepływ będzie charakteryzował się spójną wydajnością zgodną z określonymi standardami, uznaje się go za gotowy do przejścia do kolejnego etapu.

Na koniec, w fazie wdrażania, przepływ jest optymalizowany pod kątem wydajności i wdrażany w środowisku produkcyjnym. w tym opcje wdrażania A/B, monitorowanie, zbieranie opinii użytkowników i cykle ciągłego doskonaleniaNic nie jest ustalone na stałe: przepływ jest stale dostosowywany na podstawie obserwacji rzeczywistego użytkowania.

Ta metodologia jest zawarta w szablonie repozytorium GenAIOps, z gotowymi potokami opartymi na kodzie i Lokalne i oparte na chmurze narzędzia wykonawcze do tworzenia, oceniania i wdrażania aplikacji opartych na LLM bez konieczności wymyślania Ameryki na nowo w każdym projekcie.

Integracja z usługą Azure DevOps: repozytoria, potoki i uwierzytelnianie

Aby przenieść GenAIOps z teorii do rzeczywistej organizacji, kluczowe jest zintegrowanie go z Azure DevOps. Typowy szablon zaczyna się od repozytorium w Azure Repos z dwiema głównymi gałęziami: główną i rozwojową, które odzwierciedlają różne środowiska i strategie promocji kodu.

Przykładowe repozytorium jest klonowane z GitHub, powiązane z Azure Repos i Zazwyczaj pracujemy, tworząc gałęzie funkcjonalności na podstawie fazy rozwoju.Zmiany są wysyłane za pomocą żądań ściągnięcia, które automatycznie uruchamiają procesy walidacji i eksperymentowania.

Aby usługa Azure DevOps mogła współdziałać z usługą Azure Machine Learning i innymi usługami, należy ją skonfigurować jednostka usługi w usłudze Azure jako tożsamość technicznaTa tożsamość jest używana w połączeniu z usługą Azure DevOps, dzięki czemu potoki są uwierzytelniane bez ujawniania kluczy w postaci zwykłego tekstu.

Zwykle ta jednostka ma uprawnienia właściciela do subskrypcji ML lub zasobu roboczego, dzięki czemu Przepływy danych mogą zapewniać punkty końcowe, rejestrować modele i aktualizować zasady w magazynach kluczyJeśli chcesz zwiększyć bezpieczeństwo, możesz dostosować rolę do Współpracownika, dostosowując kroki YAML, które obsługują uprawnienia.

Dodatkowo w usłudze Azure DevOps tworzona jest grupa zmiennych, która Przechowuje poufne dane, takie jak nazwa połączenia z usługą lub identyfikatory zasobów.Zmienne te są udostępniane potokom jako środowisko, co pozwala uniknąć konieczności kodowania krytycznych informacji na stałe w kodzie.

Konfigurowanie repozytoriów lokalnych i zdalnych umożliwia: Gałąź rozwojowa jest chroniona politykami gałęzi które wymagają uruchomienia potoku żądania ściągnięcia przed zezwoleniem na scalenie. Ten potok obsługuje walidację kompilacji i przepływy eksperymentów, zapobiegając wprowadzaniu wadliwych zmian.

Po wejściu kodu do fazy rozwoju uruchamiany jest proces rozwoju, który Obejmuje kompletne fazy CI i CD:przeprowadzanie eksperymentów i ocen, rejestrowanie przepływów w rejestrze modelu Azure ML, wdrażanie punktów końcowych i testów dymowych oraz integrowanie nowo utworzonych punktów końcowych.

Ten sam schemat jest powielany w całej wersji lub gałęzi wydania, połączonej ze środowiskami produkcyjnymi. Tam, Procesy CI/CD dla produkcji powtarzają cykl eksperymentowania, oceny i wdrażaniaale na poziomie infrastruktury i danych produkcyjnych, z większą kontrolą i dodatkowymi przeglądami ręcznymi, jeśli zajdzie taka potrzeba.

Kluczowym szczegółem jest „przegląd pętli ludzkiej” zawarty w tych procesach: Po fazie CI płyta CD pozostaje zablokowana do momentu jej ręcznego zatwierdzenia przez użytkownika. Kontynuacja pochodzi z interfejsu Azure Pipelines. Jeśli nie zostanie zatwierdzona w określonym czasie (na przykład 60 minut), wykonanie zostanie odrzucone.

Lokalna implementacja i połączenie z dostawcami LLM

Nie wszystko kręci się wokół potoków: GenAIOps obsługuje również lokalne wykonanie w celu szybkiego eksperymentowaniaMożesz sklonować repozytorium szablonów, utworzyć plik .env w katalogu głównym i zdefiniować w nim połączenia z usługą Azure OpenAI lub innymi zgodnymi punktami końcowymi.

Połączenia te obejmują parametry takie jak api_key, api_base, api_type i api_version. Są one odwoływane według nazwy w przepływach (na przykład połączenie o nazwie „aoai” z określoną wersją API). W ten sposób ten sam przepływ może być wykonywany lokalnie i w chmurze bez konieczności wprowadzania zmian w kodzie.

Aby użyć tego trybu, wystarczy utwórz środowisko wirtualne lub conda i zainstaluj niezbędne zależności (promptflow, promptflow-tools, promptflow-sdk, openai, jinja2, python-dotenv itp.). Stamtąd możesz pisać skrypty testowe w lokalnym folderze wykonawczym i uruchamiać eksperymenty na zdefiniowanych przepływach.

Ta dwoistość chmury/lokalu doskonale wpisuje się w dojrzałe podejście DevOps: Jest on testowany lokalnie na małą skalę, formalnie weryfikowany w procesach, a następnie wdrażany w środowiskach wyższego poziomu przy użyciu mechanizmów kontroli i audytów.Wszystko jest wersjonowane w Git i połączone z usługą Azure DevOps.

Typowe narzędzia w ekosystemie DevOps ze sztuczną inteligencją i LLMOps

Oprócz konkretnej oferty platformy Azure, nowoczesny ekosystem DevOps ze sztuczną inteligencją i LLMOps zazwyczaj opiera się na zestaw narzędzi obejmujący ChatOps, orkiestrację modeli, monitorowanie i obserwowalność.

W warstwie ChatOps powszechne jest łączenie Slack z botami takimi jak HubotFirma Microsoft współpracuje z agentami opartymi na Power Virtual Agents lub Discord, a także z frameworkami takimi jak Botpress lub Rasa, aby tworzyć niestandardowe asystenty łączące się z potokami, systemami monitorowania i usługami wewnętrznymi.

W płaszczyźnie LLMOps/MLOps występują one często platformy takie jak Kubeflow i MLflow do zarządzania procesami, rekordami modeli i eksperymentami, a także konkretnymi narzędziami, takimi jak Weights & Biases (W&B), służącymi do zaawansowanego śledzenia metryk, porównywania przebiegów lub tworzenia dogłębnych wizualizacji.

Do tworzenia aplikacji na LLM powszechnie używa się frameworki takie jak LangChain lub biblioteki typu OpenLLMRozwiązania te ułatwiają tworzenie łańcuchów komunikatów, łączników do danych zewnętrznych, narzędzi i agentów wieloetapowych. Jednocześnie pojawiają się rozwiązania do obserwowalności specyficznej dla LLM, umożliwiające monitorowanie komunikatów, odpowiedzi, kosztów i jakości.

W integracji z klasycznym podejściem DevOps narzędzia takie jak Jenkins lub GitLab CI pozostają istotne w części CI/CD, Kubernetes i ArgoCD do ciągłego wdrażania w chmurzeoraz stosy narzędzi do obserwacji, takie jak Prometheus, Grafana i Loki, służące do gromadzenia metryk, pulpitów nawigacyjnych i dzienników.

Wyzwania, ograniczenia i stopniowe wdrażanie

Wdrażanie praktyk i narzędzi nie jest darmowe. Złożoność zarządzania monitami, wersjami modeli i wariantami przepływu jest znaczny, zwłaszcza gdy wiele zespołów pracuje jednocześnie —scenariusz, w którym wskazane jest zastosowanie strategie takie jak GitOps aby koordynować zmiany i wdrożenia.

Ponadto boty ChatOps i same LLM-y mają możliwość działania Wprowadzają znaczne ryzyko bezpieczeństwa jeśli mają nadmierne uprawnienia w środowiskach produkcyjnych lub jeśli powierzchnie ujawniania danych nie są odpowiednio kontrolowane.

Do tego dochodzi zależność od modeli open-source z wrażliwymi licencjami lub komercyjnymi interfejsami API Co może zmienić warunki, ceny lub limity. Co gorsza, dokładna ocena LLM w produkcji pozostaje otwarta, a wiele pytań wciąż pozostaje bez odpowiedzi.

Dlatego ma sens zająć się wdrażaniem LLMOps i ChatOps w ramach DevOps w sposób postępowy i kontrolowany, zaczynając od automatyzacji powtarzalnych zadań za pomocą prostych botów (ponowne uruchamianie, zapytania dotyczące dzienników, tagowanie kompilacji itp.).

Później można je wprowadzić LLM w zakresie zadań wsparcia, klasyfikacji incydentów lub pomocy w debugowaniuNa przykład poprzez objaśnianie błędów na podstawie rejestrów lub proponowanie środków zaradczych na podstawie wewnętrznej dokumentacji.

Gdy klasyczna operacja ML zostanie ustabilizowana, nadszedł czas na adresowanie LLMOps za pomocą specjalistycznych modeli językowych dla takich obszarów jak obsługa klienta, DevSecOps czy QA, wykorzystując wszystko, czego nauczyliśmy się w poprzednich fazach.

Horyzont, ku któremu zmierzają wszystkie te praktyki, to środowisko inżynierskie umożliwiające konwersację, predykcyjne i coraz bardziej autonomicznegdzie znaczna część rozwoju i działania jest wyrażona w języku naturalnym, a sztuczna inteligencja pomaga podejmować proaktywne decyzje dotyczące wdrożeń, skalowania lub wycofywania.

Mając tę ​​układankę — DevOps, ChatOps, MLOps, GenAIOps i LLMOps — organizacje muszą solidne ramy do tworzenia i utrzymywania systemów opartych na LLM, które naprawdę przynoszą wartośćUtrzymanie kontroli nad jakością, kosztami, bezpieczeństwem i zgodnością z działalnością firmy, zamiast ograniczania się do prostych prototypów lub odosobnionych testów, które rozpadają się natychmiast po dotarciu do produkcji.