Dziewięć nawyków inżynierskich niezbędnych do wdrożenia pierwszego agenta AI.

W kręgach zajmujących się agentami inżynieryjnymi krąży historia o rachunku w wysokości 47 000 dolarów. Jest ona opowiadana bez większych szczegółów, więc należy ją traktować jako przykład ilustracyjny, a nie sprawę poddaną audytowi. Agent zachowywał się doskonale we wszystkich demonstracjach. Następnie został zastosowany w rzeczywistym procesie pracy klienta, co doprowadziło do błędnego cyklu zwrotów pieniędzy – agent wykonywał tę samą czynność w kółko przez sześć godzin, bez żadnej kontroli. Model nie był zbyt słaby. Ludzie, którzy stworzyli system, pominęli wszystko, co pozwala modelowi wiedzieć, kiedy przestać.

To jest nieprzyjemna prawda dotycząca pracy inżynierskiej nad systemami AI. Możesz znać Python, RAG, agenty, bazy danych wektorowych, techniki promptowania oraz każdą nową wersję modeli, a mimo to nie być gotowym do użycia w produkcji. Umiejętności, które ratują sytuację po nieudanej demonstracji, rzadko pojawiają się w tutorialach. Są nudne i łatwe do pominięcia, a jednocześnie odróżniają system wyglądający imponująco od tego, któremu można zaufać. Oto dziewięć przydatnych nawyków, które warto mieć przed wdrożeniem jakiegokolwiek autonomicznego rozwiązania.

Dlaczego większa wiedza nie czyni cię ekspertem

Kilka danych pokazuje, jak często projekty utykają pomiędzy demonstracją a wdrożeniem. Są to dane pochodne, a metody się różnią, więc traktuj je jako przybliżony obraz sytuacji:

• Prognoza Gartnera z połowy 2025 roku, według której ponad 40% projektów AI opartych na agentach zostanie anulowanych przed końcem 2027 roku, co wynika z rosnących kosztów, niejasnej wartości dodanej oraz słabych mechanizmów kontrolowania ryzyka.

Zgodnie z badaniem przeprowadzonym w 2025 roku przez S&P Global Market Intelligence, przed wpuszczeniem rozwiązań do produkcji firmy odrzucają około 46% swoich prototypów opartych na sztucznej inteligencji.

Międzynarodowy instytut technologii MIT w ramach inicjatywy NANDA, po przeanalizowaniu ponad 300 przypadków wdrożeń, stwierdził, że tylko około 5% z nich przyniosło mierzalny wpływ finansowy.

Żaden model nagle nie stał się o 40% gorszy pod względem umiejętności rozumowania. Coś idzie nie tak pomiędzy demonstracją a faktycznym wdrożeniem. Obowiązująca tu teoria głosi, że problemy w produkcji są często spowodowane lub wzmacniane przez system otaczający model, a nie wyłącznie przez jego wyniki: brak odpowiednich zabezpieczeń, niska jakość danych, słaba weryfikacja, ograniczona możliwość obserwacji oraz niekontrolowane wydatki.

Wskaźnik benchmarkowy wskazuje w tym samym kierunku, ale nie udowadnia przyczyny. W projekcie tau-bench, który testuje agenty używające narzędzi do zadań takich jak rezerwowanie lotów i rozwiązywanie zgłoszeń klientów, w jednym podsumowaniu stwierdzono, że nawet najlepsze modele ukończyły mniej niż połowę z nich, a powtarzanie zadania spowodowało spadek spójności do około jednej czwartej. To mierzy zdolności, ale niczego nie diagnozuje. Stwierdza się tam jedynie, że agenci są niewiarygodni, ale nie wyjaśnia dlaczego.

Pamiętaj o jednej różnicy, ponieważ przenika ona każdy z poniższych nawyków: powyższy błąd nie był błędną odpowiedzią. Nic go nie powstrzymało. Różnica pomiędzy wynikiem modelu a tym, co system pozwala osiągnąć dzięki temu wynikowi, jest miejscem, gdzie znajduje się większość tych nawyków.

1. Napisz funkcję oceny przed funkcją charakterystyczną

