איך לבדוק OCR למסמכים בעברית ובאנגלית לפני חיבור למערכת ליבה

קטגוריה: OCR ואוטומציה | תאריך: ספטמבר 2026

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

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

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

להתחיל מהחלטה עסקית, לא ממנוע ה-OCR

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

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

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

רשמו עבור כל שדה:

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

הטבלה הזאת מחברת בין בדיקת OCR לבין התהליך האמיתי. היא גם עוזרת להחליט אילו שדות חייבים להיכלל ב-POC ואילו יכולים להמתין.

לבנות מדגם שמייצג את העבודה האמיתית

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

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

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

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

להגדיר אמת מידה מאושרת לכל מסמך

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

כדאי לשמור לצד כל ערך גם הקשר:

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

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

לבדוק ארבע שכבות שונות של איכות

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

1. איכות המסמך הנכנס

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

2. זיהוי טקסט וכיווניות

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

3. חילוץ שדות ומבנה

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

4. נירמול וכללים עסקיים

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

הפרדה זו מונעת מצב שבו משפרים את מודל ה-OCR בזמן שהבעיה האמיתית היא כלל מיפוי, או להפך.

למדוד לפי שדה ולפי מסמך, לא רק לפי תו

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

מומלץ לתעד לפחות:

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

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

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

Confidence הוא אות, לא החלטה עסקית

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

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

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

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

לתכנן את מסלול החריג לפני החיבור

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

מסלול חריג שימושי צריך לענות על השאלות הבאות:

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

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

מדריך על אישור אנושי בתוך תהליך AI או אוטומציה מסביר כיצד לשמור החלטה אנושית בנקודה שבה היא באמת מצמצמת סיכון.

לאמת מול מערכת הליבה בלי לכתוב אליה מיד

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

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

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

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

לבנות תרחישי קבלה מקצה לקצה

בדיקת OCR צריכה להסתיים בתוצאה תפעולית, לא רק בקובץ JSON. עבור ה-POC הגדירו תרחישים כגון:

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

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

לשמור פרטיות ובקרה במדגם הבדיקה

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

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

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

מתי ה-POC מוכן לשלב הבא

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

ה-POC בשל יותר כאשר:

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

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

שאלות נפוצות

האם צריך לבדוק בנפרד מסמכים בעברית ובאנגלית?

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

כמה מסמכים צריך ל-POC?

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

האם ציון confidence גבוה מספיק לעדכון אוטומטי?

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

מה עושים עם תבנית חדשה שלא הופיעה ב-POC?

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

האם אפשר להתחיל בלי חיבור ל-SAP או למערכת הליבה?

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

להתחיל מסוג מסמך אחד ושדות קריטיים בלבד

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

Adaptico עוסקת ב[אוטומציה של מסמכים ובאינטגרציות למערכות ארגוניות](/#services). אם אתם רוצים לבדוק OCR על מסמכים אמיתיים לפני חיבור ל-SAP או למערכת פנימית, אפשר [לקבוע שיחת התאמה](/#contact) ולהגדיר POC קטן עם מדגם, קריטריוני קבלה וגבולות עדכון ברורים.