GraphRAG — שילוב Knowledge Graph ו-LLM

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

כשהמידע שלכם הוא בעיקר קשרים בין ישויות - מוצרים, לקוחות, תלויות - ולא רק טקסט חופשי, Vector Search לבדו מפספס. מדריך ל-GraphRAG ולמתי הוא באמת שווה את המורכבות.

שאלה כמו "אילו לקוחות מושפעים אם השרת בפרנקפורט נופל?" היא שאלה שכל מערכת RAG סטנדרטית תיכשל בה, לא בגלל שהמידע לא קיים, אלא בגלל שהתשובה דורשת מעבר בין כמה קשרים: שרת בפרנקפורט מארח שירותים מסוימים, שירותים אלה משמשים לקוחות מסוימים, ולקוחות אלה שייכים לחוזי SLA שונים. אין קטע טקסט בודד שמכיל את כל השרשרת הזו - המידע פזור על פני מסמכים ורשומות נפרדות, מחובר רק דרך קשרים לוגיים. GraphRAG נועד בדיוק לפער הזה: הוא משלב Knowledge Graph - מבנה שמייצג ישויות (Entities) והקשרים ביניהן במפורש - עם יכולות ה-Retrieval הסמנטי הרגילות של RAG.

מקרה שימוש קלאסי: ניתוח תלויות בתשתית טכנית

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

למה Vector Search לבדו לא מספיק כאן

Vector Search מצטיין במציאת דמיון - קטעי טקסט שעוסקים בנושא דומה. אבל שאלות מסוג "מה משפיע על מה", "מי קשור למי", או "מה השרשרת בין A ל-C דרך B" הן שאלות מבניות, לא שאלות דמיון. אפשר לחפש "פרנקפורט" ולקבל קטעים שמזכירים את המילה, אבל אף קטע בודד לא "יודע" לענות על שאלת ריבוי-הקפיצות בלי שמישהו יבנה מראש את מבנה הקשרים בין הישויות. זו בדיוק המגבלה שגם גרפי ידע קלאסיים נועדו לפתור עוד לפני עידן ה-LLM - GraphRAG פשוט מחבר את היכולת הזו ליכולות השפה הטבעית של מודל שפה.

מה קורה כשהמידע מגיע מכמה מקורות במקביל

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

איך בונים גרף ידע ממקורות טקסט

שלב הבנייה עצמו כולל בדרך כלל שני תת-שלבים: Entity extraction - זיהוי ישויות (אנשים, מוצרים, מיקומים, מושגים) בתוך מסמכי המקור, בדרך כלל בעזרת LLM שעובר על הטקסט ומחלץ ישויות וטיפוסיהן; ו-Relation extraction - זיהוי הקשרים בין הישויות שזוהו ("שרת X מארח שירות Y", "לקוח Z רכש חוזה W"). התוצאה נשמרת במסד נתונים גרפי ייעודי, כשכל ישות היא צומת (Node) וכל קשר הוא קשת (Edge) עם תווית סמנטית.

חלק מהגישות המתקדמות יותר (למשל Microsoft GraphRAG וגישות דומות) הולכות צעד נוסף: הן מזהות קהילות (Communities) בתוך הגרף - אשכולות של ישויות שקשורות בצפיפות זו לזו - ומייצרות עבור כל קהילה סיכום ברמה גבוהה יותר. זה מאפשר לענות גם על שאלות "גלובליות" ("מה הנושאים המרכזיים בכל מאגר המסמכים?") ולא רק שאלות ממוקדות ישות בודדת.

דוגמה למבנה גרף פשוט

(Server: frankfurt-01) -[HOSTS]-> (Service: billing-api)
(Service: billing-api) -[USED_BY]-> (Customer: acme-corp)
(Customer: acme-corp) -[HAS_SLA]-> (Contract: enterprise-gold)
(Contract: enterprise-gold) -[REQUIRES]-> (ResponseTime: "15min")

סוגי מסדי נתונים גרפיים ומודל הנתונים

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

איך מתבצע Retrieval משולב

