MLOps a LLMOps: infrastruktura dla modeli foundation

Viacheslav Dubrov

2025-05-06 · Zaktualizowano 2026-07-15 · 7 min · Infrastruktura AI

Tłumaczenie automatyczne Ten artykuł został automatycznie przetłumaczony z angielskiego oryginału.

Gdy wydanie modelu foundation powoduje regresję, plik z wagami może pozostać niezmieniony: elementem, który uległ zmianie, może być prompt, indeks wyszukiwania, uprawnienie narzędzia, trasa lub polityka. Dlatego dla inżynierów ML, platform i aplikacji AI, którzy już utrzymują klasyczne MLOps, praktycznym artefaktem jest manifest wydania wskazujący te zależności oraz pierwszy mechanizm kontrolny, który należy sprawdzić po wystąpieniu awarii.

To model operacyjny o charakterze redakcyjnym, a nie twierdzenie, że każda aplikacja potrzebuje tej samej platformy. Zachowaj lineage w MLOps, dostarczanie etapowe, monitoring i rollback; rozszerz jednak wersjonowaną jednostkę, gdy generowane odpowiedzi lub działania narzędzi sprawiają, że zachowanie zależy od czegoś więcej niż tylko od wag.

TL;DR. Zachowaj lineage w MLOps, automatyzację, dostarczanie etapowe, monitoring i rollback. Rozszerz manifest wydania o dostawcę lub wagi, prompty, schematy, stan wyszukiwania, narzędzia, routing i politykę. Promuj ten manifest przez warstwową ewaluację, a następnie używaj śladów uwzględniających prywatność, aby przekształcać awarie produkcyjne w nowe testy.

Co MLOps już rozwiązało

MLOps ustanowiło mechanizmy kontrolne, które nie tracą aktualności, gdy model generuje tekst:

• lineage od danych, kodu, konfiguracji i modelu do wydania
• powtarzalne pipeline’y trenowania lub budowania
• walidacja offline przed promocją
• rejestry i niezmienna tożsamość artefaktów
• etapowe wdrażanie, cele poziomu usługi, rollback i reagowanie na incydenty
• telemetria infrastruktury i planowanie pojemności
• kontrola dostępu, retencja i polityka audytowa danych

Modele foundation nie eliminują tych potrzeb. Sprawiają jedynie, że dawne określenie „wersja modelu” staje się zbyt wąskie.

Jednostka wydania stała się manifestem systemu

W przypadku systemu opartego na modelu foundation zalecam manifest rejestrujący co najmniej:

application code revision
model provider + model/revision + serving configuration
system and task prompts
response schema + decoding parameters
retrieval corpus snapshot + parser + chunker + embedding model + index
tool definitions + implementation revisions + permission policy
routing, fallback, caching, and budget policy
safety and business-rule revisions
evaluation dataset + scorer revisions

Dokładna lista zależy od systemu. Zasada redakcyjna jest taka, aby zidentyfikować każdy niezależnie zmieniający się komponent, który może wpłynąć na zachowanie widoczne dla użytkownika.

Traktuj nazwę modelu dostawcy jako zmienną, chyba że dostawca dokumentuje niezmienną rewizję. Hash checkpointu pomaga identyfikować wagi utrzymywane samodzielnie, ale mimo to rejestrowałbym runtime, kwantyzację, template i konfigurację równoległości.

Pięć rozszerzonych powierzchni awarii

Różnica między MLOps a LLMOps jest wyraźniejsza w analizie awarii niż w listach narzędzi.

1. Model i serwowanie

Na potrzeby planowania rozdziel kwestie modeli hostowanych (dostępność dostawcy, limity, przetwarzanie regionalne i koszt użycia) od kwestii modeli utrzymywanych samodzielnie (dostępność wag, pojemność GPU, batchowanie, polityka cache, kwantyzacja i serwowanie). Odpowiednie mechanizmy kontrolne zależą od wybranego sposobu wdrożenia.

W obu trybach uwzględnij w decyzji o wydaniu opóźnienie, błędy, przepustowość, nasycenie, koszt i kontrole jakości zadania.

2. Prompt, schemat i orkiestracja

W systemie, który składa żądania w runtime, wersjonuj złożone żądanie, a nie tylko tekst promptu: kolejność komunikatów, opisy narzędzi, schemat odpowiedzi, dekodowanie, ponowienia, obcinanie oraz otaczający kod mogą niezależnie zmienić zachowanie.

Traktuj poprawny składniowo JSON jako kontrolę transportu, a następnie osobno testuj niezmienniki biznesowe zadania.

3. Wyszukiwanie i kontekst

Wyszukiwanie dodaje niezależny produkt danych między źródłem prawdy a modelem:

