Brakujący element w dyskusji o AI
Wszyscy mówią o agentach AI. Przeglądając dowolny kanał technologiczny, znajdziesz dziesiątki demonstracji pokazujących, jak duży model językowy rezerwuje loty, pisze kod lub odpowiada na zgłoszenia wsparcia w ramach jednej, olśniewającej rozmowy. Przekaz wydaje się jasny: jeśli połączysz użytkownika z LLM, dzieją się cuda.
Ta iluzja świetnie sprawdza się podczas pięciominutowej prezentacji. Rozpada się jednak w momencie, gdy do gry wchodzą prawdziwi użytkownicy, prawdziwe dane i prawdziwe pieniądze. W środowisku produkcyjnym relacja nigdy nie ogranicza się tylko do User ↔ LLM. To User ↔ złożony system, który po prostu zawiera w sobie LLM. Częścią tego systemu, o której nikt nie mówi, jest harness – rusztowanie, które wybiera, kieruje, chroni i orkiestruje wszystko wokół modelu. Bez niego nie masz produktu. Masz prototyp.
Dlaczego prosta pętla zawodzi
Demo to kontrolowane środowisko. Zapytania są krótkie, kontekst ograniczony, a stawka niska. Deweloper wykonuje pojedyncze wywołanie API, otrzymuje płynną odpowiedź, a publiczność klaszcze. Ale produkcja jest chaotyczna. Użytkownicy zadają niejednoznaczne pytania uzupełniające. API firm trzecich przekraczają czas oczekiwania (timeout). Model, który wczoraj generował idealny JSON, nagle zaczyna wyrzucać markdown. Okna kontekstowe się zapełniają. Limity zapytań (rate limits) aktywują się w najgorszym możliwym momencie.
Surowa pętla prompt-odpowiedź nie ma na to odpowiedzi. Nie wie, która wersja modelu powinna obsłużyć dane zadanie. Nie pamięta, co wydarzyło się trzy kroki temu. Nie potrafi ponowić nieudanego wywołania, ograniczyć liczby żądań, gdy koszty gwałtownie rosną, ani oczyścić wyjścia przed zapisaniem go w bazie danych. To nie są przypadki brzegowe. To cechy definiujące oprogramowanie w świecie rzeczywistym. Obsługa tych sytuacji to zadanie dla harnessu.
Co tak naprawdę robi harness
Potraktuj harness jako warstwę inżynieryjną, która zmienia model językowy z błyskotliwego generatora tekstu w niezawodny komponent usługi. Jego obowiązki są konkretne i mało widowiskowe, co jest dokładnie powodem, dla którego są one często pomijane.
Wybór modelu do bieżącego zadania. Nie każda interakcja wymaga najpotężniejszego dostępnego modelu bazowego. Niektóre zadania wymagają surowej mocy rozumowania; inne potrzebują po prostu szybkości i niskich kosztów. Dobrze zbudowany harness inteligentnie kieruje zapytaniami. Na przykład agent wsparcia klienta może użyć szybkiego i taniego modelu do sklasyfikowania intencji przychodzącej wiadomości – czy jest to prośba o zwrot, czy pytanie o wysyłkę. Jeśli intencja wskazuje na złożony spór dotyczący polityki firmy, harness przekazuje zadanie do cięższego modelu rozumującego. Jeśli użytkownik chce tylko linku do śledzenia przesyłki, lekki model odpowiada natychmiast, a koszty operacyjne pozostają na rozsądnym poziomie.
Zarządzanie przepływem danych. Prawdziwe aplikacje nie istnieją w próżni. Agent AI często musi pobrać dokumenty z bazy wektorowej, zapytać CRM, odczytać ostatnią aktywność użytkownika, a następnie zsyntetyzować to wszystko w spójną odpowiedź. Harness zarządza tym procesem pobierania danych. Pobiera odpowiednie fragmenty kontekstu, sprawdza, czy mieszczą się w limitach tokenów bez utraty istotności, strukturyzuje je dla modelu i przekazuje wynikowy output do kolejnego systemu w łańcuchu. Bez tej orkiestracji model jest albo pozbawiony kontekstu, albo zalany szumem informacyjnym.
Zarządzanie błędami. Modele LLM zawodzą w sposób, w jaki nie robią tego tradycyjne usługi. Halucynują ustrukturyzowane dane wyjściowe. Zwracają puste odpowiedzi. Naruszają instrukcje formatowania w momencie, gdy wersja modelu bazowego ulegnie nawet niewielkiej zmianie. Harness traktuje te awarie jako oczekiwane zachowanie, a nie niespodzianki. Waliduje schematy, wyłapuje błędne odpowiedzi, stosuje logikę ponawiania prób z wykładniczym czasem oczekiwania (exponential backoff) i przełącza się na drugiego dostawcę lub wynik z pamięci podręcznej, gdy główny punkt końcowy (endpoint) zawiedzie. Gdy wszystko inne zawiedzie, przekazuje sprawę do operatora-człowieka, zamiast po cichu serwować bzdury płacącemu klientowi.
Zapewnienie niezawodności systemu. Produkcja oznacza wielu jednoczesnych użytkowników, limity kosztów i nieprzewidywalne opóźnienia. Harness wymusza limity zapytań (rate limits), zarządza pulą połączeń (connection pooling) i wdraża mechanizmy circuit breaker, aby jeden powolny dostawca modelu nie sparaliżował całej aplikacji. Loguje każdą interakcję, aby można było prześledzić, dlaczego dana sesja zakończyła się niepowodzeniem, i wersjonuje prompty, aby wdrożenie nie zmieniło przypadkowo osobowości Twojego agenta bez ścieżki audytowej.
Ten sam model, zupełnie inne rezultaty
To wyjaśnia zjawisko, które dezorientuje wiele zespołów produktowych. Dwie firmy mogą zacząć od dokładnie tego samego modelu bazowego – tych samych wag, tego samego okna kontekstowego, tej samej daty odcięcia danych treningowych – i dostarczyć doświadczenia, które wydają się pochodzić z zupełnie innych światów. Jedno wydaje się niestabilne, powolne i dziwnie zapominalskie. Drugie wydaje się błyskawiczne, spójne i godne zaufania.
Różnica nigdy nie tkwi w samym modelu. Tkwi w systemie zbudowanym wokół niego. Jeden zespół traktował model jako cały produkt. Drugi traktował go jako jeden z komponentów w uporządkowanej architekturze. To właśnie w tym systemie osłonowym (harness) kryje się ta dyscyplina.
Przejście od promptów do architektury
Wczesny rozwój AI stawiał prompt engineering w centrum uwagi. Dopracowywanie słownictwa, dodawanie przykładów i nakładanie instrukcji odgrywania ról mogło drastycznie poprawić jakość wyników. Ta umiejętność wciąż jest ważna, ale przestała być skuteczną fosą konkurencyjną (competitive moat) ze względu na malejące korzyści. Nie da się naprawić braku polityki ponawiania prób (retry policy) ani splątanego potoku danych (data pipeline), który wycieka prywatny kontekst do odpowiedzi publicznej, za pomocą samych promptów.
Prawdziwa zmiana, która dokonuje się właśnie teraz, to przejście w stronę architektury oprogramowania. Inżynierowie projektują maszyny stanów, definiują ścisłe interfejsy między warstwą modelu a logiką aplikacji i traktują niedeterminizm jako kluczowe zagadnienie inżynieryjne. Zadają pytania typowe dla systemów rozproszonych: Jak stan utrzymuje się w wieloturowej konwersacji? Co się dzieje, gdy narzędzie downstream jest niedostępne? Jak testować system, którego główny komponent jest probabilistyczny? To są pytania, które odróżniają zabawkę od narzędzia.
Budowanie do produkcji: Obserwowalność i kontrola
Jeśli poważnie myślisz o wdrażaniu produktów, system osłonowy wymaga dwóch cech ponad wszystko: obserwowalności i orkiestracji.
Obserwowalność oznacza, że możesz zobaczyć, co model otrzymał, co zwrócił i jak długo trwał każdy krok. Oznacza śledzenie pętli decyzyjnej agenta przez czternaście wywołań narzędzi i precyzyjne wskazanie momentu, w którym zaczął on zapętlać się lub zbaczać z kursu. Bez tej widoczności debugowanie systemu AI jest jak naprawianie silnika samochodu po ciemku.
Orkiestracja oznacza, że logika biznesowa pozostaje oddzielona od warstwy interakcji z modelem. Oznacza wersjonowanie promptów w taki sam sposób, w jaki wersjonuje się kod, aby nowa implementacja nie zmieniła po cichu zachowania systemu. Oznacza celowe testowanie trybów awaryjnych – przerywanie połączenia z API w trakcie żądania, podawanie błędnych wyników narzędzi, symulowanie przepełnienia okna kontekstowego – aby sprawdzić, czy system osłonowy utrzyma stabilność całego układu. Frameworki przychodzą i odchodzą, a niezależnie od tego, czy wybierzesz gotową bibliotekę do orkiestracji, czy zbudujesz własną, to dyscyplina jest ważniejsza niż nazwa marki.
Kluczowy wniosek
Modele bazowe będą się stale doskonalić. Będą szybsze, tańsze i bardziej zdolne. Jednak potężniejszy silnik nie naprawi uszkodzonego podwozia. Zespoły, które wygrają w ciągu najbliższych kilku lat, to nie te, które mają dostęp do najnowocześniejszych modeli. Będą to te, które zbudują system osłonowy będący niezawodnym, obserwowalnym i dobrze zorkiestrowanym środowiskiem. Będą mogli wymieniać modele bez przepisywania swoich aplikacji. Będą kontrolować koszty, ponieważ to system osłonowy zarządza każdym tokenem. Będą spać spokojnie, ponieważ ich systemy elegancko obsługują błędy.
Przestań obsesyjnie skupiać się na samym modelu. Zacznij obsesyjnie skupiać się na systemie, który go obsługuje. Przyszłość należy do inżynierów, którzy budują inteligentniejsze systemy wokół inteligentnych modeli.
Artykuł opiera się na pomysłach pierwotnie przedstawionych przez Abdulaziza Zosa w "Beyond The Model".
Więcej dyskusji na temat inżynierii AI i projektowania systemów znajdziesz w społeczności edukacyjnej GyaanSetu.