Co się faktycznie dzieje, gdy wpinasz AI w aplikację (a nie tylko w demo)

Przy budowie aplikacji Unordered - generatora pomysłów na prezenty - najprostszym elementem było samo wywołanie modelu językowego. Wpisujesz prompt, dostajesz odpowiedź, gotowe. Najtrudniejsze okazało się wszystko dookoła tego jednego wywołania.

Model to jedna linijka. Reszta to inżynieria

Funkcja "zaproponuj prezent" w aplikacji musiała działać dla użytkownika, który:

• ma słaby internet albo żaden (aplikacja jest offline-first, z synchronizacją danych po odzyskaniu połączenia),
• oczekuje odpowiedzi w rozsądnym czasie, nie w 15 sekund,
• czasem poda za mało kontekstu, żeby propozycja miała ręce i nogi.

To zmienia AI z "wywołania API" w komponent architektury. Backend AI-owy siedzi za Firebase - uwierzytelnianie, baza danych i synchronizacja w czasie rzeczywistym trzymają stan aplikacji spójny niezależnie od tego, czy zapytanie do modelu akurat się powiodło. Infrastrukturę wokół tego (część logiki, cache'owanie) oparłem o Google Cloud Platform i Cloudflare Workers - nie dlatego, że to modny stack, ale dlatego, że pozwala trzymać logikę blisko użytkownika i nie płacić pełnej ceny za każde zapytanie do modelu.

Offline-first i AI to trudna para

Najciekawszy problem inżynieryjny: co pokazać użytkownikowi, kiedy prosi o propozycję prezentu, a telefon jest offline? Trzy uczciwe opcje: pokazać błąd, pokazać coś z cache'u, albo skolejkować zapytanie i zsynchronizować wynik później. Wybrałem trzecią - działanie offline-first oznacza, że akcja użytkownika nigdy nie ginie, nawet jeśli wynik przychodzi z opóźnieniem. To wymaga jednak zaprojektowania stanu aplikacji tak, żeby "propozycja w trakcie generowania" było normalnym, widocznym stanem UI, a nie wyjątkiem.

Czego nauczyłem się o granicach AI w produkcie

Model językowy nie wie, czy jego odpowiedź jest dobra - wie tylko, że jest prawdopodobna. W praktyce oznacza to, że każda funkcja oparta o LLM potrzebuje warstwy nad modelem: walidacji formatu odpowiedzi, sensownych wartości domyślnych, kiedy model się "rozmarzy", i iteracyjnego poprawiania promptów na podstawie realnych przypadków, a nie tylko tych, które wymyślisz przy biurku. Największe poprawki jakości odpowiedzi w Unordered nie wzięły się ze zmiany modelu - wzięły się z doprecyzowania promptu po tym, jak zobaczyłem, jakie dziwne propozycje generuje przy niepełnym kontekście od użytkownika.

Co z tego wynika dla wdrożeń AI w firmach

Jeśli ktoś przychodzi do mnie z pomysłem "dodajmy AI do naszej appki", pierwsze pytanie, jakie zadaję, brzmi: co się stanie, kiedy model odpowie źle, wolno albo wcale? Dopiero odpowiedź na to pytanie mówi, czy potrzebujesz jednego zapytania do API, czy całej warstwy wokół niego - kolejkowania, fallbacków, cache'u i monitoringu jakości odpowiedzi w czasie. Ta warstwa, a nie sam model, jest tym, za co realnie płaci się przy wdrożeniu AI.