יום רביעי, 27 באפריל 2016

298 The history of visual object detection

אנחנו בפודקאסט 298, ה22 במרץ, עם אמרי קיסוס והיום נדבר על ראייה ממוחשבת וזיהוי עצמים.

  • 1:13- אמרי, מומחה בראייה ממוחשבת ובזיהוי עצמים ופנים עובד בFDNA. חברה הקיימת מעל 4 שנים ובעלת אפליקציה לזיהוי מחלות גנטיות ככלי עזר לרופא.
  • 3:40 – אילו בעיות קיימות בזיהוי אובייקטים – בעיית זיהוי פנים (Face detection) נחשב בעיה פתורה אך זיהוי למי שייכות הפנים (Face recognition) - אינה פתורה.
  • בזיהוי אובייקטים שונים מקטגוריות שונות, מייקרוסופט הוציאה מערכת לפני מספר חודשים שהיוותה שיפור משמעותי וגוגל אף שיפרה את אחוזי הזיהוי בחודשים האחרונים.
  • סוג הבעיות שמעוניינים לפתור בזיהיו עצמים בתמונות הם (קישור):
  • 7:35- סקירה היסטורית – התיעוד הראשון של זיהוי עצמים הינו ממחקר של סקינר ממלחמת העולם השנייה –לאמן יונים לזהות מטרות ועצמים ליצירת פצצות מונחות. משנות ה70 זוהי טכנולוגיה צבאית לזיהוי מטרות והטכנולוגיה "אוזרחה" בשנים האחרונות.
  • 10:42 – תחילת העיסוק באיתור פנים – המעבר למודלים מתמטיים מתקדמים ומבוססי סטטיסטיקה – המערכת הראשונה Eigenfaces) 1987)– מערכת המנסה לאתר פנים ע"י בניית צירוף של תמונות פנים קודמות.
איך נסווג פנים - אם נצליח להרכיב את התמונה ממספר פרצופי בסיס קטן - אילו פנים, אחרת הם לא פנים.
  • 13:35- הצעד הבא בזיהוי פנים (1997) – הפנים כגרף של נקודות – כמו ש"מדמיינים" זיהוי פנים. מחלקים את הפנים למאפיינים שיש לכל פרצוף וקבעו אותן כנק' חובה ואת הפרופורציות ביניהן. איתור הפנים – כמציאת התאמה בין גרפים. המודל למרות שנראה מרשים אינו עומד במציאות.
  • 16:47 – בשנת 2001 – ויולה וג'ונס – מצאו שיטה שמהווה פריצת דרך בתחום זיהוי הפנים -   השיטה מתבססת על מציאת תבנית של ניגודיות כגון הניגודיות בין העיניים לגבות ואם מספיק תבניות התאמתו כתבניות המתאימות לפנים המערכת מסווגת את התמונה כפנים. מודל יותר סטטיסטי והיוריסטי. דוגמא לטעויות באלגוריתם ניתן לראות ממצלמה של HP ב2009 שלא זיהתה פנים של אנשים כהי-עור.
  • 24:40 – ב2014 יצא מאמר Head Hunter שהראה שבפועל לא הייתה התקדמות משמעותית למרות אלגוריתמים רבים שנוצרו.
  • 25:39- Deep Learning– הקפיצה הבאה שנעשתה בתחום זיהוי הפנים. הDeep Learning  מאפשר לאמן את המערכת עם כמות הרבה יותר גדלה של תמונות מאשר אלגוריתמים קודמים. באלגוריתמים אלו, קשה יותר לרמות את המערכת – נעשה נסיון של Cornell Tech שלא הצליח לשבור את האלגוריתמים.
  • 30:45- שיוך פנים לאדם – המאמר 2014  Deep face – המאמר מוציא מאפיינים לכל אדם לפי מספר תמונות. המערכת מחשבת וקטור של הסתברויות לכל אחד מהפרטים בתמונות. השלב הראשון הוא Feature extraction ולאחר מכן משליכים את התוצאות על שאר התוצאות בTraining set.  כיום מספיק כ3-5 תמונות בכדי לזהות אדם באופן טוב.
  • 34:10- שימוש נוסף, זיהוי הבעות על ידי זיהוי נק' על הפנים.
  • 34:57 – זיהוי פנים לא באופן פרונטלי – זהו אתגר שפחות מטפלים בו ומעדיפים להתמקד בפנים "לא סטנדרטיים" כגון מייקל ג'קסון ומחלת הזיקה.

