Ideas for experiments - master's thesis

[she3r]

We currently have two options:

1. To what extent does the interactive layer help in generating counterfactuals? This option involves collaborating with other people to conduct research using the Streamlit application. We need to come up with a meaningful study that we can assign to students, one that can yield useful results, considering that students have no interest in obtaining good counterfactuals—it is only right if the experiment does not end on our testers clicking random values on the screen.
2. Option without the participation of others - experiments for the ACFX API, where EBM is not the only blackbox available- Comparison for ACFX/ACFXLinear (ACFXCustom). I could potentially experiment using Friedman post-hoc statistical tests as you did, but this time comparing different input tools for acfx (classifier/optimizer). Similarly, an ablation study could be conducted, but for different acfx.
   Option 2 - that one I think I am ready to do without further brainstorming, but it is a worse option because the streamlit app has no use here.
   Option 1 - requires further consideration. Let's brainstorm below.

[she3r]

Cel: Próba wygenerowania realistycznych, minimalnych, prawdopodobnych i użytecznych kontrfaktów.

Dataset: w wielu popularnych pracach na temat generowania kontrfaktów daje się w zasadzie ten sam przykład - udzielanie kredytów - i całkiem słusznie, bo poszczególne cechy datasetu są faktycznie intuicyjne dla użytkowników. Proponowałbym „Give Me Some Credit” (https://www.kaggle.com/c/GiveMeSomeCredit). Pytanie - czy dostarczamy studentom dane, które sami wcześniej preprocesujemy? Czy sposób, w jaki studenci samodzielnie mogliby to zrobić jest istotny z punktu widzenia eksperymentu?
Zgaduje, że najlepiej by było, gdybyśmy sami preprocesowali dane i dali ten sam set danych studentom.

Metoda:

Poproś uczestników o wygenerowanie jak najlepszych kontrfaktów dla kilku przypadków (spreparowane przez nas) gdy chcemy doprowadzić do pozytywnej lub negatywnej decyzji o kredycie.
Uczestnicy oceniają kontrfakty według kilku kryteriów:

(Proximity) Realizm (czy kontrfakt wygląda jak prawdziwy przypadek?)

(Sparsity) Minimalność (czy zmiany są minimalne, ale skuteczne? Czy wiele wartości cech uległo zmianie?)

(Plausibility) Zgodność z przyczynowością (czy kontrfakt nie narusza zależności przyczynowych?)

Użyteczność (czy kontrfakt pomaga zrozumieć decyzję modelu?) - to może być śliskie i niekonkretne pytanie dla większości osób. Podejrzewam (choc moze nieslusznie), że w tej rubryce nie dostaniemy sensownych odpowiedzi, no chyba że ktoś naprawdę poważnie zabierze się za zadanie.

a. Analiza przez użytkowników wpływu różnych komponentów funkcji kosztu. Analiza udziału plausibility loss kontra brak tego komponentu. Moglibyśmy prosić studentów o samodzielną opinię na temat każdego z komponentu funkcji kosztu w formie słownej, a samodzielnie ewaluować już w oparciu o komponenty funkcji kosztu

b. Ewalaucja na wielu modelach, z dopuszczeniem zmiany parametrów uczenia. Podanie z uzasadnieniem, który blackbox daje najlepsze wyniki i z jakimi ustawieniami uczenia, w tym kroku zachęcamy do eksperymentów.

c. Próba zaproponowania własnego modelu DAG. Analiza porównawcza - co wg studenta powinno być inaczej względem tego, co wygenerował DirectLINGAM.

• tutaj chcielibyśmy, aby użytkownik nie próbował podmieniać DAGa tak, żeby mu wyszło lepiej, tylko żeby coś zaproponował z uzasadnieniem, a następnie ewaluował swój pomysł i dał znać, czy jego pomysł zadziałał lepiej niż automatyczny DAG.

d. Ewaluacja z użyciem różnych parametrów optymalizacji bayesowskiej (Number of initial points for Bayesian Optimization, Number of iterations for Bayesian Optimization) - może tutaj wystarczy, że każdy badany tylko napisze, jakie wartości sobie ustawił?

Całość moglibyśmy ująć w jupyter notebook, z którego możnaby potem w łatwy sposób zebrać numeryczne wyniki do agregacji oraz przeanalizować odpowiedzi w formie tekstowej.

Wydaje się, że przed rozpoczęciem eksperymentu przydałoby się opowiedzieć studentom o samej metodzie - jak działa, co uwzględnia?
Będziemy w stanie im podrzucić manuskrypt?

[sbobek]

Jeśli chodzi o postać eksperymentu, to zaproponowane przez pana pomysły są super, ale jednak wymagałyby dużej skali, a tej chyba nie uda sie osiągnąć.
User study powinno mieć określone cele i zacząłbym od tego.

1.) Czy Jakość kontrfaktów generowanych przez ACFX jest lepasza/gorsza/neutralna od kontrfaktów z metod dostępnych na rynku
2.) Czy graf zależności (liniowych/warunkowych) wpływa na postrzegana jakość wyjaśnień (i.e. czy istnienie tego grafu użytkownicy oceniają in plus, czy jest on np. całkowicie obojętmy, lub wręcz wadzi)
3.) Czy graf zależności wpływa w praktyce na możliwosć wygenerowania lepszych (bardziej spójnych z wiedzą ekspercją) kontrfaktów -- trochę podobne do 2.) ale tutaj sprawdzamy czy to że użytkonik ma dostęp do KG pozwala mu w praktyce osiagnać lepsze wyniki w obrębie np, plausability
4.) Jak zaprojektowane interakcje wpływaja na jakość wyjaśnień (tutaj chodziłoby o część streamlit i bardziej UX-owy wątek) - to jest coś co można pominąć, ale tutaj może być ciekawie, jeśli np pozowli sie userowi ocenić na skali likerta każdy z kroków w aplikacji i zobaczyć czy są jakieś korelacje z jakością kontrfaktów tego usera, ewentualnie czy któryś z kroków jest wyjatkowo problematyczny.

