מדוע זיהוי טבלאות נשבר בסריקות וב-PDF
כשל בזיהוי טבלאות מתחיל לעיתים רחוקות בשגיאה בזיהוי תווים — המשימה מוחלפת בשלב מוקדם יותר. המודל מחזיר שורות טקסט, בעוד שטבלה היא מבנה שבו הערך נקרא רק יחד עם קואורדינטה וכותרת עמודה. ברגע שמחלצים טקסט בלי גאומטריה, פריסת טבלאות מורכבת מתפרקת עוד לפני שלב הבדיקה.
תאים מאוחדים הם נקודת הכשל הראשונה: משמעות הערך מפוזרת על פני שניים-שלושה רבדים של הכותרת, בעוד שהערך עצמו נמצא בתא אחד. בפירוק שטוח הקשר אובד, והשורה נופלת לעמודה הלא נכונה.
כותרות מרובות שורות ותאי הפרדה ריקים שמשמעותם "אותו דבר כמו למעלה" משלימים את התמונה — בלי שחזור היררכיית הכותרת הנתונים נראים סבירים, אך אינם נכונים.
סריקות ו-PDF מוסיפים קבוצת סיבות שנייה. PDF עם שכבת טקסט מספק קואורדינטות, אבל לעיתים קרובות זה מסמך שהורכב מחדש לאחר הדפסה, עם קווי רשת שאבדו; קובץ סרוק הוא רק תמונה, שבה סיבוב של כמה מעלות, פרספקטיבה ורעש מזיזים את הגבולות ביחס למקור. בלי יישור לפי קווים וחיפוש יציב של גרפים התא "זז", הערכים נדבקים או עוברים לעמודה הסמוכה.
סיבה נפרדת היא שבירות עמודים. טבלה שנקרעה לשני עמודים מגיעה בחצי השני בלי כותרת, והכותרת החוזרת נכנסת לנתונים כשורה רגילה. איכות חילוץ הנתונים אינה מגיעה לסף שמאפשר למסור את הייצוא למערכת החשבונאית, והמפעיל מתחיל להעביר ערכים ידנית. נפרק כיצד כל אחד מהכשלים האלה נסגר.
אפקט מדיד: דיוק, מהירות, נפח עיבוד
את האפקט של אוטומציה של הזנת נתונים מודדים בשלוש נקודות, ולא "באופן כללי בפרויקט". הראשונה — שיעור המסמכים שנכנסים למערכת החשבונאית בלי תיקון מפעיל: בהתחלה זה בדרך כלל 60–70%, כי נטיית סריקות, תאים מאוחדים וכותרות מרובות שורות שוברים את הפירוק.
השנייה — זמן לחבילה של אלף עמודים: שתיים-שלוש משמרות של הזנה ידנית לעומת דקות של פירוק ממוחשב. השלישית — שיעור השורות שהמודל מסמן כמפוקפקות ומוסר לבדיקה.
דיוק החילוץ גדל באופן לא אחיד, וזה נראה מראש. עמודות מספריות המיושרות לימין נקראות כמעט בלי שגיאות, ואילו כותרות מורכבות של שתיים-שלוש שורות ומפרידים ריקים בתוך הטבלה דורשים כלל נפרד.
לכן בדוח הדיוק מפורק לפי סוגי טבלאות ושדות: ברור היכן המילוי האוטומטי נדלק מיד, והיכן נדרש בקרת סכום או התאמה למאגר ייחוס.
נעלם מעמד שלם של שגיאות הזנה ידנית: הזזת ספרה, החלפת עמודות בעת העברה, שורה שהוחמצה במעבר בין עמודים, פריט כפול. פירוק ממוחשב מיישם כלל אחד על כל החבילה, והתאמת סכום ערכי השורות לשורת הסיכום חוסמת עיוותים לפני רישום בחשבונאות.
אם הבקרה אינה מתאמתת, את המסמך לא "משלימים בעין", אלא שולחים לתור חריגים עם סימון האזור הבעייתי.
הקלה על המפעילים נובעת מהפחתת פעולות ידניות, ולא מהאצת ההקלדה. אנשים מפסיקים להעביר ספרות ועוסקים בחריגים — ככלל, אלה 5–15% מהעמודים: סריקות מקומטות, תיקונים בכתב יד, טבלאות ללא כותרת.
את הסטאק בוחרים לפי סוג המסמך: טפסים מודפסים מפורקים בידי מנוע קוד פתוח (Tesseract) עם פוסט-עיבוד של המבנה, וטפסים בכתב יד — בידי מודל מולטימודלי, ולכן מהירות עיבוד המסמכים עולה בלי גידול פרופורציונלי בצוות.
אפשרויות עיבוד מסמכים: תבניות, כללים, למידה
מצב העיבוד נבחר לא לפי "מורכבות" המסמך, אלא לפי יציבות הצורה שלו. חילוץ תבניתי נשען על קואורדינטות של בלוקים בעמוד, כללי פירוק — על מבנה הטקסט, ולמידה מדוגמאות — על סטטיסטיקה של אוסף דוגמאות. טעות בבחירה מתבטאת באופן זהה: שיעור הטבלאות הדורשות תיקון ידני עולה יחד עם נפח הזרימה.
| אפשרות | מתי מתאימה | מגבלות |
|---|---|---|
| חילוץ תבניתי | הטופס קבוע: בלוקים ועמודות אינם זזים ממשלוח למשלוח | נשבר בעת החלפת גרסת טופס; לכל סוג חדש נדרשת הגדרה נפרדת |
| כללי פירוק | המבנה צפוי: כותרות יציבות, מפרידים, שורות חוזרות | רגישות לשגיאות הקלדה ולמסמכים "דומים אך שונים"; הכללים מתרחבים |
| למידה מדוגמאות | סריקות מגוונות, כמה ספקים, פריסה משתנה | נדרשת מדגם מתויג; האיכות תלויה בכיסוי טפסים נדירים |
זרימת מסמכים מעורבת נסגרת בסכמה היברידית: המסמך מזוהה תחילה לפי סוג הטופס, ואז עובר למצב המתאים לו — תבנית, כללים או מודל. תאים מתחת לסף ודאות לא נכנסים לייצוא, אלא מגיעים לתור אימות ידני, והמפעיל רואה קטע מודגש מהתמונה המקורית, ולא שדה ריק.
את בחירת המצב אנחנו בודקים על נתוני עבר של הלקוח: מריצים קורפוס מסמכים וסופרים את שיעור הטבלאות שפורקו ללא תיקון, וכן את נפח הכללים שיהיה צורך לתחזק בהחלפת הטופס הבאה. אם הכללים גדלים מהר יותר מהדיוק, מחליפים מצב — המדידה הזו נעשית לפני הפעלה תעשייתית, ולא אחריה.
שלבים: פירוק מסמכים, הגדרה, בדיקה, מסירה
מסמכים מגיעים לעיתים רחוקות כקבוצה אחידה: סריקות עם נטייה, דפים מחוברים, כותרות שחוזרות לאורך העמוד, הערות בכתב יד מעל טקסט מודפס. על סט כזה המזהה טועה באופן לא אחיד — בסוג טופס אחד עובר נקי, ובאחר מבלבל גבולות עמודות. לכן שלבי ההטמעה נבנים עם נקודת בקרה בכל שלב: רואים מה כבר מקובע ומה לא.
- ביקורת דוגמאות — אוספים מסמכים אמיתיים, כולל לא נוחים: סריקות גרועות, טבלאות מרובות עמודים, תבניות מספקים שונים.
- פירוק מסמכים לפי מחלקות — לכל סוג סכמת שדות משלו וכללים לתאים מאוחדים ולכותרות חוזרות.
- מדגם ייחוס — 100–200 עמודים מתויגים ידנית ומחולקים לחלק אימון ולחלק שנשמר לבדיקה; האיכות נמדדת לפי תאים, לא לפי עמוד.
- הרכבת חילוץ — זיהוי אזורי טבלאות, זיהוי מבנה, הבאת ערכים לפורמט אחיד.
- בדיקת איכות — הרצה על החלק שנשמר לבדיקה, דוח עם שיעור התאים הנכונים ופירוט שגיאות אופייניות לכל מחלקת מסמכים.
- כיוונון לפי התוצאות — מדייקים כללים ופוסט-עיבוד, ואז מריצים שוב על אותו מדד ייחוס כדי שההשוואה תהיה הוגנת.
- מסירה לתפעול — סכמת הפעלה, טיפול בחריגים, תור בדיקה ידנית לעמודים שנויים במחלוקת, תיעוד והדרכת הצוות שלכם.
מה נשאר אצלכם: קונפיגורציות, סכמות, נהלים
הערכה נמסרת לא "עם סיום המסירה", אלא ככלי עבודה לתמיכה: לפיו הצוות שלכם סוגר מצבי שגרה בעצמו, בלי לפנות אלינו. להלן מה בדיוק עובר לידיכם יחד עם זיהוי טבלאות עובד.
- סכמות אינטגרציה — מאין מגיעים המסמכים (דואר, תיקיית רשת, מערכת חשבונאית), לאן הולכת התוצאה, היכן נקודות הכשל וכיצד לעבור למסלול גיבוי בלי לאבד קבצים.
- כללי גישה — תפקידים והרשאות: מי רואה את הסריקות המקוריות, מי משנה ספי ודאות ומילון שדות, היכן מנוהל יומן פעולות.
- מילון שדות וכללי תיוג — כיצד עמודות מותאמות לשדות המערכת החשבונאית, מה לעשות עם תאים מאוחדים, כותרות מרובות שורות וסריקות מסובבות.
- נוהל תחזוקה — תדירות בדיקות האיכות, סדר עדכון הקונפיגורציה, העלאת שינויים וחזרה לסט ההגדרות הקודם.
- טיפול במקרים שנויים במחלוקת — הוראה למפעיל: כיצד נראה תור הבדיקה הידנית, למה להסתכל קודם, כיצד לסמן שגיאה כדי שתיכנס לאימון נוסף.
- תיעוד הפתרון — תיאור הקונפיגורציה, מדדי איכות לכל סוג טופס, רשימת מגבלות ידועות ודרכי עקיפה.
- סטי ייחוס ובדיקות — דוגמאות מסמכים ותסריטי הרצה, שמראים לאחר כל שינוי אם הדיוק לא נפגע בטבלאות מורכבות.
סט כזה מאפשר להעביר את התחזוקה לצוות פנימי ולחזור אלינו רק לפיתוח: סוגי מסמכים חדשים, שינוי סכמת הייצוא או העלאת דיוק.
תרגול: זרימת חשבוניות ומסמכי אישור לפני ואחרי השינויים
חברת סיטונאות מקבלת כ-8,000 חשבוניות ומסמכי אישור בחודש מ-400 ספקים. חלק מגיעים כ-PDF אלקטרוניים עם שכבת טקסט, חלק כסריקות ותצלומים באיכות משתנה: טביעות חיוורות, דף מסובב, טבלה על פני שני עמודים. יש להזין את הפריטים שורה-שורה למערך החשבונאי 1C — הפיננסים והמחסן משווים שורות, לא את סיכום המסמך.
לפני: הזנה ידנית בשתי משמרות
שני מפעילים פירקו את הזרימה ידנית: פתחו קובץ, הקלידו שורות, השוו סיכום. חבילת החודש נסגרה בשלושה ימי עבודה, שיעור השגיאות בעמודות מספריות הגיע ל-4–6%, והן נמצאו כבר בבדיקה, תוך פתיחה מחדש של מסמכים.
אחרי: פירוק אוטומטי ובקרת איכות
כעת הזרימה מתחלקת לפי סוג המקור: קבצי טקסט מפורקים ישירות, סריקות עוברות זיהוי טבלאות עם שחזור תאים, כותרות ושורות סיכום. כל פריט מנורמל — קוד, יחידה, תעריף, סכום — ונבדק בסכומי ביקורת: סכום השורות מותאם לסיכום הטבלה, ופער מעל הסף עובר למפעיל. 84% מהשורות נכנסות לחשבונאות ללא תיקונים, ומסמכים עם תיקונים — כ-12%.
התאמות במהלך הדרך
אחרי השבועות הראשונים הוספו תבניות למסמכי אישור לא טיפוסיים, פירוק טבלאות מרובות עמודים עם העברת כותרת, וטיפול בסריקות מסובבות. כל תיקון נבדק על מדגם ייחוס כדי לא לאבד את הדיוק שהושג.
סיכום: חבילת החודש מעובדת ביום אחד בכוח של מפעיל ובודק, ולא בשלושה ימים בשני מומחים. פערי סכומים נחסמים לפני החשבונאות, ולא צפים בבדיקה.
במה שונה זיהוי טבלאות מזיהוי טקסט רגיל
זיהוי טקסט רגיל הוא משימה חד-ממדית: לשמור על סדר התווים בשורה. מספיק לפצל נכון את העמוד לתווים ולמילים, והאיכות נמדדת לפי שיעור התווים שזוהו נכון. טבלה היא דו-ממדית: הערך נקבע לפי מפגש של שורה ועמודה, ואם הרשת אבדה, הקטע "סה״כ" מפסיק להיות מספר עם משמעות ברורה.
מה שמפריע אינו הגופן, אלא הגאומטריה. תאים מאוחדים, כותרות רב-שכבתיות, תא ריק כסימן משמעותי, טבלאות ללא קווים — את כל אלה יש לפרק למודל "שורה — עמודה — ערך".
החיבור עובד כך: תחילה מזהים קווים וגבולות של בלוקים (אלגוריתמי בסיס לפירוק כזה קיימים בספריות קוד פתוח כמו Camelot), אחר כך בונים רשת עם כתובות, ורק לאחר מכן מזהים את תוכן כל תא בנפרד — כבר תוך התחשבות בכך שעמודת מספרים ועמודת תאריכים דורשות כללים שונים.
העיקר הוא הקשרים בין התאים. כותרת הטבלה קשורה לכל ערכי העמודה, וכותרת רב-שכבתית יוצרת מפתח מורכב שיש לאחד לשם שדה אחד. אם הקשרים לא שוחזרו, הטקסט זוהה באופן מושלם, אבל סיכומים וחתכים בדוח מחושבים לא נכון, והשורות בטעינה למערכת החשבונאית נופלות למקומות הלא נכונים.
מכאן דרישות שונות לבדיקה. דיוק ברמת התווים מפסיק להיות קריטריון קבלה: הוא יכול להיות גבוה כשהעמודות כבר זזו. בודקים מבחינה מבנית — התאמת מספר השורות והעמודות, התאמת סכומים לפי שורות ולפי עמודות, שלמות מפתחות, היעדר כפילויות, יציבות התוצאה בהרצה חוזרת על מדגם בקרה של מסמכים.
לכן הקבלה נבנית לא על "טקסט מהתמונה", אלא על התאמת הייצוא לשימוש: סט רשומות עם מפתחות תקינים וקשרים מאומתים, שאפשר לטעון ללא תיקון ידני. כמה שורות זזו וכמה רשומות לא עברו ולידציה — אלה מדדי האיכות של זיהוי טבלאות.
ספקות טכניים שאנו מסירים בתחילת הפרויקט
ספקות הנדסיים נוגעים לעיתים רחוקות למודל עצמו — הם עוסקים בנתוני הקלט, בקבלת התוצאה ובגבולות האחריות. לכן לפני ההתחלה אנו בוחנים את איכות הסריקות, את האחריות לשגיאה, את היקף הפיילוט ואת הרחבת הכיסוי.
יש לנו סריקות גרועות — האם הזיהוי בכלל יעבוד?
תחילה נחשב מדד על המדגם שלכם: שיעור התאים שחולצו נכון, על כמה מאות עמודים. רעש, נטייה ורשת מעוותת מטופלים ביישור ובזיהוי קווים; הוספות בכתב יד ותווים דבוקים יוצרים ירידה — שדות כאלה מסומנים לבדיקה ידנית. אם הדיוק נמוך מהסף, נאמר ישירות מה יעניק עיבוד מקדים, ומה — רק סריקה חוזרת.
מי אחראי לשגיאה בערך שחולץ?
בסכמת הקבלה לכל שדה מוגדר סף ודאות: מעליו — הערך עובר למערכת החשבונאית בעצמו, מתחתיו — לתור בדיקה בידי מפעיל. שגיאה לא נכנסת לחשבונאות בשקט, היא נעצרת בבקרה. אנחנו אחראים על קו העיבוד ועל יציבות המדד, אתם — על הכלל: אילו שדות קריטיים ומה לעשות במקרה של אי-התאמה.
איך נראה שלב הפיילוט?
לוקחים סוג מסמך אחד וקטע תהליך אחד ומריצים את כל המסלול מהעלאה ועד רישום במערכת שלכם. בפלט — זרימה עובדת, דוח דיוק לכל שדה ורשימת מקומות שבהם נדרשים תיקוני כללים. החלטה על הרחבה מתקבלת לפי המספרים.
עד כמה קשה אחר כך להרחיב את כיסוי המסמכים?
קו העיבוד מורכב משלבים: פירוק עמוד, זיהוי טבלה, שחזור מבנה, התאמת עמודות לסכמה. סוג מסמך חדש הוא בדרך כלל תבנית חדשה וכללי נרמול בשלבים האחרונים, ולא כתיבה מחדש של הליבה. לכן סוגי הטפסים השני והשלישי מתחברים מהר יותר מהראשון, והעומס על התמיכה לא גדל באופן ליניארי עם מספר הטפסים.
נדון במשימה ונחזור עם הערכה ותוכנית עבודה
כדי לחזור עם הערכה ותוכנית עבודה, איננו צריכים את כל ארכיון המסמכים — מספיק חתך מהזרימה האמיתית. ככל שתתארו ביתר דיוק אילו טבלאות מגיעות ובאיזה פורמט, כך יישארו פחות הנחות בתוכנית, וכך מהר יותר הפיילוט יגיע לעמודים שלכם, ולא לעמודי הדגמה.
דיון במשימה אורך שיחה אחת: אנו מפרקים את הזרימה, מסמנים אילו תבניות נסגרות בהגדרה והיכן נדרש מודל נפרד, ומסכימים על מדדי הקבלה. מערך הנתונים המינימלי לכך הוא:
- סוגי מסמכים: חשבוניות, תעודות משלוח, תדפיסי חשבון, דוחות ענפיים — מה סורקים, מה מגיע כקובץ דיגיטלי, מה מצלמים.
- נפח הזרימה: כמה עמודים בחודש והפרופיל שלו — אחיד או עם שיאים בתקופות דיווח.
- מבנה הטבלאות: תבניות קבועות או חופשיות, תאים מאוחדים, כותרות רב-שכבתיות, פריטים מרובי שורות.
- איכות הסריקות: רזולוציה, נטייה, רעש, תיקונים בכתב יד — זה הגורם העיקרי לדיוק הסופי.
- לאן למסור את התוצאה: Excel, מערכת חשבונאית, בסיס נתונים או החלפה דרך API — פורמט וכללי התאמה.
- תפקידי אנשים: מי מטפל בשורות שנויות במחלוקת ואיזה שיעור תיקון ידני מקובל עליכם.
- מערך ותשתית הרשאות: ענן או תשתית פנימית, דרישות אבטחת מידע, קיום סביבת בדיקות.
- דוגמאות: כמה עשרות עמודים המכסים את כל וריאציות התבניות שמופיעות.
מערך זה מרכיב תוכנית פיילוט: היקף המדגם לבדיקה, מדדי יעד לפי שורות ותאים, שלבים ותנאי עבודה — אותם מקבעים לפני ההתחלה, כדי שהתוצאה תתקבל לפי מספרים שסוכמו מראש. תארו את המשימה בצורה חופשית וצרפו דוגמאות — נחזור עם הערכת לוחות זמנים וסדר ההכנה להתחלה.