هشدارهای زمان اجرا و مشکلات همگرایی

یک مزیت بزرگ از استن این است که از طیف وسیعی از تشخیص ها استفاده می کند تا به شما اجازه دهد بسیاری از مشکلات بالقوه را در مورد مدل خود مشاهده کنید - استن محافظه کار است و هشدارهایی را برای هرگونه مشکوک به وجود می آورد. در اینجا ما انواع هشدارها و نکات را طی می کنیم تا به شما در تشخیص و حل مشکلات مدل سازی اساسی کمک کنیم. اگر در تشخیص و حل مشکلات مربوط به مدل خودتان یا اگر در درک یا استفاده از برخی از نکات مشکل دارید ، نگران نباشید ، نگران نباشید ، خوشحال می شوید که از گفتمان استن بپرسید ، ما سعی خواهیم کرد کمک کنیم!

حل مسائل مربوط به مدل سازی به طور کلی سخت است و نیاز به درک برخی از تئوری های احتمالی و همیلتون مونت کارلو دارد ، به درک اصول آمار بیزی و مدل سازی برای منابع کلی تر مراجعه کنید.

برای راهنمایی در مورد هشدارهایی که هنگام تهیه مدل رخ می دهد ، به راهنمای کاربر STAN در مورد خطاها و هشدارها مراجعه کنید.

چه موقع هشدارها را می توان نادیده گرفت

در بیشتر موارد ، هشدارها در واقع نشان دهنده مشکلات مهم مدل شما است. این بدان معنا نیست که هر بار که هشدار می دهید تخمین های مدل بی معنی است ، اما وقتی هشدارها را می بینید ، نباید به برآوردهای خود اعتماد کنید بدون اینکه ابتدا بفهمید هشدارها به چه معنی است.

با این حال ، در مراحل اولیه یک گردش کار مدل سازی ، ما اغلب نیازی به استنتاج کاملاً قابل اعتماد نداریم ، و یک خلفی تقریباً صحیح می تواند کافی باشد تا به ما اجازه دهیم که آیا مدل با استفاده از چک های پیش بینی خلفی معقول است یا خیر. اگر هشدارها به ندرت اتفاق بیفتد یا تشخیص ها فقط تا حدودی بالاتر از آستانه توصیه شده باشند ، اغلب قبل از بررسی هشدارها به تفصیل ، برخی از چک های بهداشتی خشن را انجام می دهد. این می تواند به جلوگیری از سرمایه گذاری زیادی در مورد اشکال زدایی مدلی که به هر حال به دلیل عدم تناسب با داده ها یا سایر مشکلات مفهومی دور ریخته می شود ، کمک کند.

انواع هشدارها

• انتقال واگرا پس از گرم شدن
• استثنائاتی که هنگام محاسبه تراکم هدف و شیب آن پرتاب می شود (پیشنهاد همیلتون رد شد)
• کلاه
• فله- و دم
• حداکثر treedepth
• BFMI کم

انتقال واگرا پس از گرم شدن

مثال:

استن با شبیه سازی تکامل یک سیستم همیلتونیا ، از همیلتون مونت کارلو (HMC) برای کشف توزیع هدف - خلفی تعریف شده توسط یک برنامه STAN + داده - استفاده می کند. به منظور تقریب راه حل دقیق پویایی همیلتون ، ما باید یک اندازه پله را انتخاب کنیم که هر بار که سیستم را به جلو تکامل می دهیم ، چقدر حرکت می کنیم. اندازه مرحله وضوح نمونه را کنترل می کند.

برای مشکلات سخت ، انحنای خلفی می تواند بسیار متفاوت باشد و ویژگی های توزیع هدف وجود دارد که برای این وضوح بسیار کوچک است. به عنوان مثال ، اگر چگالی خلفی ورود به سیستم دارای مشتق مداوم در همه جا نباشد ، واگرایی به احتمال زیاد وجود دارد. در نتیجه نمونه این ویژگی ها را از دست می دهد و برآوردهای مغرضانه را باز می گرداند. خوشبختانه ، این عدم تطابق مقیاس به عنوان واگرایی که یک تشخیص عملی را ارائه می دهد ، تجلی می یابد.

در صورت تمایل به استنتاج کاملاً قابل اعتماد ، حتی تعداد کمی از واگرایی پس از گرم کردن نمی توان با خیال راحت نادیده گرفت. اما اگر فقط تعداد کمی از واگرایی دریافت می کنید و مقادیر خوب RHAT و ESS را بدست می آورید ، خلفی حاصل اغلب به اندازه کافی خوب است که به جلو حرکت کند. همچنین مواردی وجود دارد که تعداد کمی از واگرایی بدون هیچ الگویی در مکان های آنها می تواند مهم باشد که بی اهمیت باشد ، اما بدون بررسی دقیق مدل نمی توان با اطمینان فرض کرد.

