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

تغییرات
ارزیابی بهبود نتایج و تکمیل گزارش

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

چکیده

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

۱. ۱.مقدمه

در دنیای امروز، شبکه جهانی وب به عنوان ابزاری فراگیر به منظور رفع نیازهای مختلف مورد استفاده قرار گرفته است و حدود نیمی از جمعیت کره زمین از آن استفاده می‌کنند.[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]

کلیت سامانه پیشنهادگر m-CCS

قدم اول در این سیستم جمع آوری مقالات بلاگ‌ها از اینترنت با استفاده از مکانیزم RSS است، در قدم بعدی با استفاده از تکنولوژی بازیابی اطلاعات (در اینجا tf-idf) مقالات پیش‌پردازش و ویژگی‌های آن‌ها در قالب بردار کلمات32 استخراج می‌شود.

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

نکته دیگر قابل توجه در این سیستم مدل سازی رفتار کاربر در هنگام مرور صفحات وب، به وسیله آنالیز داده‌های مربوط به پیشینه کاربران تلفن همراه است که با استفاده از محاسبه میانگین زمان مطالعه به ازای هر کلمه مقاله تحت زمان 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}

با داشتن الگوی رفتاری کاربر، می‌توان تمایل او را نسبت به مقالات سنجید و مقالات مناسب را به او پیشنهاد کرد، بدین ترتیب که با تخمین زمان مرور مقاله33 (PBT) و مقایسه آن با زمان مرور واقعی34 (ABT)، امتیاز تمایل کاربر35 (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

این سیستم برای سازمان‌دهی بلاگ‌ها، از تگها به منظور خوشه‌بندی محتوا محور36 استفاده می‌کند. سپس با معرفی یک روش امتیاز دهی به خوشه‌ها، به حذف خوشه‌های نامناسب می‌پردازد.[9]
یک راه ساده برای پیشنهاد بلاگ پست جدید، استفاده از تگ‌هاست. روشی که توسط Technorati استفاده شد و توسط Brooks و Montanez آنالیز گردید. [9]

به هر حال مشخص شده که استفاده صرف از تگ‌ها برای این منظور مناسب نیست. در بررسی ۷۲۰۹ سند، ۳۹۳۴ تگ استفاده شده بود که از بین آن‌ها فقط ۵۶۳ تگ ( حدود ۱۴ درصد ) دو بار یا بیشتر استفاده شده بودند و این به این معنی است که در حدود ۸۴ درصد تگ‌ها برای بازیابی کاربردی نخواهند داشت.

با خوشه‌بندی مقالات براساس محتوا و تگ، برای هر خوشه، سه نوع تگ تعریف می‌شود:

  • تگ‌های سری C : تگ‌هایی هستند که توسط هیچ کاربر دیگری در خوشه استفاده نشده‌اند.

  • تگ‌های سری B : تگ‌هایی که بسامد تکرار آن‌ها ۲ یا بیشتر است، این تگ‌ها عموما کلمات قطع37 هستند و برای شاخص‌گذاری38 و بازیابی اطلاعات مناسب نخواهند بود.

  • تگ‌های سری 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 یک پیاده سازی توزیع شده از یک سامانه پیشنهادگر ترکیبی، به عنوان بخشی از کتابخانه دیجیتال دانشگاه استنفورد است. پروسه پیشنهادگر از دو بخش جمع آوری دیتا از یک پایگاه داده و انتخاب بخشی از آن برای کاربری خاص تشکیل می‌شود.
این سیستم بر مبنای ساخت پروفایل کاربری عمل می‌کند و تمرکزش بر روی دقیق بودن پروفایل‌ها است که بر اساس تعامل کاربر با سیستم و امتیازدهی‌های او به روز می‌شوند.

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

۴.۱. ۱.۴. ساختار کلی

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

۴.۱.۱. ۱.۱.۴. داده

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

از پایگاه‌های داده می‌توان برای ذخیره‌سازی مناسب، شاخص گذاری، و بازیابی بهینه اطلاعات استفاده نمود، لذا در پیاده سازی سامانه پیشنهادگر باید یک لایه جهت دسترسی به داده بدین طریق، پیاده سازی نمود. این لایه در معماری نرم‌افزار لایه دسترسی به داده39 نامیده می‌شود و کلاس‌های این لایه را اشیاء دسترسی به داده40 یا به اختصار DAO می‌نامند.

به دلیل تنوع و گوناگونی پایگاه‌های داده برای ایجاد یکپارچگی در سیستم این اشیاء باید از یک اینترفیس یکسان تبعیت کنند.

از مهمترین اشیاء می‌توان به موارد زیر اشاره کرد:

  • شیء دسترسی به داده کاربر41

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

  • شیء دسترسی به داده آیتم42

قطب دیگر سامانه پیشنهادگر داده‌های مربوط به آیتم‌ها هستند. ویژگی‌ها و صفات آیتم‌ها، تگ‌ها و خصوصیات مورد استفاده در بررسی محتوا محور توسط ItemDAO قابل دسترس خواهند بود.

  • شیء دسترسی به داده رویداد43

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

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

۴.۱.۲. ۲.۱.۴. منطق

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

این پیش‌بینی به بیان ساده، پیش‌بینی امتیاز کاربر به آیتم‌هایی است که رویدادی بین آن‌ها و کاربر ثبت نشده، لذا این بخش از برنامه را بخش امتیازدهنده (Scorer) نیز می‌گویند.

۴.۲. ۲.۴. حل مساله

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

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

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

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

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

  • ‌trainPosts.json

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

  • ‌trainPostsThin.json

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

  • ‌trainUsers.json

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

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

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

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

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

  • ‌LensKit

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

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

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

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

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

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

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

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

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

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

  • ‌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 منتقل کردیم تا بتوانیم روی آن‌ها اعمال پرس و جو51 و اجتماع52 را به راحتی انجام دهیم.

در آخر با درنظر گرفتن این نکته که تست و اجرای برنامه برای سایرین مشکل خواهد بود، خروجی unwind شده این داده‌ها از ‌MongoDB به یک فایل CSV منتقل شد تا بخشی از آن برای تست و اجرا در کنار کد قرار گیرد.

با این وجود باز هم محاسبات سنگین خواهد بود و باید در هنگام تست در قسمت Run Configuration مقادیر -Xms1024M -Xmx4048M را به VM Options اضافه کنید، در غیر این صورت با خطای OutOfMemoryError مواجه خواهید شد.

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

  • داده

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

در پایین‌ترین سطح، داده‌های ما در پایگاه داده MongoDB قرار داشت و از آن جا که برای کار با MongoDB در LensKit کلاسی ارائه نشده است، ابتدا یک MongoDbDAO پیاده‌سازی شد.

وظیفه این کلاس ایجاد امکان دسترسی به داده‌های مربوط به کاربر، آیتم و رویداد بین آن‌هاست. در نتیجه با این کلاس به پیاده‌سازی اینترفیس‌های EventDAO, ItemDAO, UserDAO, UserEventDAO پرداخته شد.

برای پیاده‌سازی پروفایل کاربری، به پیاده‌سازی اینترفیس UserHistory نیز نیاز داشتیم که با پیاده‌سازی کلاس UserLikeHistory انجام پذیرفت.

  • منطق

در آخر به منظور پیکربندی سیستم پیشنهادگر، از میانگین امتیاز کاربر (UserMeanItemScorer) به عنوان معیار امتیاز پایه در راه اندازی اولیه موجود در مستندات استفاده کرده و همچنین برای کار با فایل CSV از SimpleFileRatingDAO استفاده شد.

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

برای تست و اجرای کد می‌توانید به مخزن GitHub مراجعه و پروژه سپتاک (سامانه پیشنهادگر ترکیبی آیتم کاربر) را دریافت نمایید.

۵. ۵. ارزیابی

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

۶. ۶. کارهای آینده

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

۷. ۷.مراجع

[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. term-vector

  33. Predict Browsing Time

  34. Actual Browsing Time

  35. preference score

  36. content-based clustering

  37. stop words

  38. indexing

  39. Data Access Layer

  40. Data Access Object

  41. User DAO

  42. Item DAO

  43. Event DAO

  44. Event

  45. Data Model

  46. library

  47. documentation

  48. Machine Learning ToolKit

  49. Dependency Injection Design Pattern

  50. inject

  51. Query

  52. Aggregation

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

سلام.
خسته نباشید.
از توضیحات شما این طور بر میاد که روش روشن و مشخّصی برای ارزیابی کارهای مشابه کار شما وجود نداره. این رو با ارجاع به مراجع خودتون توضیح می‌دادید بهتر بود. سؤال دیگه‌ای که برای من پیش میاد اینه که امکان نداشت با انتخاب بخشی از داده‌ها نیاز به منابع پردازشی رو برطرف کنید؟
در هر صورت امیدوارم پروژه رو ادامه بدید و به نتیجهٔ قابل قبولی برسید.

تایید شده

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

رد شده