מדוע סיווג תמונות ב-AI נשבר בגלריות אמיתיות
סיווג תמונות ב-AI על גבי עמדת הדגמה נראה משכנע: עשרה צילומים נקיים, קטגוריות מסודרות, תגובה מיידית. בגלריה אמיתית אותו מודל מתפרק בתוך ימים ספורים. המשתמש מצלם סדרות של 10-20 פריימים ברצף, מחציתם כמעט זהים, חלקם מטושטשים תוך כדי תנועה, חלקם צולמו בחושך עם רעש.
המודל רואה בהם לא "כפילויות של צילומים" אלא תמונות שונות, ותיוג התמונות הופך לכאוס: אותה סצנה מפוזרת על פני שלוש קטגוריות, ולצדן מונחים פריימים שלא נכנסו לשום מקום בכלל.
צרה נפרדת היא קטגוריות שגויות. צילום של אוכל באור חם נודד ל"מסמכים", ילד בבריכה — ל"בעלי חיים", צילום מסך עם טקסט — ל"נופים".
ככל שיש יותר קבצים, כך הטעות בולטת יותר: בעשרות אלפי צילומים אפילו 3-5% החטאות מייצרות אלפי תמונות שלא במקומן, והמשתמש מפסיק לסמוך על מיון הגלריה. בהמשך נשבר החיפוש לפי תמונות: אדם מחפש "ים", לא מוצא, מדפדף ידנית ועוזב את האפליקציה.
יש גם צד הנדסי לחלוטין. מימוש נאיבי מריץ כל קובץ דרך המודל בכל פתיחה של הגלריה — זמן התגובה גדל באופן ליניארי ובנפחים גדולים הופך לבלתי נסבל. צילומים מטושטשים וחשוכים נוספים ומ� clog את האינדקס בוקטורים של זבל, והכפילויות מייצרות רשומות זהות שהמודל לא מצליח לבחור ביניהן.
מפרקים כיצד זה נסגר: היכן למקם את מסנן האיכות לפני המודל, כיצד לכווץ סדרות לפריים אחד, במה להגביל התראות שגויות וכיצד לחשב מאפיינים פעם אחת ולא בכל הצגה.
מה נותנת סיווג נכון: השפעה במטריקות
סיווג מפסיק להיות "פיצ'ר לשם סימון וי" כאשר ההשפעה שלו נראית במטריקות המוצר. אנחנו מסתכלים על שלושה מדדים מדידים: מהירות החיפוש של התמונה הרצויה, שיעור הקטגוריות השגויות וזמן העיבוד של אצוות תמונות חדשה. именно הם מראים אם המודל משתלם על גלריה אמיתית של המשתמש, ולא על סט הדגמה של עשר תמונות.
מהירות החיפוש — הדבר הראשון שאדם מרגיש. כאשר התמונות מסודרות לפי קטגוריות במכשיר, ולא נשלחות לשרת, התוצאה מופיעה בשברירי שנייה: המשתמש מקליד "מסמכים" או "קבלות" ומיד רואה את מה שצריך.
בגלריה של כמה אלפי תמונות זה ההבדל בין "גולל ומחכה" ל"מצאתי מהשאילתה הראשונה" — וזה בדיוק מה שמחזיק את האדם באפליקציה.
דיוק הקטגוריות נמדד לפי שיעור ההפעלות השגויות: כמה תמונות נכנסו לקבוצה הלא נכונה. אנחנו שומרים על מדד זה נמוך הודות לאימון נוסף על תמונות של מוצר ספציפי, ולא על סט אוניברסלי. ככל שיש פחות שגיאות, כך המשתמש מפסיק פחות לסמוך על האוספים וחוזר פחות לגלילה ידנית.
זמן העיבוד של אצוות תמונות חדשה קובע כמה מהר הגלריה נשארת רלוונטית. הסיווג מתבצע באופן אינקרמנטלי: מעובד רק מה שהתווסף, ולא כל הספרייה מחדש. לכן גם לאחר צילום של מאות פריימים חדשים האוספים מתעדכנים ללא השהיה מורגשת, והעומס על המכשיר נשאר צפוי.
שלוש המטריקות הללו קשורות זו בזו: חיפוש מהיר חסר תועלת כשיש שיעור שגיאות גבוה, ודיוק גבוה מאבד משמעות אם העיבוד מאט את הממשק. אנחנו מכווננים אותן יחד ובודקים בתרחישים אמיתיים — כך חוויית המשתמש הופכת למדידה, ולא להצהרתית.
כיצד פועלת סיווג AI של תמונות באפליקציה לנייד
הסיווג מתחיל בחילוץ מאפיינים: המודל מריץ את הצילום ומחזיר וקטור — קבוצת מספרים המתארים את תוכן הפריים. לפיו התמונות מושוות זו לזו, ולא לפי שם הקובץ או התאריך. לשם כך אנו משתמשים ב-Core ML ב-iOS ואנלוגי ב-Android — ה-inference מתבצע על המכשיר, והתמונות אינן עוזבות את הטלפון.
לאחר מכן הווקטורים נכנסים לאינדקס של הגלריה — אחסון מקומי שבו כל תמונה מקבלת רשומה עם וקטור ומטא-נתונים. קיבוץ התמונות מבוסס על קרבה בין וקטורים: פריימים דומים נאספים לאשכולות שהמשתמש רואה כ"חוף", "מסמכים", "ילדים". האינדקס נבנה מחדש באופן אינקרמנטלי — כאשר מתווספות תמונות חדשות, מעובדות רק הן, ולא כל הספרייה.
סנכרון בין מכשירים הוא הקטע הרגיש ביותר. הווקטורים נשלחים לשרת בצורה דחוסה ומקושרים למזהה של התמונה, ולא לקובץ עצמו: כך המטא-נתונים אינם מתנפחים לגדלים של הגלריה כולה. אם המשתמש מחק תמונה במכשיר אחד, הרשומה מבוטלת לפי המזהה, והאשכול נבנה מחדש בלעדיה.
בפועל זה נותן גלריה שמחפשת לפי משמעות, ולא לפי תגיות: "הראה לי קבלות של החודש" עובד ללא סימון ידני. דיוק הקיבוץ תלוי באיכות המודל — אנו מאמנים אותו מחדש על תמונות אמיתיות של הלקוח, ולא משאירים את הבסיסי.
השוואת גישות: על המכשיר, בענן, היברידי
הבחירה בין עיבוד על המכשיר, בענן ותוכנית היברידית נקבעת לא על ידי "אופנתיות" הגישה, אלא על ידי היכן פיזית נמצאות התמונות וכמה חישובים דורשת המודל.
עיבוד על המכשיר מתבצע על מאיץ הנוירונים של הטלפון: התמונה אינה יוצאת מהגלריה, פרטיות התמונות נשמרת כברירת מחדל, השהיה מינימלית, אך המודל מוגבל על ידי הזיכרון ותקציב החום של המכשיר.
עיבוד בענן מסיר מגבלות אלו — זמינים מודלים גדולים ועדכון שוטף של מילון המחלקות, אך כל פריים נשלח לשרת, והזיהוי תלוי ברשת.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| על המכשיר | פרטיות קריטית, נדרשת עבודה לא מקוונת, המחלקות יציבות | המודל מצומצם בגודלו, מכשירים חלשים מתחממים ומאטים |
| בענן | ספריית מחלקות גדולה, עדכוני מודל תכופים, אנליטיקה עוצמתית | ההשהיה תלויה בערוץ, עלויות התעבורה והחישוב גדלות עם הנפח |
| היברידי | נדרש איזון: תגובה מהירה ותרחישים חכמים | לוגיקה מורכבת יותר: שני מעגלים, סנכרון תוצאות, חלוקה לפי סוגי פריימים |
תוכנית היברידית נראית בדרך כלל כך: מודל קל על המכשיר מתייג את עיקר התמונות מיד, ופריימים שנויים במחלוקת ונדירים נשלחים לענן להעשרה.
הדבר מפחית את העומס על הערוץ ושומר על פרטיות עבור תמונות רגישות, אך דורש כלל ניתוב מחושב היטב — אחרת המשתמש יראה אי-התאמה בין תגיות מקומיות לתגיות מהענן.
בנפרד יש לתכנן הגירה: החלפת גישה לא אמורה לשבור גלריה שכבר תויגה. אנו מתכננים את התוכנית כך שתוצאות הסיווג יישמרו בנפרד מהמקורות, והאינדוקס מחדש יתבצע ללא אובדן עריכות המשתמש.
שלבי יישום: מביקורת הגלריה ועד למסירת הנהלים
את העבודה מתחילים בביקורת הגלריה: בודקים מה באמת נשמר אצל המשתמשים — שיעור הכפילויות וצילומי המסך, פיזור הרזולוציות, קבצים פגומים ושאינם הורדו במלואם, ההתפלגות לפי אלבומים.
על בסיס נתונים אלה בונים סכמת טקסונומיה: כמה מחלקות פותחים, מה עובר ל"אחר", וכיצד מטפלים במקרי גבול כמו סלפי במראה או צילום מסך של התכתבות.
- ביקורת הגלריה. מייצאים מדגם אנונימי, מחשבים סטטיסטיקה לפי סוגי תוכן ומאתרים מחלקות שהמסווג יתבלבל בהן. התוצאה — רשימת קטגוריות וקריטריונים שלפיהם תמונה משויכת לכל אחת מהן.
- תכנון הסכמה. קובעים את עץ הקטגוריות, כללי העדיפות במקרה של חפיפה וההתנהגות כאשר הביטחון נמוך: התמונה עוברת ל"אחר", ולא לאלבום אקראי.
- הגדרת המסווג. מתאימים מודל לפרופיל הגלריה ולמגבלות המכשיר, מגדירים את סף הביטחון ואת כללי הקיבוץ. חלק מהחישובים מתבצעים על המכשיר — התמונות אינן יוצאות מהטלפון.
- בדיקה על נתונים אמיתיים. מריצים את המסווג על מדגם, מחשבים את שיעור השיוכים הנכונים בכל קטגוריה ומנתחים את השגיאות. את הסף ואת הכללים מתקנים עד לדיוק מקובל.
- אינטגרציה באפליקציה. מטמיעים את העיבוד במשימות רקע, כך שהסיווג מתבצע בזמן טעינה ואינו מפריע לעבודת הממשק.
- מסירת התיעוד. מוסרים את הנהלים: סכמת הקטגוריות, ההגדרות, סדר האימון מחדש וטיפול במקרים שנויים במחלוקת.
לאחר המסירה, צוות הלקוח יכול לשנות קטגוריות וספים ללא מעורבות שלנו. תארו את המשימה — נחזור עם הערכה ותוכנית לגלריה שלכם.
מה הלקוח מקבל לידיו לאחר ההטמעה
הטמעת סיווג תמונות ב-AI אינה מסתיימת בהדגמה של אב-טיפוס עובד, אלא במסירת ערכה שלמה שלפיה ניתן לפתח ולתחזק את האפליקציה בלעדינו. להלן מה שמתועד במסמכים ובמאגרי הקוד עד למועד המסירה.
- תצורות של המודל ושל שירות הסיווג. קבצי פרמטרים של האינפרנס, ספי ודאות לפי קטגוריות, כללים לסיווג תמונה כ"אחר" — עם הערות המסבירות מדוע נבחרו ערכים אלה.
- סכמות נתונים. מבנה האחסון של אמבדינגים ותוויות, פורמט החלפה בין האפליקציה לשירות, מיגרציות בעת שינוי טקסונומיית הקטגוריות.
- מדיניות גישה. הפרדת הרשאות לקריאת מטא-נתונים, ייצוא מערך נתונים לאימון נוסף, גישה ללוגים של העיבוד; בנפרד — כללים לעיבוד תמונות משתמש ותקופות האחסון שלהן.
- תיעוד המודל. כרטיס מודל: על אילו נתונים אומן, אילו קטגוריות הוא מבחין בהן בביטחון, היכן הוא טועה, כיצד לפרש את מדדי האיכות בולידציה.
- נהלי תחזוקה. סדר האימון הנוסף עם הופעת קטגוריות חדשות, תדירות בדיקת האיכות על תמונות חדשות, כללים לחזרה לגרסה קודמת של המודל.
- הוראות לצוות הלקוח. כיצד להפעיל אינדוקס מחדש של הגלריה, כיצד לקרוא דוחות על שיעור התמונות שלא זוהו, לאן להסתכל כשזמן העיבוד גדל.
- תוכנית פיתוח. רשימת שיפורים עם הערכת ההשפעה על האיכות — מהרחבת הטקסונומיה ועד חיבור חיפוש לפי תוכן התמונה.
כל ארטיפקט קשור לתרחיש תפעול מוגדר: עדכון קטגוריות, טיפול בתלונות על מיון שגוי, הכנת מדגם לאימון נוסף. ערכה כזו מאפשרת לצוות שלכם לבצע שינויים באופן עצמאי, ולפנות אלינו באופן ממוקד — במשימות שבהן נדרשת עיבוד מחדש של המודל עצמו.
במה שונה סיווג במכשיר מעיבוד בענן
הגבול עובר לפי היכן שהנתונים ומשאבי המחשוב נמצאים פיזית. בסיווג במכשיר המודל פועל ישירות באפליקציה: התמונה לא עוזבת את זיכרון הטלפון, האינפרנס מתבצע על המעבד הנוירוני או מאיץ גרפי, והתוצאה — תגיות, קבוצות, אינדקסים לחיפוש — נשארת מקומית.
בעיבוד בענן הצילום נשלח לשרת, שם הוא עובר דרך המודל וחוזר עם תיוג. מכאן נגזרים גם כל ארבעת הפרמטרים: פרטיות, איכות, השהיה, ותעבורה.
פרטיות הנתונים — הטיעון המרכזי לטובת המכשיר. הצילום לא חוצה את גבול האפליקציה, אין העברה ברשת, אין אחסון בצד זר, ולכן אין גם התחייבויות להגנת מידע אישי בהיקף שגורר עיבוד בשרת.
עבור גלריות שמכילות מסמכים, קבלות, תמונות אישיות, הדבר מסיר סוג שלם של סיכונים ומפשט את מעבר בדיקות של חנויות אפליקציות.
איכות המודל — זה שעבורו משלמים לענן. מודל בשרת גדול יותר, מאומן על נתונים עדכניים ומתעדכן בלי להוציא גרסה חדשה של האפליקציה. מודל מקומי מוגבל במשאבי הטלפון, ולכן נאלצים לכמת אותו ולקצץ בו.
בקטגוריות טיפוסיות — אנשים, אוכל, בעלי חיים, נופים — ההבדל כמעט לא מורגש, אבל בקטגוריות נדירות או ספציפיות הענן מנצח.
השהיית העיבוד והתעבורה קשורות ישירות. אינפרנס מקומי נותן תגובה בתוך שברירי שנייה ואינו תלוי באיכות החיבור: התיוג מופיע גם כשהטלפון במצב לא מקוון. הענן מוסיף סבב רשת — בערוץ חלש אלו שניות של המתנה, ובנסעות גם צריכת תעבורה. בגלריה של אלפי צילומים ההבדל בתעבורה הופך מורגש.
בפועל את הגבול מציבים לא כ"או-או", אלא בהיברידי: סיווג בסיסי מתבצע במכשיר, ומקרים כבדים או נדירים — כשהמשתמש עצמו יוזם חיפוש לפי משמעות — עוברים לענן בהסכמה מפורשת. כך הפרטיות נשארת כברירת מחדל, והאיכות מתחברת במקום שבו היא באמת נדרשת.
מקרה בוחן: איך גלריה עם 40,000 תמונות הפסיקה להאט
מה היה לפני השינויים
צוות עם אפליקציית גלריה פנה אלינו: 40,000 תמונות אצל משתמש פעיל, הסיווג בוצע על המכשיר ב-thread אחד ישירות בעת פתיחת המקטע.
בהפעלה קרה הגלריה הציגה אריחים ריקים 4-6 שניות, חיפוש לפי קטגוריית «מסמכים» החזיר תוצאה תוך 3.5 שניות, ושיעור הקטגוריות השגויות הגיע ל-22% — תמונות של קבלות וכרטיסי ביקור נפלו ל«אחר». המשתמשים פשוט גללו את הפיד ידנית, כי לא היה אמון במסננים.
מה שינו
פיצלנו את העבודה לשני שלבים. את מודל האינפרנס הכבד הוצאנו לתור רקע: הוא מעבד תמונות חדשות בקבוצות, בזמן שהאפליקציה לא בחזית, ואינו מתחרה עם רינדור הממשק.
מסווג קל לפי מטא-נתונים ותמונות ממוזערות נותן קטגוריה ראשונית מיד — המשתמש רואה תוצאה באופן מיידי, והתווית המדויקת מוצבת מאוחר יותר.
את תוצאות האינפרנס אנחנו שומרים באינדקס מקומי לצד ספריית המדיה, ולכן הפעלה חוזרת לא מחשבת מחדש את מה שכבר עובד. עבור קטגוריות שגויות הוספנו סף ביטחון: אם המודל לא בטוח, התמונה עוברת ל«לא מסודר», ולא לתיקייה אקראית — זה הסיר את עיקר ההתראות השגויות.
את ה-stack והמודל התאמנו למשימה, ואת הבנייה הסופית העברנו דרך המהנדסים שלנו על ספריות מדיה אמיתיות של משתמשים.
מדדים לפני ואחרי
| מדד | לפני | אחרי |
|---|---|---|
| זמן חיפוש לפי קטגוריה | 3.5 ש' | 0.4 ש' |
| שיעור קטגוריות שגויות | 22% | 6% |
| הפעלה קרה של הגלריה | 4-6 ש' | 1.2 ש' |
| עומס על המכשיר בעת פתיחה | שיאי, עם ירידת פריימים | אחיד, ללא ירידות |
בנפרד עקבנו אחרי שיעור התמונות ב«לא מסודר» — הוא נשמר בטווח של 4-5% ומשמש כאינדיקטור כן לאיכות המודל: עלייה משמעותה שהופיע סוג תוכן חדש שדורש אימון נוסף.
נדון במשימת סיווג התמונות שלכם
כדי לחזור עם הערכה ותוכנית, ולא עם מילים כלליות, אנחנו צריכים נתוני מקור על הגלריה שלכם. ספרו לנו מאיפה מגיעות התמונות (מצלמה, אפליקציות מסרים, ייבוא מהענן), כמה מהן יש למשתמש פעיל, ואילו קטגוריות אתם רוצים להבחין — אנשים, מסמכים, אוכל, בעלי חיים, צילומי מסך. מזה תלוי אם נבנה סיווג על מודל מוכן או נאמן אותו לתרחישים שלכם.
בנפרד נבהיר היכן בדיוק פועל הסיווג: על המכשיר או בשרת. זה משפיע על פרטיות, מהירות תגובה ודרישות לחיבור. אם התמונות לא צריכות לעזוב את הטלפון, נחשב על המכשיר — ואז התיוג מופיע באופן מיידי וללא רשת.
- דוגמאות לתמונות עם תיוג: 200-500 צילומים לכל קטגוריה, ואם יש — עם שגיאות הסיווג הנוכחיות.
- תיאור הקטגוריות: מה נחשב ל"מסמך", מה ל"צילום מסך", איך להתמודד עם פריימים גבוליים.
- הסטאק הנוכחי של האפליקציה: פלטפורמה, שפה, איך בנויים האחסון והצגת הגלריה.
- תרחיש המשתמש: היכן אנחנו מציגים את הקטגוריות — בחיפוש, באלבומים, באוספים חכמים.
- מגבלות: דרישות פרטיות, עבודה לא מקוונת, מכשירי יעד.
- מדדי הצלחה: איזה שיעור של פריימים הסיווג צריך לתייג נכון ומה נחשב לפספוס.
לפי הנתונים האלה אנחנו מעריכים את היקף העבודה, נוקבים בלוחות זמנים ומראים היכן הסיווג ייתן אפקט מידי והיכן ידרוש אימון נוסף על הנתונים שלכם. תארו את המשימה — נחזור עם הערכה ותוכנית.