תודה רבה לחן סלומון על התקצור. הקובץ זמין כאן להורדה.

יום חמישי, 21 באפריל 2016

297 Fogcast 24 - Lambda

בפרק זה רן וליאור מדברים על AWS Lambda והנסיון של רן בכתיבת crawler מעל שרות זה.

2:10 בניית פריימוורק ל AWS Lambda עבור Yodas

3:37 המוצר AWS Lambda נוצר ע״י אמאזון עם הקונספט של ״פונקציות ולא סרברים״. אין לך סרבר משלך , המתכנת מממש פונקציה משלו ב Node.js, Python, Java או אחר. ואלו רצות על תשתיות על אמאזון מבלי דאגות של Scale.

5:00 ההבדל בין Microservice לבין AWS Lambda, אוסף של פונקציות לעומת תשתית

6:57 ההבדל המשמעותי בין Lambda לבין Heroku ו Paas אחרים הוא שב Lambda כותבים אך ורק פונקציה - היחידה האטומית היא מאוד קטנה לעומת כתיבת Service שהוא שרת שלם.

7:46 הסוד הוא ב UNIXification של התוכנה. כותבים הרבה מאוד יחידות קטנות של פונקציונליות ומחברים אותן עם כלים חזקים כמו Message queues או דאטאבייסים המייצאים Stream, והתשתית הזו מסופקת ע״י אמאזון (או ספק אחר). הכלים הללו הבשילו לרמת פרודקשן והופכים לאופציה ריאלית לפיתוח.

9:30 קונספטים של למבדה: הפונקציות הן Stateless - בין הרצה להרצה לא שומרים על קבצים, אחרי ריצה - הדיסק ״מתאדה״. כשפונקציה מתחילה לרוץ היא מתחילה ״מאפס״ - ומוזנת מ ה Event או מידע מ S3 או דאטאבייס. זה אמנם אילוץ, אך הוא דוחף לארכיטקטורה נכונה שניתן לעשות לה Scale בפשטות יחסית.

11:24 אין סרברים, לא צריך לתכנת אותם, לתחזק אותם, לנטר אותם. הכל מאחורי אבסטרקציה, ומוריד הרבה מטלות תחזוקה.

12:25 הפונקציות הן Event driven - מחכות להודעות כדי לעבוד. יכולות להיות מוזנות ע״י הזנה לחלק אחר מהאקוסיסטם של אמאזון - S3, SQS, Kinesis, Dynamo DB. לדוגמא, אפשר לכתוב פונקציית Lambda, שבכל הזנה של קובץ תמונה ל S3, מייצרת עבורו גם Thumbnail (תמונה מוקטנת). הפונקציה תופעל לאחר שהוספת הקובץ ל S3, תבצע  ״Trigger״ באופן אוטומטי של ה״Event״.

13:45 שימוש ב Api Gateway של אמאזון כדי לחבר גם פעולות שמקורן בווב. זו אבולוציה של ה Lambda שהחל כיכולת ״פנימית״ בלבד לארכיטקטורה ואח״כ התווספה היכולת לקבל איוונטים מבחוץ ולהחזיר תשובות.

15:10 הקונספט של ״Infinite Scalability, Zero maintenance״ - כמובן בגבול הסביר.

15:41 גוגל הכריזו על Google cloud functions - אלטרנטיבה ל Lambda שנמצאת באלפא וכרגע תומכת רק ב Node.js.

16:10 שירות בשם iron.io שגם מציע אלטרנטיבה דומה.

16:55  סכנת ה Lock-in לספק השירות הספציפי - למשל ב AWS, התשתית תהיה תלויה בשירותים המשלימים של אמאזון ונוצרת סכנה של  ״Vendor Lock in״. הקוד עצמו (הלוגיקה) גנרי ולא תלוי תשתית, אך התלות ב״דבק״ - השירותים שמשנעים את המידע, מאוד תלוי ספק.

