تصور کنید سیستمی ساختهاید که در محیط تست عالی کار میکند، اما سه هفته بعد و در شلوغترین ساعت کاری، بدون اینکه خطی از کد تغییر کرده باشد، ناگهان کرش میکند یا با خطای Timeout مواجه میشود. این کابوس بسیاری از توسعهدهندگانی است که تصور میکنند یک پاسخ موفق از مدل، به معنای تأیید پایداری کل سیستم است. در واقع، یک پرامپت موفق تنها یک نمونه (Sample of one) است، نه یک گواهینامه برای پایداری.
بسیاری از برنامهنویسان مستندات طراحی خود را بر این فرض میسازند که یک نقطه اتصال (Endpoint) رایگان، رفتاری ثابت دارد. اما حقیقت این است که در اکوسیستم فعلی، دسترسی رایگان یک سرویس تضمینشده با سطح کیفیت مشخص نیست، بلکه یک صف مشترک است. ساختن محصول روی این لایهها بدون یک سیستم اعتبارسنجی سختگیرانه، بدهی فنی (Technical Debt) ایجاد میکند که دقیقاً در لحظات بحرانی یا ددلاینهای حساس، خودش را نشان میدهد. نویسنده این متدولوژی اشاره میکند که خودش دو بار با این دیوار برخورد کرده است؛ هر دو بار بهدلیل پذیرش افسانههایی که هرگز مورد تست قرار نگرفته بودند.
زمینه: محیط آزمایش
برای جلوگیری از به خطر انداختن سیستمهای عملیاتی، این آزمایشها با استفاده از دسترسی رایگان مدلها و گزینه سرور رایگان MonkeyCode انجام شده است. بسیار حیاتی است که بدانید این موارد صرفاً «ادعاهای در دسترس بودن» ارائه شده توسط اپراتور هستند و نه تضمینهای قراردادی. در همین راستا، پیشتر بررسی کردیم که چرا ۱۰ میلیون توکن رایگان MonkeyCode نباید به عنوان بودجهای برای محیط تولید در نظر گرفته شود و تکیه بر آن ریسکهای عملیاتی دارد. از آنجا که جزئیات لایههای رایگان بهسرعت تغییر میکنند، توسعهدهندگان باید پیش از ساخت هر چیزی بر اساس یک عدد یا ظرفیت خاص، صفحه فعلی پروژه را بررسی کنند.
به همین دلیل است که ابزار پیشنهادی در این مقاله بهجای اعتماد به حافظه انسانی، یک اثر انگشت (Fingerprint) و تاریخ ثبت میکند. هدف این است که از جملهی «دیروز کار میکرد» — که نویسنده آن را «فولکلور و افسانه» مینامد — به یک ردپای مستند از شواهد برسیم.
به گزارش راهنمای فنی منتشر شده در dev.to در تاریخ ۱۴ سپتامبر ۲۰۲۶، توسعهدهندگان هنگام استفاده از استکهای رایگان معمولاً دچار ۵ باور غلط میشوند:
ظرفیت در برابر قیمت: این باور که «رایگان بودن» به معنای داشتن یک برنامه ظرفیت (Capacity Plan) است. در واقع، رایگان بودن توصیف قیمت است، نه ظرفیت. ظرفیت مشترک در نقاط اتصال رایگان عادی است؛ یعنی عملکردی که ساعت ۱۰ صبح میبینید، ممکن است ساعت ۱۰ شب کاملاً ناپدید شود.
- روش تست: ۲۰ درخواست متوالی و سپس ۲۰ درخواست موازی ارسال کنید. کد وضعیت (Status Code)، تأخیر (Latency) و تعداد تلاشهای مجدد (Retry Count) را برای هر کدام ثبت کنید. نرخ شکست را مقایسه کنید، نه فقط میانگین تأخیر را.
- مدل اصلاحشده: دسترسی رایگان صفی است که با غریبهها شریک شدهاید. اگر کار شما به همزمانی (Concurrency) تضمینشده نیاز دارد، لایه رایگان گزینه اشتباهی است.
محیط استیج در برابر کانتینرها: فرض بر این است که یک سرور رایگان، محیط استیج (Staging) معتبری است. هرچند این سرور یک کانتینر را اجرا میکند، اما فاقد هدف سطح سرویس (SLO)، سیستم هشدار (Pager) یا مسیر بازگشت (Rollback) است.
- روش تست: یک پردازش طولانی را شروع کنید و در میانه اجرا، اتصال خود را قطع کنید. دوباره وصل شوید و بررسی کنید که آیا پردازش هنوز وجود دارد یا خیر. یک فایل بنویسید، سرور را ریاستارت کنید و ببینید چه چیزی باقی مانده است.
- چه کسانی باید اجتناب کنند: هر چیزی که با مشتری در ارتباط است، هر چیزی که دارای بند «زمان فعال بودن» (Uptime) است و هر چیزی که اسراری (Secrets) دارد که نمیتوان آنها را ظرف یک ساعت تغییر داد.
تکرارپذیری در برابر مشاهده: این باور که دو اجرای یکسان، ثابتکننده قطعی بودن (Determinism) مدل است. دو خروجی مشابه صرفاً یک نمونه است که دو بار تحت شرایط نامعلوم مشاهده شده است.
- روش تست: پیش از هر اجرا، اثر انگشتی شامل نسخه پایتون/Runtime، URL نقطه اتصال، رشته نسخه مدل (اگر در دسترس باشد)، هش پرامپت، دما (Temperature) و برچسب زمانی ثبت کنید.
- مدل اصلاحشده: یک اجرا تنها نسبت به اثر انگشت ثبتشدهاش تکرارپذیر است.
توان عملیاتی در برابر سهمیه: اشتباه گرفتن سهمیه توکن (که یک سقف یا Ceiling است) با توان عملیاتی (که یک نرخ یا Rate است). اشتباه گرفتن این دو واحد متفاوت، محاسبات ظرفیت شما را در روزهای جمعه (پایان هفته) به هم میریزد.
- روش تست: فیلد Usage را در هر پاسخ ثبت کنید. مجموع توکنها را در ۲۰ فراخوانی محاسبه کنید. برای برنامهریزی، از مقدار p90 (۹۰ درصد بدترین حالتها) استفاده کنید، هرگز از میانگین (Mean) استفاده نکنید.
- مدل اصلاحشده: محاسبات بودجه باید بر اساس بدترین فراخوانی واقعبینانه باشد. یک پاسخ طولانی از یک ابزار (Tool Response) میتواند سهمیه کل یک روز شما را ببلعد.
کد منبع در برابر استقرار: باور به اینکه کد متنباز، صحت یک نمونه در حال اجرا را تأیید میکند. کد خوانا به شما میگوید چه چیزی «میتواند» اجرا شود، اما درباره آنچه «در حال حاضر» با آن صحبت میکنید چیزی نمیگوید.
- روش تست: نسخهای که اجرا میکنید را پین (Pin) کنید. کامیت یا ریلیز مستقر شده را ثبت کنید. هدرهای پاسخ و هر فیلد نسخه قابل مشاهده را لاگ کنید. این پین را هفتگی بررسی کنید تا از رانش استقرار (Deployment Drift) جلوگیری شود.
- مدل اصلاحشده: استقرار شما یک موجودیت مجزا با ردپای شواهد خودش است. پین کردن نسخه وظیفه توسعهدهنده است، نه پروژه.
مکانیسم دفتر کل ادعاها
برای مقابله با این باورها، نویسنده سیستمی به نام «دفتر کل ادعاها» (Claim Ledger) معرفی میکند؛ یک ساختار مبتنی بر JSON که در آن هر ادعای عملکردی باید تاریخ انقضای اجباری داشته باشد. قانون ساده است: بدون تاریخ انقضا، ادعایی وجود ندارد. این رویکرد شباهت زیادی به متدولوژیهای سختگیرانه در اعتبارسنجی دارد؛ برای مثال، میتوان چگونگی استفاده MonkeyCode از چهار لایه اعتبارسنجی برای تبدیل مدلهای رایگان به ابزارهای اصلاح کد را به عنوان نمونهای از تبدیل خروجیهای غیرقابلپیشبینی به نتایج قابلاتکا بررسی کرد.
یک ورودی نمونه در این دفتر، ادعای خاص (مثلاً «تأخیر p90 زیر ۳ ثانیه برای پرامپتهای کوتاه»)، روش کاوش (مثلاً «اسکریپت probe.py، تعداد ۲۰ نمونه، متوالی، پرامپت تککلمهای»)، شواهد (مثلاً «summary.p90_ms = 2180») و حکم «امروز معتبر است» (holds-today) با تاریخ ثبت (مثلاً «۲۰۲۶-۰۹-۱۵») و یک تاریخ انقضای سختگیرانه (مثلاً «۲۰۲۶-۰۹-۲۲») را ذخیره میکند.
پیادهسازی کاوشگر (Probe)
این فرآیند از طریق یک اسکریپت پایتون به نام probe.py خودکار شده است. این اسکریپت با ارسال یک پرامپت ساده («فقط کلمه pong را پاسخ بده»)، تأخیر و مصرف توکن را برای یک نقطه اتصال خاص ثبت میکند.
جزئیات فنی کاوشگر:
- ورودیها: استفاده از متغیرهای محیطی برای
PROBE_ENDPOINT،PROBE_KEYوPROBE_N(که پیشفرض آن ۲۰ است). - اثر انگشت: ثبت پلتفرم سیستمعامل، نسخه پایتون و هش SHA-256 پرامپت.
- معیارها: محاسبه p50، p90 و حداکثر تأخیر (Max Latency) در مجموعه نمونهها.
- اجرا: اسکریپت اجرا شده و خروجی آن به یک فایل JSON تاریخدار منتقل میشود:
python3 probe.py > ledger-$(date +%F).json.
برای تست باور مربوط به موازیسازی، نویسنده استفاده از یک نسخه رشتهای (Threaded) با استفاده از ThreadPoolExecutor و مقدار max_workers=20 را پیشنهاد میکند تا تابع فراخوانی را روی بازهای از ۲۰ درخواست بهطور همزمان اجرا کند.
جدول تصمیمگیری: تفسیر نتایج
برای جلوگیری از «بیشازحد خوشبینانه دیدن طراحی» (Flattering the design)، یک جدول تصمیمگیری برای شفافسازی آنچه نتایج واقعاً ثابت میکنند، ارائه شده است:
| مشاهده | ثابت میکند | ثابت نمیکند |
|---|---|---|
| ۲۰ فراخوانی موفق از ۲۰ | نقطه اتصال در آن بازه زمانی کار میکرد | در ساعت پیک شما هم کار خواهد کرد |
| p90 امروز زیر حد مجاز است | یک خط پایه قابل استفاده در حال حاضر | یک روند کلی یا عدد هفته آینده |
| زنده ماندن پردازش بعد از قطع اتصال | چرخه حیات در آن روز خاص | پایداری به عنوان یک ویژگی مستند شده |
| کد منبع عمومی است | میتوانید منطق را بخوانید | نمونه شما با آن کامیت مطابقت دارد |
| وجود فیلد Usage | نقطه اتصال توکنها را گزارش میدهد | سهمیه شما حجم کاری واقعی را پوشش میدهد |
تحلیل: هزینه «رایگان بودن»
برای یک توسعهدهنده عملیاتی، این تغییر دیدگاه، ادغام هوش مصنوعی را از «مهندسی پرامپت» به «مهندسی سیستمها» تبدیل میکند. ریسک اصلی لایههای رایگان، هزینه نیست، بلکه غیرقابلپیشبینی بودن زیرساخت زیرین است. وقتی یک توسعهدهنده با یک نقطه اتصال رایگان مانند یک قطعه پایدار (Stable Primitive) رفتار میکند، در واقع پایداری سیستم خود را به شخص ثالثی میسپارد که هیچ تعهد قراردادی برای ارائه آن ندارد.
این رویکرد معیار «آماده برای تولید» (Production-ready) را تغییر میدهد. این متدولوژی پیشنهاد میکند که توانایی اندازهگیری نرخ شکست یک مدل، ارزشمندتر از توانایی تولید یک پاسخ بینقص است. با پیادهسازی دفتر کل، تیمها بهجای بحث درباره اینکه آیا ابزاری «کار میکند یا نه»، درباره این بحث میکنند که «دقیقاً چه زمانی احتمالاً شکست میخورد».
محدودیتها و مرزهای صادقانه
بسیار مهم است که مرزهای این روش را بشناسیم. یک کاوش ۲۰ تایی صرفاً یک تست اولیه (Smoke Test) است و نمیتواند الگوهای هفتگی را شناسایی کند. علاوه بر این، تأخیر اندازهگیری شده از یک شبکه، با تأخیر در شبکه دیگر یکسان نیست. این گردشکار در دسترس بودن و شکل هزینهها را تأیید میکند، اما کیفیت خروجی را نه؛ زیرا تأیید کیفیت نیازمند دادههای ارزیابی برچسبدار (Labeled Evaluation Data) است.
گام بعدی: روتین دوشنبهها
برای حفظ یک فایل README صادقانه، نویسنده یک ریتوال هفتگی را توصیه میکند:
۱. هر دوشنبه اسکریپت کاوش را مجدداً اجرا کنید.
۲. نتایج خلاصه را با هفته قبل مقایسه (Diff) کنید.
۳. ادعاهای قدیمی را بهجای حذف، به عنوان «منقضی شده» علامت بزنید.
۴. تنها ادعاهایی را به مستندات طراحی منتقل کنید که سه هفته متوالی دوام آوردهاند.
۵. پیش از نیاز واقعی، یک مسیر جایگزین (Fallback) موازی را سیمکشی و آماده کنید.
توسعهدهندگان باید مخازن فعلی خود را برای هرگونه ادعای تأخیر یا توان عملیاتی که تاریخ ثبت ندارد، بازرسی کنند. اگر نمیتوانید روی یک ادعا تاریخ بگذارید، آن ادعا همین حالا منقضی شده است. برای شروع، یک اسکریپت ساده برای ثبت خط پایه p90 این هفته روی نقطه اتصال اصلی خود پیاده کنید.
اما داستان سختافزاری این تحول حتی شگفتانگیزتر است — به تحلیل ما دربارهی تراشههای Blackwell مراجعه کنید.
گفتگو