Azure AI zwalnia z prostych powodów. Model jest zbyt duży, zadanie jest zbyt wąskie, albo system został zbudowany bez wyraźnego dopasowania między obciążeniem a architekturą.
To jest prawdziwa lekcja płynąca z tej sytuacji. Szybsze systemy AI nie pochodzą od jednego wielkiego modelu. Pochodzą od lepszego dopasowania.
Przedostałem wystarczająco dużo czasu wokół systemów AI, by zaufać jednej regule: najlepszą architekturą jest ta, która zużywa mniej mocy obliczeniowej na błędne rzeczy. Azure AI Foundry została zbudowana wokół tego pomysłu. Daje zespołom katalog modeli, porównanie obok siebie oraz tabele liderów, aby mogły wybrać model według zadania, kosztu, przepustowości i bezpieczeństwa, zamiast zgadywać.
Czym tak naprawdę jest obciążenie AI
Obciążenie AI to rodzaj pracy, którą system musi wykonać. Niektóre obciążenia tworzą tekst. Niektóre analizują tekst. Niektóre słuchają mowy. Niektóre czytają obrazy. Niektóre łączą kilka z nich w jednym przepływie.
Generatywne AI obejmuje takie zadania jak chatboty, tworzenie treści, tłumaczenie i podsumowanie. Agentywna AI obejmuje asystentów, którzy mogą podejmować działania, wywoływać narzędzia i przechodzić przez wieloetapowe zadania. Analiza tekstu obejmuje takie rzeczy jak wykrywanie języka, klasyfikacja, analiza sentymentu, ekstrakcja kluczowych fraz, rozpoznawanie encji nazwanych (NER) i wykrywanie danych osobowych (PII).
Obciążenia dotyczące mowy obejmują transkrypcję, syntezę, głosowych agentów na żywo i tłumaczenie. Obciążenia computer vision obejmują OCR, klasyfikację, wykrywanie obiektów i segmentację. Ekstrakcja informacji często miesza tekst, wizję i mowę, dzięki czemu system może wyciągać fakty z kilku źródeł jednocześnie.
To mieszanie ma znaczenie. Model stworzony do generowania obrazów jest kiepskim wyborem dla lekkiego klasyfikatora. Model mowy jest stratny, gdy wejściem jest krótki etykieta tekstowa. Azure AI działa najlepiej, gdy obciążenie i model są czysto zgodne.
Dlaczego architektura wpływa na prędkość i koszt
Architektura to nie tylko serwery. W systemach AI architektura oznacza sposób, w jaki aplikacja routuje żądania, wybiera modele, obsługuje kontekst i ogranicza zmarnowaną pracę.
Pierwszą dużą decyzją jest rozmiar modelu. Duże modele są silniejsze w rozumowaniu, kodowaniu, matematyce i generowaniu otwartym. Małe modele są lepsze, gdy zadanie jest proste, o wysokiej objętości lub wrażliwe na opóźnienia. Większy rozmiar nie jest darmowym zwycięstwem. Często oznacza to większy koszt i większe opóźnienie.
Drugą decyzją jest dopasowanie możliwości. Model może być doskonały w pisaniu, ale słaby w rozumieniu obrazów. Inny może dobrze radzić sobie ze strukturą wyjściową, ale mieć problemy z długimi łańcuchami rozumowania. Dobra architektura wybiera najmniejszy model, który nadal pokrywa zadanie.
Trzecią decyzją jest modalność. Niektóre modele obsługują tylko tekst. Inne obsługują tekst i obraz, lub mowę i tekst. Jeśli aplikacja wymaga multimodalnego wejścia, system powinien użyć modelu multimodalnego, zamiast wymuszać na modelu tylko tekstowym, by udawał, że widzi.
Czwartą decyzją jest okno kontekstowe. Długie dokumenty, duże bazy kodu i przedłużone rozmowy wymagają więcej tokenów. Krótkie zadania nie. Większe okno może pomóc, ale zmienia też koszt i opóźnienie.
Piątą decyzją jest wysiłek rozumowania. Niektóre modele oferują tryb niskiego lub wysokiego rozumowania. Niskie rozumowanie jest szybsze. Wysokie rozumowanie spędza więcej czasu na myśleniu nad trudnymi zadaniami matematycznymi, kodowaniem lub planowaniem. Jest to przydatne tylko wtedy, gdy zadanie tego wymaga.
Opóźnienie ma największe znaczenie w chatbotach, współpilotach i agentach głosowych. Mniej znaczenia ma w przetwarzaniu wsadowym dokumentów. Koszt ma większe znaczenie, gdy system obsługuje miliony żądań. To właśnie tam niedbała architektura szybko staje się droga.
Praktyczny wzorzec: kieruj ruchem według obciążenia, a nie haka marketingowego
Czysty wzorzec jest prosty. Zacznij od nazwania obciążenia. Następnie dopasuj rodzinę modeli do zadania. Sprawdź następnie, czy model jest wystarczająco szybki, wystarczająco tani i wystarczająco zdolny do rzeczywistego wzorca żądań.
Duży ogólnego przeznaczenia model może być dobrym wyborem do złożonej analizy dokumentów, generowania kodu i zaawansowanych asystentów. Mniejszy model może być dobrym wyborem do podsumowania, klasyfikacji lub prostego chatbota. Model embeddingu należy umieścić w wyszukiwaniu. Model mowy należy umieścić w transkrypcji. Model wizji należy umieścić w OCR lub analizie obrazu.
W tym miejscu pomaga Azure AI Foundry. Jej katalog modeli pozwala zespołom przeglądać modele od kilku dostawców w jednym miejscu. Widok porównania pokazuje kilka modeli obok siebie. Tablice liderów pokazują jakość, bezpieczeństwo, szacowany koszt i przepustowość. Tablice liderów scenariuszowych idą o krok dalej i rangują modele dla konkretnego zadania.
Ma to znaczenie, ponieważ „najlepszy ogólnie” to słabe pytanie. „Najlepszy dla tego obciążenia” jest użytecznym pytaniem.
Mały przykład: rozpoznawanie encji nazwanych
Weźmy pipeline tekstowy, który potrzebuje rozpoznawania encji nazwanych. Zadaniem jest wskazanie imion, miejsc, organizacji i dat w tekście.
Takie zdanie jak „Satya Nadella odwiedził Londyn w poniedziałek dla Microsoft” można podzielić na Osoba, Lokalizacja, Data/Czas i Organizacja. To wąskie zadanie. Nie potrzebuje gigantycznego kreatywnego modelu. Potrzebuje modelu, który jest dobry w rozumieniu strukturyzowanego tekstu i wystarczająco szybki, by działać często.
Mniejszy model tekstowy, a nawet specjalistyczne podejście do analizy tekstu, może z tym dobrze poradzić. Jeśli ten sam pipeline potrzebuje również podsumowania dokumentu, ekstrakcji encji i odpowiadania na pytania uzupełniające, szerszy LLM może mieć sens. Ale architektura nadal powinna oddzielać pracę. Jeden model do wyszukiwania. Inny do ekstrakcji. Inny do finalnej odpowiedzi, jeśli jest potrzebna.
To rozdzielanie jest tam, gdzie optymalizacja w stylu Azure zaczyna się opłacać. System przestaje marnować najsilniejszy model na łatwą pracę.
Do czego służą narzędzia Foundry
Katalog modeli jest punktem wyjścia. Pozwala zespołom odkrywać modele i inspekcjonować karty modeli pod kątem typu danych, możliwości, opcji wdrożenia i benchmarków, gdy są dostępne.
Widok porównania jest przydatny, gdy wybór jest bliski. Azure pozwala porównać dwa lub trzy modele obok siebie. To wystarczy, by zobaczyć rzeczywiste różnice, bez zamieniania wyboru w sport.
Tablice liderów są lepsze, gdy pytanie brzmi: „który model jest najsilniejszy w tym metryku?”. Rangują one według jakości, bezpieczeństwa, przepustowości i szacowanego kosztu. Wykresy kompromisów pokazują, co się dzieje, gdy jedna metryka poprawia się, a inna spada. Tablice liderów scenariuszowych są jeszcze lepsze, gdy zadanie jest wąskie, bo odpowiadają na pytanie, które naprawdę ma znaczenie.
To jest uczciwa część. Żadna tablica liderów nie zastępuje osądu domenowego. Liczby z benchmarków są użyteczne, ale nie znają stylu Twoich promptów, kształtu Twoich danych, limitu opóźnień ani tolerancji na awarie. Zawężają pole. Nie domykają sprawy.
Lekcja dotycząca architektury, która trwa
Azure AI przyspiesza zadania, gdy system jest zaprojektowany tak, by marnować mniej. Oznacza to wybór właściwej rodziny modeli, właściwego rozmiaru, właściwej modalności i właściwego routingu dla każdego zadania. Oznacza to również zaakceptowanie faktu, że mniejszy model często wygrywa pod względem prędkości i kosztu, gdy zadanie jest proste.
Ufam takiemu projektowi, ponieważ jest nudny w najlepszy możliwy sposób. Zamienia wybór modelu w inżynierię, a nie zgadywanie. Robi też widocznymi limity, co jest miejscem, gdzie prawdziwe systemy zaczynają się poprawiać.
Model Log jest zbudowany wokół tego samego pomysłu: jeden praktyczny koncept AI, jeden działający przykład i jeden szczery rzut oka na to, co naprawdę działa.
