פיתוח מערכות VLM לניתוח תמונות וטקסט

פיתוח VLM: היכן צוואר הבקבוק בניתוח תמונות

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

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

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

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

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

מה נותן פיתוח VLM: אפקט מדיד

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

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

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

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

האפקט הכי מהיר מופיע בבדיקה הידנית. כאשר המערכת שולחת לאדם רק מקרים שנויים במחלוקת — ביטחון נמוך של המודל, סתירה בין שדות, קטע שאינו קריא — שיעור הבדיקה הידנית יורד מכלל הזרימה ל-5–15%. הזמן שהתפנה מופנה לפניות מורכבות במקום להקלדה מחדש של טיפוסיים.

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

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

השוואת מצבי עבודה: ענן, קונטור מקומי, היברידי

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

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

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

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

איך אנחנו מובילים הטמעה: שלבי העבודה ההנדסית

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

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

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

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

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

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

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

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

מקרה בוחן: בקרת פגמים בקו ייצור

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

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

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

שיעור הפגמים שהוחמצו ירד ל-0.5%, ניתוח מקרה שנוי במחלוקת אורך כ-20 שניות במקום 3–4 דקות. בקרת האיכות הפסיקה להיות מדגמית: הכיסוי רציף, ובמקביל למשמרת יש 60–80 פניות למפעיל במקום סקירה ידנית של כל הזרימה.

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

במה אימון נוסף שונה מהנחיה עם דוגמה?

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

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

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

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

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

ספקות טכניים: מפרקים לפי סעיפים

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

האם אפשר לא להוציא נתונים מחוץ לקונטור?

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

אצלנו כבר פרוס קונטור — נצטרך לבנות הכול מחדש?

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

איך להבין שהפתרון מוכן להטמעה?

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

מה קורה אחרי ההרצה?

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

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

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

מה עוזר להגיע במהירות להערכה:

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

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