Knowledge Graph Architecture: מעבר לחיפוש וקטורי גרידא

מאת צוות מדיה דיל · 05.09.2026 · AI · 6 דק׳

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

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

למה חיפוש וקטורי נכשל בשאלות רב-שלביות

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

אבני הבניין: ישויות, יחסים וסכימה

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

בניית הגרף: חילוץ ישויות ויחסים מטקסט חופשי

הפיכת מסמכים לא מובנים לגרף דורשת שלב חילוץ (NER — Named Entity Recognition — ואחריו Relation Extraction) שמזהה ישויות וקושר ביניהן יחסים לפי הסכמה שהוגדרה. מודלי שפה גדולים הפכו את השלב הזה למעשי בהיקף רחב — לפני כן זו הייתה עבודה ידנית או מבוססת חוקים שלא סוקלה. עדיין נדרש שכבת אימות: LLM עלול לחלץ יחס שגוי או ישות כפולה בניסוח שונה, ובלי בקרה הגרף מצטבר טעויות.

שאילתת גרף מול חיפוש וקטורי: שני מנועי חיפוש שונים

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

GraphRAG: שילוב שני העולמות

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

תחזוקה: גרף שלא מתעדכן הוא גרף שמשקר

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

סקלאביליות: מסדי גרף ייעודיים לעומת הרחבות

גרפים בקנה מידה ארגוני — מיליוני צמתים וקשתות — דורשים מסד ייעודי (Neo4j, Amazon Neptune) שבנוי לביצועי Traversal, לא מסד יחסי רגיל עם טבלת קשרים. הבדל הביצועים בשאילתות רב-קפיצתיות (Multi-hop) בין מסד גרף ייעודי למימוש נאיבי ב-SQL יכול להגיע לסדרי גודל, במיוחד ככל שהעומק גדל.

מתי בכלל שווה את המורכבות

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

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

תגיות: Knowledge Graph · GraphRAG · AI · Vector Database · Neo4j

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