למה פרויקטי AI בתעשייה נכשלים לפני Production

המודל עבד מצוין. המערכת לא.

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

הנה איך זה מתחיל: 98.7% זיהוי. שבוע אחרי - 62%.

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

הערת מקור: הנתון של 80% מגיע מדוח RAND Corporation מאוגוסט 2024: "The Root Causes of Failure for Artificial Intelligence Projects and How They Can Succeed: Avoiding the Anti-Patterns of AI" מאת Ryseff, De Bruhl ו-Newberry, המבוסס על ראיונות עם 65 data scientists ומהנדסים (rand.org/pubs/research_reports/RRA2680-1.html). הנתון עצמו מוצג בדוח כהערכת שוק ("by some estimates") - לא כמדידה ישירה שלהם. מחקרים אחרים (Gartner, McKinsey) מציגים טווחים דומים. הכיוון עקבי ברוב הספרות; המספר המדויק פחות חשוב מהדפוס שהוא מתאר.

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

השאלה הראשונה שרוב הצוותים שואלים היא: איזה מודל נשתמש? YOLO? ResNet? משהו מ-Hugging Face?
השאלה הנכונה היא אחרת לגמרי: מה קורה כשהאינטרנט נופל? מה קורה כשה-PLC מחזיר קוד שגיאה? מה קורה כש-Edge Device נתקע?

מפעל הוא סביבה עוינת. יש בה רטט, אבק, רשתות OT מבודלות, ציוד בן 20 שנה שתקשורת ה-Modbus שלו מוגבלת ל-9600 baud, ומהנדסי אחזקה שאין להם זמן לאבחן תקלות בתוכנה.
המודל הוא רכיב אחד בשרשרת. אם אחת החוליות נשברת - השרשרת נשברת.

Cloud AI מול Edge AI: לא שאלה של ביצועים, אלא שאלה של כשל

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

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

לכן, ברוב הסביבות התעשייתיות שנתקלנו בהן, ה-inference חייב לרוץ locally. לא "כי זה מהיר יותר" - אלא כי זה היחיד שעובד. על הנושא הזה כתבנו בהרחבה במאמר על Edge AI ועל ההבדל בין inference מקומי לענן.

שלושת ה-use cases שמייצרים ROI מדיד

לא כל יישום AI מתאים לרצפת מפעל. אלו שחוזרים שוב ושוב עם תוצאות מדידות:
Quality Inspection (Visual) - זיהוי פגמים, בדיקת הרכבה, בדיקת אריזה. זה ה-use case הבשל ביותר - קיים tooling טוב, ויש מספיק נתוני benchmark אמיתיים כדי לתכנן ציפיות ריאליסטיות. גם הכי קל להוכיח ROI: כמה יחידות פגומות עברו לשוק לפני? כמה אחרי?
Predictive Maintenance - רטט, רעש, טמפרטורה. הרעיון פשוט, אבל המימוש דורש baseline ארוך מספיק. מודל שאומן על שלושה חודשים לא יודע מה "נורמלי" בסתיו מול קיץ. קפיצות שגויות יגרמו לצוות האחזקה להפסיק לסמוך על המערכת - ומשם כבר קשה לחזור.
Safety Monitoring - זיהוי כניסה לאזורים מסוכנים (PPE Detection), התרעות בזמן אמת. כאן ה-latency קריטי - התרעה שמגיעה אחרי 4 שניות היא התרעה שמגיעה מאוחר מדי.

מקרה: Computer Vision בשטח - מה שלא כתוב בתיעוד

בפרויקט שבנינו עבור חברה בתחום בקרת כניסה ואוטומציה - מערכת Computer Vision לזיהוי לוחיות רישוי (LPR) המשולבת עם שערים אוטומטיים וניהול חניונים - נתקלנו ב"בעיה" שלא הייתה בשום spec.

