חילוץ טקסט בעברית מ-PDF: Unstructured AI מול Vision LLMs ב-2026

בשבוע שעבר הגיע אליי אריאל, מנהל מוצר בחברת SaaS מרוטשילד. היו לו 4,000 קטלוגים טכניים ב-PDF, מלאים בטבלאות בעברית, מפרטים הנדסיים ותמונות מוצר.

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

טקסט בעברית בתוך קובצי PDF הוא סיוט טכנולוגי וותיק.

השילוב בין כיווניות מימין לשמאל (RTL), קידודי פונטים נוראיים ומבנה ויזואלי מורכב דורש פתרון רציני. היום נפתור את השאלה: האם להשתמש בכלי ניתוח מובנה כמו Unstructured AI, או פשוט לזרוק את העמודים כאימג'ים ל-Vision LLM?

הגדרה · Unstructured AI

פלטפורמת בק-אנד וספריית open-source המפרקת מסמכים לא מובנים (PDF, DOCX, HTML) לרכיבי טקסט מובנים (Elements) המוכנים להזרמה למאגרי וקטורים (Vector DBs).

1. התמודדות עם עברית הפוכה ו-RTL

ספריות קלאסיות כמו PyPDF או PDFPlumber מנסות לחלץ את הטקסט מתוך שכבת ה-Vector של ה-PDF. בעברית, השכבה הזו היא מלכודת. לעיתים קרובות המילים נשמרות מהסוף להתחלה, או שהרווחים נעלמים.

Unstructured AI פותרת את זה על ידי שילוב של מודלי Layout יחד עם מנועי OCR (כמו Tesseract או PaddleOCR). הספרייה מבינה איפה יש בלוק טקסט, מריצה עליו OCR מותאם עברית, ומחזירה טקסט קריא בסדר הנכון.

מה צד ה-Vision LLMs? מודלים כמו GPT-4o או Claude 3.5 Sonnet לא קוראים את שכבת ה-PDF. הם מקבלים תמונה של העמוד. בדיוק כמו שפעינחת בעצמך את הקטלוג, המודל רואה את העברית, מבין את ההקשר ומחלץ אותה ללא שום בעיית RTL.

זה עובד מדהים.

2. חילוץ מבנה וטבלאות מורכבות

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

Unstructured AI מחלקת את המסמך לרכיבים: Header, NarrativeText, Table, Title. זה היתרון הגדול שלה. החלוקה הזו מאפשרת לעשות Chunking מדויק לפי מכלולים הגיוניים ולא לפי מספרי מילים שרירותיים.

## דוגמה לפלט מובנה מ-Unstructured
{
  "type": "Table",
  "text": "מק"ט | תיאור מוצר | מחיר",
  "metadata": {"page_number": 12, "filename": "catalog.pdf"}
}

Vision LLMs מסוגלים להוציא Markdown מצוין מטבלאות, אבל לפעמים הם "ממציאים" נתונים קטנים בטבלאות צפופות בעברית (הזיות). בנוסף, קשה יותר להוציא ממנה Metadata מובנה ועקבי על כל עמוד בסקייל גמיש.

3. עלויות, מהירות וסקלביליות

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

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

💡

אל תשלם על LLM בשביל לקרוא טקסט סטנדרטי. השתמש ב-Unstructured כדי לסנן ולחלץ 90% מהחומר, ושלח רק את העמודים הבעייתיים ל-Vision LLM.

ההמלצה שלי: הארכיטקטורה ההיברידית

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

1. סריקה ראשונית עם Unstructured AI: אנחנו מריצים את ה-PDF דרך Unstructured עם הגדרת strategy="hi_res" ומנוע OCR תומך עברית.
2. זיהוי מקשיים: המערכת בודקת את מדד ה-Confidence של ה-OCR. אם העמוד מכיל טבלה מסובכת מטושטשת או כמות חריגה של סימנים מוזרים — העמוד מסומן.
3. נתיב מעקף ל-Vision LLM: רק העמודים שנכשלו בסריקה הראשונית נשלחים כאימג' ל-Claude 3.5 Sonnet או GPT-4o להוצאת Markdown נקי.
4. הזרמה ל-Vector DB: המידע המובנה נכנס ל-ChromaDB או Pinecone, כשהוא מופרד בצורה מודולרית.

סיכום

אין תרופת פלא אחת לחילוץ עברית מ-PDF ב-2026. ספריות ישנות כבר לא רלוונטיות. Unstructured AI מעניקה את התשתית החזקה, המהירה והזולה ביותר לבניית צינור מידע (Data Pipeline) מקצועי בסקייל גבוה. Vision LLMs הם כלי המנתחים המדויק למקרים המורכבים ביותר.

שלב ביניהם ותקבל מערכת RAG שלא מפספסת אף נקודה בסקריפט.