Zbuduj kompleksowy potok MLOps do wizualnej kontroli jakości na krawędzi — część 1 | Usługi internetowe Amazona

Pomyślne wdrożenie modelu uczenia maszynowego (ML) w środowisku produkcyjnym w dużym stopniu zależy od kompleksowego potoku ML. Chociaż opracowanie takiego potoku może być wyzwaniem, staje się ono jeszcze bardziej złożone w przypadku przypadek użycia Edge ML. Uczenie maszynowe na krawędzi to koncepcja, która zapewnia możliwość lokalnego uruchamiania modeli uczenia maszynowego na urządzeniach brzegowych. Aby wdrażać, monitorować i utrzymywać te modele na brzegu, wymagany jest solidny potok MLOps. Potok MLOps umożliwia automatyzację pełnego cyklu życia uczenia maszynowego, od etykietowania danych po szkolenie modeli i wdrażanie.

Wdrożenie potoku MLOps na brzegu sieci wprowadza dodatkowe złożoności, które sprawiają, że procesy automatyzacji, integracji i konserwacji stają się większym wyzwaniem ze względu na zwiększone koszty operacyjne. Jednak korzystanie ze specjalnie zaprojektowanych usług, takich jak Amazon Sage Maker i Zielona trawa AWS IoT pozwala znacząco ograniczyć ten wysiłek. W tej serii przeprowadzimy Cię przez proces projektowania i budowania zintegrowanego, kompleksowego potoku MLOps dla przypadku użycia widzenia komputerowego na brzegu przy użyciu SageMaker, AWS IoT Greengrass i Zestaw programistyczny AWS Cloud (CDK AWS).

Ten post skupia się na projektowaniu ogólnej architektury potoku MLOps; Część 2 i Część 3 z tej serii skupiają się na wykonaniu poszczególnych komponentów. W załączeniu zamieściliśmy przykładową realizację Repozytorium GitHub abyś mógł spróbować. Jeśli dopiero zaczynasz korzystać z MLOps na krawędzi w AWS, zapoznaj się z MLOps na krawędzi dzięki Amazon SageMaker Edge Manager i AWS IoT Greengrass dla przeglądu i architektury referencyjnej.

Przypadek użycia: Sprawdzanie jakości metalowych przywieszek

Jako inżynier ML ważne jest, aby zrozumieć uzasadnienie biznesowe, nad którym pracujesz. Zanim więc zagłębimy się w architekturę potoku MLOps, spójrzmy na przykładowy przypadek użycia w tym poście. Wyobraź sobie linię produkcyjną producenta, który graweruje metalowe przywieszki w celu stworzenia spersonalizowanych przywieszek bagażowych. Proces zapewniania jakości jest kosztowny, ponieważ przywieszki z surowego metalu muszą być sprawdzane ręcznie pod kątem wad, takich jak zadrapania. Aby usprawnić ten proces, używamy ML do wykrywania wadliwych tagów na wczesnym etapie procesu. Pomaga to uniknąć kosztownych usterek na późniejszych etapach procesu produkcyjnego. Model powinien identyfikować możliwe defekty, takie jak zadrapania, w czasie zbliżonym do rzeczywistego i je oznaczać. W środowiskach produkcyjnych często trzeba radzić sobie z brakiem łączności lub ograniczoną przepustowością i zwiększonymi opóźnieniami. Dlatego chcemy wdrożyć nowatorskie rozwiązanie ML do wizualnej kontroli jakości, które będzie w stanie wyciągać wnioski lokalnie w hali produkcyjnej i zmniejszać wymagania dotyczące łączności. Aby nasz przykład był prosty, szkolimy model, który zaznacza wykryte zadrapania ramkami ograniczającymi. Poniższy obraz jest przykładem znacznika z naszego zbioru danych z zaznaczonymi trzema zadrapaniami.

Definiowanie architektury rurociągu