בזמן שאילתה, מערכת GraphRAG טובה לא בוחרת בין חיפוש גרפי לחיפוש וקטורי - היא משלבת את שניהם. גישה נפוצה: שכבת חילוץ ישויות מזהה אילו ישויות רלוונטיות מוזכרות בשאלה, מבצעת מעבר (traversal) בגרף כדי למצוא ישויות וקשרים קשורים (כולל מעבר כמה "קפיצות" כשצריך), ובמקביל מבצעת Vector Search רגיל למציאת קטעי טקסט תומכים ומפורטים. שני סוגי התוצאות - העובדות המבניות מהגרף, והפרטים הטקסטואליים מה-Retrieval הסמנטי - מוזרקים יחד לפרומפט הסופי, מה שנותן למודל גם את "השלד" הלוגי וגם את "הבשר" הטקסטואלי.

מעברי-קפיצה (Multi-hop) - היכולת שVector Search פשוט לא יכול לתת

הערך המרכזי של GraphRAG מתגלה בשאלות שדורשות כמה קפיצות לוגיות ברצף. "אילו לקוחות בחוזה Enterprise נמצאים על שרתים שעברו תחזוקה בחודש האחרון?" דורשת מעבר משרת לתחזוקה, מתחזוקה לשירותים מושפעים, משירותים ללקוחות, ומלקוחות לסינון לפי סוג חוזה - ארבע קפיצות נפרדות בגרף. Vector Search, גם המשוכלל ביותר, לא יכול לבצע היסק שרשרתי כזה, כי הוא מבוסס על דמיון בין ייצוגים בודדים, לא על מעבר מבני בין ישויות. גרף ידע, לעומת זאת, נבנה בדיוק כדי לתמוך במעברים כאלה - שאילתת traversal שעוברת דרך כמה קשתות ברצף היא פעולה טבעית וסטנדרטית במסדי נתונים גרפיים.

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

Trade-offs: מתי GraphRAG שווה את המורכבות

GraphRAG הוא לא שדרוג "ברירת מחדל" ל-RAG רגיל - הוא מוסיף שכבת מורכבות משמעותית שדורשת הצדקה עסקית אמיתית:

• עלות בנייה ותחזוקה - חילוץ ישויות וקשרים באמצעות LLM על מאגר מסמכים גדול הוא תהליך יקר ואיטי, וצריך לרוץ מחדש (או באופן אינקרמנטלי) בכל פעם שהמקורות מתעדכנים.
• איכות תלויה בדיוק החילוץ - אם שלב Entity extraction מפספס ישויות או יוצר קשרים שגויים, כל שרשרת ההיסקים שבנויה עליהם נפגעת. זה דורש בקרת איכות שלא קיימת ב-RAG טקסטואלי רגיל.
• מתאים בעיקר לדומיינים עתירי-קשרים - תשתית IT, רשתות ארגוניות, מבני בעלות תאגידיים, מערכות רגולציה מורכבות. עבור מאגר מסמכים "שטוח" יחסית (למשל בסיס ידע של שאלות נפוצות), GraphRAG הוא Over-engineering שמוסיף עלות בלי תועלת מקבילה.
• Latency גבוה יותר - שאילתה שדורשת מעבר גרף רב-קפיצות, בנוסף לחיפוש וקטורי, איטית יותר משאילתת Vector Search בודדת.

עדכון גרף לאורך זמן: בעיה שונה מעדכון קטעי טקסט

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

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

שילוב עם Hybrid Search

שווה להבהיר: GraphRAG לא מחליף Hybrid Search - הוא רובד נוסף מעליו. Hybrid Search עדיין פותר את הבעיה של שילוב חיפוש סמנטי וחיפוש מילות מפתח על תוכן טקסטואלי; GraphRAG מוסיף שכבה שלישית שמטפלת בקשרים מבניים בין ישויות. מערכת בשלה מאוד יכולה לכלול את שלושת הרבדים יחד: BM25, Vector Search וגרף ידע, כשכל רובד תורם סוג מידע אחר לתשובה הסופית.

עלות חילוץ: איך מצמצמים בלי לוותר על איכות

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

שאלות נפוצות

האם GraphRAG מתאים לכל מערכת RAG?

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

איך שומרים את הגרף מעודכן כשהמקורות משתנים?

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

איזה מסד נתונים משמש לאחסון הגרף?

מסדי נתונים גרפיים ייעודיים (Graph databases) הם הבחירה הנפוצה, לעיתים לצד Vector Database נפרד לחיפוש הטקסטואלי המשלים.

מה ההבדל בין GraphRAG לגרף ידע קלאסי?

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

האם GraphRAG יקר יותר להרצה מ-RAG רגיל?

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

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

תגיות: GraphRAG · Knowledge Graph · RAG · LLM · Entity Extraction · Graph Database

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