Nikunj Bajaj, współzałożyciel i CEO TrueFoundry – seria wywiadów

Pracowałeś w obszarze badań nad uczeniem maszynowym, produkcją AI w Facebooku i dużych systemach rekomendacji przed założeniem TrueFoundry — jakie doświadczenia najbardziej bezpośrednio skierowały Cię ku budowie przedsiębiorczej infrastruktury AI, i jaki ból nie był rozwiązany w tym czasie?

W Meta uważaliśmy uczenie maszynowe za specjalny przypadek oprogramowania, a GenAI za specjalny przypadek uczenia maszynowego, co skutkowało pionową strukturą ze oprogramowaniem u podstawy, uczeniem maszynowym w środku, a GenAI na górze. W tym układzie, jeśli jestem deweloperem uczenia maszynowego, modele, które buduję, podążają tym samym wzorcem wdrożenia, co reszta oprogramowania, co sprawia, że skalowanie systemów staje się bardzo proste.

Większość przedsiębiorstw jednak wdrożyla równoległe struktury, co oznaczało, że miały oddzielne struktury dla oprogramowania, uczenia maszynowego i GenAI. W momencie, gdy masz te równoległe struktury, skalowanie staje się bardziej złożone ze względu na wymagane przekazania między światem uczenia maszynowego a oprogramowaniem.

Nasz zespół zawsze pracował na styku budowy modeli uczenia maszynowego i infrastruktury uczenia maszynowego, więc mieliśmy unikalną perspektywę, którą mogliśmy przynieść podobne pionowe struktury do przedsiębiorstw i dostosować je do ich konkretnych wymagań. Mieliśmy również hipotezę pod koniec 2021 roku, że uczenie maszynowe zbliżało się do punktu zwrotnego, i kiedy to nastąpi, więcej firm będzie potrzebować pionowo zintegrowanej struktury, aby wdrożyć i skalować te systemy skutecznie. To ostatecznie doprowadziło nas do założenia TrueFoundry, a nasza hipoteza okazała się słuszna. Wdrożenie AI przyspieszyło po uruchomieniu ChatGPT pod koniec 2022 roku.

Jak systemy AI przechodzą z eksperymentów do codziennych operacji, co się zmieniło w sposobie, w jaki organizacje powinny myśleć o niezawodności i awariach?

Stawki związane z Gen AI są znacznie wyższe w porównaniu z tradycyjnymi systemami uczenia maszynowego. Gdy te systemy przechodzą do produkcji, organizacje mają do czynienia z znacznie wyższym poziomem niepewności i nieokreśloności, ponieważ LLM są losowe z natury. Systemy agentyckie zbudowane na ich podstawie dodają kolejną niepewność.

Ponadto awarie nie są już binarne. Zamiast systemów, które po prostu zawodzą lub nie zawodzą, wiele problemów pojawia się jako częściowe awarie lub ciche degradacje. Systemy mogą odpowiadać z wyższą latencją, pogorszoną jakością lub niewłaściwym zachowaniem w czasie. W wielu przypadkach te degradacje mogą być trudniejsze do wykrycia i czasem nawet bardziej szkodliwe niż twardy przestój.

Organizacje muszą myśleć o niezawodności nie tylko w kategoriach czasu bezawaryjnej pracy, ale także degradacji wydajności w czasie.

TrueFailover został uruchomiony wśród fali wysokoprofilowych awarii usług chmurowych i AI. Jakie ostatnie wydarzenia sprawiły, że stało się jasne, iż niezawodność AI przeszła z „miłego do posiadania” do podstawowego wymogu architektonicznego?

Jeden z naszych klientów z sektora opieki zdrowotnej, który przetwarzał czasowe, wrażliwe na czas wnioski pacjentów związane z receptami, został dotknięty awarią spowodowaną awarią modelu. Ich przepływy pracy generowały tysiące dolarów przychodu na sekundę, a awaria zakłóciła niektóre z tych krytycznych przepływów pracy. Jako wczesny klient TrueFailover, byliśmy w stanie pomóc w szybkim odzyskaniu, a wpływ został ograniczony.

