مردم چقدر این نوشته‌ها را دوست دارند؟

تغییرات
ارزیابی پیاده‌سازی و گزارش نتایج

به نام یگانه هستی بخش

چکیده

در این پروژه هدف طراحی و پیاده سازی یک سیستم پیشنهادگر به منظور پیشنهاد مطالب بلاگ‌های وردپرس به کاربران مطابق سلیقه آنان خواهد بود. برای این منظور ابتدا در بخش اول به اختصار سیستم‌های پیشنهادگر را معرفی و انواع آن را ذکر می‌کنیم. سپس با تمرکز بر روی "سیستم پیشنهادگر ترکیبی" تلاش خواهیم کرد تا سیستمی مناسب مسئله مورد نظر طراحی کنیم.

۱. ۱.مقدمه

در دنیای امروز، شبکه جهانی وب به عنوان ابزاری فراگیر به منظور رفع نیازهای مختلف مورد استفاده قرار گرفته است و حدود نیمی از جمعیت کره زمین از آن استفاده می‌کنند.[1] جست و جوی اطلاعات مورد نیاز ، تبادل اطلاعات ، برقراری روابط اجتماعی ، خرید و فروش کالا و حتی گذراندن اوقات فراغت ، امروزه توسط بسیاری از افراد در بستر وب صورت می‌پذیرد.

استقبال کاربران از وب سبب شده فعالان این حوزه تمرکز اصلی خود را بر ارتفاء هر چه بیشتر سطح کیفی خدمات به منظور جذب مخاطب بیشتر، قرار دهند. و مسلما کسی برنده میدان رقابت خواهد بود که مخاطب خود را بهتر شناخته و مطابق سلیقه او ، خدمات خویش را ارائه دهد.

سیستم‌های پیشنهادگر (Recommender Systems) از میانه دهه 1990 به عنوان یک زمینه پژوهشی مستقل به منظور پاسخ به همین نیاز، یعنی شناخت مخاطب و ارائه آیتمی که بدان علاقه‌مند است، مطرح شده‌اند[2][3]. در اینجا آیتم هر محصول یا خدمتی است که به مخاطب ارائه می‌شود ( مانند کتاب، فیلم، اخبار ، صفحات وب ، نتایج جست و جو و … ).

۱.۱. ۱.۱.سیستم پیشنهادگر

مجموعه‌ای از ابزارهای نرم‌افزاری و روش‌هایی است که به وسیله آن می‌توان آیتمی که کاربر ممکن است به آن علاقه‌مند باشد را به او پیشنهاد داد. هدف اصلی سامانه پیشنهادگر افزایش تعداد پیشنهادهای مؤثر است.

دلایل استفاده از سامانه پیشنهادگر را می‌توان موارد زیر دانست[2]:

  • افزایش تعداد فروش کالا

یکی از مهمترین دلایل استفاده از سامانه پیشنهادگر فروش کالاهایی است که در برابر کالاهای پرفروش قرار دارند. این امر را می‌توان به افزایش تعداد مشاهده یک پست در وب سایت‌های اجتماعی، خبری و … نگاشت داد.

  • فروش کالاهای متنوع

هدف دیگر استفاده از سامانه پیشنهادگر کمک به کاربر به منظور پیدا کردن آیتمی است که در حالت عادی بدون یک پیشنهاد دقیق ، به سختی یافت می‌شود.

  • افزایش سطح رضایت کاربران

اگر سامانه پیشنهادگر به خوبی طراحی شود ، می‌تواند تجربه کاربری سرویس ارائه شده را بهبود بخشد. کاربر پیشنهادها را مرتبط با سلیقه خود می‌یابد و از تعامل با سیستم لذت خواهد برد.

  • افزایش سطح وفاداری کاربران

کاربران نسبت به سیستمی که با آن‌ها مطابق سلیقه‌شان رفتار می‌کند و خود را بر اساس اطلاعات به دست آمده از سابقه تعامل کاربر و سلیقه‌مندی او تطبیق می‌هد، وفادار خواهند بود و به راحتی سیستم دیگری را به عنوان جایگزین انتخاب نخواهند کرد.

  • درک بهتر خواسته‌های کاربران