مطالعه بیشتر در مورد واگرایی: - بحران هویت - بحث در مورد دلایل واگرایی ، تشخیص و درمان.* واگرایی های Taming در مدل های Stan یک شهود کمتر ریاضی اما امیدوارم در دسترس تر در مورد انتقال واگرا باشد.* مقدمه ای مفهومی با همیلتون مونت کارلو

استثنائاتی که وقتی پیشنهاد همیلتون را رد کرد ، پرتاب شد

مثال ها:

هشدار اول نشان می دهد که انحراف استاندارد (پارامتر مقیاس) توزیع عادی (در خط 24 در برنامه STAN) 0 است ، اما برای محاسبه مقدار عملکرد چگالی باید برای STAN مثبت باشد.

پیام دوم نشان می دهد که شیب هدف (همانطور که توسط تفاوت اتوماتیک استن محاسبه می شود) بی نهایت است و نشانگر مشکلات عددی در جایی در مدل است اما متأسفانه بدون اطلاعات واضح در مورد دقیقاً کجا.

انواع دیگر این هشدارها وجود دارد. پیامی مانند این لزوماً نشان نمی دهد که مشکلی در مدل شما وجود ندارد ، زیرا ممکن است که حتی در یک مدل صحیح مشخص و به طور کلی با رفتار خوب ، نادرستی عددی گاه به گاه دیده می شود ، به خصوص در هنگام گرم کردن (به عنوان مثال ، پارامتر مقیاس با صفر پایین ترمحدود هنوز هم می تواند از نظر عددی قابل تشخیص باشد). اگر چنین هشدارهایی فقط قبل از اولین تکرار اتفاق بیفتد ، نشانه این است که اولیه سازی مشکل ساز است. در این حالت تغییر مقادیر اولیه می تواند کمک کند اما در صورت عدم هشدارهای بیشتر لازم نیست. هشدارها پس از چند تکرار اول ممکن است نشان دهنده اشکالات یا موضوعات عددی در مدل باشد و اگر استثنائات بارها اتفاق بیفتد ، تحقیقات قطعاً ضروری است.

خواندن بیشتر در مورد دقت عددی قالب نقطه شناور مورد استفاده در محاسبه: - یادداشت های سخنرانی توسط Geyer (2020) "STAT 3701 یادداشت های سخنرانی: حساب های رایانه ای" نمونه هایی از کد را در RAT ارائه می دهد که رایج ترین موضوعات در حسابی با نقطه شناور استگردان ناخواسته به مرز محدودیت.

تشخیص همگرایی R-HAT (گاهی اوقات RHAT) تخمین های بین و درون زنجیره ای را برای پارامترهای مدل و سایر مقادیر مورد علاقه یکپارچه مقایسه می کند. اگر زنجیرها به خوبی مخلوط نشده اند (به طوری که تخمین های بین و درون زنجیره ای موافق نیستند) ، R-HAT بزرگتر از 1 استکلاه کمتر از 1. 01 است. در گردش کار اولیه ، R-HAT زیر 1. 1 اغلب کافی است.

Stan گزارش R-HAT را به عنوان حداکثر رتبه بندی شده رتبه بندی-HAT-HAT و رتبه بندی شده نرمال شده با-SPLIT-R-HAT ، که برای توزیع های ضخیم کار می کند و نسبت به تفاوت در مقیاس نیز حساس است.

High R-Hat به این معنی است که زنجیرها به خوبی مخلوط نشده اند و بنابراین دلیل خوبی برای فکر کردن در مورد آنها وجود ندارد ، زیرا آنها کاملاً نماینده خلفی هستند.

هنگامی که انتقال های واگرا در مدل وجود دارد ، High R-HAT اغلب فقط یکی دیگر از علائم هندسه مشکل ساز است که باعث واگرایی می شود. اگر هشدارهای "حداکثر treedipth" در کنار R-HAT بالا وجود داشته باشد ، معمولاً یک هندسه مشکل ساز خلفی را نشان می دهد که به سختی می توان از آن عبور کرد و اغلب در تلاش برای حل واگرایی ، یک عارضه جانبی در تنظیم Adapt_delta است. کلاه R بالا و بدون هشدارهای دیگر معمولاً با خلفی هایی که دارای چندین حالت جدا شده برای پارامترهای متخلف هستند ، همراه است ، اما همچنین می تواند در خلفی های غیرمعمول با هندسه دشوار ، در صورت همبستگی بالا ، یا در خلفی های نزدیک به نامناسب ایجاد شود.

