מימוש זיהוי תמונות באפליקציה לנייד

מדוע זיהוי תמונות באפליקציה מאט וטועה

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

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

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

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

מה משתנה לאחר ההטמעה: דיוק, מהירות, כשלים

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

לפי מדידות בענף על סטים מסומנים, דיוק הזיהוי לפי מחלקות עיקריות עולה מ-80–85 ל-92–97% — ונשמר בזרימה, ולא רק במדגם הדגמה. אותם נתונים מובאים בהרצות פומביות של MLPerf Mobile, כלומר מדובר בערך משוחזר, ולא בניסוי בודד מוצלח.

מהירות עיבוד התמונה הופכת לצפויה: תשובה על פריים מגיעה תוך 0,3–0,6 שניות ישירות במכשיר, ללא המתנה לרשת. זה משנה את התרחיש עצמו — העובד מכוון את המצלמה ורואה תוצאה מבלי לצאת מתהליך העבודה, ותור התמונות מעובד במקביל לעבודה העיקרית.

הנתון שהכי משתנה הוא שיעור התיקונים הידניים: במקום שבו מפעיל עבד מחדש על כל פריים רביעי-חמישי, נשארים אחוזים בודדים — הם נראים ביומן וניתן לטפל בהם נקודתית. נעלמות קטגוריות שלמות של כשלים: "לא זיהה", "זיהה אובייקט שגוי", "תשובה לא הגיעה בזמן". כל אחד מהם עלה בעבר בביקור חוזר או בשיחה ללקוח.

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

מצבי זיהוי תמונות: במכשיר או בשרת

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

להלן — שלושה מצבים כפי שאנחנו מטמיעים אותם בארכיטקטורה.

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

אם הקשר אבד, פריימים ותגיות נשמרים בתור מקומי ונשלחים כשהקשר מתחדש — עבודה ללא קשר אינה מביאה לאובדן נתונים, ופער בתשובות משני הצדדים נפתר בבדיקה חוזרת.

שלבי העבודה: ביקורת נתונים, סכימה, כיול, קבלה

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

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

1. ביקורת נתונים. מנתחים ארכיון תמונות: נפח, תנאי צילום, התפלגות מחלקות, סתירות בסימון. הפלט — מפת בעיות והבנה אילו דוגמאות חסרות.
2. הכנת מדגם. מסירים כפילויות וקבצים פגומים, משלימים מחלקות נדירות, מקבעים חלק מושהה של המדגם שאינו משתתף באימון. דווקא הוא נותן הערכה הוגנת של התוצאה.
3. סכימת פתרון. קובעים מה נחשב במכשיר ומה בשרת, כיצד מטופל ביטחון נמוך ומה רואה המשתמש בזיהוי כושל.
4. כיול ואימון. מאמנים את המודל על נתונים מוכנים ועוקבים אחרי דיוק לפי כל מחלקה בנפרד, ולא רק אחרי מדד ממוצע.
5. אינטגרציה באפליקציה. מטמיעים את הזיהוי בתרחיש המשתמש, מודדים זמן תגובה וגודל בנייה, בודקים התנהגות ברשת חלשה ובמכשירים ישנים.
6. קבלה בתנאים אמיתיים. מריצים את המערכת על תמונות טריות מהזרימה החיה, מצליבים מדדים עם אלה שנקבעו בסכימה, מנתחים כל סוג שגיאה.
7. מסירת המערכת. מעבירים קונפיגורציות, סקריפטים להכנת נתונים, תיאור מדדים וסדר אימון מחדש על דוגמאות חדשות, כדי שצוות הלקוח יוכל לפתח את הפתרון בעצמו.

ערכת מסירה: סכימות, מדיניות גישה, נהלי סימון

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

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

מקרה בוחן: כיצד צמצמנו בדיקה ידנית של תמונות בחשבונאות

לפני ההטמעה, הקבלה ב-«Товароучёт» נשענה על אנשים: מחסנאי צילם כל פריט, והמפעיל אחר כך השווה ידנית את התמונה עם תעודת המשלוח. על אצווה של 300 פריטים נדרשו 40–50 דקות, וכעשירית מהתמונות הכילו שגיאה — מק"ט מבולבל, תווית לא קריאה, פריים מיותר. פערים צפו רק בספירת מלאי, כשנאלצו לחפש אותם בכל היסטוריית הקבלות.

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

את המודל אימנו מחדש על תמונות מסומנות של הלקוח — תחילה על כמה אלפי פריימים, אחר כך פעם ברבעון, תוך הוספת מה שהמפעילים סימנו בבדיקה ידנית. פריימים שנויים במחלוקת לא נזרקים: הם הופכים לחומר לאימון מחדש הבא.

מדדים נלקחו על סט מושהה ועל זרימת קבלות חיה. דיוק זיהוי מק"ט לפי תמונה עלה מ-91% ל-98,6%, שלמות — עד 97%, שיעור התמונות שנשלחו לבדיקה ידנית ירד מ-100% ל-7%. זמן קבלה ממוצע של אצווה הצטמצם מ-45 ל-6 דקות: המפעיל מסתכל לא על הכול ברצף, אלא רק על פריימים בעייתיים.

האפקט העיקרי של אוטומציית בדיקת התמונות — פער נראה ברגע הקבלה, ולא אחרי שבוע. דיוק ושלמות מחשבים לא לפי ממוצע, אלא לפי כל סוג תווית בנפרד: על מדבקות מקומטות ומבריקות הערכים נמוכים יותר, וסף הביטחון עבורן מכויל מחמיר יותר.

מה לעשות אם כבר פרוסה מערכת צד שלישי לעיבוד תמונות

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

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

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

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

ספקות טכניים: תאורה, זווית, פרטיות נתונים

צילום מיד — המקור העיקרי לשגיאות: פריים מטושטש, תאורה נגדית, צל מהיד, הטיה בזווית. לפני הזיהוי התמונה עוברת נרמול — יישור לפי ניגודיות, הפחתת רעש, הבאה לקנה מידה אחיד — ובפריימים מורכבים זה מחזיר את הדיוק לרמת צילום סטודיו.

פרטיות נפתרת בארכיטקטורה, ולא בהבטחות. כברירת מחדל הפריים מעובד במכשיר עצמו, ולשרת עוברת רק תוצאת הזיהוי; אם לפי המשימה נדרשת העברת תמונה, היא עוברת אנונימיזציה, מוצפנת בהעברה ונשמרת לזמן מוגבל.

כיצד הזיהוי מתנהג בזווית גרועה?

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

כיצד מנותקות התראות שווא?

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

האם אפשר לעבד פריים בלי לשלוח לשרת?

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

נדון במשימה: מה לקחת בחשבון לפני תחילת העבודה

כדי לחזור עם הערכת פרויקט זיהוי, ולא עם טווח רחב, נדרשים נתוני פתיחה משני הצדדים. ההערכה נשענת על שלושה עמודים: אילו אובייקטים מזהים, כמה נתונים יש ובאיזו צורה, והיכן מחשבים — במכשיר או בשרת. חלק מהתשובות כבר יש לכם, חלק מקבעים יחד והופכים לתוכנית עבודה.

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

תארו את המשימה בצורה חופשית, גם אם חלק מהסעיפים עדיין פתוחים. נחזור עם הערכה, תוכנית עבודה וסדר שלבים, ואת נתוני הפתיחה החסרים נשלים בדיון.