W pytaniach 1,2 można użyć wyników precomputed - po prostu pokazane użytkownikowi w porównaniu do jakichś inncy CF wygenerowancyh DICE, CEM itp. coś jak tutaj: https://forms.office.com/Pages/ResponsePage.aspx?id=6yYO676_0keekOvSQm286-5Obsnzlg9LiO_-ZTEPX1VUOFVYU0dRU1Q0TVMzSjlKS1lESk4yS1Y3Vy4u
W pytaniach 3,4, warto byloby dac możliwość pobawienia sie aplikacją (wrzuciłem ją na streamlit community: https://acfx-dashboard.streamlit.app/ i pięknie działa -- gratulacje!)

Na jakim datasecie testować aplikację.
I tutaj mamy kilka opcji.
Najprostsza to po prostu jakis dataset który każdy student po kursie z ML zna -- np. iris, titanic, wine quality itp.
Druga opcja -- ambiteniejsza, to dataset który może nie jest oklepany, ale za to może dotyczyć społeczności w której będzie tesotwany, np
1.) Predict Students' Dropout and Academic Success: https://archive.ics.uci.edu/dataset/697/predict%2Bstudents%2Bdropout%2Band%2Bacademic%2Bsuccess
2.) Albo jeszcze ambitniej: https://webfs.oecd.org/pisa2022/index.html -- Pytanie na ile ten dataset będzie mógł być przetworzony przez streamlit hostowany w wesji community.
3.) Opcja z nieco bardziej lokalnym datasetem, to analiza danych z eurostatu - serwis ma całkiem używalne API i można znaleźć sporo danych społecznych i próbować je wykorzystać do robienia modelu/kontrfaktów -- swego czasu robiliśmy coś takiego do analizy wpływu COVID na turystykę w krajach europejskich. Tutaj musiałbym zasięgnąć pomocy moich znajomych socjologów , ale to nie powinno być problematyczne i być może do 20 osób udałoby mi się zebrać.

Jeśli chodzi o wyniki ilośćiowe (tj. porównanie pod względem sparsity, proximity itp -- robiłem już coś takiego do tego papieru głównego i dodałem je też tutaj do repo.

supplementary-materials-evaluation-raw-results.csv

[she3r]

W kwestii datasetu,
Wydaje się w takim razie, że najłatwiej byłoby wgrać do aplikacji możliwość wyboru eksperymentalnego datasetu jako opcja wyboru. Teraz pytanie:
W kodzie benchmarku metoda dostarcza dataset do blackboxa EBM bez żadnego preprocessingu. Taka sytuacja może być niedopuszczalna dla reszty blackboxów do wyboru jakie wskazałem w aplikacji streamlitowej, z tego powodu, że w przypadku EBM z interpretML można narzucić typy kolumn => można mieć kolumny, które za pomocą liczb całkowitych wskazują kategorie. Jest nam to potrzebne, ponieważ musimy zachować kompatybilność z tym, jak generujemy kandydatów na kontrfakty w optunie:
kwargs[key] = trial.suggest_categorical(key, list(range(int(bounds[key][0]), int(bounds[key][1]) + 1))) - w przedziałach dopuszczalności dla cech wskazujemy przedział również dla cech kategorycznych.

Obecna implementacja nie pozwala na to, by na modelach innych niż EBM stosowano dataset, który posiada w kolumnach niebędących targetem takich, które nie mają charakteru ciągłego (continous). Co więcej, wśród wbudowanych do aplikacji datasetów w tym momencie nie wskazuje takich, które miałyby cechy inne niż ciągłe (iris,wine,breast cancer), natomiast ciągle dajemy możliwość wgrania swojego pliku z danymi z .csv.
Problem mogłoby się dać rozwiązać dla logistycznej regresji, widzę że jest implementacja w interpret.glassbox, która daje możliwość narzucenia typu kolumn:
https://interpret.ml/docs/python/api/LogisticRegression.html
Pozostałe blackboxy jakie wykorzystałem (z sklearnu) to: RandomForestClassifier, KNeighborsClassifier. W przypadku tych modeli wykorzystanie metody z danymi kategorycznymi na wejściu nie będzie miało sensu - czy wobec tego powinienem je usunąć i znaleźć jakieś alternatywy?

W każdym razie,

1. Aplikacja będzie działać najpełniej dla wersji z EBM
2. Można zrobić tak, żeby działała na tym samym stopniu pełności dla LogisticRegression
3. Pozostałe blackboxy działają dla datasetów z cechami w pełni ciągłymi (np. datasety wbudowane iris, wine, breast cancer)
4. Aplikacja nie działa poprawnie z danymi kategorycznymi dla innych modeli - obecnie w pierwszej zakładce, gdzie deklaruje się typy kolumn, gdy inicjujemy inny blackbox niż EBM to te informacje są ignorowane w zakresie fitowania modelu
5. Aplikacja nie dokonuje preprocessingu sama, trzeba jej poprawne dane dostarczyć (np. niedopuszczalne są kolumny stringowe przy generowaniu pbounds za pomocą suwaków)

[she3r]

W kwestii formularza do wypełnienia przez badanych, rozumiem że to bardziej deklaratywny formularz, gdzie badani oceniają różne komponenty/jakości/problemy w skali aniżeli coś bardziej w stronę interaktywnego notebooka, w którym wypisuje się częściowe wyniki swoich własnych eksperymentów