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

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

שילוב בין טכנולוגיות RAG לתורת הגרפים לשליפה מדוייקת של מידע

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

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

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

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

אבל דמיון סמנטי לא תמיד מספיק.

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

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

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

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

ההבדל בהכנת המידע ל-GraphRAG לעומת RAG רגיל

אחד ההבדלים החשובים ביותר בין RAG רגיל לבין GraphRAG נמצא עוד לפני שהמשתמש שואל את השאלה.

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

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

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

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

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

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

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

הבדל נוסף הוא הצורך בסכמה ברורה.

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

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

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

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

זו בדיוק הסיבה שהכנת מידע ל-GraphRAG מורכבת יותר מהכנת מידע ל-RAG רגיל. היא דורשת גם הכנה סמנטית וגם הכנה מבנית. גם טקסטים וגם ישויות. גם embeddings וגם קשרים. גם מסמכים וגם שכבת ידע.

כיצד אחזור תשובה עם GraphRAG עובד (הסבר לקהל הרחב)

ברמה פשוטה, GraphRAG הוא תהליך בן כמה שלבים.

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

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

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

4 בשלב הרביעי, המידע המסונן מועבר למודל השפה או לסוכן ה-AI, שמייצר תשובה על בסיס ההקשר שנאסף.

ההבדל הגדול בין GraphRAG ל RAG רגיל הוא שהמודל אינו מקבל רק אוסף טקסטים דומים. הוא מקבל תמונה מאורגנת יותר של הקשרים סביב השאלה.

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

מתי GraphRAG עדיף על RAG בסיסי

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

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

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

היתרונות המרכזיים של GraphRAG: דיוק, המשמעות וממשל נתונים

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

היתרון השני הוא הבנת המשמעות של המענה. בארגונים, לא מספיק לקבל תשובה. חשוב להבין על מה היא מבוססת. GraphRAG מאפשר להציג מסלול לוגי יותר: אילו ישויות היו מעורבות, אילו מסמכים שימשו כמקור, אילו קשרים חיברו ביניהם, ומה היה הנתיב שהוביל לתשובה.

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

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

האתגרים שחשוב להכיר

כמו בכל טכנולוגיה גם ל GraphRAG יש כמה אתגרים שחשוב להכיר:

1 האתגר הראשון הוא איכות גרף הידע. אם הישויות אינן מוגדרות היטב, אם הקשרים אינם עקביים, או אם מקורות המידע אינם מנוהלים, ה GraphRAG יתקשה לייצר תשובות אמינות.

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

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

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

לסיכום: GraphRAG הופך תורת הגרפים למפת ההקשר של סוכני ה AI

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

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

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