התמודדות עם תהליכי OCR פגומים וזיהוי זבל טקסטואלי

ממשיכים בפוסטים שבהם יש בעיה נפוצה אצל צוות באנטרפרייז שבונה ארכיטקטורה אג'נטית ל-AI כדי לעבד מסמכים של הארגון ואולי גם של לקוחות של הארגון וגם לענות לשאילתות ולצרכים של משתמשים שונים בארגון. הכל נבנה לוקאלית, on premises עם open source וללא גישה לשירותי ענן ול-APIים חיצוניים משום סוג. סדרת הפוסטים עוסקת בבעיות נפוצות באתגרים נפוצים ובפתרונות בית הספר שחוזרים על עצמם שוב ושוב.

הצוות הפעם מספר שבמערכת שלהם קליטת המסמכים והפענוח האופטי נעשים באמצעות תוכנה שרצה מקומית בשם Dockling, עקב איסור של מחלקת אבטחת המידע להשתמש במנועי OCR ענניים כמו זה של וגם מקומיים דוגמת מנועי DeepSeek או Azure Document Intelligence. כתוצאה ממגבלה זו, נשאלת השאלה כיצד ניתן לזהות האם הפלט שיוצא מרכיב ה-OCR של Dockling הוא טקסט איכותי ולגיטימי, או שמדובר בזבל שישנה את איכות החיפוש אם יוטמע במערכת?

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

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

אם פלט משובש זה עובר ישירות לשלב ה-Encoder וה-Embedding מבלי להיבדק, מודל ה-embedding יחשב עבורו ייצוג וקטורי ויאחסן אותו. כאשר משתמש ישאל שאלה שקשורה לאותו מסמך, סביר להניח שהוקטור הרעשני לא יצליח לעלות בחיפוש בעקבות ריחוק סמנטי עצום, או גרוע מכך, הוא יוחזר ל-LLM כהקשר שגוי לחלוטין ויגרום למודל לדמיין תרחישים ולהפיק הזיות בעלות חזות ביטחון גבוה. פתרון שגיאות אלו לא יימצא בשיפור מנגנון ה-Chunking או בהחלפת מודל ההטמעה, שכן התקלה התרחשה בשלב העוּבּרִי של הפייפליין.

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

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

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

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

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

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

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

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

התמודדות עם תהליכי OCR פגומים וזיהוי זבל טקסטואלי

צריכים עזרה עם AI/GenAI/AgenticAI/AI Platform ועם מעבר מהוכחת יכולת לעבודה בסקייל מלא באנטרפרייז? 

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

רוצים מחקר אלגוריתמי יישומי?  

הבה נדבר!

שלמה יונה,

מייסד ומדען ראשי, 

מתמטיקאי מחקר ופיתוח בע"מ

053-7326360

shlomo.yona@mathematic.ai

https://mathematic.ai

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

A technical deep dive about Mathematic.ai