Czy istnieje standardowa technika debugowania programów MCMC?

Debugowanie programów MCMC jest niezwykle trudne. Trudność wynika z kilku problemów, z których niektóre to:

(a) Cykliczny charakter algorytmu

Iteracyjnie rysujemy parametry na podstawie wszystkich innych parametrów. Dlatego jeśli implementacja nie działa poprawnie, trudno jest wyodrębnić błąd, ponieważ problemem może być dowolne miejsce w iteracyjnym samplerze.

(b) Prawidłowa odpowiedź nie musi być znana.

Nie mamy sposobu, aby stwierdzić, czy osiągnęliśmy zbieżność. Do pewnego stopnia można to złagodzić, testując kod na symulowanych danych.

W świetle powyższych problemów zastanawiałem się, czy istnieje standardowa technika, której można użyć do debugowania programów MCMC.

Edytować

Chciałem podzielić się podejściem do debugowania własnych programów. Ja oczywiście robię wszystkie rzeczy, o których wspomniał PeterR. Oprócz tych wykonuję następujące testy przy użyciu danych symulowanych:

1. Uruchom wszystkie parametry od prawdziwych wartości i sprawdź, czy próbnik nie odbiega zbyt daleko od prawdziwych wartości.

2. Mam flagi dla każdego parametru w iteracyjnym samplerze, który określa, czy rysuję ten parametr w iteracyjnym samplerze. Na przykład, jeśli flaga „gen_param1” jest ustawiona na true, wówczas rysuję „param1” z pełnego warunku w iteracyjnym samplerze. Jeśli ta wartość ma wartość false, wówczas parametr „param1” jest ustawiany na wartość true.

Po zakończeniu pisania samplera testuję program, stosując następujący przepis:

• Ustaw flagę generowania dla jednego parametru na wartość true, a wszystko inne na fałsz i oceń zbieżność w odniesieniu do wartości true.
• Ustaw flagę generowania dla innego parametru w połączeniu z pierwszym i ponownie oceń zbieżność.

Powyższe kroki były dla mnie niezwykle pomocne.

Standardowa praktyka programowania:

• podczas debugowania uruchom symulację ze stałymi źródłami losowości (tj. tym samym ziarnem), aby wszelkie zmiany były spowodowane zmianami kodu, a nie różnymi liczbami losowymi.
• wypróbuj swój kod na modelu (lub kilku modelach), dla których odpowiedź jest znana.
• stosuj dobre nawyki programistyczne, aby wprowadzać mniej błędów.
• bardzo mocno i długo zastanawiaj się nad odpowiedziami, które otrzymujesz, czy mają sens itp.

Życzę powodzenia i dużo kawy!

Mam przygnębiającą i niezbyt konkretną anegdotę, którą mogę tu podzielić. Spędziłem trochę czasu jako współpracownik statystycznego badacza MT. Jeśli chcesz zobaczyć naprawdę duży, złożony model, nie szukaj dalej.

Dla własnej rozrywki przeprowadzał mnie przez bootcamp NLP. Ogólnie jestem programistą, który żyje i umiera podczas testu jednostkowego i debuggera. Jako młoda osoba w Symbolics uderzyła mnie aforyzm: „programowanie debuguje pusty bufor edytora”. (Coś jak trening modelu perceptronu.)

Zapytałem go więc: „jak testujesz i debugujesz te rzeczy”. Odpowiedział: „Za pierwszym razem masz rację. Bardzo dokładnie to przemyślasz (w jego przypadku często na papierze) i bardzo ostrożnie kodujesz. Ponieważ, gdy popełnisz błąd, szanse na odizolowanie problemu są bardzo szczupły."

Dobre wskazówki w odpowiedzi PeterR; Nie mam żadnych dalszych wskazówek dotyczących faktycznego debugowania, ale znalazłem bardzo przydatną procedurę testowania, czy Twój kod może zawierać błąd. Jest to opisane w tym artykule:

http://pubs.amstat.org/doi/abs/10.1198/016214504000001132

Zasadniczo chodzi o dwie symulacje: jedną z nich jest MCMC do wnioskowania (przypuszczalnie) parametrów modelu. Drugi symulator po prostu próbkuje parametry z poprzedniego. Generują dane z parametrów obu symulatorów i obliczają statystykę testową porównując wspólne rozkłady parametrów i danych. Jeśli kod MCMC poprawnie pobiera parametry z tylnej części ciała, statystyki testowe będą miały rozkład N (0,1). Kod do obliczania statystyki testu jest dostępny.