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

Pracowałeś w badaniach nad machine learning, produkcją AI w Facebooku i dużymi systemami 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ł w tym czasie rozwiązany?

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

Większość przedsiębiorstw jednak wdrożyła równoległe struktury, co oznacza, że miały oddzielne struktury dla oprogramowania, machine learning 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 machine learning a światem oprogramowania.

Nasz zespół zawsze pracował na przecięciu budowy modeli machine learning i infrastruktury machine learning, więc mieliśmy unikalny punkt widzenia, który mogliśmy wprowadzić podobne pionowe struktury do przedsiębiorstw i dostosować je do ich konkretnych wymagań. Mieliśmy również hipotezę pod koniec 2021 roku, że machine learning zbliżał 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 była słuszna. Wdrożenie AI przyspieszyło po uruchomieniu ChatGPT pod koniec 2022 roku.

Gdy 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 machine learning. Gdy te systemy przechodzą do produkcji, organizacje mają do czynienia z znacznie wyższym poziomem niepewności i nieoznaczoności, ponieważ LLM są stochasticzne z natury. Systemy agenty zbudowane na ich podstawie dodają dalszą niepewność.

Ponadto awarie nie są już binarne. Zamiast systemy 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 pracy, ale także degradacji wydajności w czasie.

TrueFailover został uruchomiony wśród fali wysokoprofilowych zakłóceń usług chmury i AI. Jakie niedawne wydarzenia ujawniły, że niezawodność AI przeszła od „miłego do posiadania” do podstawowego wymogu architektonicznego?

Jeden z naszych klientów z sektora opieki zdrowotnej, który przetwarza bieżące, wrażliwe na czas żądania pacjentów związanych z receptami, został dotknięty awarią spowodowaną awarią modelu. Ich przepływy generują tysiące dolarów dochodu na sekundę, a awaria zakłóciła niektóre z tych krytycznych przepływów. 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? To potwierdziło ideę, ż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ę modelu między dostawcami.

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

Przedsiębiorczy AI ewoluował 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 postrzeganie publiczne i zyski, ponieważ przypadki użycia w produkcji są teraz zorientowane na klienta. To przesunięcie z wewnętrznego testowania do aplikacji o wysokim ryzyku, zorientowanych na publiczność, jest powodem, dla którego widzimy zwiększony popyt na uwagę i nadzór wyższego szczebla.

Gdy systemy AI stają się głębiej osadzone w operacyjnych przepływach pracy, awarie nie są już tylko technicznymi problemami. Coraz częściej mają bezpośrednie konsekwencje biznesowe, klienta i reputacyjne.

W misyjnych środowiskach, takich jak apteki, operacje opieki zdrowotnej lub wsparcie klienta, jak szybko może awaria AI eskalować w kierunku operacyjnego lub reputacyjnego ryzyka?

W misyjnych środowiskach eskalacja następuje prawie natychmiast, ponieważ te systemy wspierają bieżące, wrażliwe na czas przepływy pracy. Nawet krótkie zakłócenie może zatrzymać krytyczne procesy, opóźnić dostawę usług lub przerwać poniższe systemy, które zależą od tych danych wyjściowych, tworząc lawinowe skutki operacyjne w całej 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 wypełnić recepty na czas, mogą wystąpić prawdziwe konsekwencje. Nie tylko jest to problemem dla pacjenta, ale także może uszkodzić reputację apteki lub dostawcy opieki zdrowotnej. W misyjnych środowiskach, w których zaufanie jest czynnikiem, jest niezwykle ważne, aby systemy pozostawały online. Dlatego organizacje coraz częściej uznają, że systemy AI muszą być zaprojektowane z założeniem, że awarie będą występować, i że mechanizmy odzyskiwania muszą aktywować się automatycznie, aby zminimalizować ryzyko.

Powiedziałeś, że wiele zespołów architektury dla zdolności, a nie ciągłości. Dlaczego uważasz, że wytrzymałość była historycznie zaniżona w projekcie systemu 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ą skierowane ku wysyłaniu nowych funkcji, a nie zapewnieniu, że nic nie ulegnie awarii. W rezultacie organizacje często inwestują niewspółmiernie w rozwój zdolności, a nie w inżynierię wytrzymałości.

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

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

Ponieważ LLM są współdzielonymi zasobami, 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ącej redundancji systemu, aby zaprojektować wytrzymały system.

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

Organizacje powinny powrócić do pierwszych zasad projektowania systemów rozproszonych. Systemy oprogramowania były budowane z założeniem, że składniki 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 wytrzymałe w różnych scenariuszach awaryjnych.

Czy oczekujesz, że wytrzymałość AI stanie się decydującym czynnikiem w wyborze platformy i dostawcy, podobnie jak w przypadku, gdy czas pracy i redundancja kształtowały decyzje dotyczące infrastruktury chmury?

Gdy więcej systemów AI przechodzi do produkcji, wytrzymałość stanie się podstawą. Jeśli dostawca nie może przedstawić swoich wykresów i wskaźników dotyczących czasu pracy i ogólnej wytrzymałości, nie zostaną nawet brani pod uwagę. Gdy wytrzymałość 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 możliwości produktowych. Wraz z czasem składniki, takie jak brama AI i automatyczne możliwości przełączania awaryjnego, staną się podstawowymi elementami infrastruktury przedsiębiorczej AI.

Spójrzając w przyszłość, co oznacza „gotowy do produkcji” AI w świecie, w którym AI ma być nieprzerwanie dostępny, a nie tylko okazjonalnie pomocny?

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

Aby AI w produkcji było obserwowalne, zespoły potrzebują głębokiej widoczności w zachowaniu modelu, opóźnieniach, wskaźnikach błędów, zużyciu tokenów, dryfie i wzorcach awarii. Bez silnej obserwowalności staje się bardzo trudno wykryć degradacje, zanim użytkownicy zaczną je zauważać.

Aby systemy były kontrolowalne, obejmuje to kształtowanie ruchu, ograniczanie stawek, barierki, egzekwowanie polityki 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 kontrolna, która egzekwuje barierki, zapewnia spójne zarządzanie i umożliwia dynamiczne przełączanie modelu, gdy wydajność lub niezawodność spada.

I wreszcie, jeśli chodzi o odzyskiwalność, systemy powinny być budowane z założeniem, że składniki mogą być częściowo lub całkowicie uszkodzone, niezależnie od tego, czy jest to spowodowane awarią dostawcy, pogorszeniem jakości modelu, limitami stawek czy nieoczekiwanymi wprowadzeniami ze strony złych aktorów. Automatyczne mechanizmy przełączania awaryjnego i samonaprawy powinny być rodzime dla architektury, a nie ręczne podręczniki wyzwalane po wystąpieniu czegoś.

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 rozwiązywać nowe problemy, gdy tylko się pojawiają.

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