R-HAT و ESS (به زیر مراجعه کنید) خلاصه های سریع مفید هستند ، اما برای نتایج نهایی ، بررسی خطای استاندارد مونت کارلو برای مقادیر مورد علاقه مفید است و آن را با دانش دامنه از دقت لازم و در صورت مقایسه مقایسه کنید. کم است ، سپس زنجیرهای طولانی تر را اجرا کنید تا نمونه های بیشتری از خلفی بدست آورید.

مطالعه بیشتر در مورد R-HAT:

فله و دم

تقریباً صحبت می کند ، اندازه نمونه مؤثر (ESS) مقدار مورد علاقه ، تعداد قرعه کشی مستقل را شامل می شود که تعداد اطلاعات مشابه نمونه وابسته به دست آمده توسط الگوریتم MCMC را نشان می دهد. هرچه ESS بالاتر باشد بهتر است. استن از تنظیم R-HAT برای استفاده از اطلاعات درون و بین زنجیره ای در محاسبه ESS استفاده می کند. به عنوان مثال ، در صورت توزیع چند حالته با حالت های جدا شده ، این منجر به تخمین ESS می شود که نزدیک به تعداد حالت های مجزا است که یافت می شود.

Bulk-ESS refers to the effective sample size based on the rank normalized draws. This does not directly compute the ESS relevant for computing the mean of the parameter, but instead computes a quantity that is well defined even if the chains do not have finite mean or variance. Overall bulk-ESS estimates the sampling efficiency for location summaries such as mean and median. Often smaller ESS would be sufficient for the desired estimation accuracy, but the estimation of ESS and convergence diagnostics themselves require higher ESS. For final results, we recommend requiring that the bulk-ESS is greater than 100 times the number of chains. For example, when ruing four chains, this corresponds to having a rank-normalized effective sample size of at least 400. In early workflow, ESS >20 اغلب کافی است.

Tail-ESS computes the minimum of the effective sample sizes (ESS) of the 5% and 95% quantiles. Tail-ESS can help diagnose problems due to different scales of the chains and slow mixing in the tails. If one or more chains has no draws below the 5% or above 95% quantiles computed from the all draws, there will be no direct way to assess that those chains are not completely failing, and thus NA (not available) can be reported for tail-ESS. >[Name = Paul] ما اخیراً این خط مشی را در خلفی تغییر دادیم زیرا ثابت در زنجیره ای بیش از حد محافظه کار بود و معلوم شد که NA را به OFT برگرداند

در بیشتر موارد ، ESS فله کم و Ess با HAT R-HAT همراه است و کلیه توصیه های مربوط به RHAT بزرگ اغلب در برخورد با ESS کم مفید است.

R-HAT و ESS خلاصه های سریع مفید هستند ، اما برای نتایج نهایی ، می توان خطای استاندارد مونت کارلو را برای مقادیر مورد علاقه نیز بررسی کرد و آن را با دانش دامنه از دقت مورد نیاز مقایسه کرد و در صورت لزوم از خلفی نمونه برداری کردبشر

خواندن بیشتر در ESS:

حداکثر treedepth

هشدارها در مورد ضربه زدن به حداکثر حداکثر ، به اندازه سایر هشدارها جدی نیست. در حالی که انتقال واگرا ، R-HAT بالا و ESS کم نگرانی اعتبار است ، اما ضربه زدن به حداکثر Treedipt یک نگرانی کارآیی است. پیکربندی No-U-Tu-Sampler (نوع HMC مورد استفاده Stan) شامل قرار دادن کلاه بر روی تعداد مراحل شبیه سازی است که در طول هر تکرار ارزیابی می کند (برای جزئیات بیشتر در این مورد ، فصل نمونه برداری همیلتونیان مونت کارلو را در کتابچه راهنمای STAN مشاهده کنید)بشراین از طریق یک پارامتر حداکثر عمق درخت MAX_TREEDEPTH کنترل می شود که در آن حداکثر تعداد مراحل 2^max_treedepth است. با رسیدن به حداکثر عمق درخت مجاز ، نشان می دهد که آجیل ممکن است زودرس خاتمه یابد تا از زمان اجرای بیش از حد طولانی جلوگیری شود.

اگر این تنها هشداری است که شما دریافت می کنید و تشخیص ESS و R-HAT شما خوب است ، احتمالاً نادیده گرفتن این هشدار بی خطر است ، اما پیدا کردن علت اصلی می تواند به یک مدل کارآمدتر منجر شود.