اطلاعات به دست آمده از تعامل کاربران با سیستم، اطلاعات بسیار ارزشمندی به شمار می‌آیند. بررسی و آنالیز این اطلاعات می‌تواند در تعیین سیاست‌های کلی و مدیریت منابع و انتخاب آیتم‌های ارائه شونده به منظور سود آوری و پاسخ به نیاز کاربران کمک شایانی نماید.

در نتیجه سامانه پیشنهادگر باید بین نیازهای کاربر و ارائه دهنده خدمت نوعی تعادل ایجاد کرده تا سرویس ارائه شده برای هر دو طرف ارزشمند و سودآور باشد.

۱.۲. ۲.۱.داده ها و اطلاعات در سیستم‌های پیشنهادگر

از دیدگاه فنی سامانه پیشنهادگر ها سیستم های پردازش اطلاعاتی هستند که به صورت فعال به عنوان جزئی از سیستم اصلی به جمع آوری اطلاعات مختلف می‌پردازند-اطلاعاتی در مورد آیتم‌های پیشنهاد شده و کاربرانی که پیشنهادها را دریافت می‌کنند-.

در تقسیم بندی کلی از منظر وابستگی به این اطلاعات سیستم‌های پیشنهادگر به دو دسته تقسیم می‌شوند[2]:

  • دسته اول تنها از اطلاعات ساده و پایه (مانند امتیاز کاربران به آیتم‌ها) استفاده می‌کنند.

  • در مقابل دسته دوم از روش‌هایی استفاده می‌کنند که از اطلاعات مریوط به هستی شناسی کاربران و آیتم‌ها بهره می‌برند.

در هر حال، به عنوان یک تقسیم بندی کلی اطلاعات جمع آوری شده به سه موجودیت کلی مرتبط‌اند[2]:

  1. آیتم‌ها

  2. کاربران

  3. تراکنش‌ها، که توصیف کننده ارتباط بین کاربر و آیتم‌ها هستند.

۱.۳. ۳.۱.تقسیم بندی سیستم‌های پیشنهادگر

به منظور ارائه یک دید کلی از انواع سامانه پیشنهادگر تقسیم بندی زیر را به طور خلاصه مطرح می‌کنیم[3]:.

  1. محتوا محور1

سیستم یاد می‌گیرد تا آیتم‌هایی را پیشنهاد دهد که مشابه آیتم‌هایی است که کاربر در گذشته برگزیده. مقایسه آیتم‌ها بر اساس ویژگی‌هایی صورت می‌گیرد که به آن‌ها نسبت داده شده.(مانند ژانر یک فیلم و یا برچسب‌های یک سند)

  1. کاربر محور2

حالت کلی و ساده‌ترین نوع این سیستم به کاربران فعال سیستم آیتم‌هایی را پیشنهاد می‌دهد که سایر کاربران با سلیقه مشابه در گذشته برگزیده‌اند. تشابه سلیقه دو کاربر بر اساس سابقه امتیاز دهی کاربران به آیتم‌ها محاسبه می‌شود. این سیستم معروف‌ترین نوع سامانه پیشنهادگر است.

  1. ویژگی‌هاى جمعیتى محور3

این سیستم آیتم‌ها را بر اساس ویژگی‌های جمعیتی (مانند محل زندگی، سن، جنسیت و …) پیشنهاد می‌کند.

  1. دانش محور4

این نوع سیستم آیتم‌ها را بر اساس دامنه‌ی مشخصی از دانش، در این زمینه که ویژگی‌های یک آیتم تا چه اندازه مطابق نیازها و سلیقه کاربر خواهد بود، پیشنهاد می‌کند. سیستم‌های محدودیت محور5 نوع دیگری از سیستم‌های دانش محور محسوب می‌گردند.

