פיתוח מערכת AI לתעשייה מהיסוד

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

תחומי פיתוח AI

שאלות נפוצות

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

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

פיתוח AI לתעשייה: היכן נשבר הפיילוט

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

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

צוואר הבקבוק השני — הפער בין הפיילוט לתפעול. הטמעת AI בתעשייה דורשת שהתוצאה תשתלב במעגל הקיים: ב-АСУ ТП, MES, מערכות שיגור. אם המודל חי כסקריפט נפרד על המחשב הנייד של המהנדס, הוא לא ישרוד את המשמרת הראשונה של שינוי תקנון, החלפת חיישן או עצירה מתוכננת. מכאן התמונה האופיינית: אב-טיפוס קיים, אפקט בבית המלאכה אין.

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

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

מה נותנת מערכת AI בייצור: אפקט ומצבי עבודה

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

מצבי עבודה של מערכת AI

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

אפשרות מתי מתאימה מגבלות
רמזים למפעיל פארק מגוון, המפעיל נשאר החוליה המכריעה האפקט תלוי במשמעת המשמרת
לולאת המלצה קיימת מערכת בקרה אוטומטית (АСУ ТП) ונתונים יציבים מחיישנים דורשת תיאום ערכי סף עם הטכנולוג
שליטה אוטונומית באתר פעולות אחידות, חזרתיות גבוהה נדרשת לולאת בטיחות וחזרה למצב ידני

מה נותנת כל לולאה

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

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

אנחנו מפרקים איך זה נסגר על הפארק שלכם.

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

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

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

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

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

במה שונה פיילוט AI ממערכת AI תעשייתית?

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

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

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

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

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

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

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

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

מקרה בוחן: בקרת איכות מבוססת AI בקו ייצור

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

מה שינו

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

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

מה התקבל

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

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

למה זה עובד באופן יציב

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

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

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

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

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

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

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

לכן לפני ההתחלה אנחנו מתעדים דרך אילו ממשקים המערכת קוראת נתונים (OPC UA, Modbus, Ethernet תעשייתי, ייצוא מ-АСУ ТП), היכן מתבצעים החישובים — על שרתים קיימים, על צומת נפרד ליד הציוד או במתחם סגור ללא יציאה החוצה. אם חסרים חיישנים, זה מתברר בשלב הסקר, ולא בהרצה.

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

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

האם אפשר ליישם בשלבים, בלי לעצור את הייצור?

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

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

למסירה לאחר סיום מועברים:

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

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

לוחות זמנים ליישום מערכת AI לפי שלבים

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

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

שלב מה קורה לוח זמנים משוער
סקר ונתונים ניתוח תהליכים, ביקורת מקורות, הערכת שלמות ואיכות הנתונים ההיסטוריים, בחירת האתר עם האפקט הגדול ביותר 1–2 שבועות
הגדרה ומדדים קובעים מדדי יעד (דיוק, שיעור התראות שווא, זמן תגובה), מתאמים קריטריוני קבלה שבוע
אב טיפוס על נתונים היסטוריים אימון ובדיקה על נתוני עבר, השוואה עם הכלל הנוכחי או עם החלטה ידנית 2–4 שבועות
פיילוט במעגל אמיתי עבודה במצב המלצה: המערכת מחשבת, ההחלטה מתקבלת על ידי אדם, פערים מנותחים 3–6 שבועות
אינטגרציה תעשייתית חיבור ל-АСУ ТП, MES ומערכות חשבונאיות, טיפול בניתוקי תקשורת ובכשלי חיישנים 4–8 שבועות
מסירה ותמיכה נהלי אימון מחדש, ניטור דריפט של המודל, הדרכת משמרות, תיעוד 2–3 שבועות

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

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

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

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