Uzyskaliśmy teraz jasność co do naszego przypadku użycia i konkretnego problemu ML, którym chcemy się zająć, a który dotyczy wykrywania obiektów na krawędzi. Nadszedł czas na zaprojektowanie architektury naszego potoku MLOps. Na tym etapie nie przyglądamy się jeszcze technologiom ani konkretnym usługom, ale raczej zaawansowanym komponentom naszego rurociągu. Aby szybko przeszkolić i wdrożyć, musimy zautomatyzować cały kompleksowy proces: od etykietowania danych, przez szkolenie, aż po wnioskowanie. Istnieje jednak kilka wyzwań, które sprawiają, że skonfigurowanie potoku dla przypadku brzegowego jest szczególnie trudne:

• Budowanie różnych części tego procesu wymaga różnych zestawów umiejętności. Na przykład etykietowanie i szkolenie danych skupia się głównie na nauce danych, wdrażanie brzegowe wymaga specjalisty ds. Internetu rzeczy (IoT), a automatyzacją całego procesu zajmuje się zwykle osoba posiadająca umiejętności DevOps.
• W zależności od organizacji cały ten proces może być realizowany nawet przez wiele zespołów. W naszym przypadku użycia pracujemy przy założeniu, że za etykietowanie, szkolenie i wdrażanie odpowiadają osobne zespoły.
• Więcej ról i zestawów umiejętności oznacza różne wymagania dotyczące narzędzi i procesów. Na przykład badacze danych mogą chcieć monitorować i pracować w znanym środowisku notebooków. Inżynierowie MLOps chcą pracować przy użyciu infrastruktury jako narzędzi kodu (IaC) i mogą być bardziej zaznajomieni z Konsola zarządzania AWS.

Co to oznacza dla naszej architektury rurociągów?

Po pierwsze, ważne jest jasne zdefiniowanie głównych elementów kompleksowego systemu, który pozwala różnym zespołom na niezależną pracę. Po drugie, aby zwiększyć efektywność współpracy, należy zdefiniować dobrze zdefiniowane interfejsy między zespołami. Interfejsy te pomagają minimalizować zakłócenia pomiędzy zespołami, umożliwiając im modyfikowanie procesów wewnętrznych w miarę potrzeb, o ile są one zgodne ze zdefiniowanymi interfejsami. Poniższy diagram ilustruje, jak mogłoby to wyglądać w przypadku naszego potoku widzenia komputerowego.

Przyjrzyjmy się szczegółowo ogólnej architekturze potoku MLOps:

1. Proces rozpoczyna się od zebrania surowych obrazów metalowych znaczników, które są rejestrowane za pomocą kamery krawędziowej w środowisku produkcyjnym w celu utworzenia wstępnego zbioru danych szkoleniowych.
2. Następny krok polega na etykietowaniu tych obrazów i zaznaczaniu defektów za pomocą obwiedni. Niezbędne jest wersjonowanie oznaczonego zbioru danych, co zapewnia identyfikowalność i odpowiedzialność za wykorzystane dane szkoleniowe.
3. Po utworzeniu oznaczonego zestawu danych możemy przystąpić do uczenia, dostrajania, oceniania i wersjonowania naszego modelu.
4. Kiedy jesteśmy zadowoleni z wydajności naszego modelu, możemy wdrożyć model na urządzeniu brzegowym i uruchamiać wnioski na żywo na brzegu.
5. Podczas gdy model pracuje w fazie produkcyjnej, urządzenie z kamerą krawędziową generuje cenne dane obrazu zawierające wcześniej niewidziane defekty i przypadki Edge. Możemy wykorzystać te dane, aby jeszcze bardziej poprawić wydajność naszego modelu. Aby to osiągnąć, zapisujemy obrazy, dla których model przewiduje z niską pewnością lub dokonuje błędnych przewidywań. Obrazy te są następnie dodawane z powrotem do naszego surowego zbioru danych, rozpoczynając cały proces od nowa.

