AI miało sprawdzać zadania domowe 24h/7 i dawać natychmiastowy feedback. Genialny pomysł... który zaczął kosztować ~$300 dziennie 😱
Co poszło niezgodnie z planem? 🧵 ↓
Gdy z Adamem Gospodarczykiem ruszaliśmy z pierwszą edycją szkolenia AI Devs, postawiliśmy na automatyczną weryfikację zadań przez LLM.
Kursanci natychmiast dostawali feedback, czy rozwiązanie jest ok.
Nie musieli czekać na człowieka.
To spoko działało przy ~1000 uczestnikach.
Przyszła druga edycja. Dołączył do nas Mateusz Chrobok, a liczba kursantów podskoczyła do prawie 3x. I tutaj zaczęły się schody.
Zadania domowe były naprawdę trudne. Większość osób nie rozwiązywała ich za pierwszym razem, a dopiero po 10-20 próbach.
Każda próba = 1-2 wywołania API od OpenAI (ówcześnie modele GPT-3.5 oraz GPT-4).
Koszty?
➤ Proste zadania: $10-20 dziennie
➤ Trudne zadania: do $300 dziennie
Przy takiej skali portfel zaczynał boleć...
Podjąłem decyzję projektową w AI_Devs 3:
Muszę ograniczyć użycie AI w automatach do minimum i wrócić do "klasyki".
↳ wyrażenia regularne
↳ proste instrukcje warunkowe
↳ klasyczne SQL-e
W 90% przypadków wystarczało to do weryfikacji zadań.
Poruszam ten temat, bo AI niesamowicie ułatwia budowanie systemów weryfikujących dane. Może więc kusić, aby pójść na skróty i skorzystać z prostego prompta.
Jednak przy odpowiednio dużej skali (np. dziesiątki tysięcy wywołań dziennie) koszty potrafią być już znaczące.
Dzięki zmianie metody weryfikacji zadań zaoszczędziliśmy prawdopodobnie tysiące dolarów.
Trzeba jednak pamiętać o kilku ograniczeniach przy takim podejściu do tematu.
Wybór LLM-ów jako weryfikatorów nie był zwykłą fanaberią i podążaniem za modą, a podyktowany był tym, że ogromna część zadań musiałaby być weryfikowana przez ludzi.
Tam, gdzie potrzebna jest ludzka inteligencja, tam możemy wepchnąć... tą sztuczną.
Nowe wersje zadań zostały więc zbudowane w sposób warstwowy, czyli odpowiedź udzielana przez kursanta przechodziła przez sito warunków, wyrażeń regularnych, które klasyfikowały, czy wszystko jest OK.
Dopiero na ostatnim etapie (o ile była taka potrzeba), angażowany był LLM.
Czy znacząco zwiększyło to ilość pracy programistycznej do wykonania?
No tak — zdecydowanie.
Plusem tego podejścia było jednak zwiększenie wydajności rozwiązania i zmniejszenie kosztów jego utrzymania.
Nie oznacza to jednak, że LLM-y nie nadają się do pracy przy dużej liczbie użytkowników.
Po pierwsze, czasami rezygnacja z modeli językowych oznacza po prostu zatrudnienie ludzi - wbrew temu, co mówią fanatycy RegExów, nie wszystko da się ogarnąć prostym wyrażeniem ;)
Po drugie, zamiast korzystać z metody "albo LLM, albo klasyczne metody" warto wykorzystać podejście "Why not both?!".
Tam, gdzie LLM się sprawdza - tam go używaj.
Tam, gdzie jest za drogi, obniż jego koszty metodami klasycznymi.
Po trzecie, jeśli rezygnacja z LLMów nie jest możliwa, a szybkość działania nie jest kluczowa, rozważ wykorzystywanie modeli lokalnych.