העניין עם "AI בהקשר ארוך" הוא שכולם בטוחים שיש להם את זה — עד שאתה שואל שאלה מפורטת על עמוד 47. ואז, פתאום, הזיכרון שלו כמו זה של דג זהב עם פציעת ראש. DeepSeek-OCR מגיע במדויק ואומר משהו פשוט-אם-נכון: לדחוס את מה שחשוב, לשמור על המבנה, ולעצור את בזבוז הטוקנים כאילו זה 2023. ההבטחה היא לא "OCR אבל טוב יותר". זה OCR שמכבד את פריסת העמוד ומסרב להעמיס את חלון ההקשר ברועש מיותר.
כן, זה בדיוק מה שרוב מה שנקרא צינורות הקשר ארוך טועים בו. הם משילים טקסט גולמי לתוך המודל וקוראים לזה סיום. והיום מסתיים בהזיות.
בואו נצלול לאיך לשלב את DeepSeek-OCR בצינור הקשר ארוך אמיתי — כזה שיכול להתרחב, שמשלם את חשבון העיבוד בלי דמעות, ולא מתפרק כשה-PDF מכיל טבלאות, הערות שוליים, או, אלוהים יעזור, נספחים משפטיים.
למה DeepSeek-OCR שונה (וערכי)
- הפריסה היא מידע: מסמכים ארוכים הם לא רק טקסט; הם טיעונים מרחביים. כותרות, טורים, טבלאות, תיאורי איור — הכל משמעותי. DeepSeek-OCR מתכוון לשמר את המבנה הזה כרשת ראשית, וזה בדיוק מה שמודלי הקשר ארוך צריכים כדי להבין מאות עמודים בלי לאבד את העלילה.
- דחיסה בלי לובוטומיה: המטרה אינה לדחוס הכל לחלון 8K. אלא לשמור על האות — צפוף, מובנה, נגיש — ולהוזיל את שארית החומר.
- מתואם עם שלבים המשך: RAG, סיכום, טרנספורמרים להקשר ארוך ואפילו סוכנים. שכבה טובה יותר של OCR מפחיתה את טעויות השכבות של שליפה והסקת מסקנות.
מה שאתם בונים: צנרת הקשר ארוך עם עמוד שדרה
תחשבו על הצנרת כחמישה חלקים, שכל אחד עושה עבודה אחת טוב:
- סוגי קלט: PDF (דיגיטלי ומסורק), תמונות, TIFFים מסורקים, ייצוא משרדיים מבולגנים.
- עיבוד מקדים: יישור, ניקוי רעשים, בינריזציה אם צריך, ופיצול עמודים באופן עקבי. שמירת מטא-נתונים לכל עמוד — מספר עמוד, מקור הקובץ, עוגני סעיפים.
- פלט יעד: תמונות או בדי עמוד בפורמט צפוי (PNG או JPEG) וברזולוציה יציבה.
- הריץ DeepSeek-OCR על כל עמוד כדי לחלץ:
- קטעי טקסט עם תיבות גבול (x, y, רוחב, גובה)
- סוגי בלוקים: כותרות, פסקאות, רשימות, טבלאות, איורים, הערות שוליים
- סדר קריאה ומבנה היררכי (עץ המסמך)
- שמור גם טקסט גולמי וגם תכונות פריסה. אם אפשר לייצא מפת טוקנים, שמור אותה. טבלאות צריכות להיות מובנות (CSV/HTML) ומקושרות למיקום שלהן.
- הטריק: לדחוס לפי חשיבות הבלוק, לא לפי חיתוך נאיבי של טוקנים.
- היוריסטיקות שעובדות באמת:
- כותרות וסיכומי פרקים: שמרו אותן במדויק.
- פסקאות: בחירת משפטים ברמת משפט באמצעות דירוג קל (סגנון BM25/ColBERT או מקודד קטן מקומי).
- טבלאות: שמור כותרות ושורות מובילות עם שונות סטטיסטית; שמור עמודות מספריות בשלמות; הדחס את הטבלה המלאה בנפרד.
- תיאורים והערות שוליים: שמור; מעט טוקנים, משמעות גבוהה.
- קונטקסט סיפורי דחוס, מודע לפריסה: 10–20% מהטוקנים המקוריים, עקבי ונגיש.
- אינדקס צדדי: קישורים מקטעי טקסט דחוסים אל הבלוקים המלאים.
- שחרור ושליפה (RAG מבוצע בייעילות)
- וקטורים צפופים לחיפוש סמנטי במשפטים/פסקאות.
- אינדקס דל (BM25) למlookup מדויק — קודים, ציטוטים, מזהים.
- אינדקס מודע טבלאות: הטמעות לפי שורה ותא לשאילתות מספריות.
- שאלות עם מילות מפתח→ תחילה דל, דירוג מחדש עם צפוף.
- שאלות אנליטיות או 'למה' → תחילה צפוף, דירוג מחדש עם עוגנים דלים.
- שאילתות טבלה/מתמטיקה → אינדקס הטבלה ישירות, עם מקור שורה/עמודה.
- LLM להקשר ארוך עבור בקשות כוללות (מסמכי מדיניות, RFPs, מאמרים מחקריים).
- סוכן שלב-אחר-שלב עם קריאת כלים למשימות מרובות שלבים: שלוף → נתח → אמת → צטט.
- אל תזריק את כל הקונטקסט הדחוס למודל בבת אחת. הרכב בהקשר בזמן אמת: חלקי עיקר לפי הכוונה, טבלאות רלוונטיות, פסקאות סמוכות. חבר באמצעות פירורי לחם (שמות סעיפים, הפניות לעמודים, מזהי איורים).
מה שיוצא: תשובות עם קבלות. כל טענה מקושרת למזהה בלוק, מספר עמוד וטווח קואורדינטות שניתן להדגיש ב-PDF המקורי. ככה מקבלים אמון.
מפת הדרכים המעשית: מ-PDF גולמי לתשובות בהקשר ארוך
שלב 1: קליטת המסמך
- ודא שהקובץ תקין: אם מוגן בסיסמה או פגום, כישלון מהיר.
- הפעל רינדור לתמונות עמודים ברזולוציה קבועה (300 DPI טוב; 200 למהירות).
- שמור שטחי חיתוך לעמודים כדי לאפשר מטמון OCR.
שלב 2: הרצת DeepSeek-OCR
- אצור עמודים עבור יעילות GPU.
- חלץ בלוקים וסדר קריאה. תקנן קואורדינטות למרחב עמוד קונסיסטנטי.
- JSON: רשימת בלוקים עם סוג, טקסט, bbox, עמוד.
- טבלאות כ-CSV/HTML בנוסף למפת bbox לכל תא.
- סימון אופציונלי במארקדאון עם רמזי פריסה (## לכותרות, :::table לטבלאות וכו').
שלב 3: ניקוי אחרי OCR
- מיזוג מילים משורשרות על פני שבירות שורה.
- פתרון טורים: אם עמוד דו-עמודי, סדר הקריאה מתאים לטורים.
- זיהוי כותרות לפי גופן/גודל אם לא סופק; בניית עץ TOC.
- הסרת כותרות/כותרות תחתונות שחוזרות על עצמן (נפוץ בחוזים מסרוקים).
שלב 4: דחיסה עם מבנה
- פצל פסקאות למשפטים. דרג משפטים על ידי מדורג זול ומותאם לתחום.
- שמור משפטים בעלי דירוג גבוה; שמור תמיד את המשפט הראשון תחת כל כותרת.
- לטבלאות: שמור שורת כותרת + k השורות העליונות לפי שונות/חשיבות וקישור לטבלה המלאה.
- הפק את הסיפור הדחוס ואת אינדקס הסיוע שקושר כל משפט שמור למקורו.
שלב 5: אינדוקס
- הטמעות צפופות למשפטים (השתמש במודל רב-לשוני חזק אם צריך).
- אינדקס דל על כל הקורפוס (כותרת, כותרות, קודים, ציטוטים, מזהים, יחידות).
- הטמעות טבלה ברמת שורה ותא; שמור סטטיסטיקות מספריות (מינימום, מקסימום, ממוצע) לסינון מהיר.
- אחסן מקוריות: doc_id, עמוד, bbox, block_id.
שלב 6: ניתוב ושחרור שאילתות
- סווג כוונת השאלה: חיפוש מול ניתוח מול מתמטיקת טבלה מול השוואה.
- הפעל את המתכון המתאים לשחרור:
- חיפוש: דל → דירוג מחדש צפוף.
- ניתוח: צפוף → שכני סעיפים.
- מתמטיקת טבלה: אינדקס טבלה + מסנני שורה; צירוף טקסט סמוך להקשר.
- 3–6 קטעים שהובחרו (עם כותרות והפניות לעמודים)
- אם צריך, 1–2 טבלאות קטנות או סטטיסטיקות מחושבות
- שמור על הנחיות מתחת למגבלות המתאימות לדגם. הקשר ארוך לא הוא הקשר אינסופי.
שלב 7: סינתזת תשובות עם ציטוטים
- בקשת פלט מובנה: תשובה מחולקת וסיטוטים בתוך הטקסט כמו [Doc §2.3, עמ' 47, טבלא A].
- לטענות מורכבות, הפעל מעבר אימות: שלוף מחדש קטעים מדויקים, שאל שאלה ממוקדת, הפשר סתירות.
- החזר תשובה עם מסלול מקוריות שניתן ללחוץ עליו.
הערות על ביצועים שיחסכו הרבה כסף
- אל תעשה YOLO על ה-GPU: OCR תלוי I/O ו-GPU בהחלפה מוזרה. אצור לפי מספר עמודים ותקנן גדלי תמונות למקסום שימוש בקרנל.
- מטמון בקדיחות: אם מסמך המקור לא השתנה, אל תריץ OCR מחדש. חשב את הגיבוב (hash) של ביטמאפ העמוד, לא של הקובץ.
- טבלאות הן מוקשים: הן מגדילות את ספירת הטוקנים ומורידות איכות. חלץ אותן בניקיון ושמור אותן מחוץ להקשר הכללי אלא אם השאלה דורשת.
- פיצול מקטעים זה לא דת: חתוך לפי פריסה (כותרות, פסקאות), לא לפי אורך טוקנים. פיצול לפי טוקנים מאבד את מבנה הטיעון.
- אמת לפני סיכום: אל תסכם קטעים לא ברורים עד שהשליפה תמקד את ההקשר; תדחוס את הדברים הלא נכונים.
התמודדות עם שגיאות: החלקים הלא סקסיים שחשובים
- קבצי PDF שבורים: נסה רנדר רסטר כגיבוי. אם עדיין שבור, החזר ארטיפקט אבחון. כישלון שקט גרוע מאין תשובה.
- סריקות גרועות (ברמת פקס): נסה ניקוי רעשים/הגברת ניגודיות; אם האמון יורד מתחת לסף, סמן לבדיקה אנושית. תתוודות על מה שלא ידוע.
- תסריטים לא לטיניים: ודא שמודל OCR תומך בסט התסריטים שלך; אחרת ניתוב לגרסה מותאמת של OCR.
- טבלאות שנראות כמו אמנות: אם זיהוי טבלה נכשל, אל תעמיד פנים. התייחס אליה כתמונה עם כיתוב והחזר הודעה שדורש חילוץ ידני.
מודל נתונים: שמור על המפה עם השטח
- סוג: כותרת/פסקה/רשימה/טבלה/איור/הערת שוליים
- טקסט (אופציונלי), bbox, סדר, רמזי סגנון
- שורות, עמודות, טקסטי תאים, bbox תאים, דגלי כותרת
- doc_id, עמוד, block_id, offsets, bbox
אבטחה וציות
- אל תעלה PDF רגישים ל-APIs של צד שלישי אלא אם המדיניות מאפשרת. אם חייב, הצפן בשליחה ובמנוחה.
- טשטש PII בשלב OCR אם אפשר — טשטוש באמצעות תיבת גבול חזק יותר ממסיכת מחרוזות לאחר מעשה.
- תעד שליפות ויצירת תשובות בלי לרשום תוכן כשאסור. שמור גיבובים ומזהים, לא טקסט גולמי.
בחירת מודלים להקשר ארוך (בלי ההייפ)
- אם השאלות שלך בעיקר "איפה זה נאמר X" — העדף שליפה וציטוטים על פני אורך הקשר גולמי. הקשר קצר ומדויק עדיף על הזיה של מיליון טוקנים.
- אם המסמכים שלך נרטיביים (מחקר, דוחות), מודלים להקשר ארוך עוזרים, אך רק כשהם מונחים על ידי מבנה הסעיפים.
- זרימות עבודה עם המון טבלאות רוצות 'מוח מפוצל': מודל שפה לפרוזה, תוכנית קלה לאריתמטיקה וסינון.
גרסאות וסטייה
- OCR משתפר; מסמכים משתנים; הטמעות זזות. תעשה גרסאות לכל:
- כשמשהו משתנה, עשה אינדוקס מחדש באופן מצטבר. שמור ישן וחדש עד שתוכיח שקולות.
שרטוט אינטגרציה למפתחים
- עובד 1: קליטה → רינדור עמודים → תור.
- עובד 2 (GPU): DeepSeek-OCR לעמוד → JSON מובנה → טבלאות.
- עובד 3: ניקוי + עץ פריסה → דחיסה.
- עובד 4: בניית אינדקס (צפוף + דל + טבלאות) → פרסום.
- שירות: נתב שאילתות → שליפה → הרכבת הנחיות → LLM → אימות → תגובה.
- אחסון: אחסון עצמים לתמונות עמודים ו-csidecar; DB לבלוקים ומקוריות; אינדקסים וקטוריים ודתיים.
מילה על כלים שלא עושים בלגן
החלק הכי פחות בולט לעיתים כשול ההקשר. OCR מחמירה שמכבדת פריסה, אינדקס שיכול לומר "אני לא יודע", ובונה הנחיות שמסרב לעמוס מדיי. זו העבודה. אם רוצים לשלב את זה בזרימת עבודה מעשית—למשל לסכם חוזים, לסרוק 300 עמודי RFI, או לבדוק מדריכי SOP — Sider.AI באמת עובד כמו שכבת דבק בין OCR, שליפה והנחייה להקשר ארוך, במיוחד כשמתייחסים אליו כמפקח המחליט ולא כקוסם. השתמש בו לארכיטקטורה: משימות קליטה, מדיניות חלוקה, בחירת מודלים ולולאת "אמת לפני שאתה סומך". הוא שווה כשצריך להרחיב על פני צוותים ולשמור על תוצאות שחוזרות על עצמן. ה'פחותים' שתיתקל בהם עד יום שישי
- דחיסה יתרה: חותכים יותר מדי והתשובות מאבדות גוון. עקוב אחרי מדדי אורך/כיסוי תשובות; הוסף גיבוי שמשלף את הבלוק המלא כשהאמון יורד.
- שליפת יתר: מעלים 60 מקטעים להנחיה וחורגים מההקשר. תגבול ותטה לכיוון סמיכות (סעיפים שימיים זהב).
- אשליות טבלה: המודל מצטט מספר באופן משכנע — אבל משורה שגויה. תמיד תשלב קטעי טבלה עם מפתח שורה בהנחיה.
- עמודים כפולים: זרימות סריקה אוהבות לשכפל. חשב את גיבוב העמודים; מחק כפילויות לפני שאתה משלם על OCR.
- הפניות והערות שוליים: הן נושאות הסתייגויות בעלות משמעות משפטית. לעולם אל תדלג על הערות שוליים במסמכי מדיניות/משפט; שמור אותן בנתיב עם טוקנים נמוכים.
מדדי איכות שאינם משקרים
- דיוק ציטוטים מובילים: האם הבלוק המצוטט באמת תומך בטענה?
- דיוק תא טבלה: שיעור הפניות נכונות בתשובות מספריות.
- אמינות דחיסה: חפיפה בסגנון ROUGE/LFQA בין הסיפור הדחוס למקור לכל סעיף.
- זמן תגובה בשאילתות תחת עומס: P95 מקצה לקצה, לא רק זמן LLM.
- ציון אמון אנושי: האם משתמשים מאמצים או דוחים את התשובה במבט ראשון? זה המדד היחיד שמנבא הטמעה.
דוגמה מינימלית עובדת (קונספטואלי)
- קלט: מפרט רכש של 180 עמוד עם נספחים וחמש טבלאות מורכבות.
- מריצים DeepSeek-OCR; הוא מוציא בלוקים מובנים עם תיבות גבול וטבלת תוכן נאמנה.
- דחיסה שומרת את כל הכותרות, המשפטים הראשונים והשורות החיוניות מהטבלאות. סיידקאר מפנה חזרה לכל פריט.
- משתמש שואל: "איזה סעיף קובע תקופת אחריות לרכיבים חשמליים?"
- השליפה מחזירה שני סעיפים ונספח אחד.
- ההנחיה מספקת כותרות+פסקאות עם ציטוטים בתוך הטקסט.
- המודל עונה: "סעיף 4.2.1, עמ' 67: 'רכיבים חשמליים מקבלים אחריות מינימלית של 36 חודשים...'" עם קישור שמדגיש בדיוק את הקטע.
- משתמש שואל: "מה התקציב הכולל להספק מכל המדפים?"
- הנתב בוחר אינדקס טבלה. הוא מחלץ את השורות הנכונות, מסכם שני עמודות עם כלי פשוט, וצוטט טבלה B-3 עם מפתחות שורה. אין מתמטיקה מהולה בהזיות.
למה זה עובד כשאחרים לא
כי הוא מטפל ב-OCR, שליפה והסקת מסקנות כמטלות נפרדות עם חוזה ביניהן. DeepSeek-OCR נותן מבנה; הדחיסה שומרת על משמעות; השליפה מביאה את ההוכחות הנכונות; מודל ההקשר הארוך מאחד הכל בלי לטבוע במילוי מיותר. ברירת המחדל בתעשייה היא לדחוף הכל לחלון גדול יותר ולבקש. תפילה היא לא אסטרטגיה.
אם אתה מתכוון לקצר דרך, תקצר אותן אחרונות
- חלץ טבלאות: אם תחסוך בזה, כל השלבים הבאים ירשו את הבלגן.
- צנרת מקוריות: משתמשים סולחים לאיטיות ולפעמים טעויות; הם לא סולחים על תשובות שאי אפשר לאמת.
- מטמון וגיבוב: חשבון הענן יסלח לך אם תעשה את זה נכון.
החלק הנרטיבי: האם באמת צריך הקשר ארוך?
מחשבה חריפה: לפעמים הקשר ארוך הוא קב מצידה של שליפה גרועה. אם השאלות מדויקות וצרות, תשקיע באינדוקס טוב יותר ובהקשרים קטנים יותר. הקשר ארוך טוב כשצריך סינתזה בין סעיפים — חריגי מדיניות, הפניות חוצות סעיפים, סקירות ספרות. אחרת אתה משלם על קשב מיותר.
ואם באמת צריך "לקרוא את הכל"? אל תכריח את המודל לשמור הכל בזיכרון העבודה. שלב: מתווה → שליפה → הצדקה. אפילו אנשים עושים את זה.
סיכום: הבא קבלות או אל תטרח
שילוב DeepSeek-OCR בצנרת הקשר הארוך הוא לא פולחן של חלונות גדולים. זה לכבד מסמכים כטיעונים מרחביים, לדחוס בטעם, לשלוף בכוונה, ולהשיב עם קבלות. עשו את זה, והצנרת שלכם מפסיקה להעמיד פנים שהיא זוכרת עמוד 47 — ומתחילה להוכיח את זה.
Sider.AI, בשימוש מושכל, עושה את זה מעשי: מארגן את השלבים, שומר על הנחיות כנות, ומכפה את המשמעת שדרושה בעבודה בהקשר ארוך. אם זה נשמע לא סקסי, טוב. החלק הסקסי זה תשובות שאפשר לסמוך עליהן. שאלות נפוצות
ש1: איך משלבים את DeepSeek-OCR בצנרת הקשר הארוך הכי מהר?
טפלו ב-OCR כשירות אצווה GPU עם מטמון קפדני, דחוסו לפי פריסה (כותרות, פסקאות, טבלאות) לפני השליפה. הוסיפו אינדקס היברידי (צפוף + דל + טבלה) והרכבו הנחיות בזמן אמת במקום להטביע את כל המסמך.
ש2: האם אני באמת צריך מודלי הקשר ארוך כשאני משתמש ב-DeepSeek-OCR?
לא תמיד. אם השאלות מדויקות, שליפה טובה וציטוטים מנצחים את כוח הגס של הקשר. הקשר ארוך משתלם כשצריך סינתזה בין סעיפים, לא כשמחפשים סעיף אחד בעמוד 67.
ש3: איך מטפלים בטבלאות בלי לגרום למספר טוקנים להיגמד?
חלצו טבלאות במבנה, שמרו כותרות וכמה שורות עם אותות גבוהים, ואכסנו את הטבלה המלאה בנפרד. כוונו שאלות טבלה לאינדקס טבלה ושתפו בהנחיה רק את התאים הנדרשים.
ש4: אילו מדדים מוכיחים שהצנרת באמת עובדת?
עקבו אחרי דיוק ציטוטים, דיוק הפניות תאי טבלה, אמינות דחיסה לפי סעיף, וזמן תגובה P95 מקצה לקצה. הכי חשוב הוא ציון אמון אנושי—האם המשתמשים מקבלים תשובות בלי לחפש הוכחות?
ש5: איפה Sider.AI משתלב בהגדרה הזו?
כשכבת אכיפה: מתזמן OCR, מכריח מדיניות חלוקה ושליפה, ושומר על הנחיות מצוננות. תחשוב עליו כמפקח, לא כקוסם—הדבר שגורם לכל החלקים האחרים להגיע בזמן ועם קבלות. 
