Kiedy zaczynasz budować z wykorzystaniem sztucznej inteligencji, najgłośniejsze głosy wskazują w tym samym kierunku: na model. Wybierz właściwy, mówią, a reszta ułoży się sama. Po kilku tygodniach własnych eksperymentów mogę ci powiedzieć, że to po prostu nieprawda. Wybór między dostępnymi dużymi modelami językowymi ma znaczenie, ale to może zaledwie dwadzieścia procent pracy. Reszta to praca nad systemami. To instalacje, rzemiosło i nieustanne testowanie. To uświadomienie sobie czegoś nastąpiło u mnie wcześnie i od tego czasu zmieniło sposób, w jaki podchodzę do każdego projektu.

Model to dopiero początek

Łatwo zrozumieć, dlaczego początkujący obsesyjnie skupiają się na modelach. Notatki z wydania obiecują lepsze rozumowanie, większe okna kontekstowe i czystsze wyniki. Te ulepszenia są realne, ale mają charakter ogólny. Najnowocześniejszy model nie będzie automatycznie znał polityki zwrotów twojej firmy. Nie będzie niezawodnie formatował odpowiedzi dla twojej aplikacji mobilnej, chyba że powiesz mu, jak to zrobić. Nie wyczaruje danych o aktualnych stanach magazynowych z powietrza.

Nauczyłem się tego na własnej skórze. Mój pierwszy prototyp wykorzystywał zdolny model i generował piękne, pewne siebie akapity, które bywały czasem całkowicie błędne. Tekst brzmiał profesjonalnie, ponieważ model opanował ton, ale nie miał dostępu do aktualnych informacji. Spędzałem dni na porównywaniu benchmarków modeli, podczas gdy powinienem był myśleć o potokach danych (data pipelines) i wstrzykiwaniu kontekstu (context injection). Model nie był zepsuty. System wokół niego był niekompletny. To rozróżnienie jest kluczowe, gdy przechodzisz od wersji demonstracyjnych do oprogramowania, na którym ludzie faktycznie polegają.

Prompty to kod, a nie sugestie

Wysokiej jakości prompty stanowią serce każdej niezawodnej aplikacji AI. Na początku traktowałem prompty jak zapytania wyszukiwania – krótkie, swobodne, optymistyczne. Prosiłem model o „podsumuj to” lub „bądź pomocny” i liczyłem na najlepsze. Wyniki wahały się drastycznie między użytecznymi a nieistotnymi, a ja nie miałem pojęcia dlaczego.

Teraz traktuję prompty jak lekkie programy. Dobry prompt definiuje rolę, określa format wyjściowy, zawiera przykłady, gdy jest to konieczne, i wyznacza granice. Jeśli chcę JSON, proszę o JSON i pokazuję schemat. Jeśli potrzebuję zwięzłej odpowiedzi, wyraźnie ograniczam długość i zakazuję wstępów. Iteracja ma znaczenie. Prowadzę bieżący log promptów i ich wyników, zmieniając jedną zmienną na raz. Pojedynczy niejednoznaczny przymiotnik w prompcie może zmienić zachowanie całego przepływu pracy (workflow). Ta wrażliwość wymaga rygoru, a nie zgadywania.

Śmieci na wejściu, śmieci na wyjściu

Niezawodne pobieranie danych to miejsce, w którym wiele projektów AI po cichu umiera. Retrieval-Augmented Generation, czyli RAG, stało się standardowym wzorcem udostępniania modelom dostępu do prywatnych lub aktualnych danych. Pomysł jest prosty: pobierz istotne dokumenty, włóż je do okna kontekstowego modelu i pozwól mu wyciągać wnioski na podstawie faktów. Praktyka jest jednak znacznie bardziej skomplikowana.

Spędziłem czas na debugowaniu prostej bazy wiedzy, która wciąż zwracała niepowiązane wyniki. Model był w porządku. Warstwa pobierania danych (retrieval layer) zawodziła. Moje fragmenty (chunks) były zbyt małe i pozbawione kontekstu. Moje osadzenia (embeddings) były generowane bez oczyszczenia duplikujących się nagłówków. Wyszukiwanie podobieństwa znajdowało technicznie bliski tekst, który odpowiadał na błędne pytanie. Naprawa tego wymagała przemyślenia strategii dzielenia tekstu (chunking), dodania filtrów metadanych i wprowadzenia etapu ponownego rankingu (re-ranking). Gdy pobieranie danych się ustabilizowało, odpowiedzi modelu natychmiast się poprawiły. Lekcja była jasna: nie naprawisz złego pobierania danych lepszym modelem. Musisz poprawnie zbudować potok danych (pipeline).

