از یک پرسش پژوهشی شروع کنید
یک پلتفرم پژوهشی مفید باید به تیم کمک کند فرضیه‌ای مشخص را آزمایش کند، نه اینکه بنا به درخواست یک منحنی سرمایه‌ی جذاب تولید کند. پیش از اجرای آزمایش‌ها، پرسش، بازار هدف، دوره‌ی مشاهده، داده‌های ورودی و قاعده‌ی تصمیم‌گیری را بنویسید. پیش‌بینی مدل را از اقدامی که شبیه‌ساز بر اساس آن پیش‌بینی انجام می‌دهد جدا کنید. یک روش مقایسه‌ی ساده ثبت کنید تا پیچیدگی اضافه‌شده چیزی برای توجیه خود در برابر آن داشته باشد. ارزش محصول در یک بررسی قابل ردیابی و توضیح روشنِ عدم‌قطعیت است، نه در وعده‌ی تکرار نتایج تاریخی.
آنچه را در همان زمان قابل دانستن بوده حفظ کنید
هر مشاهده به رابطه‌ای روشن میان زمان وقوع رویداد، زمان انتشار و زمانی که برنامه می‌توانسته آن را دریافت کند نیاز دارد. یک عدد بازنگری‌شده نباید فقط به این دلیل که در مجموعه‌داده‌ی امروز وجود دارد، در شبیه‌سازیِ قدیمی‌تر ظاهر شود. نسخه‌های داده، بازه‌های مفقود، افزوده‌شدن ابزارها و حذف از فهرست‌ها را ثبت کنید. آزمایش کنید وقتی یک فید دیر می‌رسد یا فیلدی در دسترس نیست چه رخ می‌دهد. تبدیل‌ها را بازتولیدپذیر و محدود به داده‌ی آموزشیِ مناسب نگه دارید. گزارشی زیبا کمکی نمی‌کند اگر ورودی‌های آن بی‌سروصدا شامل اطلاعاتی باشند که در زمان تصمیم‌گیریِ شبیه‌سازی‌شده در دسترس نبوده‌اند.
در ارزیابی، ترتیب زمانی را رعایت کنید
مستندات TimeSeriesSplit در Scikit-learn توضیح می‌دهد چرا داده‌های زمان‌مند نباید با آینده آموزش ببینند و روی گذشته ارزیابی شوند. مرزهای ارزیابی را بر اساس پرسش پژوهشی واقعی طراحی کنید. دوره‌های آموزش، اعتبارسنجی و ارزیابیِ دست‌نخورده را همراه هر جداسازی لازم به‌خاطر هدفِ مورد پیش‌بینی ثبت کنید. آزمایش‌ها، از جمله آزمایش‌های ناموفق، را لاگ کنید و فقط پیکربندی خوش‌ظاهر را نگه ندارید. تصمیم بگیرید چه زمانی مدل و پارامترهایش ثابت می‌شوند. بررسی مکرر یک دوره‌ی ارزیابی و تنظیم مدل بر اساس آن، آن دوره را به بخشی از فرایند توسعه تبدیل می‌کند.
فرض‌های اجرا را آشکار کنید
به بازبینان اجازه دهید کارمزدها، اسپرد، لغزش قیمت، محدودیت اندازه‌ی سفارش، تأخیرها و قاعده‌ی تصمیم‌گیری درباره‌ی انجام شدن سفارش را بررسی کنند. به‌جای پنهان کردن یک تنظیم خوش‌بینانه در کد، نتایج را تحت چند فرض معقول مقایسه کنید. توضیح دهید قیمت‌های مفقود، توقف بازار، انجام جزئی سفارش و سفارش‌های ردشده چه اثری بر شبیه‌سازی دارند. نتایج ناخالص را از هزینه‌ها جدا کنید و خط مبنا را کنار روش آزموده‌شده نشان دهید. این کنترل‌ها ابزارهای حفاظتی پژوهش برای تفسیر مدل‌اند. آن‌ها بک‌تست را به شواهدی تبدیل نمی‌کنند که نشان دهد استقرار زنده همان نتیجه را به دست خواهد آورد.
خروجی هوش مصنوعی را ورودی یک آزمایش بدانید
وقتی یک دستیار، قابلیت پیشنهاد می‌کند، اخبار را خلاصه می‌کند یا منطق استراتژی می‌نویسد، شناسه مدل، نسخه پرامپت، ارجاع‌های منبع و کد یا خروجی ساختاریافته حاصل را نگه دارید. پیش از ورود داده‌های نقل‌شده به دیتاست، صحت آن‌ها را بررسی کنید. منطق تولیدشده را از همان فرایند بازبینی و ارزیابی عبور دهید که برای منطق نوشته‌شده توسط انسان استفاده می‌کنید. نگذارید یک پاسخ مکالمه‌ای، بی‌سروصدا یک آزمایش تأییدشده را تغییر دهد. راهی فراهم کنید که بتوان آرتیفکت ذخیره‌شده را بدون وابستگی به یک نشست چت بازتولید کرد. این کار دستیار را برای پژوهشگران مفید می‌کند، درحالی‌که مسئولیت پذیرش همچنان با تیمی می‌ماند که پلتفرم را اداره می‌کند.
گزارشی ارائه دهید که فرد دیگری بتواند آن را بازتولید کند
یک آزمایش تکمیل‌شده باید شامل پیکربندی، ارجاع‌های داده، نسخه کد، بازه‌های ارزیابی، فرضیات، نتایج و محدودیت‌های خود باشد. به بازبین‌ها امکان بدهید به‌جای دیدن فقط نمودارهای خلاصه، تصمیم‌های منفرد را هم بررسی کنند. خروجی گرفتن از گزارش و اجرای دوباره آن را در یک محیط تمیز با وابستگی‌های مستندشده آزمایش کنید. دسترسی پژوهشی را از مجوزهای ارسال سفارش زنده جدا کنید. اگر اجرای کاغذی هم وجود دارد، تفاوت‌های باقی‌مانده آن با یک محل اجرای واقعی را توضیح دهید. پذیرش باید بازتولیدپذیری و رفتار کنترل‌شده را ثابت کند، درحالی‌که ادعاهای عملکردی فقط به همان آزمایش دقیقی که آن‌ها را تولید کرده وابسته بمانند.