Należy zauważyć, że surowe dane obrazu, oznaczony zestaw danych i przeszkolony model służą jako dobrze zdefiniowane interfejsy między różnymi potokami. Inżynierowie i analitycy danych MLOps mają swobodę wyboru technologii w swoich potokach, pod warunkiem, że konsekwentnie generują te artefakty. Co najważniejsze, stworzyliśmy zamkniętą pętlę informacji zwrotnej. Błędne lub mało pewne przewidywania wykonane w środowisku produkcyjnym można wykorzystać do regularnego powiększania naszego zbioru danych oraz automatycznego ponownego uczenia i ulepszania modelu.

Docelowa architektura

Teraz, gdy architektura wysokiego poziomu jest już ustalona, ​​czas wejść o jeden poziom głębiej i przyjrzeć się, jak moglibyśmy ją zbudować za pomocą usług AWS. Pamiętaj, że architektura pokazana w tym poście zakłada, że ​​chcesz przejąć pełną kontrolę nad całym procesem analizy danych. Jeśli jednak dopiero zaczynasz od kontroli jakości na krawędzi, zalecamy Amazon Lookout dla wizji. Zapewnia sposób uczenia własnego modelu kontroli jakości bez konieczności tworzenia, utrzymywania lub rozumienia kodu ML. Aby uzyskać więcej informacji, zobacz Amazon Lookout for Vision obsługuje teraz wizualną kontrolę wad produktu na krawędzi.

Jeśli jednak chcesz przejąć pełną kontrolę, poniższy diagram pokazuje, jak może wyglądać architektura.

Podobnie jak poprzednio, przeanalizujmy krok po kroku przepływ pracy i określmy, które usługi AWS odpowiadają naszym wymaganiom:

1. Usługa Amazon Simple Storage (Amazon S3) służy do przechowywania nieprzetworzonych danych obrazu, ponieważ zapewnia nam niedrogie rozwiązanie do przechowywania.
2. Przepływ pracy związany z etykietowaniem jest zorganizowany przy użyciu Funkcje kroków AWS, bezserwerowy silnik przepływu pracy, który ułatwia koordynację etapów przepływu pracy związanych z etykietowaniem. W ramach tego przepływu pracy używamy Amazon SageMaker Ground Prawda w pełni zautomatyzować etykietowanie za pomocą zadań etykietowania i zarządzanej siły roboczej. AWS Lambda służy do przygotowania danych, rozpoczęcia zadań etykietowania i przechowywania etykiet Sklep funkcji Amazon SageMaker.
3. Sklep z funkcjami SageMaker przechowuje etykiety. Pozwala nam centralnie zarządzać naszymi funkcjami i udostępniać je, a także zapewnia wbudowane możliwości wersjonowania danych, co czyni nasz potok bardziej niezawodnym.
4. Organizujemy proces budowania modeli i szkoleń przy użyciu Rurociągi Amazon SageMaker. Integruje się z innymi wymaganymi funkcjami SageMaker poprzez wbudowane kroki. Oferty pracy szkoleniowej SageMaker służą do automatyzacji uczenia modelu, oraz Praca w SageMaker Przetwarzanie służą do przygotowania danych i oceny wydajności modelu. W tym przykładzie używamy Ultralityka YOLOv8 Architektura pakietu i modelu języka Python do uczenia i eksportowania modelu wykrywania obiektów do platformy ONNX Format modelu ML zapewniający przenośność.
5. Jeśli wydajność jest akceptowalna, wytrenowany model jest rejestrowany w Rejestr modelu Amazon SageMaker z dołączonym rosnącym numerem wersji. Działa jako nasz interfejs między etapami szkolenia modelu a wdrażaniem brzegowym. Tutaj zarządzamy również stanem zatwierdzenia modeli. Podobnie jak pozostałe usługi, z których korzystamy, jest w pełni zarządzany, dzięki czemu nie musimy zajmować się prowadzeniem własnej infrastruktury.
6. Przepływ pracy w zakresie wdrażania brzegowego jest zautomatyzowany przy użyciu funkcji krokowych, podobnie jak w przypadku przepływu pracy związanego z etykietowaniem. Możemy wykorzystać integrację API funkcji Step, aby łatwo wywoływać różne wymagane interfejsy API usług AWS, takie jak AWS IoT Greengrass, w celu tworzenia nowych komponentów modelu, a następnie wdrażania komponentów na urządzeniu brzegowym.
7. AWS IoT Greengrass służy jako środowisko wykonawcze urządzeń brzegowych. Zarządza cyklem życia naszego modelu i komponentów wnioskowania na brzegu. Pozwala nam łatwo wdrażać nowe wersje naszego modelu i komponentów wnioskowania za pomocą prostych wywołań API. Ponadto modele ML na brzegu zwykle nie działają w izolacji; możemy korzystać z różnych AWS i społeczność dostarczył komponenty AWS IoT Greengrass do łączenia się z innymi usługami.

