PlayQ Smart Playlist בן אלון מגישים:

PlayQ Smart Playlist בן אלון מגישים:

מבוא המטרה של פרויקט זה היא ללמוד את העדפותיו המוזיקליות של המשתמש, ולהשתמש בידע שנצבר ע"י התוכנה בכדי לייצר רשימות השמעה שיתאימו לטעמו של המאזין. התוכנה מקבלת מסד-נתונים ראשוני של שירים וממנו מציעה למשתמש בכל פעם רשימת שירים בגודל של 20 שירים, שאת תוצאותיה היא מעבדת ומגדילה את הידע שלה על העדפות המשתמש. התקדמות התוכנית היא מחזורית הלמידה מתרחשת כל הזמן והשירים שהתוכנה תציע למאזין ישתנו עם כמות הלמידה ועם אחוזי ההצלחה של התוכנית. לצורך כך אנו עושים שימוש בעצי החלטה Trees) (Decision יחד עם סוג מסוים של למידה תחת פיקוח Learning).(Supervised השילוב של שני הכלים האלה יחד יוצר מערכת משולבת שמסוגלת לענות על השאלה "האם המשתמש ירצה להאזין לשיר X". המערכת המתקבלת לומדת כל הזמן והיא בעלת יכולת הכללה יודעת לספק רשימה מתאימה שתכלול גם שירים שלא הושמעו מעולם והיא למעשה לא למדה עליהם ספציפית. הבעיה שברצוננו לפתור העולם היום מוקף במוסיקה. בין אם זה בטלויזיה, ביוטיוב, תחנות רדיו אינטרנטיות כגון last.fm או פנדורה ואפילו ברדיו עדיין יש מוסיקה. הבעיה היחידה עם כל המוסיקה הזו היא הטעם השונה של כל אדם. כיצד ניתן לקלוע בדיוק לטעמו האישי של האינדוידואל. אם רק הייתה דרך להחליט מה להשמיע לפי הטעם של השומע.. כאן נכנס הפרוייקט שלנו. אנו יצרנו נגן מוסיקה אשר לומד את הטעם המוסיקלי של המשתמש. הנגן לומד לאט לאט לפי מאגר שירים מה המשתמש מעדיף לשמוע. הנגן יודע לשנות את רשימת ההשמעה לבד ולהחליף את השירים כאשר המשתמש מחליף לעיתים תכופות את השירים. כמו כן הנגן לומד עם הזמן איזה שירים / סגנונות / אמנים וכו' המשתמש מעדיף, בין אם מעדיף ברגע מסויים ובין אם מעדיף באופן כללי ובהתאם מתכוונן על רשימת השמעה רלוונטית.

אופן השימוש והנחות על הקלט על מנת להשתמש בנגן שלנו תחילה יש להניח מספר הנחות לגבי השירים. קובץ השיר חייב להיות מסוג,mp3 כאשר הסיומת יכולה להיכתב בכל צורה mp3,mp3 וכו'. על השם להיות באנגלית בלבד. ניתן להוסיף תווים נוספים כל עוד אינם בעברית. לקובץ השיר חייב להיות ID TAG כלומר תווית מיוחדת שבה הפרטים על השיר )בכל קובץ יש( כאשר הפרטים הבאים חייבים להיות לא ריקים בתווית של שיר מסוים כדי שיכלל במאגר השירים של התוכנה : סגנון, שם אמן, שנה. את שם האמן ניתן לכתוב באותיות גדולות או קטנות, אך בשביל שלא יהיו תוצאות לא קונסיסטנטיות מומלץ לוודא ששמות האמנים קונסיסטנטיים. למשל Jay z / jay-z / JayZ יחשב כשלושה אמנים שונים, שכן אמנם גודל האותיות לא משנה אך רווח, מקף ומילים צמודות יקראו שונה. על מנת שהתוצאות יהיו טובות ככל האפשר מומלץ להימנע ממספר גדול מאוד של סגנונות, כלומר עדיף לשמור על סגנונות כלליים כגון RAP/ROCK/R&B/METAL/CLASSIC וכו', ולהימנע Prog Rock / מתת תת ז'אנרים כגון New Metal )ובכלליות להימנע ממזרחית...(. כאשר ישנם סגנונות רבים מדי קשה להחליט על טעם מסויים, סוגיה שנובעת מעצם השימוש בעצי החלטה. חשבנו בהתחלה להגדיר לעץ ז'אנרים שונים שיכיר כתת ז'אנרים ויסווג את אותו תיוג )למשל אם יש punk שיכיר כRock ( אך מכיוון שכל ז'אנר ניתן לכתוב ולא רק מוכרים )ניתן להמציא ז'אנרים תחת קטגוריה זו בקובץ השיר( החלטנו לקבל זאת כמו שזה ופשוט לכתוב כהמלצה את התנאי. גם כאן, בדומה לשם האמן, יש להימנע מכתיבת השם בסגנון שונה, לדוגמא: Alt. Rock / Alternative Rock / Alternative יחשבו כשלושה סגנונות שונים. החלוקה של מאגר המידע, ובכך עץ ההחלטות, מתחלקת לפי שישה פרמטרים של השיר: מספר 1 1 השמעות )אשר מחולק ל- 4 קטוגריות מספריות בין ל- 4, כאשר זה קצת השמעות ו- 4 זה השמעות רבות ביחס לשיר המושמע ביותר(, אורך השיר, עשור, שם האומן, סגנון ודירוג. כאשר הדירוג ומספר ההשמעות הם הפרמטרים הלא קבועים היחידים. מספר ההשמעות, כשמו כן הוא, מתעדכן עם כל השמעה ודירוג השיר הוא הדירוג המצטבר מכל השמעה לחלק למספר ההשמעות. פרמטרים אלו נותנים לנו חלוקה טובה של השירים ומצליחים למיין את כל השירים שלא הושמעו ככה שיקלעו לטעם המשתמש.