سیستم‌های دانش محور نسبت به سایر سیستم‌ها در بدو راه اندازی بهتر عمل می‌کنند و می‌توانند مجهز به زیر سیستم‌های یادگیری نباشند(از دامنه دانش مشخص شده اولیه استفاده کنند)، اما اکثرا از متدهایی به منظور استفاده از سابقه تعامل کاربر با سیستم استفاده می‌کنند تا عملکرد بهتری داشته باشند.

  1. جامعه محور6

این سیستم‌ آیتم‌ها را بر اساس سلیقه دوستان کاربر مورد نظر و روابط اجتماعی او پیشنهاد می‌کند. با رشد شبکه‌های اجتماعی این سیستم‌ها اخیرا مورد توجه قرار گرفته‌اند.

  1. سیستم ترکیبی7

این سیستم ترکیبی از سیستم‌های اشاره شده در موارد فوق است. یک سیستم ترکیبی متشکل از سیستم‌های A و B سعی دارد تا از مزایای A برای پوشش معایب B استفاده کند. به عنوان مثال سیستم collaborative filtering قادر به پیشنهاد آیتم‌های جدیدی که توسط هیچ یک از کاربران امتیاز دهی نشده‌اند ، نیست اما این مشکل در سیستم محتوا محور وجود ندارد چرا که پیشنهادها بر اساس ویژگی آیتم‌ها صورت می‌پذیرد. با در نظر گرفتن دو سامانه پیشنهادگر روش‌های متعددی برای ایجاد یک سیستم ترکیبی ارائه شده است. (برای توضیحات دقیق‌تر رجوع شود به [3])

در این پروژه سعی بر این خواهد بود تا یک سیستم پیشنهادگر ترکیبی مبتنی بر یادگیری، بر اساس سیستم‌های محتوا محور و کاربر محور ، پیاده‌سازی شود برای تست و توسعه سیستم از داده‌های مربوط به پست‌ها و کاربران وردپرس برگرفته از Kaggle.com استفاده خواهیم کرد.

این مجموعه شامل اطلاعاتی در مورد پست‌ها (متن، رده و برچسب‌ها) و کاربران (پست‌های لایک شده توسط آن‌ها) می‌باشد.

۱.۴. ۴.۱.چالش‌های پیش رو

تمامی سیستم‌های مبتنی بر یادگیری (Collaborative، Content-based، Demographic) در ارائه پیشنهاد برای آیتم‌ها و کاربران جدید دارای مشکل هستنند[3]. (cold-start problem)

این مشکل به بیان دیگر به صورت مسئله حفظ ثبات8 در برابر انعطاف‌پذیری9 بیان می‌شود.به عنوان مثال کاربری که از ورزش به هنر تغییر علاقه می‌دهد تا مدت ها پیشنهادهای ورزشی دریافت خواهد کرد. برخی سیستم‌های انطباقی10 با کاهش تاثیر امتیازات در اثر گذشت زمان به حل این مشکل می‌پردازند[4] [5] اما این سیستم‌ها نیز با ریسک از دست دادن اطلاعات در مورد علاقه‌مندی‌های ثابتی که کاربر به ندرت به آن‌ها مراجعه میکند نیز مواجه‌اند. برای مثال یک کاربر ممکن است نسبت به وقایع زلزله علاقه‌مند باشد اما تا زمانی که زلزله جدیدی رخ ندهد، کاربر به سراغ این نوع اطلاعات نرود.[3]

۲. ۲.سیستم پیشنهادگر ترکیبی

سیستم‌های پیشنهادگر ترکیبی به منظور حل مسئله cold-start که در بالا بدان اشاره شد، مطرح شده‌اند، در این بخش ابتدا ۷ روش ترکیب سیستم‌های پیشنهادگر را به اختصار ذکر خواهیم نمود[3] سپس الگوریتم‌های پایه‌ای را که در این سیستم‌ها استفاده می‌شوند ذکر خواهیم کرد و در آخر چگونگی مدل سازی کاربران را به منظور مقدمه مرحله پیاده‌سازی شرح خواهیم داد.