ما به طور کلی توصیه نمی کنیم حداکثر Treedepth. در عمل ، حداکثر حداکثر Treedepth که به دست آمده می تواند نشانه ای از اشتباه مدل باشد ، و افزایش حداکثر Treedepth می تواند منجر به این شود که فقط بیشتر طول بکشد تا مدلی را که نمی خواهید متناسب باشد ، قرار دهد.

BFMI کم

مثال:

ممکن است هشدار دهنده ای را ببینید که می گوید تعدادی از زنجیرها دارای BFMI تخمین زده شده بودند که خیلی کم بود. این بدان معنی است که مرحله سازگاری زنجیرهای مارکوف به خوبی ظاهر نمی شود یا خلفی دارای دمهای ضخیم است که در شبیه سازی به خوبی مورد کاوش قرار نگرفته است. مانند سایر هشدارها ، اگر مقدار BFMI فقط کمی پایین تر از آستانه باشد ، خلفی احتمالاً برای بررسی های سلامتری مناسب است اما احتمالاً هنوز هم برای استنتاج نهایی خوب نیست.

توضیحات فنی مختصری از تشخیص را می توان در بخش 6. 1 مقدمه مفهومی برای همیلتون مونت کارلو یافت و یک حساب کاربری کامل در https://arxiv.org/abs/1604. 00695 آورده شده است.

تشخیص و حل مشکلات

تشخیص مشکلات به عنوان بخشی از گردش کار بزرگتر از ساخت مدل ، آزمایش و انتقاد/ارزیابی بهتر تصور می شود. بلوک های ساختمانی چنین گردش کار در مقاله گردش کار بیزی ما ارائه شده است.

برخی از رویکردها که می تواند برای اکثر انواع هشدارها مفید باشد. این یک راهنمای قطعی نیست و نمی تواند باشد - هر مورد به روش خاص خود مشکل ساز است و هیچ رویکردی وجود ندارد که همیشه کار کند.

اگر از Stan از طریق یک بسته یا رابط سطح بالاتر مانند RSTANARM یا BRMS استفاده می کنید ، گزینه های شما محدودتر است ، اما توصیه های کلی زیر هنوز هم اعمال می شود. علاوه بر این ممکن است بخواهید با مستندات بسته یا کد STAN اساسی مشورت کنید تا درک خوبی در مورد آنچه در زیر کاپوت اتفاق می افتد بدست آورید.

مدل خود را کاهش دهید. کوچکترین / کمترین مدل پیچیده و یک مجموعه داده (ترجیحاً شبیه سازی شده) را پیدا کنید که مشکلات را نشان می دهد. فقط بعد از حل و فصل شما پیچیدگی بیشتری را اضافه کنید یا حداقل همه موارد را با مدل کوچک درک کنید. اگر مدل شما دارای چندین مؤلفه است (به عنوان مثال ، یک پیش بینی کننده خطی برای پارامترها در یک مدل ODE) ، مدل های کوچک را بسازید و تست کنید که در آن هر یک از مؤلفه ها جدا هستند (برای مثال ، یک مدل خطی جداگانه و مدل ODE جداگانه با پارامترهای ثابت). برای رابط های سطح بالاتر ، این معمولاً به معنای از بین بردن شرایط پیش بینی کننده است.

• Vignette گردش کار اجرای مدل کوچک از بسته SBC نمونه ای از ساخت یک مدل بزرگتر از اجزای ساده تر مرحله به مرحله را نشان می دهد.

داده های خود را کاهش دهید (اگر بزرگ باشد). تشخیص مدلی که مدت زمان زیادی برای جا دادن و پارامترهای زیادی دارد ، دشوار است ، بنابراین کار با زیر مجموعه مناسب از داده ها می تواند روند را سرعت بخشد. با این حال ، این یک شمشیر دو لبه است زیرا برخی از مشکلات می تواند با نداشتن داده های کافی ایجاد شود ، به ویژه متناسب بودن دامنه ها/رهگیری های مختلف برای کمتر از 3 دسته می تواند در صورت ضعیف بودن Priors مشکل ساز باشد.

• شما اغلب می توانید مدل و داده ها را همزمان کاهش دهید - به عنوان مثالاگر مدل خطی شما دارای پیش بینی های مختلفی است ، می توانید داده ها را فیلتر کنید تا فقط ردیف هایی با مقدار خاصی از یک پیش بینی کننده طبقه بندی (یا محدوده باریک از یک پیش بینی کننده مداوم) داشته باشند و سپس پیش بینی کننده را از مدل خارج کنید.

از مقدمات قوی تر استفاده کنید. غالباً محاسبات همگرا آهسته است زیرا در تمام فضای پارامتر در حال حرکت است. یک قبلی معقول می تواند با کاهش دامنه عملکرد ، کارها را کنترل کند. از جمله یک قبلی معقول همیشه مشکلات محاسبات را حل نمی کند ، اما اغلب از بدترین مشکلات خلاص می شود.