המצלמות הותקנו בחוץ. הדיוק בדמו היה מעל 97%. שבועות אחרי ההתקנה, בבוקר של ינואר, התחילו להגיע דיווחים: המערכת לא מזהה. הסיבה: אור השמש הישיר בזמן עלות השחר פגע ישירות בעדשה בזווית שאף אחד לא דמה. המודל לא היה "שגוי" - הוא לא אומן על הסתייה הזו של אור. הפתרון שילב שכבת pre-processing מסתגלת לתנאי תאורה משתנים, לא שינוי של המודל עצמו.

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

הפרק שרוב המאמרים דוחים: PLC, Modbus ו-OPC-UA

זה המקום שבו נגמרים המאמרים הגנריים ומתחיל הפרויקט האמיתי.

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

Siemens S7-1500 מדבר בצורה שונה לחלוטין מ-Allen Bradley. מנגד, Beckhoff עובד בדרכו. ובו בזמן Schneider Electric שיש בו פרוטוקולים שספק אם תמצא להם תיעוד טוב. OPC-UA הוא הסטנדרט המודרני, אבל ציוד מעל גיל מסוים מדבר רק Modbus RTU על RS-485.

מי שלא עבד עם שכבת OT לא יודע כמה זמן לוקח לבנות data pipeline יציב בין Edge AI לבין ה-PLC שאמור לפעול על פיו. לא שעות - שבועות. יש קשר ישיר בין האתגר הזה לבין מה שאנחנו מתארים במאמר על Legacy System Integration: ממשקים ישנים שלא עוצבו לדבר עם תוכנה חדשה, וצריך לבנות את הגשר בזהירות.

Data Drift: הבעיה שמגיעה אחרי ה-launch, לא לפניו

מודל שעבד בינואר יכול להיכשל ביוני. לא בגלל באג. בגלל שהעולם השתנה.
שינוי תאורה: החלפת נורות פלואורסנט ב-LED שינתה את ספקטרום האור. המצלמה רואה את אותו מוצר אחרת לחלוטין.
חומרי גלם חדשים: ספק החליף את הפלסטיק. הגוון השתנה ב-3%. המודל פתאום לא בטוח.
בלאי מכני: עדשת המצלמה נצברת עם אבק. זה לא "תקלה" - זה תופעה תפעולית רגילה שצריך לנטר.
מצלמה שהוחלפה: אחרי תקלה, הטכנאי החליף מצלמה מאותו דגם. אבל הקליבציה שונה. הפרויקציה שונה. המודל לא יודע.
המסקנה: מערכת AI תעשייתית זקוקה ל-drift monitoring כחלק אינטגרלי מהתכנון, לא כתוספת אחרי. זה אומר לאסוף נתונים ב-production, לשמור samples, ולהגדיר trigger אוטומטי לretraining.

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

לא "דיוק" (accuracy)! דיוק הוא מדד שמשמעותי במעבדה ולא קשור לשום דבר בשטח.

השאלות הנכונות:

False Negative Cost: מה עולה לנו כשמוצר פגום עובר לשוק?

False Positive Cost: מה עולה לנו כשעוצרים את הקו בטעות? (בסביבות מסוימות - עצירה לא מתוכננת של 10 דקות שווה עשרות אלפי שקלים)

Recovery Time: כמה זמן לוקח לזהות שהמערכת הפסיקה לעבוד כראוי?

Mean Time To Detect (MTTD): כמה זמן בין כשל אמיתי לבין התרעה?

Downtime Cost: מה קורה לקו הייצור אם ה-Edge Device מתרסק?

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

ארכיטקטורת Reference לסביבה תעשייתית

כל שכבה עם אחריות ברורה:
Edge AI Gateway:
inference, pre-processing, buffering כשהרשת לא זמינה, watchdog שמפעיל fallback אם המודל לא מגיב. אנחנו בונים את שכבת ה-Gateway הזו על גבי פלטפורמות SBC תעשייתיות - לוחות שנבחרים לפי IP rating, טווח טמפרטורות, וצריכת חשמל, לא רק לפי benchmark מעבד.

