‏چطور با کمک AI خطای تخمین حافظه رو ۹۹٪ کم کردیم

تیم مهندسی Mixpanel تعریف می‌کنه چطور خطای تخمین حافظه‌ی خط لوله‌اش رو حسابی کم کرد. این سیستم صدها هزار کار compaction رو پردازش می‌کنه و برای هر درخواست یه تخمین حافظه می‌زنه تا تصمیم بگیره چندتا رو هم‌زمان اجرا کنه. بیش‌برآورد یعنی هدررفت منابع و کم‌برآورد یعنی OOM؛ یعنی کرش پاد، تلاش مجدد و پیجرخوردن مهندس on-call.

سال‌ها تخمینشون یه ضریب ساده بود: حجم فایل ورودی ضربدر عدد ثابت ۲.۵. ساده و سریع بود، ولی اغلب صدها مگابایت اشتباه درمی‌اومد. برای فهمیدن دقیق ماجرا، طی یه پنجره‌ی سه‌روزه با لاگ‌گیری نمونه‌ای، ۱۴۶ هزار نقطه‌داده جمع کردن که حافظه‌ی تخمینی و واقعیِ هر درخواست رو ثبت می‌کرد. اینجا بود که هوش مصنوعی وارد شد: نویسنده که مهندس زیرساخته نه data scientist، با یه ایجنت هوش مصنوعی اسکریپت‌های تحلیل رو می‌ساخت — ایده رو توصیف می‌کرد، ایجنت اسکریپت رو می‌نوشت، او صحتش رو بررسی می‌کرد، اجراش می‌کرد و تکرار. کاری که عادتاً یه هفته فقط برای یادگیری ابزار وقت می‌برد، به چند ساعت فشرده شد.

اول بررسی کردن ضریب ۲.۵ چقدر بده: میانگین خطای مطلق (MAE) برابر ۰.۴۸ گیگابایت بود و بدترین موارد بیش از ۱۰ گیگابایت انحراف داشتن. تنظیم ضریب با رگرسیون به عدد بهینه‌ی ۳.۹ هم فقط ۲٪ بهتر شد؛ یعنی خود رویکرد مشکل داشت، نه عددش. برای درخواست‌های پرمشکل‌تر اوضاع بدتر بود (MAE برابر ۵.۹ گیگابایت).

بعد یه نکته توی داده‌ها به چشم اومد: ردپای حافظه‌ی هر datashard بین اجراهای مختلف زیاد تغییر نمی‌کنه. این یه ایده‌ی تقریباً بدیهی پیشنهاد داد: بعد از هر اجرای compaction، حافظه‌ی واقعیِ مصرف‌شده رو ثبت کن و همون رو به‌عنوان تخمین اجرای بعدی بذار. با همین، MAE از ۰.۴۸ به ۰.۱۲ گیگابایت رسید (۴ برابر بهتر) و برای همون موارد دردسرساز از ۵.۹ به ۰.۱۴ گیگابایت سقوط کرد. چون این بهبودِ یه‌خطی زیادی خوب به‌نظر می‌رسید، چهار رویکرد جایگزین (مثل گروه‌بندی با منبع، میانگین متحرک نمایی و نسبت اندازه‌ی فایل per-shard) رو هم تست کردن و هرکدوم به دلیل مشخصی کم آوردن. در production نتیجه این شد: ۹۹٪ کاهش در خطای میانه (از ۵۷۰- مبی‌بایت به ۴.۶- مبی‌بایت). این راه‌حل خودتصحیح هم هست؛ چون بر پایه‌ی رفتار مشاهده‌شده‌ست، اگه کد compaction عوض بشه، تخمین‌ها توی اجرای بعدی خودشون رو اصلاح می‌کنن.

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

نکات کلیدی:

• Mixpanel خطای میانه‌ی تخمین حافظه‌ی خط لوله‌اش رو ۹۹٪ کم کرد
• ضریب ثابت قدیمی (حجم × ۲.۵) اغلب صدها مگابایت اشتباه می‌کرد و OOM می‌ساخت
• راه‌حل ساده: استفاده از حافظه‌ی واقعیِ اجرای قبلیِ هر datashard به‌عنوان تخمین بعدی
• درس: نقش هوش مصنوعی رو با شعاع انفجار تطبیق بده؛ AI برای تحلیل، انسان برای پیاده‌سازی