Początkujący piszą prompt, testują go kilka razy, sprawdzają wyniki i wdrażają rozwiązanie. Doświadczeni inżynierowie najpierw zapisują, co oznacza „poprawność” w postaci zestawu przypadków testowych, a dopiero potem przystępują do realizacji funkcji.

Ocena może być prosta – zebrane 20 do 30 rzeczywistych przykładów z faktycznego użycia, każdy z przewidywanym wynikiem, oraz sprawdzanie promptu we wszystkich tych przypadkach za każdym razem, gdy coś się zmienia. Jeśli nie potrafisz stwierdzić, czy zmiana przyniosła korzyść, nie patrząc na wyniki i nie zgadując, to masz jedynie przeczucie, a nie rzetelną ocenę. Ten jeden nawyk to najszybszy sposób na uniknięcie wdrażania regresji, których nie można dostrzec.

2. Traktuj kontekst jak pieniądze

Zwykłem początkujących polega na wkładaniu tam wszystkiego: całego dokumentu, całej rozmowy, pięciu przykładów „na wszelki wypadek”. Więcej kontekstu wydaje się bezpieczniejsze, ale zazwyczaj tak nie jest. Każdy dodatkowy element konkuruje o uwagę modelu i dostarcza mu kolejnego błędnego szczegółu, na którym może się skupić. Traktuj okno jako budżet:

• Zredukuj pobrane dokumenty do istotnych części.
• Streszczaj starsze fragmenty rozmowy i nie odtwarzaj ich w całości.
• Usuń przykłady, które nie przyczyniają się efektywnie.

Jeśli nie wiesz, co wypełnia okno, wydrukuj całe zapytanie, które wysyłasz, i przeczytaj je. Wielu ludzi jest zaskoczonych, ile w nim znajduje się zbędnego materiału.

3. Zastosuj ograniczenia autonomii przed uruchomieniem

To właśnie ten nawyk mógłby przerwać błędny cykl zwrotów pieniędzy. Jedna analiza kosztownych błędów agentów, przeprowadzona przez grupę o nazwie Operator Collective, podzieliła te przypadki na pięć kategorii: brak ograniczeń w działaniu autonomicznym, przestarzałe lub błędne dane, ufanie wynikom bez weryfikacji, bezpieczeństwo traktowane jako kwestia drugorzędna oraz błędy, których nikt nie zauważył, ponieważ nic ich nie monitorowało. Żadna z tych pięciu kategorii nie dotyczy „błędnego rozumowania modelu”. To jedynie analiza, a nie prawo przyrody, ale wskazuje na coś rzeczywistego. Błędny wynik rzadko powoduje szkodę sam w sobie – szkoda pojawia się wtedy, gdy nic poniżej w łańcuchu nie łapie tego błędu, nie ogranicza go ani nie zapobiega jego powtórzeniu.

Matematyka pokazuje, że to jest kwestia niepodważalna. Jeśli każdy krok w procesie pracy agenta kończy się sukcesem w 95% przypadków, a zadanie składa się z 20 kroków, to całość nie zostanie ukończona prawidłowo w 95% przypadków, ponieważ szanse się mnożą. Przy 90% skuteczności na krok, łańcuch z 20 kroków kończy się sukcesem jedynie w około 12% przypadków. Demo, które bez problemów wykonuje trzy kroki, niewiele mówi o procesie produkcyjnym z dwudziestoma krokami.

Zanim jakikolwiek autonomiczny system wejdzie do eksploatacji, należy ustalić dla niego limit kroków, górny próg kosztów, czas timeout oraz sposób na samozatrzymanie. Powodem nie jest to, że model nie może być godny zaufania – prawdopodobieństwo po prostu nigdy nie przegrywa.

4. Rejestruj wszystko, jakbyś miał debugować w ciemności o 2 w nocy.

Najniebezpieczniejszy błąd nie powoduje głośnego awarii. Agent podejmuje niewłaściwą decyzję, zgłasza sukces, panel sterowania pozostaje w kolorze zielonym, a klient traci pieniądze lub otrzymuje złe porady, zanim ktokolwiek to zauważy.

