Document Intelligence Architecture — OCR, Extraction, Classification ו-LLM

מאת צוות מדיה דיל · 09.08.2026 · AI · 8 דק׳

מאות חשבוניות בפורמטים שונים מגיעות כל חודש, ומישהו צריך לחלץ מהן נתונים ידנית. מדריך לבניית מערכת Document Intelligence שמשלבת OCR, סיווג ו-LLM יחד בדיוק.

מחלקת כספים מקבלת מדי חודש מאות חשבוניות מספקים שונים - כל אחת בפורמט אחר, חלקן PDF סרוקים באיכות ירודה, חלקן טבלאות מורכבות, חלקן תמונות שצולמו בטלפון. מישהו צריך לקרוא כל חשבונית, לחלץ ממנה סכום, תאריך, מספר ספק ופריטים, ולהזין את זה למערכת ה-ERP. זו בדיוק המשימה שה-Document Intelligence נועד לפתור: שילוב של OCR, זיהוי מבנה מסמך וסיווג עם הבנה סמנטית של LLM, כדי להפוך מסמך גולמי לנתונים מובנים ואמינים - בלי אדם שקורא כל דף בנפרד.

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

שלוש השכבות של Document Intelligence

ארכיטקטורה בשלה מבוססת על שלוש שכבות נפרדות שכל אחת פותרת בעיה אחרת: OCR שהופך פיקסלים לטקסט גולמי, Layout Analysis שמזהה את המבנה המרחבי של המסמך (טבלאות, כותרות, שדות טופס), ו-LLM Extraction שמבין את המשמעות הסמנטית ומחלץ שדות ספציפיים מתוך ההקשר. ניסיון לדלג על שכבה - למשל לתת ל-LLM תמונה גולמית בלי שכבת layout analysis שקדמה לה - עובד סביר על מסמכים פשוטים ונשבר על מסמכים מורכבים עם טבלאות משורגות או עמודות מרובות.

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

OCR: מגבלות שחשוב להכיר

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

טיפול בטבלאות ובמסמכים מרובי עמודות

טבלאות הן נקודת הכשל הנפוצה ביותר ב-OCR קלאסי - הוא נוטה "לשטח" את הטבלה לטקסט רציף ולאבד את הקשר בין עמודה לשורה. מנועי Layout Analysis ייעודיים שמזהים גבולות תא וטבלה לפני החילוץ נותנים תוצאה טובה משמעותית ממנועי OCR גנריים, ולעיתים משתלם להשקיע במנוע ייעודי דווקא לטיפול בטבלאות גם אם שאר המסמך מטופל היטב על ידי OCR רגיל. אותו עיקרון חל גם על טפסים עם שדות מסומנים (checkboxes, חתימות) - מנועי OCR טקסטואליים פשוט לא מזהים אותם נכון, ונדרשת שכבת זיהוי ייעודית שמבינה את הסמנטיקה החזותית של טופס.

Classification: לזהות מה סוג המסמך לפני שמחלצים

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

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

Extraction: מפריסה חזותית למידע מובנה

שלב החילוץ עצמו, אחרי הסיווג, משתמש ב-LLM עם פרומפט ממוקד וסכימת פלט מובנית (JSON Schema) כדי להוציא שדות ספציפיים - סכום, תאריך, ספק, פריטים. חשוב להגדיר סכימת פלט קשיחה כדי שהתוצאה תמיד תגיע בפורמט צפוי שאפשר לעבד אוטומטית, בדומה לעקרונות שמפורטים במדריך Structured Outputs.

{
  "vendor": "string",
  "invoice_date": "YYYY-MM-DD",
  "total_amount": "number",
  "confidence": "number"
}

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

Human-in-the-Loop לפי רמת ביטחון

לא כל מסמך צריך לעבור בדיקה אנושית - זה יהרוג את היעילות של המערכת כולה. הגישה הנכונה היא ניתוב לפי ביטחון: מסמכים עם ציון ביטחון גבוה עוברים אוטומטית, מסמכים עם ציון בינוני מסומנים לבדיקה מהירה, ומסמכים עם ציון נמוך עוברים לתהליך ידני מלא. סף ההפרדה בין הקטגוריות האלה לא קבוע - הוא נגזר מהעלות של טעות (חשבונית עם סכום שגוי היא יקרה יותר מטעות בסיווג תגית פנימית) ומדויק ל-Human-in-the-Loop שמפורט במדריך Human-in-the-Loop ובApproval Gates.

מדידת דיוק ושיפור מתמשך

מערכת Document Intelligence טובה נמדדת לא רק לפי דיוק ראשוני אלא לפי היכולת שלה להשתפר עם הזמן. כל מקרה שעבר לבדיקה אנושית ותוקן הוא הזדמנות ללמידה - אם נאסף כדוגמה לספריית few-shot או לכיול סף הביטחון, המערכת משתפרת בהדרגה על סוגי המסמכים הספציפיים שהארגון בפועל מקבל, ולא רק על בנצ'מארק כללי. הרחבה על בניית ערכות evals לתהליך כזה במדריך LLM Evals.