W systemie opartym na wyszukiwaniu zachowuj rewizję źródła, wersje parsera i chunkera, tożsamość embedding, proces budowania indeksu, metadane kontroli dostępu oraz stan usunięcia. Oryginalny projekt RAG rozdziela wyszukiwanie od generowania; wykorzystaj ten podział do niezależnego testowania wyszukiwania dowodów, filtrowania autoryzacyjnego i wykorzystania dowodów. Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks opisuje architekturę wyszukiwania, a następnie generowania.

Nie używaj indeksu wektorowego jako zamiennika feature store ani hurtowni danych: wyszukiwanie podobieństwa, cechy point-in-time i fakty analityczne mają różne wymagania dotyczące zapytań i spójności.

4. Narzędzia i działania

Gdy model może wywoływać API, uwzględnij w granicy operacyjnej uwierzytelnianie narzędzi, zasadę najmniejszych uprawnień, walidację argumentów, limity czasu, idempotencję, politykę akceptacji i kontrole postcondition. Generative AI Profile firmy NIST wskazuje ryzyka związane ze szkodliwą treścią, prywatnością i bezpieczeństwem; wymienione mechanizmy kontrolne stanowią ukierunkowaną rekomendację inżynieryjną, a nie kompletny katalog kontroli.

Śledź, które narzędzie zostało udostępnione, wybrane, wywołane, odrzucone, ponowione i zatwierdzone. Płynna odpowiedź końcowa nie dowodzi, że ścieżka działania była prawidłowa.

5. Bezpieczeństwo, security i polityka

Filtry treści to jeden z mechanizmów kontrolnych, a nie kompletna warstwa guardrails. Zagrożenia obejmują również prompt injection, wyszukiwanie między tenantami, ujawnienie sekretów, nadmierną autonomię, niezaufany kod modelu lub węzła oraz niebezpieczne argumenty narzędzi.

W miarę możliwości wyrażaj deterministyczne reguły biznesowe poza modelem. Zdefiniuj ryzyka rezydualne, testuj przypadki adwersarialne i wyznacz właściciela zmian polityki. Generative AI Profile firmy NIST to użyteczny inwentarz ryzyka, a nie gotowy test akceptacyjny.

Ewaluacja staje się bramką wydania

W decyzjach dotyczących wydań generujących swobodny tekst nie polegaj na jednej zagregowanej wartości accuracy. Używaj kilku typów dowodów i określ, który z nich jest rozstrzygający dla każdego trybu awarii.

Zbuduj stos ewaluacyjny obejmujący kilka typów dowodów:

1. Kontrole deterministyczne: poprawność schematu, obecność cytowań, dozwolone narzędzia, ograniczenia argumentów, reguły polityki, opóźnienie i budżet.
2. Metryki komponentów: recall wyszukiwania i ranking, accuracy wyboru narzędzia, poprawność argumentów narzędzia oraz wybór trasy.
3. Zadania end-to-end: reprezentatywne dane wejściowe z jawnymi kryteriami sukcesu i etykietami wycinków.
4. Scoring oparty na modelu: oceny według rubryki kalibrowane względem etykiet ekspertów i monitorowane pod kątem driftu sędziego.
5. Weryfikacja przez człowieka: przypadki niejednoznaczne, konsekwentne, nowe lub losowo próbkowane, w których automatyzacja nie jest źródłem rozstrzygającym.
6. Testy adwersarialne: injection, granice danych, nadużycia, odmowy i przypadki efektów ubocznych powiązane z modelem zagrożeń.

Przechowuj wyniki dla poszczególnych przykładów, a nie tylko średnie, aby podczas przeglądu wydania można było analizować regresje według języka, tenanta, typu dokumentu lub klasy działania.

W przypadku bramki wdrożeniowej porównuj manifest kandydata z bieżącym wydaniem na tym samym, wersjonowanym zestawie testów. Ustalaj jednocześnie progi jakości, bezpieczeństwa, opóźnienia i kosztu; tańsza trasa, która nie wykonuje zadania poprawnie, nie jest optymalizacją.

Ślady łączą produkcję z ewaluacją

Metryki infrastruktury mogą pokazać, że wywołanie modelu trwało długo. Nie pokażą jednak, że wyszukiwanie zwróciło dokument, do którego użytkownik nie miał uprawnień, ani że narzędzie zostało wywołane z nieprawidłowym kontem. Dokumentacja tracingu w MLflow opisuje ślady rejestrujące kroki pośrednie i metadane potrzebne do zbadania tej ścieżki.

Rejestruj ślad obejmujący całą ścieżkę decyzyjną:

• tożsamość manifestu wydania i korelację żądania
• wywołania modelu i dostawcy, opóźnienie, użycie oraz stan zakończenia
• zapytanie wyszukiwania, identyfikatory dokumentów, wyniki i decyzje filtrowania
• rewizję promptu/template’u bez bezwarunkowego przechowywania wrażliwej treści
• udostępnione narzędzia, argumenty, akceptacje, wyniki i identyfikatory efektów ubocznych
• decyzje polityki, ponowienia, fallbacki i wynik końcowy