Zdarzenia takie podnoszą ważne pytanie. Gdy stawki systemów Gen AI nadal rosną, dlaczego procesy odzyskiwania są nadal w dużej mierze ręczne? Potwierdziło to pomysł, że systemy powinny być budowane z założeniem, że awarie będą występować, i powinny być zaprojektowane tak, aby automatycznie naprawiać się same. Niezawodność musi być również wbudowana w samą strukturę AI za pomocą bram AI, które mogą zapewnić scentralizowane routowanie, obserwowalność, barierki i inteligentną zmianę modeli między dostawcami.

Wiele awarii AI jest nadal przedstawianych jako techniczne potknięcia. Gdzie widzisz prawdziwe koszty ekonomiczne i ludzkie zaczynające pojawiać się, gdy systemy AI ulegają awariom?

Przedsiębiorczy AI rozwinął się do punktu, w którym te potknięcia nie wpływają już tylko na wewnętrzne przepływy pracy. Dziś awarie i degradacje wpływają bezpośrednio na publiczne postrzeganie i zyski, ponieważ przypadki użycia w produkcji są teraz zorientowane na klienta. To przesunięcie z testowania wewnętrznego do aplikacji o wysokich stawkach, zorientowanych na klienta, jest powodem, dla którego widzimy wzrost zapotrzebowania na uwagę i nadzór wyższego szczebla.

Gdy systemy AI stają się coraz bardziej wbudowane w operacyjne przepływy pracy, awarie nie są już tylko problemami technicznymi. Coraz częściej mają bezpośrednie konsekwencje biznesowe, klientowskie i reputacyjne.

W środowiskach o wysokiej krityczności, takich jak apteki, operacje zdrowotne lub obsługa klienta, jak szybko może awaria AI eskalować w ryzyko operacyjne lub reputacyjne?

W środowiskach o wysokiej krityczności eskalacja następuje niemal natychmiast, ponieważ te systemy wspierają czasowe, wrażliwe na czas przepływy pracy. Nawet krótkie zakłócenie może zahamować krytyczne procesy, opóźnić dostawę usług lub przerwać systemy zależne od tych danych wyjściowych, tworząc efekt kaskady w organizacji.

W sektorach takich jak opieka zdrowotna wpływ wykracza poza zakłócenie operacyjne do doświadczenia klienta i wyników usług. Jeśli pacjent nie może uzyskać recepty na czas, mogą wystąpić prawdziwe konsekwencje. Nie tylko jest to problemem dla pacjenta, ale może również uszkodzić reputację apteki lub dostawcy usług zdrowotnych. W środowiskach o wysokiej krityczności, gdzie zaufanie jest czynnikiem, jest niezwykle ważne, aby systemy pozostawały w trybie online. Dlatego organizacje coraz częściej uznają, że systemy AI muszą być zaprojektowane z założeniem, że awarie będą występować, i mechanizmy odzyskiwania muszą aktywować się automatycznie, aby zminimalizować ryzyko.

Powiedziałeś, że wiele zespołów architektury jest projektowanych raczej pod kątem zdolności niż ciągłości. Dlaczego uważasz, że odporność była historycznie pomijana w projekcie systemów AI?

To w dużej mierze wynika z zachęt wewnątrz organizacji. Nowe zdolności są widoczne i ekscytujące. Odblokowują demonstracje, funkcje i możliwości produktowe, które kierownictwo może natychmiast zobaczyć.

Ciągłość, przez definicję, jest niewidoczna, gdy wszystko działa dobrze. Ze względu na to systemy nagradzające są zniekształcone w kierunku dostarczania nowych funkcji, a nie zapewniania, że nic nie ulegnie awarii. W rezultacie organizacje inwestują niewspółmiernie w rozwój zdolności, a nie w inżynierię odporności.

Gdy przedsiębiorstwa coraz częściej polegają na zewnętrznych modelach i API, jakie nowe słabości są wprowadzane do stosu AI, których liderzy mogą jeszcze nie w pełni doceniać?

LLM są fundamentalnie współdzielonymi zasobami, a przedsiębiorstwa nie posiadają ich, tak jak tradycyjną infrastrukturę. Ponadto ważne, krytyczne systemy biznesowe w przedsiębiorstwach są uruchamiane na zewnętrznych systemach, które nie są w pełni przetestowane w czasie. LLM same ewoluują bardzo szybko, co oznacza, że dostawca modelu nie może być odpowiedzialny za takie rzeczy, jak opóźnienia lub niewielkie spadki jakości modelu, ponieważ szybko iterują swoje badania.

