ניסיתי שוב ושוב לתקן את המודל. הבעיה הייתה האור.
המספר הראשון שכתבתי על הלוח לבנייה הזו היה 97 אחוז. השני היה 14.
שניהם מתארים את אותו מודל. בדוגמת ההטבעה מהמחקר שלנו, מודל ראייה שאומת בדיוק של 97% במעבדה עולה על מכבש תבניות מתקדם של 200 טון שרץ ב-40 פעימות לדקה ומתחיל לדחות בשגיאה 14% מהחלקים התקינים. שום דבר בתוך המודל לא השתנה. הקלטים השתנו: בוהק מתאורת המפרץ העליונה שזז עם זווית הפעימה, חומר סיכה שמצטבר אחרת על תבניות חמות מאשר על קרות, ו-50 החלקים הראשונים של כל משמרת שמיוצרים לפני שהמכבש מגיע לשיווי משקל תרמי. הפיזיקה של הקו הוציאה את התמונות מחוץ להתפלגות שעליה אומת המודל, ואין מודל, בשום דיוק, שניתן לסמוך עליו שם בחוץ.
ביליתי את החלק האחרון של הפרויקט הזה בבניית דמו שלוקח את המשפט הזה ברצינות. הוא נקרא Inspection Trust Gate, ואפשר לצפות בו מחליט, חלק אחר חלק, ב-veriprajna.com/he/demos/edge-ai-manufacturing-inspection. זה לא מודל פגמים טוב יותר. זה שכבת הריצה בין מודל הראייה לבין מפעיל הדחייה של ה-PLC, והתפקיד היחיד שלו הוא להחליט, עבור כל חלק בודד, האם פסק הדין של המודל בטוח להפעלה.
מה שבא אחרי זה הוא סיפור הבנייה דרך שלושת הרגעים ששינו את הדרך שבה אני חושב על AI לבדיקה: אירוע סחיפה מתוסרט ב-06:00, מספר בנצ'מרק שסירבתי להאמין לו, וכלל שכמעט מחקתי.
התיקון אינו מודל טוב יותר
התנגדתי למשפט הזה יותר זמן משהייתי צריך. כשגלאי מתנהג רע, כל האינסטינקט שלי כבונה אומר לאמן מחדש, לשדרג את עמוד השדרה, לקנות עוד תוויות. המחקר סירב לשתף פעולה. מערכות AOI מהקופסה דוחות בשגיאה 5 עד 15% מהחלקים התקינים, ומכוונות היטב יורדות מתחת ל-2%, מה שעמוד הפתרון שלנו מכנה "בעיית כיול ונתונים, לא בעיית ארכיטקטורת מודל". אותו מחקר מדווח ש-84% מפרויקטי אינטגרציית מערכות נכשלים או נכשלים חלקית, ושבפריסת בדיקה טיפוסית עבודת האינטגרציה היא 60% מלוח הזמנים של הפרויקט בעוד אימון המודל הוא 15%. השורה ששמרתי לקרוא שוב ושוב: "החומרה היא הזמנת רכש."
אז עשיתי משהו שהרגיש מעט כופר: עשיתי את מודל הפגמים של הדמו בלתי מרשים במכוון. זה מרחק kNN למרקם ידוע-כתקין, תחליף PatchCore-lite, והוא משיג AUROC של 0.845 בהפרדה בין חלקים תקינים נקיים לפגומים בסט הבדיקה המוחזק החוצה של MVTec AD metal_nut (תצלומים אמיתיים של חלקים מיוצרים אמיתיים, תוויות ציבוריות). אני לא מסתיר את המספר הזה ואני לא מוכר אותו. בייצור החריץ הזה מחזיק את צינור NVIDIA Metropolis שלכם, את מערכת Cognex שלכם, את המודל המותאם שלכם, מאחורי ממשק קבוע. המוצר הוא השכבה סביב המנוע, לא המנוע.
השכבה מתחילה בשאלה שאף מדד דיוק לא עונה עליה: האם התמונה הזו נמצאת בתוך תנאי הלכידה שעליהם אומת המודל? ה-EnvelopeDetector של הדמו מחשב מרחק מהלנוביס במרחב אותות פיזיקליים (חשיפה, ניגודיות, טווח דינמי, פרוקסי לפוקוס, פרט בתדר גבוה, גוון צבע תרמי, רוויה, שבר בוהק), מותאם על 220 תמונות האימון הידועות-כתקינות ולא על שום דבר אחר. כשחלק נוחת מחוץ למעטפת מאומתת, השער מפסיק לסמוך לחלוטין על פלט המודל, לא משנה כמה המודל בטוח בו.
גם מודל מושלם תקף רק על קלטים בתוך המעטפת המאומתת שלו.
זה המשפט שעליו תלויה כל הבנייה. סחיפה היא כשל קלט, לא כשל מודל, וכשל קלט אף פעם לא מופיע בלוח הדיוק שלכם. הוא מופיע בפח הגרוטאות שלכם.
מה קורה ב-06:00?
הרגע שאני סומך עליו ביותר בכל הדמו הוא חותמת זמן. האפליקציה משחזרת משמרת מתוסרטת דטרמיניסטית בתחנה "Line 3 - metal_nut press," ומשדרת תצלומי MVTec AD metal_nut אמיתיים דרך הצינור המלא. באמצע, סמן חוצה את המסך: "SHIFT CHANGE 06:00 - cold dies, bay lights on." אחר כך מגיעים 12 חלקים תקינים מושחתים בבוהק, חוסר פוקוס וגוון תרמי. אני רוצה להיות מדויק לגבי מה זה: התצלומים אמיתיים, הסחיפה היא השחתת תמונה כנה שהוחלה עליהם, והאפליקציה מסמנת אותה ככזו. לא הייתה לי קו הטבעה לצלם, ולהעמיד פנים אחרת היה מרעיל את כל הנקודה.
מה שקורה אחר כך הוא הסיבה שהדמו קיים. מוניטור המעטפת הופך לאדום. השער קורא כל חלק עם סחיפה כמחוץ למעטפת המאומתת ומסרב לתת לפסק הדין של המודל לגעת במפעיל. פסק דין אחר פסק דין חוזר HOLD, מועבר לתור ההסלמה לבן אדם, בעוד הפאנל לידו מראה מה AOI תמים ללא בדיקת מעטפת היה עושה עם אותה תמונה: REJECT.
בפעם הראשונה שראיתי את התור מתמלא, לחצתי לתוך חלק מוחזק וציפיתי לראות תירוץ מעורפל של "זוהתה חריגה". במקום זאת מוניטור המעטפת פירק את אות ההפרה אות אחר אות, כי בניתי אותו ממדידות פיזיקליות ולא מהטמעות, ומדידות פיזיקליות יכולות להסביר את עצמן. בחלק אחד עם סחיפה, הבהירות יושבת 7.6 סיגמה מההתאמה המאומתת ונושאת 87.1% ממרחק המהלנוביס בריבוע. זה לא מודל שיש לו תחושה. זו קריאת מכשיר.
בסוף שלב הסחיפה לוח התוצאות חד. קו הבסיס התמים גרס אוטומטית 12 חלקים תקינים. ה-Trust Gate גרס אוטומטית אפס, והחזיק את כולם לסקירה. אותן תמונות, אותו מודל פגמים תחליפי, אותם ספים על ציון הפגם. ההבדל היחיד הוא שנתיב אחד בדק את הקלט לפני שסמך על הפלט.
קו הבסיס התמים והשער ראו את אותם חלקים ואת אותו מודל. ההבדל היחיד היה הרשאה להפעיל.
לגבי נתון הדולרים הזה, כי כאן דמואים בדרך כלל מתחילים לשקר: הפאנל משליך את שיעור הדחייה השגויה הנמדד של התמים למשמרת מלאה (40 פעימות לדקה במשך 8 שעות הן 19,200 חלקים) ב-$2.42 לכל חלק שנגרוס. ה-$2.42 הוא סדר גודל ממקור, מעוגן בתיק מפורסם של יצרן עוגיות שבו הפחתת פסולת גרוטאות של 8.7% חסכה $94K בשנה ו-38,800 ק"ג של מוצר. זה לא מספר של לקוח, והמונה מסומן כתחזית בכל מקום שבו הוא מופיע. מדדתי את הדחיות השגויות; הקרנתי את הדולרים; ה-UI אומר איזה מהם מה.
עוד דבר אחד שבדקתי לפני שהאמנתי לסיפור הסחיפה של עצמי: חלקים פגומים שהוזרקו במהלך שלב הסחיפה עדיין נתפסים או מועברים להסלמה, אף פעם לא עוברים אוטומטית. בכל הסט המוחזק החוצה הנתון הוא 93 מתוך 93. להחזיק חלקים תקינים חסר ערך אם חלקים פגומים מחליקים בתוך הכאוס.
האם בדיקת המעטפת שלי בדקה את שיעורי הבית של עצמה?
מספר הבנצ'מרק שחשדתי בו ביותר היה הטוב ביותר שלי. כשהרצתי לראשונה את סקריפט הספסל, גלאי המעטפת הפריד תמונות עם סחיפה מתמונות נקיות בעצם בצורה מושלמת. התגובה המיידית שלי לא הייתה גאווה. היא הייתה חשד, כי בניתי את שני צדי המבחן: כתבתי את השחתות הבוהק, חוסר הפוקוס והגוון התרמי, ובחרתי את האותות הפיזיקליים שהגלאי צופה בהם. כמובן שגלאי בוהק תופס בוהק. מבקר עם שיניים היה קורא לזה מעגלי, והוא היה צודק.
אז החרגתי משפחת סחיפה אחת לגמרי החוצה. הגלאי מעולם לא כוון נגד תת-חשיפה, מעולם לא ראה אותה במהלך הפיתוח. אחר כך הרצתי מחדש את bench.py (לאחרונה ב-2026-07-17) על סט הבדיקה המוחזק החוצה של MVTec AD metal_nut: 22 חלקים תקינים, 93 פגומים, התאמת אימון על 220 התמונות התקינות בלבד. על משפחת תת-החשיפה המוחזקת החוצה, גלאי המעטפת קיבל AUROC 1.000. זה המספר שנושא את התזה, בדיוק כי הוא הושג על מצב כשל שמעולם לא הנדסתי עבורו. הסקריפט מדפיס "THESIS HOLDS" רק אם המספרים הנמדדים באמת תומכים בטענה; כתבתי אותו כך כדי שהשיווק לא יוכל להיסחף מהמדידה.
שאר הבנצ'מרק ראוי להיקף המדויק שלו, אז הנה הוא בלי עיגול לטובתי. על חלקים תקינים עם סחיפה, קו הבסיס התמים ללא מעטפת דוחה בשגיאה 95.5 עד 100% לכל משפחת סחיפה (בוהק 100%, חוסר פוקוס 100%, גוון תרמי 100%, תת-חשיפה 95.5%, ממוצע 98.9%). ה-Trust Gate דוחה בשגיאה 0.0% מהם, ומחזיק כל אחד לסקירה. והסייג הכנה: ההשחתות הן בעוצמה מלאה, כך שהתמוטטות הבסיס היא כמעט מוחלטת מעצם הבנייה. הטענה שאגן עליה היא הכיוון, שמודל מאומת בנקיון מתמוטט ברגע שהקלטים עוזבים את המעטפת שלו, לא האחוז הספציפי. אלה מדידות על בנצ'מרק מחקרי תחת סחיפה סינתטית. אלה לא ערבויות עולם פתוח, וכל מי שמצטט אותן כביצועי ייצור משתמש בהן לרעה, כולל אני.
הכלל שכמעט מחקתי
קריאת הכנות הקשה ביותר שעשיתי בבנייה הזו הייתה לגבי כלל שבקושי עובד. בתחילה הוספתי כלל אזור גאומטרי: למקם את החריגה על רשת גסה 8 על 8, ולטפל בפגם בתוך האזור הפונקציונלי אחרת מכתם בקצה הקוסמטי. זה נשמע כמו מטרולוגיה אמיתית. אחר כך מדדתי, והמדידות היו משפילות. פרוקסי החספוס המקומי ממקם חריגה ב-33 מתוך 93 פגמים מוחזקים חוצה, כ-35%. הוא משנה את תוצאת השער בדיוק ב-1 מתוך 93. ו-0 מתוך 18 הדחיות האוטומטיות מגובות בחריגה ממוקמת אמיתית; כששום דבר לא ממוקם, הצנטרואיד נופל חזרה למרכז הרשת, שנקרא כאזור כברירת מחדל.
ישבתי עם שלוש אפשרויות. למחוק את הכלל ולהעמיד פנים שמעולם לא ניסיתי. לשמור אותו ולתת ל-UI לרמוז על מטרולוגיה מדויקת שאין לי. או לשמור אותו ולגרום לממשק להתוודות. בחרתי בווידוי. כשהפגם הגיבור של הדמו נדחה אוטומטית (חלק test-flip-264, פגם מבני גס אמיתי ממחלקת flip של MVTec), קידוח הגיאומטריה קובע במפורש ששום דבר לא ממוקם בחלק הזה והדחייה נשענת על ביטחון מרקם בלבד.
הכלל כן מצדיק את עצמו בדיוק פעם אחת, וגרמתי לאפליקציה להוכיח זאת במקום לביים. בהפעלה, הדמו מחפש בכל 93 הפגמים המוחזקים חוצה חלק עם חריגה ממוקמת באמת מחוץ לאזור הפונקציונלי בחלק שבטוח אחרת. בסט שנשלח החיפוש מוצא את test-flip-251, מרכז בשורה 2, עמודה 6, והשער מנתב אותו ל-HOLD במקום להפעיל את המפעיל. אם הנתונים היו משתנים ושום חלק לא היה כשיר, הפעימה הזו פשוט לא הייתה מופיעה. אפילו בדקתי A/B את סף הסיגמה של הכלל עם אימות צולב בן 5 קיפולים; הערך המותאם לא הראה שיפור על 2.5 שנקבע ידנית, אז שמרתי על 2.5 ותיעדתי את התוצאה השלילית בריפו עם "shipped": false. במעורבות ייצור הכלל הזה מוחלף במטרולוגיה מדויקת לפיקסל, מעוגנת ב-CAD. בדמו זה תחליף כנה, וה-UI אומר זאת על כל חלק.
שכבת אמון שמוכרת את עצמה יותר מדי היא סתירה במונחים.
השורה הזו הפכה לכלל עיצוב. אם כל ההבטחה של המוצר היא לדעת מתי לא לסמוך על מודל, הוא לא יכול בו-זמנית לבלף לגבי הרכיב החלש ביותר שלו.
סוכנים מייעצים, קוד מחליט
ההחלטה שאני מסרב להאציל היא זו שמזיזה מתכת. השער עצמו הוא קוד דטרמיניסטי פשוט, מחוץ לכל LLM ומחוץ גם למודל הראייה. הספים שלו מותאמים מנתוני הדמו עצמו, לא מנופנפים ביד: מעבר אוטומטי מתחת ל-0.948 ודחייה אוטומטית מעל 1.30 בסולם הביטחון המכויל, עם כל מה שביניהם, וכל מה שמחוץ למעטפת, הולך ל-HOLD. הוא רץ מול תקציב חלון פעימה קשיח של 750 ms, ובלוג הביקורת שנשלח ההחלטות נוחתות בעשרות מילישניות: test-good-288 עבר אוטומטית ב-37.7 ms, test-good-289 ב-24.4 ms, ולוג מפעיל הדחייה עבור test-flip-264 קורא "REJECT actuated in 25ms (budget 750ms)."
אני צריך להיות ברור לגבי מה מפעיל: כלום, עדיין. נתיב ה-EtherNet/IP למפעיל דחייה Allen-Bradley ControlLogix הוא סימולטור שרושם בדיוק מה שהיה עושה, וכיור ה-MES הוא stub שכותב את שורת העקיבות שהיה כותב. שניהם מסומנים כ-stubs באפליקציה. הם מעוצבים כמו המתאמים האמיתיים כי מציאות ה-OT (מפעלים מעורבים של Siemens ו-Allen-Bradley, חלון דחייה שנמדד במילישניות) היא משטח המוצר האמיתי, אבל דמו שרמז על קו חי היה נכשל במבחן האמון של עצמו.
יש סוכנים במערכת, והגבלתי אותם במכוון. כשחלקים מצטברים בתור ההסלמה, זוג Drift Triage יוצא לעבודה: סוכן אבחון קורא את סטיות האות הפיזיקלי המדורגות על פני החלקים המוחזקים ומציע השערת שורש-סיבה עם פעולה מומלצת, וסוכן מבקר בודק אז את ההשערה מול הראיות המספריות, ומוריד אותה ל-"חקירה ידנית" אם האות המצוטט אינו באמת הסטייה הדומיננטית. הם בנויים על Pydantic AI וניתנים להחלפת ספק, ובלי מפתח API מוגדר הכל יורד לטריאז' תבניתי דטרמיניסטי, כך שהדמו רץ במלואו אופליין. מה שהסוכנים לא יכולים לעשות, מעצם הבנייה, הוא לגעת במפעיל. עד שהם מדברים, השער כבר החליט.
סוכנים מייעצים, קוד מחליט.
כל אחת מההחלטות האלה משאירה קבלה. כל חלק כותב רשומת שושלת JSONL: מזהה חלק, תחנה, מזהה מודל metalnut-defect-knn גרסה v7, hash מערך נתונים ae95b5b533c8, ביטחון פגם, ציון OOD, האותות הפיזיקליים, אילו כללי שער הופעלו, השהיה מול תקציב 750 ms, שורות לוג ההפעלה וה-MES, מה שקו הבסיס התמים היה עושה, ותג הסיכון high-risk:quality-gate (EU AI Act Annex III, בתוקף 2026-08-02). לחיצה אחת מייצאת את המשמרת כ-inspection_audit.jsonl.
השעון הרגולטורי חשוב כאן. חובות הסיכון הגבוה של ה-EU AI Act הופכות לישימות במלואן ב-2 באוגוסט 2026, החלטות איכות קריטיות לבטיחות יושבות ב-Annex III, והקנסות המרביים מגיעים ל-€35M או 7% מהמחזור העולמי עבור הפרות הפרקטיקה האסורה החמורות ביותר. אני רוצה להיות זהיר עם המילים שלי, כי בדיוק כאן מילים זהירות חשובות: הדמו אינו מוסמך EU AI Act, ושום דמו לא יכול להיות. מה שהוא מראה הוא שושלת מוכנה ל-EU AI Act, רשומה לכל החלטה שתוכננה להיות ראיה שניתן להגיש בתיק התאמה בסיכון גבוה, שנוצרת במהירות קו במקום לשחזר אחרי תקלה.
מה שורד את שדרוג המודל הבא?
השאלה ששמרתי לשאול את עצמי בזמן הבנייה הייתה אכזרית ליוצר דמו: אם מודל הפגמים הבא של הלקוח טוב דרמטית מהתחליף שלי, האם משהו מזה עדיין חשוב? עכשיו אני חושב שזה בדיוק הפוך. Deloitte חוזה שאימוץ agentic AI בייצור יעלה מ-6% ל-24% ב-2026 (Deloitte), מה שאומר יותר מודלים ויותר אוטונומיה שמגיעים ליותר מפעילים. לכל אחד מהמודלים האלה תהיה מעטפת מאומתת, והפיזיקה של קו מכבש (בוהק, תבניות קרות, שיווי משקל תרמי) תמשיך להוציא קלטים ממנה. מודל מושלם לא משנה דבר בזה, כי הכשל שהשער מונע הוא כשל קלט, וחובת הביקורת שהוא משרת היא משפטית, לא מודלית. שערי סחיפה, מקוריות ופעולה נשלטת מחזיקים ב-כל דיוק מודל. זו התכונה ששכנעה אותי שהשכבה הזו, ולא מודל נוסף, היא הדבר ששווה לבנות; המשמרת המתוסרטת ב-veriprajna.com/he/demos/edge-ai-manufacturing-inspection היא הניסיון שלי לתת לכם לצפות בה מרוויחה את הטענה הזו חלק אחר חלק.
ואם תעדיפו לראות מאשר לקרוא אותי מתאר, הנה חיתוך המייסד, מקצה לקצה.
אז השאלה שהייתי שואל על כל מודל בדיקה בקו שלכם, כולל אחד של 97%, אינה "כמה מדויק הוא?" היא: עבור החלק שזה עתה חצה את המצלמה, האם אתם יודעים אם התמונה הזו הייתה בתוך המעטפת שעליה אומת המודל? אם אינכם יכולים לענות לכל חלק, במילישניות, עם רשומה שתוכלו למסור למבקר, אז אני לא חושב שיש לכם בעיית דיוק. אני חושב שיש לכם בעיית מעטפת, ואשמח באמת לדעת איזו מהן יש לקו שלכם.