Nie możesz ulepszyć tego, czego nie mierzysz

Ciągła ewaluacja to nawyk, który odróżnia eksperymenty od produktów. Kiedy zaczynałem, oceniałem na podstawie „wrażenia”. Czytałem pięć wyników, potakiwałem z aprobatą i szedłem dalej. To działa, dopóki użytkownik nie zada szóstego pytania i nie otrzyma czegoś dziwnego.

Teraz tworzę małe zestawy ewaluacyjne dla każdej funkcji. Zbieram rzeczywiste zapytania użytkowników, etykietuję oczekiwane zachowanie i przeprowadzam automatyczne testy względem nich. Obserwuję dryf (drift): prompt, który działał w zeszłym miesiącu, może stracić na jakości po aktualizacji modelu lub zmianie danych źródłowych. Oddzielam ocenę stylu od dokładności faktograficznej. Wyglądanie profesjonalnie jest miłe; bycie poprawnym jest obowiązkowe. Bez tej pętli wypuszczasz produkt w oparciu o nadzieję, a nadzieja nie jest strategią testowania.

Poznaj ograniczenia maszyny

Zrozumienie ograniczeń modeli uchroniło mnie przed obiecywaniem zbyt wiele i niedostarczaniem obiecanych rezultatów. Te systemy mają realne ograniczenia. Okna kontekstowe są większe niż kiedyś, ale wciąż mają swoje limity, a ich przepełnianie pogarsza wydajność w skrajnych przypadkach. Modele halucynują, zwłaszcza w niszowych tematach, gdzie dane treningowe są skąpe. Mają trudności z precyzyjną arytmetyką i pewnymi rodzajami logiki wieloetapowej. Są wrażliwe na sformułowania.

Koszt i szybkość to również ograniczenia. Model, który generuje idealną prozę w dziesięć sekund, może być bezużyteczny w interfejsie czatu działającym w czasie rzeczywistym. Teraz na wczesnym etapie przypisuję funkcje do budżetów opóźnień. Jeśli zadanie wymaga odpowiedzi w czasie poniżej sekundy, mogę wstępnie obliczyć odpowiedzi, agresywnie stosować buforowanie lub użyć mniejszego modelu do pierwszej wersji, a większego tylko do dopracowania. Praca w ramach ograniczeń to standard w inżynierii. AI nie różni się od tego.

Budowanie dla prawdziwych ludzi

Obecnie studiuję zastosowania LLM i inżynierię oprogramowania z prostym celem: budować narzędzia, których ludzie używają każdego dnia. Brzmi to oczywistością, ale przepaść między fajnym prototypem a narzędziem codziennego użytku jest ogromna. Demo może tolerować czterdziestosekundową pauzę i rozwlekłą odpowiedź. Osoba próbująca skończyć zadanie przed spotkaniem – nie może.

Narzędzia codziennego użytku wymagają obsługi błędów, mechanizmów awaryjnych i przejrzystego interfejsu użytkownika, gdy model nie jest pewny. Muszą integrować się z istniejącymi procesami pracy, zamiast wymuszać nowe. Teraz myślę o przypadkach brzegowych: co się stanie, gdy model odmówi odpowiedzi, gdy kontekst się przepełni lub gdy nastąpi timeout API? Wdrażanie oprogramowania AI oznacza odpowiadanie na te pytania za pomocą kodu, a nie tylko optymizmu.

Dzielmy się tym, czego się uczymy

Chcę nawiązać kontakt z innymi programistami, którzy poruszają się po tej samej ścieżce. Ta dziedzina rozwija się szybko, a najlepsze praktyki wciąż są tworzone. Nikt nie ma wszystkich odpowiedzi. Niezależnie od tego, czy zmagasz się z projektowaniem promptów, walczysz z potokami wyszukiwania, czy zastanawiasz się, jak oceniać wyniki na dużą skalę, problemy te lepiej rozwiązywać wspólnie.

Dzielmy się tym, czego się uczymy. Nie wygładzonymi wystąpieniami konferencyjnymi, ale tym, co dzieje się w samym środku procesu. Zepsutymi potokami, poprawkami promptów, które w końcu zadziałały, testami ewaluacyjnymi, które wyłapały błąd przed premierą. Ta szczegółowa, szczera wymiana doświadczeń to coś, co zmienia indywidualne eksperymenty w wspólny zasób wiedzy.

Kluczowy wniosek

Jeśli zaczynasz przygodę z rozwojem AI, poświęć mniej czasu na szukanie