MLOps چیست و چرا مدل بدون آن میپوسد؟
نرمافزار معمولی وقتی خراب میشود، خطا میدهد. مدل وقتی خراب میشود، همچنان جواب میدهد — فقط جوابهایش بدتر میشوند، آرام و بدون اینکه چیزی قرمز شود.
این تفاوت، دلیل وجود MLOps است.
چرا مدل بد میشود
دنیا عوض میشود. مدلی که روی رفتار خرید پارسال آموزش دیده، امسال با سبد متفاوتی روبروست. مدلی که تیکتها را دستهبندی میکند، بعد از عرضهٔ یک محصول جدید دستهای میبیند که در دادهٔ آموزشش نبوده.
داده ورودی عوض میشود. سامانهٔ بالادستی فیلدی را تغییر میدهد، فرمت تاریخ جابهجا میشود، یا واحدی که قبلاً گرم بود کیلوگرم میشود. مدل همچنان عدد برمیگرداند.
اسناد بهروز میشوند و نمایه نمیشود. در سامانههای RAG رایجترین حالت است: بخشنامه عوض شده، نمایهٔ برداری هنوز نسخهٔ قدیمی را دارد، و سامانه با اطمینان از سند منسوخ جواب میدهد.
هیچکدام از اینها خطا تولید نمیکند. به همین دلیل معمولاً وقتی کشف میشوند که مشتری یا کارشناس شکایت کند.
چه چیزی باید نسخه داشته باشد
اگر یک جملهٔ عملی از این مقاله بردارید، این باشد: باید بتوانید خروجی امروز را بازتولید کنید.
برای آن، سه چیز نسخه میخواهند:
خود مدل، با تاریخ و شمارهٔ نسخه.
دادهای که با آن ساخته شده — یا دستکم اینکه کدام برش از داده بوده.
و کد و پیکربندی: دستور سامانه، اندازهٔ قطعه، آستانهها، مدل بردارسازی.
آن مورد سوم را بیشتر از همه فراموش میکنند. تغییر یک آستانه در پیکربندی، رفتار سامانه را بهاندازهٔ تعویض مدل عوض میکند و اگر جایی ثبت نشود، هفتهٔ بعد کسی نمیفهمد چرا نتایج فرق کردهاند.
پایش: سه لایه
سلامت فنی. تأخیر پاسخ، نرخ خطا، مصرف. همان چیزی که برای هر سرویس دیگری هم میسنجید.
سلامت ورودی. این لایه مخصوص مدل است و معمولاً غایب. توزیع ورودیها را بسنجید: طول متن، تعداد فیلدهای خالی، سهم مقادیر ناشناخته. اگر امروز ناگهان سی درصد ورودیها فیلدی خالی دارند که دیروز نداشتند، یک جای بالادست عوض شده و شما زودتر از هر شکایتی میفهمید.
سلامت خروجی. توزیع نتایج. اگر مدل دستهبندی شما تا هفتهٔ پیش ده درصد تیکتها را «مالی» میدید و حالا چهل درصد، اتفاقی افتاده — یا در دنیای واقعی، یا در مدل.
هیچکدام از اینها به داده برچسبخورده نیاز ندارند، و همین ارزانشان میکند.
سنجش کیفیت واقعی
پایش توزیع میگوید چیزی عوض شده؛ نمیگوید بدتر شده. برای آن به معیار نیاز دارید.
مجموعهٔ آزمون ثابت، که هر بار تغییری دادید روی همان اجرا شود. این حداقل است.
نمونهگیری دورهٔای از خروجی واقعی، با بازبینی انسانی. پرهزینهتر و تنها راه دیدن چیزی که در مجموعهٔ آزمون شما نیست.
و بازخورد ضمنی: کارشناسی که پیشنویس پیشنهادی سامانه را اصلاح میکند، در واقع دارد به شما میگوید کجا غلط بوده. اگر آن اصلاحها ذخیره نشوند، ارزشمندترین دادهٔ رایگان پروژه را دور ریختهاید.
سنجههای بیشتر در ارزیابی کیفیت پاسخ هوش مصنوعی هست.
بازآموزی: کی و چطور
سه الگو، به ترتیب بلوغ:
دستی و دورهای. هر چند ماه یک بار، آدمی تصمیم میگیرد. برای بیشتر سازمانهای ایرانی این کاملاً کافی است و پیشنهاد ما هم همین است تا وقتی که واقعاً لازم شود.
آستانهمحور. وقتی سنجهٔ کیفیت از حدی پایین رفت، هشدار داده میشود و بازآموزی شروع.
خودکار کامل. خط لولهٔ خودکار. جذاب است و ریسک بزرگی دارد: اگر داده آلوده شود، مدل بد را خودکار به تولید فرستادهاید.
هر سه به یک چیز مشترک نیاز دارند که غیرقابل مذاکره است: راه برگشت. باید بتوانید در چند دقیقه به نسخهٔ قبلی برگردید. اگر این را ندارید، بازآموزی خودکار نکنید.
استقرار
مدل جدید را یکباره جای قبلی نگذارید.
سایهای: مدل جدید همان ورودیها را میگیرد ولی خروجیاش استفاده نمیشود، فقط مقایسه میشود. کاملاً بیریسک و بهترین راه اثبات بهبود.
تدریجی: بخش کوچکی از ترافیک، و بعد افزایش.
و آمادهبودن برای برگشت، همیشه.
لازم نیست از اول بزرگ ببندید
MLOps در متنهای عمومی معمولاً بهشکل یک پشتهٔ ابزاری مفصل معرفی میشود. برای سازمانی با یکی دو مدل در تولید، این زیادی است.
چیزی که واقعاً از روز اول لازم است، کوتاه است: نسخهبندی مدل و پیکربندی، ثبت ورودی و خروجی، یک مجموعهٔ آزمون ثابت، و یک راه برگشت.
این چهار تا را میشود با ابزارهایی که همین حالا دارید ساخت. بقیه وقتی بیاید که تعداد مدلها یا تیم بزرگ شود — نه زودتر، چون ابزاری که کسی نگهش نمیدارد خودش به بدهی تبدیل میشود.