Zarysowana architektura przypomina pokazaną wcześniej architekturę wysokiego poziomu. Amazon S3, SageMaker Feature Store i SageMaker Model Registry działają jako interfejsy pomiędzy różnymi potokami. Aby zminimalizować wysiłek związany z uruchomieniem i obsługą rozwiązania, tam, gdzie to możliwe, korzystamy z usług zarządzanych i bezserwerowych.

Połączenie w solidny system CI/CD

Etykietowanie danych, szkolenie modeli i etapy wdrażania brzegowego stanowią podstawę naszego rozwiązania. W związku z tym każda zmiana związana z kodem źródłowym lub danymi w którejkolwiek z tych części powinna spowodować ponowne uruchomienie całego procesu orkiestracji. Aby to osiągnąć, musimy zintegrować ten potok z systemem CI/CD, który umożliwi nam automatyczne wdrażanie zmian w kodzie i infrastrukturze z wersjonowanego repozytorium kodu do środowiska produkcyjnego. Podobnie jak w poprzedniej architekturze, ważnym aspektem jest tutaj autonomia zespołu. Poniższy diagram pokazuje, jak mogłoby to wyglądać przy użyciu usług AWS.

Przyjrzyjmy się architekturze CI/CD:

1. Zatwierdzenie kodu AWS działa jako nasze repozytorium Git. Dla uproszczenia w dostarczonym przykładzie rozdzieliliśmy odrębne części (etykietowanie, szkolenie modeli, wdrażanie brzegowe) za pomocą podfolderów w jednym repozytorium Git. W rzeczywistym świecie każdy zespół może używać różnych repozytoriów dla każdej części.
2. Wdrażanie infrastruktury jest zautomatyzowane przy użyciu AWS CDK, a każda część (etykietowanie, szkolenie i brzeg) otrzymuje własną aplikację AWS CDK, aby umożliwić niezależne wdrożenia.
3. Wykorzystuje funkcję potoku AWS CDK AWS Code Pipeline w celu automatyzacji wdrażania infrastruktury i kodu.
4. AWS CDK wdraża dwa potoki kodu na każdym etapie: potok zasobów i potok przepływu pracy. Oddzieliliśmy przepływ pracy od wdrażania zasobów, aby umożliwić oddzielne rozpoczęcie przepływów pracy w przypadku braku zmian w zasobach (na przykład, gdy dostępne są nowe obrazy do szkolenia).
   • Potok kodu zasobu wdraża całą infrastrukturę wymaganą do pomyślnego działania przepływu pracy, np AWS Zarządzanie tożsamością i dostępem (IAM), funkcje Lambda i obrazy kontenerów używane podczas szkolenia.
   • Potok kodu przepływu pracy uruchamia rzeczywisty przepływ pracy związany z etykietowaniem, szkoleniem lub wdrażaniem brzegowym.
