Knowledge Graphs + AI — בניית שכבת ידע למערכות חכמות

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

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

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

המודל הבסיסי - ישויות, קשרים, טריפלטים

הבסיס המתמטי של Knowledge Graph הוא פשוט להפתיע: כל עובדה מיוצגת כ-Triplet - נושא, קשר, מושא (Subject-Predicate-Object). למשל: "דנה - כיהנה_כ - סמנכ"לית מוצר", או "יוסי - מדווח_ל - דנה". אוסף גדול של triplets כאלה בונה גרף שבו ישויות הן צמתים (nodes) וקשרים הם קשתות (edges) בין הצמתים. זה מודל פשוט אבל עוצמתי - הוא מאפשר שאילתות שדורשות "לעבור" מצומת לצומת דרך כמה קשרים ברצף, בדיוק סוג ההסקה שחיפוש דמיון וקטורי לא מסוגל לבצע מעצם טבעו.

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

בניית גרף מתוכן לא מובנה - Entity ו-Relation Extraction

רוב הארגונים לא מתחילים עם גרף ידע מוכן - יש להם מסמכים, אימיילים, תיעוד פנימי. בניית גרף מתוכן כזה דורשת שני שלבים: Entity Extraction (זיהוי ישויות בטקסט - שמות אנשים, מחלקות, מוצרים) ו-Relation Extraction (זיהוי הקשרים ביניהן). היום נהוג להשתמש ב-LLM לביצוע שני השלבים האלה, בעזרת Structured Outputs שמכריחים את המודל להחזיר triplets בפורמט קבוע ומוגדר מראש, ולא טקסט חופשי שקשה לפרסר בצורה עקבית.

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

עדכון גרף בזמן אמת

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

GraphRAG - שילוב גרף ידע עם RAG וקטורי

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

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

גרף ידע מול Vector Database - מתי כל אחד מנצח

ההבדל המהותי הוא סוג השאלה שכל שיטה עונה עליה בטבעיות. חיפוש וקטורי מצטיין בשאלות "מצא לי דברים דומים ל-X" - שאילתות דמיון סמנטי חד-שלביות. Knowledge Graph מצטיין בשאלות "מהו הקשר בין X ל-Y", "מי/מה מחובר ל-Z דרך שני צעדים", או שאלות שדורשות שרשור עובדות בדיוק לוגי - סוג שאלות שמכונה לעיתים Multi-hop reasoning.

• עדיפות ל-Vector Search - חיפוש תוכן חופשי, שאלות "מה נאמר על X", תוכן טקסטואלי עשיר בלי מבנה יחסים ברור.
• עדיפות ל-Knowledge Graph - שאלות ארגוניות/היררכיות (מי מדווח למי), עקיבות (traceability) בין ישויות, שאלות שדורשות שרשור לוגי בין כמה עובדות נפרדות.
• עדיפות לשילוב GraphRAG - מערכות ארגוניות מורכבות שמשלבות תוכן חופשי (מסמכים, מיילים) עם מבנה יחסים ברור (ארגון, פרויקטים, אחריות).

עלות תחזוקה - המחיר האמיתי של גרף ידע

נקודה שקל להתעלם ממנה בשלב ההערכה הראשונית: בניית גרף ידע היא רק ההתחלה - התחזוקה השוטפת שלו היא לרוב ההשקעה הגדולה יותר לאורך זמן. בניגוד ל-Vector Database, שבו re-embedding הוא תהליך פשוט יחסית וניתן לאוטומציה, תחזוקת גרף איכותי דורשת ניטור מתמשך של איכות ה-Entity Resolution, טיפול בקשרים סותרים או מיושנים, ולעיתים גם עדכון ידני של האונטולוגיה ככל שהעסק מתפתח ומוסיף סוגי ישויות וקשרים חדשים.

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

Graph Database - איפה מאחסנים את זה בפועל

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

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

ביצועים - עומק שאילתה וזמן תגובה

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

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

טעויות נפוצות בבניית גרפי ידע

• אונטולוגיה שנקבעת מוקדם מדי ובאופן נוקשה - הגדרת סכימת ישויות וקשרים סופית לפני שהבינו לעומק אילו שאלות המערכת באמת צריכה לענות עליהן.
• הזנחת Entity Resolution - הפקת triplets בלי מנגנון איחוד ישויות, מה שיוצר גרף מפוצל עם אזכורים כפולים לאותה ישות בדיוק.
• גרף שלא מתעדכן - בניית גרף חד-פעמי בלי תהליך עדכון שוטף, מה שהופך אותו למקור מידע מטעה עם הזמן.
• בחירת Knowledge Graph כשחיפוש וקטורי מספיק - השקעה בתשתית מורכבת בלי הוכחה שהשאלות בפועל דורשות הסקה רב-שלבית.

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

בפרויקט GraphRAG עבור מערכת ניהול ידע ארגונית, הצוות הפיק triplets אוטומטית מתוך אלפי מסמכי תיעוד פנימי באמצעות LLM. בבדיקה ראשונית הכל נראה תקין, אבל אחרי שבועיים בפרודקשן התברר ששאלות רב-שלביות (כמו "מי מדווח למחליף של X") מחזירות תשובות חלקיות או שגויות בתדירות גבוהה יחסית. הסיבה: תהליך ה-Entity Extraction יצר כמה צמתים נפרדים לאותו אדם - פעם עם שם מלא, פעם עם תואר תפקיד, פעם עם כינוי מקוצר שהופיע במסמך פנימי אחד - כך שקשרים שהיו אמורים "להתחבר" לאותו צומת התפזרו בין כמה צמתים לא מקושרים. הפתרון כלל בניית שלב Entity Resolution ייעודי שרץ אחרי ה-extraction הראשוני, משתמש בשילוב של דמיון embedding על שמות ישויות יחד עם כללי resolution מפורשים (למשל תואר תפקיד + מחלקה כאיתות לזהות), ומאחד צמתים לפני שהגרף נכנס לשימוש בפרודקשן. הלקח המרכזי: איכות גרף ידע נמדדת בעיקר באיכות ה-resolution, לא רק בכמות ה-triplets שהופקו.

שאלות נפוצות

האם Knowledge Graph מחליף Vector Database?

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

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

באמצעות LLM שמפיק triplets (ישות-קשר-ישות) מתוך טקסט, לרוב עם Structured Outputs כדי להבטיח פורמט עקבי, ולאחר מכן שלב Entity Resolution לאיחוד ישויות כפולות.

מה זה Entity Resolution ולמה זה קריטי?

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

איך שומרים גרף ידע מעודכן לאורך זמן?

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

מתי לא כדאי להשקיע בגרף ידע?

כשהשאלות במערכת הן בעיקר חיפוש תוכן חופשי ולא דורשות הסקה רב-שלבית בין ישויות - במקרים כאלה Hybrid Search עם Reranking לרוב מספיק.

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

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

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