۲.۱. ۱.۲.استراتژی‌های ایجاد یک پیشنهادگر ترکیبی

  1. ترکیب وزنی11 : ترکیب عددی امتیاز خروجی سیستم‌ها به عنوان خروجی نهایی

  2. ترکیب گزینشی12 : انتخاب یکی از امتیازهای خروجی سیستم‌ها به عنوان خروجی نهایی

  3. ترکیب آمیخته13 : نمایش خروجی همه‌ی سیستم‌ها

  4. ترکیب ویژگی‌ها14 : ویژگی‌های استخراج شده از سیستم‌های مختلف به یک الگوریتم پیشنهادگر داده میشود

  5. تقویت ویژگی‌ها15 : ویژگی‌های استخراج شده توسط یک سیستم به عنوان بخشی از ورودی سیستم دیگر استفاده می‌شود

  6. ترکیب آبشاری16 : سیستم‌ها اولویت بندی شده و بر اساس این اولویت امتیاز نهایی محاسبه می‌گردد

  7. ترکیب مرحله‌ای17 : با استفاده از یک سیستم بخشی از مدل ایجاد شده و به عنوان ورودی توسط سیستم دیگر استفاده می‌شود.

۲.۲. ۲.۲.الگوریتم‌های پایه

  • ‌Collaborative Pearson – CFP :

الگوریتمی بر اساس الگوریتم Collaborative filtering که از ضریب هم‌بستگی پیرسون18 استفاده می‌کند.

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 احتمال لایک شدن یک پست را محاسبه می‌کند.

۲.۳. ۳.۲. مدل کاربر19

یک مدل کاربر حاوی اطلاعاتی در مورد سلایق شخصی کاربر است و رفتار کاربر را در سیستم توصیف می‌کند.

در اینجا عناصر تشکیل دهنده مدل کاربر را به اختصار شرح می‌دهیم[7]:

۲.۳.۱. ۱.۳.۲.‌ ارائه دهنده پروفایل کاربر20

پروفایل کاربر21 باید تمامی اطلاعات لازم برای مدل سازی کاربر در سیستم پیشنهادگر را دارا باشد. این پروفایل را در سیستم می‌توان به فرم‌های مختلف از قبیل : بردارهای باینری22 ، بردارهای ویژگی23، درخت24، درخت تصمیم‌گیری25، شبکه‌های معنایی26 و … نمایش داد.

۲.۳.۲. ۲.۳.۲. مقدار دهی اولیه پروفایل کاربر 27

پروفایل اولیه خصوصا در سیستم‌های محتوا محور خالی از اطلاعات است. پروفایل‌های کاربری اغلب توسط فرم‌های پرس و جو در زمان ثبت نام کاربر، و بر اساس فعالیت کاربر در سیستم(مشاهده پست، لایک کردن و به اشتراک گذاری پست و …) تکمیل می‌گردد.

۲.۳.۳. ۳.۳.۲.‌ محاسبه فاصله و شباهت پروفایل‌های کاربران 28

برای تمامی مقادیر صفات29 پروفایل کاربری باید یک تابع جهت محاسبه فاصله توسط طراح سیستم به صورت زیر ارائه شود:

\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))] .

به هر حال می‌توان از فرمول‌های محاسبه شباهت نظیر ضریب همبستگی پیرسون که در بخش ۲.۲ بدان اشاره شد نیز استفاده کرد.

۲.۳.۴. ۴.۳.۲. خوشه‌بندی پروفایل‌های کاربران 30