18:40 דוגמא איך הבדלי סמנטיקה בין ה Message Queues יכולה להשפיע על המימוש וליצור Lock-in, אפילו למוצר מסויים בתוך אותו השירות (כמו SQS לעומת Kinesis ששניהם שירותי תורים של AWS).

20:45 זה לא לחלוטין ניתן להעברה. יש Vendor Lock in גבוהה יותר מאשר כתיבת שרת ״old fashioned״, של node+ express, אבל זה צפוי להשתפר.

21:52 בטווך הארוך הרעיון הוא לבנות תשתית פונקציונלית בסיסית, והציפייה היא שהשירותים יישרו קו ויתמכו בפורמטים דומים.

23:00 טוב שיש תחרות מגוגל - כי יש בעיות רבות ואמאזון צריכים תחרות

23:30 מימוש: אפשר לכתוב Node.js, Python, Java או לכתוב Shim שיאפשר לכתוב בשפה אחרת - למשל Go, ע״י הרצתו כ Process עם Input - output. פריימוורק שמאפשר את זה מבלי לכתוב את ה Shim בעצמך הוא Apex.

24:57 התהליך של העלאת הפונקציות וניהולן די מתיש מול הממשק של AWS, ובגלל שצריך גם ניהול קוד. Apex נותן פתרון טוב ל Version control, Deployment, Rollback ותמיכה ב Go בנוסף לשפות שמוצעות ע״י Lambda.

27:00 בנוסף Apex נותן יכולות טובות לחיבור הפונקציות ל Events וניטור של התהליך. הניהול הזה הוא חלק נכבד מתהליך הפיתוח ב Lambda.

28:03 ב Apex החליטו לעבוד עם Terraform, כלי לניהול ה Infrastructure בענן. הכלי יכול לשמש למגוון של use cases להגדרת התשתיות בקוד (עם Version control). ב Apex השימוש ב Terraform הוא די הכרחי. ייתכן כי Apex יתרחב בעתיד מעבר לתשתיות של AWS בלבד.

31:31 נקודת התורפה בקונספט - האם באמת נחסך הצורך בלימוד כלים לניהול ה Infrastructure? אכן הניהול הוא נקודת חיכוך משמעותית ב Flow של Lambda.

32:43 זה יהיה הרבה יותר נחמד אם זה פשוט יעבוד. זה לא בשמיים לחבר פונקציה לתור והאבסטרקציה תגיע בקרוב. AWS LAmbda עוד צעיר ונמצא בגרסא 0.7

33:57 פריימוורק נוסף Serverless גם מנסה להתחרות בספייס הזה - להריץ Lambda על עננים שונים (כרגע רק באמאזון). Apex יחסית פשוט יותר, אבל שניהם בכיוון הנכון. חיוני להשתמש באחד מהם כדי לעבוד עם  Lambda.

35:09 ניהול התשתיות הוא נקודת חיכוך שקיימת גם ככה בניהול שרתים ״Old school״. עדיף לעשות את זה נכון עם ניהול הרשאות

36:05 ה Tool fatigue מהאקוסיסטם של Javascript מגיע גם ל Devops, ולימוד של כלי חדש (כמו Lambda) מכריח ללמוד כלים נלווים נוספים.

38:28 יש מגוון Use cases. למשל Api Gateway + Lambda. שירות Cronjob (למשל שליחה ל Slack פעם ביום בשעה 10). דוגמא נוספת ל Slack היא שליחת הודעות בתגובה ל Events בתשתית (העלאת שרת, הורדת שרת). העלויות זניחות למקרה שבו ה Workload נמוך - זה עדיף מהחזקת שרת לצורך המשימה.

40:44 שימוש ב Analytics. חברת Segment.com פרסמה תיאור מעניין של Data pipeline בעזרת Lambda. זה יכול לשמש גם לניתוח מסוג Crawling. העלויות לעיבוד בקנה מידה גדול משמעותיות, וזה יכול להוות פקטור בבחירת הטכנולוגיה.

43:21 מימוש Data pipeline באמצעות Lambda Architechture, המימוש של AWS Lambda דומה בקונספט ל Use case של Data processing - פונקציות קטנות שהן Stateless שעושות את עבודתן ומעבירות הלאה. לא להתבלבל בין שניהם.

