פיתוח מערכת OCR לזיהוי טקסט בתמונות

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

תחומי פיתוח AI

שאלות נפוצות

העבודות האחרונות

  • פיתוח אפליקציית ווב עבור FEEDME
    פיתוח אפליקציית ווב עבור FEEDME
    1359
  • פיתוח חנות מקוונת לחברת FURNORO
    פיתוח חנות מקוונת לחברת FURNORO
    1330
  • עיצוב לוגו לחברת B2B Advance
    עיצוב לוגו לחברת B2B Advance
    776
  • פיתוח אפליקציית ווב עבור Enviok
    פיתוח אפליקציית ווב עבור Enviok
    1077
  • פיתוח לוגו חברת AIDER
    פיתוח לוגו חברת AIDER
    1022
  • פיתוח CRM עבור Chasseurs
    פיתוח CRM עבור Chasseurs
    1113

מדוע OCR נכשל בסריקות, צילומים וקובצי PDF אמיתיים

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

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

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

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

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

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

השפעת ההטמעה: שיעור מילוי אוטומטי, מהירות, סוג הכשלים

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

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

שיעור הפענוח האוטומטי בטפסים אחידים עולה מ־55–65% ל־85–93%. הזנב שנותר אינו "מערכת גרועה", אלא מסמכים שבהם המקור עצמו אינו קריא: סריקה עקומה, כתם, תיקון בכתב יד. אותם אנו שולחים למפעיל לפי סף הביטחון, ולא את כל האצווה כולה.

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

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

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

מצבי עבודה של שירות OCR: אצווה, זרימה, היברידי

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

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

השוואת מצבים

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

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

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

שלבי ההטמעה: מביקורת קורפוס המסמכים ועד לנהלים

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

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

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

תצורות, סכימות זרימה ונהלים: ארטיפקטים של הפרויקט

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

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

מקרה בוחן: מערכת OCR צמצמה קלט ידני פי שישה

לפני: בדיקה ידנית החזיקה את הזרימה

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

שיעור הקלט הידני הגיע ל-62%, אצווה של 500 עמודים יצאה לעבודה בשלוש משמרות, כל מסמך חמישי נחשב שנוי במחלוקת ונותח כולו — למרות שהשגיאה הייתה בשדה אחד מתוך עשרה.

מה שינו ומה התקבל

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

שיעור הקלט הידני — מ-62% ל-10%. אצווה של 500 עמודים — משלוש משמרות ל-50 דקות. מסמכים שנויים במחלוקת — מ-20% ל-4%, ובהם מתקנים שדה אחד, ולא מקלידים מחדש את הטופס.

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

במה OCR של טקסט מודפס שונה מזיהוי כתב יד

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

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

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

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

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

ספקות טכניים: דיוק, מתחם נתונים, נפחים

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

מה יקרה בסריקות גרועות — עיוותים, רעש, הערות בכתב יד?

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

האם אפשר לפרוס את המערכת בתוך המתחם שלנו?

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

האם הפתרון יעמוד בגידול נפחים?

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

מה לעשות אם צורת המסמך השתנתה?

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

נדון במשימה: מה צריך כדי להתחיל בזיהוי

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

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

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