שילוב זיהוי צמחים מבוסס בינה מלאכותית באפליקציית מובייל

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

פיתוח ותמיכה בכל סוגי היישומים הניידים:

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

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

השירותים שאנו מציעים
מציג 1 מתוך 1כל 1734 השירותים
שילוב זיהוי צמחים מבוסס בינה מלאכותית באפליקציית מובייל
בינוני
מ- 4 שעות עד 2 ימים

הכישורים שלנו:

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית מובייל עבור FEEDME
    פיתוח אפליקציית מובייל עבור FEEDME
    971
  • פיתוח אפליקציית מובייל עבור XOOMER
    פיתוח אפליקציית מובייל עבור XOOMER
    869
  • פיתוח אפליקציית מובייל עבור RHL
    פיתוח אפליקציית מובייל עבור RHL
    1289
  • פיתוח אפליקציית מובייל עבור ZIPPY
    פיתוח אפליקציית מובייל עבור ZIPPY
    1143
  • פיתוח אפליקציית מובייל עבור Affhome
    פיתוח אפליקציית מובייל עבור Affhome
    1076
  • פיתוח אפליקציית מובייל עבור חברת FLAVORS
    פיתוח אפליקציית מובייל עבור חברת FLAVORS
    677

מדוע זיהוי צמחים באפליקציה נכשל

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

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

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

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

מה משתנה לאחר ההטמעה: זמן תגובה ודיוק

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

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

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

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

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

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

תכניות זיהוי צמחים: במכשיר ובענן

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

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

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

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

שלבי ההטמעה: מביקורת תמונות ועד מסירת המודל

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

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

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

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

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

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

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

חבילת המסירה: מודל מאומן, תיוג, נהלים

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

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

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

מקרה בוחן: זיהוי מין ומחלות לפי תמונה מהשטח

איך היה לפני ההטמעה

המשתמש שלח תמונה לתמיכה, הנציג השווה אותה ידנית למדריך וחזר עם תשובה בטקסט. זמן התגובה הממוצע — 6-8 שעות, בשיא העונתי זה הגיע עד ליממה, ושאלות הבהרה («צלמו שוב את העלה», «נדרש צילום מהצד השני») שלחו את האדם לסבב המתנה שני. שיעור שאלות ההבהרה הללו עמד על כשליש מהפניות.

מה שינינו

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

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

מה השתנה במספרים:

  • זמן עד לתשובה: מ-6-8 שעות ל-2-4 שניות ישירות על המסך.
  • שיעור שאלות ההבהרה: מ-31% ל-9% — בעיקר נותרו גידולים נדירים.
  • העומס על הקו הראשון של התמיכה ירד פי ארבעה, והמהנדסים שהתפנו עסקו בבירור מקרים מורכבים.
  • דיוק על מדגם בדיקה של 2000 תמונות — 94% למין ו-88% לסימני מחלות.

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

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

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

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

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

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

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

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

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

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

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

ספקות טכניים: צילום, תיוג, נפח נתונים

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

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

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

המשתמש מצלם בדמדומים — האם הזיהוי לפי תמונה יידרדר?

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

לאן מגיעות התמונות של המשתמשים?

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

כמה זמן ייקח אימון המודל לפלורה שלנו?

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

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

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

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

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