Industrial Network:
מבודל מרשת ה-IT. לרום מצוייד ב-Firewall חד-כיווני. לא כי "זה מומלץ" אלא כי זו דרישת רגולציה תעשייתית ודרישת ביטוח בחלק מהסביבות.

MES:
זה המקום שבו ה-AI events הופכים לאיתותים ואירועים עסקיים. WO עצירה, quality record, קריאה לטכנאי ועוד. הפיכת event טכני ל-workflow עסקי היא בדיוק מה שעושה שכבת Middleware - בלי החיבור הזה, האנומליה שזוהתה נשארת בלוג קובץ שאף אחד לא פותח.

Lessons Learned: ארבע הטעויות שחוזרות על עצמן

טעות #1: מתחילים מאימון מודל לפני שיש KPI עסקי.
"נוריד false positive rate ל-5%" - זה לא KPI. KPI הוא: "נוריד בלאי ציוד ב-X שעות בחודש" או "נוריד החזרות לקוח ב-Y%". בלי זה, אי אפשר לדעת אם הפרויקט הצליח.

טעות #2: מניחים שהרשת זמינה.
ראה פרק Cloud vs Edge. זה לא הנחה לגיטימית בסביבת OT.

טעות #3: מתכננים מודל, לא מתכננים תחזוקה.
מי יעדכן אותו? מתי? מי מנטר drift? אם אין תשובה לזה לפני שמתחילים, המערכת תהפוך ל-technical debt תוך שנה.

טעות #4: לא מערבים את אנשי האחזקה בשלב ה-design.
הם אלה שיעבדו עם המערכת ביום-יום. אם הם לא מבינים מה זה false positive ולמה הקו עצר - הם יכבו את המערכת. ואין כאן אשמה.

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

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

אם יותר ממחצית התשובות הן "לא יודעים" - זה לא בעיה, זה scope. אבל כדאי לדעת את זה לפני שמתחילים לאמן מודל.

Physical AI: הגל הבא כבר מגיע לרצפת המפעל

ChatGPT שינה את הציפיות. Physical AI שינה את הפרדיגמה.

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

NVIDIA Isaac, Boston Dynamics Spot, ועשרות פרויקטים פחות מוכרים בתעשייה - כולם מניחים את אותו מסד: AI שחי בסביבה הפיזית, לא מצפה לה.

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

Bit-Gem: מה אנחנו בונים בפועל

ב-Bit-Gem אנחנו בונים מערכות AI תעשייתיות מקצה לקצה - לא רק את המודל.

זה אומר: בחירת חומרת Edge המתאימה לסביבה (תנאי טמפרטורה, IP rating, גורם צורה), כתיבת ה-driver ל-PLC, בניית ה-data pipeline מהמצלמה ועד ל-MES, ואינטגרציה עם ERP כמו Priority או SAP בצד של ה-business logic.

עבדנו עם לקוחות מ-automotive ועד medical, בסביבות שבהן Downtime אינו אופציה ו-data privacy אינו משא ומתן. הניסיון הזה מתבטא בדברים ספציפיים: אנחנו יודעים מתי Edge מספיק ומתי צריך Hybrid. אנחנו יודעים לדבר עם Siemens ועם Modbus ועם Beckhoff. אנחנו יודעים לבנות fallback שעובד גם כשה-AI לא עובד.

הדבר שמבדיל אותנו: אנחנו לא חברת Data Science שלמדה לכתוב embedded. אנחנו חברה שמגיעה מהצד ההפוך - ועל הדרך למדנו את כל שאר השכבות.

יש לכם פרויקט Edge AI תעשייתי? נשמח לבדוק יחד אם הגישה שלכם מחזיקה מעמד מחוץ למעבדה. צרו קשר.