Visualisations: در R برخی از توطئه های بسیار مفید توسط بسته Bayesplot (به عنوان مثال MCMC_PARCOORD ، MCMC_PAIRS ، MCMC_RANK_OVERLAY) و بسته Shinystan (که یک رابط کاربری گرافیکی تعاملی را فراهم می کند) ارائه شده است. در پایتون و جولیا بسته های Arviz و Arviz. jl عملکرد مشابهی را ارائه می دهند. تجسم متداول ، طرح جفت است که در آن مدل های خوب رفتار شده مجموعه ای از "حباب های گاوسی" را نشان می دهند در حالی که هر الگوی دیگری می تواند مشکلات را نشان دهد. بیشتر خواندن:

اطمینان حاصل کنید که تمام پارامترهای مدل شما به خوبی توسط مدل مطلع هستند. موقعیت های مشکل ساز معمولی زمانی است که تغییرات بزرگ در پارامترها می تواند به چگالی خلفی تقریباً یکسان (به عنوان مثال جداسازی کامل در یک رگرسیون لجستیک) و چندوجهی (بیشینه های محلی چندگانه توزیع های خلفی) منجر شود. بیشتر خواندن:

اگر محاسبات در مرحله گرم کردن بسیار کند باشد، گاهی اوقات می توان با انتخاب مقادیر اولیه معقول تر به جای استفاده از پیش فرض های Stan، که می تواند به قدری پراکنده باشد که برای مدل هایی با هندسه پیچیده، زنجیره ها در نواحی بی اهمیت فضای پارامتر گیر کنند، این مشکل را برطرف کرد..

به طور خاص برای واگرایی / حداکثر عمق درخت:

• بررسی کنید که چگالی خلفی ورود به سیستم و مشتقات آن در همه جا پیوسته باشند. ناپایداری ها و نادرستی های عددی نیز می توانند باعث شوند که چگالی log یا مشتقات آن در عمل ناپیوسته رفتار کنند، حتی اگر در تئوری پیوسته باشند.
• اگر مدل "تقریباً خوب" به نظر می رسد یا بسیار سریع جا می گیرد، ممکن است بتوانید با کمی بازی با adapt_delta و stepize، هشدارها را برطرف کنید. برای مثال اینجا را ببینیدافزایش adapt_delta به طور خاص به عنوان اولین چیزی که مردم امتحان می کنند رایج شده است، و در حالی که مواردی وجود دارد که می تواند مفید باشد، ممکن است بتوان نمونه گیری کارآمدتری را با adapt_delta پیش فرض و مدل اصلاح شده، قبل یا پارامترسازی به دست آورد. افزایش adapt_delta / max_treedepth احتمالا زمان نمونه برداری را در هر تکرار افزایش می دهد. با دنبال کردن گزینه های بالا و رها کردن تنظیم adapt_delta به عنوان آخرین راه، احتمال بیشتری وجود دارد که هم به عملکرد نمونه گیری بهتر و هم به مدل قوی تر دست یابید (بدون ذکر درک آن). افزایش adapt_delta بیش از 0. 99 و max_treedepth بیش از 12 به ندرت مفید است. برای تشخیص، گاهی اوقات وجود واگرایی های بیشتر مفید است، بنابراین بازگشت به تنظیمات پیش فرض برای تشخیص می تواند مفید باشد. افزایش adapt_delta / max_treedepth به ندرت برای حل مشکلات Rhat/ESS/BFMI مفید است.

یک مجموعه داده شبیه سازی شده با مقادیر واقعی شناخته شده همه پارامترها ایجاد کنید. اگر خطاها در داده های شبیه سازی شده ناپدید می شوند و قسمت بعدی بیشتر پارامترهای «درست» شبیه سازی را پوشش می دهد، مدل شما ممکن است برای داده های مشاهده شده واقعی مناسب نباشد. اگر از یک رابط سطح بالاتر استفاده می کنید، نوشتن کد برای شبیه سازی داده ها راهی عالی برای آزمایش اینکه متوجه می شوید مدل واقعاً چه کاری انجام می دهد یا خیر است. بیشتر خواندن:

• نمونه هایی از استفاده از Stan برای شبیه سازی داده ها دارد. یک شبیه سازی R را برای یک مدل پیچیده و چگونگی کمک به تشخیص یک اشکال نشان می دهد.
• BRMS می تواند مجموعه داده ها را با استفاده از آرگومان sample_prior = "فقط" شبیه سازی کند (برای اطلاعات بیشتر به اسناد مراجعه کنید).