Początkujący dodają logowanie dopiero wtedy, gdy coś się zepsuje. Doświadczeni inżynierowie od samego początku tworzą ustrukturyzowane ślady działania: każdy wprowadzony dane, wywołanie narzędzia oraz krok rozumowania są zaznaczane datą i czasem oraz dostępne do wyszukiwania. Po trzech tygodniach chcesz odtworzyć dokładnie to, co agent widział i zdecydował, zamiast składać informacje z pamięci. Jeśli obecna konfiguracja zmusza cię do zgadywania w środku nocy, najpierw zamknij tę lukę.

5. Wspinaj się po drabinie: twórz prompty, pobieraj dane, a następnie dopracowuj

Gdy dokładność jest niezadowalająca, początkujący często od razu przechodzą do drobnej kalibracji, ponieważ wydaje im się to „prawdziwą” inżynierią. Zazwyczaj jest to błędny pierwszy krok, a dobrze znany przypadek pokazuje dlaczego. Badacze z Microsoftu wzięli GPT-4, dodali zestaw technik sterowania modelami zwany Medprompt i porównali go z Med-PaLM 2, specjalistą medycznym Google’a, dostosowanym na podstawie danych klinicznych i współpracującym z instrukcjami napisanymi przez ekspertów. Zgodnie z wynikami testów MedQA, kalibrowany Med-PaLM 2 osiągnął wynik 86,5%, natomiast GPT-4 z techniką Medprompt osiągnął 90,2%. Oznacza to 27% mniejszy wskaźnik błędów oraz znacznie mniej wywołań modelu w porównaniu z metodą kalibracji.

Rozsądny porządek działania powinien przebiegać od tanich i odwracalnych rozwiązań do drogich i wolnych:

Prompting        Retrieval (RAG)      Fine-tuning
(cheap, fast,  →  (add missing    →   (expensive, slow,
reversible)        knowledge)          last resort)

Najpierw popraw zapytanie i je zmierz. Jeśli model nie posiada potrzebnych faktów, dodaj funkcję wyszukiwania informacji. Dopiero wtedy, gdy masz duży, czysty zbiór danych oraz konkretne zachowanie, którego zapytania nie są w stanie wywołać, przystąp do drobnej optymalizacji. Większość zespołów nigdy tego nie musi robić, ponieważ wcześniejsze kroki rozwiązują problem.

6. Trzymaj umysł oddzielnie od rąk

Agent dla początkujących to często jedno ogromne zapytanie, które planuje, decyduje i wykonuje wszystko za jednym razem. Gdy zawodzi, nic nie oddziela stwierdzenia „model pomylił się w myśleniu” od stwierdzenia „kod zrobił coś nie tak”, ponieważ wszystko jest ze sobą splątane.

Doświadczeni programiści dzielą system na dwie części. Jedna z nich, model, pełni rolę „mózgu” i decyduje o następnym kroku. Druga część, zwykły kod deterministyczny działający jako narzędzie wykonawcze, realizuje tę decyzję: wywołuje API, sprawdza odpowiedź, próbuje ponownie w określonych granicach oraz egzekwuje zasady wynikające z trzeciego nawyku. To właśnie to podział sprawia, że system można debugować. Można od razu stwierdzić, czy model wybrał niewłaściwą akcję, czy kod wykonawczy źle zrealizował dobrą decyzję – są to różne błędy wymagające różnych rozwiązań.

7. Traktuj prompty jak kod i weryfikuj ich wersje

Zapytanie, które wymagało czterech przeredagowań, to przykład logiki produkcyjnej. Traktuj je jak papier do rysowania – stracisz wersję działającą w momencie, gdy ktoś je „ulepszy”. Zachowuj zapytania w systemie kontroli wersji tak jak każdy inny plik, sprawdzaj zestaw testowy od razu po każdej zmianie przed jej włączeniem i zapisuj krótki log zmian, pokazujący, co się zmieniło i dlaczego. Brzmi to zbyt podstawowo, by o tym wspominać, i właśnie dlatego większość zespołów tego pomija, aż regresja w działaniu zapytania dotrze do środowiska produkcyjnego i nikt nie będzie w stanie powiedzieć, co się zmieniło.

