Model AI to 5% systemu

Rzadko dlatego, że model jest zły. Utykają, bo nikt z góry nie ustalił, co znaczy „działa”, więc pilotaż nie ma mety; bo dane, dzięki którym demo wyglądało dobrze, w tej postaci na produkcji nie istnieją; bo opóźnienia albo koszt tokenów przy prawdziwym wolumenie okazują się nie do udźwignięcia; albo bo nikt nigdy nie wskazał zespołu, który przejmie system po starcie. Wszystkie cztery to decyzje, a nie ograniczenia techniczne – i wszystkie taniej naprawić przed budową niż po niej.

Wszystko wokół modelu, bo tam jest prawdziwa praca: pipeline’y danych, które go zasilają, warstwa wyszukiwania, ewaluacje potwierdzające, że po każdej zmianie model wciąż zachowuje się jak trzeba, budżet opóźnień i kosztów, w którym musi się zmieścić, i monitoring, który da znać, kiedy zacznie się mylić. Sam model też zbudujemy, jeśli jest potrzebny – i powiemy wprost, jeśli nie jest.

Koszty są dwa, a zwykle budżetuje się tylko pierwszy. Budowa to od kilku tygodni do kilku miesięcy pracy małego zespołu seniorów. Koszt utrzymania – inferencja, wyszukiwanie, monitoring i czas inżynierów, którzy pilnują jakości – płacisz tak długo, jak funkcja istnieje, a przy prawdziwym wolumenie często przewyższa on koszt budowy. Liczymy oba, zanim się zobowiążesz, bo funkcja, którą stać Cię zbudować, ale nie utrzymać, to gorzej niż żadna.

Zacznij od wyszukiwania. RAG pasuje do typowego przypadku: odpowiedzi muszą opierać się na Twoich dokumentach i zmieniać razem z nimi. Jest tańszy, szybciej się go dostraja i dużo łatwiej go audytować, bo widać, z którego źródła wzięła się odpowiedź. Fine-tuning ma sens, gdy potrzebujesz stałego formatu, tonu albo słownictwa branżowego, którego prompting nie utrzyma – i zwykle szlifuje się nim system, w którym wyszukiwanie już działa, a nie zastępuje się nim wyszukiwania.

Stałym zestawem testowym: prawdziwe dane wejściowe, oczekiwane zachowania i uzgodniony z Tobą sposób oceny, uruchamianym jako testy regresji przy każdej zmianie – promptu, wersji modelu, indeksu wyszukiwania. Nie chodzi o idealny wynik, tylko o to, żeby w kilka minut wiedzieć, że jakość się zmieniła i co to spowodowało. Bez tego zespoły zmieniają prompty na wyczucie, a o regresjach dowiadują się z reklamacji klientów.

Prawie na pewno nie. Trenowanie modelu od zera uzasadniają tylko własne dane w skali, jaką ma bardzo niewiele firm – a do tego skazuje Cię na utrzymywanie czegoś, co modele komercyjne i tak wyprzedzą. Decyzja, która naprawdę ma znaczenie, brzmi: które części systemu mogą zależeć od zewnętrznego dostawcy i co się stanie, gdy wycofa on wersję. Pod ten scenariusz projektujemy od początku.

MLOps to wdrażanie, wersjonowanie, monitorowanie i wycofywanie modeli tak, jak dojrzałe zespoły od dawna robią to ze zwykłym oprogramowaniem. Potrzebujesz go w chwili, gdy model wpływa na decyzję, którą może zakwestionować klient albo regulator. Wcześniej to zbędny narzut; później jego brak sprawia, że nikt nie umie wyjaśnić, co zmieniło się w zeszłym tygodniu.

Monitorować dane wejściowe, nie tylko wyniki. Dryf zwykle widać w rozkładzie danych, zanim pojawi się w metryce, na którą ktokolwiek patrzy, więc ustawiamy alerty na jedno i drugie, regularnie uruchamiamy zestaw ewaluacyjny i trzymamy poprzednią wersję modelu w gotowości – wtedy rollback to decyzja, a nie projekt. Spadek jakości jest normalny i da się nad nim zapanować. Porażką jest dać się nim zaskoczyć.