Systemy sztucznej inteligencji wymagają ustrukturyzowanej architektury oprogramowania. To jest prosta odpowiedź, a ma to znaczenie, ponieważ kod AI nie pozostaje prosty przez długi czas. Gdy system posiada przepływ danych, wywołania modeli, prompty, narzędzia, pamięć, kontrole i logowanie, kod potrzebuje jasnego kształtu.
Wciąż wracam do jednego faktu: praca z AI to nie jedno wywołanie modelu. To system. System potrzebuje części o jasno określonych zadaniach. Potrzebuje sposobu na przyjmowanie danych, przekazywanie wyników i sprawdzanie tego, co się stało, gdy coś pójdzie nie tak. Właśnie tam pojawia się architektura. Nadaje ona pracy strukturę, którą ludzie mogą czytać, testować i zmieniać.
Bez tej struktury oprogramowanie AI staje się kruche w szybkim tempie. Mała zmiana w jednym miejscu może zepsuć działanie w innym. Zmiana prompta może wpłynąć na wywołanie narzędzia. Wywołanie narzędzia może zmienić format wyjściowy. Aktualizacja modelu może przesunąć cały przepływ. Gdy kod nie ma jasnych granic, te zmiany rozprzestrzeniają się w sposób trudny do śledzenia.
Przydatną koncepcją tutaj jest projekt modularny. Chodzi o podzielenie systemu na części o wąskich zadaniach. Jedna część może obsługiwać wejście. Inna może czyścić dane. Inna może wywoływać model. Inna może sprawdzać wynik. Inna może logować przebieg zdarzeń. Każda część ma wyraźny interfejs. Dzięki temu system łatwiej przetestować i łatwiej wymienić.
Jest to szczególnie ważne w przypadku AI, ponieważ zachowanie AI nie jest w pełni ustalone. Dwa uruchomienia mogą wyglądać podobnie, a mimo to różnić się drobnymi szczegółami. Model może odpowiadać dobrze jednego dnia, a następnego dnia zacząć odbiegać od normy po zmianie wersji, edycji prompta lub nowej ścieżce narzędzi. Ustrukturyzowana architektura nie usuwa tej niepewności, ale sprawia, że staje się ona widoczna. Ma to większe znaczenie, niż się wydaje.
Uważam, że obserwowalność (observability) to drugi kluczowy element. Oznacza to, że system może pokazywać swoją własną pracę. Rejestruje on dane wejściowe, wyjściowe, błędy, opóźnienia i inne użyteczne sygnały. W systemie AI nie jest to luksus. To sposób, w jaki zespoły debugują części między żądaniem a odpowiedzią. Jeśli system korzysta z narzędzi lub wielu kroków, śledzenie każdego kroku staje się jeszcze ważniejsze.
Dlatego też koordynacja (orchestracja) ma znaczenie. Koordynacja to logika, która zarządza krokami. Decyduje, co wykonuje się pierwsze, co następne i co dzieje się w przypadku awarii. W prostym oprogramowaniu bezpośrednie wywołanie funkcji może wystarczyć. W systemach AI ścieżka jest często dłuższa. Żądanie może wymagać routingu, pobierania danych, wnioskowania modelu, walidacji i logiki ponawiania prób. Czysta koordynacja zapobiega splątaniu tego przepływu.
Nie uważam, by każdy projekt AI potrzebował dużego frameworka lub ciężkiego stosu technologicznego. Byłaby to leniwa odpowiedź. Małe systemy mogą pozostać małe. Ale nawet mała funkcja AI potrzebuje pewnej struktury, jeśli ma funkcjonować w ramach prawdziwego oprogramowania. Granica między demonstracją a systemem jest często bardzo krótka, a ta druga zazwyczaj ma użytkowników.
Istnieje też ograniczenie, które zasługuje na szczere omówienie. Dobra architektura nie gwarantuje dobrego zachowania AI. Estetyczna struktura nadal może zawierać słaby model, złe dane lub kiepski prompt. Może też ukrywać złożoność, jeśli zespół doda zbyt wiele warstw zbyt szybko. Struktura pomaga kontrolować system. Nie rozwiązuje trudnych kwestii rozumowania, jakości danych ani limitów modeli.
Dlatego ufam architekturze bardziej niż histerii otaczającej AI. Systemy AI to nie magiczne skrzynki. To systemy oprogramowania o nietypowych trybach awarii. Potrzebują kontraktów między częściami, logowania, kontroli wersji i jasnej ścieżki dla zmian. Jeśli brzmi to nudno, tym lepiej. Nudna architektura często pozwala ciekawym funkcjom AI przetrwać kontakt z produkcją.
Praktyczna lekcja jest prosta. Jeśli AI jest częścią oprogramowania, to oprogramowanie potrzebuje kształtu. Nie każda część musi być wymyślna. Ale system musi być podzielony na elementy, które można zrozumieć, sprawdzić i zmienić bez zgadywania. To różnica między prototypem, który działa raz, a oprogramowaniem, które może działać ciągle.
Szczerze mówiąc, ograniczeniem jest to, że ta dziedzina wciąż się rozwija. Nowe typy modeli, wzorce agentów i narzędzia szybko zmieniają szczegóły. Ale główna idea nie zmieniła się zbytnio: jeśli od systemu oczekuje się wzrostu, awarii i konserwacji, potrzebuje on struktury zanim potrzebuje sprytu.
To rodzaj pracy, którą The Model Log stara się wspierać: jedna praktyczna koncepcja AI, jeden działający przykład i jeden szczery przegląd tego, co naprawdę działa.