5. Potoki zasobów są automatycznie wyzwalane w momencie zatwierdzenia, a także po zakończeniu poprzedniego potoku przepływu pracy.
6. Cały proces jest uruchamiany zgodnie z harmonogramem za pomocą pliku Most zdarzeń Amazona zasada regularnego przekwalifikowania się.

Dzięki integracji CI/CD cały kompleksowy łańcuch jest teraz w pełni zautomatyzowany. Potok jest uruchamiany za każdym razem, gdy zmienia się kod w naszym repozytorium git, a także zgodnie z harmonogramem uwzględniającym zmiany danych.

Patrzeć w przyszłość

Opisana architektura rozwiązania reprezentuje podstawowe komponenty umożliwiające zbudowanie kompleksowego potoku MLOps na brzegu. Jednakże, w zależności od Twoich wymagań, możesz pomyśleć o dodaniu dodatkowej funkcjonalności. Oto kilka przykładów:

Wnioski

W tym poście opisaliśmy naszą architekturę budowania kompleksowego potoku MLOps do wizualnej kontroli jakości na brzegu sieci przy użyciu usług AWS. Architektura ta usprawnia cały proces, obejmujący etykietowanie danych, opracowywanie modelu i wdrażanie brzegowe, umożliwiając nam szybkie i niezawodne szkolenie i wdrażanie nowych wersji modelu. Dzięki bezserwerowym i zarządzanym usługom możemy skupić się na dostarczaniu wartości biznesowej, a nie na zarządzaniu infrastrukturą.

In Część 2 w tej serii zagłębimy się o jeden poziom głębiej i przyjrzymy się implementacji tej architektury bardziej szczegółowo, w szczególności etykietowaniu i budowaniu modeli. Jeśli chcesz od razu przejść do kodu, możesz zapoznać się z załączonym kodem GitHub repo.

---

O autorach

Michael Roth jest starszym architektem rozwiązań w AWS i wspiera klientów produkcyjnych w Niemczech w rozwiązywaniu ich wyzwań biznesowych za pomocą technologii AWS. Oprócz pracy i rodziny interesuje się samochodami sportowymi i pije włoską kawę.

Jörga Wöhrle jest architektem rozwiązań w AWS i współpracuje z klientami produkcyjnymi w Niemczech. Z pasją do automatyzacji Joerg pracował jako programista, inżynier DevOps i inżynier ds. niezawodności witryny w swoim życiu przed AWS. Poza chmurą jest ambitnym biegaczem i lubi miło spędzać czas z rodziną. Jeśli więc masz wyzwanie DevOps lub chcesz pobiegać: daj mu znać.

Johannesa Langera jest starszym architektem rozwiązań w AWS i współpracuje z klientami korporacyjnymi w Niemczech. Johannes pasjonuje się wykorzystaniem uczenia maszynowego do rozwiązywania rzeczywistych problemów biznesowych. W życiu osobistym Johannes lubi pracować nad projektami remontowymi i spędzać czas na świeżym powietrzu z rodziną.

• Dystrybucja treści i PR oparta na SEO. Uzyskaj wzmocnienie już dziś.
• PlatoData.Network Pionowe generatywne AI. Wzmocnij się. Dostęp tutaj.
• PlatoAiStream. Inteligencja Web3. Wiedza wzmocniona. Dostęp tutaj.
• PlatonESG. Węgiel Czysta technologia, Energia, Środowisko, Słoneczny, Gospodarowanie odpadami. Dostęp tutaj.
• Platon Zdrowie. Inteligencja w zakresie biotechnologii i badań klinicznych. Dostęp tutaj.
• Źródło: https://aws.amazon.com/blogs/machine-learning/build-an-end-to-end-mlops-pipeline-for-visual-quality-inspection-at-the-edge-part-1/