مسئله خوشه‌بندی31 در اینجا به صورت تقسیم مجموعه کاربران (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

این سیستم برای سازمان‌دهی بلاگ‌ها، از تگها به منظور خوشه‌بندی محتوا محور32 استفاده می‌کند. سپس با معرفی یک روش امتیاز دهی به خوشه‌ها، به حذف خوشه‌های نامناسب می‌پردازد.[9]

۳.۳. ۳.۳.‌Fab: content-based, collaborative recommendation

یک سیستم پیشنهادگر ترکیبی (CB-CF) که برای کتابخانه‌های دیجیتال طراحی شده‌ است.[10]

۴. ۴. پیاده‌سازی

۴.۱. ۱.۴. داده‌های مساله

در این مساله همان‌طور که پیش از این اشاره شد از داده‌های مساله سایت Kaggle.com برای سامانه پیشنهادگر سایت وردپرس استفاده خواهیم کرد. در اینجا به صورت مفصل به توصیف این داده‌ها می‌پردازیم:

داده‌های اصلی مساله که در سایت موجوداند به شرح زیر است:

  • ‌trainPosts.json
    داده‌های مربوط به هر پست، که شامل شناسه بلاگ، شناسه پست، متن پست، برچسب‌ها، رده پست و آرایه‌ای که در آن تاریخ پسندیده شدن پست و شناسه کاربری که پست را پسندیده است می‌باشد و حدود 5.1 گیگابایت حجم دارد.

  • ‌trainPostsThin.json
    اطلاعات مربوط به هر پست، بدون متن، برچسب و رده آن، با حجم 127 مگابایت.

  • ‌trainUsers.json
    اطلاعات کاربران شامل شناسه کاربر و آرایه‌ای از پست‌های پسندیده شده توسط او. با حجم 101.3 مگابایت.

در سایت Kaggle به این مساله اشاره نشده که آیا این دو فایل حاوی اطلاعات یکسان در مورد پست‌ها و افراد مشخص‌اند یا خیر. لذا ما برای اطمینان، در این مرحله تنها از trainPostThin.json استفاده کردیم.

۴.۲. ۲.۴. ابزارهای متن‌باز

برای پیاده‌سازی یک سامانه پیشنهادگر می‌توان از ابزارهای متن‌باز موجود استفاده نمود. ابزارهای مختلفی برای زبان‌های مختلف پیاده‌سازی شده‌اند و ما در اینجا چند نمونه از آن‌ها را ذکر می‌کنیم[11]:

  • ‌MyMediaLite یک کتاب‌خانه33 سبک شامل الگوریتم‌های سامانه پیشنهادگر کاربر محور با پشتیبانی از زبان‌های C#, F# , Clojure, Python و Ruby

  • ‌LensKit
    یک فریم‌ورک قدرتمند برای پیاده‌سازی سامانه‌های پیشنهادگر کاربر محور و محتوا محور تحت زبان جاوا، در ادامه با تمرکز بیشتری این ابزار را بررسی خواهیم نمود.

  • ‌Duine
    یک فریم‌ورک تحت زبان جاوا برای پیاده‌سازی سیستم‌های پیشنهادگر ترکیبی که متاسفانه فاقد مستندات34 قوی است.

  • ‌Crab
    یک فریم‌ورک تحت زبان Python که برای پیاده‌سازی سامانه‌های کاربر محور و آیتم محور به کار می‌رود.

  • ‌Waffles
    مجموعه ابزار یادگیری ماشین35 تحت زبان ++C که می‌توان از آن در پیاده‌سازی سامانه کاربر محور استفاده نمود.

۴.۳. ۳.۴. فریم‌ورک LensKit

برای پیاده‌سازی سامانه پیشنهادگر در این پروژه، از فریم‌ورک LensKit استفاده می‌کنیم. زیرا یک فریم‌ورک قدرتمند تحت زبان جاوا و داری مستندات نسبتا خوبی است و مهم‌تر از همه این که در حال حاضر روی سایت GitHub توسط توسعه‌دهندگانش پشتیبانی و توسعه داده می‌شود.
در اینجا به صورت مختصر به معرفی این فریم‌ورک می‌پردازیم[11]:

۴.۳.۱. ۱.۳.۴. کلیت

فریم‌ورک LensKit بر اساس الگوی طراحی تزریق وابستگی36 پیاده سازی شده است. در نتیجه عملکرد منعطفی را ارائه می‌دهد و می‌توان به کمک هسته اصلی آن و در صورت لزوم با پیاده‌سازی الگوریتم‌های شخصی سازی شده یک سیستم پیشنهادگر مطلوب طراحی نمود.
در LensKit کاربران و آیتم‌ها تنها با یک عدد long به عنوان شناسه مشخص می‌شوند.

۴.۳.۲. ۲.۳.۴. اجزای اصلی و قابلیت‌ها

برای ایجاد یک سیستم پیشنهادگر توسط LensKit می‌توان اجزای مورد نیاز هسته را توسط یک شی از کلاس LenskitConfiguration به هسته تزریق37 نمود. این اجزا به شرح زیر می‌باشند:

  • ‌ItemScorer
    قلب اکثر سیستم‌هایی که با LensKit پیاده‌سازی می‌شوند، همین اینترفیس است، در واقع برای پیاده سازی یک الگوریتم جدید برای LensKit باید این اینترفیس را پیاده‌سازی نمود.
    اینترفیس ItemScorer ارائه دهنده امتیاز شخصی سازی شده هر کاربر به آیتم‌هاست این امتیاز می‌تواند احتمال خرید، یا معیار شباهت کسینوسی TF-IDF و … باشد.
    دو پیاده سازی از این اینترفیس در LensKit موجودند که می‌توان از آن‌ها استفاده نمود:

  • پیاده‌سازی الگوریتم Item-based Collaborative Filtering در ItemItemScorer که با استفاده از محاسبات برداری شباهت را محاسبه می‌کند.

  • پیاده سازی 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 منتقل شد تا بتوانیم روی آن‌ها اعمال پرس و جو38 و اجتماع39 را به راحتی انجام دهیم.
در آخر با درنظر گرفتن این نکته که تست و اجرای برنامه برای سایرین مشکل خواهد بود، خروجی unwind شده این داده ها از ‌MongoDB به یک فایل CSV منتقل شد تا بخشی از آن برای تست و اجرا در کنار کد قرار گیرد.
با این وجود باز هم محاسبات سنگین خواهد بود و چنانچه از Intellij استفاده می‌کنید، در هنگام تست در قسمت Run Configuration مقادیر -Xms1024M -Xmx4048M را به VM Options اضافه کنید، در غیر این صورت با خطای OutOfMemoryError مواجه خواهید شد.

۴.۴.۲. ‌ ۲.۴.۴. کد

برای کار با MongoDB در LensKit ابزاری در نظر گرفته نشده است، لذا ابتدا یک MongoDbDAO پیاده‌سازی شد.
این کلاس به پیاده‌سازی اینترفیس‌های EventDAO, ItemDAO, UserDAO, UserEentDAO می‌پردازد و لذا به پیاده‌سازی اینترفیس UserHistory نیز نیاز داشت که با پیاده‌سازی کلاس UserLikeHistory انجام پذیرفت.
در آخر به منظور پیکربندی سیستم پیشنهادگر، از میانگین امتیاز کاربر (UserMeanItemScorer) به عنوان معیار امتیاز پایه و سایر پیکربندی‌های پیشنهادی در راه اندازی اولیه موجود در مستندات استفاده کرده و همچنین برای کار با فایل CSV از SimpleFileRatingDAO استفاده شد.

۴.۴.۳. ۳.۴.۴. تست

برای تست و اجرای کد می‌توانید به مخزن GitHub مراجعه و پروژه سپتاک (سامانه پیشنهادگر ترکیبی آیتم کاربر) را دریافت نمایید.
ارزیابی سیستم‌های پیشنهادگر و بررسی دقت آن‌ها امری دشوار است و عموما توسط جمع آوری سوابق تعامل کاربر با سیستم و استقبال او از پیشنهادات ارائه شده انجام می‌پذیرد. از آن‌جایی که حجم داده‌ها بسیار زیاد و محاسبات سنگین است، عملا اجرای چندین باره و بررسی خروجی‌ها به صورت فردی امکان پذیر نخواهد بود. لذا در فاز بعدی تلاش بر این خواهد بود تا با ایجاد یک وب سایت و با همکاری افراد داوطلب ارزیابی سیستم و بهبود آن انجام پذیرد.

۵. ۵.مراجع

[1] internetlivestats.com

[2]Ricci, F., Rokach, L., Shapir, B.: Introduction to Recommender Systems Handbook . (2011)

[3] Burke, R. : Hybrid web recommender systems. In: The Adaptive Web, pp. 377–408. Springer Berlin / Heidelberg (2007)

[4] Billsus, D. & Pazzani, M.: User Modelingfor Adaptive News Access. UMUAI 10(2-3),147-180. (2000)

[5] Schwab, I. & Kobsa, A.: Adaptivity through Unobstrusive Learning.Künstliche Intelli-genz 16(3): 5-9. (2002)

[6] Burke, R.: Knowledge-based Recommender Systems. 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, Institute of Applied Informatics, pp 52 - 64. (2006)

[8] Liu, DR., Tsai, PY., Chiu, PH. :Personalized recommendation of popular blog articles for mobile applications - Information Sciences, - Elsevier (2011)

[9]Hayes, C., Avesani, P. : An analysis of the use of tags in a blog recommender system, IJCAI'07, (2007)

[10] Balabanović, M. ,Shoham, Y. :Fab: content-based, collaborative recommendation - Communications of the ACM, (1997)

[11] Recommender systems, Part 2: Introducing open source engines
[12] LensKit Documentation

  1. Content-based

  2. Collaborative filtering

  3. Demography based

  4. Knowledge-based

  5. Constraint-based

  6. Community-based

  7. Hybrid recommender systems

  8. stability

  9. plasticity

  10. adaptive systems

  11. Weighted

  12. Switching

  13. Mixed

  14. Feature Combination

  15. Feature Augmentation

  16. Cascade

  17. Meta-level

  18. Pearson's correlation coefficient

  19. User Model

  20. User profile representation

  21. User Profile

  22. binary vectors

  23. feature vectors

  24. tree

  25. decision tree

  26. Bayesian networks

  27. User profiles initialization

  28. Distance and similarity between user profiles

  29. attributes

  30. User Profile Clustering

  31. clustering

  32. content-based clustering

  33. library

  34. documentation

  35. Machine Learning ToolKit

  36. Dependency Injection Design Pattern

  37. inject

  38. Query

  39. Aggregation

سعید عادل مهربان

سلام، خسته نباشید.
به نظر می‌رسه زحمت زیادی کشیدید تا راه‌حل رو پیاده‌سازی کنید، هر چند این ایراد به کار شما وارد هست که خیلی فنی به موضوع پرداختید تا علمی. فراموش نکنید که بین یک سامانهٔ پیشنهادگر عملیّاتی قابل بهره‌برداری که چیزی ازش نمی‌دونیم و یک سامانهٔ پیشنهادگر آزمایشگاهی که دقیقاً می‌دونیم هر قسمتش چه کاری انجام می‌ده، برای پروژه‌های هوش مورد دوم یقیناً برای ما جذاب‌تر هست. خیلی خوبه که نتیجه کاملاً قابل استفاده باشه، اما قابل قبول نیست که پشتوانهٔ‌ علمی رو جا انداخته باشید.
باید ازتون تشکّر کنم که سعی کردید نواقص مرحلهٔ قبل رو برطرف کنید. بالاخره کسی پیدا شد که انگار بازبینی‌ها رو خونده باشه. ولی ایراد اصلی مرحلهٔ قبل که بررسی کارهای مشابه بود رو برطرف نکردید. هم‌چنین روش پیشنهادی رو نتونستید به خوبی به خواننده انتقال بدید. بهتره اول یه تصویر کلی از اجزای مختلف کار داشته باشید و بعد اجزا مختلف رو به تفصیل شرح بدید.
چیزی که باید به یاد داشته باشید اینه: شما ساعت‌ها درگیر مفاهیمی بودید که خوانندهٔ متن‌تون چندان با اون‌ها آشنا نیست، پس سعی کنید کوچک‌ترین جزئیات رو هم بهش بگید.
ایراد دیگهٔ کار، ارزیابیه. یک سیستم پیاده‌سازی کردید، ولی نگفتید چه طور ارزیابی می‌شه. معمولاً قسمتی از داده‌ها برای آموزش به کار می‌رن و قسمتی برای ارزیابی. آیا سیستم‌های توصیه‌گر هم به همین صورت کار می‌کنن؟