סיווג אוטומטי של מסמכים לפי סוג: יישום ב-ML

מדוע סיווג אוטומטי של מסמכים נשבר בזרימה

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

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

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

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

מה נותן סיווג בפועל: מהירות, דיוק, סיכונים

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

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

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

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

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

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

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

שלוש סכימות ומחיר התחזוקה שלהן

איך אנחנו מיישמים ניתוח זרימת נכנסים: שלבי עבודה

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

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

מה נשאר אצלכם אחרי היישום: קונפיגורציות ותקנונים

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

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

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

מקרה בוחן: ניתוח זרימת נכנסים במערכת חשבונאית

היכן עמד הזרימה

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

מה שינו בקו העיבוד

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

מטריקות על אותה זרימה

דיוק זיהוי הסוג עלה מ-78% ל-96%, שיעור הבדיקה הידנית ירד מ-100% ל-21% — והאחוזים האלה נופלים בעיקר על סריקות מקומטות וחבילות משולבות. הזמן הממוצע מקבלת הקובץ ועד מסמך ממוין הצטמצם מ-38 דקות ל-2.5 דקות.

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

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

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

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

חוקים לעתים קרובות חיים ישירות במערכת החשבונאית — 1С:Документооборот וקונטורים דומים, שבהם כל שינוי מתואם. מכאן גם סדר המעבר: תחילה הרצת צל, אחר כך סוג מסמך אחד, לאחר מכן האחרים, ורק אחרי זה מכבים את התנאים אחד אחד.

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

ספקות טכניים: דיוק, סימון, השלמה

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

כמה מסמכים צריך לסמן ומי עושה זאת?

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

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

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

מה קורה אחרי ההרצה ואיך נראית ההשלמה?

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

נדון במשימה ונחזור עם הערכה ותוכנית

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

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

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

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

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