רווחים:
- יכולת להחליט במכשיר או בענן ולבחור בכלי המתאים (ML Kit, Core ML, TensorFlow Lite) בהתבסס על פרטיות, צורך במצב לא מקוון, גודל הדגם וקריטריוני הסוללה
- יכולת למנוע שגיאות שקטות על ידי אימות עיבוד מקדים של קלט (גודל ונורמליזציה) ממסמך המודל בשילוב המודל
- יכולת להעריך את ציון הביטחון ולמדוד את התוצאה באישור המשתמש ובמכשיר האמיתי, מבלי להציג תחזיות ביטחון נמוך כאמת מוחלטת.
עד כה, השתמשנו בבינה מלאכותית ככלי עזר להאצת תהליך הפיתוח. כעת נעבור לתפקיד השני של AI: הכישרון המוטמע באפליקציה. לטלפונים מודרניים יש את הכוח להפעיל דגמי בינה מלאכותית כגון זיהוי תמונות, תרגום טקסט, תמלול דיבור וכו' ישירות על המכשיר (במכשיר - במעבד של הטלפון עצמו מבלי לעבור לשרת). AI במכשיר; הוא מציע יתרונות גדולים על פני פתרונות ענן מבחינת מהירות, פרטיות ותפעול לא מקוון. ביחידה זו, נלמד כיצד להטמיע בינה מלאכותית באפליקציה עם Core ML של iOS, TensorFlow Lite חוצה פלטפורמות (הידועה כיום בשם LiteRT) והפתרון המוכן ML Kit של גוגל, וכיצד להשתמש ב-AI כעוזר באינטגרציה זו.
במכשיר או בענן?
זוהי ההחלטה האדריכלית הראשונה והחשובה ביותר. AI במכשיר אינו מסיר נתונים מהטלפון - ניצחון ענק לפרטיות. זה גם מיידי ועובד במצב לא מקוון מכיוון שאין חביון רשת. עם זאת, הוא מוגבל על ידי כוח העיבוד והזיכרון של המכשיר; דגמים גדולים מאוד (למשל דגמי לשון ענק) לא יכנסו לטלפון או ירוקנו את הסוללה. לעומת זאת, ענן AI מציע עוצמה בלתי מוגבלת, אך שולח נתונים לשרת, דורש רשת ויוצר חביון.
קריטריון
במכשיר
ענן (Cloud API)
פרטיות
הנתונים נשארים במכשיר, חזקים
הנתונים עוברים לשרת, יש צורך בתשומת לב
מהירות
מיידי, אין רשת
תלוי בהשהיית הרשת
במצב לא מקוון
זה עובד
לא עובד
גודל הדגם
מוגבל (משאב טלפוני)
בלתי מוגבל
סוללה/חום
אפקטים עם שימוש רב
שרת תחת עומס, המכשיר רגוע
עלות
חינם (מקור מכשיר)
עמלה לכל שימוש
כלל החלטה: בחר במכשיר אם נתונים אישיים/רגישים מעובדים, צריכים לעבוד במצב לא מקוון, או תגובה מיידית חיונית. אם אתה צריך דגם גדול מאוד, פנה לענן. יחידה זו ממוקדת במכשיר; ביחידה הבאה נסקור AI בענן.
טיפ: הפוך תמיד במכשיר לברירת המחדל שלך עבור תכונה המטפלת בנתונים רגישים (בריאות, ביומטריה, מיקום). הביטוי "נתונים לא עוזבים את המכשיר" הוא בעל ערך רב הן עבור ציות לפרטיות והן לאמון המשתמש, ועושה הבדל גדול בתווית הפרטיות של החנות.
שלוש דרכים: ML Kit, Core ML, TensorFlow Lite
ערכת ML (גוגל) היא הדרך הקלה ביותר להתחיל: היא מעניקה יכולות מוכנות כמו זיהוי טקסט (OCR - קריאת טקסט בתמונה), זיהוי פנים, קריאת ברקוד, תרגום בכמה שורות. אתה לא צריך להכשיר את הדגם שלך. Core ML (Apple) היא הדרך היעילה ביותר להפעיל דגם משלך או דגם מוכן ב-iOS; הוא משתמש בחומרה Neural Engine (מעבד רשת עצבית מלאכותית) של אפל. TensorFlow Lite/LiteRT הוא פתרון חוצה פלטפורמות המאפשר לך להפעיל דגם מיומן משלך גם באנדרואיד וגם ב-iOS.
זרימת האינטגרציה הכללית עם AI הולך כך:
- הגדרת כישרון. מטרה ברורה, כגון "אני רוצה לקרוא את הטקסט בתמונה".
- בחירת נתיב. אם יש כישרון מוכן, ML Kit; Core ML/TF Lite אם קיים דגם מיוחד.
- פורמט דגם. .mlmodel (Core ML), .tflite (TF Lite). מסביר את שלבי השינוי בינה מלאכותית.
- קוד אינטגרציה. טעינת המודל, עיבוד מקדים של הקלט, פירוש הפלט.
- מבחן ביצועים. מהירות, זיכרון, מדידת סוללה במכשיר אמיתי.
זהירות: טעות הבינה המלאכותית הנפוצה ביותר באינטגרציה של מודלים במכשיר היא עיבוד מקדים של קלט - המרת התמונה לגודל ולפורמט הצבע שהדגם מצפה לו. אם הדגם מצפה ל-224x224 פיקסלים ואתה נותן לו 300x300, התוצאה תהיה חסרת משמעות, אך לא תקבל הודעת שגיאה. אמת את ערכי העיבוד המקדים מהמסמך של הדגם.
הכרת גבולות המודל
מודל במכשיר מקבל החלטות על סמך הנתונים שעליהם הוא הוכשר. מודל זיהוי עצמים שאומן רק על תמונות שצולמו במהלך היום יטעה בתמונות לילה. למודל יש ציון ביטחון (ביטחון - עד כמה המודל בטוח בתשובה שלו, בדרך כלל בין 0 ל-1); מסוכן להציג למשתמש תוצאות בעלות אמון נמוכה כמדויקות. לדוגמה, יישום סריקת כתמי עור לא אמור לומר "שפיר בהחלט", אלא צריך לומר "התחזית של הדגם היא זו, נא להתייעץ עם רופא". תוצאת המודל היא המלצה, לא אבחנה.
שלושה מיני תיקים
מקרה 1 - האצה עם OCR. אפליקציית מעקב אחר הוצאות הסירה את הנטל של הזנה ידנית של קבלות עם זיהוי טקסט של ML Kit. המשתמש מצלם את הקבלה, והסכום והתאריך ממולאים באופן אוטומטי. זמן הכניסה הידני ירד מ-40 שניות ל-8 שניות לכל קבלה. הצוות תמיד ביקש מהמשתמש לאשר את הכמות שה-AI קרא; כי לקבלות מקומטות היה מרווח טעות של 6%. אוטומציה + אישור אנושי היה האיזון הנכון.
מקרה 2 - שגיאת עיבוד מקדים. צוות אחד שילב מודל זיהוי צמחים עם TensorFlow Lite; על הבוחן, התוצאות היו אקראיות. הבעיה הייתה שהקוד שה-AI יצר לא נרמל את התמונה לטווח [0,1] שהדגם ציפה לו (ערכי הפיקסלים נותרו ב-0-255). כאשר נוספה נורמליזציה, הדיוק גדל מ-30% ל-89%. שיעור: עיבוד מקדים שקט אך קטלני.
מקרה 3 - רווח בפרטיות. יישום בריאות זיהה חריגות מנתוני דופק עם מודל Core ML במכשיר. הנתונים מעולם לא הלכו לשרת. בחירה זו אפשרה לאפליקציה לקבל את הביטוי "לא אוספת נתונים" בתווית הפרטיות של App Store והגדילה את קצב ההורדות שלה בהשוואה למתחרים. הבחירה במכשיר הייתה גם אתית וגם רווחית מבחינה מסחרית.
הנחיה חלשה / הנחיה חזקה
הנחיה חלשה: "הוסף זיהוי תמונה לאפליקציה שלי."
הנחיה עוצמתית: "הוסף את תכונת קריאת הכמות והתאריך לאפליקציית Android/Kotlin שלי. - השתמש בזיהוי טקסט של Google ML Kit (במכשיר, במצב לא מקוון) - צלם תמונה מהמצלמה או מהגלריה - חילץ את הכמות והתאריך מהטקסט המזוהה עם ביטוי רגולרי - הצג את התוצאה למשתמש לאישור בשדה EDITABLE, שמירה אוטומטית ועיבוד שגיאה אוטומטית של מצב כתיבה ועיבוד מחדש של המצלמה. להסביר את השלבים."
תבניות הניתנות להעתקה
תבנית בחירת נתיב: "אני רוצה ליצור את התכונה הבאה: [פיצ'ר]. האם זה צריך להיות במכשיר או בענן? השווה על סמך: פרטיות, צורך לא מקוון, גודל דגם, סוללה, עלות. המלץ על הכלי המתאים (ML Kit / Core ML / TF Lite) והצדק."
תבנית אינטגרציה: "כתוב [דגם/יכולת] אינטגרציה עבור [פלטפורמה]:1) טעינת מודל2) עיבוד מקדים של קלט (גודל ונורמליזציה צפויים)3) קריאת הסקת מסקנות 4) פרשנות פלט ובדיקת ציון ביטחון 5) אזהרה למשתמש על תוצאת ביטחון נמוך הזכר לי לאמת את ערכי העיבוד המקדים מהתיעוד של המודל."
תבנית ציון ביטחון: "שקול את ציון הביטחון בקוד ההסקה הזה:- הצג את התוצאה 'מדויק' מתחת לסף (לדוגמה
תבנית אימות ביצועים: "רשום את המדדים שעליי למדוד במכשיר בפועל עבור שילוב מודל זה במכשיר: זמן מסקנות, הגדלת זיכרון, השפעה על הסוללה, חימום. ספר את שיטת המדידה עבור כל אחד מהם."
טעויות נפוצות
- דילוג על עיבוד מקדים או ביצוע לא נכון. גודל שגוי/נורמליזציה מייצרת בשקט תוצאה שגויה.
- התעלמות מציון הביטחון. הצגת אומדן בעל ביטחון נמוך כמדויק תטעה את המשתמש.
- בדיקת הדגם באמולטור. מהירות המכשיר והסוללה בפועל שונים מאוד; תמיד למדוד על חומרה אמיתית.
- שליחת נתונים רגישים לענן שלא לצורך. הבחירה בענן כאשר אפשרית במכשיר היא סיכון פרטיות.
- התעלמות מגודל הדגם. אפליקציות דגמים גדולות מנפחות את גודל ההורדות וקורסות בחומרה נמוכה.
- שוכחים את מגבלת האימון של הדגם. הדגם טועה במצב בו אינו רואה (לילה, שפה אחרת); הבהירו זאת למשתמש.
לסיכום
AI במכשיר מספק פרטיות, מהירות ותפעול לא מקוון על ידי שמירת נתונים בטלפון; המגבלה היא כוח המכשיר וגודל הדגם. ערכת ML משמשת ליכולות מחוץ לקופסה, Core ML (iOS) ו- TensorFlow Lite (חוצה פלטפורמות) משמשות עבור דגמים מותאמים אישית. הרוצח השקט של האינטגרציה הוא עיבוד מקדים לא תקין; גודל הקלט והנורמליזציה מאומתים מהתיעוד של המודל. כל תוצאה מגיעה עם ציון ביטחון, ותחזיות ביטחון נמוך אינן מוצגות כאמת מוחלטת. החלטות נמדדות במכשיר האמיתי, לא באמולטור.
משימת יישום
עבור תכונת "קריאת טקסט מתמונה" או "קריאת ברקוד", שאל את ה-AI אם זה צריך להיות במכשיר או בענן עם "תבנית בחירת נתיב", ולאחר מכן בקש תוכנית מבוססת ערכת ML עם "תבנית אינטגרציה". ודא ששלב העיבוד המקדים וזרימת אישור/עריכה של המשתמש קיימים בקוד. הגדר סף ציון אמון וכתוב מה תעשה אם התוצאה תהיה אמון נמוך.
רשימת בדיקה
- [ ] קיבלתי את ההחלטה במכשיר/ענן על סמך קריטריונים
- [ ] בחרתי בכלי הנכון (ML Kit / Core ML / TF Lite)
- [ ] אימתתי את ממד העיבוד המקדים והנורמליזציה מהתיעוד של המודל
- [ ] בדקתי את ציון האמון והזהרתי מפני תוצאות אמון נמוכות
- [ ] הצגתי את התוצאה למשתמש באישור/עריכה, לא שמרתי אותה באופן עיוור
- [ ] מדדתי ביצועים במכשיר האמיתי, לא באמולטור