מסמכים בעברית ל-AI ו-OCR: ציון ביטחון, מקור ונתיב חריגים

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

למה טקסט בעברית נשמר נכון ומוצג הפוך

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

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

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

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

UAX #9 גם מסביר למה הפיסוק נוחת בצד הלא נכון. הטבלה שם מסווגת את האלפבית העברי כטיפוס R, ספרות אירופיות כטיפוס חלש EN, סימני מטבע כ-ET שהוא מסיים מספר אירופי, ונקודה, פסיק, נקודתיים ורווח קשיח כ-CS שהוא מפריד מספרים משותף. לטיפוסים החלשים והניטרליים אין כיוון משלהם, והם יורשים אותו מהשכנים. לכן מחיר בשקלים בתוך משפט עברי הוא בדיוק המקום שבו סימן המטבע או הנקודה העשרונית מוצגים היכן שלא ציפיתם, וסימוני הכיוון האפסיים U+200F ו-U+200E הם כלי לתיקון תצוגה - לעולם לא לתיקון הערך השמור.

מה ציון הביטחון לא מודד במסמך עברי?

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

בעברית הפער בין נקרא נכון לבין נכון גדול במיוחד:

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

טבלת שדות: מה נכשל דווקא בעברית ולאן זה מנותב

הספים נקבעים מול המסמכים שאתם מקבלים; רק השיטה עוברת ממקום למקום.

שורת התאריך היא הזולה לתיקון והיקרה להתעלמות. 6/9/26 תקין בשני פירושים, ולכן אין ציון ביטחון שיסמן אותו. רק כלל עסקי, שלפיו רכיב היום קטן או שווה 12 ולכן הפירוש דו-משמעי, מוציא אותו מהזרימה האוטומטית.

גרשיים, קיצורים ואותיות סופיות: איפה הטוקניזציה נשברת

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

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

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

קשור: עברית ו-RTL בתוכנה עסקית, הזמנות PDF במייל עם תור אישור, בדיקות איכות ל-PDF בעברית.

איך נראה נתיב חריגים שאפשר באמת לאשר בו?

מסך שמציג ערך חשוד בלי המסמך שממנו נלקח מבקש מהאדם לנחש. תגובת Document AI של Google מצמידה לכל פסקה, טוקן ובלוק אובייקט layout ובו confidence, מלבן boundingPoly עם vertices ו-normalizedVertices, ושדה orientation כמו PAGE_UP. ברמת העמוד מוחזר detectedLanguages ובו languageCode ו-confidence, ומעבד ה-OCR הארגוני מחזיר גם imageQualityScores עם qualityScore בטווח 0 עד 1 ורשימת detectedDefects עם ערכים כמו quality/defect_glare או quality/defect_text_cutoff.

מכאן נגזר מסך חריגים שאפשר לעבוד בו:

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

מה נשמר לכל שדה כדי שאפשר יהיה לחזור למקור

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

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

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

מקורות

• Unicode UAX #9 - Unicode Bidirectional Algorithm
• Google Cloud Document AI - handle the processing response
• Amazon Textract - confidence in detection results