Multimodal RAG — Retrieval משולב של טקסט, תמונות וטבלאות

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

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

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

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

למה RAG טקסטואלי מפספס תוכן חזותי

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

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

ייצוג רב-מודלי: Embeddings משותפים או נפרדים

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

טיפול בטבלאות כסוג תוכן נפרד

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

Retrieval: איחוד תוצאות ממקורות שונים

כשיש כמה סוגי תוכן, שאילתת retrieval בודדת צריכה להחזיר תוצאות ממקורות מעורבים - קטע טקסט, תמונה, שורת טבלה - ולדרג אותם יחד בסקאלה אחת. זה מאתגר כי ציוני דמיון ממודלים שונים לא בהכרח ניתנים להשוואה ישירה. פתרון נפוץ הוא שלב reranking נפרד שמעריך מחדש את כל התוצאות המועמדות - מכל סוגי התוכן - באמצעות מודל אחד משותף שמסוגל לשפוט רלוונטיות בין-מודלית, במקום להסתמך על ציוני ה-retrieval הגולמיים. הרחבה מלאה על התבנית הזו במדריך Reranking ב-RAG ובHybrid Search.

Generation: איך ה-LLM צורך תוכן רב-מודלי

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

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

Chunking לתוכן מעורב

מסמך אמיתי (PDF טכני, מצגת) מערבב טקסט, תמונות וטבלאות באותו עמוד. חיתוך (chunking) נכון שומר על הקשר בין תמונה לטקסט שמתאר אותה - למשל, לא להפריד תרשים מהכיתוב שמסביר אותו לשני chunks נפרדים. גישה מעשית היא chunking מבוסס פריסה (layout-aware) שמזהה את המבנה החזותי של העמוד ושומר יחד אלמנטים שקשורים מרחבית, בשילוב עם עקרונות ה-Semantic Chunking הכלליים. כלל אצבע פרקטי: אם תמונה ופסקה מסבירה אותה נמצאות באותו chunk לוגי, סביר שאותה יחידת retrieval תספק ל-LLM את כל מה שהוא צריך כדי לענות נכון - ואם הן מתפצלות, כדאי לשקול לצרף ביניהן קישור מפורש גם אם הן ב-chunks נפרדים.

הכנת התוכן: מ-PDF גולמי למאגר רב-מודלי

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

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

שילוב עם RAG טקסטואלי קיים

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

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

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

דוגמה מהשטח

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

מדידת איכות במערכת רב-מודלית

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

שאלות נפוצות

האם צריך מודל embedding נפרד לתמונות ולטקסט?

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

איך מטפלים בטבלאות מורכבות ב-RAG?

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

כמה תמונות כדאי להזין ל-LLM בכל בקשה?

רק את המספר הרלוונטי ביותר לפי דירוג reranking - בדרך כלל כמה בודדות - כי כל תמונה נוספת מייקרת את הקריאה משמעותית.

מה קורה כשה-chunking מפריד תמונה מהכיתוב שלה?

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

האם multimodal RAG יקר יותר מ-RAG טקסטואלי רגיל?

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

איך מוסיפים יכולת רב-מודלית למערכת RAG טקסטואלית קיימת?

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

איך מטפלים בטקסט מוטבע בתוך גרפים ודיאגרמות?

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

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

תגיות: multimodal RAG · vision RAG · document AI · reranking · hybrid search · embeddings

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