Typowe błędy wdrożeń AI/ML
Czyli o grzechu "nie rozmawiania o potrzebach"
Wdrożenie AI - sensowne, wykonalne, mierzalne?
Grupa PL/AI i jej raport
Inspiracją dla dzisiejszego maila jest raport grupy PL/AI przy Ministerstwie Cyfryzacji. Gdyby Was ominęło to co za grupa - na początku roku MC powołało grupę “pionierów AI”, której celem jest “sprawić, że AI zostanie wykorzystana do istotnego ulepszenia funkcjonowania ważnych dla obywateli działań administracji, a w konsekwencji do poprawy życia Polaków” (cytat z komunikatu na stronach MC).
Kluczowy w ocenie ostatnio opublikowanego raportu tej grupy jest ten cytat z komunikatu o powołaniu zespołu:
"Kluczem w organizacji pracy zespołu jest wybranie takich pól działania, które są sensowne z perspektywy priorytetów całego systemu zarządzania państwem, interesu obywatelu i zwiększenia PKB, wykonalne – to znaczy możliwe technologicznie i finansowo oraz mierzalne – czyli dające się osadzić w konkretnym czasie i konkretnych metrykach efektywności."
Sensowne, wykonalne, mierzalne. Naprawdę dobre kryteria, nie nabijam się.
Ekspertów w grupach przy różnych ministerstwach trudno oceniać z efektów wdrożeń swoich pomysłów. Te wdrożenia często zależą od wsparcia politycznego, które bywa zmienne i od pogodzenia priorytetów różnych grup czy pionów tejże administracji, co nie zawsze jest łatwe. Natomiast ekspertów można oceniać pod kątem jakości tych pomysłów i powyższe kryteria świetnie się do tego nadają.
Problem tkwi w tym, że opublikowany dwa tygodnie temu raport ze szczegółami pierwszych dziesięciu projektów zawiera inicjatywy, które tych kryteriów nie spełniają. I gdyby pewnie bym to wszystko zignorował, gdyby nie to, że jak w soczewce powyższy raport skupia typowe błędy popełniane przez ekspertów IT przy wdrażaniu projektów AI/Uczenia maszynowego/Data science w branżach nietechnologicznych (prawo, opieka zdrowotna, FMCG, itd.)
To nie jest personalny atak na ekspertów - tylko pokazanie ślepych punktów przy tego typu projektach.
Omówię tylko te projekty, w których mam jakąkolwiek wiedzę - nie podejmuję się ocenić projektów prawnych (drodzy prawnicy wśród subskrybentów, chętnie usłyszę Waszą opinię).
Typowe błędy projektów AI/ML/Data science
Ignorowanie złożoności wdrożenia
Projekt Radiolog AI to pomysł udrożnienia mammografii poprzez zastosowanie AI. Ja nazywam to "mam fajny model, a Wy się zajmijcie wdrożeniem". To jest przykład ignorowania trudności we wdrożeniu (wśród problemów można wymienić brak wsparcia prawnego dla systemów wspomagania decyzji klinicznych, nierozwiązane kwestie odpowiedzialności, niejednorodność systemów przechowywania i zbierania danych, niejasny buy-in interesariuszy, konieczność silnego wsparcia nie tylko politycznego, ale także ze strony środowiska medycznego itd.).
Inną kwestią jest to, czy w procesie screeningu pod kątem raka piersi, radiolodzy stanowią wąskie gardło - wg ekspertów proces jest dobrze ustawiony, a problemem jest wykluczenie geograficzne, późna zgłaszalność i blokowanie wizyt.
Zbieranie danych w ciemno
Centralne repozytorium danych medycznych to inicjatywa, która krąży w środowisku akademickim co najmniej od 15 lat. Z punktu widzenia naukowców, więcej danych to lepiej. Ale to nie wystarczy - w projekcie nie ma słowa nt. czyszczenia i standaryzacji danych. Nie jestem też pewien, czy możliwa będzie komercjalizacja danych zbieranych w ciemno (wg GDPR "blanket agreement", czyli zgoda na przetwarzanie danych wrażliwych bez wyraźnie określonego celu, dostępna jest wyłącznie dla podmiotów badawczych). Porządnie zrobione studium wykonalności (które wzięłoby pod uwagę doświadczenia innych krajów, lokalne uwarunkowania i technologie) zajęłoby co najmniej rok. Dopiero wtedy można proponować takie rozwiązanie.
Brak weryfikacji, które kompetencje stanowią wąskie gardło
Nauka programowania nauczycieli informatyki jest dla mnie fascynującym przykładem ignorowania tego, jak AI już jest używany w edukacji. Oddolna adopcja AI w oświacie jest faktem. Dlaczego nie uczyć kompetencji, które oszczędzają nauczycielom czas? Druga sprawa - tworzenie oprogramowania bardzo się automatyzuje dzięki technologiom takim jak modele językowe. Dlaczego uczyć programowania, a nie rozwiązywania problemów przy pomocy programów tworzonych ad hoc przez AI? Dlaczego nie wykorzystywać AI do podniesienia jakości samych materiałów edukacyjnych, na przykład poprzez tworzenie interaktywnych symulacji praw fizyki?
Szukanie problemu dla rozwiązania
Na liście projektów jest inicjatywa tworzenia systemu opartego o modele językowe, który automatyzowałby dostęp do informacji publicznej wyszukując i automatycznie odpowiadając na pytanie na podstawie podobnych zapytań w przeszłości. Jaki tu mamy problem? Średniej wielkości miasto (Zduńska Wola) miało 92 takie zapytania w ciągu roku. Wrzucanie tam kosztownego w utworzeniu i utrzymaniu systemu, żeby obsłużyć półautomatycznie 2 zapytania na tydzień to klasyczny przykład rozwiązania w poszukiwaniu problemu.
Poprawienie powyższych projektów pod kątem ww. kryteriów (sensowność, mierzalność, wykonalność) wcale nie byłoby trudne. Alternatywami dla projektów z raportu byłyby:
repozytorium błędów medycznych (ponad 5 tys. postępowań prokuratorskich rocznie, jest co zbierać) - raz, że nie mamy a powinniśmy, a dwa przyda się do następnego projektu
system weryfikacji spójności i kompletności diagnoz - jak lekarz wpisuje w swój system dane z wywiadu (tekstem) to po kliknięciu "zapisz" odpowiednio sprofilowany LLM mógłby ocenić, czy nie trzeba zadać dodatkowego pytania i czy informacje są wewnętrznie spójne i to wszystko pod kątem zmniejszenia liczby błędów medycznych (i miałoby charakter edukacyjny)
nauka korzystania z AI (np. tworzenie interaktywnych symulacji konceptów w fizyce z użyciem Artifact/Sonnet, albo tworzenie dokumentacji wewnętrznej) dla nauczycieli - raporty z dobrych praktyk już są, nie trzeba zgadywać
zamiast RAG na dziurawej dokumentacji, poprosiłbym mailowo pracowników (w pilotażu, wybranej instytucji), żeby opisali procedury załatwiania nietypowych spraw przez klientów, wrzucił w LLMy, żeby uspójniły i wygenerowały spójną instrukcję - w dowolnym urzędzie są dziesiątki typów spraw do załatwienia, które nie wiadomo jak załatwić a klienci zadają te same pytania, ale na miejscu (trudno je wyłapać, bo nie są wysyłane mailowo - przykład: zapisywałem się ostatnio do szpitala na badania i na stronie szpitala jest instrukcja, że mam zabrać szczoteczkę do zębów, ale gdzie się zgłosić i w jakiej kolejności, to musiałem się dopytać przez telefon)
Grzech “nie rozmawiania”
Paul Graham, informatyk, pisarz, przedsiębiorca i inwestor powiedział kiedyś:
Inwestorzy mają listę znaków ostrzegawczych, kiedy oceniają firmę. Wysoko na niej jest prowadzenie firmy przez technoentuzjastów, którzy są zainteresowani rozwiązywaniem interesujących problemów technicznych, a nie uszczęśliwianiem użytkowników.
Jest wiele powodów, dla których 85% projektów AI kończy się klapą. Ale bardzo rzadko są to kwestie stricte techniczne. Zdecydowanie częściej jest to źle wybrany problem, niedoszacowane (pod kątem złożoności) wdrożenie, zarządzanie zmianą, ignorowanie kontekstu (na przykład tego, że dane wejściowe mogą zawierać błędy), szukanie problemu pod konkretną technologię, brak analizy potrzebnych kompetencji, brak zaadresowania prawdziwych potrzeb interesariuszy itd.
Wszystko się sprowadza do grzechu pierworodnego - unikania rozmów.
Raport grupy PL/AI postrzegam jako przykład tego grzechu. Bardzo bym się zdziwił, gdyby dobrze postawione pytania ekspertom np. medycznym (nie na zasadzie: “czy to się nadaje” ale na zasadzie “czy to rozwiązuje istotny problem”) nie zmusiłyby ekspertów grupy do mocnej zmiany zaproponowanych projektów. Sam ten projekt mammograficzny nie wytrzymuje konfrontacji z wyszukiwaniem w sieci.
Czytelnikami tego newslettera są w większości ludzie z firm nietechnologicznych (to do nich głównie piszę). Dla nich taka heurystyka: jeśli Wasz partner technologiczny nie zadaje Wam dobrych pytań o potrzeby, to rozmawiacie za mało.
Ciekawe niusy
Parę miesięcy temu ukazał się mocno techniczny artykuł nt. stabilności promptów pomiędzy kolejnymi wersjami modeli językowych. Badacze zaobserowali, że zoptymalizowane prompty pod konkretną wersję modelu po aktualizacji modelu zaczęły działać gorzej niż wcześniej około połowie badanych przypadków. A teoretycznie nowszy model, to większe “kompetencje”.
Dlatego też nie jestem fanem agresywnej optymalizacji instrukcji dla modeli językowych (zwanej dla niepoznaki “inżynierią promptów”).