Jak budować PoC aplikacji AI?

Jest wiele sposobów na wykorzystanie AI w aplikacjach. Od chatbotów, przez operacje na dokumentach aż do automatyzacji pewnych czynności przez agentów AI. Jednak zanim zaczniemy tę kosztowną inwestycję, warto sprawdzić, czy nasz pomysł jest możliwy do realizacji. Temu służy odpowiedni proces budowania PoC (proof of concept).

PoC aplikacji AI

PoC jest bardzo ważnym elementem budowania aplikacji korzystających z AI. Dlaczego? Bo aktualnie poruszamy się po nieznanych wodach, terra incognita. Dopiero odkrywamy co jest możliwe, kiedy AI się nadaje, a kiedy nie, najlepsze praktyki, wzorce i antywzorce. Już dużo udało się osiągnąć i mamy parę standardowych przykładów użycia np.: chatboty albo procesowanie dokumentów. Ale wszystko to zaczynało się też od PoC i pytania - Czy możemy sprawdzić jak zautomatyzować X?. W ciągu ostatnich dwóch lat pisałem sporo różnych PoC dla AI i ten proces jest bardzo powtarzalny. Najczęściej składa się z 5 kroków i 1 wstępnego:

Użyj ChatGPT
Zebranie wymagań
Zaprojektowanie prototypu
Zebranie danych
Implementacja
Zebranie wniosków

Każdy z etapów jest niezwykle ważny i ma wpływ na wynik całego eksperymentu oraz kolejne kroki.

Krok 0. Użyj ChatGPT

Zanim zaczniesz inwestować czas i pieniądze w budowanie PoC wykorzystaj ChatGPT. Przygotuj przykładowe dane, stwórz jakiś prompt i zobacz czy dostajesz jakieś w miarę rozsądne rezultaty. Jeśli dostajesz dobre wyniki - GRATULACJE. Jest duże prawdopodobieństwo, że twój pomysł da się zrealizować. Ale to dopiero początek drogi.

Krok 1. Zebranie wymagań

Nikogo nie zaskoczę, że jest to najważniejszy etap budowania każdego PoC. Bez poświęcenia odpowiedniej uwagi temu elementowi, może się okazać, że wyniki eksperymentu pójdą do kosza, bo ktoś zapomniał o małym elemencie.

W kontekście aplikacji AI trzeba rozważyć następujące kwestie:

Czy to jest aplikacja dla klienta wewnętrznego, czy zewnętrznego?
Jakie są wymagania/ograniczenia działu prawnego/bezpieczeństwa?
Czy możemy korzystać z modeli w chmurze, czy musi być self-hosted?
Czy są ograniczenia co do modeli, czy możemy używać wszystkich?
Jakiego typu to jest aplikacja: chat, procesowanie w tle, realtime?
Jaka jest domena rozwiązania?
To ma być osobny produkt/aplikacja, czy rozwinięcie aktualnej?
Jakie są ograniczenia kosztowe?

Każde z tych pytań jest istotne i może wywrócić cały pomysł na aplikacje. Najistotniejsze są te dotyczące kosztów, ograniczeń z działu prawnego/security oraz wymagań co do could/self-hosted. Małe nieporozumienie i możemy skończyć z czymś, czego nie da się zrobić. Bardzo często może się okazać, że to, co dało się zrobić w ChatGPT nie spełnia wymagań albo jest za drogie po implementacji w aplikacji.

Krok 2. Zaprojektowanie PoC

Jeśli mamy wszystkie wymagania, to można zaprojektować PoC. Natomiast tutaj nie rzucamy się do klawiatury, myszki i asystenta AI.

Na tym etapie zastanawiamy się co jest potrzebne do zbudowania PoC

Jedną z najważniejszych decyzji będzie wybór modelu. Na tym etapie warto wyznaczyć paru kandydatów. Musimy się oczywiście trzymać ograniczeń które mamy, bo co z tego, że test wykonamy na najmocniejszym modelu od OpenAI skoro docelowo to musi być self-hosted? Warto się też zastanowić czy musimy używać dużych modeli, czy też wystarczą mniejsze z jakimś fine-tunning albo klasyczne metody.

Warto też się rozejrzeć za innymi potrzebnymi elementami np.: baza grafowa, dodatkowe API, jakie zabezpieczenia są potrzebne itd.

Krok 3. Zbieranie danych

Skoro wiadomo, co trzeba zbudować, to należy zebrać dane. Jest niewiele przypadków gdy te dane nie będą potrzebne i raczej są to wyjątki od reguły. Od jakości zebranych danych zależy sukces PoC. Idealnie gdy podczas budowania PoC pracujemy na danych, które są zbliżone do produkcyjnych albo są faktycznie danymi z produkcji. Nie potrzebujemy tego dużo, ale wystarczającą próbkę, by przetestować pomysł np.: 2-3 różne dokumenty, które będziemy przetwarzać.

W przypadku, gdy będziemy testować fine-tunning to tych danych potrzebujemy dużo więcej. Do fine-tunningu potrzebujemy dane z etykietami podzielone na zbiór testowy i walidacyjny.

Warto też przeanalizować jak będzie wyglądała komunikacja użytkownika z funkcjonalnością i zastanowić się nad wiadomościami i scenariuszami rozmowy/interakcji.

Krok 4. Implementacja

Kod ma działać, a nie wyglądać na tym etapie

PoC rządzi się swoimi prawami. Tutaj kod ma działać, a nie wyglądać. PoC musi być zrobiony szybko. PoC ma sprawdzać konkretną rzecz/funkcjonalność i ignorować inne.

Czego nie robić podczas budowania PoC:

nie tworzymy całego designu, design systemu itd
nie skupiamy się na wszystkich zasadach DRY, KISS itd
nie analizujemy wszystkich edge case i różnych zabezpieczeń

PoC to ma być minimalizacja pracy i maksymalizacja efektu. Idealny prototyp to ten, który działa, a nie ten, który wygląda.

Krok 5. Zebranie wniosków

Najważniejszy punkt budowania PoC to znalezienie odpowiedzi na pytanie: Czy jesteśmy w stanie zbudować X z pomocą AI. I odpowiedź może nie być taka prosta. Przy zbieraniu wniosków z budowania PoC warto się skupić na kilku obszarach:

czy udało się osiągnąć zamierzony cel? tak/nie/częściowo
jakie były największe problemy przy budowaniu prototypu
czy musieliśmy zmieniać założenia co do PoC, bo coś zaczęło działać inaczej?
ile nas to kosztowało

Jeśli PoC jest sukcesem to warto również dodać informacje na temat tego jak to będzie działać na produkcji, ile to zajmie i co trzeba zrobić. Przy budowaniu takiego raportu jest parę rzeczy, na które warto zwrócić uwagę:

architektura docelowego rozwiązania - jakie modele, usługi, API, sposób komunikacji itd
jakie są zagrożenia i jak im zaradzić
ile zajmie porządna implementacja tego
ile będzie kosztować wdrożenie tego na produkcję
jaki będzie koszt używania tej funkcjonalności (estymacja kosztów korzystania z modeli - polecam mój kalkulator kosztów LLM)

Dopiero po zebraniu tych wszystkich informacji można zadecydować czy kontynuować projekt. Bo może się okazać, że pomimo działającego prototypu koszty na produkcji będą za duże i nie warto tego wdrażać w takiej postaci.