**به نام یگانه هستی بخش**
## **چکیده**
در این پروژه هدف طراحی و پیاده سازی یک *سیستم پیشنهادگر* به منظور پیشنهاد مطالب بلاگ‌های وردپرس به کاربران مطابق سلیقه آنان خواهد بود. برای این منظور ابتدا در بخش اول به اختصار سیستم‌های پیشنهادگر را معرفی و انواع آن را ذکر می‌کنیم. سپس با تمرکز بر روی "سیستم پیشنهادگر ترکیبی" تلاش خواهیم کرد تا سیستمی مناسب مسئله مورد نظر طراحی کنیم.
# ۱.مقدمه
در دنیای امروز، شبکه جهانی وب به عنوان ابزاری فراگیر به منظور رفع نیازهای مختلف مورد استفاده قرار گرفته است و حدود نیمی از جمعیت کره زمین از آن استفاده می‌کنند.[1] جست و جوی اطلاعات مورد نیاز ، تبادل اطلاعات ، برقراری روابط اجتماعی ، خرید و فروش کالا و حتی گذراندن اوقات فراغت ، امروزه توسط بسیاری از افراد در بستر وب صورت می‌پذیرد.
استقبال کاربران از وب سبب شده فعالان این حوزه تمرکز اصلی خود را بر ارتفاء هر چه بیشتر سطح کیفی خدمات به منظور جذب مخاطب بیشتر، قرار دهند. و مسلما کسی برنده میدان رقابت خواهد بود که مخاطب خود را بهتر شناخته و مطابق سلیقه او ، خدمات خویش را ارائه دهد.
سیستم‌های پیشنهادگر (Recommender Systems) از میانه دهه 1990 به عنوان یک زمینه پژوهشی مستقل به منظور پاسخ به همین نیاز، یعنی شناخت مخاطب و ارائه آیتمی که بدان علاقه‌مند است، مطرح شده‌اند[2][3]. در اینجا *آیتم* هر محصول یا خدمتی است که به مخاطب ارائه میشود ( مانند کتاب، فیلم، اخبار ، صفحات وب ، نتایج جست و جو و … ).
## ۱.۱.سیستم پیشنهادگر
مجموعه‌ای از ابزارهای نرم‌افزاری و روش‌هایی است که به وسیله آن می‌توان آیتمی که کاربر ممکن است به آن علاقه‌مند باشد را به او پیشنهاد داد. هدف اصلی سامانه پیشنهادگر افزایش تعداد پیشنهادهای مؤثر است.
دلایل استفاده از سامانه پیشنهادگر را می‌توان موارد زیر دانست[2]:
+ **افزایش تعداد فروش کالا**
یکی از مهمترین دلایل استفاده از سامانه پیشنهادگر فروش کالاهایی است که در برابر کالاهای پرفروش قرار دارند. این امر را می‌توان به افزایش تعداد مشاهده یک پست در وب سایت‌های اجتماعی، خبری و … نگاشت داد.
+ ** فروش کالاهای متنوع**
هدف دیگر استفاده از سامانه پیشنهادگر کمک به کاربر به منظور پیدا کردن آیتمی است که در حالت عادی بدون یک پیشنهاد دقیق ، به سختی یافت میشود.
+ **افزایش سطح رضایت کاربران **
اگر سامانه پیشنهادگر به خوبی طراحی شود ، می‌تواند تجربه کاربری سرویس ارائه شده را بهبود بخشد. کاربر پیشنهادها را مرتبط با سلیقه خود می‌یابد و از تعامل با سیستم لذت خواهد برد.
+ ** افزایش سطح وفاداری کاربران**
کاربران نسبت به سیستمی که با آنها مطابق سلیقه‌شان رفتار میکند و خود را بر اساس اطلاعات به دست آمده از سابقه تعامل کاربر و سلیقه‌مندی او تطبیق می‌هد، وفادار خواهند بود و به راحتی سیستم دیگری را به عنوان جایگزین انتخاب نخواهند کرد.
+ **درک بهتر خواسته‌های کاربران**
اطلاعات به دست آمده از تعامل کاربران با سیستم، اطلاعات بسیار ارزشمندی به شمار می‌آیند. بررسی و آنالیز این اطلاعات می‌تواند در تعیین سیاست‌های کلی و مدیریت منابع و انتخاب آیتم‌های ارائه شونده به منظور سود آوری و پاسخ به نیاز کاربران کمک شایانی نماید.
در نتیجه سامانه پیشنهادگر باید بین نیازهای کاربر و ارائه دهنده خدمت نوعی تعادل ایجاد کرده تا سرویس ارائه شده برای هر دو طرف ارزشمند و سودآور باشد.
## ۲.۱.داده ها و اطلاعات در سیستم‌های پیشنهادگر
از دیدگاه فنی سامانه پیشنهادگر ها سیستم های پردازش اطلاعاتی هستند که به صورت فعال به عنوان جزئی از سیستم اصلی به جمع آوری اطلاعات مختلف می‌پردازند-اطلاعاتی در مورد آیتم‌های پیشنهاد شده و کاربرانی که پیشنهادها را دریافت می‌کنند-.
در تقسیم بندی کلی از منظر وابستگی به این اطلاعات سیستم‌های پیشنهادگر به دو دسته تقسیم می‌شوند[2]:
+ **دسته اول** تنها از اطلاعات ساده و پایه (مانند امتیاز کاربران به آیتم‌ها) استفاده می‌کنند.
+ در مقابل **دسته دوم** از روش‌هایی استفاده می‌کنند که از اطلاعات مریوط به هستی شناسی کاربران و آیتم‌ها بهره می‌برند.
در هر حال، به عنوان یک تقسیم بندی کلی اطلاعات جمع آوری شده به سه موجودیت کلی مرتبط‌اند[2]:
1. آیتم‌ها
2. کاربران
3. تراکنش‌ها، که توصیف کننده ارتباط بین کاربر و آیتم‌ها هستند.
## ۳.۱.تقسیم بندی سیستم‌های پیشنهادگر
به منظور ارائه یک دید کلی از انواع سامانه پیشنهادگر تقسیم بندی زیر را به طور خلاصه مطرح می‌کنیم[3]:.
1. **محتوا محور**[^Content-based]
سیستم یاد می‌گیرد تا آیتم‌هایی را پیشنهاد دهد که مشابه آیتم‌هایی است که کاربر در گذشته برگزیده. مقایسه آیتم‌ها بر اساس ویژگی‌هایی صورت می‌گیرد که به آنها نسبت داده شده.(مانند ژانر یک فیلم و یا برچسب‌های یک سند)
2. ** کاربر محور**[^Collaborative filtering]
حالت کلی و ساده‌ترین نوع این سیستم به کاربران فعال سیستم آیتم‌هایی را پیشنهاد می‌دهد که سایر کاربران با سلیقه مشابه در گذشته برگزیده‌اند. تشابه سلیقه دو کاربر بر اساس سابقه امتیاز دهی کاربران به آیتم‌ها محاسبه میشود. این سیستم معروف‌ترین نوع سامانه پیشنهادگر است.
3. **ویژگی‌هاى جمعیتى محور**[^Demography based]
این سیستم آیتم‌ها را بر اساس ویژگی‌های جمعیتی (مانند محل زندگی، سن، جنسیت و …) پیشنهاد میکند.
4. **دانش محور**[^Knowledge-based]
این نوع سیستم آیتم‌ها را بر اساس دامنه‌ی مشخصی از دانش، در این زمینه که ویژگی‌های یک آیتم تا چه اندازه مطابق نیازها و سلیقه کاربر خواهد بود، پیشنهاد میکند. سیستم‌های محدودیت محور[^Constraint-based] نوع دیگری از سیستم‌های دانش محور محسوب می‌گردند.
سیستم‌های دانش محور نسبت به سایر سیستم‌ها در بدو راه اندازی بهتر عمل می‌کنند و می‌توانند مجهز به زیر سیستم‌های یادگیری نباشند(از دامنه دانش مشخص شده اولیه استفاده کنند)، اما اکثرا از متدهایی به منظور استفاده از سابقه تعامل کاربر با سیستم استفاده می‌کنند تا عملکرد بهتری داشته باشند.
5. **جامعه محور**[^Community-based]
این سیستم آیتم‌ها را بر اساس سلیقه دوستان کاربر مورد نظر و روابط اجتماعی او پیشنهاد میکند. با رشد شبکه‌های اجتماعی این سیستم‌ها اخیرا مورد توجه قرار گرفته‌اند.
6. **سیستم ترکیبی**[^Hybrid recommender systems]
این سیستم ترکیبی از سیستم‌های اشاره شده در موارد فوق است. یک سیستم ترکیبی متشکل از سیستم‌های A و B سعی دارد تا از مزایای A برای پوشش معایب B استفاده کند. به عنوان مثال سیستم collaborative filtering قادر به پیشنهاد آیتم‌های جدیدی که توسط هیچ یک از کاربران امتیاز دهی نشده‌اند ، نیست اما این مشکل در سیستم محتوا محور وجود ندارد چرا که پیشنهادها بر اساس ویژگی آیتم‌ها صورت می‌پذیرد. با در نظر گرفتن دو سامانه پیشنهادگر روش‌های متعددی برای ایجاد یک سیستم ترکیبی ارائه شده است. (برای توضیحات دقیق‌تر رجوع شود به [3])
در این پروژه سعی بر این خواهد بود تا یک سیستم پیشنهادگر ترکیبی مبتنی بر یادگیری، بر اساس سیستم‌های محتوا محور و کاربر محور ، پیاده‌سازی شود برای تست و توسعه سیستم از داده‌های مربوط به پست‌ها و کاربران وردپرس برگرفته از [Kaggle.com](https://www.kaggle.com/c/predict-wordpress-likes/data) استفاده خواهیم کرد.
این مجموعه شامل اطلاعاتی در مورد پست‌ها (متن، رده و برچسب‌ها) و کاربران (پست‌های لایک شده توسط آنها) می‌باشد.
## ۴.۱.چالش‌های پیش رو
تمامی سیستم‌های مبتنی بر یادگیری (Collaborative، Content-based، Demographic) در ارائه پیشنهاد برای آیتم‌ها و کاربران جدید دارای مشکل هستنند[3]. (**cold-start problem**)
این مشکل به بیان دیگر به صورت مسئله حفظ *ثبات*[^stability] در برابر *انعطاف‌پذیری*[^plasticity] بیان میشود.به عنوان مثال کاربری که از ورزش به هنر تغییر علاقه می‌دهد تا مدت ها پیشنهادهای ورزشی دریافت خواهد کرد. برخی سیستم‌های انطباقی[^adaptive systems] با *کاهش تاثیر امتیازات در اثر گذشت زمان* به حل این مشکل می‌پردازند[4] [5] اما این سیستم‌ها نیز با ریسک از دست دادن اطلاعات در مورد علاقه‌مندی‌های ثابتی که کاربر به ندرت به آنها مراجعه میکند نیز مواجه‌اند. برای مثال یک کاربر ممکن است نسبت به وقایع زلزله علاقه‌مند باشد اما تا زمانی که زلزله جدیدی رخ ندهد، کاربر به سراغ این نوع اطلاعات نرود.[3]
# ۲.سیستم پیشنهادگر ترکیبی
سیستم‌های پیشنهادگر ترکیبی به منظور حل مسئله *cold-start* که در بالا بدان اشاره شد، مطرح شده‌اند، در این بخش ابتدا ۷ روش ترکیب سیستم‌های پیشنهادگر را به اختصار ذکر خواهیم نمود[3] سپس الگوریتمهای پایه‌ای را که در این سیستم‌ها استفاده می‌شوند ذکر خواهیم کرد و در آخر چگونگی مدل سازی کاربران را به منظور مقدمه مرحله پیاده‌سازی شرح خواهیم داد.
## ۱.۲.استراتژی‌های ایجاد یک پیشنهادگر ترکیبی
1. ترکیب وزنی[^Weighted] : ترکیب عددی امتیاز خروجی سیستم‌ها به عنوان خروجی نهایی
2. ترکیب گزینشی[^Switching] : انتخاب یکی از امتیازهای خروجی سیستم‌ها به عنوان خروجی نهایی
3. ترکیب آمیخته[^Mixed] : نمایش خروجی همه‌ی سیستم‌ها
4. ترکیب ویژگی‌ها[^Feature Combination] : ویژگی‌های استخراج شده از سیستم‌های مختلف به یک الگوریتم پیشنهادگر داده میشود
5. تقویت ویژگی‌ها[^Feature Augmentation] : ویژگی‌های استخراج شده توسط یک سیستم به عنوان بخشی از ورودی سیستم دیگر استفاده میشود
6. ترکیب آبشاری[^Cascade] : سیستم‌ها اولویت بندی شده و بر اساس این اولویت امتیاز نهایی محاسبه میگردد
7. ترکیب مرحله‌ای[^Meta-level] : با استفاده از یک سیستم بخشی از مدل ایجاد شده و به عنوان ورودی توسط سیستم دیگر استفاده میشود.
## ۲.۲.الگوریتمهای پایه
+ **Collaborative Pearson – CFP** :
الگوریتمی بر اساس الگوریتم Collaborative filtering که از *ضریب همبستگی پیرسون*[^Pearson's correlation coefficient] استفاده میکند.
$$ UserSimilarity(a,b)=\cfrac{\sum_{j=1}^{n} (V_{aj} - \bar{V_a})(V_{bj} - \bar{V_b})} { \sqrt{\sum_{j=1}^{n}(V_{aj} - \bar{V_a})^2} . \sqrt{ \sum_{j=1}^{n}(V_{bj} - \bar{V_b})^2 } } $$
$$ V_{aj} :\text{ User "a" rate to item j}$$$$\bar{V_a} : \text{Average of User "a" item rates} $$
+ **Collaborative Heuristic – CFH** :
الگوریتمی بر پایه الگوریتم Collaborative با این تفاوت که امتیازها را از دید معنایی بررسی میکند. ر.ک[6]
+ **Content-Based – CN** :
این الگوریتم بر پایه الگوریتم *naive Bayes* احتمال لایک شدن یک پست را محاسبه میکند.
## ۳.۲. مدل کاربر[^User Model]
یک *مدل کاربر* حاوی اطلاعاتی در مورد سلایق شخصی کاربر است و رفتار کاربر را در سیستم توصیف میکند.
در اینجا عناصر تشکیل دهنده مدل کاربر را به اختصار شرح می‌دهیم[7]:
### ۱.۳.۲. ارائه دهنده پروفایل کاربر[^User profile representation]
*پروفایل کاربر*[^User Profile] باید تمامی اطلاعات لازم برای مدل سازی کاربر در سیستم پیشنهادگر را دارا باشد. این پروفایل را در سیستم می‌توان به فرم‌های مختلف از قبیل : بردارهای باینری[^binary vectors] ، بردارهای ویژگی[^feature vectors]، درخت[^tree]، درخت تصمیم‌گیری[^decision tree]، شبکه‌های معنایی[^Bayesian networks] و … نمایش داد.
### ۲.۳.۲. مقدار دهی اولیه پروفایل کاربر [^User profiles initialization]
پروفایل اولیه خصوصا در سیستم‌های *محتوا محور* خالی از اطلاعات است. پروفایل‌های کاربری اغلب توسط فرم‌های پرس و جو در زمان ثبت نام کاربر، و بر اساس فعالیت کاربر در سیستم(مشاهده پست، لایک کردن و به اشتراک گذاری پست و …) تکمیل میگردد.
### ۳.۳.۲. محاسبه فاصله و شباهت پروفایل‌های کاربران [^Distance and similarity between user profiles]
برای تمامی مقادیر صفات[^attributes] پروفایل کاربری باید یک تابع جهت محاسبه فاصله توسط طراح سیستم به صورت زیر ارائه شود:
$$ \delta ^{at} : V_a \times V_a \rightarrow [0,1] \text{ for all } a \in A $$
فاصله بین پروفایل‌های کاربری می‌تواند به شیوه‌های مختلفی محاسبه گردد:
+ به عنوان اولین و ساده‌ترین راه می‌توان برای تاپل‌های i و j مجموع فواصل مقادیر آنها را فاصله دو تاپل در نظر گرفت:
$$ d(r_i ,r_j ) = \sum_{a \in A}d^{at} (r_i (a),r_j (a)) . $$
+ دومین راه محاسبه ریشه مجموع مربعات فواصل فوق است
+ و به عنوان راه سوم می‌توان با استفاده از یک ضریب بین ۰ و ۱ اهمیت هر صفت را در محاسبه فاصله تعیین نمود:
$$ d(r_i ,r_j ) = \sum_{a \in A}[c(a)*d^{at} (r_i (a),r_j (a))] . $$
به هر حال می‌توان از فرمول‌های محاسبه شباهت نظیر ضریب همبستگی پیرسون که در بخش ۲.۲ بدان اشاره شد نیز استفاده کرد.
### ۴.۳.۲. خوشه‌بندی پروفایل‌های کاربران [^User Profile Clustering]
مسئله خوشه‌بندی[^clustering] در اینجا به صورت تقسیم مجموعه کاربران (U) به زیر مجموعه‌هایی از این مجموعه بر اساس **معیارهای بهینه سازی** مطرح میشود. می‌توان از سه الگوریتم خوشه‌بندی زیر برای این منظور استفاده نمود:
+ Hierarchical
+ Euclidean
+ Similar metric space and similarity matrix
که از این میان، الگوریتمهای خانواده Euclidean و Similar metric space از محبوبیت بیشتری برخوردارند[7]
**معیار بهینه‌سازی** را می‌توان کمینه بودن فاصله کاربران در هر خوشه تعریف نمود، این فاصله به صورت زیر محاسبه خواهد شد:
$$ d(C_i) = \sum_{j=1}^r\sum_{k=1}^rd(u_j,u_k), \text{ where } r=Card(C_i) $$
در فازهای بعدی به صورت مفصل به تکمیل این بخش خواهیم پرداخت.
# ۳.کارهای مرتبط
در اینجا به چند پروژه مشابه که در آینده ممکن است از آنها استفاده شود، اشاره می‌کنیم:
## ۱.۳.Personalized recommendation of popular blog articles
در این سیستم با تمرکز بر محیط کاربری موبایل از یک پیشنهادگر ترکیبی متشکل از سیستم محتوا محور ، الگوریتم item-based collaborative filtering و خوشه بندی مقالات بلاگ استفاده شده و وزن دهی بر اساس قدمت اطلاعات صورت می‌گیرد.[8]
## ۲.۳. An Analysis of the Use of Tags in a Blog Recommender System
این سیستم برای سازمان‌دهی بلاگ‌ها، از *تگ*ها به منظور *خوشه‌بندی محتوا محور*[^content-based clustering] استفاده میکند. سپس با معرفی یک روش امتیاز دهی به خوشه‌ها، به حذف خوشه‌های نامناسب می‌پردازد.[9]
## ۳.۳.Fab: content-based, collaborative recommendation
یک سیستم پیشنهادگر ترکیبی (CB-CF) که برای کتابخانه‌های دیجیتال طراحی شده است.[10]
# ۴. پیاده‌سازی
## ۱
قدم اول در این سیستم جمع آوری مقالات بلاگ‌ها از اینترنت با استفاده از مکانیزم RSS است، در قدم بعدی با استفاده از تکنولوژی بازیابی اطلاعات (در اینجا tf-idf) مقالات پیش‌پردازش و ویژگی‌های آنها در قالب بردار کلمات[^term-vector] استخراج میشود.
در آخر با پیاده سازی یک ماژول *بررسی محبوبیت حساس به زمان*، مقالات براساس موضوع خوشه‌بندی می‌شوند و بدین ترتیب به صورت خودکار روند محبوبیت آنها پیش‌بینی میشود.
نکته دیگر قابل توجه در این سیستم مدل سازی رفتار کاربر در هنگام مرور صفحات وب، به وسیله آنالیز داده‌های مربوط به پیشینه کاربران تلفن همراه است که با استفاده از محاسبه میانگین زمان مطالعه به ازای هر کلمه مقاله تحت زمان session جاری به صورت زیر انجام میشود:
$$H_{u,s} = \frac{1}{ \mid D_{u,s} \mid } \times \sum_{d_i \in D_{u,s}} \frac{Time_u(d_i)}{DocSize(d_i)}$$
$$ d_i : \text{article i that user browsed within session s} $$
$$ D_{u,s} : \text{set of article browsed by user u in session s} $$
$$ DocSize(d_i) : \text{number of words of the article } d_i $$
$$ Time_u(d_i) : \text{user u’s browsing time on blog article } d_i $$
*پیش‌بینی الگوی رفتار کاربر*، با تکیه بر سابقه الگوی رفتار کاربر و الگوی جاری، محاسبه میشود. همان طور که در عبارت زیر می‌بینیم، با استفاده از ضریب بتا، تاثیر بیشتری برای الگوی جاری درنظر گرفته شده است:
$$ H'_{u,s+1} = \beta \times H_{u,s} + (1-\beta) \times H'_{u,s} $$
با داشتن الگوی رفتاری کاربر، می‌توان تمایل او را نسبت به مقالات سنجید و مقالات مناسب را به او پیشنهاد کرد، بدین ترتیب که با تخمین زمان مرور مقاله[^Predict Browsing Time] (PBT) و مقایسه آن با زمان مرور واقعی[^Actual Browsing Time] (ABT)، امتیاز تمایل کاربر[^preference score] (PS) برای هر مقاله محاسبه میشود.
$$ PBT_u(d_i) = DocSize(d_i) \times H'_{u,s+1} $$
$$ PS_u(d_i) = \frac{1}{1+\frac{PBT_u(d_i)}{ABT_u(d_i)}} $$
## ۲.۳. An Analysis of the Use of Tags in a Blog Recommender System
این سیستم برای سازمان‌دهی بلاگ‌ها، از *تگ*ها به منظور *خوشه‌بندی محتوا محور*[^content-based clustering] استفاده میکند. سپس با معرفی یک روش امتیاز دهی به خوشه‌ها، به حذف خوشه‌های نامناسب می‌پردازد.[9]
یک راه ساده برای پیشنهاد بلاگ پست جدید، استفاده از تگ‌هاست. روشی که توسط Technorati استفاده شد و توسط Brooks و Montanez آنالیز گردید. [9]
به هر حال مشخص شده که استفاده صرف از تگ‌ها برای این منظور مناسب نیست. در بررسی ۷۲۰۹ سند، ۳۹۳۴ تگ استفاده شده بود که از بین آنها فقط ۵۶۳ تگ ( حدود ۱۴ درصد ) دو بار یا بیشتر استفاده شده بودند و این به این معنی است که در حدود ۸۴ درصد تگ‌ها برای بازیابی کاربردی نخواهند داشت.
با خوشه‌بندی مقالات براساس محتوا و تگ، برای هر خوشه، سه نوع تگ تعریف میشود:
+ تگ‌های سری C : تگ‌هایی هستند که توسط هیچ کاربر دیگری در خوشه استفاده نشده‌اند.
+ تگ‌های سری B : تگ‌هایی که بسامد تکرار آنها ۲ یا بیشتر است، این تگ‌ها عموما کلمات قطع[^stop words] هستند و برای شاخص‌گذاری[^indexing] و بازیابی اطلاعات مناسب نخواهند بود.
+ تگ‌های سری A : سایر تگ‌ها با بسامد تکرار بالا.
+ امتیاز T : نسبت تگ‌های سری A به اندازه خوشه است:
$$ \tau_r = \frac{1}{ \mid n \mid } \frac{ \sum_{i=1}^{\mid A_r \mid} \mid a_i \mid }{ \sum_{i=1}^{\mid A_r \mid} \mid a_i \mid + \sum_{i=1}^{\mid B_r \mid} \mid b_i \mid + \sum_{i=1}^{\mid C_r \mid} \mid c_i \mid} $$
با استفاده از این معیار می‌توان خوشه‌های ضعیف را پیدا کرد و از نتایج مربوط به آنها چشم‌پوشی نمود.
## ۳.۳.Fab: content-based, collaborative recommendation
یک سیستم پیشنهادگر ترکیبی (CB-CF) که برای کتابخانه‌های دیجیتال طراحی شده است.[10]
Fab یک پیاده سازی توزیع شده از یک سامانه پیشنهادگر ترکیبی، به عنوان بخشی از کتابخانه دیجیتال دانشگاه استنفورد است. پروسه پیشنهادگر از دو بخش جمع آوری دیتا از یک پایگاه داده و انتخاب بخشی از آن برای کاربری خاص تشکیل میشود.
این سیستم بر مبنای ساخت پروفایل کاربری عمل میکند و تمرکزش بر روی دقیق بودن پروفایل‌ها است که بر اساس تعامل کاربر با سیستم و امتیازدهی‌های او به روز می‌شوند.
# ۴. پیاده‌سازی
## ۱.۴. ساختار کلی
در این جا به معرفی ساختار کلی یک سامانه پیشنهادگر و شرح قسمت‌های اصلی در آن به منظور پیاده‌سازی می‌پردازیم. سپس با استفاده از ابزار مناسب به حل مساله درنظر گرفته شده خواهیم پرداخت.
### ۱.۱.۴. داده
همانطور که در قسمت‌های مختلف اشاره شد، داده از مهمترین بخش‌های یک سامانه پیشنهادگر به شمار می‌رود. ایجاد جدول کاربر - آیتم ، ایجاد پروفایل کاربری، خوشه بندی و … همگی با استفاده از داده‌های مناسب امکان پذیر است، لذا جمع آوری، ذخیره و بازیابی صحیح دادهها از بخش‌های اصلی سامانه‌های پیشنهادگر به شمار می‌روند.
از پایگاه‌های داده می‌توان برای ذخیره‌سازی مناسب، شاخص گذاری، و بازیابی بهینه اطلاعات استفاده نمود، لذا در پیاده سازی سامانه پیشنهادگر باید یک لایه جهت دسترسی به داده بدین طریق، پیاده سازی نمود. این لایه در معماری نرم‌افزار **لایه دسترسی به داده**[^Data Access Layer] نامیده میشود و کلاس‌های این لایه را **اشیاء دسترسی به داده**[^Data Access Object] یا به اختصار DAO می‌نامند.
به دلیل تنوع و گوناگونی پایگاه‌های داده برای ایجاد یکپارچگی در سیستم این اشیاء باید از یک اینترفیس یکسان تبعیت کنند.
از مهمترین اشیاء می‌توان به موارد زیر اشاره کرد:
+ **شیء دسترسی به داده کاربر**[^User DAO]
از مهمترین قسمت‌های داده، داده‌های مربوط به کاربران است، پروفایل کاربری، الگوی رفتاری کاربر، سوابق و … می‌توانند در قالب **UserDAO** پیاده‌سازی شوند.
+ **شیء دسترسی به داده آیتم**[^Item DAO]
قطب دیگر سامانه پیشنهادگر داده‌های مربوط به آیتم‌ها هستند. ویژگی‌ها و صفات آیتم‌ها، تگ‌ها و خصوصیات مورد استفاده در بررسی محتوا محور توسط **ItemDAO** قابل دسترس خواهند بود.
+ **شیء دسترسی به داده رویداد**[^Event DAO]
رابطه بین کاربر و هر آیتم در قالب یک رویداد[^Event] ذخیره میشود. این رویداد می‌تواند کلیک کردن روی یک لینک، پسندیدن یا نپسندیدن یک آیتم، امتیاز کاربر به یک آیتم و یا حتی نظر کاربر در مورد آیتم باشد که توسط **EventDAO** ارائه میشود.
بخش مهم دیگری که در قسمت داده مطرح است، **مدل داده**[^Data Model] نام دارد که خروجی حاصل از پردازش اطلاعات خام در قالب ماتریس‌ها، خوشه‌ها و حتی شبکه‌های عصبی ذخیره و برای پیش‌بینی استفاده میگردد.
### ۲.۱.۴. منطق
هسته اصلی سامانه پیشنهادگر که با استفاده از داده‌های خام، و پردازش آنها با روش‌ها و الگوریتمهای مختلف ذکر شده، به ایجاد پروفایل کاربری و در حقیقت تشخیص سلیقه او پرداخته و خروجی آن در قالب مدل داده، به منظور پیش‌بینی و ارائه پیشنهاد به کاربران استفاده میگردد.
این پیش‌بینی به بیان ساده، پیش‌بینی امتیاز کاربر به آیتم‌هایی است که رویدادی بین آنها و کاربر ثبت نشده، لذا این بخش از برنامه را بخش **امتیازدهنده (Scorer)** نیز می‌گویند.
## ۲.۴. حل مساله
در این مرحله با معرفی دقیق داده‌های مساله، زیرساخت را تشریح می‌کنیم، سپس با معرفی ابزارهای متن‌باز و بررسی آنها به پیاده‌سازی منطق اصلی برنامه می‌پردازیم.
در مرحله اول با بهره‌گیری از الگوریتمهای پیش‌فرض، و اعمال آنها بر روی داده‌های مساله، خروجی اولیه را ارزیابی و سپس با ترکیب و یا تغییر آنها سعی در بهبود نتایج خواهیم نمود.
## ۱.۲.۴. داده‌های مساله
در این مساله همانطور که پیش از این اشاره شد از داده‌های مساله سایت Kaggle.com برای سامانه پیشنهادگر سایت وردپرس استفاده خواهیم کرد. در اینجا به صورت مفصل به توصیف این دادهها می‌پردازیم:
داده‌های اصلی مساله که در سایت موجوداند به شرح زیر است:
+ trainPosts.json
داده‌های مربوط به هر پست، که شامل شناسه بلاگ، شناسه پست، متن پست، برچسب‌ها، رده پست و آرایه‌ای که در آن تاریخ پسندیده شدن پست و شناسه کاربری که پست را پسندیده است می‌باشد و حدود 5.1 گیگابایت حجم دارد.
+ trainPostsThin.json
اطلاعات مربوط به هر پست، بدون متن، برچسب و رده آن، با حجم 127 مگابایت.
+ trainUsers.json
اطلاعات کاربران شامل شناسه کاربر و آرایه‌ای از پست‌های پسندیده شده توسط او. با حجم 101.3 مگابایت.
در سایت Kaggle به این مساله اشاره نشده که آیا این دو فایل حاوی اطلاعات یکسان در مورد پست‌ها و افراد مشخص‌اند یا خیر. لذا ما برای اطمینان، در این مرحله تنها از trainPostThin.json استفاده کردیم.
## # ۲.۲.۴. ابزارهای متن‌باز
برای پیاده‌سازی یک سامانه پیشنهادگر می‌توان از ابزارهای متن‌باز موجود استفاده نمود. ابزارهای مختلفی برای زبان‌های مختلف پیاده‌سازی شده‌اند و ما در اینجا چند نمونه از آنها را ذکر می‌کنیم[11]:
+ [MyMediaLite](http://www.ismll.uni-hildesheim.de/mymedialite/documentation)
یک کتابخانه[^library] سبک شامل الگوریتمهای سامانه پیشنهادگر کاربر محور با پشتیبانی از زبان‌های C#, F# , Clojure, Python و Ruby
+ [LensKit](http://lenskit.grouplens.org/)
یک فریم‌ورک قدرتمند برای پیاده‌سازی سامانه‌های پیشنهادگر کاربر محور و محتوا محور تحت زبان جاوا، در ادامه با تمرکز بیشتری این ابزار را بررسی خواهیم نمود.
+ [Duine](http://www.duineframework.org/)
یک فریم‌ورک تحت زبان جاوا برای پیاده‌سازی سیستم‌های پیشنهادگر ترکیبی که متاسفانه فاقد مستندات[^documentation] قوی است.
+ [Crab](http://muricoca.github.com/crab/)
یک فریم‌ورک تحت زبان Python که برای پیاده‌سازی سامانه‌های کاربر محور و آیتم محور به کار می‌رود.
+ [Waffles](waffles.sourceforge.net)
مجموعه ابزار یادگیری ماشین[^Machine Learning ToolKit] تحت زبان ++C که می‌توان از آن در پیاده‌سازی سامانه کاربر محور استفاده نمود.
## ۳.۴. فریم‌ورک LensKit
برای پیاده‌سازی سامانه پیشنهادگر در این پروژه، از فریم‌ورک LensKit استفاده می‌کنیم. زیرا یک فریم‌ورک قدرتمند تحت زبان جاوا و داری مستندات نسبتا خوبی است و مهم‌تر از همه این که در حال حاضر روی سایت [GitHub](https://github.com/lenskit) توسط توسعه‌دهندگانش پشتیبانی و توسعه داده میشود.
در اینجا به صورت مختصر به معرفی این فریم‌ورک می‌پردازیم[11]:
### ۱.۳.۴. کلیت
فریم‌ورک LensKit بر اساس *الگوی طراحی تزریق وابستگی[^Dependency Injection Design Pattern]* پیاده سازی شده است. در نتیجه عملکرد منعطفی را ارائه می‌دهد و می‌توان به کمک هسته اصلی آن و در صورت لزوم با پیاده‌سازی الگوریتمهای شخصی سازی شده یک سیستم پیشنهادگر مطلوب طراحی نمود.
در LensKit کاربران و آیتم‌ها تنها با یک عدد long به عنوان شناسه مشخص می‌شوند.
### ۲.۳.۴. اجزای اصلی و قابلیت‌ها
برای ایجاد یک سیستم پیشنهادگر توسط LensKit می‌توان اجزای مورد نیاز هسته را توسط یک شی از کلاس LenskitConfiguration به هسته تزریق[^inject] نمود. این اجزا به شرح زیر می‌باشند:
+ ItemScorer
قلب اکثر سیستم‌هایی که با LensKit پیاده‌سازی می‌شوند، همین اینترفیس است، در واقع برای پیاده سازی یک الگوریتم جدید برای LensKit باید این اینترفیس را پیاده‌سازی نمود.
اینترفیس ItemScorer ارائه دهنده امتیاز شخصی سازی شده هر کاربر به آیتم‌هاست این امتیاز می‌تواند احتمال خرید، یا معیار شباهت کسینوسی TF-IDF و … باشد.
دو پیاده سازی از این اینترفیس در LensKit موجودند که می‌توان از آنها استفاده نمود:
1. پیاده‌سازی الگوریتم Item-based Collaborative Filtering در ItemItemScorer که با استفاده از محاسبات برداری شباهت را محاسبه میکند.
2. پیاده سازی User-based Collaborative Filtering در UserUserItemScorer که با استفاده از بردار نرمال کاربر ، پیدا کردن نزدیک‌ترین همسایه و محاسبه شباهت کاربران بر اساس شباهت برداری امتیاز کاربر به آیتم‌ها را پیش‌بینی می‌نماید.
+ EventDAO
رابطه بین کاربر و آیتم‌ها در LensKit توسط اینترفیس Event مشخص میشود. برای استخراج داده و دسترسی هسته به Eventها باید اینترفیس EventDAO را پیاده سازی نمود.
در LensKit پیاده‌سازی های مختلفی برای این اینترفیس موجودند که برای کار با فایل CSV و یا JDBC استفاده می‌شوند.
+ UserDAO
یک اینترفیس به منظور دسترسی به اطلاعات کاربران، *پروفایل کاربری* تحت اینترفیس UserHistory در این قسمت قابل پیاده‌سازی است.
+ ItemDAO
یک اینترفیس به منظور دسترسی به اطلاعات آیتم‌ها، اطلاعات اضافی چون برچسب‌ها و … در این قسمت قابلیت اضافه شدن را دارند.
+ SparseVectores
یک اینترفیس برای نگاشت مقادیر long -که برای شناسه کاربران و آیتم‌ها استفاده میشود- به double -که برای مشخض نمودن امتیاز کاربران به کار می‌رود- می‌باشد. و به منظور بهینه سازی اعمال جبر خطی استفاده می‌شوند.
پیاده‌سازی‌های مختلفی از این اینترفیس موجود است که توسط ItemScorerها استفاده می‌شوند.
## ۴.۴. کارهای انجام شده و آزمایش‌ها
در اینجا به اختصار به توضیح کارهای انجام شده در این فاز برای پیاده‌سازی سیستم پیشنهادگر به وسیله LensKit می‌پردازیم:
### ۱.۴.۴. داده
همانطور که در بالا اشاره شد با در نظر گرفتن حجم و توان پردازشی در اختیار، از داده‌های trainPostsThin.json استفاده کردیم.
که متاسفانه به دلیل مواجه شدن با خطای *out of memory exception* در حین مدل سازی در زمان اجرا، مجبور شدیم نیمی از آن را نیز کنار بگذاریم.
برای سهولت کار داده‌های فوق به پایگاه داده MongoDB منتقل شد تا بتوانیم روی آنها اعمال پرس و جو[^Query] و اجتماع[^Aggregation] را به راحتی انجام دهیم.
در آخر با درنظر گرفتن این نکته که تست و اجرای برنامه برای سایرین مشکل خواهد بود، خروجی unwind شده این داده ها از MongoDB به یک فایل CSV منتقل شد تا بخشی از آن برای تست و اجرا در کنار کد قرار گیرد.
با این وجود باز هم محاسبات سنگین خواهد بود و چنانچه از Intellij استفاده می‌کنید، در هنگام تست در قسمت Run Configuration مقادیر -Xms1024M -Xmx4048M را به VM Options اضافه کنید، در غیر این صورت با خطای *OutOfMemoryError* مواجه خواهید شد.
### ۲.۴.۴. کد
برای کار با MongoDB در LensKit ابزاری در نظر گرفته نشده است، لذا ابتدا یک MongoDbDAO پیاده‌سازی شد.
این کلاس به پیاده‌سازی اینترفیس‌های EventDAO, ItemDAO, UserDAO, UserEentDAO می‌پردازد و لذا به پیاده‌سازی اینترفیس UserHistory نیز نیاز داشت که با پیاده‌سازی کلاس UserLikeHistory انجام پذیرفت.
در آخر به منظور پیکربندی سیستم پیشنهادگر، از میانگین امتیاز کاربر (UserMeanItemScorer) به عنوان معیار امتیاز پایه و سایر پیکربندی‌های پیشنهادی در راه اندازی اولیه موجود در مستندات استفاده کرده و همچنین برای کار با فایل CSV از SimpleFileRatingDAO استفاده شد.
### ۳.۴.۴. تست
برای تست و اجرای کد می‌توانید به مخزن [GitHub](https://github.com/m-nouredini/wordpress_likes_ai93) مراجعه و پروژه سپتاک (سامانه پیشنهادگر ترکیبی آیتم کاربر) را دریافت نمایید.
ارزیابی سیستم‌های پیشنهادگر و بررسی دقت آنها امری دشوار است و عموما توسط جمع آوری سوابق تعامل کاربر با سیستم و استقبال او از پیشنهادات ارائه شده انجام می‌پذیرد. از آن‌جایی که حجم دادهها بسیار زیاد و محاسبات سنگین است، عملا اجرای چندین باره و بررسی خروجی‌ها به صورت فردی امکان پذیر نخواهد بود. لذا در فاز بعدی تلاش بر این خواهد بود تا با ایجاد یک وب سایت و با همکاری افراد داوطلب ارزیابی سیستم و بهبود آن انجام پذیرد.
# ۵
همانطور که در بالا اشاره شد با در نظر گرفتن حجم و توان پردازشی در اختیار، از داده‌های trainPostsThin.json استفاده شد.
این مجموعه داده حاوی اطلاعات اولیه هر پست، و لیستی از شناسه کاربرانی است که آن را پسندیده‌اند.
متاسفانه به دلیل مواجه شدن با خطای *out of memory exception* در حین مدل سازی در زمان اجرا، به دلیل کمبود توان پردازشی دستگاه، مجبور شدیم نیمی از آن را کنار بگذاریم.
برای بهبود دسترسی و مدیریت دادهها، داده‌های فوق را به پایگاه داده MongoDB منتقل کردیم تا بتوانیم روی آنها اعمال پرس و جو[^Query] و اجتماع[^Aggregation] را به راحتی انجام دهیم.
در آخر با درنظر گرفتن این نکته که تست و اجرای برنامه برای سایرین مشکل خواهد بود، خروجی unwind شده این دادهها از MongoDB به یک فایل CSV منتقل شد تا بخشی از آن برای تست و اجرا در کنار کد قرار گیرد.
با این وجود باز هم محاسبات سنگین خواهد بود و باید در هنگام تست در قسمت Run Configuration مقادیر -Xms1024M -Xmx4048M را به VM Options اضافه کنید، در غیر این صورت با خطای *OutOfMemoryError* مواجه خواهید شد.
### ۲.۴.۴. کد
+ داده
همانطور که در بالا ذکر شد، قدم اول در پیاده‌سازی سامانه پیشنهادگر، ایجاد امکان دسترسی ساختار‌یافته به داده‌هاست.
در پایین‌ترین سطح، داده‌های ما در پایگاه داده MongoDB قرار داشت و از آن جا که برای کار با MongoDB در LensKit کلاسی ارائه نشده است، ابتدا یک MongoDbDAO پیاده‌سازی شد.
وظیفه این کلاس ایجاد امکان دسترسی به داده‌های مربوط به کاربر، آیتم و رویداد بین آن‌هاست. در نتیجه با این کلاس به پیاده‌سازی اینترفیس‌های EventDAO, ItemDAO, UserDAO, UserEventDAO پرداخته شد.
برای پیاده‌سازی پروفایل کاربری، به پیاده‌سازی اینترفیس UserHistory نیز نیاز داشتیم که با پیاده‌سازی کلاس UserLikeHistory انجام پذیرفت.
+ منطق
در آخر به منظور پیکربندی سیستم پیشنهادگر، از **میانگین امتیاز کاربر** (UserMeanItemScorer) به عنوان معیار امتیاز پایه در راه اندازی اولیه موجود در مستندات استفاده کرده و همچنین برای کار با فایل CSV از SimpleFileRatingDAO استفاده شد.
### ۳.۴.۴. تست
برای تست و اجرای کد می‌توانید به مخزن [GitHub](https://github.com/m-nouredini/wordpress_likes_ai93) مراجعه و پروژه **سپتاک (سامانه پیشنهادگر ترکیبی آیتم کاربر)** را دریافت نمایید.
# ۵. ارزیابی
ارزیابی سیستم‌های پیشنهادگر و بررسی دقت آنها امری دشوار است و عموما توسط جمع آوری سوابق تعامل کاربر با سیستم و استقبال او از پیشنهادات ارائه شده انجام می‌پذیرد. از آن‌جایی که حجم دادهها بسیار زیاد و محاسبات سنگین است، عملا اجرای چندین باره و بررسی خروجی‌ها به صورت فردی امکان پذیر نخواهد بود.
با این وجود در مجموعه داده در اختیار قرار گرفته ، قسمتی از داده به منظور ارزیابی سیستم در نظر گرفته شده، و یک کد به زبان R برای تحلیل دادهها نیز ضمیمه شده است، که متاسفانه به دلیل وجود محدودیت در توان پردازشی سیستم، اینجانب قادر به اجرا و آموزش کامل مدل و در نتیجه ارزیابی نهایی توسط داده‌های ذکر شده نبودم. به همین دلیل به بررسی خروجی به صورت موردی پرداخته شد، و همانطور که در ضمیمه پروژه موجود در مخزن گیت‌هاب قابل بررسی است، پیشنهادها از لحاظ موضوعی تا حد مناسبی مرتبط و مطلوب به نظر می‌رسند.
با تمام این‌ها در آینده نزدیک تلاش بر این خواهد بود تا با ایجاد یک وب سایت و با همکاری افراد داوطلب ارزیابی سیستم و بهبود آن انجام پذیرد.
# ۶. کارهای آینده
**سپتاک** به عنوان بخشی از یک سایت پرسش و پاسخ فارسی به منظور کمک هر چه بیشتر به مخاطبان و ارتقاء سطح کیفی تجربه کاربری استفاده خواهد شد، لذا در آینده بخش‌هایی به منظور افزایش دقت و صحت عملکرد، از قبیل پردازش زبان فارسی به منظور ارائه پیشنهادهای محتوا محور دقیق‌تر به آن اضافه خواهد شد و نیز با گذشت زمان و جمع‌آوری سوابق بازخورد کاربران نسبت به پیشنهادهای صورت گرفته ایرادات فعلی سامانه برطرف و پیشنهادها دقیق‌تر خواهد شد.
# ۷.مراجع
[1] [internetlivestats.com](http://www.internetlivestats.com/internet-users/)
[2]Ricci, F., Rokach, L., Shapir, B.: [Introduction to Recommender Systems Handbook](http://www.researchgate.net/profile/Bracha_Shapira/publication/227268858_Introduction_to_Recommender_Systems_Handbook/links/0912f5086b632e0363000000.pdf) . (2011)
[3] Burke, R. : [Hybrid web recommender systems. In: The Adaptive Web](http://www.dcs.warwick.ac.uk/~acristea/courses/CS411/2010/Book%20-%20The%20Adaptive%20Web/HybridWebRecommenderSystems.pdf), pp. 377–408. Springer Berlin / Heidelberg (2007)
[4] Billsus, D. & Pazzani, M.: [User Modelingfor Adaptive News Access](http://ics.uci.edu/~pazzani/Publications/BillsusA.pdf). UMUAI 10(2-3),147-180. (2000)
[5] Schwab, I. & Kobsa, A.: [Adaptivity through Unobstrusive Learning](http://www.ics.uci.edu/~kobsa/papers/2002-KI-kobsa.pdf).Künstliche Intelli-genz 16(3): 5-9. (2002)
[6] Burke, R.: [Knowledge-based Recommender Systems](www.cs.odu.edu/~mukka/cs795sum10dm/Lecturenotes/Day6/burke-elis00.pdf). In: A. Kent (ed.): Encyclopedia of Library and Information Syst ems, 69, Sup. 32. (2000)
[7] Sobecki, J.:[Implementations of Web-basedRecommender Systems UsingHybrid Methods](http://www.researchgate.net/profile/Janusz_Sobecki/publication/26621379_Implementations_of_Web-based_Recommender_Systems_Using_Hybrid_Methods/links/0fcfd510aa7be8d2ea000000.pdf), Institute of Applied Informatics, pp 52 - 64. (2006)
[8] Liu, DR., Tsai, PY., Chiu, PH. :[Personalized recommendation of popular blog articles for mobile applications](http://ir.nctu.edu.tw/bitstream/11536/8977/1/000288774700004.pdf) - Information Sciences, - Elsevier (2011)
[9]Hayes, C., Avesani, P. : [An analysis of the use of tags in a blog recommender system](http://www.aaai.org/Papers/IJCAI/2007/IJCAI07-445.pdf), IJCAI'07, (2007)
[10] Balabanović, M. ,Shoham, Y. :[Fab: content-based, collaborative recommendation](https://libswift.org/trac/raw-attachment/wiki/SimilarityFunction/fab-content-based-filtering.pdf) - Communications of the ACM, (1997)
[11] [Recommender systems, Part 2: Introducing open source engines](http://www.ibm.com/developerworks/library/os-recommender2/)
[12] [LensKit Documentation](http://lenskit.org/documentation/)