54. طراحی آزمایش
54.1فرضیه‌ها
آزمایش، پرسشی با پاسخ ابطال‌پذیر است که پیش از جمع‌آوری داده بیان می‌شود: «مسیریابی نویز-آوار شمارش دروازهٔ دوتایی روی هوی-هکس را برای مدارهای QFT در n=5–12 دست‌کم ۱۰٪ کم می‌کند»، نه «ما مسیریابی نویز-آوار را کاوش می‌کنیم». هر فرضیه را به‌صورت ادعا + دامنه + سنجه + آستانه ساختار دهید؛ آستانه همان چیزی است که شما را صادق نگه می‌دارد وقتی نتایج مبهم برگشتند. جفت-فرضیه ترجیح دهید (H1: اثر هست؛ H0: نیست) و آزمون آماری‌تان را حالا تصمیم بگیرید، نه بعد از دیدن داده. پیچش کوانتومی-ویژه: فرضیه باید رژیم را بیان کند — شبیه‌سازی ایده‌آل، نویزی با مدل نام‌برده، یا سخت‌افزار نام‌برده با تاریخ کالیبراسیون — چون نتیجهٔ درست در یک رژیم ممکن است در دیگری غلط باشد و بیشتر سردرگمی منتشرشده، سردرگمی رژیمی است.
54.2خطوط پایه
آزمایش بدون خط پایه، حکایت است. نردبان خط پایه برای کار کوانتومی، صعودی: شبیه‌سازی ایده‌آل (اجرای کامل چه می‌دهد؟ — منحنی نظری شما)، پیاده‌سازی ساده‌لوحانه (تنظیمات پیش‌فرض — بی‌تلاشی چه می‌دهد؟)، پیاده‌سازی استاندارد (روش معلوم خوب-تنظیم — وضعیت فعلی هنر چه می‌دهد؟) و رقیب کلاسیک جایی که هست (انضباط 50.8؛ حتی برای آزمایش‌های سخت‌افزاری، «شبیه‌سازی brute-force همین نمونه چقدر می‌ارزد؟» ستون اجباری است). خطوط پایه باید تلاش برابر تنظیم‌شدگی بگیرند — روش کوانتومی که خط پایهٔ تنظیم‌نشدهٔ کلاسیک را می‌زند، غیرنتیجهٔ پرانتشارِ حوزه است. خطوط پایه را در یادداشت آزمایش پیش‌ثبت کنید؛ افزودن خط پایهٔ ضعیف‌تر بعد از دیدن نتایج، خودفریبی با کاغذبازی است.
54.3متغیرهای کنترل‌شده
یک چیز در هر بار — اما در آزمایش‌های کوانتومی «یک چیز» لغزنده است چون همه‌چیز جفت می‌شود: شمار کیوبیت مسیریابی را عوض می‌کند، مسیریابی عمق را، عمق حساسیت نویز را. انضباط کنترل: همهٔ متغیرها را شمارش کنید (n، خانوادهٔ مدار، تنظیمات ترنسپایلر، بذرها، شات، مدل نویز، نرخ خطا، پایهٔ اندازه‌گیری، پس‌پردازش)؛ همه جز مطالعه‌شده را ثابت نگه دارید و — عادت حرفه‌ای — *مقادیر ثابت را گزارش کنید*، چون «در سطح بهینه‌سازی ۳ با SABRE، میانگین‌گیری-بذری» جهانی متفاوتی از «تنظیمات پیش‌فرض، یک بذر» است. جایی که متغیرها ناتوان از جداسازی‌اند (اغلب)، عامل درهم‌کننده را صریح جارو کنید و نتیجه را نوار ارائه کنید نه نقطه. طرح‌های عاملی (شبکه‌های کوچک روی ۲–۳ پارامتر) در مقیاس شبیه‌ساز ارزان‌اند و برهم‌کنش‌هایی را نشان می‌دهند که شهودتان ندید.
54.4داده‌ها
برای مدارها: پیکره‌های مستقر را به‌کار ببرید (QASMBench، BenchPress، خانواده‌های تولیدشدهٔ ماشین — QFT-n، مدارهای تصادفی با ساختار ثابت) و *بگویید کدام نمونه‌ها و چرا*؛ گیلاس‌چینیِ مدارهایی که روش‌تان را خوش نماینند، در چاپ نامرئی و در تکرار کشنده است. برای دادهٔ کاربردی (شیمی: کدام مولکول‌ها و مجموعه‌پایه‌ها؛ ML: کدام مجموعه‌داده — با احتیاط‌های 50.8) محک‌های استاندارد را بر سفارشی ترجیح دهید و اندازهٔ داده‌ها را صادقانه در برابر هزینهٔ محاسبه گزارش کنید. هر داده‌ای manifest می‌خواهد: منبع، نسخه، پیش‌پردازش و — برای دادهٔ تولیدی — اسکریپت تولید و بذر. آزمون اسیدی: غریبه‌ای می‌تواند نمونه‌های دقیق شما را از مقاله‌تان بازسازی کند؟ اگر نه، آزمایش‌تان هنوز آزمایش نیست؛ دموست.
54.5شبیه‌ساز در برابر سخت‌افزار
درخت تصمیم: شبیه‌سازی ایده‌آل وقتی منطق و ریاضیات تست می‌شوند (سریع، دقیق، اشکال‌زدایی‌پذیر — چک‌های Statevector و Operator، فصل ۱۶)؛ شبیه‌سازی نویزی وقتی ادعا به نویز مربوط است (رفع خطا، آموزش‌پذیری واریاسیونال، رفتار رمزگشا — ارزان، تکرارپذیر، بذردار)؛ سخت‌افزار وقتی ادعا دربارهٔ سخت‌افزار است (اثرات کالیبراسیون، کراس‌تاک، رانش — تنها حقیقت زمینی، گران و دودکننده). قاعده: هرگز فرضیه‌ای را روی سخت‌افزار تست نکنید که روی شبیه‌ساز قابل تست بود، و هرگز نتیجهٔ شبیه‌ساز را به سخت‌افزار تعمیم ندهید بدون نام‌بردن مدل نویزی که این دو را وصل می‌کند. بودجه را واقع‌بینانه ببندید: شبیه‌سازی لپ‌تاپی مجانی است، صف‌ها و سهمیه‌های سخت‌افزار ابری واقعی‌اند؛ آزمایش‌های سخت‌افزاری را طوری طراحی کنید که فقط پرسش‌هایی را جواب دهند که شبیه‌سازی نمی‌تواند.
54.6مدل‌های نویز
مدل نویز شما فرضیه‌ای دربارهٔ ماشین است. طبقه‌بندی، به ترتیب فیدیلیتی: فقط قطبی‌شونده (خطای یکنواخت به‌ازای دروازه — برای تست منطق کافی، برای ادعای برتری گمراه‌کننده)؛ مبتنی‌بر-کالیبراسیون (خطاهای به‌ازای-کیوبیت/دروازه از اسنپ‌شات‌های واقعی — استاندارد عملی، NoiseModel.from_backend)؛ ساخت‌یافته (واخزش T1/T2، خطای خوانش، جمله‌های کراس‌تاک/تماشاگر، نشت — لازم هر جا روش‌تان ادعای مدیریت نویز دارد) و آموخته (مدل‌های برازش‌شده به داده، از جمله نویز ML-آموخته — مرز پژوهشی، فصل ۶۱). مدل را به ادعا منطبق کنید: رمزگشایی که فقط روی قطبی‌شونده معتبر شده، با ماشین واقعی روبه‌رو نشده. و همیشه ابطال‌کنندهٔ مدل را بیان کنید — چه رفتار سخت‌افزاری‌ای می‌شکستش — چون دقیقاً همان چیزی است که اجرای سخت‌افزاری شما واقعاً تست می‌کند.
54.7تکرارها
نتایج کوانتومی توزیع‌اند؛ همین‌طور گزارششان کنید. منابع تصادفیِ نیازمند تکرار: شات‌های اندازه‌گیری (آماری)، نمونه‌های مدار (ساختاری — مدارهای تصادفی فرق دارند)، بذرها در الگوریتم‌های تصادفی (SABRE، بهینه‌سازها، نمونه‌گیری) و — روی سخت‌افزار — زمان (رانش کالیبراسیون، صبح و بعدازظهر را ماشین‌های متفاوت می‌کند). انضباط: ≥۲۰ بذر برای هر ادعای الگوریتم-تصادفی؛ شمار شات متناسب با دقت گزارش (±1٪ِ 16.10 حدود 10⁴ شات می‌خواهد) و تکرارهای سخت‌افزاری در دست‌کم دو پنجرهٔ کالیبراسیون اگر ادعا دربارهٔ رفتار میانگین است. میانه‌ها و بازهٔ میان‌چارکی گزارش کنید، نه میانگینِ بهترین‌ها. صادقانه‌ترین خطای رایج حوزه، تکرار کم‌توان است — اثری که در ۳ بذر «نشان داده شد»، شایعتی با نمودار است.
54.8معناداری آماری
آزمون‌هایی که واقعاً به‌کار می‌برید: مقایسهٔ دو-نمونه‌ای (مان-ویتنی U — استوار، بدون فرض نرالیته؛ یا t-ولچ با چک‌های سلامت) برای «روش A از B جلوتر است»؛ اندازهٔ اثر با بازهٔ اطمینان (بوت‌استرپ روی بذرها — کم‌استفاده‌ترین ابزار حوزه) به‌جای p-value تنها؛ و آزمون هم‌ارزی وقتی ادعا «مطابقت» است (دو آزمون یک‌طرفه — ادعاهای بازتولید 53.6 این را می‌خواهند؛ هم‌پوشانی میله‌های خطا هم‌ارزی نیست). بهداشت مقایسهٔ چندگانه: اگر ۱۰ پیکربندی جارو کردید و بهترین را گزارش می‌کنید، بگویید (یا اصلاح کنید — بنجامینی–هوچبرگ). پیش‌ثبتی تحلیل (54.1) همان چیزی است که همهٔ این‌ها را معنا می‌دهد. این فرهنگ را از A/B تست می‌دانید؛ فیزیک هیچ‌کدامش را عوض نمی‌کند.
54.9تکرارپذیری
چک‌لیستی که کارتان را از اسکرین‌شات به مشارکت تبدیل می‌کند: مخزن با اجرای تک‌فرمانی (make reproduce یا هم‌ارزش)؛ وابستگی‌ها و نسخه‌های سنجاق‌شده (شکست 0.x→1.x قیسیت این را به حوزه یاد داد)؛ همهٔ بذرها یا ثابت-و-committed یا جارو-و-گزارش‌شده؛ دادهٔ خام committed (سطح شات، نه فقط تجمیع‌ها — ذخیره‌سازی ارزان است، بازاجرا نیست)؛ نتایج سخت‌افزاری با اسنپ‌شات کالیبراسیون مهرزمانی؛ و README که ادعا، رژیم و شکل اثباتش را می‌گوید. استاندارد داخلی: پیش از انتشار، آزمایش شش‌ماههٔ خودتان را بازاجرا کنید — اگر شما نتوانید خودتان را بازتولید کنید، هیچ‌کس نخواهد توانست. این فرهنگ مزیت ناعادلانهٔ شماست: مهندسان نرم‌افزار یک دهه پیش از فیزیک به انضباط تکرارپذیری رسیدند و حوزه می‌داند به آن نیاز دارد.
54.10ردیابی آزمایش
مقیاس ابزار می‌خواهد: بیش از چند اجرا، آزمایش‌ها را مثل jobهای production ردیابی کنید. حداقلِ ممکن: گزارش ساخت‌یافتهٔ نتایج (JSONL یا SQLite — هر اجرا هش پیکربندی، commit گیت، بذر، متریک‌ها و مسیر artifactها را ثبت کند) و شاخهٔ results/ با خروجی‌های تغییرناپذیر. مناسب: MLflow یا W&B (سطح‌های آزاد، گزینه‌های محلی-اول موجود) — آزمایش‌های کوانتومی دقیقاً در قالبشان می‌نشینند (پارامترها = پیکربندی مدار/بهینه‌ساز/نویز، متریک‌ها = اندازه‌گیری‌هایتان). مهم‌ترین عادت: هر اجرا از روز اول ثبت می‌شود، چون اجراهایی که ثبت نکردید همان‌هایی هستند که لازم خواهید داشت. و پایگاه ردیابی را با مقاله commit کنید — «دادهٔ پشت شکل ۳» به‌صورت artifact قابل‌پرس‌وجو، مرز کار تکرارپذیر مدرن و عصر PDF است.