אינטגרציה עם מערכות Downstream

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

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

אבטחה ופרטיות במסמכים רגישים

מסמכים כמו חוזים, תעודות זהות וחשבוניות מכילים מידע רגיש ולעיתים מוגן ברגולציה. חשוב להגביל גישה לתוכן הגולמי לפי הרשאות ברורות, להצפין אחסון של מסמכים ותוצרי החילוץ, ולוודא ששכבת ה-LLM שמבצעת את החילוץ לא שולחת תוכן רגיש לספק חיצוני בניגוד למדיניות הארגון. הרחבה על עקרונות אלה בAI Secrets Management ובAI Audit Logs.

טעויות נפוצות

• דילוג על שכבת Layout Analysis - הזנת תמונה גולמית ישירות ל-LLM בלי זיהוי מבנה מוקדם, מה שנכשל על טבלאות ומסמכים מורכבים.
• התייחסות לפלט OCR כמדויק באופן אחיד - בלי לשקלל ציון ביטחון לכל קטע, מה שמסתיר טעויות בדיוק במקומות הכי קריטיים.
• סיווג מוטעה שממשיך לחילוץ - הפעלת סכימת חילוץ שגויה שמייצרת תוצאה שנראית תקינה אך שגויה מהותית.
• בדיקה אנושית של הכל או של כלום - בלי ניתוב לפי ביטחון, מה שהורג יעילות או מסכן דיוק.
• אין לולאת למידה ממקרי תיקון ידני - טעויות חוזרות על עצמן במקום שהמערכת משתפרת מתיקונים קודמים.
• הזרקת תוצר לחילוץ למערכת downstream בלי הקשר - שדות מחולצים בלי ציון ביטחון או קישור למקור, מה שמקשה על אבחון טעויות בדיעבד.
• שליחת תוכן רגיש לספק מודל חיצוני בלי בדיקה - התעלמות ממדיניות פרטיות ורגולציה בזמן עיצוב שכבת החילוץ.

דוגמה מהשטח

ארגון עם נפח חשבוניות ספקים גבוה בנה מערכת Document Intelligence לאוטומציה של קליטת חשבוניות. בגרסה הראשונה, כל חשבונית עברה חילוץ אוטומטי מלא בלי ניתוב לפי ביטחון וללא שכבת Layout Analysis ייעודית לטבלאות, וכמה טעויות בסכום - מקורן בטבלאות שה-OCR "שיטח" בטעות לתוך טקסט רציף - הגיעו עד למערכת התשלומים בטרם התגלו. הצוות הוסיף ציון ביטחון משוקלל שמשלב OCR ו-LLM, עם סף שמפנה כל חשבונית עם ביטחון נמוך מ-95 אחוז לבדיקה ידנית לפני תשלום. שיעור החשבוניות שעוברות אוטומטית במלואן נשאר גבוה משמעותית, אבל כעת בלי אף טעות בתשלום שהגיעה מהמערכת האוטומטית - הבדיקה הידנית התמקדה בדיוק במקרים שבאמת דרשו אותה. כחלק מהתהליך, הצוות גם הוסיף דוח שבועי שמראה את התפלגות ציוני הביטחון לאורך זמן, מה שאיפשר לזהות מוקדם ספק חדש ששלח חשבוניות באיכות סריקה נמוכה במיוחד, ולפנות אליו ישירות לבקש קבצים איכותיים יותר במקום להמשיך לספוג טעויות חילוץ.

שאלות נפוצות

האם LLM לבד יכול להחליף OCR מסורתי?

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

איך קובעים את סף הביטחון לניתוב לבדיקה אנושית?

לפי עלות הטעות - תהליכים פיננסיים או משפטיים דורשים סף גבוה יותר (יותר מסמכים לבדיקה ידנית) מתהליכים פנימיים בעלי סיכון נמוך.

מה קורה כשמסמך לא משתייך לאף קטגוריה מוכרת?

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

איך משפרים דיוק לאורך זמן?

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

מה ההבדל בין Document Intelligence ל-RAG על מסמכים?

Document Intelligence מתמקד בחילוץ שדות מובנים ומדויקים ממסמך בודד; RAG מתמקד בחיפוש ואחזור מידע רלוונטי מתוך מאגר מסמכים גדול לצורך מענה על שאלה.

איך שומרים על פרטיות במסמכים רגישים כמו חוזים?

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

האם עדיף עיבוד מיידי או batch למסמכים?

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

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

תגיות: document intelligence · OCR AI · document extraction · layout analysis · structured outputs · human in the loop

← חזרה לבלוג · צור קשר