چرا نتفلیکس از ویژگیهای دستی فاصله گرفت
در بیشتر طول تاریخچه خود، خط لوله (pipeline) پیشنهاددهنده نتفلیکس بر هزاران ویژگی تعریفشده به صورت دستی متکی بود—بردارهای عددی که کاربران، عناوین و هر تعامل بین آنها را توصیف میکردند. مهندسان هفتهها وقت صرف میکردند تا یک نوع محتوای جدید—ورزشهای زنده، پادکست یا بازی—را به مجموعهای از ویژگیهای تازه تبدیل کنند تا سیستم بتواند پیشنهاد دادن آن را شروع کند. این فرآیند پرهزینه، شکننده و همگامسازی آن با گسترش سریع کاتالوگ دشوار بود.
مدلهای زبانی بزرگ (LLMs) آماده و موجود در بازار، بلافاصله کارآمد نبودند. آنها به سمت محبوبترین عناوین تمایل داشتند، گاهی اوقات مواردی را که وجود ندارند توهم (hallucinate) میزدند و در اجرای قوانین تجاری که پیشنهادها را ایمن و مرتبط نگه میدارد، دچار مشکل میشدند. از این رو، نتفلیکس یک خط لوله سفارشی مبتنی بر LLM ساخت که ضمن رعایت محدودیتهای عملیاتی، نقاط قوت یک مدل زبانی را حفظ میکند.
نگاهی به درون GenRec: یک خط لوله آموزشی دو مرحلهای
GenRec از دو مرحله متمایز تشکیل شده است:
- تنظیم دقیق مدل پایه (Base model fine-tuning) – نتفلیکس کار را با یک مدل زبانی با وزنهای باز (open-weight) شروع کرده و آن را بر روی دادههای داخلی تماشا تنظیم دقیق میکند. این کار بدون تغییر در معماری اصلی، واژگان کاتالوگ و الگوهای رفتاری کاربر را به مدل میآموزد.
- رتبهبندی پیشنهادها (Recommendation ranking) – مرحله دوم آموزش، مدل تنظیمشده را به یک رتبهبند تبدیل میکند که به عناوین کاندید برای یک کاربر مشخص، امتیاز میدهد. نتفلیکس این مرحله را به طور مکرر بهروزرسانی میکند تا مدل با آثار جدید و روندهای در حال تغییر همگام بماند.
تفاوت اصلی با سیستم قدیمی در نحوه تغذیه تاریخچه کاربر به مدل است. بهجای فشردهسازی جلسات تماشا در بردارهای متراکم، GenRec هر تعامل—مدت زمان پخش، لایک یا دیسلایک، و ترک زودهنگام ویدیو—را به جملات ساده انگلیسی ترجمه میکند. سپس مدل کل جلسه را مانند یک گفتگوی کوتاه میخواند و تغییرات ظریف در ترجیحات ژانر یا حال و هوا را بدون نیاز به هیچ مهندسی ویژگی (feature engineering) صریحی تشخیص میدهد.
بهبود عملکرد و کارایی
در یک آزمایش چهار هفتهای که ۱۰٪ از ترافیک نتفلیکس را در معرض GenRec قرار داد، سیستم جدید بهبودهای آماری قابل توجهی را در دو دسته معیار ایجاد کرد:
- تعامل کوتاهمدت – افزایش ۰.۱۱۵ درصدی در سیگنالهای اصلی نرخ کلیک (click-through) و زمان تماشا که محرک پیشنهادهای روزانه هستند.
- معیارهای اصلی بلندمدت – افزایش ۰.۰۰۶ درصدی در نرخ حفظ مشترکین (subscriber-retention) و امتیازات کلی رضایت که برای کسبوکار بیشترین اهمیت را دارند.
در حالت آفلاین، کیفیت رتبهبندی در یک مجموعه داده جداشده (held-out dataset) در مقایسه با خط پایه عملیاتی، ۱.۶٪ بهبود یافت. نکته خیرهکنندهتر، کارایی داده است: مرحله دوم آموزش تقریباً به ۱/۴۰ از نمونههای برچسبگذاریشدهای نیاز داشت که خط لوله سنتی برای رسیدن به همان سطح عملکرد به آنها نیاز دارد.
برای کنترل هزینههای محاسباتی، نتفلیکس مدل را با vLLM اجرا میکند؛ یک پشته سرویسدهی (serving stack) که هر کاندید را در یک مرحله عبور رو به جلو (forward pass) امتیازدهی میکند، بهجای اینکه متن تولید کند. این سیستم همچنین فیلترینگ شدیدی را اعمال میکند تا تنها رویدادهای با سیگنال بالا در پنجره بافت (context window) مدل قرار بگیرند، که باعث حذف توکنهای غیرضروری و کاهش تأخیر (latency) میشود.
معنای گذار از «ویژگیها» به «بافت» (context)
GenRec بخشی از یک جنبش گستردهتر است که در آن «مهندسی بافت» (context engineering) جایگزین ویژگیهای دستی میشود. بهجای طراحی یک معماری سفارشی برای هر وظیفه پیشنهاددهی، مهندسان تصمیم میگیرند که کدام سیگنالها را در یک پرامپت متنی قرار دهند و اجازه میدهند مدل زبانی بر روی آنها استدلال کند. این رویکرد، فرآیند ورود محتواهای جدید را سرعت میبخشد: یک قسمت پادکست یا یک بازی پخشزنده را میتوان در یک جمله توصیف کرد و بلافاصله به مجموعه پیشنهادها اضافه کرد، بدون اینکه نیاز به یک دوره چندماهه برای تعریف ویژگیها باشد.
موانع باقیمانده
سیستمهای پیشنهاددهنده مبتنی بر LLM یک راهکار جادویی (silver bullet) نیستند. تمایل آنها به تأکید بیش از حد بر موارد محبوب همچنان باعث سوگیری (bias) در کاتالوگ میشود و نیاز به GPUهای قدرتمند، هزینههای عملیاتی را افزایش میدهد. حتی با وجود vLLM و فیلترینگ شدید، سرویسدهی یک مدل زبانی بزرگ در مقیاس نتفلیکس نیازمند مهندسی دقیق برای رسیدن به اهداف تأخیر (latency) است.