پارامترها را به بلوک داده منتقل کنید و آنها را روی مقادیر واقعی خود (از داده های شبیه سازی شده) تنظیم کنید. سپس آنها را یک به یک به بلوک پارامترها برگردانید. کدام پارامتر مشکلات را معرفی می کند؟

با استفاده از یک مجموعه داده شبیه سازی شده ، مقدمات محکم را با محوریت مقادیر پارامتر واقعی (شناخته شده از شبیه سازی) معرفی کنید. چقدر به Priors نیاز دارید که اجازه دهید مدل متناسب باشد؟برای شناسایی چند حالته مفید است.

کد خود را بررسی کنید. مشکلات تقریباً به احتمال زیاد نتیجه خطای برنامه نویسی است زیرا آنها یک مسئله واقعاً آماری هستند. این بیشتر برای استثنائات و طرد ها مهم است.

• آیا تمام پارامترهای اعلام شده در مدل استفاده می شوند؟
• آیا همه پارامترها دارای مقدمات آموزنده هستند؟
• آیا شاخص های آرایه شما و برای حلقه ها مطابقت دارد؟
• آیا مرزهای سخت درستی دارید (به عنوان مثال پارامترهای انحراف استاندارد ، احتمالات دارند). از مرزهای سخت برای بیان دانش قبلی نرم استفاده نکنید زیرا اثرات شکل خلفی بی اهمیت نیست.
• خطاها/هشدارهای دیگر را در خروجی STAN بررسی کنید (به عنوان مثال پارامتر موقعیت مکانی INF است ، اما باید محدود باشد!) و منابع آنها را بررسی کنید ، زیرا آنها معمولاً به خطاهای برنامه نویسی اشاره می کنند. در RSTAN ، این هشدارها ممکن است نمایش داده نشوند مگر اینکه با زنجیره ای = 1 اجرا کنید.

به طور خاص برای استثنائات/طرد ها: به نمونه کمک کنید تا از محدوده فضای پارامتر و عدم دقت عددی جلوگیری کند.

• از مقدماتی استفاده کنید که وزن کمتری را بر روی مقادیر در نزدیکی مرز قرار دهند (اگر این با تخصص دامنه سازگار باشد).
• از عبارات پایدار عددی استفاده کنید. این شامل همیشه انجام محاسبات در مقیاس ورود به سیستم در صورت امکان و استفاده از توابع خاص استن است. به عنوان مثال ، log_sum_exp (x) از نظر عددی قوی تر از log (sum (exp (x)) است. نمونه های دیگر مانند این شامل log1m (x) به جای ورود به سیستم (1-x) ، log1p_exp (x) به جای ورود به سیستم (1 +)Exp (x)) ، و بسیاری دیگر. بخش های ترکیبی از مرجع توابع STAN را برای یک لیست کامل مشاهده کنید.
• از تابع چاپ () در مدل STAN خود استفاده کنید تا مقادیر میانی را در یک محاسبات نمایش دهید تا ببینید که یک مقدار نامعتبر از کجا سرچشمه می گیرد.

مقدمات آموزنده تری را معرفی کنید. اگر خلفی شما شامل مقادیری است که دلالت بر پیش بینی های کاملاً پوچ (به عنوان مثال 10 متر بلند انسان ، تقریباً صفر اختلاف بین موضوع در بقا ، ...) ، حذف آن توسط یک سخت تر ممکن است مفید باشد.

• هنگام کار در مقیاس لگاریتمی (به عنوان مثال رگرسیون لجستیک/پواسون) حتی مقدمات به ظاهر باریک مانند عادی (0 ، 1). در واقع می تواند کاملاً گسترده باشد (این باعث می شود نسبت شانس/اثر چند برابر از Exp (2) یا تقریباً 7. 4 هنوز هم A-Priori قابل قبول باشد - آیا این با تخصص دامنه شما سازگار است؟).
• برخی از توصیه های (کمی منسوخ) در مورد Priors در https://github.com/stan-dev/stan/wiki/prior-choice-reecmendations است
• توزیع نیمه عادی یا نیمه دانش آموز معمولاً برای پارامترهای SD در مدلهای مختلف رهگیری/اثر ، به نیمه كوچی ارجح است. بحث و گفتگوی انجمن ، گلمن 2006
• اگر دانش دیگری دارید که به شما امکان می دهد از Preorors خود به طور دفاعی محدود کنید. بحران هویت بحث در مورد اینکه چه زمانی می تواند کمک کند.
• شبیه سازی داده ها از قبل (بررسی پیش بینی قبلی A. K. A) یک روش مناسب برای بررسی اینکه آیا مقدمات و تعامل آنها تقریباً منطقی است یا خیر. گابری و همکاران. 2019 مثالی دارد.