Ponieważ LLM są zasobami współdzielonymi, opóźnienia mogą wystąpić, ponieważ inny konsument tych LLM podejmuje określone działanie. Istnieje wiele takich punktów awaryjnych, które są wprowadzane ze względu na fundamentalną naturę LLM, a przedsiębiorstwa w tym nowym świecie po prostu nie mają pełnej kontroli. Bez pełnej kontroli najlepszą rzeczą, jaką może zrobić przedsiębiorstwo, jest stworzenie wystarczających redundancji systemu, aby zaprojektować odporny system.

Bez koncentrowania się na konkretnych produktach, jak organizacje powinny przemyśleć architekturę AI, aby założyć awarię, a nie traktować przestojów jako rzadkie przypadki brzegowe?

Organizacje powinny powrócić do podstawowych zasad projektowania systemów rozproszonych. Systemy oprogramowania były budowane z założeniem, że komponenty sieciowe i maszyny ulegną awarii, i że cały region może ulec awarii.

Systemy AI nie powinny być inne. Powinniśmy założyć, że dostawcy modeli będą doświadczać problemów z opóźnieniami, degradacjami lub awariami, i uwzględnić redundancję, aby aplikacje pozostały odporne na różne scenariusze awaryjne.

Czy oczekujesz, że odporność AI stanie się decydującym czynnikiem w wyborze platformy i dostawcy, podobnie jak w jaki sposób czas bezawaryjnej pracy i redundancja kształtowały decyzje o infrastrukturze chmurowej?

Gdy więcej systemów AI przechodzi do produkcji, odporność stanie się podstawowym wymogiem. Jeśli dostawca nie może przedstawić swoich wykresów i metryk dotyczących czasu bezawaryjnej pracy i ogólnej odporności, nie zostanie nawet rozważony. Gdy odporność stanie się podstawowym oczekiwaniem wśród dostawców, decydujące czynniki przesuną się w kierunku doświadczenia użytkownika, optymalizacji wydajności, obserwowalności i wyższych funkcjonalności produktu. Z czasem składniki takie jak brama AI i automatyczne funkcje failover staną się podstawowymi elementami infrastruktury AI przedsiębiorstw.

Spójrzając w przyszłość, co oznacza „gotowość do produkcji” w świecie, w którym AI ma być ciągle dostępna, a nie tylko okazjonalnie przydatna?

Systemy AI gotowe do produkcji powinny być obserwowalne, kontrolowane i odzyskiwalne. Wszystkie trzy te punkty muszą być spełnione.

Aby AI w produkcji była obserwowalna, zespoły potrzebują głębokiej widoczności w zachowaniu modelu, opóźnień, wskaźników błędów, użycia tokenów, dryfu i wzorców awarii. Bez silnej obserwowalności staje się bardzo trudno wykryć degradacje, zanim użytkownicy zaczną je zauważać.

Aby systemy były kontrolowane, obejmuje to kształtowanie ruchu, ograniczanie stawek, egzekwowanie polityk i inteligentne routowanie między modelami i dostawcami. To jest miejsce, w którym brama AI staje się podstawowa, działając jako scentralizowana płaszczyzna kontroli, która egzekwuje barierki, zapewnia spójne zarządzanie i umożliwia dynamiczną zmianę modelu, gdy wydajność lub niezawodność spadają.

I wreszcie, jeśli chodzi o odzyskiwanie, systemy powinny być budowane z założeniem, że komponenty mogą być częściowo lub całkowicie uszkodzone, niezależnie od tego, czy jest to awaria dostawcy, pogorszenie jakości modelu, limity stawek czy nieoczekiwane dane wejściowe od złych aktorów. Automatyczne failover i mechanizmy samonaprawy powinny być rodzime dla architektury, a nie ręczne podręczniki wyzwane po wystąpieniu problemu.

To jest kierunek, w którym pracujemy w TrueFoundry. Dostawcy, którzy definiują gotowość do produkcji w ten sposób, łącząc obserwowalność, scentralizowaną kontrolę i automatyczne odzyskiwanie, zdobędą długoterminowe zaufanie klientów i będą mogli nadal rozwiązywać nowe problemy, gdy się pojawiają.

Dziękuję za wspaniały wywiad, czytelnicy, którzy chcą dowiedzieć się więcej, powinni odwiedzić TrueFoundry.