Endpoint dowodzi tylko, że można wywołać model
Endpoint przyjmujący wejście i zwracający predykcję dowodzi jedynie możliwości wywołania modelu. Produkcja zaczyna się, gdy wynik przechodzi przez rzeczywisty proces z określonymi danymi, uprawnieniami, czasem, dowodami, zachowaniem przy awarii i właścicielem. Wejście musi pochodzić z właściwego źródła, być zwalidowane i powiązane z obiektem, a wynik trafić do aplikacji, we właściwym kontekście i z dozwolonym działaniem.
Model może działać dobrze w izolacji, a usługa produkcyjna zawodzić przez nieaktualne dane, zmienione schematy, niedostępne systemy źródłowe, kolejki, błędne mapowanie tożsamości albo użytkowników bez możliwości działania. Gotowość produkcyjną definiuj na granicy procesu: wynik ma być terminowy, autoryzowany, zrozumiały, połączony z dowodem źródłowym i wsparty znaną ścieżką odzyskiwania.
Produkcja zaczyna się w miejscu pozyskania wejścia
Pozyskanie wejścia potrzebuje właściciela i kontraktu: źródła, częstotliwości, identyfikacji obiektu, wymaganych pól lub właściwości obrazu oraz czasu, który opisuje. Zachowuj różnicę między czasem zdarzenia, pozyskania i przetworzenia. Waliduj przed inferencją schemat, typ, zakres, jednostkę, wymiary obrazu, kodowanie, kompletność, aktualność, kolejność, duplikaty i powiązanie z właściwym zasobem lub etapem procesu.
Jakość danych obejmuje także znaczenie operacyjne. Poprawne pole może dotyczyć złej maszyny lub okresu, dokument niewłaściwej wersji, a klatka dotrzeć po rozstrzygnięciu zdarzenia. Rejestruj zmiany źródeł, firmware, szablonów, kompresji i reguł biznesowych, aby wykrywać przesunięcia wejść.
Aplikacja określa, na co model może wpływać
Środowisko uruchomieniowe ładuje model i oblicza wynik. Aplikacja nadaje mu miejsce w procesie: zbiera kontekst, wywołuje usługi, stosuje reguły, prezentuje dowody, prosi o przegląd, zapisuje decyzje i uruchamia zatwierdzone działania. Kontrakty API powinny jasno określać wejścia, wyjścia, błędy, limity czasu, wersjonowanie i ponawianie. Autoryzację sprawdzaj na granicy działania według tożsamości i bieżących uprawnień użytkownika.
Rozróżniaj poradę, szkic treści, proponowane parametry i wykonane działanie. Przegląd człowieka jest potrzebny, gdy konsekwencje, niepewność, polityka lub brak kontekstu wykluczają automatyzację. NIST SSDF i NIST SP 800-218A wspierają traktowanie kodu aplikacji, artefaktów modelu, zależności, danych i kontroli wdrożenia jako jednej odpowiedzialności rozwojowej.
Interfejs językowy potrzebuje ograniczonej władzy
W jednym z przypadków Gaiaa użytkownicy nietechniczni potrzebowali prostszego dostępu do zatwierdzonych funkcji przedsiębiorstwa. Kontrolowana warstwa orkiestracji tłumaczyła intencję na parametry i wybierała tylko zdefiniowane, autoryzowane narzędzia. System walidował odpowiedzi i wyjaśniał zatwierdzone ścieżki odzyskania po błędzie.
Ślad wykonania zachowywał zinterpretowaną intencję, decyzję autoryzacyjną, wejście narzędzia, odpowiedź systemu i decyzję o odzyskaniu. Ograniczone narzędzia ułatwiają testowanie, ponieważ każde ma znane parametry, reguły uprawnień, odpowiedzi i błędy, a deterministyczne kontrole rozstrzygają, czy działanie może zostać wykonane.
Monitoruj usługę, wejścia i wynik procesu
Monitoruj nie tylko czas modelu, lecz także dostępność usług, kolejki, błędy integracji, jakość oraz aktualność wejść, wykorzystanie zasobów, wynik procesu i pracę przeglądową. Sygnały operacyjne powinny wskazywać właścicielowi, co wymaga reakcji. Zachowuj wersje modelu, konfiguracji, źródeł i kontraktów, aby zmiany jakości były możliwe do wyjaśnienia.
Miary jakości muszą odpowiadać rzeczywistemu zastosowaniu. Zbieraj informacje zwrotne z procesu, rozróżniaj brak odpowiedzi, odpowiedź niepewną i błąd oraz sprawdzaj, czy użytkownicy mogą skutecznie użyć wyniku. Obserwowalność ma wspierać naprawę, a nie tworzyć kolejne niewyjaśnione wykresy.
Projektuj odzyskiwanie dla awarii, których się spodziewasz
Zdefiniuj zachowanie przy nieaktualnym lub niepoprawnym wejściu, przepełnionej kolejce, niedostępnym modelu, limicie usługi, błędzie zależności, utracie uprawnień, częściowej odpowiedzi i zmianie kontraktu. Użytkownik lub system zależny musi zobaczyć stan, bezpieczne następne działanie i konsekwencje dla danych. Nie ukrywaj błędu za pewnym komunikatem.
Testuj odłączenie źródła, restart komponentu, opóźnienie zależności, błędne poświadczenia, wyczerpanie zasobów i wycofanie wersji. Zapisuj strategię ponawiania, idempotencję, limity czasu, kolejki błędów, odtwarzanie i komunikację. Przewidywalna degradacja jest bezpieczniejsza niż ciche gubienie pracy.
Usługa produkcyjna potrzebuje nazwanych właścicieli i rutyn wsparcia
Nazwij właścicieli danych, modelu, aplikacji, infrastruktury, integracji, bezpieczeństwa i procesu biznesowego. Ustal, kto odbiera alerty, zatwierdza zmiany, przegląda jakość, odnawia poświadczenia, utrzymuje zależności i prowadzi odzyskiwanie. Współdzielona odpowiedzialność bez jawnych granic tworzy luki.
Rytm wsparcia powinien obejmować przegląd zdrowia, kosztów i jakości, aktualizacje, kopie, ćwiczenia odtwarzania, zarządzanie incydentami oraz dokumentowanie zmian. Usługa nie jest gotowa, jeśli działa tylko wtedy, gdy autorzy projektu pozostają stale dostępni.
Niech pilotaż odpowie na pytania produkcyjne
Pilotaż powinien sprawdzać rzeczywistą ścieżkę danych, integracje, uprawnienia, warunki obciążenia, pracę użytkownika, jakość i awarie, a nie tylko pokaz modelu. Ustal przed nim kryteria akceptacji, reprezentatywny zakres, właściciela decyzji i granice, których nie przekracza.
Na końcu zdecyduj na podstawie dowodów: rozszerzyć, zmienić zakres, poprawić konkretną warstwę albo zatrzymać wdrożenie. GAIAA może przeprowadzić pilotaż od granicy procesu po utrzymywaną usługę, tak aby wynik odpowiadał na pytanie o gotowość produkcyjną.