مقدمات خود را با توزیع خلفی مقایسه کنید. اگر این مدل به شدت در دمهای مقدماتی شما یا در مرزهای محدودیت های پارامتر در حال نمونه برداری است ، این یک علامت بد است ، نشان می دهد که مقدمات شما ممکن است به طور قابل توجهی در نمونه گیری تأثیر بگذارد. در اینجا ، تنظیم مقدمات گسترده تر گاهی اوقات می تواند کمک کند.

مدل خود را دوباره تنظیم کنید. خلفی ایده آل نزدیک به توزیع عادی مستقل در هر پارامتر است زیرا این امر منجر به انحنای ثابت می شود. هرگونه انحراف از این گوشه های تیز ، لبه ها ، لبه ها ، قوطی ها ، شکل موز ، همبستگی های محکم یا سایر بی نظمی ها اهداف بالقوه برای بازپرداخت را نشان می دهد. در تنظیم پیش فرض ، استن به طور خودکار هر پارامتر را با یک عامل ثابت در حین سازگاری نجات می دهد ، بنابراین مقیاس مطلق خلفی معمولاً بسیار مهم نیست. بخش اصلی بازپرداخت تغییر پارامترهای واقعی و محاسبه پارامترهای مورد علاقه خود در بلوک پارامترهای تبدیل شده است. بیشتر خواندن:

• فصل راهنمای کاربر STAN در مورد بازپرداخت. در مورد پارامتر سازی غیر محور که اغلب مفید است بحث می کند. توسط مایک بتانکورت به جزئیات بیشتری در مورد پارامترهای غیر محور می پردازد ، Betancourt & Girolami 2015 به همان موضوع می پردازد.
• راهنمای کاربران STAN فصل در مورد qr reparameTization برای مدل های خطی نمونه ای از مکان هایی که پارامترها به خوبی توسط داده ها آگاه نیستند ، نشان می دهد ، در حالی/8286/3 نشان دادن یک بازپرداخت بالقوه. مشکلات و راه حل ها را در یک مدل ODE نشان می دهد. بشر

به طور خاص برای هشدارهای کم BFMI:

• به نمودار جفت ها نگاه کنید تا ببینید کدام پارامترهای اولیه با حاشیه انرژی__ همبستگی دارند.
• پارامترهای اولیه که با حاشیه انرژی__ در نمودار جفتی همبستگی دارند، مکان خوبی برای شروع به فکر کردن در مورد پارامترهای مجدد هستند. باید یک رابطه منفی بین lp__ و انرژی__ در نمودار جفت وجود داشته باشد، اما این جای نگرانی نیست زیرا lp__ لگاریتم هسته خلفی است نه یک پارامتر اولیه.

مخصوصاً برای هشدارهای Rhat، ESS، BFMI پایین: ممکن است سعی کنید تعداد دفعات گرم کردن یا نمونه برداری بیشتری را تنظیم کنید. افزایش تعداد تکرارها به ندرت برای رفع واگرایی ها/هشدارهای حداکثر عمق درخت مفید است.

• وقتی تعداد تکرارها افزایش می یابد، به تغییر در bulk-ESS و tail-ESS نگاه کنید. اگر R-hat کمتر از 1. 01 باشد و ESS با تعداد تکرارها به صورت خطی رشد کند و در نهایت از حد توصیه شده فراتر رود، اختلاط کافی است اما MCMC همبستگی بالایی دارد که به تعداد زیادی تکرار نیاز دارد.

حالت بهینه سازی (حداکثر احتمال جریمه شده) را به جای نمونه برداری (NUTS) اجرا کنید تا بررسی کنید که آیا مقادیر حاصل حداقل تقریباً معقول به نظر می رسند یا نه، سعی کنید دلیل آن را بیابید.

برای آزمایش محاسبات گرادیان، Stan را در حالت تشخیص (test_grad) اجرا کنید. این گاهی اوقات می تواند ناپایداری های عددی را در مدل شما تشخیص دهد.

هنگام نصب همان مدل در JAGS/WinBUGS/… هیچ هشداری دریافت نکردم.

ممکن است به دیدن اخطارهای زیاد از نرم افزارهای دیگری که استفاده می کنید عادت نداشته باشید، اما این بدان معنا نیست که Stan مشکلات بیشتری نسبت به نرم افزارهای دیگر دارد. تیم توسعه Stan برای اطلاع رسانی به کاربران در مورد هر موضوعی که به طور بالقوه می تواند مهم باشد اولویت بالایی دارد و Stan به جای پنهان کردن آنها از شما، همیشه در مورد مشکلاتی که با آن مواجه می شود به شما اطلاع می دهد.

