شروعِ سرد در پیشنهاددهنده فقط مسئلهٔ کالایِ تازه نیست؛ کاربرِ واقعاً بدونِ سابقه هم شاهدِ رفتاریِ کافی برایِ شخصی‌سازی ندارد. اما خطایِ دریافتِ سابقه را نباید «کاربرِ تازه» حساب کنیم. این صفحه پنج وضعیتِ داده و یک گذارِ پس از نخستین تعامل را با کدِ بی‌اثر اجرا می‌کند تا ادعایِ شخصی‌سازی روشن بماند.
خالیِ موفق با دریافتِ ناموفق فرق دارد
در قراردادِ ما history_state باید دریافتِ موفق را اعلام کند تا فهرستِ خالی، واقعاً بی‌سابقه تفسیر شود. اگر دریافت خطا کرده باشد، حتی با بافرِ خالی، خروجی history_unavailable و فهرستِ پیشنهادِ خالی است. این سیاستِ آموزشی، مشکلِ دریافت را پشتِ پیشنهادِ ظاهراً شخصی پنهان نمی‌کند؛ رابطِ واقعی می‌تواند وضعیتِ در دسترس‌نبودن را صریح نشان دهد.
این تمایز از تعدادِ ردیف‌ها به‌تنهایی معلوم نمی‌شود. منبع، وضعیت و زمانِ دریافت هم بخشی از قراردادند. فایلِ حاضر درخواستِ شبکه نمی‌فرستد؛ ورودیِ وضعیت را نویسنده ساخته است تا دو شاخه را دقیق آزمایش کند. نبودِ داده را علاقهٔ صفر یا نارضایتیِ کاربر نمی‌نامیم.
سه مسیرِ روشنِ پیشنهاد
چهار محتوایِ خیالیِ K1 تا K4 با دو ویژگیِ دستی داریم. محبوبیت‌هایِ ۱۰،۸،۶ و صفر هم دادهٔ ساختگی‌اند و تعدادِ بازدیدِ اپرا نیستند. K3 غیرفعال است و پیش از امتیازدهی کنار می‌رود. وقتی دریافتِ سابقه موفق ولی فهرست خالی و ترجیحِ صریح هم ناموجود باشد، فقط ترتیبِ محبوبیتِ غیرشخصی را می‌دهیم.
اگر در همان وضعیت، ترجیحِ داوطلبانهٔ [۰،۱] به‌صراحت داده شده باشد، می‌توانیم شباهتِ ویژگی‌ها را با آن حساب کنیم. این ترجیح در تمرین از سویِ نویسنده داده شده و از هویت یا دادهٔ پنهانِ یک شخص استنباط نشده است. خروجی، منبعِ پروفایل را «ترجیحِ صریح» می‌نامد؛ سابقهٔ رفتاریِ آموخته‌شده نمی‌نامد.
پنج شاخهٔ واقعاً اجراشده
| وضعیت | مسیرِ خروجی | نتیجهٔ نخستِ مثال |
|---|---|---|
| دریافتِ موفق و سابقهٔ خالی | محبوبیتِ غیرشخصی | K1 |
| خالی با ترجیحِ داوطلبانه | محتوا از ترجیحِ صریح | K2 |
| خطایِ دریافت با بافرِ خالی | سابقه ناموجود | پیشنهاد ساخته نمی‌شود |
| پس از یک پسندِ ساختگیِ K2 | محتوا از سابقهٔ مشاهده‌شده | K4 |
| شناسهٔ سابقه در موجودی نیست | منبعِ سابقه مفقود | پروفایل اختراع نمی‌شود |
در مسیرهایِ محتوایی، تساویِ شباهت با محبوبیتِ ساختگی و سپس شناسه شکسته می‌شود. مواردِ قبلاً پسندیده‌شده نیز در این قرارداد از نامزدها حذف می‌شوند. این دو سیاست برایِ تمرین صریح‌اند و الزامِ همهٔ پیشنهاددهنده‌ها نیستند.
پس از نخستین تعامل چه عوض می‌شود؟
کد ابتدا سابقهٔ خالی را می‌گیرد؛ سپس نویسنده یک رویدادِ مثبتِ K2 در ورودیِ مرحلهٔ بعد قرار می‌دهد و تابع دوباره از همان داده پروفایل می‌سازد. K2 از نامزدها کنار می‌رود و K4 با ویژگیِ مشابه جلو می‌افتد. این گذارِ محاسبه واقعی است؛ رویدادِ کاربرِ واقعی، جمع‌آوریِ ردیاب یا آموزشِ مدلِ هم‌رفتاری نیست.
یک پسند هم ترجیحِ پایدار را اثبات نمی‌کند. تعامل می‌تواند به جایگاهِ نمایش، خطایِ ثبت یا نیازِ موقت وابسته باشد. فایلِ ما بازهٔ زمانی، نرخِ مواجهه، بازخوردِ منفی و ارزیابیِ رضایت ندارد. عددِ شباهت را احتمالِ خرید یا نتیجهٔ بهتر معرفی نمی‌کنیم.
چه چیزی به مطلبِ موجود اضافه شد؟
مقایسهٔ محتوا، هم‌رفتاری و هیبرید از قبل به کالایِ بدونِ تعامل با ویژگی امتیاز می‌دهد. مسئلهٔ این صفحه، وضعیتِ سابقهٔ کاربر، fallbackِ شفاف و گذارِ نخستین شاهد است. منبعِ اصلی هم محدودیتِ عامل‌سازیِ ماتریس برایِ موردِ تازه را توضیح می‌دهد؛ چنین مدلی اینجا اجرا نشده است.
دادهٔ ناموجود، کاربرِ تازه و سابقهٔ کم را در گزارش جدا نگه دارید. برایِ نیازِ پاسخ‌گوییِ مشتری، ورودیِ مجاز و خروجیِ قابلِ قبول را در بررسیِ نیاز با اپرا مشخص کنید. این تمرین، سرویسِ پیشنهاددهنده یا شخصی‌سازیِ آماده در اپرا را اعلام نمی‌کند.
فایل تمرین و منبع
پنج وضعیتِ سابقه و گذارِ واقعیِ کد پس از نخستین تعامل · مسیرِ fallback، ترجیحِ صریح، خطایِ دریافت و سابقهٔ تازه
منابع در 2026-11-04 خوانده شدند؛ این تاریخ، تاریخ انتشار منبع نیست. مثال‌ها و فایل‌های این راهنما آموزشی و ساختهٔ تحریریه‌اند.