Tracing tworzy nową powierzchnię zarządzania danymi. Przed gromadzeniem pełnych promptów lub dokumentów zastosuj minimalizację, redakcję, izolację tenantów, szyfrowanie, próbkowanie, retencję i przegląd dostępu. Konwencje semantyczne GenAI w OpenTelemetry mogą pomóc w interoperacyjności, ale nadal są rozwijane. Przypnij wersję konwencji lub schematu, wersję instrumentacji i wersje collectora.

Pętla doskonalenia wygląda następująco:

production trace → triaged failure → labeled regression case
                 → candidate change → offline comparison
                 → staged release → monitored outcome

Informacje zwrotne od użytkowników mogą pomóc ustalić priorytety dochodzenia, ale „kciuk w górę” nie jest ground truth. Zachowuj otaczający ślad i pozyskuj etykiety ekspertów dla przypadków o istotnych konsekwencjach.

Gateway serwujący jest granicą polityki

Gateway może odseparować klientów aplikacji od dostawców lub silników utrzymywanych samodzielnie. Warto umieścić w nim między innymi:

• uwierzytelnianie, budżety tenantów, limity i rate limiting
• stabilne kontrakty żądań i odpowiedzi
• wybór trasy według możliwości, regionu, opóźnienia lub ocenionej jakości
• ograniczone ponowienia, circuit breakery i jawne semantyki fallbacku
• partycjonowanie cache oraz politykę danych wrażliwych
• przypisywanie użycia i propagowanie manifestu wydania

Fallback jest zmianą zachowania w takim samym stopniu, jak mechanizmem niezawodności. Jeśli mniejszy model, alternatywny dostawca lub ograniczony kontekst zmienia jakość zadania, oceniaj i śledź tę gałąź jako osobną trasę.

Nie umieszczaj każdej decyzji orkiestracyjnej w gatewayu. Reguły domenowe trzymaj blisko aplikacji i zapewnij widoczną odpowiedzialność.

Fine-tuning to jedna z interwencji, a nie drabina dojrzałości

Wybieraj interwencję na podstawie zaobserwowanej awarii:

LoRA zamraża wagi pretrenowanego modelu i dodaje trenowalne macierze niskiego rzędu, zmniejszając liczbę trenowalnych parametrów dla zadania downstream. Ta optymalizacja nie eliminuje potrzeby zarządzania datasetem, licencjonowania modelu bazowego, ewaluacji, kompatybilności serwowania ani wymagań dotyczących rollbacku.

Praktyczna kolejność wdrażania

1. Zdefiniuj zadanie użytkownika, granice szkód, cele poziomu usługi i budżet kosztowy.
2. Utwórz manifest wydania przed wprowadzeniem rejestru promptów, wektorowej bazy danych lub produktu typu gateway.
3. Zbuduj niewielki, podzielony na wycinki zestaw ewaluacyjny oraz deterministyczne testy komponentów.
4. Zinstrumentuj jeden ślad end-to-end z kontrolami prywatności i stabilnymi tożsamościami wydań.
5. Promuj wydanie przez shadow, canary lub ograniczony ruch z jawnym wyzwalaczem rollbacku.
6. Przekształcaj zweryfikowane awarie produkcyjne w przypadki regresyjne i powtarzaj proces.

Dodawaj infrastrukturę tylko wtedy, gdy przejmuje odpowiedzialność za nazwany mechanizm kontrolny lub usuwa zmierzony wąskie gardło. „Platforma LLMOps” nie jest wymaganiem architektonicznym.

Podsumowanie

LLMOps to MLOps zastosowane do większej jednostki zachowania. Model pozostaje ważny, ale prompty, wyszukane dowody, uprawnienia narzędzi, routing i polityka mogą zmienić wynik bez zmiany wag.

Wersjonuj całą tę jednostkę, ewaluuj ją przed wydaniem, śledź ją z zachowaniem granic prywatności i wycofuj jako jeden system.

Referencje

• MLflow: ewaluacja śladów produkcyjnych — ponowne wykorzystywanie śladów produkcyjnych do ewaluacji i ocenianie informacji z pośrednich etapów śladu.
• MLflow: tracing LLM i agentów — rejestrowanie kroków pośrednich i metadanych śladu na potrzeby dochodzenia.
• Konwencje semantyczne GenAI w OpenTelemetry — aktualnie rozwijane konwencje dotyczące spanów, metryk, zdarzeń i danych specyficznych dla dostawców GenAI.
• NIST AI 600-1: Generative AI Profile — kategorie ryzyka związane z prompt injection, prywatnością, bezpieczeństwem i powiązanymi zagadnieniami generatywnego AI.
• Retrieval-Augmented Generation for Knowledge-Intensive NLP Tasks — oryginalna architektura wyszukiwania, a następnie generowania.
• LoRA: Low-Rank Adaptation of Large Language Models — zamrożone wagi pretrenowanego modelu oraz trenowalne macierze niskiego rzędu na potrzeby adaptacji downstream.