مزیت بزرگ الگوریتم های مورد استفاده توسط Stan این است که آنها تشخیص های منحصر به فرد خاصی را امکان پذیر می کنند که هنگام استفاده از الگوریتم های دیگر در دسترس نیستند. این می تواند به هشدارهای بیشتری از طرف Stan منجر شود، اما این یک ویژگی است تا یک اشکال. گاهی اوقات زمانی که افراد مدلی را از برخی نرم افزارهای دیگر در Stan مجدداً پیاده سازی می کنند، هشدارهای غیرمنتظره ای دریافت می کنند و بررسی های بیشتر نشان می دهد که مشکل این است که Stan خیلی حساس نیست، بلکه مدل اصلی در واقع مدل قبلی را درست محاسبه نکرده است.

کمک گرفتن

بهترین مکان برای کمک گرفتن از توسعه دهندگان و کاربران Stan در صورتی که در نصب مدل مشکل دارید، بازدید از تالار گفتمان Stan است.

به منظور کاهش هر دو کمک مورد نیاز شما و به ما اجازه می دهد تا در صورت نیاز به بهترین کمک کمک کنیم ، توصیه می شود: * برنامه های Stan را در یک پرونده مستقل با یک پسوند . stan قرار دهید. حتی اگر برخی از رابط های Stan اجازه می دهند مدل را به عنوان یک رشته مشخص کنند ، تعداد خط در پیام های هشدار و خطا فقط در صورت استفاده از یک فایل جداگانه معنی دار است.* با صرفه جویی در مدل و مقادیر اولیه در پرونده ها و دستورات RSTAN (سایر رابط های STAN) در اسکریپت ها ، قابلیت تکرارپذیری را حفظ کنید.* از کنترل نسخه مانند GIT در پرونده ها و اسکریپت های خود استفاده کنید تا سابقه تغییراتی را که ایجاد کرده اید داشته باشید.* شروع ساده! مدل خود را به صورت مراحل بسازید و در هر مرحله متناسب با آن را بررسی کنید ، فقط در صورت عدم وجود پرچم قرمز ، پیچیدگی را اضافه کنید. اگر با نوشتن یک مدل پیچیده شروع کنید ، می توان تشخیص داد که در کجا اشتباه می شود.< Pan> به منظور کاهش میزان کمک مورد نیاز شما و به ما اجازه می دهد تا در صورت نیاز به بهترین کمک کمک کنیم ، توصیه می شود: * برنامه های Stan را در یک پرونده مستقل با یک پسوند . Stan قرار دهید. حتی اگر برخی از رابط های Stan اجازه می دهند مدل را به عنوان یک رشته مشخص کنند ، تعداد خط در پیام های هشدار و خطا فقط در صورت استفاده از یک فایل جداگانه معنی دار است.* با صرفه جویی در مدل و مقادیر اولیه در پرونده ها و دستورات RSTAN (سایر رابط های STAN) در اسکریپت ها ، قابلیت تکرارپذیری را حفظ کنید.* از کنترل نسخه مانند GIT در پرونده ها و اسکریپت های خود استفاده کنید تا سابقه تغییراتی را که ایجاد کرده اید داشته باشید.* شروع ساده! مدل خود را به صورت مراحل بسازید و در هر مرحله متناسب با آن را بررسی کنید ، فقط در صورت عدم وجود پرچم قرمز ، پیچیدگی را اضافه کنید. اگر با نوشتن یک مدل پیچیده شروع کنید ، می توان تشخیص داد که در کجا اتفاق می افتدبه: * برنامه های Stan را در یک پرونده مستقل با یک پسوند . stan قرار دهید. حتی اگر برخی از رابط های Stan اجازه می دهند مدل را به عنوان یک رشته مشخص کنند ، تعداد خط در پیام های هشدار و خطا فقط در صورت استفاده از یک فایل جداگانه معنی دار است.* با صرفه جویی در مدل و مقادیر اولیه در پرونده ها و دستورات RSTAN (سایر رابط های STAN) در اسکریپت ها ، قابلیت تکرارپذیری را حفظ کنید.* از کنترل نسخه مانند GIT در پرونده ها و اسکریپت های خود استفاده کنید تا سابقه تغییراتی را که ایجاد کرده اید داشته باشید.* شروع ساده! مدل خود را به صورت مراحل بسازید و در هر مرحله متناسب با آن را بررسی کنید ، فقط در صورت عدم وجود پرچم قرمز ، پیچیدگی را اضافه کنید. اگر با نوشتن یک مدل پیچیده شروع کنید ، می توان تشخیص داد که در کجا اشتباه می شود.