להפוך מיילים ו-PDF לרשומות במערכת

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

Naomivoעודכן

OCR לבד לא מספיק

OCR הופך תמונה לטקסט. הוא לא יודע ששורה מסוימת היא כמות ולא מק"ט, שהמספר בפינה הוא מספר הזמנה, או שהטבלה נמשכת לעמוד הבא.

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

איפה מודל שפה באמת עוזר

בהבנה. לזהות שהמשפט "תשלחו כמו בפעם שעברה אבל 20 יחידות" הוא הזמנה שדורשת היסטוריה. לחלץ שדות ממסמך שלא ראיתם בפורמט הזה. להבחין בין כתובת חיוב לכתובת משלוח כששתיהן מופיעות בלי כותרת.

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

ואיפה הוא מזיק

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

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

ביטחון ונקודת עצירה

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

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

מה למדוד

שלושה מספרים אומרים אם זה עובד:

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

התהליך בפועל

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

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

שאלות שחוזרות

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

בשורה התחתונה

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