מערכת AI לניתוח ערך תזונתי של מוצרים

ניתוח תזונה ב‑AI: מדוע צילום של מנה יוצר פיזור בקלוריות

ערך קלורי מחושב לפי מסה, לא לפי תמונה: הצילום נותן נפח, צבע ומרקם, אך לא משקל. טעות בהערכת משקל המנה בעין — בדרך כלל בטווח של שליש, ובמשקאות? Wait sauces and oil up to double. And it linearly transfers. לכן שתי מנות זהות בתמונה נבדלות בחישוב פי אחד וחצי עד פי שניים.

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

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

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

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

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

אפקט ההטמעה: מהירות עיבוד ושיעור התיקונים הידניים

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

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

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

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

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

מצבי זיהוי: צילום, ברקוד, הזנה ידנית והיברידי

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

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

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

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

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

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

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

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

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

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

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

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

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

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

כיצד ארגנו את הפירוק

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

מדדים לפני ואחרי

שיעור הפריטים שפורקו ללא מפעיל עלה מ‑58% ל‑93% — ידנית נשארו בעיקר תמונות מקומטות וזרוחות אור. שגיאות בקלוריות ובחלבון/שומן/פחמימות במדגם בקרה הצטמצמו מכרטיס אחד מתוך שנים־עשר לאחד מתוך שישים.

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

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

במה שונה הערכה לפי צילום מפירוק הרכב לפי תווית?

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

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

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

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

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

ספקות לגבי איכות הנתונים: מפרקים שאלות נפוצות

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

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

כיצד נלקח בחשבון מלאי עונתי?

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

מה עם עיבוד בחום ואובדנים?

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

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

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

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

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

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

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

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