ממשק התוכנה : מסך הפתיחה כאן ניתן להוסיף ספריות למאגר המידע. כאשר Add Library מוסיפים תיקייה מתווספות בצורה רקורסיבית כל תת הסיפריות שלה גם כן. כל שיר נבדק אם קיים כבר במאגר, כאשר שיר מוגדר לפי שילוב של שם האמן ושם השיר. במידה וקיים כבר מושווה עם מיקום השיר בדיסק )הכתובת שלו( ובמידה ואינם זהים מוגדר לפי הקובץ החדש. מוחק את קובץ מאגר המידע ויוצר קובץ ריק חדש. נא לשים לב: כל המידע Delete Data נמחק! כולל העץ, רשימת השיר ומיקום השירים. השירים עצמם נשארים ללא שינוי. - Exit במידה וברצונך לצאת מהתוכנה לפני הפעלת הנגן, נא להימנע מללחוץ על האיקס, אלא לצאת בצורה מסודרת עם הכפתור המיועד, שכן התוכנה עלולה להמשיך לרוץ ברקע. Start Player יתחיל את פעולת הנגן. עם לחיצה יבנה העץ )עוד על כך בהמשך(, תוחלט רשימת השמעה ויופעל הנגן. נא לשים לב: הנגן לא יתחיל לנגן אוטומטית, יש ללחוץ play על מנת להתחיל. jlgui3.0 javazoom הנגן עצמו הנגן מבוסס על נגן אחר הנקרא אשר הוספנו לו אופציות חדשות וערכנו קיימות. בעת הפתיחה של הנגן יעלו שני מסכים. נסביר תחילה על מסך הנגן עצמו: הנגן הוא נגן סטנדרטי, הדומה מאוד לנגן.winamp כל האופציות די ברורות: הפעל, הרץ קדימה, הרץ אחורה וכו'. ההבדל הגדול הוא שינוי תפקיד כפתור הRepeat. במקום לחזור על שיר, כאשר לוחצים על כפתור זה באופן אוטומטי נוצר עץ החלטה חדש שמכיל גם את תוצאות ההשמעה

האחרונה, מוחלפת רשימת ההשמעה ברשימה חדשה, הציון של הרשימה שהסתיימה נשמר ומאגר המידע מעודכן. הרשימה המועלה מקבלת ציון ברירת מחדל )הסבר מפורט על כך בהמשך( ומתחיל session השמעה חדש. לחיצה על repeat מפסיקה session מסוים, מעבדת אותו מתחילה את הבא. רשימת ההשמעה )playlist( כאן ניתן לראות את כל השירים ולבחור שיר אחר שיתנגן. יש לשים לב, אם נבחר שיר אחר באמצע ההשמעה של השיר הנוכחי, הדבר שקול ללחיצה על.next כלומר, הדירוג של השיר המושמע יקבע באותו רגע לפי המיקום בשיר. למרות שניתן להשתמש באפשרויות שונות ברשימת ההשמעה הוספת שירים כמו בעזרת הכפתורים השונים שנמצאים בה, יש להימנע מכך, שכן השירים שיוספו בדרך זו )ולא על ידי המסך הראשי( לא יצטרפו למאגר המידע ועלולים לפגוע בתקינות העבודה של הנגן. שירים אלה בוודאות לא יחשבו כאופציות השמעה בעתיד ותוצאותיהם לא ישפיעו על עץ ההחלטה הבא. הוספת שירים צריכה להתבצע אך ורק דרך מסך הפתיחה. חלון המידע למרות שחלון המידע לא חיוני לפעולת הנגן עצמו, החלון עוזר לנו לראות כיצד מתקדם הנגן, מידע על רשימת השירים ומעקב כללי על תקינות התוכנה. זהו כלי עזר לנו )ולכם( לראות כיצד מתנהל ארגון המידע ובה מופיעים חיוויים שונים על מצבי הנגן והתקדמות הלמידה. כמובן שלו הייתה זו תוכנה המשווקת, מידע זה היה מוסתר מהמשתמש.

החלון מציג מידע מגוון, נפרט כאן בקצרה ובהמשך בפירוט: Switch t-hold ערך הסף של רשימת ההשמעה. כאשר רשימת ההשמעה חוצה סף זה )כלומר יורדת תחתיו( מוחלפת הרשימה ברשימה חדשה והערך מתעדכן. Song Score דירוג השיר האחרון שהושמע. משתנה אחרי השמעת כל שיר. Session Score דירוג רשימת ההשמעה הנוכחית. משתנה אחרי השמעת כל שיר. Playlist Accepted Songs Ratio היחס בין השירים ה"טובים" ל"ניסיוניים" ברשימת ההשמעה הנוכחית. DB rating הדירוג הכללי של מאגר המידע משתנה עם כל session של נגינה.

עצי החלטה עצי החלטה הם מהדרכים הנפוצות ביותר לכריית מידע. עץ החלטה הוא עץ חיפוש בו כל קודקוד הוא מאפיין של מאגר המידע וכל ענף הוא ערך )או קבוצה( באותו מאפיין. העלים מציינים החלטה/תוצאה של העץ עבור סט מאפיינים. תוצאה בעץ עבור מסלול מסויים מהשורש לעלה מציין את קבוצת המאפיינים והתוצאה עבורם. בעץ החלטה עבור מסלול מסויים לעולם לא ימצא אותו מאפיין במסלול נתון מהשורש )המאפיין עליו בוחרים להתחיל את ההחלטה( ועד לעלה. כאשר מגיעים לעלה הוא מציין לאיזו החלטה )קבוצה( שייך המסלול, או פיסת המידע הנתונה. עצי החלטה נבנים בשני שלבים: שלב ראשון: בונים את העץ לפי נתוני למדה שלנו. מחפשים את הפרמטר שלפיו הכי טוב לחלק את המידע. מחפשים את המאפיין שיתן לנו את המידע הרב ביותר על מאגר המידע הנתון. עושים זאת על ידי חישוב האנטרופיה של הערך. האנטרופיה נותנת לנו מאיזה מאפיין נשיג את מירב האינפורמציה עם נחלק לפיו. לאחר מכן ממשיך הלאה ובוחר את המאפיין הבא לפיו ניתן לחלק את שאר המידע עבור תת העץ. תהליך המפסיק כאשר מגיעים לפיסת מידע בה כל הערכים מסכימים על תוצאה רצוייה. כמובן התהליך נועד על מנת לגרום לכך שכל מידע היגיע דרך הקודקוד )או עלה( זה יהיו משוייכים לאותה קבוצה. שלב שני: "גיזום העץ" pruning - tree בו אנו בודקים את העץ על ידי ריצה עם נתוני בדיקה שנקבעו מראש )אשר לא לקחו חלק בבניית העץ המקורי( וריצה על העץ. אנו בודקים את העץ לפי המידע הנתון ובודקים אם "ריצה" על העץ עם הערך הנתון אכן מגיעה לתוצאה אשר מתאימה לערך. אנו בודקים אם אחוז ההצלחה שלו משתפר עם הורדת עלה מסויים )עושים זאת רקורסיבית( במידה ואכן משתפר נגזום את העלה ובמידה וצריך נוסיף עלה במקום הערך אשר יקבע לפי ממוצע התוצאות לאותו קודקוד אב.

אופן השימוש בעצי החלטה במימוש שלנו: על מנת להשיג את התוצאות הטובות ביותר החלטנו לבדוק איזה מסוגי העצים השונים יתן את התוצאה הטובה ביותר. ניסינו לבדוק כל פעם איזה מהעצים מוציא תוצאה קונסיסטנטית בהתאם למידע אשר במאגר השירים. להלן העצים ודרך הבדיקה: בהינתן רשימה של שירים אשר קיים עליהם מידע, כלומר, עברו Information Gain לפחות השמעה אחת כך שקיים להם דירוג, הוא מחפש את המאפיין שיתן לנו את המידע הרב ביותר. הוא עושה זאת על ידי חישוב האנטרופיה וחיסור ממוצע האנטרופיות של כל ערך למאפיין. הערך שיתן את הקידום הכי טוב להחלטה )כלומר יקרב ככל הניתן ל- 0 ( יבחר כערך הפיצול. הבעייתיות שהתגלתה בבחירה זו היא שנוצר מצב בו ישנו פיצול גדול מדי. בעזרת GR אנו בעצם מאזנים את הכוחות עבור מאפיינים בעלי מעט Gain Ratio ערכים. כדי למנוע מצב בו אנו מחלקים את המידע רק עבור מאפיין בעל כמות רבה של ערכים )לדוגמא במקרה שלנו שהתחיל מפיצול לפי אמנים(. האיזון נעשה על ידי חישוב של מאפיין וחלוקה במדד האינפורמציה מתקבל על ידי חילוק הGain Information המידע למספר תתי קבוצות. התוצאה היא היחס של המידע אשר שימושי לנו מפיצול העץ על אותו מאפיין נתון. - Pruning במקרה הזה אנו משלבים טכניקה של גיזום ושל בחירת העץ הטוב ביותר. אנו מייצרים 10 עצים מכל סוג ממאגר הלמידה: 10 של Information gain ו- 10 של Gain כאשר לכל עץ כזה אנו רנדומלית מחלקים את המידע לשני חלקים: 75 אחוז Ratio מהשירים כמאגר למידה ו- 25 אחוז לבדיקת העץ. עבור כל עץ שכזה מריץ את המאגר בדיקה ובודק האם לאחר גיזום עלה אחוז ההצלחות גדל, במידה וכן העץ הגזום ישמר. על מנת להשיג את העץ הטוב ביותר, אנו משווים בין עשרה עצים ובוחרים את הטוב ביותר.

אופן הפעולה של הנגן תחילה מאותחל מאגר המידע של השירים כמאגר מידע ריק. על המשתמש להחליט על תיקייה ממנה הוא מעוניין לפעול. בכל שלב ניתן להוסיף תיקיות חדשות וכל שיר שיוסף למאגר יבדק אם קיים, במידה וקיים לא יתבצע שינוי )פרט אולי לשינוי הכתובת בו הוא נמצא בדיסק(. בשלב זה אין דוגמאות מהן ניתן להפיק עץ העדפות של המשתמש )כפי שהוסבר קודם על בחירתו( ולכן מוצעת רשימת השמעה רנדומלית. כל השמעה מנותחת לפי מספר פרמטרים: - ציון השיר המנוגן נקבע לפי אחוז הזמן אשר הושמע מהשיר. שיר "טוב" הוא שיר אשר יושמע מעל 50 אחוז מאורכו, למשל אם המשתמש ילחץ על "הבא" לאחר כחמש שניות יתקבל הציון 0.07 )כמובן כתלות באורך השיר עצמו(. הדירוג של השיר הוא ערך אשר נלמד עם הזמן ולא נקבע בכל השמעה. הדירוג נקבע על ידי סכום כל הציונים שקיבל השיר לחלק למספר ההשמעות של השיר. - ציון הרשימה )להלן )session נקבע לפי ממוצע ציוני השירים שנוגנו ברשימה זו. ציון זה מתחיל עם 0.5 כציון התחלתי,על מנת לאפשר דילוג על מספר שירים ראשוניים אשר עלולים לא להתאים לרצון המאזין או להחלפת הרשימה במצב שאין צורך. )פירוט בהמשך לגבי השימוש בסף זה(. - ציון מאגר המידע מחושב לפי ממוצע הרשימות שמושמעות ממנו והציון שהרשימה קיבלה. מדד זה משמש לקביעת סף איכות הרשימה. לאחר השמעת הרשימה הראשונה ישנן דוגמאות מהן ניתן להפיק עץ ומתחילה העבודה של מנגנון ניתוח השירים. אנו מפיקים עץ החלטה המשתמש בתוצאות ההשמעה כדוגמאות. יש לציין כי אנו עושים זאת לאחר כל רשימת השמעה על סך כל הדוגמאות הכלליות ולא כל עץ נקבע לפי ה- 20 שירים האחרונים. בכך אנו משיגים למידה מפורטת יותר של טעם המשתמש ולא מבט "רגעי" לטעם הנוכחי שלו. למעשה, ככל שמשמיעים יותר רשימות המערכת "מכירה" את המשתמש ומאפשרת פחות רעש )הכוונה לדוגמאות לא טובות ולא "רעש" מוסיקלי(.

מנגנון הלמידה על מנת למנוע מצב בו רשימת ההשמעה המתקבלת מתכנסת לערכים מסויימים מדי וכתוצאה מכך תיקבע על טעם ספציפי )דבר בעייתי, במיוחד כאשר מדובר בטעם מוסיקלי( יצרנו מנגנון למידה אשר מאפשר שינוי רגעי וכללי של העדפות המשתמש. הנגן עושה זאת באופן הבא: בתחילת ההשמעה )הפעם במידה וכבר יש מידע כלשהו על מאגר הידע( הנגן בונה את העץ הראשוני לפיו ימויינו השירים. הנגן בונה רשימת השמעה לפי שירים שמתקבלים ולא מתקבלים מהעץ ביחס ראשוני של 60 אחוז שירים "מוצלחים" ו- 40 אחוז "נסיוניים" אשר לא עברו את הבדיקה בעץ. אנו מוסיפים שירים אלו כדי לאפשר "עידון" הטעם ולאפשר שינוי של העץ וקבלת מידע נוסף עבור שירים שאולי העץ טעה לגביהם. 10( לכל רשימת השמעה קיים סף משתנה המאותחל על 0.1 אחוז( המציין האם הרשימה הזו נחשבת כרשימה כושלת. אם ציון הרשימה, אשר כפי שציינו נקבע לפי ממוצע הציונים של השירים שהושמעו ברשימה, יורד מתחת לסף זה אנו מכריזים על הרשימה כ"לא מוצלחת" ומייצרים עץ חדש יחד עם המידע החדש וממנו גוזרים רשימה חדשה. במצב כזה ציון הסף לרשימה יורד ב- 40 אחוז וכן ציון מאגר המידע יורד. במידה והרשימה מושמעת עד סופה )או עד שנסגר הנגן( ציון הסף עולה לרשימה הבאה בגורם קבוע של 10 אחוז. בכך למעשה, אנו מאפשרים מצד אחד רשימות השמעה יותר מגוונות בהתחלה בשביל מצב בו אנו מעוניינים לשנות את הטעם שלנו ומצד שני ככל שמאגר המידע מוצלח יותר ובעל ציון גבוהה יותר איתו יעלה סף השמעת הרשימה ולא נרשה רשימות עם מספר גדול מדי של שירים לא מתאימים. לאחר השמעת רשימת השמעה אנו מחשבים מחדש את יחס השירים ה"מוצלחים" לעומת ה"ניסיוניים", שכן לאחר השמעה מוצלחת אנו מעלים אחוז )65-35 את הסף ב- 5 בהתחלה( כך שבפעם הבאה יהיה רוב גדול יותר לשירים מועדפים ובכך מייצגים את ביטחוננו באיכות העץ וגם בקליעה לטעם ה"רגעי". מצד שני, במידה והרשימה אינה מוצלחת אנו מורידים את היחס לטובת השירים ה"ניסיוניים" ב- 10 אחוז )50-50 בהתחלה( ובכך מאפשרים כניסתם של יותר שירים "ניסיוניים" ושינוי הטעם הנרכש עד כה. יש לציין כי סף זה, בניגוד למידע על השירים והעץ הנבנה, מתאפס בכל הפעלה מחדש של הנגן על מנת לשקף יותר את הטעם הרגעי ולהשפיע פחות על הטעם הכללי. כלומר, בכל

השמעה נתחיל תמיד עם יחס 60-40 ולאט לאט נטפס )או נרד( עד נקודה קבועה להשמעה הנוכחית. מנגנון למידה אחרון הוא הציון של מאגר המידע שלנו, כאמור ציון זה הוא היחיד )פרט לציון השירים( אשר נשמר גם בין ההפעלות. ערכו נקבע לפי ציוני רשימות ההשמעה השונות המופקות ממנו. במידה וציון זה עובר סף של 80 אחוז אנו מכריזים על מאגר המידע כמאגר מידע "מוצלח" ומרגע זה קובעים את סף החלפת הרשימה לגבוהה יותר משמעותית )80 אחוז מציון מאגר המידע(. כלומר, ברגע שקבענו שמאגר המידע שלנו מוצלח נאפשר רק רשימות בעלות סף מאוד גבוהה. למעשה מצב זה מסמל כי למדנו להכיר את טעם המשתמש וכעת צריך להציג פחות תוצאות ניסיוניות ויותר תוצאות מוצלחות. בדיקות המימוש : לאחר בדיקות רבות שעשינו על מאגר מידע מאוזן, כלומר שאין בו יותר מדי רעש פרט למספר האמנים, הגענו לתוצאות הבאות: הסקנו כי העץ המתאים ביותר הוא.Information Gain Ratio Pruned ניתן לראות מגרף התוצאות ומניסויים דומים לזה, ששיטת בנייה זו מניבה עצים יציבים וקטנים בגודלם באופן יחסי לשאר השיטות. כמוכן רואים בתוצאות ששיטת הRatio Gain מניבה תוצאות קרובות כך שלמעשה ניתן לבחור את אחת משתי אלה. הסיבה העיקרית לחוזקן של שיטות אלה מול השתיים האחרות היא ההתחשבות ברוחב הפיצול של צומת מסוים כגורם שלילי בהחלטה האם

לפצל לפיו. מכיוון שאנו עובדים עם שירים בהם הסגנונות עלולים להיות רבים ומספר האמנים יכול להיות רב מאוד חלוקה זו תורמת רבות למינימיזציה של העץ. אנו בחרנו להעדיף את העץ המינימלי ביותר מכיוון שאנו מאמינים שלמרות היותו הקטן ביותר מבחינת מספר הקודקודים, הוא עדיין מייצג היטב את הידע הנרכש ואפילו מספק רמת הכללה גדולה יותר, כי במקום לפצל למקרים יותר ספציפיים, דבר שמתבטא בהרבה קודקודים, אנו מקבלים פחות צמתים ויותר הכללה, דבר שמאפשר לנו להסיק על מאגר שירים כללי ולא רק על הדוגמאות שהושמעו. כך אנו מרוויחים וריאביליות בבניית העץ ובהמשך ברשימות ההשמעה שנוצרות ממנו. מידע לגבי הבדיקה עצמה : יצרנו מאגר שירים שמחולק לשלוש קבוצות, והרצנו את הנגן במשך רשימות השמעה )שקול ל 200 Sessions של למידה( כאשר הגדרנו לו לתת ציון 200 מקסימלי)להשמיע עד סוף השיר( לכל השירים מקבוצה 1, מחצית השירים מקבוצה שנייה ואף שיר מהקבוצה השלישית)קיבלו ציון קרוב לאפס(. עשינו זאת ע"י הפרדת מאפיינים בTAG של השירים בכל קבוצה והגדרת ריצת התוכנה על הבדלים אלה. כך למעשה גרמנו לתוכנה להתייצב/ללמוד טעם מסוים אך עם רמת גיוון כלשהי, שהושגה ע"י כך שהקבוצה האמצעית הייתה בעלת מאפיינים שונים במקצת מהראשונה. מכיוון שמאגר זה הוא קבוע, איפסנו אותו כל פעם והרצנו על סוג אחר של בניית עץ לקבלת כלי השוואה לגיטימי בין השיטות. הגרף המובא מייצג סט אחד של בדיקות אך הם נבדקו על כמה וריאציות של אותו מאגר נתונים, מכיוון שהגרפים דומים בחרנו לצרף רק אחד. כדי לבדוק ולהדגים את מנגנון הלמידה ביצענו את בדיקת הניסוי הבאה: הרצנו את הנגן על מאגר נתונים קבוע כ- 200 אפיזודות ריצה)רשימות השמעה שונות( ובהם הגדרנו רק טעם מונוטוני יחיד שם להקה יחיד או סגנון מוזיקלי. המטרה הייתה לראות איך משתנים המדדים הנ"ל. במקרה פשוט ומוחלט זה)בשונה מהמקרה הראשון, אין כמעט גיוון בהגדרת הטעם של המשתמש( - אנו מצפים שאחרי מספר הרצות רב כזה, הDB יתייצב על ציון גבוה מאוד, איתו רמות סף הרשימה

והעץ יהיה פשוט והחלטי)להקה מתאימה אז כן, אחרת לא(. התוצאות : הגרף מראה את רשימות ההשמעה לאורך זמן. רשימה מס' 1 היא למעשה הרשימה ה 151 בבדיקה שלנו. בחרנו להראות את מנגנון הלמידה לאחר שלמד קצת את הטעם המוסיקלי של המשתמש. כפי שניתן לראות, כל הנקודות בהן יש ירידה חדה בScore Session וב Switch Threshold אלו הנקודות בהן נתלנו ברשימה "רעה" כאשר ציון הרשימה ירד מתחת לסף. ולכן, בוצעה התאמה של ערכים אלו )ירידה ב 40 אחוז( וניתן לראות שלאחר כמעט כל הורדה כזו המנגנון משתפר ואנו נשארים באחוזי קבלה גבוהים. הרשימה המושמעת מקבלת אחוזים הקרובים ל 90 אחוזי הצלחה, ועקב זאת גם הסף עולה. הירידה המחזורית הזו היא מכוונת, על מנת לאפשר שינוי הטעם הנלמד, כפי שרואים, במידה והשינוי לא התבקש )כמו בין 25-28( התוכנה מהר מאוד חוזרת לרשימה המבוקשת. בדוגמא זו, כאשר הטעם התייצב, נעשה ניסוי לשנות את הטעם, אך בגלל שזו בדיקה אוטומטית ולא איפשרנו קבלה של שיר "רע", תוך שתי רשימות הרשימה התייצבה חזרה ו"הבינה" כי זו הייתה סטיה רגעית ולא מגמה משתנה. הקו הירוק מראה, את אחוז השירים המתקבלים על העץ בכל רשימה. כאן יהיה רלוונטי דווקא להראות את ההתקדמות מתחילת הבדיקה:

ניתן לראות כי הוא מתייצב על שירים טובים כ 0.95 אחוז. ועם כל רשימה המתחלפת יש ירידה קלה שלאחריה חוזרים לשירים "טובים". לבסוף ישנו הציון הכללי של מאגר המידע. זהו הציון היחיד אשר נשמר בעת יציאה מהתוכנה. שאר הנתונים משתנים פר הרצה של תוכנית. לכן המדד הזה הוא הרלוונטי ביותר לרמת הלמידה הכללית של המשתמש. ציון זה מראה למעשה את איכות העצים שאנו מפיקים וכמה הם מתאימים למשתמש בממוצע. במקרה של הבדיקה שלנו, בו ניסינו להכריח את התוכנה לטעם ספציפי אנו רואים כי אכן המאגר מידע התאזן על ניקוד של 80 אחוז הצלחה למאגר המידע. בגרף אנו רואים את ההתקדמות של המאגר לאורך ההשמעות השונות. לאחר הפעלה מחדש, הציון ישמר על 0.8. זהו ציון מצויין המראה כי אכן אנו קלענו קרוב מאוד לטעם של המאזין. וזהו אכן הסף שקבענו בו הוא יוריד את כמות השירים ה"רעים" ואכן לאחר מספר השמעות נוסף, ירד אחוז השירים הניסיוניים.

ניתן לראות בנספח א' את שני העצים אחרי הרצות רבות. כפי שנראה בניתוח התוצאות בהמשך, רואים כי קיבלנו עץ עם טעם מאוד מאוד ספציפי כפי שרצינו. הגדרנו לרובוט טעם מאוד מסויים ואכן הוא בונה את העץ כפי שצפוי כאשר הגורמים המשפיעים היחידים הופכים להיות אורך השיר ומספר ההשמעות. רואים שבהתחלה יש הרבה פיצולים אך לאחר הרבה השמעות ועם קצת פרונינג נעלמים כל העלים הלא רלוונטים ורק מה שרצינו מוגדר להיות "טוב". גם במקרה הבדיקה הראשון )גרף קודקודי העצים( שהוצג למעלה נבדקו מדדים אלה, אך עם שינוי קל: במקום לקבוע טעם אחיד, חילקנו לשלוש קבוצות עם אמנים רבים ומספר סגנונות לא רב. הגדרנו לו לקבל מקבוצה ראשונה את כל השירים, מקבוצה שנייה חלקית ומקבוצה שלישית לא לקבל דבר. כלומר ליצור טעם מוסיקלי אשר אינו חד משמעי. ישר רואים כי הגרף אכן מתייצב אך על ערך הנמוך בכ- 20 אחוז מהערך של הניסוי השני, בעל הטעם המוסיקלי האחיד. תוצאות אלו מתאימות לציפיות כי מצד אחד כאשר אנו מכוונים אותו לטעם מסויים הוא מגיע אליו מהר מאוד, לעומת זאת, כאשר מאפשרים לו התנהגות "אנושית" התוצאות מתייצבות על ערכי הצלחה נמוכים יותר. יחד עם זאת, יש לשים כי הוא עדיין מקבל אחוזי הצלחה גבוהים מאוד, ופרט לירידה קלה בתחילת הלמידה, הוא מתאזן על אחוזי הצלחה גבוהים ביותר. כלומר קלענו לטעם של המאזין הממוחשב. גם בערכים האחרים רואים את השינוי בלמידה:

שוב נראה את ה- 50 רשימות האחרונות בסדרה. כאן אנו רואים כי אמנם שוב היחס קבלה לשיר מתאזן על אחוזים גבוהים )ואפילו גבוהים יותר ממקודם( כאן הניקוד של הרשימה מזגזג קצת סביב ה 70 אחוז, אך מספר רשימות ההשמעה שאינן מתחלפות הוא גבוהה. נתון זה הפתיע אותנו, שכן דווקא ברובוט עם הטעם המגוון, מספר הרשימות שקלעו לטעמו היה גבוהה יותר לפני קבלת רשימה "רעה" שהורידה את הThreshold. ניתן להבין זאת, שכן במקרה ה"פשוט" יותר )כלומר, טעם מכוון( קל יותר להבחין בין רשימה "טובה" לרשימה "רעה", לעומת המקרה המגוון. כאן אמנם העץ היה משמעותית גדול יותר, אך עם Pruning הצלחנו לצמצם אותו לסביבות ה- 60 קודקודים לעומת מעל ל 300 באחת ההרצות. כאן הוא אכן קלע מעט פחות לטעם המוסיקלי אך עדיין הביא תוצאות גבוהות מהצפוי, קרוב ל 70 אחוזי הצלחה באופן קבוע. לבסוף, אין כמו המוח האנושי. עשינו בדיקות על עצמנו. וקיבלנו תוצאות דומות מאוד למקרה של הרובוט אשר אינו חד משמעי. גילינו שרק אחת לכ- 12 רשימות השמעה יוצא שהתוכנה מגדירה את ההשמעה הנידונה כרשימה "רעה". ופרט למספר מקרים בהתחלה, בהם משום מה הוא חשב שאני מעדיף בקסטריט בויז, אחוזי ההצלחה היו מספקים.

ניתוח תוצאות יתרונות וחסרונות לאחר בדיקות מרובות של רשימות השמעה מגוונות הגענו למספר מסקנות: - כל עוד הרשימות מסודרות המנגנון שלנו מנבא בצורה די מוצלחת את טעמו המוסיקלי של המשתמש. הוא לומד היטב מה המשתמש אוהב ומה לא. לאחר מספר השמעות אפילו היו מקרים שבהם המחשב הציע שירים ששכחנו שמופיעים במאגר השירים שלנו. לאחר שימוש נרחב במהלך רוב תקופת המבחנים, הגענו גם לשלב בו איננו על לוחצים - כפתור העברת השירים בכלל. כמעט כל שיר היה קליעה, וגם השירים שהוגדרו כ"לא טובים" דווקא היו טובים כי שכחנו שהם קיימים. יחד עם זאת, לתוכנה יש מספר חולשות: - על מנת לשמור על מבנה טוב של העץ התוכנה מחייבת שמירה על מאגר תקין. בעולם של היום רוב השירים מגיעים עם תווית והשימוש בתוכנה מחייב על המשתמש לערוך את התבנית לכל שיר כדי של יהיה מגוון רב מדי של סגנונות וגם ששם האמן יתאם לצורת הכתיבה )כלומר בלי שגיאות כתיב(. - בעיה נוספת היא המחסור באטריבוטים. גילינו מהר מאוד כי העץ שלנו נבנה, פחות או יותר, אך ורק לפי שלושה אטריבוטים עיקריים: שם האמן סגנון ושנה. במקרים בהם העץ נבנה לפי אורך השיר או מספר השמעות העץ הפך להיות פחות רלוונטי ובמקרה של מספר השמעות התוצאה דווקא הייתה הפוכה למה שרצינו, שכן לאחר מספר השמעות רב השיר הופך להיות מאוס, ודווקא שיר שיוגדר "טוב" לפי מספר השמעות, רוב הסיכויים שיהפוך להיות "לא טוב" מהר מאוד. - בסופו של דבר, הגענו למסקנה שמאוד קשה לקלוע לטעם מוסיקלי של בנאדם. אם היינו עובדים עם מאגר עצום ולא מאגר נתון ועם קצת יותר אטריביוטים שניתן היה להוציא מהשיר היינו יכולים לקלוע יותר לטעם המוסיקלי. במקרה של מוסיקה נתונה, אין תחליף לדעה האישית של המשתמש. גם אם זה אומר ללחוץ קצת יותר על כפתור הנקסט.

קצת על הקוד כפי שציינו, השתמשנו בחבילה של JavaZoom אשר נותנת בסיס לנגן עצמו ואת כל הפונקציות. שינינו מספר פונקציות והוספנו התנהגויות חדשות לפונקציות קיימות. לדוגמא, בעת סגירת הנגן מתבצעת שמירת מאגר המידע, בעת לחיצה על כפתור העברת השיר נשמר המידע על השיר הרלוונטי ומתעדכן המאגר וכו'. כמו כן, אנו משתמשים בחבילה JAudioTagger בשביל לקבל את המידע על השיר, את כל תבנית הIDv3 שלו, אשר מחזיקה את כל המידע הרלוונטי. בנוסף להוספת הפונקציליות של החבילות האלה הוספנו מספר אובייקטים משלנו שתפקידם לנהל את הנגן, לנהל את מאגר המידע ולבנות את העצים. האובייקטים שלנו - TreeNode : אובייקט היורש מ< HashMap<String,TreeNode הוא למעשה העץ עצמו. אובייקט זה משמש לבניית העץ כאשר כל קודקוד מחזיק שדה בולאני המציין האם הוא עלה, מצביע להורה שלו, שם, ומאגר שירים הרלוונטים לקודקוד זה. בעת בניית הקודקוד מקבלים אטריבוט נבחר ולפיו מחלקים את השירים בין הערכים השונים הרלוונטים לערך. DataBase מאגר השירים שלנו. מחזיק מפה עם String ו- Song, כאשר הגורם הראשון - הוא שם השיר, הייחודי לכל שיר הנקבע על ידי שם האמן ושם השיר, והגורם השני הוא אובייקט השיר עצמו. אנו מחזיקים גם מערך של עצים )למידה ונרצה לאפשר עבודה עם יותר מעץ אחד, מאותחל כרגע לעץ יחיד(. כמו כן, יש לאובייקט רשימה של Atrributes מוכרים עליהם לפצל את המאגר. Song אובייקט המציין שיר במאגר המידע. האובייקט מחזיק את שם השיר )בפורמט - שצויין( את הכתובת בדיסק, Tag )אובייקט עם מידע על השיר( ומידע בסיסי. בעת יצירת האובייקט נבדקים כל הפרמטרים שהם תקינים, במידה ואינם תקינים, השיר נקבע כ"לא נוצר" ולא יוכנס למאגרי המידע.

Tree אובייקט המציין את העץ עצמו. העץ מחזיק 4 סוגי עצים, כפי שציינו קודם. - כאשר ניתן בקלות להחליט לעבור לסוג עץ אחר )ניתן לשנות זאת באובייקט.)PlayQ בעץ מחליטים על אחוזי הלמידה ועל אחוז הקבלה של שיר. כל מתודות הבדיקה נמצאות בו. AttMap הוא מפה של הנתונים מהם העץ נבנה. מתרתו היא להקל על הבנת מבנה - הנתונים,וליצור קוד קריא יותר. playsession אובייקט המריץ את הsessions השונים. הוא מייצר את העצים ומאזין - לנגן. תפקידו העיקרי לקשר בין רכיבי התוכנה הנוספים לבין הנגן עצמו ולקרוא את המידע מהנגן. אחרי על "תנאי הקבלה" של רשימת השמעה ובדיקה של כל רשימה. PlayQ התוכנית הראשית. מחזיק את מאגר המידע ואת הplaySession. אחרי על - הפעלת הרכיבים ושמירת המידע. מפעיל את הנגן עצמו ומאזין באופן קבוע לפקודות המתקבלות מplaySession. כמו כן, הוא היחיד שניגש לקבצים ושומר אותם.

נספח א עץ הרובוט עם הטעם המכוון לאחר 022 איטרציות

עץ הרובוט המכוון לאחר כ- 5 הרצות )עקב מקום בדף, לא כל העלים מצויירים(

הוראות הפעלת התוכנה לתוכנה מצורף קובץ jar המכיל בתוכו את כל התוכנה. בנוסף מצורף קוד המקור )בנפרד(. יש לפתוח את הקובץ לתיקייה אחת ולהריץ את הפקודה הבאה בPrompt :Command Java jar playq,jar התוכנה רצה רק על מערכת הפעלה,WINDOWS עקב שימוש בחבילה אשר אינה עובדת על לינוקס כראוי. במהלך ההפעלה מודפסות לקונסולת הפלט הודעות שונות שמודיעות על מצב התוכנה )החלפת רשימה, הצגת עץ וכו'(. מטרת הדפסות אלה היא לעקוב אחר השינויים העיקריים בהתקדמות התוכנה ואפשרות לראות את העץ הנבנה בכל פעם. לעתים נזרקת הודעת שגיאת DSP )בעיקר במצב בו מנסים להעביר הרבה שירים מהר(, הודעה זו היא שגיאה של חבילת הנגן החיצונית בה השתמשנו ולמרות שהיא מופיעה התוכנה עובדת במצב תקין. במידה והיא מופיעה אפשר להמשיך לעבוד כרגיל ומהלך התוכנה לא משתנה. שימו לב: לאחר הוספת הספרייה, יכול להיות שצריך המתנה קלה )כמספר שניות( עד שניתן יהיה ללחוץ על הכפתור של הפעלת הנגן. כדי לראות את השירים ברשימת ההשמעה צריך ללחוץ על הכפתור PL הערה אחרונה, עם יצירת מאגר נתונים חדש דרוש מספר מינמלי של שירים שהושמעו בעבר על מנת ליצור עץ ראשוני. )המספר הדיפולטיבי הוא 01(.