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