44:55 מימוש של רן ל Crawler הוא ניסוי. כרגע נראה שזה לא משתלם מבחינת זמן, אבל רק בעתיד נדע.

45:29 המלצה להשתמש ב Lambda רק עבור שירותים פנימיים ולא כחלק מליבת המוצר. זה כדי לחסוך בעלויות ולהכיר את טכנולוגיית העתיד במקום עם סיכון נמוך.

48:10 ב Bringg מגייסים מתכנתי iOS.

תודה רבה לשי אלון על התקצור. הקובץ נמצא כאן.

יום שני, 18 באפריל 2016

296 NLP with Yoav Goldberg

אנחנו בפודקאסט 296 התאריך הוא ה 13 למרץ ואנחנו מארחים את יואב גולדברג לשיחה על NLP- תחום עיבוד שפה טבעית וחלקו בMachine Learning.
  • 2:24 – NLP – עיבוד שפה טבעית – אלגוריתמים שעובדים על טקסטים אנושיים ומוציאים מידע שימושי מתוך הטקסט.
  • 5:54 – שימושים מעניינים בNLP כגון שימוש GOOGLE בחיפוש – הבנה של כוונת המשתמש והדפים שעליהם מחפשים. האפשרות לשאול את מנוע החיפוש שאלות בשפה טבעית וקבלת התשובות.
  • 9:32- הדגש על הבנת הדומיין בעיבוד שפה – לעומת סירי שעובדת בדומיין מוגבל וקטן יחסית, גוגל עובדת בדומיין מאוד רחב. דוגמא עבור שימוש מדומיין ספציפי – גוגל מאפשרת לקרוא מהמייל אישורי טיסה ולהכניס ליומן זימון לטיסות בתאריכים הנכונים.
  • 13:17- אחד הנושאים שחשוב להבין בNLP הוא קושי הבעיה, למרות התפיסה שזהו מימוש פשוט ולאדם זוהי משימה קלה, המשימה עבור מחשב היא מורכבת. קיימות ספריות בסיסיות לניתוח תחביר וניתוח חלקי דיבר ומעליהן יש לממש את האפליקציה הספציפית (לדוגמא NLTK בפייתון)
  • 17:50 – אין מוצר שמבין עמוקות את הטקסט – יוצאות דופן הינן מערכות הדיאלוג שמנסות להבין את בקשת המשתמש ולמפות שפה טבעית ל"שפת מחשב" ואובייקטים.
  • 19:50 – הקשר בין  Machine Learning ל NLP – הגישה בעבר הייתה כתיבת ותחזוקת חוקים לצורך עיבוד השפה. לפני כעשור נעשה מעבר לעולם הלמידה- Machine Learning – המחשב רואה דוגמאות עם תשובות ולאחר הלמידה יודע לסווג את הדוגמאות וקלטים חדשים.  עדיין – ישנה התערבות ידנית בתהליך הלמידה והגדרת בעיית הסיווג – לדוגמא בעיית סיווג עמודים ברשת לפי נושא.
  • 26:35- היבטי Deep learning בעיבוד שפה – בשנים האחרונות נכנסים אלגוריתמי Deep learning לעולם ה NLP אך הם עדיין לא חזקים.
  • 27:50 – המחקר העכשווי של יואב - תשתיות של עיבוד שפה – לקחת את אבני הבניין של עיבוד השפה ולשפר אותן. רוב המחקר נעשה באנגלית – השפה הנפוצה במוצרים ובמחקר.
  • 32:50- יואב פעיל ב Git ובעבודות האחרונות אבל לדאבונו, מייצר יותר מסמכי LaTex  מאשר קוד -  בפרוייקט קוד נוכחי מייצר ספריית Deep Learning לעיבוד שפה רכיב Core בשפת C++  ומעליו Wrapper בPython
  • 35:35 – טיפ לסיום – לא להשתמש בNLTK – היא ספרייה לימודית בעיקרה ולא לשימוש בProduction. עדיף להשתמש בSpacy.IO דמו :https://sense2vec.spacy.io/?natural_language_processing%7CNOUN.
  • וספריה נוספת שלא הוזכרה Gensim  

תודה רבה לחן סלומון על התקצור! הקובץ זמין כאן להאזנה.