8. Najpierw ustal cenę funkcji

Oto jeden przykład ilustrujący tę kwestię. Agent działający bez ograniczeń przy wykonywaniu pojedynczego zadania programistycznego wydał od 5 do 8 dolarów na opłaty API, podczas gdy całe sesje produkcyjne, próby ponowne oraz wywołania narzędzi kosztowały od 10 do 100 dolarów. Wartości te mogą się różnić w zależności od modelu, zadania i metod optymalizacji, ale ogólny schemat pozostaje ten sam. Koszt, który wydaje się znikomy przy małej skali, przestaje nim być przy większej ilości zadań, a projekt pilotażowy, który wydawał się tani podczas testów, może potajemnie stać się powodem odłożenia projektu.

Początkujący najpierw tworzą, a rachunek czytają później. Doświadczeni inżynierowie szacują koszt za zadanie przed napisaniem jakiegokolwiek kodu: przybliżoną liczbę tokenów wydanych i otrzymanych, oczekiwane liczbę wywołań na zadanie oraz przewidywaną dzienną ilość zadań. Jeśli liczby wydają się niewłaściwe przy dziesięciu użytkownikach, nie będą lepsze przy dziesięciu tysiącach. Koszt nie jest kwestią finansową do rozpatrzenia po uruchomieniu – to decyzja architektoniczna, którą podjęto już wcześniej, niezależnie od tego, czy się tego zauważyło, czy nie.

9. Diagnozuj przed domysłami

Gdy coś się zepsuje, pierwszym odruchem początkującego jest wskazanie na model i zastąpienie go większym lub napisanie dłuższego promptu. Nie rób tego. Problemy wspomniane w recenzjach pod punktem trzecim wynikały z braku ograniczeń, złych danych, niekontrolowanego zaufania, słabej bezpieczeństwa lub błędu, którego nikt nie zauważył, a nie z błędu samego modelu. To obserwacja oparta na jednej grupie przypadków i nie stanowi gwarancji w twoim przypadku, ale to tanie sprawdzenie przed droższymi działaniami. Zanim dotkniesz promptu, zapytaj się, czy uzyskane dane są przestarzałe lub błędne, czy wywołanie narzędzia zakończyło się bezpowrotnie oraz czy istnieje limit prób ponownych. Rozwiązanie często znajduje się w otaczającym systemie, a sprawdzenie to zajmuje pięć minut w porównaniu z pisaniem od nowa.

Kiedy pominąć połowę tego tekstu

Żadna z dziewięciu nawyków nie jest darmowa. Budowa narzędzi oceny wymaga czasu, zasady bezpieczeństwa dodają kod, a modelowanie kosztów pochłania popołudnie, które wolałbyś przeznaczyć na tworzenie. Jeśli projektujesz prototyp w weekend i jesteś jedynym użytkownikiem, pomiń większość tych kroków. Włącz zestaw narzędzi oceny, zasady bezpieczeństwa oraz wersjonowane instrukcje dopiero wtedy, gdy inni zaczną polegać na tym, co stworzyłeś, a nie wcześniej. Prowadzenie eksperymentu jednej osoby z pełnymi procedurami produkcyjnymi to marnowanie czasu, który lepiej wykorzystać na sprawdzenie, co faktycznie działa. Dyscyplina przynosi efekty tam, gdzie występuje pętla zwrotów: w systemach, które dotyczą rzeczywistych użytkowników, prawdziwych pieniędzy lub ważnych decyzji.

Zmiana w jednym zdaniu

Zgodnie z tym opisem żaden bardziej zaawansowany model nie naprawił tego błędu. To zestaw pisemnych zasad go naprawił: ograniczenia autonomii, weryfikacja przed każdą akcją oraz osoba przeglądająca logi. To zarządzanie, a nie inteligencja. Początkujący próbują przezwyciężyć błędy za pomocą lepszego modelu. Doświadczeni inżynierowie tworzą system, który bezpiecznie zawodzi, gdy model jest błędny, ponieważ prędzej czy później tak się stanie.